From housley@vigilsec.com Fri Jan 20 10:32:43 2006 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 k0KFWgsL018892 for ; Fri, 20 Jan 2006 10:32:42 -0500 (EST) Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) k0KFW8lR023236 for ; Fri, 20 Jan 2006 10:32:09 -0500 (EST) Received: (qmail 12765 invoked by uid 0); 20 Jan 2006 15:32:05 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.4.63) by woodstock.binhost.com with SMTP; 20 Jan 2006 15:32:05 -0000 Message-Id: <7.0.0.16.2.20060120102902.065f16a8@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Fri, 20 Jan 2006 10:32:04 -0500 To: saag@mit.edu From: Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.628704 Subject: [saag] Message on Behalf of RAND Europe 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, 20 Jan 2006 15:32:44 -0000 I have agreed to forward this message to the SAAG list. Please respond directly to Lorenzo Valeri (lvaleri@rand.org) if you have any interest. I do not expect to discuss the content of this message on this mail list. Russ = = = = = = = = = RAND Europe has been asked by the European Commission to undertake a study into the Security Challenges to the Use and Deployment of Disruptive Technologies. The study will focus on implementations of five 'disruptive' technologies, listed below. Disruptive technologies can be defined as a new technology that unexpectedly displaces an established technology. The technologies under review are: * Radio Frequency ID (RFID) technology * WiMAX (Wireless Metropolitan Area Networking) * Trusted Computing * Voice over IP (VoIP) * Internet Protocol version 6 (IPv6) The project, which is set to last 6 months, will commence with a Delphi exercise to identify main security challenges associated with these five technologies. The Delphi exercise is expected to inform five case studies, which will be a closer look at specific implementations of each technology. The findings of this work will be discussed during a workshop to be held in Brussels during the last week of May 2006. The aim of the Delphi survey is to identify the security challenges that are associated with these technologies by asking experts in the area what they foresee as the main issues to address. A Delphi survey is a way of forecasting the challenges and likely futures associated with an issue through the knowledge of experts in the field. In the case of the 5 technologies we are studying, this would be based around the sorts of security challenges that face them (either technical, social or economic challenges). The Delphi survey would involved the following two steps: First Part: In the first section, participants are expected to answer the following general question: "What are the key shared security challenges to the use and deployment of the five technologies mentioned above?" Participants would be expected to produce a list and a set of general comments about the challenges they foresee in a concise format (not more than two or three paragraphs per challenge). These will be emailed back to the Lorenzo Valeri (lvaleri@rand.org), senior analyst RAND Europe, who will collate them and remove any duplicate findings or suggestions. Second Part: In the second part of the Delphi survey, RAND Europe will send out a full list of the suggested security challenges to those who have responded and ask them to rate the top ten security challenges from the list and send their list back to us at RAND Europe. This second part is expected to be finish by February 7, 2006. If you are interested in participating, please provide Lorenzo Valeri (lvaleri@rand.org) with two or three paragraphs in response to the First Part question above. These security challenges should cover things like socio-economic, regulatory and economic challenges as well as those relating to privacy, operational risks, and consumer protection. It may be that some challenges are not obviously applicable to all of the technologies listed; however, these may be useful in stimulating discussion on general challenges and should not be overlooked. From tim.polk@nist.gov Thu Jan 26 11:35:19 2006 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 k0QGZIsL015639 for ; Thu, 26 Jan 2006 11:35:18 -0500 (EST) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) k0QGZBoJ012779 for ; Thu, 26 Jan 2006 11:35:13 -0500 (EST) Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k0QGZ6fg022357 for ; Thu, 26 Jan 2006 11:35:07 -0500 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 k0QGYR3v005426 for ; Thu, 26 Jan 2006 11:34:28 -0500 (EST) Message-Id: <5.1.0.14.2.20060126111823.031e7720@email.nist.gov> X-Sender: wpolk@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 26 Jan 2006 11:35:03 -0500 To: saag@mit.edu From: Tim Polk Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_-1104723118==_" X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: tim.polk@nist.gov X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.683233 Subject: [saag] Fwd: The Second Cryptographic Hash Workshop Call for Participation 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, 26 Jan 2006 16:35:20 -0000 --=====================_-1104723118==_ Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Folks, NIST has published the call for papers for our next hash function=20 workshop. The workshop will follow Crypto 2006. I have forwarded the CFP= =20 to this group because I believe that IETF involvement is crucial to this=20 project's success. The workshop has three goals: =95 Explore potential mathematical principles and structures that can= provide=20 the foundation for cryptographic hash functions; =95 Foster accelerated research on the analysis of hash functions,= especially=20 the SHA-2 hash functions; =95 Survey the uses of hash functions, and investigate the properties that= =20 are assumed, used, or needed. Identify and articulate the required or=20 desirable properties for future hash functions. To accomplish the third goal, we will need the support and participation of= =20 protocol designers in addition to cryptographers. I would strongly=20 encourage the readers of this list to participate in this workshop. We=20 need the benefit of your insights and expertise. Thanks, Tim Polk >X-Sieve: CMU Sieve 2.2 >X-Sender: sjchang@email.nist.gov >X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 >Date: Wed, 25 Jan 2006 15:06:20 -0500 >To: shu-jen.chang@nist.gov >From: Shu-jen Chang >Subject: The Second Cryptographic Hash Workshop Call for Participation >X-NIST-MailScanner: Found to be clean >X-NIST-MailScanner-From: shu-jen.chang@nist.gov > >The Second Cryptographic Hash Workshop >Santa Barbara, CA >August 24-25, 2006 (Starting at 1PM, August 24) >Submission deadline: May 12, 2006 (Workshop without proceedings) > >As a follow-up to the first Cryptographic Hash Workshop held on Oct.=20 >31-Nov. 1, 2005, NIST plans to host a series of public workshops to focus= =20 >on hash function research. The next workshop will be held on August=20 >24-25, 2006, in conjunction with Crypto 2006, at UCSB, Santa Barbara.=20 >Attached is the Call for Participation for the Second Cryptographic Hash=20 >Workshop. Details about the workshop will be available at the following=20 >web site shortly: http://www.nist.gov/hash-function > >Shu-jen Chang >Computer Security Division >NIST > --=====================_-1104723118==_ Content-Type: application/pdf; name="Second Cryptographic Hash Workshop CFP.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Second Cryptographic Hash Workshop CFP.pdf" JVBERi0xLjQNJeLjz9MNCjEyNCAwIG9iajw8L0hbODUxIDI0MV0vTGluZWFyaXplZCAxL0UgMTk2 ODIvTCAzMDcwMC9OIDIvTyAxMjcvVCAyODE3Mj4+DWVuZG9iag0gICAgICAgICAgICAgICAgICAg DQp4cmVmDQoxMjQgMjcNCjAwMDAwMDAwMTYgMDAwMDAgbg0KMDAwMDAwMTI2OSAwMDAwMCBuDQow MDAwMDAwODUxIDAwMDAwIG4NCjAwMDAwMDE1MDUgMDAwMDAgbg0KMDAwMDAwMTgzNiAwMDAwMCBu DQowMDAwMDAyNTEzIDAwMDAwIG4NCjAwMDAwMDI5NDYgMDAwMDAgbg0KMDAwMDAwMjk4MiAwMDAw MCBuDQowMDAwMDAzMjIyIDAwMDAwIG4NCjAwMDAwMDM0NjggMDAwMDAgbg0KMDAwMDAwMzU0NSAw MDAwMCBuDQowMDAwMDA0MTk2IDAwMDAwIG4NCjAwMDAwMDQ5MDYgMDAwMDAgbg0KMDAwMDAwNTAz OSAwMDAwMCBuDQowMDAwMDA1MzM3IDAwMDAwIG4NCjAwMDAwMDYwMDMgMDAwMDAgbg0KMDAwMDAw NjY5MCAwMDAwMCBuDQowMDAwMDA3MDA4IDAwMDAwIG4NCjAwMDAwMDc2ODcgMDAwMDAgbg0KMDAw MDAwODIyMCAwMDAwMCBuDQowMDAwMDA4NzYwIDAwMDAwIG4NCjAwMDAwMDkyODEgMDAwMDAgbg0K MDAwMDAxMTk1MSAwMDAwMCBuDQowMDAwMDE5MDI2IDAwMDAwIG4NCjAwMDAwMTkyNTcgMDAwMDAg bg0KMDAwMDAxOTQ0OSAwMDAwMCBuDQowMDAwMDAxMDkyIDAwMDAwIG4NCnRyYWlsZXINCjw8L1Np emUgMTUxL1ByZXYgMjgxNjAvWFJlZlN0bSAxMDkyL1Jvb3QgMTI1IDAgUi9JbmZvIDEyIDAgUi9J RFs8OTQyZTEzMzM1NWIyYjhlY2Q0N2E2NTFkZGEyMWU1YTg+PDEyMDgyNGRiZjA4ZmVkNGM4ZGVm YTIxYTRlZGE0YzhmPl0+Pg0Kc3RhcnR4cmVmDQowDQolJUVPRg0KICAgICAgICAgICAgDQoxMjYg MCBvYmo8PC9MZW5ndGggMTU0L0ZpbHRlci9GbGF0ZURlY29kZS9DIDE2My9MIDE0Ny9TIDc4Pj5z dHJlYW0NCnjaYmBgYGZgYPnAwMrAwPaRgZ8BAfgZWICiLAwcCxgaFBgY7sHEeRo1pkxOCl6aB2Qr eXQ0gMQ6OhpAaoCAhYEh6BGQFgdiSbCICgMvp8UCZykGhjRmD1aldFEBCSce9UTXloyAxI/8BypD pm7/kNhUILFAhvkF1AoOBoboLCDNBMQWQMzGwBB8GMJnXw6mWY8eAAgwAD7oHtANCmVuZHN0cmVh bQ1lbmRvYmoNMTUwIDAgb2JqPDwvU2l6ZSAxMjQvTGVuZ3RoIDI3L0ZpbHRlci9GbGF0ZURlY29k ZS9EZWNvZGVQYXJtczw8L0NvbHVtbnMgMy9QcmVkaWN0b3IgMTI+Pi9XWzEgMSAxXS9UeXBlL1hS ZWYvSW5kZXhbMTMgMTExXT4+c3RyZWFtDQp42mJiYmNgYmBgHMWDBTPOJVYtQIABAEkdAfINCmVu ZHN0cmVhbQ1lbmRvYmoNMTI1IDAgb2JqPDwvUGFnZXMgMTAgMCBSL1R5cGUvQ2F0YWxvZy9QYWdl TGFiZWxzIDggMCBSL1N0cnVjdFRyZWVSb290IDEzIDAgUi9NZXRhZGF0YSAxMSAwIFIvUGllY2VJ bmZvPDwvTWFya2VkUERGPDwvTGFzdE1vZGlmaWVkKEQ6MjAwNjAxMjUxNDA1MTMpPj4+Pi9MYXN0 TW9kaWZpZWQoRDoyMDA2MDEyNTE0MDUxMykvTWFya0luZm88PC9NYXJrZWQgdHJ1ZS9MZXR0ZXJz cGFjZUZsYWdzIDA+Pj4+DWVuZG9iag0xMjcgMCBvYmo8PC9Db250ZW50c1sxMzQgMCBSIDEzNSAw IFIgMTM4IDAgUiAxMzkgMCBSIDE0MSAwIFIgMTQyIDAgUiAxNDMgMCBSIDE0NCAwIFJdL1R5cGUv UGFnZS9QYXJlbnQgMTAgMCBSL1JvdGF0ZSAwL01lZGlhQm94WzAgMCA2MTIgNzkyXS9Dcm9wQm94 WzAgMCA2MTIgNzkyXS9SZXNvdXJjZXM8PC9Db2xvclNwYWNlPDwvQ1MwIDEzMCAwIFI+Pi9Gb250 PDwvVFQyIDE0MCAwIFIvVFQwIDEyOCAwIFIvVFQxIDEyOSAwIFIvQzJfMCAxMzYgMCBSPj4vUHJv Y1NldFsvUERGL1RleHRdL0V4dEdTdGF0ZTw8L0dTMCAxMzMgMCBSPj4+Pi9TdHJ1Y3RQYXJlbnRz IDA+Pg1lbmRvYmoNMTI4IDAgb2JqPDwvVHlwZS9Gb250L0VuY29kaW5nL1dpbkFuc2lFbmNvZGlu Zy9CYXNlRm9udC9UaW1lc05ld1JvbWFuUFNNVC9GaXJzdENoYXIgMzIvTGFzdENoYXIgMjI5L1N1 YnR5cGUvVHJ1ZVR5cGUvRm9udERlc2NyaXB0b3IgMTMxIDAgUi9XaWR0aHNbMjUwIDAgNDA4IDAg MCAwIDAgMCAzMzMgMzMzIDAgMCAyNTAgMzMzIDI1MCAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAw IDUwMCAwIDUwMCAwIDI3OCAyNzggMCAwIDAgMCAwIDcyMiA2NjcgNjY3IDcyMiA2MTEgNTU2IDcy MiA3MjIgMzMzIDAgMCAwIDg4OSA3MjIgNzIyIDU1NiAwIDAgNTU2IDYxMSA3MjIgNzIyIDk0NCAw IDAgMCAwIDAgMCAwIDAgMCA0NDQgNTAwIDQ0NCA1MDAgNDQ0IDMzMyA1MDAgNTAwIDI3OCAyNzgg NTAwIDI3OCA3NzggNTAwIDUwMCA1MDAgNTAwIDMzMyAzODkgMjc4IDUwMCA1MDAgNzIyIDUwMCA1 MDAgNDQ0IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNDQ0XT4+DWVu ZG9iag0xMjkgMCBvYmo8PC9UeXBlL0ZvbnQvRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL0Jhc2VG b250L1RpbWVzTmV3Um9tYW5QUy1Cb2xkTVQvRmlyc3RDaGFyIDMyL0xhc3RDaGFyIDEyMS9TdWJ0 eXBlL1RydWVUeXBlL0ZvbnREZXNjcmlwdG9yIDEzMiAwIFIvV2lkdGhzWzI1MCAwIDAgMCAwIDAg MCAwIDMzMyAzMzMgMCAwIDI1MCAzMzMgMjUwIDI3OCA1MDAgNTAwIDUwMCA1MDAgMCAwIDUwMCAw IDAgMCAzMzMgMCAwIDAgMCAwIDkzMCA3MjIgMCAwIDcyMiAwIDAgMCA3NzggMCA1MDAgMCAwIDk0 NCA3MjIgMCAwIDAgMCA1NTYgMCAwIDcyMiAxMDAwIDAgMCAwIDAgMCAwIDAgMCAwIDUwMCA1NTYg NDQ0IDU1NiA0NDQgMzMzIDUwMCA1NTYgMjc4IDAgNTU2IDI3OCA4MzMgNTU2IDUwMCA1NTYgMCA0 NDQgMzg5IDMzMyA1NTYgNTAwIDcyMiAwIDUwMF0+Pg1lbmRvYmoNMTMwIDAgb2JqWy9JQ0NCYXNl ZCAxNDUgMCBSXQ1lbmRvYmoNMTMxIDAgb2JqPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250QkJv eFstNTY4IC0zMDcgMjAwMCAxMDA3XS9Gb250TmFtZS9UaW1lc05ld1JvbWFuUFNNVC9GbGFncyAz NC9TdGVtViA4Mi9DYXBIZWlnaHQgNjU2L1hIZWlnaHQgMC9Bc2NlbnQgODkxL0Rlc2NlbnQgLTIx Ni9JdGFsaWNBbmdsZSAwL0ZvbnRGYW1pbHkoVGltZXMgTmV3IFJvbWFuKS9Gb250U3RyZXRjaC9O b3JtYWwvRm9udFdlaWdodCA0MDA+Pg1lbmRvYmoNMTMyIDAgb2JqPDwvVHlwZS9Gb250RGVzY3Jp cHRvci9Gb250QkJveFstNTU4IC0zMDcgMjAwMCAxMDI2XS9Gb250TmFtZS9UaW1lc05ld1JvbWFu UFMtQm9sZE1UL0ZsYWdzIDM0L1N0ZW1WIDEzNi9DYXBIZWlnaHQgNjU2L1hIZWlnaHQgMC9Bc2Nl bnQgODkxL0Rlc2NlbnQgLTIxNi9JdGFsaWNBbmdsZSAwL0ZvbnRGYW1pbHkoVGltZXMgTmV3IFJv bWFuKS9Gb250U3RyZXRjaC9Ob3JtYWwvRm9udFdlaWdodCA3MDA+Pg1lbmRvYmoNMTMzIDAgb2Jq PDwvVHlwZS9FeHRHU3RhdGUvU0EgZmFsc2UvT1AgZmFsc2UvU00gMC4wMi9vcCBmYWxzZS9PUE0g MT4+DWVuZG9iag0xMzQgMCBvYmo8PC9MZW5ndGggNTgxL0ZpbHRlci9GbGF0ZURlY29kZT4+c3Ry ZWFtDQpIiYyTUWvbMBDH3/0p7lGGWJFk2bFHKaRpt3aQrhDBHtY9KLYXa0ulYMkN3aef5CRNx5ow jPGdkO5+99ff4we4uBjPZ3fXQODy8up6BtF4tiBQWb8QHrCVjigov/7Jr69sdCWisRAEKIgfEcGE MBAVJCEK4TYcEhYoCd/fPhOdT3CZlZQOJUNSQElgklLMs7LMQTxF35BoG1g0ldE1xBmadS9xMkGb OGHIxTkyq05uWuWjCm6lbeGr6X7Z1mwg/i4+RzciupkH+uNE9DDRP8SkDMiHaHsKjxa48FvSHd5C aifhSnZL2cVJhuQIZtOTzdnJ5uyNXvxMd5JjygfA0H3ar3rrgPGExRxl/h0BI8R/c3hECyc7F7TR K5AO6MN8BNN4gvaH/C4eJxQ9xid507956ZGX5ke1PORJ4LxMMS/89r1c/fJJWauMhqBW3ch6rXTz AebyBSgb6AO6h369ya1yrekdbDpTNU2t9MqeQebvSzzAnsEsCC4KkvGAiSAWP9+rnZ28vjDfXg12 pkteYMZITndi3GnoGrsx2jbgDLjg9NtpQuG5X+umk0u1VsHk3vIFCu53rXTD3EPL4jjTBKecZyGp fV3YSgtSa9PrqqlBafjYLLE/H9TNRnB/txChXNusa5DwWpGFizyYMB0uNTmUTiimWbqr//8/ofEe 02EbfKkchpQm9+YZH0co3zTcu6jEKcv56ygek44GrwZXkywIZc3a91IxRZXytvDr/XKtKj/oEA9Y +9YcgXLWjwh/BBgAjowpjw0KZW5kc3RyZWFtDWVuZG9iag0xMzUgMCBvYmo8PC9MZW5ndGggNjQw L0ZpbHRlci9GbGF0ZURlY29kZT4+c3RyZWFtDQpIiXxUX2+bMBx851P8HkEqFBMgQaoq9U+kddKm SeGt3YMLTmAltmWTRvv2O5skdFK3N+zYd/e7O6f+GqRJmrIV1Q2lVB8pZlWyyMocHwkrFlS3wXPY mN9RvAx1FGfhqHaG665volVIHbcdbQ+yGXslSavoZ31CLDwivtIFc7gsS4qMMUfiEAfcX4ZABQiX LVmsRnxw09qE6PvTpqZGybGXB2EpKkBLRjRqvxfSXWqJ02i4tL1nnnkr5ohjz8zYNNGJ+uNEW6P2 boDNl7uYEcDHTtDAzU4Y4lob9S5aR/vXgJZewg02cSfL8it/OSvK6WOxwg6XUQ5tbj1Lms1NvYZ8 WUDYI1QULHuJMO5TVIbSmYsZrQaROEs6whflfjFvtlP6CuyTORBGfLCKWtH0LcSOHR+pH53oozoM Lb0K0gbAByfJQQiJA5JG7HV+TYPCb3I3a3U2XeybgksvvjnFozDet9ERv4tBacxMvG2RA3CV5MNc ChzE7ic+sDLJ87kMCHDsnFR12HVuAE768IqKoAJ7LUaf8RXZ3lH3SOnsjseOz2gf8z2Jcxfc2FFc hAi1EdbSVhl/+XVQzRs1ve4EThlvTXdReyrPM1y6a985TsgGLq8l3oL2nduc+opS3K03PsdJ0LoO 1t8eKLj+QTc3198enh6ppNvb+0fs3dfBdV2nBPBtkM6GpElVVN6R1C9WVKVULKukLNmionofhBTV vz7DXn6OfXH8H9jl0p3IC4f9HN4L2CLgAbzmeHU7b1HjH4l/9pcUfPuQkR7w+lwQ/3t7+DMp2Cq9 JN0p6xtqEY9BVVwujmKquDjHflSoO7bReDsV+9gPAwoCMvojwACR1UX4DQplbmRzdHJlYW0NZW5k b2JqDTEzNiAwIG9iajw8L1R5cGUvRm9udC9FbmNvZGluZy9JZGVudGl0eS1IL0Jhc2VGb250L01C T0NQTitTeW1ib2xNVC9TdWJ0eXBlL1R5cGUwL0Rlc2NlbmRhbnRGb250c1sxNDggMCBSXS9Ub1Vu aWNvZGUgMTM3IDAgUj4+DWVuZG9iag0xMzcgMCBvYmo8PC9MZW5ndGggMjI4L0ZpbHRlci9GbGF0 ZURlY29kZT4+c3RyZWFtDQpIiVSQsW7DIBCGd57ixkYZIDRVO1gs6eIhbVW73QmcHaQa0BkPfvsC tRJ1AHT/3Xf3c/zUvrbeJeAfFEyHCQbnLeEcFjIIFxydh4ME60zaonqbSUfgGe7WOeHU+iFA0zD+ mZNzohUe+v5pL3bA38kiOT9m5Si/vrPSLTH+4IQ+gQClwOLA+Oms45ueEHgF72K/RgRZ48M2O1ic ozZI2o8IjRDiUZXn+UUBevs/z+QfdRnMVRO7V0uh2AY1UkipWGa3qtKl/PDmyixE2XBdQ7VVDDmP t03FEMvsctivAAMAGddtKAoNCmVuZHN0cmVhbQ1lbmRvYmoNMTM4IDAgb2JqPDwvTGVuZ3RoIDU5 Ni9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSImcVF1r3DAQfPev2EcJzo5kW/5oj0BySWkL gUL9VkpRbd1ZqWMZS+4l/74r+y53gYRCMBhpLc3Ozuy6+hqwiDGeQVWDX7EYqj2EvIwELxjHVcTT XHComoBsTT1ZMD200rawnfraadyNyio51m0EULUKevXoYG/GP5ZW9wt8McN7ZATOWSlKv2uCH6Q1 A1BB9rrr4LeCVnWNT3A17SbrIE5DmpFYrCBmLFuB7oH+rBbOMeceNfRrkfMj7QXd0xbJkqI2/f2B Kk0J7LVrgYaCbManwRmIMTiD+5j/6A/5tcNatqbrzF73O9gZSQvS2Q8Lg9squL3bQHDxDdbri7vN lxso4PLy+gZj11VwUVUMkNM2YKfSWYTUkDXDx28KKBmIuIxYwcscqocAE6Nkr2CX59ib+NcBfC6e LUK8Ac9FlKVxmnn4NWN5gReSS8xyRtFbJJ47IJm15P6aONp0+zh0ZlQw0IQYGsbEqd5p2cGDRJnw pWvcDKPuaz10yoLsm5NVS1PxIspFfkS0bpxqN2HvgGulg1r2eN/81Y2CRXlMNfWNnH1LCAbGE+JZ R4UH3BeWj080zMkwM8UOMrtRDq2u0cEXvYtW9/YjvGkpZ+/VPS1wgtKEJf/RneVH3fkrsn8y1qkR ZF3TMCWqUyMNMyKdauah80E/eHO74tR43WQvOyy+IJZyou2ZZFn5bPEhVx4lSfKczGxP2qBQXne7 AmUHVWtJw4R03dOc4vvnqzBezp7QS37myAH4ZAk5/ixQ7TdaHDm9V+ssiQSLSy81/BNgACsaN3IN CmVuZHN0cmVhbQ1lbmRvYmoNMTM5IDAgb2JqPDwvTGVuZ3RoIDYxNy9GaWx0ZXIvRmxhdGVEZWNv ZGU+PnN0cmVhbQ0KSIl8VEtvnDAQvu+vmCNIi2PzCCBFOeQhNZVSVQq3qAcHhuCWALXNrvLvOza7 bDaKegJj+J6DrzjPC855cl393lxUFQcBVbvhjHNxCVUN7o7HUO1BsMs0zoBD1Wyeg6dZ7zAsgvcw KgKwHcJsaIkGxhY6aTpo56G2ahzMFuTQgBp2aMJf1fcFnIsVPS89fM7yIk7KI4FVr9KiR570OKG2 isBtJy1IjSCNmR31GzbusiV6bLYwajhxpCtF6hiilSISTGTJwjMgNtgweGhwsKp992IlsdVzfxSg 8e+sNDYe/jJo0CgtX/ozZS3ttbOdSZuzHybBKQG2iLqvNvePt7C5+AlXVxePtw93IGK4vr65o4c3 1cf8vXIfC2dlVgpBK+4XBZQc0qRgokg4eXjbBBBSeV+BJ1+Du2ySNZvsPzRxxrI4EY7lOfjx8FSB GXtVK2soE4NS190WjBsFPwdUdaNMPRtDrmGSE65lLBWIkiUiS5eOA03vTw5nsPIwKbU0CMbODUVK m3LA3oc8GtnTA2fUy8+c/OgI97FPV9/k+1OTR4VWj29hHoDse5pCi8RocXkpjLLAM6mh7j8NzpnW 54AkDa+ra3Ta3ddmMW5xoaAtZbG2tLvDoRn1Yfo99pd6aW41DQj4dPeKNJJZ68cuzAJZ1zgtaidH hGFMsZ0gPzRYsCIpxSHas1iBQvB4h/Ri4X++yH/s2t1DweK8OFrdj/qP6cbJCdjjCxiydE75+WyI 4pwJkQvvLM0zsQC5VOfG/0NUqxpAwordEeA4WwbfKLgxjGKi2p3mJY5PEtODvyw5nj/wT4ABALPa T0wNCmVuZHN0cmVhbQ1lbmRvYmoNMTQwIDAgb2JqPDwvVHlwZS9Gb250L0VuY29kaW5nL1dpbkFu c2lFbmNvZGluZy9CYXNlRm9udC9Db3VyaWVyTmV3UFNNVC9GaXJzdENoYXIgMzIvTGFzdENoYXIg MTExL1N1YnR5cGUvVHJ1ZVR5cGUvRm9udERlc2NyaXB0b3IgMTQ5IDAgUi9XaWR0aHNbNjAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDYwMF0+Pg1lbmRvYmoNMTQx IDAgb2JqPDwvTGVuZ3RoIDYwOS9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSIl0VDtv2zAQ 3v0rbqQKW6Eky7aKIEMeBVIgSYFyMzrQEh2zpUVCpGrk3/eOsS0lTTbyKH6vO2rNuim0Fra22ycr Jg0cbPfH76wD19laqUa3zx5P4KCNgY2C5Jf4PuEp59kcRA204rg6wCxbpWWRl7hIs7IA0UyY6zdG +51qUni8/ylAtbXtO/msPMIrr9ogg07E71fARXVGzDKCzMq0nK+WGXBCWzPbepBtA51ytgsebEsw RpN03coumZXsJTqAsJMBkpI52QVdaydb/N4Z2R4NvCo+4Q+S1yxYOMoGZbw67FSnUhAW5F+rGwjJ gu2SWc4UOOu9xu3GKGh6ZzTx1+gIddktOOlUh4LrWrmgGsoYZdEFn+RsCFqiejR1DvZoXnxBMTfd SzJbMkeExGxpATnniymaI4O+30T7KIXiiW16fBLUqhoLukH5zdC08hxxEVlynhbL/JzwSaQf5Okt FlSyZC+RW3YKkNMHTFRLY7CK0/FuKmYn2HGwPuazRyRtJLJYwoWoH0t0dvTwJjGqxxRW71MYOKss ko4nZ5VWRT74osRSvEmJCet07SP4KbwROXruTQPUppZoatM3akr3Nn0Ycf43rLMz59g0xdXaAMch JVfBTsdTtLXG2AM+s6+v6HdicvdwA5OLH3B5efFwc38LGOrV1fUtFq/F5EIIDsi4pSGuIU5yxtOq rDKyy+NmBRWHIsvSJZ8XOYj9BK3jO/sIvPwYHJ3lyyHX6nOevKpSPp8XFfGs2YPEvu6TiuFLqPGP 8s32LcbXxIfhsf65z8VbKflIShZ7DP8EGACqp0QnDQplbmRzdHJlYW0NZW5kb2JqDTE0MiAwIG9i ajw8L0xlbmd0aCA0NjMvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJpFJNT9wwEL3nV8zR lojXduzEVhFS2aUqlVbi4BvtIdqYJWWTrJwsFf31HQfYqjRZpFa5jJ2ZN+/DHNwPEJxZbYUAjl88 GBBSM2utzkCanGVGqRxck5AOqPueLJzDRnB3CWecC4nlBmLJ8xGP5UpqxHJVckuuBx/KoX700A/h sKGpIsMh+P4MaubZGazKhhZkS1NDvmZKhypd+/Cw89AFKHc43I7T/Qeg39yX5MolV+slJIsbOD9f rJfXKxAFXFxcrvDy0kVu8jc3KZ65vS+zyFghlZbzMnN7lBlR3+pcdjQtSEMN2dNUElTY110Ld4d2 M8Ri07XPBkQV075JplX2iheH0CTPtgw9eqx9j8Y8RZs8RfgTdph/tyOPZAqQuWA8V9pOupGOlOXf Fnwu+/u63UI0oYsmVNES/6oilG3VUUWa+qev4P6lGWN+8DjwNPaitAqoJi9/T6i00yrflaYMU7my xXzQ6hiLequRfOpCU+5gH7q9DwOGwkaECYKS/0mQHwnOB2DH/fieZaaZ4ToSQJazK8T0iunXemqd zJhQWsRtt+RjW+7GNHpMo+4BY4uRrHxfb9vZQKT8/2eHZ2W0OJGNHZHglwADAOFoGxENCmVuZHN0 cmVhbQ1lbmRvYmoNMTQzIDAgb2JqPDwvTGVuZ3RoIDQ3MC9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0 cmVhbQ0KSIms00tvnDAQAOA7v2KOthS8YDAPNYqUl9RWShUp3KoeKJjF1a5NbW/T9td3DOmm7SZ7 qFZcwFjj+WbGccKSJElTaB4hZUXOBSTQ9NFHcqnbzQ8al8RRTpSDVvdABemlU2sNZoCxdbQiI405 gQH/7HTnlaE50ctmP0ploTNb3DUZLbV3b4B+at5Ht010e3cN0eoezs9Xd9fvboBncHFxdYOLV020 ahoOmNIQhex4yK4LaWGKCatFjQsJPuGjgpQXuCmt8K0uWcUFhmq2ETFAmy8hVPIcKs3mSIEsDsUf 5CN0Fs2Yb1D5dilBRTzyVAdedqNWX3c0IxKN61Zp50MdRhie9BnqjyjzEygrwdJCHEHme2R+iHyQ 3c4qP7PAyslYD0aD/K6cV3odWvwnSLszkG6SnWo3Sy3g4e1lzI8YxQmMJWeiEEX5n8jGmI2DwVhY xjXAwkjuG/ozzDQuhuksQ7crYqVz6H2GHyEWJyCKmtWJKMXrxGJP5IfEe2u+tZ83EiZrJmm9wonE S/l03cL4WhoL8i8Ku8nW7Cy02cp+tyyCN0vfbR/CYdStY6/ry7/1v1M+5q7n2mQZpHnJeC4qPrNn 9UtHVC8fEarC5wLDLwEGAOrlLf0NCmVuZHN0cmVhbQ1lbmRvYmoNMTQ0IDAgb2JqPDwvTGVuZ3Ro IDQ1MS9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSImkk71u2zAURnc9xR1JoJL5IzIiEmRI nKEFAnhQuxQdaJmCWciSSkpo+/YlmcSO69iLoYUihe/ec3hFCkKIhPo3UFIooSgFEp74UoEi4ZRx DpSXhahEVUG9y76jldPNZBvdAc4F+uqNB91vYGWnVnedB/yj/pI91dnT8yNkixXc3S2eHz8vgSm4 v39Yhs2HOlvUNQMKdZulKqFw3YTKH3dCmQwf0SquaKGYUCK2ggbA9c8YRQ5RVKSkCMZpyitkyUTM 3oTmU7tDC1vtt6n/du4DzdB7sD1oLNE4dgHuZStyjW6Yhmbo/O1ZMk6uI2ORjKiCM8nZeTK6J7s5 BVu5YTRusu/wDmjTVk+gnQHtcV4iPyeSFCr3oSyFyqIspVBvsTuz+QTO/Jqti6vBwbDGHE3a9mYD Nvjqcc5QsJSGwlyQRK+TxIMkJQspZXle0f80R4q+zV1vnF7bzp54whV6UdXo2QeygyDyTrt6VcSF IvQtdv0X5xWCuTd/RtNMJo3M/i4c7PANsjiXQbu/5Idd50cQAVUZFrK88HfwPYw4FbQ03gY/nYkE EWqMd/tK0gaUdp7mMEXH01UcI8E/AQYAV4gWfA0KZW5kc3RyZWFtDWVuZG9iag0xNDUgMCBvYmo8 PC9MZW5ndGggMjU3NS9GaWx0ZXIvRmxhdGVEZWNvZGUvTiAzL0FsdGVybmF0ZS9EZXZpY2VSR0I+ PnN0cmVhbQ0KSImclnlUU3cWx39vyZ6QlbDDYw1bgLAGkDVsYZEdBFEISQgBEkJI2AVBRAUURUSE qpUy1m10Rk9FnS6uY60O1n3q0gP1MOroOLQW146dFzhHnU5nptPvH+/3Ofd37+/d3733nfMAoCel qrXVMAsAjdagz0qMxRYVFGKkCQADCiACEQAyea0uLTshB+CSxkuwWtwJ/IueXgeQab0iTMrAMPD/ iS3X6Q0AQBk4ByiUtXKcO3GuqjfoTPYZnHmllSaGURPr8QRxtjSxap6953zmOdrECo1WgbMpZ51C ozDxaZxX1xmVOCOpOHfVqZX1OF/F2aXKqFHj/NwUq1HKagFA6Sa7QSkvx9kPZ7o+J0uC8wIAyHTV O1z6DhuUDQbTpSTVuka9WlVuwNzlHpgoNFSMJSnrq5QGgzBDJq+U6RWYpFqjk2kbAZi/85w4ptpi eJGDRaHBwUJ/H9E7hfqvm79Qpt7O05PMuZ5B/AtvbT/nVz0KgHgWr836t7bSLQCMrwTA8uZbm8v7 ADDxvh2++M59+KZ5KTcYdGG+vvX19T5qpdzHVNA3+p8Ov0DvvM/HdNyb8mBxyjKZscqAmeomr66q NuqxWp1MrsSEPx3iXx3483l4ZynLlHqlFo/Iw6dMrVXh7dYq1AZ1tRZTa/9TE39l2E80P9e4uGOv Aa/YB7Au8gDytwsA5dIAUrQN34He9C2Vkgcy8DXf4d783M8J+vdT4T7To1atmouTZOVgcqO+bn7P 9FkCAqACJuABK2APnIE7EAJ/EALCQTSIB8kgHeSAArAUyEE50AA9qActoB10gR6wHmwCw2A7GAO7 wX5wEIyDj8EJ8EdwHnwJroFbYBJMg4dgBjwFryAIIkEMiAtZQQ6QK+QF+UNiKBKKh1KhLKgAKoFU kBYyQi3QCqgH6oeGoR3Qbuj30FHoBHQOugR9BU1BD6DvoJcwAtNhHmwHu8G+sBiOgVPgHHgJrIJr 4Ca4E14HD8Gj8D74MHwCPg9fgyfhh/AsAhAawkccESEiRiRIOlKIlCF6pBXpRgaRUWQ/cgw5i1xB JpFHyAuUiHJRDBWi4WgSmovK0Rq0Fe1Fh9Fd6GH0NHoFnUJn0NcEBsGW4EUII0gJiwgqQj2hizBI 2En4iHCGcI0wTXhKJBL5RAExhJhELCBWEJuJvcStxAPE48RLxLvEWRKJZEXyIkWQ0kkykoHURdpC 2kf6jHSZNE16TqaRHcj+5ARyIVlL7iAPkveQPyVfJt8jv6KwKK6UMEo6RUFppPRRxijHKBcp05RX VDZVQI2g5lArqO3UIep+6hnqbeoTGo3mRAulZdLUtOW0IdrvaJ/Tpmgv6By6J11CL6Ib6evoH9KP 07+iP2EwGG6MaEYhw8BYx9jNOMX4mvHcjGvmYyY1U5i1mY2YHTa7bPaYSWG6MmOYS5lNzEHmIeZF 5iMWheXGkrBkrFbWCOso6wZrls1li9jpbA27l72HfY59n0PiuHHiOQpOJ+cDzinOXS7CdeZKuHLu Cu4Y9wx3mkfkCXhSXgWvh/db3gRvxpxjHmieZ95gPmL+ifkkH+G78aX8Kn4f/yD/Ov+lhZ1FjIXS Yo3FfovLFs8sbSyjLZWW3ZYHLK9ZvrTCrOKtKq02WI1b3bFGrT2tM63rrbdZn7F+ZMOzCbeR23Tb HLS5aQvbetpm2TbbfmB7wXbWzt4u0U5nt8XulN0je759tH2F/YD9p/YPHLgOkQ5qhwGHzxz+iplj MVgVNoSdxmYcbR2THI2OOxwnHF85CZxynTqcDjjdcaY6i53LnAecTzrPuDi4pLm0uOx1uelKcRW7 lrtudj3r+sxN4Jbvtspt3O2+wFIgFTQJ9gpuuzPco9xr3Efdr3oQPcQelR5bPb70hD2DPMs9Rzwv esFewV5qr61el7wJ3qHeWu9R7xtCujBGWCfcK5zy4fuk+nT4jPs89nXxLfTd4HvW97VfkF+V35jf LRFHlCzqEB0Tfefv6S/3H/G/GsAISAhoCzgS8G2gV6AycFvgn4O4QWlBq4JOBv0jOCRYH7w/+EGI S0hJyHshN8Q8cYa4V/x5KCE0NrQt9OPQF2HBYYawg2F/DxeGV4bvCb+/QLBAuWBswd0IpwhZxI6I yUgssiTy/cjJKMcoWdRo1DfRztGK6J3R92I8Yipi9sU8jvWL1cd+FPtMEiZZJjkeh8QlxnXHTcRz 4nPjh+O/TnBKUCXsTZhJDEpsTjyeREhKSdqQdENqJ5VLd0tnkkOSlyWfTqGnZKcMp3yT6pmqTz2W Bqclp21Mu73QdaF24Xg6SJemb0y/kyHIqMn4QyYxMyNzJPMvWaKslqyz2dzs4uw92U9zYnP6cm7l uucac0/mMfOK8nbnPcuPy+/Pn1zku2jZovMF1gXqgiOFpMK8wp2Fs4vjF29aPF0UVNRVdH2JYEnD knNLrZdWLf2kmFksKz5UQijJL9lT8oMsXTYqmy2Vlr5XOiOXyDfLHyqiFQOKB8oIZb/yXllEWX/Z fVWEaqPqQXlU+WD5I7VEPaz+tiKpYnvFs8r0yg8rf6zKrzqgIWtKNEe1HG2l9nS1fXVD9SWdl65L N1kTVrOpZkafot9ZC9UuqT1i4OE/UxeM7saVxqm6yLqRuuf1efWHGtgN2oYLjZ6NaxrvNSU0/aYZ bZY3n2xxbGlvmVoWs2xHK9Ra2nqyzbmts216eeLyXe3U9sr2P3X4dfR3fL8if8WxTrvO5Z13Vyau 3Ntl1qXvurEqfNX21ehq9eqJNQFrtqx53a3o/qLHr2ew54deee8Xa0Vrh9b+uK5s3URfcN+29cT1 2vXXN0Rt2NXP7m/qv7sxbePhAWyge+D7TcWbzg0GDm7fTN1s3Dw5lPpPAKQBW/6YuJkkmZCZ/Jpo mtWbQpuvnByciZz3nWSd0p5Anq6fHZ+Ln/qgaaDYoUehtqImopajBqN2o+akVqTHpTilqaYapoum /adup+CoUqjEqTepqaocqo+rAqt1q+msXKzQrUStuK4trqGvFq+LsACwdbDqsWCx1rJLssKzOLOu tCW0nLUTtYq2AbZ5tvC3aLfguFm40blKucK6O7q1uy67p7whvJu9Fb2Pvgq+hL7/v3q/9cBwwOzB Z8Hjwl/C28NYw9TEUcTOxUvFyMZGxsPHQce/yD3IvMk6ybnKOMq3yzbLtsw1zLXNNc21zjbOts83 z7jQOdC60TzRvtI/0sHTRNPG1EnUy9VO1dHWVdbY11zX4Nhk2OjZbNnx2nba+9uA3AXcit0Q3Zbe HN6i3ynfr+A24L3hROHM4lPi2+Nj4+vkc+T85YTmDeaW5x/nqegy6LzpRunQ6lvq5etw6/vshu0R 7ZzuKO6070DvzPBY8OXxcvH/8ozzGfOn9DT0wvVQ9d72bfb794r4Gfio+Tj5x/pX+uf7d/wH/Jj9 Kf26/kv+3P9t//8CDAD3hPP7Cg0KZW5kc3RyZWFtDWVuZG9iag0xNDYgMCBvYmo8PC9MZW5ndGgg Njk5MC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoMSAxMTA0MD4+c3RyZWFtDQpIidxXCVRTZxZ+ WYFEtiao41D9gaICSXgBg4bFGkLA50CCSYho1TEJDxLNRt4DpKiQqAhaLVXElYraiorUpbhMz9TB o+NCheJW0XEbGadal2rdBXT+B1XQ1plz5pyZM2feO/95797/u/f//v/em/uC0BAE6YeUIAxkTJIG S7lY2DwRao4jCJ+v0kRGzbt/3Qnfr0CdzphPgvBDHfMRJGAUgrCY2Y4c60P0UC6CDIqHsm+OpTB7 6/z6AwgSSuF3mXB91p/rJ+MIEn4dyjEmqPAVMlwIMiQVyu+ZrOTMgnRsNJQdCELvtNiN+oHxA6Gv oZUIQnNb9TMddAarFtofhXhg01txzoEpUgQZPhDiv3A4cccc3wPQf7AFQRiQB0LrvqknwuuCTz7S ffEeom7ePbZXeOnY0sfeNA96jZt3Faou0Wk0sQ/aj+3ZM0NnsRB0GpsTwaYxae6RdBqzRo2mo4I+ msANg0sCkfjuW4UYEAKxIxYER0g4RlM3Cl73x/RbWrfgWjOnc1n8uZS65/GyQzVu3/dRN70RjjA6 n1fecGLh9dpDX0uOrFlc1jSkSaP7BPV+xZXGhJRcn4qHoO+yGRlMDq+/DneaNeYcG9A68wgSKHGy wO6cIR6ABlAALs/nJUAAMJtRJBag4T0TIb2WZisONKTe6jDbcoAGd+abjThQ2+2keAQa1YOOUKpA KiZLxFIx7UQgk8sV6VpFkgAMN4ZJR4LX10AHD/CWjkQl4ih0JAqvSVCUiqOixT+L//sbcK3re+Y0 FsJwLYbnXk53uZBTInDXNEsgFLkCd7J31XL3+ntPOK9py2s/Fh2+6/Qjrw9G3L9R8dyrX+tffjvp D83fPyrbWd24IPTm7Ew/YvrMb3IDug5nPgqry5xaxewSGvwzXYFNuZVngjMjzxzns+bFfFW5tSFt 3I07ccH1ulVzgtZaShvHpayY3rAp5kynl/BUg3QNnQGT+o2UYEBesf5r57NGn7xR0lF0ZsuDbYWd rM7lCbkhWyKGX/6Ih5c/FyygfTxptaHJv7bkwd79/L0ndKtmeBoUhzd8fl5SzAq+5BQyS1m1s7z6 L+PL7z7un/adx5I1fpbM5xzJiqbydZeZjrXhs/VLDlzn5q7efCTbkJiwvDI4amVw+cJnWZ7vPTz5 DOZvMxwx9ADka//V5+W3gzqSM+eVNyWXVYTe4U/7/0vibeJhaGiP48H/nMbLnXLfutN/i+LL8+H8 4nz8UV9qwoPnidlI3GnDSdRV/YuUXgSjsIBK6Tr97Yb6xRUpFRca/KeaL3CKDRVscXPLi7JPks9i sZU3TrPfr67fMHPSraedRoVqH9eG/rghpk7odfmefVid9/hpLImquEWrat0rSGzjti7eN/XFnpLW 9qqG4mAs0c9yauUOmm7jwW9F62IfFG/O3HQ2GL/2Ud3MtX88l5Jo+kA4u2s3ncb4lYS2TutY9fvP zF+eKnJEGEIGJ4Hx20MCjpD0p9hPwwZN3laaK/GMePTxpSu7q64vqv1dO3F0rFf1jvOLzgcsbWJc 8wrVsb9Xfpby+YkJyadH6R4GNR8cGicMjWpZc/VPY1J+aLOm5F9rRDf6lrQUt8XNqXm6PFwcEfDs KP/2xR03MmSOZKFgDur22gSHbw2DTqPT/Qqzq2xzd7Tuob1jq25swHP7MqbDhNb/yqm/PULRqLgn 4OGvMkJut1pxp9GstwCNPZss0DtxkJ5nsJgJE+4kgFzWnZKj0BHiGBR9lZKUGBUtkUqkk1A3bcp/ nIQ4GU3qMUooKCgQ5UNDAhqKjHZrJOzAdsJM2p2FkfJ0DbWG3ekQAUMhUOPZIgGV16JUbRKVyzHi 0Wh8jx9JkjnHTMIFsSQgt+gJAkQDIUgzG512AlLo5aHTW8xZetJst4H8KDEX9aLs2Tx6hkbMQ/0p wZPHmaAnTLD0SLtN7If69ByFhxrPstptWeLBaCClYfADet3LIUe7s9vty3nuW+bhAYM3q8hN80ag 3pPuptGQhoqTQzdn/f1mwMEX1iKZivPUHp7bIhqo2RQVc+W06a+SLuydtqpO/FsNH+xnHvvw4TGH tfLW8S+3h6OrozJn7dkyIzRnVePVgh9Y135sr3pcz/3Npi/i5zmuPrFPVs22+6oVCwPO4hfiAKs9 Yb1lRawPN5R3O+gbsET6oWEu61jIoE519bbq1Kqz8crMBHfRHS+JbrepMVGxIU68saNteUfGEcHm jQfDVC0Plt1lDCm6FxC75cnW9Lksq+HuIl7ZqHPtgT7EAfaYr4YfvNm8NPfI/uxd67XB33FzZj1Z UFi+LZuzdfyzLmdQZ+mUww/G+dzK1Iekte6MzbrC+3Tq0fnW1P7bEzxgIW90sy6ibta57ui8y2PS UQTlUq++TCaDzqpBXWWURGO6StA5JX5FVX87Ie8yrbw/6rgt7ieue73xv1BIbha9AX4VokEUEyaN 9oI5AOWj1Jdf75ddfwbdowSB0YYQDpONQvLsMaibGdMHw6FM3cwQqB5SE1YyzESSDiI2MvJfFMZ6 N2Ofy81o0JrMBDDiTtKcbTbqSRyYuwuGSjacoKrGiWfjTtxmxAVAb8sCZpIAeQSEEYAgnWYjaSnk EHmG6biRBKRdAEgTDnoP4ZVfql7SnXojSTVE2JpI3IrbSDAcMgnjQJoEBRCLULhIvt5s0RssFJPX vfVuAOjJWM7bNhpHsVYIrdANxAG4gtCJ5+bhBEmMeR1nd3Ig9CXw9ZgKQJREGg3DqIcdUpaPQ0Wa Pc9G6iErnRkvEMAQAukIdEQ0J0MjgzhHodOcYyKpJimWSmPecAeAzGIBagpBwB8iAvZkPEsE5Aq1 VoYpORNkarVMqcUUGpCEaeSpMixNkQRkyqQ+fTgVS8NgGxZxKLQSU6bEAu1YBcjQKIAqGb5imm53 WDIml2kVAIoarRqTa1MnAk1G4jiFXAu0KsqEo1OoMfjHStkHj6mUIF0tk2sxuQLaQQdpCqUW0qaW wDSaDLjeP5iv8rAojiz+qqp7BgcVBfEAo62IgBp28MADJXIMh5wygiLqMpyiwChXQMCMI7qAyuGZ IIp4LsEoJEHRRBGyoq64umJcQ9REVHBZ9SOJt2E6b1DAZXe/b//ab/tNz0xV16t6v987qlpwCpzn 4ReAtsi6jFR2IRA8ffy9Pd/arFjgH6BQKoUeVEiCr4t3oKt+lp5eGdrtowhw8cBmF0q/AMHNc56v Xt0N/zsJ/k5oo0ugt1OA4B8Y4O+nVEzoXGS+p7e34Os3T+as6CTJW9Gp4OLnq1TMDUTjPZ28J6CK r+c8z6C3Ol3G+iGqAMHVycfJXaG0FZQKhUyPU79f6OdwVeAobyUy7aLG3I9Hl6mjesdidEwiloXI CCFeHa8Pq6iYyAjlm0RwSsLMCEvGBJJFpqJ+Z3CnqGKTI4XEpSqMg3h1khAWKYSr8VFE5ySqREEV Hp6c8CYDo9QJcZ05I0t5s93gCIxUvQWeTrayffaayf9Nmnf1x6qj1bbRMVHyNUf1lUTg1hySa+Qa iWHoeg+y/oWCSAnBDmuJAVYVnscKOnj4f5wfSZKHdY+k8iC56eBe9VCOhxViNqur0yqxk9mYnp24 u6YIsTGqMFshNglz4Z9Pl9B5yQe/U+nMOQO5BKsdfnqde/QntW3ee9MCm5IWbbCsOyi0x1Z/ke6W vrtk1cmVEg9T48iGxTYv5jrkrKx8MmhaalP+EUONfcFijx1nYZpMWTN7qphrYhUH7pOfe3jbJvxc 37i6w1U9Ov+vm0vubn3UKsKFuscJw78rZvHHasPTJ6a6Ouxel/s6a/1Ua9vWg9OmOp789RethZ2W G401eARClyf/D/aPf3MY7CsxeEMK5XnYs+awfFg3S32Y3bsbC4dnjJ6WoV2vbUc+skeRszPmBvB/ SJzY4FNRfbHt2eH4c/2Oyf3fGd7Xzlk+e89QzWBQQhrEQRioIRYEiMLfeEgqHaMZrY+mt8EU13Wo 6YympITkyKS0FZG/63Wk4bQEFp4zObesdVeO6seTIx4VVMiqis0dH5Y6DXGLiqzPO7/2uHaxc37u w4JLs36cs+7zVcOO/lR8mL0KPl0cdzfpSnOTy08R1jWpL/2WbRly3KffpXu5YZuWfzZg1+il0h8G DUvLGRP8yCorzGJYajLlppV4zTar+ZsiyNHad6j0vXCr+IXjtv190av0XV8mjMgsO/RMOXDn05aN 2sacktpRq4ya227HLAidVORFT3t8+vH+7PUPHG7r/HZebW061xw77tqp0K/ql14rslJZn89sVN0r DLpsGmvsGXqPxHkmmnyyK9TkzgGLxlX16UK1yaqDQ0VIyWloKbxzMTivWTvzQv6hbN3Fk+n3J90Y b12qJVfwVNfQ4wuJnZacwq4T+iBbU/1///5KTeHUwKIml0ejXrstyMr5s1t2geXjQaG9AjVYPvTd ODXsbkgJhmn3E97OSP/qYSfHdw253ZRJkxf+S5i2FRb0u7ZXVrl6i/jcZJuRV++gWqNRpK+OC4mb 4pye8t39Gytemg70Kgy+3pBZK0b7OSY+zbgZNUW6PFIxqL85fCS+OlVUZlOc0lKVJh6Zmfn9om1P HmsSSwaW9THL3HBhVNbENYNqL98XspraJmaHpN25IZqXbS101OaGWG6+te+p3Ni5dPVov6w+Hr+e tN/p8PWnjb4tG8sT9UWNcJdIAfAAfBE/CZuWb37ZHoiixn0ZzxNKpBLKS6HX5aOOV8PsdqFd5Dfq 3MgkA0NSp+l+yi8GO94bRuI9nG0FcwDxztv7ni5YfMQvBwvdMvGmlREO/vLt/eZSgSUsARuYA3XQ DqfJOPCHM+IVCIcF9EN4H/vz4TicgdvgChFAwYxkgCAWw0YYC2thD0znzMQq8IYHBkYwGMbADKIG CZhCNOwmN8ETvHAOB3CHHEjA77nY/5xMwycEZLAYV98KO+E0/AV+gGE4oy1cR9c/F78CF6wo4ZAO J+A278xvABMohENQBrVwn9iS/aSNPRarxAbxH6hlA3ZgDyFYfcJgM5TiuENwkVqwfaKZmC7+UTwP w9H6ckRdC2dxrWdEIEEknB5kabpXYrxYjjz0RZvRehQnROMLSXAAR16H16QPipYK9AMarhsoDgEp jMQKNx7tC8SKtxqyYROiKIISOAoPyAdkKblEHtN+VENreH+pr9S3T03Ht6K7+AzX6Auj0Nr5sBxS UXMzbIHtqFmKa/0JpR06iD1xII7EkwSQfLKeHCAv6Hj6PX3N+jMjNoEFs1CWwZrZSwO+w0+3Q3dF 9BdTkUuCnMvQky6Icx4sghWQCB9CBmjQujyUAmSvHKUC+axB+QZuwV2UFngADzHmeMQoI+NQ5CgO ZDaZQwLJ70k0SSQ7yDFSTU6Ts6SNPKGTqT2dTv1oAI2mK2gSLaAVtJLW0Hv0F7RyBlOwRPYRK2d1 7Dy7ypo44OZwKi6GS+a2chXct1w794TT8cBboNjyKn5Px16dly5EHCs6iGHiJrEA5QFyPALRjAUr xOOPXg3HHSUaUa2AlShpyN06RLQddiN3evaOQTV8jVFah/6thyvQhPhuQTM8h5dIjh6fKRlF3id2 yO8s4o6yEP2UQjKIhuSRIuS5klShnCE3EaUOEQbRYLqEptAMuonuoDvpCXqGXkdPiEyCnhjK3JkX m89C2BKWxLazj9knbDcrYdXsDKvnKDeD8+cSuLVcAbeXO8qd4xq5m7ycd+BzUSr4Kv4U3yIxlphL JkuUkmqpxCDNoNVAB1/AOaiEqt65T7LJAFIJn5FWxjENbaALqCG9TrTcZWKFHphJgM/D3fZntPA9 cpVOJfNZOFmI/GlJFAmBXWw428vmQAMfT5TMn0SAktsBv/LfgIrPpZ8zyueyDvKSlsNSyKPLO8rE YNIflGQ/PYgRkwkzwYYzg+t0OneCWFIbWiM9QqrBUSph09kMAyNs7Wd30UylgRFpAxX7jfxqC27i OsP/2V3truULsjC2bGG0YpEcW5aNzcU31ZYsyRCEHdsyVAuk1cWiNkOxJwE6LiWlZSipCB5lMgOZ XqaZDpMmTqY9MtCRMyn1W/uSJ2bcTukDhEv7UEomQ+g0xaj/WcnGTpm2j53pSt/57+f/91z27H6M ++cW7q1h7m18Jtwjf5RewOoW+V+gz0noJpeelMO7Bo2LkvXcJbJ78fTi7/kf5n5CqrmPARbLF32c H1fcntwMdw0ewMUnfxduwjXuBuzBp0ZC3zmf4t77Bj5p9sJjrhT3UxifI5Penp7uL3m6Ojva27Zt 3dLasrm5yd3oaqh/rs7p2KRutCu2DbXrrTXVlqrKdRVrzeWmNWWlJcXGIlkSDQK+tUJjUO2LKtQZ pYJT3bnTzWQ1horYCkWUKqjqW+1Dlajupqz29KLnwS94evOe3mVPYlI84HE3KkFVoR8FVCVL9g1F kD8fUDWF3tf5fp0XnLpQioLdjhFK0DIWUCiJKkHad3wsFYwGsL9MsdGv+pNGdyNkjMXIFiNHq9TJ DKnqJjrDVQU7MxzIpVgVrVEDQVqtBlgJlHcEY6N0cCgSDFjtds3dSIk/ocYpqL10jUt3Ab+ehop+ KulplHF2O3BOyTTOp17LmiAedZWMqqOxAxHKxzSWo9yFeQO06pt3LE9F7Nzsj5xdabXyqaBlXGFi KnVWoW8NRVZa7azVNOwDYzlHXzTVh6lfw1EMhRXMxp3RIpScwZQKuxN2V/n7S6pBpokeUmiR2quO pQ5FcW5qUhSGp+yzNTXeudxNqAkqqZGIaqc9VlWLBdZnKiA1PHW52qtUr7a4GzOm8vzAZsrWFJiS 0pVMctmmc7o740LDyyNLWEXq87giqJJQsJKIivfUzppkO6QS7eiGl0Ywio7ijIzTIn80ZepkehZP DQ6TqqQ+A1wB6v2/rNbEChrRYfoMGMvWyfJaQ/sST10u2tDAlojkxznFGrt1eZu78XiW86mTJgUJ Dh8M4tjGtM5mHH67nU3wuawX4ijQU0ORvKxA3DoL3maXRrkos8wvWdbtYZZTS5bl8KiKK/kKnl8A 66jsXP6vMVWuDY51UlL5b8zJvD0UVkND+yJKMBUtjG1oZJWUt7cv2wocXeuP8FauwHFWXrfiojyw 7MyESAkVHPgX9UU9mpVkXJW6hih91BTdmW81o93+XwZlc5+wKJ08DSuUSTtdq+WuVfKq8kpSPBYs OLnQyL5UyrjSBmzQ5OIn3djuffLe4yb5qD6MK69rwkd4qrLrc8BXO8QM3DFcgZgA4BBGYUicgR1i B+zkT0Mn2kYQbrS9jjYH+h8p0Ne5jlwO9bsQnyAaEWGEgogjNMRuxLcQQ1wHvI84h7EeFs8ofx4i jDf8BioMe2EjUrNwF2qE21AnWmGncB1U1Dkx/xZDCQwg7zCchAqplsXk/ozybtGBPn/FGl4Gp/Ah tGNsl+EMVGLtO9DWbqiHXvEA5rsNldjPz8Q/kUNIdxkCqIPcAwH4P2DfI1jHFKKPfwhBjH1ecMEO fhfe33Vwcz8FP9Ig2tchWoQf4T254DnkWf1tyGtIx9FnAGNdaN+B4+nDWgf5T2E/0mbsdz//O7hO fgCXkC6g/1bhEawln+t5PQRnC2O241iBKMKcKJLNSP+GeCTvhXrpLoSw/xeXKL8FDrKxwxN+vDCm Uxh/EPP4+J/DocIYM2xiuWSAe8J1rkOG3Hm8d0W8gHN+Etw4Nl+R7pLv4lgN6LgAMaT9DNhfO6IN 0VVAp+EKMSKK0R5GeZc4DAkGyQatGNuEuUbY2kDbZqxTR6H+3YX6dYp1NuO4+pbixV3QgDEu3gzh FYBlPMT3jYf4naNTcgljjmF8N9eC30EnubfzAD9vzr3Bm7kX8xRU5L+jU4wll2C9bx2YuTr8OTkn TJBK3B1f1dsX9LZHb5tZyzXPNttsWa5p9i1GGmdr65Fs8hbfqrG11JltnjomV3m7Dtfbbs5U224h 3qtrtb3qabWdRjQjjqPM/Opm6m0TdRNfn/jexFmhDSorcZbN5bI3S27/ck9FUUVRWzpLfu3tkNK/ ktKXpfTXpPSolP6ylO6T0tuldJOUdklph5TeJFXIZtkkl8klslGWZVEWZE4GuSKbu+l1sc1fIZoY EQXWCjpv4ljLNjo+CTgic/h1R9fyIS4U7qXtrlBWyg3TNleISoP7IxlCpjXUUu7VLIGRSJbkmOqM lZ3ac0BI7sx5a4FqGgnR+QSE4gp9FFazxIgPKoPaS6g5BKGRXgtUHu+x9Ji7yzv6As9oooXW9fSy uFZeocGpD8FGjrGPL3L0smR7Q2LaMGrTujbNtGlda6mlF0LhCJ2p1WgrY3K1Grnsu+o9wd4Domow iYjSc8fHLPRUXFEy3quFFwRnNJ4YYzSWpFfVZIB61YCS8Z14hvkEM/vUQAZOBEcimRPeZGDW5/UF 1VhAm4MBEs80TK9K9/2ldHPQQOL/2mOWxFmXDSzjwPQzMk4z8wDLOM0yTrOMA94BPWNwPNxLQoOR jAy9Gh4+Or3MFRtxqqJWu9ZbaZrs1uety255xfqBAOQdKMazuATf60oRzOT2uX3MhAuGmcrYK1/B ZHmly279gLxTMJlQXa72guuY6wvXy+wCS3A8wICVzOXmuVOzZlurS2PnDMeOIPz6w22Mk9bl3SBK CdQZhAQPRtGQ4HmupkgSEgSq5fp2i2vA9NDTv+gZMD3y9JsWPdDjWfQwtGy2l9vLHdjg2obHCj// 2GuAf+CJM6+fcte5G/jsKwb7HPDkiresSIKaUrG6pPSBnXXrGrhjugc9/fdbNpMKUd3o3LZ1+5bW Su7GwsU3FxbevLjA+fJ0QT8dW//Pftr/2I9dRnhl+f3l2/knGLBVtAalPC8gP13gReR/jFYQilB6 Au8XeAIbyEyB56CM/LbA86hfKPAC8g8LvAgbOPPI1GTyYCyRVN5VRsaSSv/EkYmjqFL8Ey9NTrwU Ozo+cUSZPJxoUgKxo7H/4NTMOlPCE4ePMc0/S6V6noShKHpCQtKEAf+AydsJn1ujMQIOEi2Q0t0U qYXkAaavkDRxcPZvOLk6M7Cz+gecnBxdgdMLMupAmvt17rnv3CbXqNaEc1XbrhTpaiVV11q5o3AY G+UGJojmwcBpdJrddqGXjPtT7Xh/l/CQ4BEBHuDjnlHhjeZhKLmDKSa0eM9SaLKKmKfeJz4ShiKi OV9idiW4f+RL5cNmCj12NGYHjiHWYtzpVWHzq6C4z2qC1jmhGV3OhNwhlimX7xlahDn9gFs10OEm XbRRoE6CMfqi5lA/ZYfU1dwv+od7THd3nUtqZeUaMzjh/18y+87mBUn7mWesnm5e7vLnP9apJfDr 9eIsje+3H5+bzfrC+rJyLHO/l78F0nkyzAoNCmVuZHN0cmVhbQ1lbmRvYmoNMTQ3IDAgb2JqPDwv VHlwZS9Gb250RGVzY3JpcHRvci9Gb250RmlsZTIgMTQ2IDAgUi9Gb250QkJveFswIC0yMjAgMTEx MyAxMDA1XS9Gb250TmFtZS9NQk9DUE4rU3ltYm9sTVQvRmxhZ3MgNC9TdGVtViAwL0NhcEhlaWdo dCAwL0FzY2VudCAxMDA1L0Rlc2NlbnQgLTIxOS9JdGFsaWNBbmdsZSAwL0ZvbnRGYW1pbHkoU3lt Ym9sKS9Gb250U3RyZXRjaC9Ob3JtYWwvRm9udFdlaWdodCA0MDA+Pg1lbmRvYmoNMTQ4IDAgb2Jq PDwvV1szWzI1MF0xMjBbNDU5XV0vVHlwZS9Gb250L0Jhc2VGb250L01CT0NQTitTeW1ib2xNVC9T dWJ0eXBlL0NJREZvbnRUeXBlMi9DSURTeXN0ZW1JbmZvPDwvT3JkZXJpbmcoSWRlbnRpdHkpL1Jl Z2lzdHJ5KEFkb2JlKS9TdXBwbGVtZW50IDA+Pi9Gb250RGVzY3JpcHRvciAxNDcgMCBSL0RXIDEw MDA+Pg1lbmRvYmoNMTQ5IDAgb2JqPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250QkJveFstMjEg LTY4MCA2MzggMTAyMV0vRm9udE5hbWUvQ291cmllck5ld1BTTVQvRmxhZ3MgMzQvU3RlbVYgNDIv Q2FwSGVpZ2h0IDU3OC9YSGVpZ2h0IDQyMS9Bc2NlbnQgODMyL0Rlc2NlbnQgLTMwMC9JdGFsaWNB bmdsZSAwL0ZvbnRGYW1pbHkoQ291cmllciBOZXcpL0ZvbnRTdHJldGNoL05vcm1hbC9Gb250V2Vp Z2h0IDQwMD4+DWVuZG9iag0xIDAgb2JqPDwvQW5ub3RzIDIgMCBSL0NvbnRlbnRzIDMgMCBSL1R5 cGUvUGFnZS9QYXJlbnQgMTAgMCBSL1JvdGF0ZSAwL01lZGlhQm94WzAgMCA2MTIgNzkyXS9Dcm9w Qm94WzAgMCA2MTIgNzkyXS9SZXNvdXJjZXM8PC9Db2xvclNwYWNlPDwvQ1MwIDEzMCAwIFI+Pi9G b250PDwvVFQwIDEyOCAwIFIvVFQxIDEyOSAwIFIvQzJfMCAxMzYgMCBSPj4vUHJvY1NldFsvUERG L1RleHRdL0V4dEdTdGF0ZTw8L0dTMCAxMzMgMCBSPj4+Pi9TdHJ1Y3RQYXJlbnRzIDE+Pg1lbmRv YmoNMiAwIG9ials1IDAgUl0NZW5kb2JqDTMgMCBvYmo8PC9MZW5ndGggMTQxNS9GaWx0ZXIvRmxh dGVEZWNvZGU+PnN0cmVhbQ0KSImsV9tu20YQfddXDPpEAtKKu7y7QdDETtoGSGDAavvQFMWKXIls KFLgrqw4X9+ZJXVLRAmpCz9YpMiZOWfOnFlN7+HFi+n721/vwIOXL1/f3cJoevvgQabxBv2BzuoR hxLv/4z3l3r0ejaazmYecJgtRh7MMnxqtqVHZxq4R/+/0K0WL1gappzbQHSRQOpB7HMWhGkawWw1 csCd/TN6Mxu9eU+pD+XwXTkn6QYi8oQlnuf5FyOK04i8B8A8D+MhioHYXsS8OI1jG/tOybwqa6Vv hrL4x1luxd994RPKM5yIewl974cQpYJFaRomlO+F58UW2EtMdlqzoEhdVEH0cxYFIiTe89GfzsNm viq1Lpsa3Em4L/sG3ssn4GIMwvMicP+avTuHIbiOwbb8MpA4ZSLyvPQakC5gF9zn32J5tTFF02r4 0JhyUar8Bt5tagXCJxRu4FwAEv4vQKKQJcIL4ytAeGTjDXTkj6b9pItmDb+4E9+R7kQ4dd5sDPyu WtunQ4/ebaonEPxKk6KzA+JdwpR2Yo8hCn0mhHdlBOPzGc6J71KuwGNhxOnBVa9MN3E6cWpASjZV Dm7ozBWs2wb7+UjclLnKQVUqM21Tl5msqid3EjtjerKsO1LOkS48JmJ/z/r9nRs7b8ewaFrQRta5 bHP47QEqZYxqJ7r8glnlWrXw0UlYCJ8PkXstTnYRJ5zx0O/CItKyzgqlP7oM7u37ejN3J4mzwnyE jaaO8NH1hgBpA3VjQH3OFCLj4RGEgCBgGj+O94Wv5VJpLEqX9bJSoNcyU2Mw2wayptpQ1JqiEjBK tZIGtjapKQ6Rz4zWZJfnBM4PQD2Rru+0yxKr3lBakNhK7AesDWCW2CHuK9kuEe2iqc1HF5BQKOSj ghqfaw6I0qO8nPd9iZNE8B0+KBRlzDFWQ+EabAcY9dkgZsWWbNyHJIyYluiAekNVznFeiPYjAsO9 Bg4gu2zHKO/bZt1oWWmrBgraKq1qI41VIt5by1pVe02iIOvmTJsCL0j3OKqmJj5MIWtYlMhEX6z+ sYtGmu6z7qR+kG66r5vv6+6iU91BHPIuCWqt2uSo1IaUFTnzSnXRS220bQJmL+sc5wQJIjjQLGBb lJnLnYJaaKvavWA7ljX1omyJUNVVRAX4NLoi6NE5OeJSJfHSmjIr15YpNmQXybAhXfKHMI6ZL3gU X/SidNCLvrHdS7migEURj4POi+4rJbWyG1L3tmTogmCjSKqq2dIclDUKxg6Ipdb0ovjK/ZOD88Z4 vvHTtGexkLqYLDZ1Rm//VGML2LJ5dLv98RVLPML93783eDLynnHEoGkIQ47uL4R/bqEdMxvsmQ2+ XWgf5AodSS4WZVVKSxvCG4Mib5JlNYZ10dT4BIrWyApknuO4dbNH9K7bciXbJ/JM0qKR+FrmCseA tPt+cO9x/tylbjnwY7QINPZrHNi2niJ/W7bk5rIbHoFLqZJf3bAz2VPTjyOOoJJZgWAn1xCK5zZY BMwP/Gc2eEZDUKJeC5V3BoJ7Dvt55Jpj6J30xOpwYOD+7i21mvaSJIsCaQyitysS397Z9zn0/n88 2AgfkXPEkPgivfzbIni2m1CyIE0ZfYg6N3lVVaCPTjeE1S5pjasZv8N9IrNPdbOtVL5UORtmIHwG A0ESsUD4ncUNMzBwevxeBmKfxZGf8I6Bn1WtWtv/rvWkfDmnQ65LBxMF290huLTE0FYjgzX2MACt WqI5tv17NEFZZllcEaf2U06vdQ9c2KPefu/f2e15Yt/7XjyiS0lapajRk+K2aq5xEUQOnsVPe/SA Qj9wGA//oEwu9cr3BQt5igsiiLBOKrvjrzBmfTOdbrdbtlsT0wKps78WjpbIoHC+dwVDECQsOCOV fwUYAKfX/FcNCmVuZHN0cmVhbQ1lbmRvYmoNNCAwIG9iajw8L1VSSShodHRwOi8vd3d3Lm5pc3Qu Z292L2hhc2hfZnVuY3Rpb24pL1MvVVJJPj4NZW5kb2JqDTUgMCBvYmo8PC9IL0kvVHlwZS9Bbm5v dC9SZWN0WzMzMi41MTk5ODkgNDU3LjcyOTA2NSA0OTIuNjY4ODg0IDQ3Mi4zNjU0NzldL0JvcmRl clswIDAgMF0vQlM8PC9XIDAvVHlwZS9Cb3JkZXIvUy9TPj4vU3VidHlwZS9MaW5rL0EgNCAwIFIv U3RydWN0UGFyZW50IDI+Pg1lbmRvYmoNNiAwIG9iajw8L0xlbmd0aCAxNTI2L0ZpbHRlci9GbGF0 ZURlY29kZS9UeXBlL09ialN0bS9GaXJzdCA4MDQvTiAxMDA+PnN0cmVhbQ0KeNrMWNtu20YQ/ZUF +pxw7xcgMJA4Neo6jQXLfTL8oNhs6saWBJlq4359z+wsHSkkRRBNizzYq92dOTtz5rIklRFSKCuU 1EI5YbQRygtjMQvChCRUFD5iP4mEDQ1h6aTQSiiljNCQUx7rUNPQ0JDUXgnthDLSCe0x2iR0wCE4 QkeMDusAdnQQ8JyXwgDPS4vzMdooDJmRNAyBHRZywIsScsCLHuvASxIWAi85zIGXUhAWpkkYb2GC 9Engp1ZKCgtTFZSsxeitsDABGwLQWrsoLEwne3G0NjCCTDbBCHLV4lwHPAsncJS2wQoHPAcSHPCc j4Jc8jDCAc+DDwe8AFoBrQOMcUQB5OCqDskJoigC1BMlCevASwCDaUZKrCMUEiCAMgq8eLiqSB7U KPgJ14yGUwGUAEAEBcpAUgAVJioB0w3ZC1ONxSQAzyGGgagEeACeR/AC8HyUAoE2xDN+IuhGAMJE kBmBF2MQEXgJwUAmmIS4RFBFeRA9qJZRQMQiUCKCShArIlEPYxNRj2RIoNoADKrWAhdHWAu/E4UC zoMS6xGnBDwPvymUlHaJQgP+EvCIP4VYWCJQgSQbKf2QVTYiXkoCMwKA+LIJ5CgKaEqUsoiIpJxB yjhJ6QybnVKkjqBRRlCWgCHKZ4RLU6Jj22lkxKtX1eXTuq7mzWZ701xu6vpitWqqM6obKS6q4/vF 4+MvizUVEM1ni029zHJUS/sr7+vPzVn9JEx1sbqvs1IgkaMjnHJ25fOEwpyHlAcEOQ+KB82D4cHy kE+GyawfWSOyRmQN8jlPeUgsmljTZUOpbmmwLGIYxjCMYRhbZqxuWFKXxWzwdTVD1WfH59W8vmmy c+9Xm4fFPdqDefb3/fbh8UpSi8n2UZPJYNRmCCcLnW+b+7sl2F8vltWvy9t682XKmNWsugStb1af q7d3f1Ynm8VDzb8QpuWqqSGHfz8ub79M5r8vENGTu4/bTV2dLglyb+ny/DX+jmk8pR/076SsnJSV +XZdbx5vNnfrhs2Zbz/sTZvN3ad6tS3Tt5vV+nixbk84Xj08ICl+0PKi/q1GftwUp05W9/erv+rb n5Bz5OsnXv5q+rD6+0XzuXlxc9fUzeLjY149Ovq3GRQ4DwKjBEYJaTirIqNERomMEhklht2Ei4yS GCUxSmKUxCjJ7uak55lnEc96Li9eX3Ea0YWzk7e6ZDGfq0tupuFkNoxiGMUwivHDGa71bqLnmuWl tkmcv/n5ojr/8IcoveCjUJzvVBUMgqp4hziWkudbNZfN8XNCt61l/rzyjENKaBoQ/pIRswIB+Z3F fRW5C+9G4CfI6glmm+r1lTMdZ21qaXmzun36WsmSku4oOXlA6cqVsF+TsuqeGA6d6HdFOYsGXQoT 3I8TZNOUbJDw0vqul/qQl0qRlutqmUPE4lI0vmXW2q62PHim2ZXleht2y07hwE0RnhKJYuWs3Hzk 2mkhw5YrkbuIlc+3X4v4rsUwQxil9/RsnVfvFk/59mgWm+YUN9+yAfcvZb7tyvyFii/l/yB+1tbB rDwc7NHAHZYrstRWLw3aD2GUnt2z9X3RcIWLY+/qoTLw3dJzrlMGeudBr22qs/Lgtcum43vH8b3j CrdukFQ/CFWuzv4tObhlqDH4btN06ZBPvUw6O5xQhrqW794GLn7TY3SiY7ptzoVveMxkq+RYA9rL FjVJWk+SNpOk7SRpN0naT5IOk6TjJGlKGaW7zxxKxcNlnW9ipVWP5sHiwb2qymP2dUboeSJUfuTs vbiHOJZT0wKvpkVeTQu98uS16lYpvZ8f9jpkTdvDlxzRjFnT9GiqkVil8mqTY6V68kSGw2frvfqP fqyiJzYATXbJ7q2URtJXm6zYDUMaiYK2WbEnCnIkCtplzZ4oyJEo4GEiPV/B9BmoY/RIwei9FpLM GKsTe0j7yJfC1zd8Kl9gUvkuI8tYXon94FXPr9B9mOW1un9LDW/pga3/9v77rsTP2vqbtZ/IdmNV GlDbTtrm0JZ4f5jMIF75UDKw54b2prj0jwADANV26gsNCmVuZHN0cmVhbQ1lbmRvYmoNNyAwIG9i ajw8L0xlbmd0aCAyMjgvRmlsdGVyL0ZsYXRlRGVjb2RlL1R5cGUvT2JqU3RtL0ZpcnN0IDg0L04g MTEvRXh0ZW5kcyA2IDAgUj4+c3RyZWFtDQp42rSPQYvCMBCF/8r8AU0mjWkLUnDBg1hRtoIH8VC3 UQqSSsjC7r/fmZauCnoQ9PQy730z5CFGIAFRg45JRpBqEgOokZQsk5ImoIhDTEGxryQo9hVCxKxS EBnKVQQaJYzHYiny8rf5DqIIpQ8zV1kXYKSHUqztTz8PMBnKLHs7Poc4oZKfYtVW4lch8lmXbbkd WW27Tg3rjmndw/0d8/AOxPGj7O53+XdPtHs9vvF1qN1x0VRW5H69v9mXtD511dXExyan+ug6ThTn 8st+2EPjbZu38+QQrP/HL9tZ9ifAAJFPrJYNCmVuZHN0cmVhbQ1lbmRvYmoNOCAwIG9iajw8L051 bXNbMCA5IDAgUl0+Pg1lbmRvYmoNOSAwIG9iajw8L1MvRD4+DWVuZG9iag0xMCAwIG9iajw8L0Nv dW50IDIvS2lkc1sxMjcgMCBSIDEgMCBSXS9UeXBlL1BhZ2VzPj4NZW5kb2JqDTExIDAgb2JqPDwv TGVuZ3RoIDM5ODkvVHlwZS9NZXRhZGF0YS9TdWJ0eXBlL1hNTD4+c3RyZWFtDQo8P3hwYWNrZXQg YmVnaW49J++7vycgaWQ9J1c1TTBNcENlaGlIenJlU3pOVGN6a2M5ZCc/Pgo8P2Fkb2JlLXhhcC1m aWx0ZXJzIGVzYz0iQ1JMRiI/Pg0KPHg6eG1wbWV0YSB4bWxuczp4PSdhZG9iZTpuczptZXRhLycg eDp4bXB0az0nWE1QIHRvb2xraXQgMi45LjEtMTMsIGZyYW1ld29yayAxLjYnPg0KPHJkZjpSREYg eG1sbnM6cmRmPSdodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjJyB4 bWxuczppWD0naHR0cDovL25zLmFkb2JlLmNvbS9pWC8xLjAvJz4NCjxyZGY6RGVzY3JpcHRpb24g cmRmOmFib3V0PSd1dWlkOmFkMDAwY2JhLTUyZWItNDQwYi1iMGM4LTU5NDdjYjg2MWM2ZScgeG1s bnM6cGRmPSdodHRwOi8vbnMuYWRvYmUuY29tL3BkZi8xLjMvJyBwZGY6UHJvZHVjZXI9J0Fjcm9i YXQgRGlzdGlsbGVyIDYuMCAoV2luZG93cyknPjwvcmRmOkRlc2NyaXB0aW9uPg0KPHJkZjpEZXNj cmlwdGlvbiByZGY6YWJvdXQ9J3V1aWQ6YWQwMDBjYmEtNTJlYi00NDBiLWIwYzgtNTk0N2NiODYx YzZlJyB4bWxuczpwZGZ4PSdodHRwOi8vbnMuYWRvYmUuY29tL3BkZngvMS4zLycgcGRmeDpDb21w YW55PSdOSVNUJyBwZGZ4OlNvdXJjZU1vZGlmaWVkPSdEOjIwMDYwMTI1MTkwNDM4Jy8+DQo8cmRm OkRlc2NyaXB0aW9uIHJkZjphYm91dD0ndXVpZDphZDAwMGNiYS01MmViLTQ0MGItYjBjOC01OTQ3 Y2I4NjFjNmUnIHhtbG5zOnBob3Rvc2hvcD0naHR0cDovL25zLmFkb2JlLmNvbS9waG90b3Nob3Av MS4wLyc+PHBob3Rvc2hvcDpoZWFkbGluZT48cmRmOlNlcT48cmRmOmxpPjwvcmRmOmxpPjwvcmRm OlNlcT48L3Bob3Rvc2hvcDpoZWFkbGluZT48L3JkZjpEZXNjcmlwdGlvbj4NCjxyZGY6RGVzY3Jp cHRpb24gcmRmOmFib3V0PSd1dWlkOmFkMDAwY2JhLTUyZWItNDQwYi1iMGM4LTU5NDdjYjg2MWM2 ZScgeG1sbnM6eGFwPSdodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvJyB4YXA6Q3JlYXRvclRv b2w9J0Fjcm9iYXQgUERGTWFrZXIgNi4wIGZvciBXb3JkJyB4YXA6TW9kaWZ5RGF0ZT0nMjAwNi0w MS0yNVQxNDowNToxMy0wNTowMCcgeGFwOkNyZWF0ZURhdGU9JzIwMDYtMDEtMjVUMTQ6MDU6MDQt MDU6MDAnIHhhcDpNZXRhZGF0YURhdGU9JzIwMDYtMDEtMjVUMTQ6MDU6MTMtMDU6MDAnPjwvcmRm OkRlc2NyaXB0aW9uPg0KPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9J3V1aWQ6YWQwMDBjYmEt NTJlYi00NDBiLWIwYzgtNTk0N2NiODYxYzZlJyB4bWxuczp4YXBNTT0naHR0cDovL25zLmFkb2Jl LmNvbS94YXAvMS4wL21tLycgeGFwTU06RG9jdW1lbnRJRD0ndXVpZDpjODM3MzAzMC1iM2VhLTQx MzItOWRkZC1mODc1NmNmMDMzZDInPjx4YXBNTTpWZXJzaW9uSUQ+PHJkZjpTZXE+PHJkZjpsaT40 PC9yZGY6bGk+PC9yZGY6U2VxPjwveGFwTU06VmVyc2lvbklEPjwvcmRmOkRlc2NyaXB0aW9uPg0K PHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9J3V1aWQ6YWQwMDBjYmEtNTJlYi00NDBiLWIwYzgt NTk0N2NiODYxYzZlJyB4bWxuczpkYz0naHR0cDovL3B1cmwub3JnL2RjL2VsZW1lbnRzLzEuMS8n IGRjOmZvcm1hdD0nYXBwbGljYXRpb24vcGRmJz48ZGM6dGl0bGU+PHJkZjpBbHQ+PHJkZjpsaSB4 bWw6bGFuZz0neC1kZWZhdWx0Jz5UaGlzIHdvcmtzaG9wIGNvbnNpZGVycyB0aGUgZnVsbCByYW5n ZSBvZiBwdWJsaWMga2V5IHRlY2hub2xvZ3kgdXNlZCBmb3Igc2VjdXJpdHkgZGVjaXNpb25zPC9y ZGY6bGk+PC9yZGY6QWx0PjwvZGM6dGl0bGU+PGRjOmNyZWF0b3I+PHJkZjpTZXE+PHJkZjpsaT5j YXN3ZWxsPC9yZGY6bGk+PC9yZGY6U2VxPjwvZGM6Y3JlYXRvcj48ZGM6c3ViamVjdD48cmRmOlNl cT48cmRmOmxpPjwvcmRmOmxpPjwvcmRmOlNlcT48L2RjOnN1YmplY3Q+PC9yZGY6RGVzY3JpcHRp b24+DQo8L3JkZjpSREY+DQo8L3g6eG1wbWV0YT4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAog ICAgICAgICAgICAgICAgICAgICAgICAgICAKPD94cGFja2V0IGVuZD0ndyc/Pg0KZW5kc3RyZWFt DWVuZG9iag0xMiAwIG9iajw8L01vZERhdGUoRDoyMDA2MDEyNTE0MDUxMy0wNScwMCcpL0NyZWF0 aW9uRGF0ZShEOjIwMDYwMTI1MTQwNTA0LTA1JzAwJykvVGl0bGUoVGhpcyB3b3Jrc2hvcCBjb25z aWRlcnMgdGhlIGZ1bGwgcmFuZ2Ugb2YgcHVibGljIGtleSB0ZWNobm9sb2d5IHVzZWQgZm9yIHNl Y3VyaXR5IGRlY2lzaW9ucykvQ3JlYXRvcihBY3JvYmF0IFBERk1ha2VyIDYuMCBmb3IgV29yZCkv UHJvZHVjZXIoQWNyb2JhdCBEaXN0aWxsZXIgNi4wIFwoV2luZG93c1wpKS9BdXRob3IoY2Fzd2Vs bCkvQ29tcGFueShOSVNUKS9Tb3VyY2VNb2RpZmllZChEOjIwMDYwMTI1MTkwNDM4KT4+DWVuZG9i ag14cmVmDQowIDEyNA0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDE5NjgyIDAwMDAwIG4NCjAw MDAwMTk5NTMgMDAwMDAgbg0KMDAwMDAxOTk3NSAwMDAwMCBuDQowMDAwMDIxNDU5IDAwMDAwIG4N CjAwMDAwMjE1MjMgMDAwMDAgbg0KMDAwMDAyMTY4NCAwMDAwMCBuDQowMDAwMDIzMzA3IDAwMDAw IG4NCjAwMDAwMjM2NDMgMDAwMDAgbg0KMDAwMDAyMzY3NiAwMDAwMCBuDQowMDAwMDIzNjk5IDAw MDAwIG4NCjAwMDAwMjM3NTggMDAwMDAgbg0KMDAwMDAyNzgyNCAwMDAwMCBuDQowMDAwMDAwMDAw IDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAw MDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAw MDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQow MDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBm DQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUz NSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2 NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAw MCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAw MDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAw MDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0K MDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUg Zg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1 MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAg NjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAw MDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAw MDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAw MDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYN CjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1 IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1 NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAw IDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAw MDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAw MDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQow MDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBm DQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUz NSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2 NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAw MCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAw MDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAw MDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0K MDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUg Zg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1 MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAg NjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAw MDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAw MDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAw MDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYN CjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1 IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQp0cmFpbGVyDQo8PC9T aXplIDEyND4+DQpzdGFydHhyZWYNCjExNg0KJSVFT0YNCg== --=====================_-1104723118==_-- From housley@vigilsec.com Fri Jan 27 12:38:53 2006 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 k0RHcrsL027137 for ; Fri, 27 Jan 2006 12:38:53 -0500 (EST) Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) k0RHcn8Q023308 for ; Fri, 27 Jan 2006 12:38:50 -0500 (EST) Received: (qmail 28918 invoked by uid 0); 27 Jan 2006 17:38:44 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.9.167) by woodstock.binhost.com with SMTP; 27 Jan 2006 17:38:44 -0000 Message-Id: <7.0.0.16.2.20060127123259.062e29f8@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Fri, 27 Jan 2006 12:38:43 -0500 To: saag@mit.edu From: Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.665825 Subject: [saag] International Conference on Network Security 2006 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, 27 Jan 2006 17:38:54 -0000 Please consider responding to this call for participation. Russ = = = = = = = = = The International Conference on Network Security 2006 April 17-19, 2006 Hyatt Regency Reston, Reston, Virginia Call for Presentations The International Conference on Network Security 2006, to be held in Reston, Virginia, April 17-19, is a highly informative and interactive event devoted to the subject of security in networks, applications, and critical information infrastructure. The goal of the conference on Network Security is to facilitate a shift in the current paradigm to a more implementation oriented model for Network and Critical Infrastructure Security. To achieve that goal, the conference will focus on honest analysis and fearless review of current practices and industry standards. Therefore the conference is targeted to those individuals that seek to make a tangible difference in the field of network security. Program Overview The program committee is looking for both novel work as well as overviews covering key practical subjects, new technologies and user experience case studies. The conference program will consist of tutorials, keynote speeches, technical sessions, panel discussions and interactive events addressing contemporary issues. Position papers on controversial issues, and papers that summarize the area, are also solicited. Each area will be presented with a short overview of the state of art in practice and in research, given by a specialist in that area. Some technical sessions that have already been accepted are: - Software Security What paths will lead to software security and what can more clever hardware do for us? Can type-safe languages like Java substantially eliminate exploitable security bugs? - Network Security Protocol Issues What are the important security issues in the Internet infrastructure and protocol implementation? - Trusted Platform How does Trusted Platform work and what problems does it solve? Will/should all computers be built on this technology in the future? - Wireless and Wireline Network Access Security What are the key security issues in the network access based on WiFi, WiMAX, Ad Hoc networks, as well as Broadband? Additional topics that are requested include, but are not limited to: - Surviving Denial of Service - Unintended Consequences of Virus Propagation: Third Party Denial of Service - Smart Cards and Biometrics - Web Browser Security - Network Firewall Control and Configuration - Authentication/authorization/PKI - Deployment challenges of new Internet standards - Security and the quantum/nanotech computing - Certification programs: Are they useful? - Mesh Network Security - Other pertinent issues in Network Security Following the conference, authors of selected presentations will be invited to prepare their manuscript for publication in a special issue of major professional journal. Conference Chair Guy Copeland - Vice President, Information Infrastructure Advisory Programs and Special Assistant to the CEO, at Computer Sciences Corporation Technical Co-chairs - Radia Perlman, Sun Microsystems - Bijan Jabbari, Isocore Technical Committee Members - Gene Spafford, Professor and Executive Director, Purdue University CERIAS - Charlie Kaufman, Security Architect, Microsoft - Andy Ellis, Akamai, InfoSec Chief Security Architect, Senior Director - Hillarie Orman, Chief Technology Officer and Vice-President of Engineering, Shinkuro Inc. - Darren Moffat, Senior Staff Engineer, Solaris Software, Sun Microsystems - Parviz Yegani, Technical Leader, Mobile Wireless Business Unit, Cisco Systems - Russ Housley, Principle Consultant, Vigil Security - Upendra Mardikar, Technical Architect, Pay Pal - Donald Eastlake, Distinguished Member of Technical Staff, Motorola Laboratories - Marcus Leech, Security Standards Advisor, Strategic Standards Group, Nortel - Greg Edwards, Sr. Staff InfoSec Engineer, Lockheed Martin Please send your proposal to the attention of the Technical Program Committee at networksecurity2006-cfp@isocore.com For additional information please visit http://www.networksecurity2006.com or send email to networksecurity2006-info@isocore.com From scott@hyperthought.com Tue Jan 31 08:50:22 2006 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 k0VDoLsL002893 for ; Tue, 31 Jan 2006 08:50:21 -0500 (EST) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.192.83]) k0VDoHdd027894 for ; Tue, 31 Jan 2006 08:50:17 -0500 (EST) Received: from [192.168.128.4] (c-24-6-207-154.hsd1.ca.comcast.net[24.6.207.154]) by comcast.net (rwcrmhc13) with ESMTP id <20060131135016m1300nirc8e>; Tue, 31 Jan 2006 13:50:16 +0000 Message-ID: <43DF6B18.6050804@hyperthought.com> Date: Tue, 31 Jan 2006 05:50:16 -0800 From: Scott G Kelly User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: saag@mit.edu Content-Type: multipart/mixed; boundary="------------090209020303050509030204" X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.752443 Subject: [saag] [Fwd: I-D ACTION:draft-kelly-saag-des-implications-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: Tue, 31 Jan 2006 13:50:22 -0000 This is a multi-part message in MIME format. --------------090209020303050509030204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Some time ago, Russ Housley asked if someone would write a note for implementers regarding the security implications of using DES. This request derived from a recommendation in http://www.ietf.org/internet-drafts/draft-ietf-newtrk-decruft-experiment-03.txt. Anyway, here's the first cut at the draft. I intend to add an appendix explaining why 3DES is still okay, and someone suggested that maybe DESX should be discussed as well. If you have suggestions or comments, I'm all ears... --------------090209020303050509030204 Content-Type: message/rfc822; name="I-D ACTION:draft-kelly-saag-des-implications-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="I-D ACTION:draft-kelly-saag-des-implications-00.txt" X-Account-Key: account2 Return-Path: Received: from zeverly.mail.atl.earthlink.net ([207.69.200.46]) id 1f3Gc11eC3Nl34h1 for ; Mon, 30 Jan 2006 16:04:09 -0500 (EST) Received: from antoninus-z.mspring.net ([207.69.231.70] helo=antoninus.mspring.net) by zeverly.mail.atl.earthlink.net with smtp (Exim 3.36 #4) id 1F3gC1-0003os-00 for s.kelly@ix.netcom.com; Mon, 30 Jan 2006 16:04:09 -0500 X-ELNK-Loop: scott@hyperthought.com Received: from megatron.ietf.org ([132.151.6.71])1f3GbX2Ss3Nl5tA0 for ; Mon, 30 Jan 2006 16:04:04 -0500 (EST) Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3fyd-0004I1-Im; Mon, 30 Jan 2006 15:50:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3fyP-0004D7-Fa for i-d-announce@megatron.ietf.org; Mon, 30 Jan 2006 15:50:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26333 for ; Mon, 30 Jan 2006 15:48:27 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3g9D-0001Zs-AX for i-d-announce@ietf.org; Mon, 30 Jan 2006 16:01:16 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1F3fyM-0007ZH-HG for i-d-announce@ietf.org; Mon, 30 Jan 2006 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 30 Jan 2006 15:50:02 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Subject: I-D ACTION:draft-kelly-saag-des-implications-00.txt X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org X-ELNK-Info: spv=0; X-ELNK-AV: 0 X-ELNK-Info: sbv=0; sbrc=.0; sbf=0b; sbw=010; --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : draft-kelly-saag-des-implications Author(s) : S. Kelly Filename : draft-kelly-saag-des-implications-00.txt Pages : 24 Date : 2006-1-30 The Data Encryption Standard [DES] is susceptible to brute force attacks which are well within the reach of a modestly financed adversary. As a result, DES has been deprecated, and replaced by the Advanced Encryption Standard [AES]. Nonetheless, many applications continue to rely on DES for security, and designers and implementers continue to provide support for it in new applications. While this is not always inappropriate, it frequently is. This note discusses DES security implications, so that designers and implementers can make judicious decisions regarding its use. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kelly-saag-des-implications-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-kelly-saag-des-implications-00.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-kelly-saag-des-implications-00.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-1-30120813.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kelly-saag-des-implications-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-kelly-saag-des-implications-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-1-30120813.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart-- --------------090209020303050509030204-- From housley@vigilsec.com Tue Feb 7 22:18:01 2006 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 k183I0sL016137 for ; Tue, 7 Feb 2006 22:18:00 -0500 (EST) Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) k183HvlZ013656 for ; Tue, 7 Feb 2006 22:17:57 -0500 (EST) Received: (qmail 13175 invoked by uid 0); 8 Feb 2006 03:17:47 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.133.185) by woodstock.binhost.com with SMTP; 8 Feb 2006 03:17:47 -0000 Message-Id: <7.0.0.16.2.20060207221621.0957bb70@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Tue, 07 Feb 2006 22:17:53 -0500 To: saag@mit.edu From: Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000441 Spam-Alum-Time: 0.508803 Subject: [saag] Please review draft-bonica-tcp-auth-04 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, 08 Feb 2006 03:18:01 -0000 A companion document will be coming to define automated key management, but I would like to have several eyes on this document. If you have a few cycles, please review this document. Russ From hartmans@MIT.EDU Thu Feb 9 20:00:12 2006 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 k1A10BsL005147 for ; Thu, 9 Feb 2006 20:00:11 -0500 (EST) Received: from carter-zimmerman.mit.edu (STRATTON-TWO-SIXTY-EIGHT.MIT.EDU [18.187.6.13])k1A108j6025689 for ; Thu, 9 Feb 2006 20:00:08 -0500 (EST) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id BED67E0053; Thu, 9 Feb 2006 20:00:01 -0500 (EST) To: newtrk@lists.uoregon.edu, saag@mit.edu From: Sam Hartman Date: Thu, 09 Feb 2006 20:00:01 -0500 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 1.217 X-Spam-Level: * (1.217) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.574312 cc: iesg@ietf.org Subject: [saag] BCP 61, advancing to draft 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, 10 Feb 2006 01:00:12 -0000 Hi. I'd like to remind everyone of BCP 61. It says roughly that protocols we approve need a mandatory to implement security mechanism. We here in the security area think that's a great idea. O, by the way, we're here to help you. As part of our plan for world domination^h^h^hhelping you, we've created a number of security solutions including things like SASL, TLS, IPsec, Kerberos, GSS-API, and CMS. We really like it when you use these security services instead of inventing your own. First, it makes it hugely easier for us to review your documents. Second, it makes it easier when we need to do algorithm upgrades to things like hash functions or replace DES with AES. Finally it probably makes your security easier to deploy. There's this littple problem though. All of the above are at proposed standard. For a number of reasons they are not moving to draft as soon as anyone would like. So, I see two options that I don't like. First, we can avoid security in anything going to draft. Draft becomes a dumping ground for all the older protocols (plus a few things like SNMP that invent their own security) without updates that add security. Secondly, we can block everything from going to draft. Does anyone want to work on a better answer to this? --Sam From harald@alvestrand.no Fri Feb 10 04:03:52 2006 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 k1A93psL008314 for ; Fri, 10 Feb 2006 04:03:51 -0500 (EST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) k1A93Z4R005689; Fri, 10 Feb 2006 04:03:35 -0500 (EST) Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 73359259747; Fri, 10 Feb 2006 10:02:15 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26029-05; Fri, 10 Feb 2006 10:02:11 +0100 (CET) Received: from halvestr-w2k02.emea.cisco.com (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1DA4A25976F; Fri, 10 Feb 2006 10:02:08 +0100 (CET) Date: Fri, 10 Feb 2006 10:02:54 +0100 From: Harald Tveit Alvestrand To: Sam Hartman , newtrk@lists.uoregon.edu, saag@MIT.EDU Subject: Re: [saag] BCP 61, advancing to draft Message-ID: <5FDB6BFF8B21BF198FE507BA@B50854F0A9192E8EC6CDA126> In-Reply-To: References: X-Mailer: Mulberry/4.0.3 (Win32) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========955C3E105A2374299B40==========" X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: -2.264 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.608669 cc: iesg@ietf.org 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, 10 Feb 2006 09:03:52 -0000 --==========955C3E105A2374299B40========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline --On 9. februar 2006 20:00 -0500 Sam Hartman wrote: > As part of our plan for world domination^h^h^hhelping you, we've > created a number of security solutions including things like SASL, > TLS, IPsec, Kerberos, GSS-API, and CMS. We really like it when you > use these security services instead of inventing your own. First, it > makes it hugely easier for us to review your documents. Second, it > makes it easier when we need to do algorithm upgrades to things like > hash functions or replace DES with AES. Finally it probably makes > your security easier to deploy. > > > There's this littple problem though. All of the above are at proposed > standard. > > For a number of reasons they are not moving to draft as soon as anyone > would like. Care to elaborate? > So, I see two options that I don't like. First, we can avoid security > in anything going to draft. Draft becomes a dumping ground for all > the older protocols (plus a few things like SNMP that invent their own > security) without updates that add security. Secondly, we can block > everything from going to draft. > > Does anyone want to work on a better answer to this? Seems that there are two possible answers: - Move the security stuff to Draft (knocking down the reasons for that not=20 happening one at a time, possibly changing the criteria for Draft on the=20 way) - Abolish Draft I consider the third option - having Draft with downreference to Proposed - = to be a Bad Idea. If we have to do that, I'd rather abandon Draft. Harald --==========955C3E105A2374299B40========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) iD8DBQFD7Fa+OMj+2+WY0F4RAm+VAKD8gDap4F3rpFzL3H8yQmz/iPp1fQCdEEiC DxD+ZLhI5VvtRpkn3Jgmc0o= =TxYc -----END PGP SIGNATURE----- --==========955C3E105A2374299B40==========-- From hartmans@MIT.EDU Fri Feb 10 07:34:53 2006 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 k1ACYqsL009639 for ; Fri, 10 Feb 2006 07:34:52 -0500 (EST) Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178])k1ACYduS013755 for ; Fri, 10 Feb 2006 07:34:39 -0500 (EST) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 01707E0053; Fri, 10 Feb 2006 07:34:33 -0500 (EST) To: Harald Tveit Alvestrand Subject: Re: [saag] BCP 61, advancing to draft References: <5FDB6BFF8B21BF198FE507BA@B50854F0A9192E8EC6CDA126> From: Sam Hartman Date: Fri, 10 Feb 2006 07:34:33 -0500 In-Reply-To: <5FDB6BFF8B21BF198FE507BA@B50854F0A9192E8EC6CDA126> (Harald Tveit Alvestrand's message of "Fri, 10 Feb 2006 10:02:54 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 1.352 X-Spam-Level: * (1.352) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.577346 cc: iesg@ietf.org cc: newtrk@lists.uoregon.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: Fri, 10 Feb 2006 12:34:53 -0000 >>>>> "Harald" == Harald Tveit Alvestrand writes: >> >> For a number of reasons they are not moving to draft as soon as >> anyone would like. Harald> Care to elaborate? Sure, but this is very much with my AD hat off and with the warning that I'm probably wrong on some of these. SASL: internationalization issues; low number of volunteers dedicating time. Not clear which mechanism to move to draft to validate the framework. IPsec: just moved to proposed again; not many implementations; already needs for clarifications drafts. TLS: Moving to proposed again because of hash mess. Kerberos: Doable, but we're all fairly busy working on meeting new customer needs. We did recently hold a meeting and develop feature matrix and roughly what we'd need to remove from the spec. We were really hoping that RFC 4120 would not need things removed; I think a lot of us lost interest in moving Kerberos to draft any time soon when we found out that was not the case. GSS-API: Needs a mechanism to move to drfat. Kerberos mechanism depends on Kerberos. Everything else needs some significant work on the documentation front that no one is really chartered to do. An individual wanted to do the work and was encouraged to contact an AD when they had a draft; haven't heard from them in months. PKIX: I think has some internationalization issues; possibly some hash fun. Not really sure. CMS: Unsure. Wouldn't surprise me if besides PKIX dependencies this was in the best shape. --Sam From rja@extremenetworks.com Fri Feb 10 08:06:37 2006 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 k1AD6asL009903 for ; Fri, 10 Feb 2006 08:06:36 -0500 (EST) Received: from eastrmmtao03.cox.net (eastrmmtao03.cox.net [68.230.240.36]) k1AD6TZe012479; Fri, 10 Feb 2006 08:06:29 -0500 (EST) Received: from [10.30.20.240] (really [70.174.17.170]) by eastrmmtao03.cox.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20060210130631.MVZI29285.eastrmmtao03.cox.net@[10.30.20.240]>; Fri, 10 Feb 2006 08:06:31 -0500 In-Reply-To: <5FDB6BFF8B21BF198FE507BA@B50854F0A9192E8EC6CDA126> References: <5FDB6BFF8B21BF198FE507BA@B50854F0A9192E8EC6CDA126> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5CEC980A-22AC-418F-B5FC-1F262919B6D7@extremenetworks.com> Content-Transfer-Encoding: 7bit From: RJ Atkinson Subject: Re: [saag] BCP 61, advancing to draft Date: Fri, 10 Feb 2006 08:06:27 -0500 To: Harald Tveit Alvestrand X-Mailer: Apple Mail (2.746.2) X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.641633 cc: iesg@ietf.org cc: Sam Hartman cc: newtrk@lists.uoregon.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: Fri, 10 Feb 2006 13:06:37 -0000 On 10 Feb 2006, at 04:02, Harald Tveit Alvestrand wrote: % Seems that there are two possible answers: % % - Move the security stuff to Draft (knocking down the reasons for that % not happening one at a time, possibly changing the criteria for Draft % on the way) % - Abolish Draft % % I consider the third option - having Draft with downreference to Proposed - % to be a Bad Idea. If we have to do that, I'd rather abandon Draft. I would suggest that in parallel both (1) "move the security stuff to Draft" and (2) "abolish Draft Standard" of Harald's suggestions be undertaken. My guess is that Sam's note was a polite way of trying to "encourage" the security community to undertake (1), but I could be wrong. Security is not the only thing that impedes going to Draft Standard or Full Standard. There is a longish list of things that can impede progression away from Proposed Standard. We have an impressive number of IETF standards-track protocols that have been at Proposed Standard for many many years. Some are widely used, while others are widely ignored. My proposal for a new standards track looks roughly like this: 1) Proposed Standard - Rules exactly as they are to progress to Proposed Standard - No Changes 2) Delete the "Draft Standard" state, but keep the "multiple interoperable implementations" rule and apply that rule to "Full Standard". 3) Require that most Proposed Standards (i.e. those that are not blocked by the failure of some other standard to advance) move to Full Standard within 2 years (edit time to your taste) of publication as a Proposed Standard or 2 years of all normative references moving to Full Standard, whichever comes later. Anything that does not meet that requirement automatically gets reclassified as HISTORIC status unless the IESG grants an exception at the 2 year timeout. IESG exceptions are themselves limited to 2 years. Any IESG exception requires the IESG to publicly say why the exception was granted in the particular case. 4) 3 months after the above changes are approved, any documents already at Draft Standard progress automatically to Full Standard, unless the IESG takes some other action (e.g. move to Historic) on the Draft Standard(s) during the 3 month window just after the process changes are approved. This achieves the following goals: (1) simplifies the standards track greatly, which by itself increases the incentive to advance a document, and (in theory) reduces the workload for the IESG. (2) retains the requirement for demonstrated interoperability before becoming a Full Standard. We all understand why this is important. (3) creates a "timeout" that incents WGs and individuals to progress their documents all the way along to Full Standard, lest the document(s) automatically move to HISTORIC. This timeout period does not start until the document is unblocked by normative references. (4) gives the IESG the power to grant exceptions to the "timeout" for any exceptional cases. Yours, Ran rja@extremenetworks.com From pgut001@cs.auckland.ac.nz Fri Feb 10 08:13:56 2006 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 k1ADDtsL009974 for ; Fri, 10 Feb 2006 08:13:55 -0500 (EST) Received: from harpo.itss.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.190.13])k1ADDpZe008568; Fri, 10 Feb 2006 08:13:52 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by harpo.itss.auckland.ac.nz (Postfix) with ESMTP id B339E34B65; Sat, 11 Feb 2006 02:13:07 +1300 (NZDT) Received: from harpo.itss.auckland.ac.nz ([127.0.0.1])port 10024) with ESMTP id 31021-29; Sat, 11 Feb 2006 02:13:07 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by harpo.itss.auckland.ac.nz (Postfix) with ESMTP id 0802834685; Sat, 11 Feb 2006 02:13:06 +1300 (NZDT) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 03A7D37748; Sat, 11 Feb 2006 02:13:06 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1F7Y5L-00055F-00; Sat, 11 Feb 2006 02:13:15 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: harald@alvestrand.no, hartmans-ietf@MIT.EDU Subject: Re: [saag] BCP 61, advancing to draft In-Reply-To: Message-Id: Sender: pgut001 Date: Sat, 11 Feb 2006 02:13:15 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.571428 cc: iesg@ietf.org cc: newtrk@lists.uoregon.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: Fri, 10 Feb 2006 13:13:56 -0000 Sam Hartman writes: >>>>>> "Harald" == Harald Tveit Alvestrand writes: > >> > >> For a number of reasons they are not moving to draft as soon as > >> anyone would like. > > Harald> Care to elaborate? > >Sure, but this is very much with my AD hat off and with the warning that I'm >probably wrong on some of these. > >[List snipped] Just looking at this list, is the document-status thing just a case of changing some policy, or is there more to it than that? For example from that list TLS, Kerberos, and CMS have all been around for 10-15 years so it's unlikely that there are going to be major changes in the spec, and in particular that there will be non-backwards-compatible changes. So all you'd need to do is instead of pointing to [RFCxxxx], point to [TLS], where [TLS] is "'The TLS Protocol', version 1.1 or any later version". This is already done by documents like the GPL, which specify use of "version X or any later version" rather than hardcoding in a particular document. Since these protocols stick around for years, even decades (I mean we've only just got around to deprecating the broken SSLv2 protocol after 12 years of use), I can't see any major interop problems turning up. Without this, you end up with horrible priority inversions where some far-distant unfinished spec ends up blocking a major standards effort that needs to refer to it. Peter. From rja@extremenetworks.com Fri Feb 10 08:21:22 2006 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 k1ADLLsL010063 for ; Fri, 10 Feb 2006 08:21:21 -0500 (EST) Received: from eastrmmtao02.cox.net (eastrmmtao02.cox.net [68.230.240.37]) k1ADLIuS014617 for ; Fri, 10 Feb 2006 08:21:18 -0500 (EST) Received: from [10.30.20.240] (really [70.174.17.170]) by eastrmmtao02.cox.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20060210132120.STUB14821.eastrmmtao02.cox.net@[10.30.20.240]>; Fri, 10 Feb 2006 08:21:20 -0500 In-Reply-To: References: <5FDB6BFF8B21BF198FE507BA@B50854F0A9192E8EC6CDA126> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7DBC3359-383A-4A2B-BF37-8D9A63DA4526@extremenetworks.com> Content-Transfer-Encoding: 7bit From: RJ Atkinson Subject: Re: [saag] BCP 61, advancing to draft Date: Fri, 10 Feb 2006 08:21:16 -0500 To: saag@mit.edu X-Mailer: Apple Mail (2.746.2) X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.683499 cc: iesg@ietf.org cc: newtrk@lists.uoregon.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, 10 Feb 2006 13:21:22 -0000 On 10 Feb 2006, at 07:34, Sam Hartman wrote: > Sure, but this is very much with my AD hat off and with the warning > that I'm probably wrong on some of these. > > SASL: internationalization issues; low number of volunteers dedicating > time. Not clear which mechanism to move to draft to validate the > framework. So the issue here is multiple-dependency: - SASL can't advance because of the I18N rules - lots of other stuff can't advance because of SASL I'd say that the thing to do is to waive the I18N rule to let SASL go to Draft (with a requirement that I18N issues get addressed before further forward motion) -- then push on the I18N portion of the IETF to pitch in on this. I'm familiar with several languages and from time to time (e.g. MIME) have been involved in I18N discussions in the IETF. However, a big percentage of the IETF are only familiar with one or two languages (polyglots are actually rare in our circles). Those familiar with only one language are not likely to be able to help very much. > IPsec: just moved to proposed again; not many implementations; already > needs for clarifications drafts. One only needs 2 interoperable implementations to move to Draft Standard. If the new spec(s) don't have that, push the implementers to sort out interoperability, find 2 that work, declare victory, and move to Draft. If our current process had been around when TCP was first being specified, implemented, and tested, TCP would have become totally wedged also, IMHO. > TLS: Moving to proposed again because of hash mess. I'd suggest pushing on this one first in a focused way. The hash situation should be very straight-forward to sort out, if the ADs apply time pressure to the group. Adding new hash functions is not technically difficult, though IETF processes can be very difficult these days. > Kerberos: Doable, but we're all fairly busy working on meeting new > customer needs. We did recently hold a meeting and develop feature > matrix and roughly what we'd need to remove from the spec. We were > really hoping that RFC 4120 would not need things removed; I think a > lot of us lost interest in moving Kerberos to draft any time soon when > we found out that was not the case. If the issue is that not all features of 4120 are in at least 2 implementations, there are a couple of approaches. One is to go find a sponsor to fund someone to add the missing feature(s) to either MIT Kerberos or Heimdal. The other is to do what OSPF did with M-OSPF, move the not yet widely implemented (but perceived useful) items into a separate document so the main spec can advance more quickly. (Aside: I still miss having M-OSPF. It worked very well and was very easy to configure and operate. PIM has never come close to being as useful as M-OSPF. Sigh) > GSS-API: Needs a mechanism to move to drfat. Kerberos mechanism > depends on Kerberos. Everything else needs some significant work on > the documentation front that no one is really chartered to do. An > individual wanted to do the work and was encouraged to contact an AD > when they had a draft; haven't heard from them in months. Given that analysis, this is probably not low hanging fruit. > PKIX: I think has some internationalization issues; possibly some hash > fun. Not really sure. > > CMS: Unsure. Wouldn't surprise me if besides PKIX dependencies this > was in the best shape. These also don't look like low-hanging fruit. I think TLS is probably the lowest hanging fruit here. IPsec, Kerberos, and SASL come next in a clump. GSS-API, PKIX, and CMS seem pretty high up the tree just now. Just as I believe the security-interested people in the IETF need to pitch in to help other areas advance their specs, I also believe the I18N- interested people in the IETF need to help the security specs so the security area can advance its specs. We are all in this together. Yours, Ran rja@extremenetworks.com From smb@cs.columbia.edu Fri Feb 10 08:29:44 2006 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 k1ADTisL010158 for ; Fri, 10 Feb 2006 08:29:44 -0500 (EST) Received: from machshav.com (machshav.com [147.28.0.16]) k1ADTfZe004625 for ; Fri, 10 Feb 2006 08:29:41 -0500 (EST) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id ED416FB2A0; Fri, 10 Feb 2006 08:29:40 -0500 (EST) Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id 6C43D3BFDED; Fri, 10 Feb 2006 08:29:40 -0500 (EST) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 From: "Steven M. Bellovin" To: RJ Atkinson Subject: Re: [saag] BCP 61, advancing to draft In-Reply-To: (Your message of "Fri, 10 Feb 2006 08:21:16 EST.") <7DBC3359-383A-4A2B-BF37-8D9A63DA4526@extremenetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 10 Feb 2006 08:29:40 -0500 Sender: smb@cs.columbia.edu Message-Id: <20060210132940.6C43D3BFDED@berkshire.machshav.com> X-Spam-Score: 1.217 X-Spam-Level: * (1.217) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.554305 cc: iesg@ietf.org cc: newtrk@lists.uoregon.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: Fri, 10 Feb 2006 13:29:45 -0000 In message <7DBC3359-383A-4A2B-BF37-8D9A63DA4526@extremenetworks.com>, RJ Atkin son writes: > > > >> TLS: Moving to proposed again because of hash mess. > >I'd suggest pushing on this one first in a focused way. The hash >situation should be very straight-forward to sort out, if the ADs >apply time pressure to the group. Adding new hash functions is >not technically difficult, though IETF processes can be very difficult >these days. The issue is not adding the hash functions, it's adding the negotiation to permit their use. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb From pgut001@cs.auckland.ac.nz Fri Feb 10 08:33:26 2006 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 k1ADXPsL010204 for ; Fri, 10 Feb 2006 08:33:25 -0500 (EST) Received: from harpo.itss.auckland.ac.nz (harpo.itss.auckland.ac.nz [130.216.190.13])k1ADXHuS018199 for ; Fri, 10 Feb 2006 08:33:18 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by harpo.itss.auckland.ac.nz (Postfix) with ESMTP id 79EEC34ADD; Sat, 11 Feb 2006 02:33:16 +1300 (NZDT) Received: from harpo.itss.auckland.ac.nz ([127.0.0.1])port 10024) with ESMTP id 16797-28; Sat, 11 Feb 2006 02:33:16 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by harpo.itss.auckland.ac.nz (Postfix) with ESMTP id BCB0334ACD; Sat, 11 Feb 2006 02:33:15 +1300 (NZDT) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 606BD37748; Sat, 11 Feb 2006 02:33:15 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1F7YOq-00057E-00; Sat, 11 Feb 2006 02:33:24 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: rja@extremenetworks.com, saag@mit.edu Subject: Re: [saag] BCP 61, advancing to draft In-Reply-To: <7DBC3359-383A-4A2B-BF37-8D9A63DA4526@extremenetworks.com> Message-Id: Sender: pgut001 Date: Sat, 11 Feb 2006 02:33:24 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.562607 cc: iesg@ietf.org cc: newtrk@lists.uoregon.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, 10 Feb 2006 13:33:27 -0000 RJ Atkinson writes: >> PKIX: I think has some internationalization issues; possibly some hash >> fun. Not really sure. >> >> CMS: Unsure. Wouldn't surprise me if besides PKIX dependencies this >> was in the best shape. > >These also don't look like low-hanging fruit. > >I think TLS is probably the lowest hanging fruit here. IPsec, Kerberos, and >SASL come next in a clump. GSS-API, PKIX, and CMS seem pretty high up the >tree just now. And that's the problem - CMS and TLS are both blocked waiting on PKIX (this is what held up TLS at the RFC 2246 stage for what, three years?). Presumably IPsec will also block on PKIX. This is why I proposed the relative- rather than absolute-value reference approach in my previous message. Without this, you get the priority-inversion situation of the lowest-hanging fruit stalled behind the highest-hanging fruit (not to mention appallingly mangled metaphors). Peter. From rja@extremenetworks.com Fri Feb 10 09:08:37 2006 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 k1AE8asL010562 for ; Fri, 10 Feb 2006 09:08:36 -0500 (EST) Received: from eastrmmtao01.cox.net (eastrmmtao01.cox.net [68.230.240.38]) k1AE8SuS010024 for ; Fri, 10 Feb 2006 09:08:28 -0500 (EST) Received: from [10.30.20.240] (really [70.174.17.170]) by eastrmmtao01.cox.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20060210140830.TTHL4894.eastrmmtao01.cox.net@[10.30.20.240]>; Fri, 10 Feb 2006 09:08:30 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0E2B3591-EF88-4D92-BE57-4C0F0C866CC5@extremenetworks.com> Content-Transfer-Encoding: 7bit From: RJ Atkinson Subject: Re: [saag] BCP 61, advancing to draft Date: Fri, 10 Feb 2006 09:08:26 -0500 To: Peter Gutmann X-Mailer: Apple Mail (2.746.2) X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.538803 cc: iesg@ietf.org cc: newtrk@lists.uoregon.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: Fri, 10 Feb 2006 14:08:38 -0000 On 10 Feb 2006, at 08:33, Peter Gutmann wrote: > And that's the problem - CMS and TLS are both blocked waiting on > PKIX (this is > what held up TLS at the RFC 2246 stage for what, three years?). > Presumably IPsec will also block on PKIX. ESP/AH do not depend on PKIX, and they ought not normatively depend on IKE (or any other automatic key management method), so ESP/AH should be able to move forward without PKIX. Similarly, applications that use ESP/AH, should be able to move forward when ESP/AH move forward, regardless of IKE (or PKIX). The modular design of ESP/AH/ISAKMP/IKE was very deliberate -- because the original designer of ESP/AH fully expected that the key management schemes would need to change (given the past history of Diffie-Hellman and Needham-Schroder in the published history up through 1995). Cheers, Ran From paul.hoffman@vpnc.org Fri Feb 10 10:02:39 2006 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 k1AF2csL011045 for ; Fri, 10 Feb 2006 10:02:39 -0500 (EST) Received: from above.proper.com (above.proper.com [208.184.76.39]) k1AF2SZe017708; Fri, 10 Feb 2006 10:02:29 -0500 (EST) Received: from [10.20.30.249] (dsl2-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id k1AF2DPG090755; Fri, 10 Feb 2006 07:02:16 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <5FDB6BFF8B21BF198FE507BA@B50854F0A9192E8EC6CDA126> References: <5FDB6BFF8B21BF198FE507BA@B50854F0A9192E8EC6CDA126> Date: Fri, 10 Feb 2006 06:52:33 -0800 To: Harald Tveit Alvestrand , Sam Hartman , newtrk@lists.uoregon.edu, saag@mit.edu From: Paul Hoffman Subject: Re: [saag] BCP 61, advancing to draft Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.534052 cc: iesg@ietf.org 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, 10 Feb 2006 15:02:40 -0000 One big issue we have with security protocols moving to draft is that there is very little volunteer interest in testing SHOULD/MUST interop beyond the basics (if even that). Our protocols have a lot of SHOULDs that have nothing to do with interop and are very difficult to test. But, even without those, the security area has been much less active at voluntary interop testing than other areas, which makes "going to Draft" not appealing. We are generally happy to cycle at Proposed. Sam's message points out a significant ramification of that attitude, although I don't have a proposed solution to the problem. --Paul Hoffman, Director --VPN Consortium From Kurt@OpenLDAP.org Fri Feb 10 10:21:14 2006 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 k1AFLDsL011180 for ; Fri, 10 Feb 2006 10:21:13 -0500 (EST) Received: from boole.openldap.org (boole.openldap.org [204.152.186.50]) k1AFKwZe026464; Fri, 10 Feb 2006 10:21:00 -0500 (EST) Received: from gyspy.OpenLDAP.org ([12.168.234.3]) (authenticated bits=0) by boole.openldap.org (8.13.3/8.13.3) with ESMTP id k1AFKfOM002622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Feb 2006 15:20:42 GMT (envelope-from Kurt@OpenLDAP.org) Message-Id: <7.0.1.0.0.20060210070911.03a20128@OpenLDAP.org> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 10 Feb 2006 07:20:37 -0800 To: Sam Hartman From: "Kurt D. Zeilenga" Subject: Re: [saag] BCP 61, advancing to draft In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.622769 cc: iesg@ietf.org cc: newtrk@lists.uoregon.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: Fri, 10 Feb 2006 15:21:15 -0000 I note that just because some dependencies are not yet ready to be progressed to Draft Standard doesn't preclude us from revising protocols as needed to address other issues holding them at Proposed. For instance, with LDAP, we've resolved a host of issues requiring publication of revised LDAP specifications. These will get published at Proposed in conjunction with revised TLS and SASL specs, then pending implementation reports and other requirements, we should get to Draft. I also note that the formal Draft Standard declaration is not nearly as important as resolution of the technical issues that kept us at Proposed. As these issues have been adequately addressed, I'm quite happy. The formalities will catch up in due course. That is, I really don't see a problem here. Kurt At 05:00 PM 2/9/2006, Sam Hartman wrote: >Hi. I'd like to remind everyone of BCP 61. It says roughly that >protocols we approve need a mandatory to implement security mechanism. >We here in the security area think that's a great idea. O, by the >way, we're here to help you. > >As part of our plan for world domination^h^h^hhelping you, we've >created a number of security solutions including things like SASL, >TLS, IPsec, Kerberos, GSS-API, and CMS. We really like it when you >use these security services instead of inventing your own. First, it >makes it hugely easier for us to review your documents. Second, it >makes it easier when we need to do algorithm upgrades to things like >hash functions or replace DES with AES. Finally it probably makes >your security easier to deploy. > > >There's this littple problem though. All of the above are at proposed >standard. > >For a number of reasons they are not moving to draft as soon as anyone >would like. > > >So, I see two options that I don't like. First, we can avoid security >in anything going to draft. Draft becomes a dumping ground for all >the older protocols (plus a few things like SNMP that invent their own >security) without updates that add security. Secondly, we can block >everything from going to draft. > >Does anyone want to work on a better answer to this? > >--Sam > > >_______________________________________________ >saag mailing list >saag@mit.edu >http://jis.mit.edu/mailman/listinfo/saag From mcr@sandelman.ottawa.on.ca Fri Feb 10 14:32:04 2006 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 k1AJW2sL012925 for ; Fri, 10 Feb 2006 14:32:03 -0500 (EST) Received: from lists.sandelman.ca (cod.sandelman.ca [192.139.46.139]) k1AJVhSJ026493; Fri, 10 Feb 2006 14:31:48 -0500 (EST) Received: from sandelman.ottawa.on.ca (postfix@res153.cooperix.net [192.139.46.153]) by lists.sandelman.ca (8.11.6p3/8.11.6) with ESMTP id k1AJVHJ22783 verified OK); Fri, 10 Feb 2006 14:31:19 -0500 (EST) Received: from sandelman.ottawa.on.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 11EE33ADA1; Fri, 10 Feb 2006 08:55:36 -0500 (EST) To: Harald Tveit Alvestrand Subject: Re: [saag] BCP 61, advancing to draft In-Reply-To: Message from Harald Tveit Alvestrand <5FDB6BFF8B21BF198FE507BA@B50854F0A9192E8EC6CDA126> References: <5FDB6BFF8B21BF198FE507BA@B50854F0A9192E8EC6CDA126> X-Mailer: MH-E 7.82; nmh 1.1; XEmacs 21.4 (patch 17) Date: Fri, 10 Feb 2006 08:55:36 -0500 Message-ID: <17947.1139579736@sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Score: -1.986 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.547788 cc: iesg@ietf.org cc: Sam Hartman cc: newtrk@lists.uoregon.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: Fri, 10 Feb 2006 19:32:04 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Harald" == Harald Tveit Alvestrand writes: >> For a number of reasons they are not moving to draft as soon as >> anyone would like. Harald> Care to elaborate? I think, because there simply isn't the patience left to do things. Harald> I consider the third option - having Draft with Harald> downreference to Proposed - to be a Bad Idea. If we have to Harald> do that, I'd rather abandon Draft. That's quite an indictment of our current three step system. - -- ] 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.4.1 (GNU/Linux) Comment: Finger me for keys iQEVAwUBQ+ybUYCLcPvd0N1lAQLbOAf9F1QBUK75+tlBGmzJarbzi1t3LyuUaDaS lnQ8OdqSBHJT03tMlepvlKLU/q1Hk5fAhTDWAvCYoZB3kBgYa0/bdNJEfPq8EhmO ywCsHFzbAdu+R5VhjSzyXVVDxuh1+84tXeRph2zVT4tT9W31iyUHxVtJSlXOdwur LH7ZbhLHLIehKM8CgMyNtvaryOR4QKXORLjs2lppruRUnP+tKNLZkupLqsyJv900 T5zpOk+xaN27XmZHwhErSq0NwXJ6U108QDo7AZiZ49ppgIVQEvdcH7eyv5SRp1iH ctisAOGBwEaRYqF+kr4RGAbTl++MsjXT6nsRhg/C2V2bPy0nQ80yBA== =qcXa -----END PGP SIGNATURE----- From hartmans@MIT.EDU Fri Feb 10 16:57:53 2006 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 k1ALvqsL013879 for ; Fri, 10 Feb 2006 16:57:52 -0500 (EST) Received: from carter-zimmerman.mit.edu (carter-zimmerman.dyn.MIT.EDU [18.188.3.148])k1ALvnEc021451 for ; Fri, 10 Feb 2006 16:57:49 -0500 (EST) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 0058CE006A; Fri, 10 Feb 2006 16:57:43 -0500 (EST) To: RJ Atkinson Subject: Re: [saag] BCP 61, advancing to draft References: <0E2B3591-EF88-4D92-BE57-4C0F0C866CC5@extremenetworks.com> From: Sam Hartman Date: Fri, 10 Feb 2006 16:57:43 -0500 In-Reply-To: <0E2B3591-EF88-4D92-BE57-4C0F0C866CC5@extremenetworks.com> (RJ Atkinson's message of "Fri, 10 Feb 2006 09:08:26 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 1.217 X-Spam-Level: * (1.217) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.520577 cc: iesg@ietf.org cc: newtrk@lists.uoregon.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: Fri, 10 Feb 2006 21:57:53 -0000 >>>>> "RJ" == RJ Atkinson writes: RJ> ESP/AH do not depend on PKIX, and they ought not normatively RJ> depend on IKE (or any other automatic key management method), RJ> so ESP/AH should be able to move forward without PKIX. RJ> Similarly, applications that use ESP/AH, should be able to RJ> move forward when ESP/AH move forward, regardless of IKE (or RJ> PKIX). However BCP 107 argues that there should be few applications for which ESP/AH is appropriate without automated key management. I also suspect that ESP/AH depend on the architecture document. From hartmans@MIT.EDU Fri Feb 10 17:03:31 2006 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 k1AM3UsL013934 for ; Fri, 10 Feb 2006 17:03:30 -0500 (EST) Received: from carter-zimmerman.mit.edu (carter-zimmerman.dyn.MIT.EDU [18.188.3.148])k1AM3LEc010822 for ; Fri, 10 Feb 2006 17:03:21 -0500 (EST) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 5D93BE006A; Fri, 10 Feb 2006 17:03:16 -0500 (EST) To: RJ Atkinson Subject: Re: [saag] BCP 61, advancing to draft References: <5FDB6BFF8B21BF198FE507BA@B50854F0A9192E8EC6CDA126> <7DBC3359-383A-4A2B-BF37-8D9A63DA4526@extremenetworks.com> From: Sam Hartman Date: Fri, 10 Feb 2006 17:03:16 -0500 In-Reply-To: <7DBC3359-383A-4A2B-BF37-8D9A63DA4526@extremenetworks.com> (RJ Atkinson's message of "Fri, 10 Feb 2006 08:21:16 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 1.217 X-Spam-Level: * (1.217) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.582382 cc: iesg@ietf.org cc: newtrk@lists.uoregon.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: Fri, 10 Feb 2006 22:03:31 -0000 >>>>> "RJ" == RJ Atkinson writes: >> Kerberos: Doable, but we're all fairly busy working on meeting >> new customer needs. We did recently hold a meeting and develop >> feature matrix and roughly what we'd need to remove from the >> spec. We were really hoping that RFC 4120 would not need >> things removed; I think a lot of us lost interest in moving >> Kerberos to draft any time soon when we found out that was not >> the case. RJ> If the issue is that not all features of 4120 are in at least RJ> 2 implementations, there are a couple of approaches. One is RJ> to go find a sponsor to fund someone to add the missing RJ> feature(s) to either MIT Kerberos or Heimdal. The other is to RJ> do what OSPF did with M-OSPF, move the not yet widely RJ> implemented (but perceived useful) items into a separate RJ> document so the main spec can advance more quickly. I think there are one or two things we found that we need a second implementation for. That is relatively easy. We found several items that we'd left in from 1510 because they were harmless. However they are things like X.500 realm names that no one plans to implement and that we don't have interop tests for. They're not actually useful to anyone so removing them is far better than implementing. The challenge is to produce a spec revision that is sufficiently focused. I have lowe confidence that would happen. Remember we're talking about the same people (and I'm as guilty as anyone else in the Kerberos group) who took 11 years to bring pk-init to the IESG. --Sam From housley@vigilsec.com Fri Feb 10 17:28:21 2006 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 k1AMSKsL014126 for ; Fri, 10 Feb 2006 17:28:20 -0500 (EST) Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) k1AMSHpb021374 for ; Fri, 10 Feb 2006 17:28:18 -0500 (EST) Received: (qmail 18298 invoked by uid 0); 10 Feb 2006 22:28:10 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.187.48) by woodstock.binhost.com with SMTP; 10 Feb 2006 22:28:10 -0000 Message-Id: <7.0.0.16.2.20060210172750.04913de0@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Fri, 10 Feb 2006 17:28:12 -0500 To: Sam Hartman , Harald Tveit Alvestrand From: Russ Housley Subject: Re: [saag] BCP 61, advancing to draft In-Reply-To: References: <5FDB6BFF8B21BF198FE507BA@B50854F0A9192E8EC6CDA126> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000003 Spam-Alum-Time: 0.507381 cc: iesg@ietf.org cc: newtrk@lists.uoregon.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: Fri, 10 Feb 2006 22:28:22 -0000 CMS depends on PKIX, so it cannot advance until PKIX does. Russ At 07:34 AM 2/10/2006, Sam Hartman wrote: >CMS: Unsure. Wouldn't surprise me if besides PKIX dependencies this >was in the best shape. From rja@extremenetworks.com Fri Feb 10 18:37:24 2006 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 k1ANbNsL014521 for ; Fri, 10 Feb 2006 18:37:23 -0500 (EST) Received: from eastrmmtao01.cox.net (eastrmmtao01.cox.net [68.230.240.38]) k1ANbKpb026069; Fri, 10 Feb 2006 18:37:20 -0500 (EST) Received: from [10.30.20.240] (really [70.174.17.170]) by eastrmmtao01.cox.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20060210233723.FCSD4894.eastrmmtao01.cox.net@[10.30.20.240]>; Fri, 10 Feb 2006 18:37:23 -0500 In-Reply-To: References: <0E2B3591-EF88-4D92-BE57-4C0F0C866CC5@extremenetworks.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: RJ Atkinson Subject: Re: [saag] BCP 61, advancing to draft Date: Fri, 10 Feb 2006 18:37:18 -0500 To: Sam Hartman X-Mailer: Apple Mail (2.746.2) X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.609309 cc: iesg@ietf.org cc: newtrk@lists.uoregon.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: Fri, 10 Feb 2006 23:37:25 -0000 On 10 Feb 2006, at 16:57, Sam Hartman wrote: >>>>>> "RJ" == RJ Atkinson writes: > > RJ> ESP/AH do not depend on PKIX, and they ought not normatively > RJ> depend on IKE (or any other automatic key management method), > RJ> so ESP/AH should be able to move forward without PKIX. > RJ> Similarly, applications that use ESP/AH, should be able to > RJ> move forward when ESP/AH move forward, regardless of IKE (or > RJ> PKIX). > > However BCP 107 argues that there should be few applications for which > ESP/AH is appropriate without automated key management. > > I also suspect that ESP/AH depend on the architecture document. I am sympathetic to the notion that no cryptographic system is easy to use without automatic key management. That said, insisting that a mechanism can only progress jointly with its (deliberately architecturally decoupled) key management method mostly seems to increase our process gridlock in a way that seems needless. Given the note at the start of today which started this thread, it seems wisest to keep ESP/AH (and the applications that depend on them -- and probably the IPsec Arch document) de-coupled from ISAKMP/IKE for advancement purposes. There is a clear trade-off between being practical about solving current issues versus being dogmatic about the ideal policy one might prefer in an ideal world. That trade-off is something that the powers that be need to sort out among themselves. I think the tools are already in place so that ESP/AH, IPsec Arch, and their dependent apps could all move rapidly to Draft Standard, without waiting for IKEv2 to get sorted out -- if the powers that be wanted to make that choice. For openers, people continue to use IKEv1 even as IKEv2 is being sorted out. IKEv1 is very widely deployed and used these days. ESP/AH can work with IKEv1 to have automatic key management -- until IKEv2 gets sorted out or KINK gets sorted out or some other better solution appears on the scene. Cheers, Ran From mcr@sandelman.ottawa.on.ca Fri Feb 10 20:19:08 2006 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 k1B1J7sL015200 for ; Fri, 10 Feb 2006 20:19:07 -0500 (EST) Received: from lists.sandelman.ca (cod.sandelman.ca [192.139.46.139]) k1B1IrJZ029793; Fri, 10 Feb 2006 20:18:54 -0500 (EST) Received: from sandelman.ottawa.on.ca (postfix@wlan225.sandelman.ca [205.150.200.225]) by lists.sandelman.ca (8.11.6p3/8.11.6) with ESMTP id k1B1I6J27959 verified OK); Fri, 10 Feb 2006 20:18:14 -0500 (EST) Received: from sandelman.ottawa.on.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id C8E373AD9C; Fri, 10 Feb 2006 20:18:04 -0500 (EST) To: Paul Hoffman Subject: Re: [saag] BCP 61, advancing to draft In-Reply-To: Message from Paul Hoffman of "Fri, 10 Feb 2006 06:52:33 PST." References: <5FDB6BFF8B21BF198FE507BA@B50854F0A9192E8EC6CDA126> X-Mailer: MH-E 7.82; nmh 1.1; XEmacs 21.4 (patch 17) Date: Fri, 10 Feb 2006 20:18:04 -0500 Message-ID: <3028.1139620684@sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Score: -2.464 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.563847 cc: iesg@ietf.org cc: Sam Hartman cc: Harald Tveit Alvestrand cc: newtrk@lists.uoregon.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: Sat, 11 Feb 2006 01:19:09 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Speaking from an IPsec point of view: - the majority of IPsec vendors are selling VPN. - few of us even have host implementations on which another protocol could really use our security service. (This in itself is very sad) - so, there is almost no market push for IPsec vendors to take a further interest in the process. None of *our* customers would care. Now, the vendors who do have host integrated implementations: KAME/BSD, Solaris, Linux and Microsoft, might be persuaded to care, but in most cases the upper layer protocols that want IPsec are still not part of our portfolio. Which documents are waiting on IPsec to go to PS? For which vendors is this a *market* problem for them? - -- ] 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.4.1 (GNU/Linux) Comment: Finger me for keys iQEVAwUBQ+07S4CLcPvd0N1lAQKGbAf/aY4X0TrYLgkM7qB5Bwe86JOvXAAVMCOb mqCNpVSPALHjF5vESshrFyad++CYraEe998ya5SwmRq0n2RDzOFb3pC+Vkj03tF2 UibgsZxGR7dmL8jw1eGMJKmIURdEUOhSoMvuegjm4xdLTRgRaJOguOUvFURNejkj 1q3ajzJFpfuFZpfR4bvubHyFOyYJ3ASfmQIstiIdOGbpzb+3VhZXLKAL+XbShptC Zs4dg3ydMHop8gLykJ0+RkWVxUaHrvYhs4mp/wtqGBdGe0CmXr6aaR2ifLHO34oM JIrbemREYbBU0JPgkY+iDWtZh5fNmePp6OieSLEr6OgKtoqvN5S0HA== =9kAw -----END PGP SIGNATURE----- From hartmans@MIT.EDU Fri Feb 10 21:47:38 2006 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 k1B2lbsL015747 for ; Fri, 10 Feb 2006 21:47:37 -0500 (EST) Received: from carter-zimmerman.mit.edu (STRATTON-THREE-EIGHTY-ONE.MIT.EDU [18.187.6.126])k1B2lT6f015400 for ; Fri, 10 Feb 2006 21:47:29 -0500 (EST) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 94731E0053; Fri, 10 Feb 2006 21:47:24 -0500 (EST) To: RJ Atkinson Subject: Re: [saag] BCP 61, advancing to draft References: <0E2B3591-EF88-4D92-BE57-4C0F0C866CC5@extremenetworks.com> From: Sam Hartman Date: Fri, 10 Feb 2006 21:47:24 -0500 In-Reply-To: (RJ Atkinson's message of "Fri, 10 Feb 2006 18:37:18 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 1.217 X-Spam-Level: * (1.217) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.543302 cc: iesg@ietf.org cc: newtrk@lists.uoregon.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: Sat, 11 Feb 2006 02:47:38 -0000 >>>>> "RJ" == RJ Atkinson writes: RJ> Given the note at the start of today which started this RJ> thread, it seems wisest to keep ESP/AH (and the applications RJ> that depend on them -- and probably the IPsec Arch document) RJ> de-coupled from ISAKMP/IKE for advancement purposes. RJ> There is a clear trade-off between being practical about RJ> solving current issues versus being dogmatic about the ideal RJ> policy one might prefer in an ideal world. That trade-off is RJ> something that the powers that be need to sort out among RJ> themselves. I think the community (and the leadership) have spoken on this issue. I think we said that we all believe that automated key management is really important from a technical standpoint. I'd much rather have proposed standards that have automated key management than draft standards that assume people will use manual keying. --Sam From rja@extremenetworks.com Sat Feb 11 09:04:07 2006 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 k1BE41sL018951 for ; Sat, 11 Feb 2006 09:04:06 -0500 (EST) Received: from eastrmmtao01.cox.net (eastrmmtao01.cox.net [68.230.240.38]) k1BE3pON027132; Sat, 11 Feb 2006 09:03:52 -0500 (EST) Received: from [10.30.20.240] (really [70.174.17.170]) by eastrmmtao01.cox.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20060211140353.LASO4894.eastrmmtao01.cox.net@[10.30.20.240]>; Sat, 11 Feb 2006 09:03:53 -0500 In-Reply-To: References: <0E2B3591-EF88-4D92-BE57-4C0F0C866CC5@extremenetworks.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <689D91A2-BC65-47A2-BAD9-E2403DCE253D@extremenetworks.com> Content-Transfer-Encoding: 7bit From: RJ Atkinson Subject: Re: [saag] BCP 61, advancing to draft Date: Sat, 11 Feb 2006 09:03:49 -0500 To: Sam Hartman X-Mailer: Apple Mail (2.746.2) X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.608512 cc: iesg@ietf.org cc: newtrk@lists.uoregon.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: Sat, 11 Feb 2006 14:04:07 -0000 On 10 Feb 2006, at 21:47, Sam Hartman wrote: > I think the community (and the leadership) have spoken on this issue. > I think we said that we all believe that automated key management is > really important from a technical standpoint. > > I'd much rather have proposed standards that have automated key > management than draft standards that assume people will use manual > keying. You can have draft standards with automated key management. It only requires advancing IKEv1 separately from (in parallel with) IKEv2. If you'd like to do that but think the current rules don't allow, then lets have a discussion about fixing the rules. IKEv1 isn't going away anytime soon from the deployed world, simply because it will take a while (probably years, if history holds true) before there are multiple IKEv2 implementations that can talk with each other, regardless of what the IETF does. It took IKEv1 some number of years to reach that state, despite active interoperability testing throughout that period. So such a modest step as advancing the 2 versions of IKE in parallel is not harming deployed security at all. It is a choice that the IESG gets to make. The bottom line is in your last paragraph, which basically says that you are comfortable having a lot of application protocols stuck at PS for a while, possibly years. If that is true, why should ordinary IETF participants feel much incentive to progress anything beyond PS ? I'm not upset with anyone or any group, but I am greatly confused by the thread of the past day or so. Cheers, Ran PS: Not speaking for my employer, but one of the observations from when I've occasionally been an end-user (ISP or other end user) is that the market need is for a stable openly published specification and for interoperability. The market does not care a great deal whether something is PS, DS, FS, or Informational. PPS: What Michael Richardson says, echos my PS just above, and sadly enough, has been true of the IPsec WG for almost 10 years now. From paul.hoffman@vpnc.org Sat Feb 11 10:15:58 2006 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 k1BFFvsL019335 for ; Sat, 11 Feb 2006 10:15:57 -0500 (EST) Received: from above.proper.com (above.proper.com [208.184.76.39]) k1BFFrON020097; Sat, 11 Feb 2006 10:15:54 -0500 (EST) Received: from [10.20.30.249] (dsl2-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id k1BFFhkE047289; Sat, 11 Feb 2006 07:15:44 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <689D91A2-BC65-47A2-BAD9-E2403DCE253D@extremenetworks.com> References: <0E2B3591-EF88-4D92-BE57-4C0F0C866CC5@extremenetworks.com> <689D91A2-BC65-47A2-BAD9-E2403DCE253D@extremenetworks.com> Date: Sat, 11 Feb 2006 07:15:21 -0800 To: RJ Atkinson , Sam Hartman From: Paul Hoffman Subject: Re: [saag] BCP 61, advancing to draft Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.552061 cc: iesg@ietf.org cc: newtrk@lists.uoregon.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: Sat, 11 Feb 2006 15:15:58 -0000 At 9:03 AM -0500 2/11/06, RJ Atkinson wrote: >You can have draft standards with automated key management. >It only requires advancing IKEv1 separately from (in parallel with) >IKEv2. That "only" assumes that there is interest in doing the work of testing every SHOULD and MUST; so far, there has not been. The "only" also assumes that there are multiple interoperable implementations of every SHOULD and MUST, which there is not. >It is a choice that the IESG gets to make. No, it is a choice that the IPsec community gets to make. In the over seven years since IKEv1 has been around, there has not been interest in testing for the purpose of advancing the category of the protocol. >The bottom line is in your last paragraph, which basically says >that you are comfortable having a lot of application protocols >stuck at PS for a while, possibly years. I read it differently: the IETF is willing to accept that some protocols will never advance in status because they rely on other protocols which will never advance in status. I don't see a lot of "comfort" there. --Paul Hoffman, Director --VPN Consortium From hartmans@MIT.EDU Sat Feb 11 13:34:30 2006 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 k1BIYTsL020315 for ; Sat, 11 Feb 2006 13:34:29 -0500 (EST) Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178])k1BIYQ8G014666 for ; Sat, 11 Feb 2006 13:34:27 -0500 (EST) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 7524AE0053; Sat, 11 Feb 2006 13:34:21 -0500 (EST) To: Paul Hoffman Subject: Re: [saag] BCP 61, advancing to draft References: <0E2B3591-EF88-4D92-BE57-4C0F0C866CC5@extremenetworks.com> <689D91A2-BC65-47A2-BAD9-E2403DCE253D@extremenetworks.com> From: Sam Hartman Date: Sat, 11 Feb 2006 13:34:21 -0500 In-Reply-To: (Paul Hoffman's message of "Sat, 11 Feb 2006 07:15:21 -0800") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 1.352 X-Spam-Level: * (1.352) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.525958 cc: iesg@ietf.org cc: RJ Atkinson cc: newtrk@lists.uoregon.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: Sat, 11 Feb 2006 18:34:30 -0000 >>>>> "Paul" == Paul Hoffman writes: Paul> That "only" assumes that there is interest in doing the work Paul> of testing every SHOULD and MUST; so far, there has not Paul> been. The "only" also assumes that there are multiple Paul> interoperable implementations of every SHOULD and MUST, Paul> which there is not. Testing every should and must is not required. You need to test every protocol feature. That is a simpler task. However I suspect there still is not interest in doing that. --Sam From pekkas@netcore.fi Sun Feb 12 10:46:30 2006 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 k1CFkTsL026241 for ; Sun, 12 Feb 2006 10:46:29 -0500 (EST) Received: from netcore.fi (netcore.fi [193.94.160.1])k1CFkL8R001629; Sun, 12 Feb 2006 10:46:22 -0500 (EST) Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.12.8/8.12.8) with ESMTP id k1CFk2Ha009276; Sun, 12 Feb 2006 17:46:02 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.8/8.12.8/Submit) with ESMTP id k1CFjseq009261; Sun, 12 Feb 2006 17:45:55 +0200 Date: Sun, 12 Feb 2006 17:45:54 +0200 (EET) From: Pekka Savola To: Sam Hartman In-Reply-To: Message-ID: References: <689D91A2-BC65-47A2-BAD9-E2403DCE253D@extremenetworks.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88/1283/Thu Feb 9 22:55:06 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-3.5 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on otso.netcore.fi X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.610140 cc: Paul Hoffman cc: iesg@ietf.org cc: RJ Atkinson cc: newtrk@lists.uoregon.edu cc: saag@mit.edu Subject: [saag] definition of 'feature'; reasons to advance 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, 12 Feb 2006 15:46:30 -0000 On Sat, 11 Feb 2006, Sam Hartman wrote: >>>>>> "Paul" == Paul Hoffman writes: > > Paul> That "only" assumes that there is interest in doing the work > Paul> of testing every SHOULD and MUST; so far, there has not > Paul> been. The "only" also assumes that there are multiple > Paul> interoperable implementations of every SHOULD and MUST, > Paul> which there is not. > > Testing every should and must is not required. You need to test every > protocol feature. Depends on what you call a 'feature'. For example, a protocol might have a MUST discard clause for certain malformed, insecure or spoofed packets. If an implementation under testing does not implement that MUST, the outcome of the testing might be unspecified and we don't really know how compliant implementations would perform. Testing SHOULDs have similar, but slightly different implications: two compliant implementations might (but where at least one doesn't implement a SHOULD) not be enough to know if all the acceptable combinations would work. I think the main issue here the motivation for pushing specs along on the standards track. If we do it to demonstrate that the spec is known to interoperate under rigorous testing and be relevant to be implemented in its entirety, detailed reports could be very useful. If the motivation is to just obtain a status level and/or allow normative referencing by other specs, it is not so useful. With the current 3-level standards track and downref rules, I'd propose that Draft Standards should not require very detailed implementation reports, but that getting to Full Standard should. If we eliminate one step and/or remove downref rules, I'd vote for requiring sufficiently detailed interoperability and implementation reports. -- 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 jas@extundo.com Fri Feb 10 09:56:38 2006 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 k1AEubsL010976 for ; Fri, 10 Feb 2006 09:56:37 -0500 (EST) Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178])k1AEuSZe024990 for ; Fri, 10 Feb 2006 09:56:29 -0500 (EST) Received: from latte.josefsson.org (jas@yxa.extundo.com [217.13.230.178]) (authenticated bits=0)k1AEu2u9027180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Feb 2006 15:56:02 +0100 From: Simon Josefsson To: pgut001@cs.auckland.ac.nz (Peter Gutmann) References: <7DBC3359-383A-4A2B-BF37-8D9A63DA4526@extremenetworks.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:060210:rja@extremenetworks.com::BVSKOVen/igG+Oge:q0e X-Hashcash: 1:21:060210:newtrk@lists.uoregon.edu::VJjTfhuDoD+gafBL:02SN X-Hashcash: 1:21:060210:iesg@ietf.org::36uWFhv8FQQOygdC:29a2 X-Hashcash: 1:21:060210:saag@mit.edu::JZTCsHHBf+Gb0MF/:AHsr X-Hashcash: 1:21:060210:pgut001@cs.auckland.ac.nz::7sGnQKDLJ+ddF4X2:Rzhn Date: Fri, 10 Feb 2006 15:56:01 +0100 In-Reply-To: (Peter Gutmann's message of "Sat, 11 Feb 2006 02:33:24 +1300") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on yxa-iv X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean X-Spam-Score: -2.464 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.604900 X-Mailman-Approved-At: Sun, 12 Feb 2006 14:54:26 -0500 cc: iesg@ietf.org cc: rja@extremenetworks.com cc: newtrk@lists.uoregon.edu cc: saag@mit.edu Subject: [saag] Re: BCP 61, advancing to draft 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, 10 Feb 2006 14:56:39 -0000 pgut001@cs.auckland.ac.nz (Peter Gutmann) writes: > RJ Atkinson writes: >>> PKIX: I think has some internationalization issues; possibly some hash >>> fun. Not really sure. >>> >>> CMS: Unsure. Wouldn't surprise me if besides PKIX dependencies this >>> was in the best shape. >> >>These also don't look like low-hanging fruit. >> >>I think TLS is probably the lowest hanging fruit here. IPsec, Kerberos, and >>SASL come next in a clump. GSS-API, PKIX, and CMS seem pretty high up the >>tree just now. > > And that's the problem - CMS and TLS are both blocked waiting on PKIX (this is > what held up TLS at the RFC 2246 stage for what, three years?). Presumably > IPsec will also block on PKIX. This is why I proposed the relative- rather > than absolute-value reference approach in my previous message. Without this, > you get the priority-inversion situation of the lowest-hanging fruit stalled > behind the highest-hanging fruit (not to mention appallingly mangled > metaphors). I don't think PKIX should be critical for TLS. Look at TLS-PSK, TLS-SRP and TLS-OpenPGP. Decoupling TLS from PKIX fully would be a good idea. It would also help non-PKIX TLS mechanisms, which is also good. OTOH, to abolish draft seem like a better approach to me. The market doesn't seem to care if a document is at proposed or draft. The technical quality isn't better at higher standards level either. Just look at DNS. The only people who seem to care about this separation is long time IETF attendees, but they seem to have few instruments available to apply pressure on others to write standards. To make somebody write a standard, there should be some incentive or at least some good reason for doing the work. It is not a compelling reason to ask "Well, don't you want this document as Draft?". I'm not sure I see any real reason for spending the time on moving, say, IPSEC from proposed to draft. For most organizations, it seems the time is better spent on improving implementations (which will result in improvements to the standard too, eventually). Thanks, Simon From tony@att.com Sat Feb 11 01:14:45 2006 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 k1B6EisL016863 for ; Sat, 11 Feb 2006 01:14:44 -0500 (EST) Received: from mail126.messagelabs.com (mail126.messagelabs.com [216.82.250.99])k1B6EZJw019279 for ; Sat, 11 Feb 2006 01:14:36 -0500 (EST) X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-15.tower-126.messagelabs.com!1139638475!9295127!1 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 12750 invoked from network); 11 Feb 2006 06:14:35 -0000 Received: from unknown (HELO maillennium.att.com) (134.24.146.4) by server-15.tower-126.messagelabs.com with SMTP; 11 Feb 2006 06:14:35 -0000 Received: from [135.70.102.74] (unknown[135.70.102.74](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20060211061434gw1001004je> (Authid: tony); Sat, 11 Feb 2006 06:14:34 +0000 Message-ID: <43ED80C7.9010608@att.com> Date: Sat, 11 Feb 2006 01:14:31 -0500 From: Tony Hansen User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: newtrk@lists.uoregon.edu, saag@mit.edu, iesg@ietf.org Subject: Re: [newtrk] Re: [saag] BCP 61, advancing to draft References: <5FDB6BFF8B21BF198FE507BA@B50854F0A9192E8EC6CDA126> In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.543974 X-Mailman-Approved-At: Sun, 12 Feb 2006 14:54:26 -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: Sat, 11 Feb 2006 06:14:45 -0000 Is it time to move beyond volunteers? Perhaps we need to ask some organization (ISOC? IGB? ????) if they would be willing to support an effort to do the interop testing? Tony Hansen tony@att.com Paul Hoffman wrote: > One big issue we have with security protocols moving to draft is that > there is very little volunteer interest in testing SHOULD/MUST > interop beyond the basics (if even that). Our protocols have a lot of > SHOULDs that have nothing to do with interop and are very difficult > to test. But, even without those, the security area has been much > less active at voluntary interop testing than other areas, which > makes "going to Draft" not appealing. We are generally happy to cycle > at Proposed. Sam's message points out a significant ramification of > that attitude, although I don't have a proposed solution to the > problem. From touch@ISI.EDU Sat Feb 11 17:02:42 2006 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 k1BM2fsL021549 for ; Sat, 11 Feb 2006 17:02:41 -0500 (EST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) k1BM2UE6006891; Sat, 11 Feb 2006 17:02:31 -0500 (EST) Received: from [128.9.176.130] (ras30.isi.edu [128.9.176.130]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k1BM1iq06185; Sat, 11 Feb 2006 14:01:44 -0800 (PST) Message-ID: <43EE5EC1.9080007@isi.edu> Date: Sat, 11 Feb 2006 14:01:37 -0800 From: Joe Touch User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Sam Hartman Subject: Re: [newtrk] Re: [saag] BCP 61, advancing to draft References: <0E2B3591-EF88-4D92-BE57-4C0F0C866CC5@extremenetworks.com> <689D91A2-BC65-47A2-BAD9-E2403DCE253D@extremenetworks.com> In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCC9D7DD12C82FD099A3A1735" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.558696 X-Mailman-Approved-At: Sun, 12 Feb 2006 14:54:26 -0500 cc: iesg@ietf.org cc: Paul Hoffman cc: RJ Atkinson cc: newtrk@lists.uoregon.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: Sat, 11 Feb 2006 22:02:42 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCC9D7DD12C82FD099A3A1735 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sam Hartman wrote: >>>>>> "Paul" =3D=3D Paul Hoffman writes: >=20 > Paul> That "only" assumes that there is interest in doing the work > Paul> of testing every SHOULD and MUST; so far, there has not > Paul> been. The "only" also assumes that there are multiple > Paul> interoperable implementations of every SHOULD and MUST, > Paul> which there is not. >=20 > Testing every should and must is not required. That seems odd; what is sufficient protocol testing if not to validate the MUST and MUST NOTs? Joe --------------enigCC9D7DD12C82FD099A3A1735 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFD7l7BE5f5cImnZrsRAn/OAJ9KCvfMFIC4SVj7PZe7QLSi9TtDlQCgnZmz IqVv1Zf1IoZEYUzXnCwUFlk= =Qa3h -----END PGP SIGNATURE----- --------------enigCC9D7DD12C82FD099A3A1735-- From LMM@acm.org Sun Feb 12 20:58:07 2006 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 k1D1w6sL029589 for ; Sun, 12 Feb 2006 20:58:06 -0500 (EST) Received: from exprod6og12.obsmtp.com (exprod6og12.obsmtp.com [64.18.1.24]) k1D1vwuR019450; Sun, 12 Feb 2006 20:57:58 -0500 (EST) Received: from source ([192.150.20.142]) by exprod6ob12.obsmtp.com ([64.18.5.12]) with SMTP; Sun, 12 Feb 2006 17:57:57 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) k1D1vv46024358; Sun, 12 Feb 2006 17:57:57 -0800 (PST) Received: from calsj-dev (calsj-dev.corp.adobe.com [153.32.1.193]) k1D1vprs010189; Sun, 12 Feb 2006 17:57:51 -0800 (PST) Received: from calsj-dev (localhost [127.0.0.1]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IUL00NXTS4E1L@mailsj-v1.corp.adobe.com>; Sun, 12 Feb 2006 17:57:50 -0800 (PST) Received: from MasinterT43p ([10.7.241.41]) by mailsj-v1.corp.adobe.com (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IUL0030RS4DZB@mailsj-v1.corp.adobe.com>; Sun, 12 Feb 2006 17:57:50 -0800 (PST) Date: Sun, 12 Feb 2006 17:57:23 -0800 From: Larry Masinter In-reply-to: To: "'Pekka Savola'" , "'Sam Hartman'" Message-id: <000d01c63040$d54ef6c0$29f1070a@corp.adobe.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcYv7fPCkrEzS48tQ8GUTl8G6G+BPAAUoCJg X-Spam-Score: 0 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.586846 X-Mailman-Approved-At: Sun, 12 Feb 2006 21:20:12 -0500 cc: 'Paul Hoffman' cc: iesg@ietf.org cc: 'RJ Atkinson' cc: newtrk@lists.uoregon.edu cc: saag@mit.edu Subject: [saag] RE: [newtrk] definition of 'feature'; reasons to advance 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 Feb 2006 01:58:08 -0000 > > Testing every should and must is not required. You need to test every > > protocol feature. > > Depends on what you call a 'feature'. For example, a protocol might > have a MUST discard clause for certain malformed, insecure or spoofed > packets. If an implementation under testing does not implement that > MUST, the outcome of the testing might be unspecified and we don't > really know how compliant implementations would perform. Testing > SHOULDs have similar, but slightly different implications: two > compliant implementations might (but where at least one doesn't > implement a SHOULD) not be enough to know if all the acceptable > combinations would work. http://www.ietf.org/internet-drafts/draft-ietf-newtrk-interop-reports-00.txt proposes creating a separate Protocol Feature Set which identifies what constitutes the "features" for a protocol. It is consistent with one-step or two-step or three-step, and might even be a way of migrating gradually between those. Larry From pgut001@cs.auckland.ac.nz Mon Feb 13 03:08:45 2006 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 k1D88hsL001690 for ; Mon, 13 Feb 2006 03:08:43 -0500 (EST) Received: from zeppo.itss.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.190.14])k1D88Wqr006992 for ; Mon, 13 Feb 2006 03:08:33 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by zeppo.itss.auckland.ac.nz (Postfix) with ESMTP id C001E33E7A; Mon, 13 Feb 2006 21:08:31 +1300 (NZDT) Received: from zeppo.itss.auckland.ac.nz ([127.0.0.1])port 10024) with ESMTP id 28725-04; Mon, 13 Feb 2006 21:08:31 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by zeppo.itss.auckland.ac.nz (Postfix) with ESMTP id 37F203414D; Mon, 13 Feb 2006 21:08:29 +1300 (NZDT) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 85DAA3774B; Mon, 13 Feb 2006 21:08:29 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1F8YlA-0001BN-00; Mon, 13 Feb 2006 21:08:36 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: jas@extundo.com, pgut001@cs.auckland.ac.nz In-Reply-To: Message-Id: Sender: pgut001 Date: Mon, 13 Feb 2006 21:08:36 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.550283 cc: iesg@ietf.org cc: rja@extremenetworks.com cc: newtrk@lists.uoregon.edu cc: saag@mit.edu Subject: [saag] Re: BCP 61, advancing to draft 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 Feb 2006 08:08:45 -0000 Simon Josefsson writes: >I don't think PKIX should be critical for TLS. Look at TLS-PSK, TLS-SRP and >TLS-OpenPGP. All of those combined are buried in the noise floor compared to use of certificates with TLS: TLS-PSK: Really only accepted as something for low-powered devices (although I disagree with this use). TLS-SRP: Amost never used due to patent concerns. TLS-PGP: Never used (or at least there's probably some experimental implementation somewhere, but I'm not aware of it). >Decoupling TLS from PKIX fully would be a good idea. It would also help non- >PKIX TLS mechanisms, which is also good. I think it'd be a good idea too, but it'll never happen in practice. You'd have to convince several million web sites with several hundred million dollars tied up in infrastructure to change, which is never going to happen. Currently every one of them will still do SSLv3 at the drop of a handshake option, which wasn't even an RFC, let alone a standards-track one. Peter. From jas@extundo.com Mon Feb 13 04:20:23 2006 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 k1D9KMsL002169 for ; Mon, 13 Feb 2006 04:20:22 -0500 (EST) Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178])k1D9KDqr018259 for ; Mon, 13 Feb 2006 04:20:14 -0500 (EST) Received: from latte.josefsson.org (jas@yxa.extundo.com [217.13.230.178]) (authenticated bits=0)k1D9JiU9002240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Feb 2006 10:19:44 +0100 From: Simon Josefsson To: pgut001@cs.auckland.ac.nz (Peter Gutmann) References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:060213:saag@mit.edu::Eg3b8VvLfP5lGDsv:bWP X-Hashcash: 1:21:060213:pgut001@cs.auckland.ac.nz::jIWk9aMCIbFynFhz:11vk X-Hashcash: 1:21:060213:iesg@ietf.org::sjd6+DU544RM6tr1:8ZPA X-Hashcash: 1:21:060213:newtrk@lists.uoregon.edu::eL4h/QeLUJ5TbZeA:6a8o X-Hashcash: 1:21:060213:rja@extremenetworks.com::wMM4hbKX1lSxVrP+:JwH/ Date: Mon, 13 Feb 2006 10:19:41 +0100 In-Reply-To: (Peter Gutmann's message of "Mon, 13 Feb 2006 21:08:36 +1300") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on yxa-iv X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean X-Spam-Score: -2.464 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.564714 cc: iesg@ietf.org cc: rja@extremenetworks.com cc: newtrk@lists.uoregon.edu cc: saag@mit.edu Subject: [saag] Re: BCP 61, advancing to draft 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 Feb 2006 09:20:24 -0000 pgut001@cs.auckland.ac.nz (Peter Gutmann) writes: >>Decoupling TLS from PKIX fully would be a good idea. It would also help non- >>PKIX TLS mechanisms, which is also good. > > I think it'd be a good idea too, but it'll never happen in practice. You'd > have to convince several million web sites with several hundred million > dollars tied up in infrastructure to change, which is never going to happen. > Currently every one of them will still do SSLv3 at the drop of a handshake > option, which wasn't even an RFC, let alone a standards-track one. I don't see how that is related to having TLS depend normatively or informatively on PKIX. The TLS protocol can be decoupled from the certificate types used. I agree that it would be a lot of work to replace the PKIX language in the TLS spec with something more abstract, that would map to PKIX or other certificate structures, but it seems possible to me. However, the benefits (i.e., having TLS at Draft) of doing all that work (rewriting the TLS spec) seem small. It seems better to me to relax how documents at Draft can reference documents at Proposed, and even to abolish Draft. Thanks, Simon From pgut001@cs.auckland.ac.nz Mon Feb 13 04:48:40 2006 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 k1D9mdsL002390 for ; Mon, 13 Feb 2006 04:48:39 -0500 (EST) Received: from zeppo.itss.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.190.14])k1D9mTkn012352 for ; Mon, 13 Feb 2006 04:48:30 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by zeppo.itss.auckland.ac.nz (Postfix) with ESMTP id 7ED9E346A9; Mon, 13 Feb 2006 22:48:28 +1300 (NZDT) Received: from zeppo.itss.auckland.ac.nz ([127.0.0.1])port 10024) with ESMTP id 27608-12; Mon, 13 Feb 2006 22:48:28 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by zeppo.itss.auckland.ac.nz (Postfix) with ESMTP id DC4F83459F; Mon, 13 Feb 2006 22:48:27 +1300 (NZDT) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 8FE783774B; Mon, 13 Feb 2006 22:48:27 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1F8aJv-0001IX-00; Mon, 13 Feb 2006 22:48:35 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: jas@extundo.com, pgut001@cs.auckland.ac.nz In-Reply-To: Message-Id: Sender: pgut001 Date: Mon, 13 Feb 2006 22:48:35 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.561025 cc: iesg@ietf.org cc: rja@extremenetworks.com cc: newtrk@lists.uoregon.edu cc: saag@mit.edu Subject: [saag] Re: BCP 61, advancing to draft 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 Feb 2006 09:48:40 -0000 Simon Josefsson writes: >pgut001@cs.auckland.ac.nz (Peter Gutmann) writes: >>>Decoupling TLS from PKIX fully would be a good idea. It would also help non- >>>PKIX TLS mechanisms, which is also good. >> >> I think it'd be a good idea too, but it'll never happen in practice. You'd >> have to convince several million web sites with several hundred million >> dollars tied up in infrastructure to change, which is never going to happen. >> Currently every one of them will still do SSLv3 at the drop of a handshake >> option, which wasn't even an RFC, let alone a standards-track one. > >I don't see how that is related to having TLS depend normatively or >informatively on PKIX. The TLS protocol can be decoupled from the >certificate types used. How? TLS, at least as used with HTTP (which is probably about 99% of it use) is synonymous with X.509 PKI. By "decouple" do you mean replace the current explicit use of X.509 certs with generic language describing an abstract certificate type, and then assume that everyone knows that the abstract certificate type is actually meant to be X.509 even though it's not made explicit? (Incidentally, you run into additional problems with TLS extensions, which reference a pile of X.509 cert mechanisms). Peter. From jas@extundo.com Mon Feb 13 05:36:53 2006 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 k1DAapsL002773 for ; Mon, 13 Feb 2006 05:36:52 -0500 (EST) Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178])k1DAaZkn014606 for ; Mon, 13 Feb 2006 05:36:36 -0500 (EST) Received: from latte.josefsson.org (jas@yxa.extundo.com [217.13.230.178]) (authenticated bits=0)k1DAaCNg012355 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Feb 2006 11:36:12 +0100 From: Simon Josefsson To: pgut001@cs.auckland.ac.nz (Peter Gutmann) References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:21:060213:saag@mit.edu::iSMpUpasYxaDpdfp:4mtw X-Hashcash: 1:21:060213:iesg@ietf.org::lnPPtscKtGMXoB1V:DHpG X-Hashcash: 1:21:060213:newtrk@lists.uoregon.edu::FzPags4hAOetnV+6:9QFd X-Hashcash: 1:21:060213:pgut001@cs.auckland.ac.nz::nviPb47BXyTlyHgD:D/gW X-Hashcash: 1:21:060213:rja@extremenetworks.com::WMQpdjlzxHiScGRh:WUHv Date: Mon, 13 Feb 2006 11:36:09 +0100 In-Reply-To: (Peter Gutmann's message of "Mon, 13 Feb 2006 22:48:35 +1300") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on yxa-iv X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on yxa.extundo.com X-Virus-Status: Clean X-Spam-Score: -2.464 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.605687 cc: iesg@ietf.org cc: rja@extremenetworks.com cc: newtrk@lists.uoregon.edu cc: saag@mit.edu Subject: [saag] Re: BCP 61, advancing to draft 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 Feb 2006 10:36:53 -0000 pgut001@cs.auckland.ac.nz (Peter Gutmann) writes: > Simon Josefsson writes: >>pgut001@cs.auckland.ac.nz (Peter Gutmann) writes: >>>>Decoupling TLS from PKIX fully would be a good idea. It would also help non- >>>>PKIX TLS mechanisms, which is also good. >>> >>> I think it'd be a good idea too, but it'll never happen in practice. You'd >>> have to convince several million web sites with several hundred million >>> dollars tied up in infrastructure to change, which is never going to happen. >>> Currently every one of them will still do SSLv3 at the drop of a handshake >>> option, which wasn't even an RFC, let alone a standards-track one. >> >>I don't see how that is related to having TLS depend normatively or >>informatively on PKIX. The TLS protocol can be decoupled from the >>certificate types used. > > How? TLS, at least as used with HTTP (which is probably about 99% of it use) > is synonymous with X.509 PKI. By "decouple" do you mean replace the current > explicit use of X.509 certs with generic language describing an abstract > certificate type, and then assume that everyone knows that the abstract > certificate type is actually meant to be X.509 even though it's not made > explicit? Yes, something like that. You could provide a "PKIX-profile for TLS" that would describe how to translate the TLS generic language into PKIX matters. TLS would then be able to be at Draft level, and the PKIX-to-TLS document staying at Proposed until PKIX moves to Draft. Implementations would not be affected, and TLS could move to Draft. > (Incidentally, you run into additional problems with TLS extensions, which > reference a pile of X.509 cert mechanisms). TLS extensions could stay at Proposed, or use a similar profile-based mechanism. Again, I'd much rather abolish Draft than to follow my approach. My approach is a lot of work, that may hide complicated problems in bureaucratic sounding text. I'd much rather design documents based around technical problems rather than around process issues within the IETF. Thanks, Simon From jari.arkko@piuha.net Mon Feb 13 06:52:01 2006 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 k1DBq0sL003387 for ; Mon, 13 Feb 2006 06:52:00 -0500 (EST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) k1DBpokn003392; Mon, 13 Feb 2006 06:51:51 -0500 (EST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id B766B89932; Mon, 13 Feb 2006 13:51:49 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 50A0089852; Mon, 13 Feb 2006 13:51:49 +0200 (EET) Message-ID: <43F072EB.60200@piuha.net> Date: Mon, 13 Feb 2006 13:52:11 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Hartman Subject: Re: [saag] BCP 61, advancing to draft References: <0E2B3591-EF88-4D92-BE57-4C0F0C866CC5@extremenetworks.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.539942 cc: iesg@ietf.org cc: RJ Atkinson cc: newtrk@lists.uoregon.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, 13 Feb 2006 11:52:02 -0000 Sam Hartman wrote: >However BCP 107 argues that there should be few applications for which >ESP/AH is appropriate without automated key management. > > Yes. But that need not stop us from advancing ESP/AH/Arch. We get those to Draft, we are half way done. Yes, we'd still have a problem with a spec at Draft employing them since it would also need to reference the key management protocol, but the key to progress is to take the first step... >I'd much rather have proposed standards that have automated key >management than draft standards that assume people will use manual >keying. > > Sure. But just advancing some of our specs to Draft does not mean that we give up on requiring the use of others. --Jari From jari.arkko@piuha.net Mon Feb 13 07:32:29 2006 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 k1DCWSsL003698 for ; Mon, 13 Feb 2006 07:32:28 -0500 (EST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) k1DCWLp1023065; Mon, 13 Feb 2006 07:32:21 -0500 (EST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 9485D89932; Mon, 13 Feb 2006 14:32:20 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 2E8EF89852; Mon, 13 Feb 2006 14:32:20 +0200 (EET) Message-ID: <43F07C6A.5010807@piuha.net> Date: Mon, 13 Feb 2006 14:32:42 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Hartman Subject: Re: [saag] BCP 61, advancing to draft References: <0E2B3591-EF88-4D92-BE57-4C0F0C866CC5@extremenetworks.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.662310 cc: iesg@ietf.org cc: newtrk@lists.uoregon.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, 13 Feb 2006 12:32:29 -0000 Thank you Sam for raising this issue. I think it is an important issue, and its not merely a process nuisance*. The main question to me is "Why aren't we updating our specs frequently enough?" Its not only about the status designation in the RFCs, it also about real-world things such as fixing bugs, adding clarifications, removing bloat^H^H^H^H^H features that no one turned out to implement, updating mandatory algorithm lists to whatever is appropriate at the time, and looking after the true interoperability of our specifications. And I do think we need to improve. Before jumping to a particular solution maybe its useful to think a little bit about the root causes that have led to the situation. I'm thinking mostly from the SEC perspective, other areas may be different. o References to common components and formats. These need to progress first before the referring spec can progress. I don't think there is a lot we can or should do about this, other than remembering to progress that referred component. Having components is good. Sometimes you can use general language to avoid a reference problem. o Desire to address a number of issues in one go. For instance, produce a "bis" revision along with adding features 1, 2, and 3. I would suggest a stepwise approach would be better. Take small steps, but take them often. As an example, a bad algorithm could be replaced by a timely published "bis" version, if we didn't need to incorporate everyone's all possible changes and new features at the same time. (And by the time you are done with the all the changes there will be new issues to address.) o Lack of editor and other participant resources for the work. I suspect timely completion of spec revisions has an impact on the availability of people to do the work. For instance, if you make a small update this will likely complete faster, giving you more willing editor candidates. And you can hire junior editors because the scope of the changes is not that big. o Lack of interoperability testing of all features. If this situation persists, I don't think its just a question about interop events or even funding. Its a more fundamental issue about specs matching the needs of the world. Personally, I like small base specs accompanied with a number of optional extensions. They are a bit harder to read, but the tradeoff wrt publication speed is well worth it. Then some specific thoughts about what we can do now. I wonder if we could attempt to progress AH/ESP/Arch to Draft. The main problem appears to be the architecture RFC which has a long list of normative references. I'm not sure though that all those references really need to be normative, e.g., both IKEv1 and IKEv2. I would also suggest pursuing the IKEv2 clarifications (is the result a "bis"?) work as soon as possible, and not adding new features during that process. For TLS... I don't know. Maybe the general language helps avoid the PKIX reference. --Jari *) There is a process question as well, namely the fate of the three-step process. Personally, I think two steps would be better, but for the most part, it doesn't matter because we already have the ability to either use or ignore the steps beyond Proposed. From hartmans@MIT.EDU Mon Feb 13 10:46:32 2006 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 k1DFkVsL004942 for ; Mon, 13 Feb 2006 10:46:31 -0500 (EST) Received: from carter-zimmerman.mit.edu (carter-zimmerman.dyn.mit.edu [18.188.3.148])k1DFkPQr014729 for ; Mon, 13 Feb 2006 10:46:26 -0500 (EST) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id D2C31E0074; Sun, 12 Feb 2006 15:20:09 -0500 (EST) To: Pekka Savola References: <0E2B3591-EF88-4D92-BE57-4C0F0C866CC5@extremenetworks.com> <689D91A2-BC65-47A2-BAD9-E2403DCE253D@extremenetworks.com> From: Sam Hartman Date: Sun, 12 Feb 2006 15:20:08 -0500 In-Reply-To: (Pekka Savola's message of "Sun, 12 Feb 2006 17:45:54 +0200 (EET)") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 1.217 X-Spam-Level: * (1.217) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.538903 cc: Paul Hoffman cc: iesg@ietf.org cc: RJ Atkinson cc: newtrk@lists.uoregon.edu cc: saag@mit.edu Subject: [saag] Re: definition of 'feature'; reasons to advance 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 Feb 2006 15:46:32 -0000 Remember the goal of the implementation report is to test the specification and make sure it is clear enough to create two interoperable implementations. We are not doing conformance testing; we are not doing interoperability testing of the implementations. We're simply trying to determine if the spec is good enough that you can create interoperable implementations from it. At least when I've asked other IESG members about this it explicitly means that you don't check error paths involving data that a conforming implementation cannot generate. Conformance testing is very useful and the kind of testing we've done can be a useful in developing conformance tests. But please let's not make the job harder than it has to be. From hartmans@MIT.EDU Mon Feb 13 10:46:36 2006 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 k1DFkZsL004949 for ; Mon, 13 Feb 2006 10:46:35 -0500 (EST) Received: from carter-zimmerman.mit.edu (carter-zimmerman.dyn.mit.edu [18.188.3.148])k1DFkPQr014731 for ; Mon, 13 Feb 2006 10:46:26 -0500 (EST) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 2BA9EE0078; Sun, 12 Feb 2006 21:42:49 -0500 (EST) To: Larry Masinter References: <000d01c63040$d54ef6c0$29f1070a@corp.adobe.com> From: Sam Hartman Date: Sun, 12 Feb 2006 21:42:49 -0500 In-Reply-To: <000d01c63040$d54ef6c0$29f1070a@corp.adobe.com> (Larry Masinter's message of "Sun, 12 Feb 2006 17:57:23 -0800") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 2.464 X-Spam-Level: ** (2.464) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.700236 cc: 'Paul Hoffman' cc: 'RJ Atkinson' cc: saag@mit.edu cc: iesg@ietf.org cc: 'Pekka Savola' cc: newtrk@lists.uoregon.edu Subject: [saag] Re: [newtrk] definition of 'feature'; reasons to advance 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 Feb 2006 15:46:37 -0000 >>>>> "Larry" == Larry Masinter writes: Larry> http://www.ietf.org/internet-drafts/draft-ietf-newtrk-interop-reports-00.txt Larry> proposes creating a separate Protocol Feature Set which Larry> identifies what constitutes the "features" for a protocol. Larry> It is consistent with one-step or two-step or three-step, Larry> and might even be a way of migrating gradually between Larry> those. As a side note, we found this analysis (based on an early draft of your work) very useful in creating a feature matrix for Kerberos. From mcr@sandelman.ottawa.on.ca Thu Feb 16 10:20:43 2006 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 k1GFKcsL003349 for ; Thu, 16 Feb 2006 10:20:42 -0500 (EST) Received: from lists.sandelman.ca (cod.sandelman.ca [192.139.46.139]) k1GFKPnL009644 for ; Thu, 16 Feb 2006 10:20:28 -0500 (EST) Received: from sandelman.ottawa.on.ca (CPE0006b123a026-CM0011aea1b6fc.cpe.net.cable.rogers.com [65.49.207.194]) by lists.sandelman.ca (8.11.6p3/8.11.6) with ESMTP id k1GFK9p29280 verified OK); Thu, 16 Feb 2006 10:20:15 -0500 (EST) Received: from sandelman.ottawa.on.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 91D8D3AD9C; Thu, 16 Feb 2006 10:20:09 -0500 (EST) To: Jari Arkko Subject: Re: [saag] BCP 61, advancing to draft In-Reply-To: Message from Jari Arkko of "Mon, 13 Feb 2006 14:32:42 +0200." <43F07C6A.5010807@piuha.net> References: <0E2B3591-EF88-4D92-BE57-4C0F0C866CC5@extremenetworks.com> <43F07C6A.5010807@piuha.net> X-Mailer: MH-E 7.82; nmh 1.1; XEmacs 21.4 (patch 17) Date: Thu, 16 Feb 2006 10:20:09 -0500 Message-ID: <19879.1140103209@sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Score: -2.464 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000000 Spam-Alum-Time: 0.621287 cc: newtrk@lists.uoregon.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: Thu, 16 Feb 2006 15:20:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Jari" == Jari Arkko writes: Jari> o Desire to address a number of issues in one go. For Jari> instance, produce a "bis" revision along with adding features Jari> 1, 2, and 3. I would suggest a stepwise approach would be Jari> better. Take small steps, but take them often. As an example, As I've said before --- we made this mistake with IKEv1->IKEv2. Jari> o Lack of editor and other participant resources for the Jari> work. I suspect timely completion of spec revisions has an Jari> impact on the availability of people to do the work. For There is another factor here -- it's hard to make a small change to an existing document because the .xml file isn't available. (Or may never have existed). And the nroff source that the rfc-editor used, won't match. Jari> o Lack of interoperability testing of all features. If this Jari> situation persists, I don't think its just a question about Jari> interop events or even funding. Its a more fundamental issue Jari> about specs matching the needs of the world. Personally, I Interop events and funding *ARE* important issues. Lots of people want open source reference implementations --- it's hard to fund this. Even if you assume the people are free (they aren't), you can't afford to attend meetings, interop events. etc. without funding. Jari> like small base specs accompanied with a number of optional Jari> extensions. They are a bit harder to read, but the tradeoff Jari> wrt publication speed is well worth it. I agree strongly. Make people plan for new features being added, rather than adding them. Mostly, we do a good job here, but not always. Jari> I would also suggest pursuing the IKEv2 clarifications (is the Jari> result a "bis"?) work as soon as possible, and not adding new Jari> features during that process. I agree. - -- ] 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.4.1 (GNU/Linux) Comment: Finger me for keys iQEVAwUBQ/SYHICLcPvd0N1lAQLPnQf/cm803pjwp8Amgo/ofy87a0jFuHHIjX2t GuiHE0E1UKFQ029C8J92GzxfYAfXdCDxS7UhuM/xnpF81+ohfXurFwq5ttjsY9Du 7Hj9Mmh60DoaPwcxZpegllm4O6RtU9s7wj2UqE2Kv49FfDkwyNkhWGwtwYoZyEIx HKv1XAuhVt+xHUi1mkZUQ08/g+lQ2a2vvIHn6J6CnyuMNc+8RNbQjbaHavH0Qs/p sB162ewqeVlzcjZpLC62K9O6ODMlifgixVamumFH5qAJLAQfQ1UTH/USNnNInSNQ f0PEtBOmZWLqGv7EK95gr/BUlC69S7XoBoRVeKgz9Det69WjnxYcTA== =9gkP -----END PGP SIGNATURE----- From housley@vigilsec.com Wed Mar 1 09:23:10 2006 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 k21EN9sL026702 for ; Wed, 1 Mar 2006 09:23:09 -0500 (EST) Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) k21EN25t027697 for ; Wed, 1 Mar 2006 09:23:02 -0500 (EST) Received: (qmail 12437 invoked by uid 0); 1 Mar 2006 14:23:00 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (71.126.156.113) by woodstock.binhost.com with SMTP; 1 Mar 2006 14:23:00 -0000 Message-Id: <7.0.0.16.2.20060227104601.04c216d0@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Wed, 01 Mar 2006 07:58:00 -0500 To: saag@mit.edu From: Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Spam-Alum-Prob: 0.000033 Spam-Alum-Time: 0.530280 Subject: [saag] Cryptographic Token Key Initialization Protocol Version 1.0 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, 01 Mar 2006 14:23:10 -0000 Please take a look at draft-nystrom-ct-kip-00.txt. It specifies Cryptographic Token Key Initialization Protocol Version 1.0, which is part of the OTPS series of documents being coordinated by RSA Laboratories. My opinion is that this is appropriate for publication as an RFC. My current plan is to sponsor this document as an Informational RFC. Please let me know if this causes concern. Russ From jis@MIT.EDU Wed Mar 1 15:43:04 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.12.8p2/8.12.8) with ESMTP id k21Kh4gQ029135 for ; Wed, 1 Mar 2006 15:43:04 -0500 Received: from jis.tzo.com (JISVPN.MIT.EDU [18.100.101.102]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id k21Kh33C011355 for ; Wed, 1 Mar 2006 15:43:03 -0500 (EST) Received: from Knoppix ([192.168.94.131]) by jis.tzo.com (8.12.11/8.12.11) with ESMTP id k21Kh3QG021183 for ; Wed, 1 Mar 2006 15:43:03 -0500 Received: by Knoppix via sendmail from stdin id (Debian Smail3.2.0.115) Wed, 1 Mar 2006 15:42:42 -0500 (EST) Date: Wed, 1 Mar 2006 15:42:42 -0500 From: "Jeffrey I. Schiller" To: saag@MIT.EDU Message-ID: <20060301204242.GI3367@mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline User-Agent: Mutt/1.5.9i X-Spam-Score: 1.352 X-Spam-Level: * (1.352) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] SAAG Mailing List has moved (sort of) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2006 20:43:04 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The SAAG mailing list has moved from jis.mit.edu to mailman.mit.edu. This only effects the website that you go to for list administration and to view the archives. The list's address continues to be saag@mit.edu and administrative requests can be mailed to saag-request@mit.edu. To access the list information (and archives) you now go to: http://mailman.mit.edu/mailman/listinfo/saag (the security conscious can use https...). -Jeff - -- ============================================================================= Jeffrey I. Schiller MIT Network Manager Information Services and Technology Massachusetts Institute of Technology 77 Massachusetts Avenue Room W92-190 Cambridge, MA 02139-4307 617.253.0161 - Voice jis@mit.edu ============================================================================ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEBgdB8CBzV/QUlSsRAl6fAJ97SM2qk3jhVhU2x/FSYd0Zvmb7IwCff2G9 NRoV5IvgUHmSZ1oj3hQ9ScU= =exa6 -----END PGP SIGNATURE----- From jis@MIT.EDU Wed Mar 1 15:50:57 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.12.8p2/8.12.8) with ESMTP id k21KovgQ030475 for ; Wed, 1 Mar 2006 15:50:57 -0500 Received: from jis.tzo.com (JISVPN.MIT.EDU [18.100.101.102]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id k21Kov3C028901 for ; Wed, 1 Mar 2006 15:50:57 -0500 (EST) Received: from Knoppix ([192.168.94.131]) by jis.tzo.com (8.12.11/8.12.11) with ESMTP id k21KovkX022659 for ; Wed, 1 Mar 2006 15:50:57 -0500 Received: by Knoppix via sendmail from stdin id (Debian Smail3.2.0.115) Wed, 1 Mar 2006 15:50:25 -0500 (EST) Date: Wed, 1 Mar 2006 15:50:25 -0500 From: "Jeffrey I. Schiller" To: saag@MIT.EDU Message-ID: <20060301205025.GJ3367@mit.edu> References: <20060301204242.GI3367@mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: <20060301204242.GI3367@mit.edu> User-Agent: Mutt/1.5.9i X-Spam-Score: 1.352 X-Spam-Level: * (1.352) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: Re: [saag] SAAG Mailing List has moved (sort of) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2006 20:50:57 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sorry to put more crud in your mailboxes. This is a test message to verify that the footer on the list messages is correct. Thanks. -Jeff - -- ============================================================================= Jeffrey I. Schiller MIT Network Manager Information Services and Technology Massachusetts Institute of Technology 77 Massachusetts Avenue Room W92-190 Cambridge, MA 02139-4307 617.253.0161 - Voice jis@mit.edu ============================================================================ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEBgkR8CBzV/QUlSsRAvxxAKCHz/M+dJJ3p2mYlZ5hao+IA9ApCwCguzek ZLT6P2PnddV8HjvFkz/7mSY= =Jskh -----END PGP SIGNATURE----- From smb@cs.columbia.edu Wed Mar 1 15:54:18 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.12.8p2/8.12.8) with ESMTP id k21KsIgQ031073 for ; Wed, 1 Mar 2006 15:54:18 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id k21KsEoq018802; Wed, 1 Mar 2006 15:54:14 -0500 (EST) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 8A3AAFB2B0; Wed, 1 Mar 2006 15:54:13 -0500 (EST) Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with SMTP id F21E33C0412; Wed, 1 Mar 2006 15:54:09 -0500 (EST) Date: Wed, 1 Mar 2006 15:54:09 -0500 From: "Steven M. Bellovin" To: "Jeffrey I. Schiller" Message-Id: <20060301155409.67727cb7.smb@cs.columbia.edu> In-Reply-To: <20060301204242.GI3367@mit.edu> References: <20060301204242.GI3367@mit.edu> Organization: Columbia University X-Mailer: Sylpheed version 2.2.1 (GTK+ 2.8.11; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 1.217 X-Spam-Level: * (1.217) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] SAAG Mailing List has moved (sort of) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2006 20:54:18 -0000 On Wed, 1 Mar 2006 15:42:42 -0500 "Jeffrey I. Schiller" wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > The SAAG mailing list has moved from jis.mit.edu to > mailman.mit.edu. This only effects the website that you go to for list > administration and to view the archives. > > The list's address continues to be saag@mit.edu and administrative > requests can be mailed to saag-request@mit.edu. > > To access the list information (and archives) you now go to: > > http://mailman.mit.edu/mailman/listinfo/saag > > (the security conscious can use https...). > I'll give you a gratuitous hard time: why isn't the URL at the end of the messages https:? Why not add a rewrite rule on the server sending all http: requests for mailman to https? That's what the CS department here does.... From jis@MIT.EDU Wed Mar 1 16:02:30 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.12.8p2/8.12.8) with ESMTP id k21L2UgQ032127 for ; Wed, 1 Mar 2006 16:02:30 -0500 Received: from jis.tzo.com (JISVPN.MIT.EDU [18.100.101.102]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id k21L2O3C027894 for ; Wed, 1 Mar 2006 16:02:29 -0500 (EST) Received: from Knoppix ([192.168.94.131]) by jis.tzo.com (8.12.11/8.12.11) with ESMTP id k21L2Gs6024473; Wed, 1 Mar 2006 16:02:16 -0500 Received: by Knoppix via sendmail from stdin id (Debian Smail3.2.0.115) Wed, 1 Mar 2006 16:01:33 -0500 (EST) Date: Wed, 1 Mar 2006 16:01:33 -0500 From: "Jeffrey I. Schiller" To: "Steven M. Bellovin" Message-ID: <20060301210133.GK3367@mit.edu> References: <20060301204242.GI3367@mit.edu> <20060301155409.67727cb7.smb@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: <20060301155409.67727cb7.smb@cs.columbia.edu> User-Agent: Mutt/1.5.9i X-Spam-Score: 1.352 X-Spam-Level: * (1.352) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] SAAG Mailing List has moved (sort of) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2006 21:02:30 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Its actually easier then that. I just set the "web_page_url" variable to "https://mailman.mit.edu/mailman/" and the desired result will happen. The "catch" is that the server certificate for mailman.mit.edu is issued by MIT and most people will not have our server CA installed in their browser. So they will get warnings (and some will not be able to access the page). I can put a public certificate on mailman.mit.edu (issued by GeoTrust) but I want to think a bit about it, as the site is used by many people... (though this shouldn't cause any real problems). -Jeff - -- ============================================================================= Jeffrey I. Schiller MIT Network Manager Information Services and Technology Massachusetts Institute of Technology 77 Massachusetts Avenue Room W92-190 Cambridge, MA 02139-4307 617.253.0161 - Voice jis@mit.edu ============================================================================ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEBgut8CBzV/QUlSsRAkU0AKDoXB55BcOBooMM+kI0HMlUJOlhEQCaAp54 G+FWYBxUPqySvjaj5YMcASs= =/4L6 -----END PGP SIGNATURE----- From smb@cs.columbia.edu Wed Mar 1 16:10:08 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.12.8p2/8.12.8) with ESMTP id k21LA8gQ000619 for ; Wed, 1 Mar 2006 16:10:08 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id k21LA4oq028929; Wed, 1 Mar 2006 16:10:05 -0500 (EST) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 24879FB2B1; Wed, 1 Mar 2006 16:10:04 -0500 (EST) Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with SMTP id 1E2A43C0410; Wed, 1 Mar 2006 16:10:01 -0500 (EST) Date: Wed, 1 Mar 2006 16:10:01 -0500 From: "Steven M. Bellovin" To: "Jeffrey I. Schiller" Message-Id: <20060301161001.20dccbfe.smb@cs.columbia.edu> In-Reply-To: <20060301210133.GK3367@mit.edu> References: <20060301204242.GI3367@mit.edu> <20060301155409.67727cb7.smb@cs.columbia.edu> <20060301210133.GK3367@mit.edu> Organization: Columbia University X-Mailer: Sylpheed version 2.2.1 (GTK+ 2.8.11; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 1.217 X-Spam-Level: * (1.217) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] SAAG Mailing List has moved (sort of) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2006 21:10:08 -0000 On Wed, 1 Mar 2006 16:01:33 -0500 "Jeffrey I. Schiller" wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Its actually easier then that. I just set the "web_page_url" variable > to "https://mailman.mit.edu/mailman/" and the desired result will > happen. I know; I've done that myself. The issue is the zillions of old URLs. > > The "catch" is that the server certificate for mailman.mit.edu is > issued by MIT and most people will not have our server CA installed in > their browser. So they will get warnings (and some will not be able to > access the page). > > I can put a public certificate on mailman.mit.edu (issued by GeoTrust) > but I want to think a bit about it, as the site is used by many > people... (though this shouldn't cause any real problems). Definitely think about it, but I suspect it's the way to go. From mouse@Sparkle.Rodents.Montreal.QC.CA Wed Mar 1 16:12:28 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.12.8p2/8.12.8) with ESMTP id k21LCRgQ000946 for ; Wed, 1 Mar 2006 16:12:28 -0500 Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id k21LCLoq004423 for ; Wed, 1 Mar 2006 16:12:22 -0500 (EST) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id QAA08333; Wed, 1 Mar 2006 16:12:20 -0500 (EST) From: der Mouse Message-Id: <200603012112.QAA08333@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. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Wed, 1 Mar 2006 16:07:05 -0500 (EST) To: saag@mit.edu In-Reply-To: <20060301155409.67727cb7.smb@cs.columbia.edu> References: <20060301204242.GI3367@mit.edu> <20060301155409.67727cb7.smb@cs.columbia.edu> X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: Re: [saag] SAAG Mailing List has moved (sort of) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2006 21:12:28 -0000 >> http://mailman.mit.edu/mailman/listinfo/saag >> (the security conscious can use https...). > I'll give you a gratuitous hard time: why isn't the URL at the end of > the messages https:? Why not add a rewrite rule on the server > sending all http: requests for mailman to https? As someone who has no SSL support, I would give Jeff a non-gratuitous hard time over either - unless and until snooping of HTTP connections to gather authentication information becomes common enough to worry about in general, or we have reason to think such an attack is being launched specifically against mailman.mit.edu. If I had to go to the Web interface, at least, which alone I would would give a firm time[%] over; having to use the Web to deal with a mailing-list matter seems really broken to me. (Having the Web as an option doesn't. It's when it becomes necessary that I squawk.) [%] Like a hard time, but milder. /~\ 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 mleech@nortel.com Wed Mar 1 15:52:22 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.12.8p2/8.12.8) with ESMTP id k21KqMgQ030678 for ; Wed, 1 Mar 2006 15:52:22 -0500 Received: from zrtps0kp.nortel.com (zrtps0kp.nortelnetworks.com [47.140.192.56]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id k21KqH3C002514; Wed, 1 Mar 2006 15:52:18 -0500 (EST) Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nort...s0.corp.nortel.com [47.129.230.89]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k21KqFi05627; Wed, 1 Mar 2006 15:52:15 -0500 (EST) Received: from [47.248.126.240] ([47.248.126.240] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 1 Mar 2006 15:52:08 -0500 Message-ID: <44060976.8080005@nortel.com> Date: Wed, 01 Mar 2006 15:52:06 -0500 From: "Marcus Leech" User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Jeffrey I. Schiller" References: <20060301204242.GI3367@mit.edu> In-Reply-To: <20060301204242.GI3367@mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Mar 2006 20:52:08.0666 (UTC) FILETIME=[01752BA0:01C63D72] X-Spam-Score: -2.465 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 X-Mailman-Approved-At: Wed, 01 Mar 2006 16:17:33 -0500 Cc: saag@mit.edu Subject: Re: [saag] SAAG Mailing List has moved (sort of) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2006 20:52:23 -0000 Jeffrey I. Schiller wrote: >- > >To access the list information (and archives) you now go to: > > http://mailman.mit.edu/mailman/listinfo/saag > >(the security conscious can use https...). > > > Not that you'd find any security-conscious folks on this list, Jeff :-) From mcr@sandelman.ottawa.on.ca Wed Mar 1 16:57:54 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.12.8p2/8.12.8) with ESMTP id k21LvsgQ007764 for ; Wed, 1 Mar 2006 16:57:54 -0500 Received: from lists.sandelman.ca (cod.sandelman.ca [192.139.46.139]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id k21Lvmc1016862; Wed, 1 Mar 2006 16:57:49 -0500 (EST) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) by lists.sandelman.ca (8.11.6p3/8.11.6) with ESMTP id k21LvY124209 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Wed, 1 Mar 2006 16:57:46 -0500 (EST) Received: from sandelman.ottawa.on.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 8A7EB3AD9C; Wed, 1 Mar 2006 16:57:33 -0500 (EST) To: "Jeffrey I. Schiller" In-Reply-To: Message from "Jeffrey I. Schiller" of "Wed, 01 Mar 2006 16:01:33 EST." <20060301210133.GK3367@mit.edu> References: <20060301204242.GI3367@mit.edu> <20060301155409.67727cb7.smb@cs.columbia.edu> <20060301210133.GK3367@mit.edu> X-Mailer: MH-E 7.82; nmh 1.1; XEmacs 21.4 (patch 17) Date: Wed, 01 Mar 2006 16:57:33 -0500 Message-ID: <23508.1141250253@sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Score: -2.464 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] SAAG Mailing List has moved (sort of) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2006 21:57:54 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Jeffrey" == Jeffrey I Schiller writes: Jeffrey> Its actually easier then that. I just set the "web_page_url" variable Jeffrey> to "https://mailman.mit.edu/mailman/" and the desired result will Jeffrey> happen. Jeffrey> The "catch" is that the server certificate for mailman.mit.edu is Jeffrey> issued by MIT and most people will not have our server CA Jeffrey> installed in Maybe we'd rather get the MIT CA key instead... maybe we trust it more:-) - -- ] 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.4.1 (GNU/Linux) Comment: Finger me for keys iQEVAwUBRAYYyYCLcPvd0N1lAQIdWwf/YRfou6MrKSX8PFz6vLXN6sKTj+VZpRCv JRZm7q6JT2Ywsjc/kvRhMS92dzVnOM8HzjxX13hRGklVLnRnxgmQNEeAeH3P0Xqi BO4oimN3GTHeArVglqep9u45ZisITHehmknsiXMAFWxwC7RavBET7LbB5cRyXwto 15ug+F5zsTwXKdECNrNnxNH9ajzGEwcgsXwSZc9X3Pg0dg/6eJ/Bo8UbAlid1dAD WfNW3t9D8dpsey2jUL+sohDyPcjFimd533QyWap9Y20GfxGr48h/bJJHuFx+JH5O 1Xj14wVh5LvR1NUjRZ1ofOFQjOGktDctfFD6spwcqge6scPEFG6FIA== =TxhH -----END PGP SIGNATURE----- From warlord@MIT.EDU Wed Mar 1 17:07:27 2006 Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by pch.mit.edu (8.12.8p2/8.12.8) with ESMTP id k21M7RgQ008889 for ; Wed, 1 Mar 2006 17:07:27 -0500 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id k21M7P57000452; Wed, 1 Mar 2006 17:07:25 -0500 (EST) Received: from w92-130-webmail-3.mit.edu (W92-130-WEBMAIL-3.MIT.EDU [18.7.22.133]) ) by outgoing.mit.edu (8.13.1/8.12.4) with ESMTP id k21M7Hvs003661; Wed, 1 Mar 2006 17:07:18 -0500 (EST) Received: (from nobody@localhost) by w92-130-webmail-3.mit.edu (8.12.4) id k21M7HY5025330; Wed, 1 Mar 2006 17:07:17 -0500 Received: from table.pgp.com (table.pgp.com [63.251.255.85]) (User authenticated as warlord@ATHENA.MIT.EDU) by webmail.mit.edu (Horde MIME library) with HTTP for ; Wed, 1 Mar 2006 17:07:17 -0500 Message-ID: <20060301170717.fyzx2ms6ok7sws8k@webmail.mit.edu> Date: Wed, 1 Mar 2006 17:07:17 -0500 From: Derek Atkins To: der Mouse References: <20060301204242.GI3367@mit.edu> <20060301155409.67727cb7.smb@cs.columbia.edu> <200603012112.QAA08333@Sparkle.Rodents.Montreal.QC.CA> In-Reply-To: <200603012112.QAA08333@Sparkle.Rodents.Montreal.QC.CA> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.3) X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] SAAG Mailing List has moved (sort of) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2006 22:07:28 -0000 Quoting der Mouse : > As someone who has no SSL support, [snip] How the heck can you not have SSL?? I've got SSL in my cell phone! EVERYTHING supports SSL. I admit that if you complained about JavaScript then I'd have to agree with you.. But SSL? What are you using? A Comodore 64? I think you could even get an SSL-capable browser there, too! -derek -- 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 jis@MIT.EDU Wed Mar 1 17:19:31 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.12.8p2/8.12.8) with ESMTP id k21MJVgQ010726 for ; Wed, 1 Mar 2006 17:19:31 -0500 Received: from jis.tzo.com (JISVPN.MIT.EDU [18.100.101.102]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id k21MJTRx001876 for ; Wed, 1 Mar 2006 17:19:29 -0500 (EST) Received: from Knoppix ([192.168.94.131]) by jis.tzo.com (8.12.11/8.12.11) with ESMTP id k21MJOVl004071; Wed, 1 Mar 2006 17:19:29 -0500 Received: by Knoppix via sendmail from stdin id (Debian Smail3.2.0.115) Wed, 1 Mar 2006 17:18:23 -0500 (EST) Date: Wed, 1 Mar 2006 17:18:23 -0500 From: "Jeffrey I. Schiller" To: Michael Richardson Message-ID: <20060301221823.GB3576@mit.edu> References: <20060301204242.GI3367@mit.edu> <20060301155409.67727cb7.smb@cs.columbia.edu> <20060301210133.GK3367@mit.edu> <23508.1141250253@sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: <23508.1141250253@sandelman.ottawa.on.ca> User-Agent: Mutt/1.5.9i X-Spam-Score: 1.352 X-Spam-Level: * (1.352) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] SAAG Mailing List has moved (sort of) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2006 22:19:31 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OK. Here is the MIT Server Root CA (you will note it expires this coming July, after a 10 year life...): Certificate: Data: Version: 1 (0x0) Serial Number: 0 (0x0) Signature Algorithm: md5WithRSAEncryption Issuer: C=US, ST=Massachusetts, O=Massachusetts Institute of Technology, OU=MIT Certification Authority Validity Not Before: Jul 15 20:23:00 1996 GMT Not After : Jul 13 20:23:00 2006 GMT Subject: C=US, ST=Massachusetts, O=Massachusetts Institute of Technology, OU=MIT Certification Authority Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:d3:d0:eb:e7:51:b5:33:75:a6:d8:a3:84:ea:02: 70:5c:cf:9c:20:e0:0b:03:8b:8e:46:6e:15:25:e1: 77:f6:6b:c4:70:dd:d4:16:0b:cc:11:88:31:38:0b: ee:7c:59:24:57:e9:8d:cd:75:f8:52:63:dd:33:0c: f0:4f:9f:b5:fc:91:ae:32:85:8c:1a:75:63:19:98: 86:1e:92:23:b2:87:f3:f5:c9:a6:a2:97:68:f2:ec: b2:1a:ad:b3:f5:ed:09:ea:cc:e7:bc:b4:64:50:15: e6:57:00:1a:7a:c6:de:fe:e1:30:58:5a:5d:ab:bb: b4:1c:11:ec:64:c1:d3:a4:55 Exponent: 65537 (0x10001) Signature Algorithm: md5WithRSAEncryption 01:19:13:24:13:13:28:10:db:54:0d:00:24:18:ca:02:35:27: af:bb:39:03:c5:e2:76:b9:7b:49:f9:1d:91:cb:52:fd:b6:09: 52:c4:ed:73:93:37:37:e2:cc:6f:18:a8:3f:47:9e:16:c6:60: 31:81:3a:21:7f:f8:27:05:2a:88:e6:51:0d:ae:24:32:b9:c5: 6a:04:02:be:4f:60:95:d2:82:92:6a:ec:65:0c:54:39:5b:54: 74:52:a2:85:6c:80:be:4d:29:f3:75:be:e0:d5:80:70:6b:dc: 39:5a:13:68:c6:ec:0e:87:b7:31:26:26:56:2d:86:bb:4c:80: 7b:43 - -----BEGIN CERTIFICATE----- MIICZTCCAc4CAQAwDQYJKoZIhvcNAQEEBQAwezELMAkGA1UEBhMCVVMxFjAUBgNV BAgTDU1hc3NhY2h1c2V0dHMxLjAsBgNVBAoTJU1hc3NhY2h1c2V0dHMgSW5zdGl0 dXRlIG9mIFRlY2hub2xvZ3kxJDAiBgNVBAsTG01JVCBDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0eTAeFw05NjA3MTUyMDIzMDBaFw0wNjA3MTMyMDIzMDBaMHsxCzAJBgNV BAYTAlVTMRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMS4wLAYDVQQKEyVNYXNzYWNo dXNldHRzIEluc3RpdHV0ZSBvZiBUZWNobm9sb2d5MSQwIgYDVQQLExtNSVQgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB ANPQ6+dRtTN1ptijhOoCcFzPnCDgCwOLjkZuFSXhd/ZrxHDd1BYLzBGIMTgL7nxZ JFfpjc11+FJj3TMM8E+ftfyRrjKFjBp1YxmYhh6SI7KH8/XJpqKXaPLsshqts/Xt CerM57y0ZFAV5lcAGnrG3v7hMFhaXau7tBwR7GTB06RVAgMBAAEwDQYJKoZIhvcN AQEEBQADgYEAARkTJBMTKBDbVA0AJBjKAjUnr7s5A8Xidrl7SfkdkctS/bYJUsTt c5M3N+LMbxioP0eeFsZgMYE6IX/4JwUqiOZRDa4kMrnFagQCvk9gldKCkmrsZQxU OVtUdFKihWyAvk0p83W+4NWAcGvcOVoTaMbsDoe3MSYmVi2Gu0yAe0M= - -----END CERTIFICATE----- - -- ============================================================================= Jeffrey I. Schiller MIT Network Manager Information Services and Technology Massachusetts Institute of Technology 77 Massachusetts Avenue Room W92-190 Cambridge, MA 02139-4307 617.253.0161 - Voice jis@mit.edu ============================================================================ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEBh2v8CBzV/QUlSsRAtGCAJ0Rz0IK7AaYVtxxrbqknGNvGBp01QCdG1nJ 3tMJNKPnbnU14KakHlnIU3o= =dJzY -----END PGP SIGNATURE----- From gem@rellim.com Wed Mar 1 17:34:03 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.12.8p2/8.12.8) with ESMTP id k21MY3gQ012714 for ; Wed, 1 Mar 2006 17:34:03 -0500 Received: from catbert.rellim.com (catbert.rellim.com [204.17.205.1]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id k21MY2c1019286 for ; Wed, 1 Mar 2006 17:34:03 -0500 (EST) Received: from catbert.rellim.com (gem@localhost [127.0.0.1]) by catbert.rellim.com (8.13.5/8.13.5) with ESMTP id k21MXv3W022892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Mar 2006 14:34:02 -0800 DomainKey-Signature: a=rsa-sha1; s=catbert; d=rellim.com; c=simple; q=dns; b=nZm7vLXFUen0Yjrp7cVJR1zsqkogujwvuZ/4i9Afy14DBJQ9sMz3+FYXdN0IOVipU IhRqauxCz3/UEnaQa8WBg== Received: from localhost (gem@localhost) by catbert.rellim.com (8.13.5/8.13.5/Submit) with ESMTP id k21MXubb022889; Wed, 1 Mar 2006 14:33:57 -0800 X-Authentication-Warning: catbert.rellim.com: gem owned process doing -bs Date: Wed, 1 Mar 2006 14:33:53 -0800 (PST) From: "Gary E. Miller" To: der Mouse In-Reply-To: <200603012112.QAA08333@Sparkle.Rodents.Montreal.QC.CA> Message-ID: References: <20060301204242.GI3367@mit.edu> <20060301155409.67727cb7.smb@cs.columbia.edu> <200603012112.QAA08333@Sparkle.Rodents.Montreal.QC.CA> X-Message-Flag: SYSTEM ERROR! Are you sure you want to use Outlook? MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: -2.6 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] SAAG Mailing List has moved (sort of) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2006 22:34:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yo Mouse! On Wed, 1 Mar 2006, der Mouse wrote: > As someone who has no SSL support, Join the new millennium! Even links and lynks have supported https for a long time. > I would give Jeff a non-gratuitous > hard time over either - unless and until snooping of HTTP connections > to gather authentication information becomes common enough to worry > about in general, or we have reason to think such an attack is being > launched specifically against mailman.mit.edu. One of my favorite tricks when I take my laptop somewhere is to leave my http password sniffer running. I tend to walk out with all sorts of good passwords that way. Since people tend to reuse the same username/password combo if I get one of their http logins then I have most of their logins. Where did I get these tools? Usually off of hacked hosts I am disinfecting, so this has been in the wild a long, long, time. RGDS GARY - --------------------------------------------------------------------------- Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701 gem@rellim.com Tel:+1(541)382-8588 Fax: +1(541)382-8676 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (GNU/Linux) iD8DBQFEBiFU8KZibdeR3qURAr3+AJ0d+8ijik43XeWVNRp8dVDR2VAA6wCaAsDc ogCwdU9UWQAcgbWyGlz25fA= =YeFj -----END PGP SIGNATURE----- From mouse@Sparkle.Rodents.Montreal.QC.CA Wed Mar 1 17:58:06 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.12.8p2/8.12.8) with ESMTP id k21Mw6gQ016007 for ; Wed, 1 Mar 2006 17:58:06 -0500 Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id k21Mw5c1012637 for ; Wed, 1 Mar 2006 17:58:05 -0500 (EST) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id RAA09100; Wed, 1 Mar 2006 17:58:04 -0500 (EST) From: der Mouse Message-Id: <200603012258.RAA09100@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. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Wed, 1 Mar 2006 17:39:05 -0500 (EST) To: saag@mit.edu In-Reply-To: References: <20060301204242.GI3367@mit.edu> <20060301155409.67727cb7.smb@cs.columbia.edu> <200603012112.QAA08333@Sparkle.Rodents.Montreal.QC.CA> X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: Re: [saag] SAAG Mailing List has moved (sort of) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2006 22:58:06 -0000 >> As someone who has no SSL support, > Join the new millennium! Even links and lynks have supported https > for a long time. So I've been told, by people who apparently know better than I do what I have installed. Twice, I have sat down to add SSL support to the lynx I run (which does nto have it, but has hooks for it). Each time, I've gotten about four levels deep in tools-to-build-the-tools before needing something insanely heavyweight (perl? python? I forget) and dumping the project. And really, for the most part, there is nothing behind https: that I much care about. Perhaps someday my motivation will get to the point of trying to dig up a newer version of lynx, one that comes with SSL support, or perhaps digging up enough doc on SSL itself to build my own (all the SSL doc I've managed to find so far has been a maze of twisty little cross-references which all eventually end up at pay-for-play "standards"). > One of my favorite tricks when I take my laptop somewhere is to leave > my http password sniffer running. I tend to walk out with all sorts > of good passwords that way. Do you really think openly admitting that you routinely try to gain unauthorized access to other people's computers is smart? I hope your upstream cuts you off for network abuse - and, preferably, the Oregon DA's office files whatever criminal charges they can find apply, though I'd be more than somewhat surprised if the latter were to actually happen. People who deliberately do such things have no business being anywhere but inside jail cells. /~\ 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 gem@rellim.com Wed Mar 1 18:34:00 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.12.8p2/8.12.8) with ESMTP id k21NY0gQ020830 for ; Wed, 1 Mar 2006 18:34:00 -0500 Received: from catbert.rellim.com (catbert.rellim.com [204.17.205.1]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id k21NXtRx025610 for ; Wed, 1 Mar 2006 18:33:55 -0500 (EST) Received: from catbert.rellim.com (gem@localhost [127.0.0.1]) by catbert.rellim.com (8.13.5/8.13.5) with ESMTP id k21NXnJv024591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Mar 2006 15:33:54 -0800 DomainKey-Signature: a=rsa-sha1; s=catbert; d=rellim.com; c=simple; q=dns; b=kCpbeDueMtU/Wzcd0/9Kv7tI0O0oR0wh5V4GS9YTC9PzqPFw9YNDVxaGn1DDUh99M cCmwVVbyH3BSfLkKDnKsw== Received: from localhost (gem@localhost) by catbert.rellim.com (8.13.5/8.13.5/Submit) with ESMTP id k21NXnJP024588; Wed, 1 Mar 2006 15:33:49 -0800 X-Authentication-Warning: catbert.rellim.com: gem owned process doing -bs Date: Wed, 1 Mar 2006 15:33:44 -0800 (PST) From: "Gary E. Miller" To: der Mouse In-Reply-To: <200603012258.RAA09100@Sparkle.Rodents.Montreal.QC.CA> Message-ID: References: <20060301204242.GI3367@mit.edu> <20060301155409.67727cb7.smb@cs.columbia.edu> <200603012112.QAA08333@Sparkle.Rodents.Montreal.QC.CA> <200603012258.RAA09100@Sparkle.Rodents.Montreal.QC.CA> X-Message-Flag: SYSTEM ERROR! Are you sure you want to use Outlook? MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: -2.6 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] SAAG Mailing List has moved (sort of) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2006 23:34:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yo Mouse! On Wed, 1 Mar 2006, der Mouse wrote: > >> As someone who has no SSL support, > > Join the new millennium! Even links and lynks have supported https > > for a long time. > > So I've been told, by people who apparently know better than I do what > I have installed. > > Twice, I have sat down to add SSL support to the lynx I run (which does > nto have it, but has hooks for it). Each time, I've gotten about four > levels deep in tools-to-build-the-tools before needing something > insanely heavyweight (perl? python? I forget) and dumping the project. Not sure what the hangup would be. I know you are a smart guy. We've been on many of the same lists for well over 10 years. The classic configure;make;make install of openssl and then links (or lynx) is all it should take. Been years since I recompiled my links, looks like 2003. If the old configure;make;make install is too hard then maybe it is time for you to get a distro made in the last 5 years and upgrade? > And really, for the most part, there is nothing behind https: that I > much care about. The real question is what are you doing in http that SHOULD be behind http? If you never use http for anything sensitive then fine. > > One of my favorite tricks when I take my laptop somewhere is to leave > > my http password sniffer running. I tend to walk out with all sorts > > of good passwords that way. > > Do you really think openly admitting that you routinely try to gain > unauthorized access to other people's computers is smart? Who said unauthorized? I am always up front on what I am doing with my customers. My intent is to help them tighten up their sloppy security practices. The clients do not want their employees accessing the web insecurely and I help them enforce their policies. > I hope your upstream cuts you off for network abuse - and, preferably, > the Oregon DA's office files whatever criminal charges they can find > apply, though I'd be more than somewhat surprised if the latter were to > actually happen. People who deliberately do such things have no > business being anywhere but inside jail cells. I think you confuse me with a black hat. My hat is very white and my upstreams absolutely know what I do. Just because I need to get in to the heads of black hats to catch them does not mean I am one. Many people will only fix a security problem after you show them in person how easy it is to exploit. That is the whole point of "Full Disclosure". RGDS GARY - --------------------------------------------------------------------------- Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701 gem@rellim.com Tel:+1(541)382-8588 Fax: +1(541)382-8676 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (GNU/Linux) iD8DBQFEBi9d8KZibdeR3qURAtBTAKDKFrDTqhUJcJNdhP7EGO8yPdypGwCaAwSC MUT7Z7vWsFuS9ny1GtBXG4c= =EXde -----END PGP SIGNATURE----- From mouse@Sparkle.Rodents.Montreal.QC.CA Wed Mar 1 18:44:15 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.12.8p2/8.12.8) with ESMTP id k21NiFgQ022034 for ; Wed, 1 Mar 2006 18:44:15 -0500 Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id k21Ni8Rx018758 for ; Wed, 1 Mar 2006 18:44:09 -0500 (EST) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id SAA09492; Wed, 1 Mar 2006 18:44:08 -0500 (EST) From: der Mouse Message-Id: <200603012344.SAA09492@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. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Wed, 1 Mar 2006 18:38:44 -0500 (EST) To: saag@mit.edu In-Reply-To: References: <20060301204242.GI3367@mit.edu> <20060301155409.67727cb7.smb@cs.columbia.edu> <200603012112.QAA08333@Sparkle.Rodents.Montreal.QC.CA> <200603012258.RAA09100@Sparkle.Rodents.Montreal.QC.CA> X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: Re: [saag] SAAG Mailing List has moved (sort of) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2006 23:44:15 -0000 >>> One of my favorite tricks when I take my laptop somewhere is to >>> leave my http password sniffer running. >> Do you really think openly admitting that you routinely try to gain >> unauthorized access to other people's computers is smart? > Who said unauthorized? I am always up front on what I am doing with > my customers. "When I take my laptop somewhere" is a long way from "when I run a pen test at a customer site". > I think you confuse me with a black hat. If you really do sniff passwords as casually as you made it sound, you are a black hat, whatever you may like to think. /~\ 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 gem@rellim.com Wed Mar 1 19:11:49 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.12.8p2/8.12.8) with ESMTP id k220BngQ025836 for ; Wed, 1 Mar 2006 19:11:49 -0500 Received: from catbert.rellim.com (catbert.rellim.com [204.17.205.1]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id k220Bnc1026800 for ; Wed, 1 Mar 2006 19:11:49 -0500 (EST) Received: from catbert.rellim.com (gem@localhost [127.0.0.1]) by catbert.rellim.com (8.13.5/8.13.5) with ESMTP id k220BhSx026161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Mar 2006 16:11:49 -0800 DomainKey-Signature: a=rsa-sha1; s=catbert; d=rellim.com; c=simple; q=dns; b=fRaY2NsORHuKasAdAidkXJhgguIRcudGSKDvFGfh70owJUmktupcRjzLNlA0nNgSv WxIL00vwiSlCbuOL7mwzQ== Received: from localhost (gem@localhost) by catbert.rellim.com (8.13.5/8.13.5/Submit) with ESMTP id k220BhXh026158; Wed, 1 Mar 2006 16:11:43 -0800 X-Authentication-Warning: catbert.rellim.com: gem owned process doing -bs Date: Wed, 1 Mar 2006 16:11:40 -0800 (PST) From: "Gary E. Miller" To: der Mouse In-Reply-To: <200603012344.SAA09492@Sparkle.Rodents.Montreal.QC.CA> Message-ID: References: <20060301204242.GI3367@mit.edu> <20060301155409.67727cb7.smb@cs.columbia.edu> <200603012112.QAA08333@Sparkle.Rodents.Montreal.QC.CA> <200603012258.RAA09100@Sparkle.Rodents.Montreal.QC.CA> <200603012344.SAA09492@Sparkle.Rodents.Montreal.QC.CA> X-Message-Flag: SYSTEM ERROR! Are you sure you want to use Outlook? MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: -2.6 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] SAAG Mailing List has moved (sort of) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2006 00:11:50 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yo Mouse! On Wed, 1 Mar 2006, der Mouse wrote: > >>> One of my favorite tricks when I take my laptop somewhere is to > >>> leave my http password sniffer running. > >> Do you really think openly admitting that you routinely try to gain > >> unauthorized access to other people's computers is smart? > > Who said unauthorized? I am always up front on what I am doing with > > my customers. > > "When I take my laptop somewhere" is a long way from "when I run a pen > test at a customer site". Misread how you wish. I never said "pen-test", and little about under what conditions I move my laptop. > > I think you confuse me with a black hat. > > If you really do sniff passwords as casually as you made it sound, you > are a black hat, whatever you may like to think. Being a black hat implies either bad motives, bad intent or harm to an uwilling or unknowing victim. None of that applies here. By your definition a Magician is a con-man. Penn and teller would disagree. Regardless, my original point still stands. Sniffing http usernames and passwords is very easy and very commonplace. It is also well known that people tend to reuse the same usernames and passwords over and over again. Put those facts together and you can see trouble is bound to happen. Being as how this is a security related list, and MIT is renowned for its "ethical" hacking, then it is only prudent that this list should take at least the usual precautions to ensure u/p safety. RGDS GARY - --------------------------------------------------------------------------- Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701 gem@rellim.com Tel:+1(541)382-8588 Fax: +1(541)382-8676 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (GNU/Linux) iD8DBQFEBjg/8KZibdeR3qURAsNwAJ9k6zkokbyFh6+9TgHltMwyC9MCfQCgk0K/ mBxi1py3l6FS8uRRbmZc/Mo= =TTS8 -----END PGP SIGNATURE----- From James.Jaques@L-3com.com Wed Mar 1 19:28:36 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.12.8p2/8.12.8) with ESMTP id k220SagQ028368 for ; Wed, 1 Mar 2006 19:28:36 -0500 Received: from mail2.L-3com.com (mail2.l-3com.com [128.170.207.35]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id k220SZc1003388 for ; Wed, 1 Mar 2006 19:28:36 -0500 (EST) Received: from iecmail.iec.l-3com.com (iecmail.iec.l-3com.com [128.170.118.25]) by mail2.L-3com.com (8.12.10+Sun/8.12.10) with ESMTP id k220SW3N008068; Wed, 1 Mar 2006 19:28:32 -0500 (EST) Received: by iecmail.iec.l-3com.com with Internet Mail Service (5.5.2657.72) id <1V50GMHY>; Wed, 1 Mar 2006 16:28:59 -0800 Message-ID: From: "Jaques, James @ IEC" To: "'Gary E. Miller'" , der Mouse Date: Wed, 1 Mar 2006 16:28:15 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="windows-1250" X-Spam-Score: -2.399 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] SAAG Mailing List has moved (sort of) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2006 00:28:36 -0000 Yo Mouse indeed! Black Hatters are generally thought of as hackers. As "Darth Elmo" of Blackhat.org says, (and I agree) "The term "hacker" carries a lot of baggage, and, popular belief to the contrary, many people who call themselves hackers don't break into other people's systems." (Okay, maybe occasionally the systems of people they know, but not anybody who'd mind.) Whether one defines hackers as "computer criminals" or as "those who push computers, networks and even society beyond their creators' imagined limits", the term still has connotations of not-quite-strict legality and nonconformance taken to extremes. In fact, the reverse is actually so. The "button down" community of IS executives and engineers attends the Black Hat expo (set of good and fairly good talks in Vegas just before the Black Hat "DEF CON" expo at a different hotel (for the real geeks). Most of those people are NOT hackers bent on destruction and mayhem. They are not script kiddies, and they are very serious about IS. We'd better hope that there are more of them when the foreign powers bent on OUR destruction come to call on our networks. Lots of the people at both of those events are Feds and State IS types and I, for one am happy that they are there. If we do not have a cadre of people able to help us defend and counter attack, then the "big brother" that listens to you and catalogs your every keystroke may speak Chinese or some other language. Nuff' :-) Jim Jaques Project Engineer, Special Weapons L-3 Communications, Interstate Electronics Bldg 604 602 E. Vermont Ave Anaheim, Ca. 92803 James.jaques@L-3com.com James.jaques@Verizon.net (checked only at home) -----Original Message----- From: Gary E. Miller [mailto:gem@rellim.com] Sent: Wednesday, March 01, 2006 4:12 PM To: der Mouse Cc: saag@mit.edu Subject: Re: [saag] SAAG Mailing List has moved (sort of) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yo Mouse! On Wed, 1 Mar 2006, der Mouse wrote: > >>> One of my favorite tricks when I take my laptop somewhere is to > >>> leave my http password sniffer running. > >> Do you really think openly admitting that you routinely try to gain > >> unauthorized access to other people's computers is smart? > > Who said unauthorized? I am always up front on what I am doing with > > my customers. > > "When I take my laptop somewhere" is a long way from "when I run a pen > test at a customer site". Misread how you wish. I never said "pen-test", and little about under what conditions I move my laptop. > > I think you confuse me with a black hat. > > If you really do sniff passwords as casually as you made it sound, you > are a black hat, whatever you may like to think. Being a black hat implies either bad motives, bad intent or harm to an uwilling or unknowing victim. None of that applies here. By your definition a Magician is a con-man. Penn and teller would disagree. Regardless, my original point still stands. Sniffing http usernames and passwords is very easy and very commonplace. It is also well known that people tend to reuse the same usernames and passwords over and over again. Put those facts together and you can see trouble is bound to happen. Being as how this is a security related list, and MIT is renowned for its "ethical" hacking, then it is only prudent that this list should take at least the usual precautions to ensure u/p safety. RGDS GARY - --------------------------------------------------------------------------- Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701 gem@rellim.com Tel:+1(541)382-8588 Fax: +1(541)382-8676 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (GNU/Linux) iD8DBQFEBjg/8KZibdeR3qURAsNwAJ9k6zkokbyFh6+9TgHltMwyC9MCfQCgk0K/ mBxi1py3l6FS8uRRbmZc/Mo= =TTS8 -----END PGP SIGNATURE----- _______________________________________________ saag mailing list saag@mit.edu http://mailman.mit.edu/mailman/listinfo/saag -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.375 / Virus Database: 268.1.1/272 - Release Date: 3/1/2006 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.375 / Virus Database: 268.1.1/272 - Release Date: 3/1/2006 From mcr@sandelman.ottawa.on.ca Thu Mar 2 10:47:37 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.12.8p2/8.12.8) with ESMTP id k22FlbgQ008829 for ; Thu, 2 Mar 2006 10:47:37 -0500 Received: from lists.sandelman.ca (cod.sandelman.ca [192.139.46.139]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id k22FlNhZ022081; Thu, 2 Mar 2006 10:47:28 -0500 (EST) Received: from sandelman.ottawa.on.ca (CPE0006b123a026-CM0011aea1b6fc.cpe.net.cable.rogers.com [65.49.207.194]) by lists.sandelman.ca (8.11.6p3/8.11.6) with ESMTP id k22Fl8X10319 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Thu, 2 Mar 2006 10:47:17 -0500 (EST) Received: from sandelman.ottawa.on.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 523EB3AD9C; Thu, 2 Mar 2006 10:47:08 -0500 (EST) To: "Jeffrey I. Schiller" In-Reply-To: Message from "Jeffrey I. Schiller" of "Wed, 01 Mar 2006 17:18:23 EST." <20060301221823.GB3576@mit.edu> References: <20060301204242.GI3367@mit.edu> <20060301155409.67727cb7.smb@cs.columbia.edu> <20060301210133.GK3367@mit.edu> <23508.1141250253@sandelman.ottawa.on.ca> <20060301221823.GB3576@mit.edu> X-Mailer: MH-E 7.82; nmh 1.1; XEmacs 21.4 (patch 17) Date: Thu, 02 Mar 2006 10:47:07 -0500 Message-ID: <21250.1141314427@sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Score: -2.464 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] SAAG Mailing List has moved (sort of) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2006 15:47:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Jeffrey" == Jeffrey I Schiller writes: Jeffrey> OK. Here is the MIT Server Root CA (you will note it Jeffrey> expires this coming July, after a 10 year life...): Thanks. http://www.sandelman.ca/tmp/mit.cac - -- ] 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.4.1 (GNU/Linux) Comment: Finger me for keys iQEVAwUBRAcTeYCLcPvd0N1lAQL0awf+Im48wdDsaOutqWbdqzT0vAURYid5ii9S r/bVFZzBnEuU1X09UIQmszbGRGXB+uS27HLF3ddcPk8srt5AR3j7Ja1bPhIbO2CJ IqlIAQ+5FSHzQaNOWQsw9AysTmM8NN7X2ULtjmfznwQ0zbAkNwN0+eO7du8FrZJr 4uLwls0FKfJ98mWrNgauSKOpb0ysWA7n6ln4Vt3Av76ZZl7MS4ntfLIqIgxtQ6hA JmiTktrfF+ExKd6ftGk1SJe+GR1EJ8nbHQiSXkL2stFZwsvjyFGRMCZhgsnAZs8p lTRXJNZ0uD0mBnkEJJTOthh6FFzj7FBBRz2BI4gmBCS2edFrliymSA== =28uU -----END PGP SIGNATURE----- From pbaker@verisign.com Fri Mar 3 19:24:21 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.12.8p2/8.12.8) with ESMTP id k240OLgQ015345 for ; Fri, 3 Mar 2006 19:24:21 -0500 Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id k240OLeE005053 for ; Fri, 3 Mar 2006 19:24:21 -0500 (EST) Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.13.1/8.13.4) with ESMTP id k240OKNJ019615; Fri, 3 Mar 2006 16:24:20 -0800 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Mar 2006 16:24:20 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 3 Mar 2006 16:24:19 -0800 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_003A_01C63EF8.11514C70" Message-ID: <198A730C2044DE4A96749D13E167AD3797CA18@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [saag] SAAG Mailing List has moved (sort of) Thread-Index: AcY9da8bhKUIIswkSs6oiQbTxO7JRwBq7eJA From: "Hallam-Baker, Phillip" To: "der Mouse" , X-OriginalArrivalTime: 04 Mar 2006 00:24:20.0009 (UTC) FILETIME=[FAC17190:01C63F21] X-Spam-Score: -1.754 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: Re: [saag] SAAG Mailing List has moved (sort of) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Mar 2006 00:24:21 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_003A_01C63EF8.11514C70 Content-Type: multipart/alternative; boundary="----=_NextPart_001_003B_01C63EF8.11514C70" ------=_NextPart_001_003B_01C63EF8.11514C70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > From: saag-bounces@mit.edu [ mailto:saag-bounces@mit.edu] On > Behalf Of der Mouse > As someone who has no SSL support, I would give Jeff a > non-gratuitous hard time over either - unless and until > snooping of HTTP connections to gather authentication > information becomes common enough to worry about in general, > or we have reason to think such an attack is being launched > specifically against mailman.mit.edu. Don't you see something of an inconsistency in joining a security research mailing list and demanding that people respect your personal anti-technology fetish by not using standard security measures? ------=_NextPart_001_003B_01C63EF8.11514C70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> From: saag-bounces@mit.edu = [mailto:saag-bounces@mit.edu]=20 On
> Behalf Of der Mouse

> As someone who has no SSL = support, I=20 would give Jeff a
> non-gratuitous hard time over either - unless = and=20 until
> snooping of HTTP connections to gather = authentication
>=20 information becomes common enough to worry about in general,
> or = we have=20 reason to think such an attack is being launched
> specifically = against=20 mailman.mit.edu.

Don't you see something of an inconsistency in = joining a=20 security
research = mailing list=20 and demanding that people respect your
personal anti-technology = fetish by=20 not using standard security
measures?

 


 

------=_NextPart_001_003B_01C63EF8.11514C70-- ------=_NextPart_000_003A_01C63EF8.11514C70 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUBDCCAoAw ggHpoAMCAQICEQCyNFw02+JxK/SJPVrL0W7rMA0GCSqGSIb3DQEBBAUAMFExCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UE AxMISVBTZWMgQ0EwHhcNOTkxMDIxMDAwMDAwWhcNMDkxMDIxMjM1OTU5WjBRMQswCQYDVQQGEwJV UzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xFjAUBgNVBAsTDUNvcnBvcmF0ZSBJU0cxETAPBgNV BAMTCElQU2VjIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8hbpukYQ9ZzsnCGcBfV9V 0S6dL6DmQTly99jiGKylKnrR6r+9IYn3p7paKD4hc5q7CuXwvkKGYKYewqmjjEE3ncwEt+Lb7d6T Rzw9q1Lktnerh+ZLZmmg66hqoJ0gvEufbhSZcaFfd+GOAwcc4gi9gms0QxRxT5iSt0GoqFaSRQID AQABo1gwVjAjBgNVHREEHDAapBgwFjEUMBIGA1UEAxMLT25zaXRlMi0xNDUwEQYJYIZIAYb4QgEB BAQDAgEGMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHid MZBUanCQ/uLOqKJkBYzqExOzrWw7hThsnrwLdkJMFIToG6zQCXF1kDhD5Dkvs62P/oDQaTz0THy7 D7L8pVmH5aXDIUQ6+0IiE5WTF8W1wy7sxXtRVtjaA5K0Ks3H/jYOTCcONZ23RKW+yzMWAUKI5neh leC1aZpra1xeCQv4MIIC6jCCAlOgAwIBAgIQbsSmTwagoePcKLXY2aPQwDANBgkqhkiG9w0BAQQF ADBRMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xFjAUBgNVBAsTDUNvcnBv cmF0ZSBJU0cxETAPBgNVBAMTCElQU2VjIENBMB4XDTA2MDExMTAwMDAwMFoXDTA3MDExMTIzNTk1 OVoweDEXMBUGA1UEChQOVmVyaVNpZ24sIEluYy4xGzAZBgNVBAsUElJlbW90ZSBBY2Nlc3MgVXNl cjEcMBoGA1UEAxMTUGhpbGlwIEhhbGxhbS1CYWtlcjEiMCAGCSqGSIb3DQEJARYTcGJha2VyQHZl cmlzaWduLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAzxhnkx3bovN4ayxbfh7jSdUX Zwu9vXe0jbEPJf6qQL1picRE3Z6Uf3WTCrIXtxq0fA3l1unByt3Ej2N4oqLPb+oUAWK8P+pHoom1 huJpEcKayU9aj+C5tj6/dytjRTvKmJTY2YK/gc8VKcCxIkk/W/YuScRFIlx5B5c5l/JlKVsCAwEA AaOBmzCBmDAJBgNVHRMEAjAAMAsGA1UdDwQEAwIFoDARBglghkgBhvhCAQEEBAMCB4AwWAYDVR0f BFEwTzBNoEugSYZHaHR0cDovL29uc2l0ZWNybC52ZXJpc2lnbi5jb20vVmVyaVNpZ25JbmNSZW1v dGVBY2Nlc3NVc2VyL0xhdGVzdENSTC5jcmwwEQYKYIZIAYb4RQEGCQQDAQH/MA0GCSqGSIb3DQEB BAUAA4GBAEbtIeGVxE1YBPgVjOy17U8r2oyX7XBSC7XmFPcZ3jVYivlHVGzBQIenSqo7xS9TxHDY rCxxTcMtx3j/knFVqpcQMGH38Aem+IuwQJAcCnTtnu8bP/IFnDh5+vnvPXF36ZI+qC9TUFttBPrF Bpc9CkvSPesoZKSfngGidzJUUK0LMIIDAzCCAmwCEQC5L2DMiJ+hekYJuFtwbIqvMA0GCSqGSIb3 DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xPDA6BgNVBAsT M0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMjE6MDgG A1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw05ODA1MTgwMDAwMDBaFw0yODA4MDEy MzU5NTlaMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xPDA6BgNVBAsT M0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMjE6MDgG A1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAp4gBIXQs5xoD8JjhlzwPIQjxnNuX6Zr8wgQGE75fUsjMHiwSViy4AWkszJkfrbCWrnkE8hM5 wXuYuggs6MKEEyyqaekJ9MepAqRCwiNPStjwDqL7MWzJ5m+ZJwf15vRMeJ5t60aG+rmGyVTyssSv 1EYcWskVMP8NbPUtDm3Of3cCAwEAATANBgkqhkiG9w0BAQUFAAOBgQByLvl/0fFx+8Se9sVeUYpA mLho+Jscg9jinb3/7aHmZuovCfTK1+qlK5X2JGCGTUQug6XELaDTrnhpb3LabK4I8GOSN+a7xDAX rXfMSTWqz9iP0b63GJZHc2pUIjRkLbYWm1lbtFFZOrMLFPQS32eg9K0yZF6xRnInjBJ7xUS0rjCC A6YwggMPoAMCAQICEHWNgosXAgaqes2nmr0jsCgwDQYJKoZIhvcNAQEFBQAwgcExCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE8MDoGA1UECxMzQ2xhc3MgMiBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEcyMTowOAYDVQQLEzEoYykgMTk5OCBWZXJp U2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyNDIzNTk1OVowga0xFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQL E0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBh LWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z56fy5WXixVcBTWLHP bxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiKQNKaiRMpqbbV26d+ 4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCBrTARBglghkgBhvhC AQEEBAMCAQYwDwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgB hvhFAQcXAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDQGA1Ud HwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzIuY3JsMA0GCSqGSIb3 DQEBBQUAA4GBAFJetpXbb3ymfgX2VIU72RqKRVlffMJl7vlA3lRux5ASgCQ8QKNj7IUf9R4bico9 juNLLt+cG+6O51S5VpP+29HERPjLnECdkqzFzgTxEUbsiLyYyIwhfTeczGu9NKWTjL2cOR3qp5wa zfVHbSxzE2NqIS5afYd9vEy+8scDwoy2MIIDwDCCAymgAwIBAgIQSsgAA2Nh1BUDFvGGNpu3zTAN BgkqhkiG9w0BAQUFADCBrTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJjAkBgNVBAMTHVZlcmlTaWduIENs YXNzIDIgUGVyc29ubmVsIENBMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyMzIzNTk1OVowgawxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkw RwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5j b20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBMIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDAitGHYaLqMANVawg28Jf6GlQ1JB/ofZ3Iw3PT2Eb1 kS3ZOO2U17Amcyrel1BN/yIcvXAAmAxYKrGkco+lufctfGDjtd/pfU4hIWHV/DtUyaQJnLsi+aK6 cGFPhkai/QVk7Ao/plh2V7sWc0R88KUNl8BspvFjCCWxBBeVoI3+fwIDAQABo4HfMIHcMCkGA1Ud EQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTExODARBglghkgBhvhCAQEEBAMCAQYw DwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAjAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDgGA1UdHwQxMC8wLaAr oCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNybDANBgkqhkiG9w0BAQUF AAOBgQA2GP0zYNYX0wS12FRfUhrlkggo9KJA2sNbjBqGl++uohX+bMTOL8gByjO+8nlYM5eXkkVw Wk4oHd33wYhOG4dXAj2TJdl+TnI1iUkXs7l3L20O+aSIJcHOdnNlaQWTd+f9k5YYOE1YbHqd6NKb 6NDbif1JwnUEA5el1JaB2CNB8DCCBBkwggOCoAMCAQICEF052qAxsWldLlk3EVCNpLEwDQYJKoZI hvcNAQEEBQAwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAy IEVtcGxveWVlIENBMB4XDTA1MDgxMDAwMDAwMFoXDTA2MDgxMDIzNTk1OVowbTERMA8GA1UEChMI VkVSSVNJR04xCzAJBgNVBAsTAkhRMRMwEQYDVQQDEwpSZWNpcGllbnRzMTYwNAYDVQQDEy1wYmFr ZXIgKEhhbGxhbS1CYWtlciBQaGlsbGlwLCBWZXJpU2lnbiwgSW5jLikwgZ8wDQYJKoZIhvcNAQEB BQADgY0AMIGJAoGBANQT8A2wsm52VpfNoc/FbBi07LKq8Q8ztSvZkocF+JRtdAbMtHn3PnO/UGqF Q1Td0has2t+XiV2xVax+/qEuAat5b20pRHj32whM/XcmMco7CHFH+TseTwChwJGt9fAVKjAGWRJq di8EISDmrRmxO3vbtIKNtzL10YHha+MRpPMbAgMBAAGjggF4MIIBdDAJBgNVHRMEAjAAMFkGA1Ud HwRSMFAwTqBMoEqGSGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL1ZlcmlTaWduSW5jRXhj aGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMLmNybDALBgNVHQ8EBAMCBaAwHgYDVR0RBBcwFYETcGJh a2VyQHZlcmlzaWduLmNvbTCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlT aWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIu IGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMB0GA1UdJQQWMBQGCCsGAQUF BwMEBggrBgEFBQcDAjANBgkqhkiG9w0BAQQFAAOBgQCrTQbYFsByl4BpUeoDHIAeqhBlPPPG/NcU uz0Edr7Eyv729E53LMbjHB8IUfHp4fN7fKD+NwS6uPMszKuczAhXMfG/YmBm/aod+VebYCw4TODA HE8c2E8AboGqFq6XVIRXjTvIFG6hZi4z4I9PN/emwSjlMe73wBeyBctUJ7O3YDGCAyAwggMcAgEB MIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBs b3llZSBDQQIQXTnaoDGxaV0uWTcRUI2ksTAJBgUrDgMCGgUAoIIBtDAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjAzMDQwMDI0MThaMCMGCSqGSIb3DQEJBDEWBBQF kHHAkfI1xJpbyP/Z0B87R5al2TBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMAcGBSsOAwIa MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAK BggqhkiG9w0CBTB0BgkrBgEEAYI3EAQxZzBlMFExCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UEAxMISVBTZWMgQ0ECEG7E pk8GoKHj3Ci12Nmj0MAwdgYLKoZIhvcNAQkQAgsxZ6BlMFExCzAJBgNVBAYTAlVTMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UEAxMISVBTZWMg Q0ECEG7Epk8GoKHj3Ci12Nmj0MAwDQYJKoZIhvcNAQEBBQAEgYA632ydjOLBXc4RavVoJN9C9P0v Dl5dD4ahai6PiNhwa2/QSpi+SRX6w7zoAlupZI7hxJYY1QvxgnEB7lO9GzzM702b5XqEM93Pm3V8 SJjKMHk9WZRoXiqClYXGAOf9p/z9cu1ml6gvlBqPuVD3z52e1ikEpL90YNDlIlpz4AN/0gAAAAAA AA== ------=_NextPart_000_003A_01C63EF8.11514C70-- From pbaker@verisign.com Fri Mar 3 19:32:00 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.12.8p2/8.12.8) with ESMTP id k240W0gQ016481 for ; Fri, 3 Mar 2006 19:32:00 -0500 Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id k240W0pT001677 for ; Fri, 3 Mar 2006 19:32:00 -0500 (EST) Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by robin.verisign.com (8.13.1/8.13.4) with ESMTP id k240VxFA021661; Fri, 3 Mar 2006 16:31:59 -0800 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Mar 2006 16:31:59 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 3 Mar 2006 16:31:58 -0800 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0042_01C63EF9.23007850" Message-ID: <198A730C2044DE4A96749D13E167AD3797CA1C@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [saag] SAAG Mailing List has moved (sort of) Thread-Index: AcY9hLTmWJg0Azi9SO+DPU44nwsqqwBnab4g From: "Hallam-Baker, Phillip" To: "der Mouse" , X-OriginalArrivalTime: 04 Mar 2006 00:31:59.0243 (UTC) FILETIME=[0C7AFDB0:01C63F23] X-Spam-Score: -2.465 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: Re: [saag] SAAG Mailing List has moved (sort of) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Mar 2006 00:32:01 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0042_01C63EF9.23007850 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu] On > Behalf Of der Mouse > >> As someone who has no SSL support, > > Join the new millennium! Even links and lynks have supported https > > for a long time. > > So I've been told, by people who apparently know better than > I do what I have installed. > > Twice, I have sat down to add SSL support to the lynx I run > (which does nto have it, but has hooks for it). Each time, > I've gotten about four levels deep in > tools-to-build-the-tools before needing something insanely > heavyweight (perl? python? I forget) and dumping the project. I have a spare demo disk for Windows Vista I picked up at RSA if you would like to join the new millenium. ------=_NextPart_000_0042_01C63EF9.23007850 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUBDCCAoAw ggHpoAMCAQICEQCyNFw02+JxK/SJPVrL0W7rMA0GCSqGSIb3DQEBBAUAMFExCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UE AxMISVBTZWMgQ0EwHhcNOTkxMDIxMDAwMDAwWhcNMDkxMDIxMjM1OTU5WjBRMQswCQYDVQQGEwJV UzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xFjAUBgNVBAsTDUNvcnBvcmF0ZSBJU0cxETAPBgNV BAMTCElQU2VjIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8hbpukYQ9ZzsnCGcBfV9V 0S6dL6DmQTly99jiGKylKnrR6r+9IYn3p7paKD4hc5q7CuXwvkKGYKYewqmjjEE3ncwEt+Lb7d6T Rzw9q1Lktnerh+ZLZmmg66hqoJ0gvEufbhSZcaFfd+GOAwcc4gi9gms0QxRxT5iSt0GoqFaSRQID AQABo1gwVjAjBgNVHREEHDAapBgwFjEUMBIGA1UEAxMLT25zaXRlMi0xNDUwEQYJYIZIAYb4QgEB BAQDAgEGMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHid MZBUanCQ/uLOqKJkBYzqExOzrWw7hThsnrwLdkJMFIToG6zQCXF1kDhD5Dkvs62P/oDQaTz0THy7 D7L8pVmH5aXDIUQ6+0IiE5WTF8W1wy7sxXtRVtjaA5K0Ks3H/jYOTCcONZ23RKW+yzMWAUKI5neh leC1aZpra1xeCQv4MIIC6jCCAlOgAwIBAgIQbsSmTwagoePcKLXY2aPQwDANBgkqhkiG9w0BAQQF ADBRMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xFjAUBgNVBAsTDUNvcnBv cmF0ZSBJU0cxETAPBgNVBAMTCElQU2VjIENBMB4XDTA2MDExMTAwMDAwMFoXDTA3MDExMTIzNTk1 OVoweDEXMBUGA1UEChQOVmVyaVNpZ24sIEluYy4xGzAZBgNVBAsUElJlbW90ZSBBY2Nlc3MgVXNl cjEcMBoGA1UEAxMTUGhpbGlwIEhhbGxhbS1CYWtlcjEiMCAGCSqGSIb3DQEJARYTcGJha2VyQHZl cmlzaWduLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAzxhnkx3bovN4ayxbfh7jSdUX Zwu9vXe0jbEPJf6qQL1picRE3Z6Uf3WTCrIXtxq0fA3l1unByt3Ej2N4oqLPb+oUAWK8P+pHoom1 huJpEcKayU9aj+C5tj6/dytjRTvKmJTY2YK/gc8VKcCxIkk/W/YuScRFIlx5B5c5l/JlKVsCAwEA AaOBmzCBmDAJBgNVHRMEAjAAMAsGA1UdDwQEAwIFoDARBglghkgBhvhCAQEEBAMCB4AwWAYDVR0f BFEwTzBNoEugSYZHaHR0cDovL29uc2l0ZWNybC52ZXJpc2lnbi5jb20vVmVyaVNpZ25JbmNSZW1v dGVBY2Nlc3NVc2VyL0xhdGVzdENSTC5jcmwwEQYKYIZIAYb4RQEGCQQDAQH/MA0GCSqGSIb3DQEB BAUAA4GBAEbtIeGVxE1YBPgVjOy17U8r2oyX7XBSC7XmFPcZ3jVYivlHVGzBQIenSqo7xS9TxHDY rCxxTcMtx3j/knFVqpcQMGH38Aem+IuwQJAcCnTtnu8bP/IFnDh5+vnvPXF36ZI+qC9TUFttBPrF Bpc9CkvSPesoZKSfngGidzJUUK0LMIIDAzCCAmwCEQC5L2DMiJ+hekYJuFtwbIqvMA0GCSqGSIb3 DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xPDA6BgNVBAsT M0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMjE6MDgG A1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw05ODA1MTgwMDAwMDBaFw0yODA4MDEy MzU5NTlaMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xPDA6BgNVBAsT M0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMjE6MDgG A1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAp4gBIXQs5xoD8JjhlzwPIQjxnNuX6Zr8wgQGE75fUsjMHiwSViy4AWkszJkfrbCWrnkE8hM5 wXuYuggs6MKEEyyqaekJ9MepAqRCwiNPStjwDqL7MWzJ5m+ZJwf15vRMeJ5t60aG+rmGyVTyssSv 1EYcWskVMP8NbPUtDm3Of3cCAwEAATANBgkqhkiG9w0BAQUFAAOBgQByLvl/0fFx+8Se9sVeUYpA mLho+Jscg9jinb3/7aHmZuovCfTK1+qlK5X2JGCGTUQug6XELaDTrnhpb3LabK4I8GOSN+a7xDAX rXfMSTWqz9iP0b63GJZHc2pUIjRkLbYWm1lbtFFZOrMLFPQS32eg9K0yZF6xRnInjBJ7xUS0rjCC A6YwggMPoAMCAQICEHWNgosXAgaqes2nmr0jsCgwDQYJKoZIhvcNAQEFBQAwgcExCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE8MDoGA1UECxMzQ2xhc3MgMiBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEcyMTowOAYDVQQLEzEoYykgMTk5OCBWZXJp U2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyNDIzNTk1OVowga0xFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQL E0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBh LWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z56fy5WXixVcBTWLHP bxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiKQNKaiRMpqbbV26d+ 4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCBrTARBglghkgBhvhC AQEEBAMCAQYwDwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgB hvhFAQcXAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDQGA1Ud HwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzIuY3JsMA0GCSqGSIb3 DQEBBQUAA4GBAFJetpXbb3ymfgX2VIU72RqKRVlffMJl7vlA3lRux5ASgCQ8QKNj7IUf9R4bico9 juNLLt+cG+6O51S5VpP+29HERPjLnECdkqzFzgTxEUbsiLyYyIwhfTeczGu9NKWTjL2cOR3qp5wa zfVHbSxzE2NqIS5afYd9vEy+8scDwoy2MIIDwDCCAymgAwIBAgIQSsgAA2Nh1BUDFvGGNpu3zTAN BgkqhkiG9w0BAQUFADCBrTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJjAkBgNVBAMTHVZlcmlTaWduIENs YXNzIDIgUGVyc29ubmVsIENBMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyMzIzNTk1OVowgawxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkw RwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5j b20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBMIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDAitGHYaLqMANVawg28Jf6GlQ1JB/ofZ3Iw3PT2Eb1 kS3ZOO2U17Amcyrel1BN/yIcvXAAmAxYKrGkco+lufctfGDjtd/pfU4hIWHV/DtUyaQJnLsi+aK6 cGFPhkai/QVk7Ao/plh2V7sWc0R88KUNl8BspvFjCCWxBBeVoI3+fwIDAQABo4HfMIHcMCkGA1Ud EQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTExODARBglghkgBhvhCAQEEBAMCAQYw DwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAjAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDgGA1UdHwQxMC8wLaAr oCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNybDANBgkqhkiG9w0BAQUF AAOBgQA2GP0zYNYX0wS12FRfUhrlkggo9KJA2sNbjBqGl++uohX+bMTOL8gByjO+8nlYM5eXkkVw Wk4oHd33wYhOG4dXAj2TJdl+TnI1iUkXs7l3L20O+aSIJcHOdnNlaQWTd+f9k5YYOE1YbHqd6NKb 6NDbif1JwnUEA5el1JaB2CNB8DCCBBkwggOCoAMCAQICEF052qAxsWldLlk3EVCNpLEwDQYJKoZI hvcNAQEEBQAwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAy IEVtcGxveWVlIENBMB4XDTA1MDgxMDAwMDAwMFoXDTA2MDgxMDIzNTk1OVowbTERMA8GA1UEChMI VkVSSVNJR04xCzAJBgNVBAsTAkhRMRMwEQYDVQQDEwpSZWNpcGllbnRzMTYwNAYDVQQDEy1wYmFr ZXIgKEhhbGxhbS1CYWtlciBQaGlsbGlwLCBWZXJpU2lnbiwgSW5jLikwgZ8wDQYJKoZIhvcNAQEB BQADgY0AMIGJAoGBANQT8A2wsm52VpfNoc/FbBi07LKq8Q8ztSvZkocF+JRtdAbMtHn3PnO/UGqF Q1Td0has2t+XiV2xVax+/qEuAat5b20pRHj32whM/XcmMco7CHFH+TseTwChwJGt9fAVKjAGWRJq di8EISDmrRmxO3vbtIKNtzL10YHha+MRpPMbAgMBAAGjggF4MIIBdDAJBgNVHRMEAjAAMFkGA1Ud HwRSMFAwTqBMoEqGSGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL1ZlcmlTaWduSW5jRXhj aGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMLmNybDALBgNVHQ8EBAMCBaAwHgYDVR0RBBcwFYETcGJh a2VyQHZlcmlzaWduLmNvbTCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlT aWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIu IGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMB0GA1UdJQQWMBQGCCsGAQUF BwMEBggrBgEFBQcDAjANBgkqhkiG9w0BAQQFAAOBgQCrTQbYFsByl4BpUeoDHIAeqhBlPPPG/NcU uz0Edr7Eyv729E53LMbjHB8IUfHp4fN7fKD+NwS6uPMszKuczAhXMfG/YmBm/aod+VebYCw4TODA HE8c2E8AboGqFq6XVIRXjTvIFG6hZi4z4I9PN/emwSjlMe73wBeyBctUJ7O3YDGCAyAwggMcAgEB MIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBs b3llZSBDQQIQXTnaoDGxaV0uWTcRUI2ksTAJBgUrDgMCGgUAoIIBtDAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjAzMDQwMDMxNThaMCMGCSqGSIb3DQEJBDEWBBR9 Us0wBlTsbimpp87h5UrLrfhZVTBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMAcGBSsOAwIa MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAK BggqhkiG9w0CBTB0BgkrBgEEAYI3EAQxZzBlMFExCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UEAxMISVBTZWMgQ0ECEG7E pk8GoKHj3Ci12Nmj0MAwdgYLKoZIhvcNAQkQAgsxZ6BlMFExCzAJBgNVBAYTAlVTMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UEAxMISVBTZWMg Q0ECEG7Epk8GoKHj3Ci12Nmj0MAwDQYJKoZIhvcNAQEBBQAEgYAqdtF+zMhCcFtrdAffW1MH6v0J 7LJ4faooajhvahDq0EeboSHiUw654k+wtoenTQN0kMQ1OjPpclINIKdEmCMYMnjUuCY7slDLNfqq kM5ioJ1uBb/xT9IR3IsfiE3GoyFwso3p/FTau0r8apZ4W+qJw4sO+oiMASykSwC9KWCbsgAAAAAA AA== ------=_NextPart_000_0042_01C63EF9.23007850-- From mouse@Sparkle.Rodents.Montreal.QC.CA Mon Mar 6 12:08:37 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.12.8p2/8.12.8) with ESMTP id k26H8bgQ016984 for ; Mon, 6 Mar 2006 12:08:37 -0500 Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id k26H8amT023839 for ; Mon, 6 Mar 2006 12:08:37 -0500 (EST) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id MAA20453; Mon, 6 Mar 2006 12:08:33 -0500 (EST) From: der Mouse Message-Id: <200603061708.MAA20453@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. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Mon, 6 Mar 2006 12:00:29 -0500 (EST) To: saag@mit.edu In-Reply-To: <198A730C2044DE4A96749D13E167AD3797CA18@MOU1WNEXMB04.vcorp.ad.vrsn.com> References: <198A730C2044DE4A96749D13E167AD3797CA18@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: Re: [saag] SAAG Mailing List has moved (sort of) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2006 17:08:37 -0000 >> As someone who has no SSL support, I would give Jeff a >> non-gratuitous hard time over either - unless and until [there is >> reason to think snooping is a live problem for them]. > Don't you see something of an inconsistency in joining a security > research mailing list and demanding that people respect your personal > anti-technology fetish by not using standard security measures? Begging the question at its finest ("personal anti-technology fetish"). Perhaps I would, if that's what it were. If I had an SSL implementation that didn't demand insanely heayweight guff to build, or simple and clear documentation on the protocol, I wouldn't mind. Perhaps an SSL for lynx exists out there that doesn't require half hell's back acre to build. Perhaps the documentation exists. But I haven't found either one. (To be sure, I haven't looked all *that* hard, because there's fairly little behind https: that I care about.) I can't see how that's an "anti-technology fetish". I'd also point out that part of good security is knowing when *not* to use it. You don't just blindly apply security measures, not if you're good; you look at the situation and decide which measures are worth applying and which aren't. The "non-gratuitous hard time" I referred to above would have been over applying a security measure where it's unnecessary: where it doesn't fix a real problem. /~\ 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 mouse@Sparkle.Rodents.Montreal.QC.CA Mon Mar 6 12:12:13 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.12.8p2/8.12.8) with ESMTP id k26HCCgQ017599 for ; Mon, 6 Mar 2006 12:12:12 -0500 Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id k26HCCmT004748 for ; Mon, 6 Mar 2006 12:12:12 -0500 (EST) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id MAA20505; Mon, 6 Mar 2006 12:12:11 -0500 (EST) From: der Mouse Message-Id: <200603061712.MAA20505@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. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Mon, 6 Mar 2006 12:11:30 -0500 (EST) To: saag@mit.edu In-Reply-To: <198A730C2044DE4A96749D13E167AD3797CA1C@MOU1WNEXMB04.vcorp.ad.vrsn.com> References: <198A730C2044DE4A96749D13E167AD3797CA1C@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: Re: [saag] SAAG Mailing List has moved (sort of) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2006 17:12:13 -0000 > I have a spare demo disk for Windows Vista I picked up at RSA if you > would like to join the new millenium. Not unless it includes full source code. /~\ 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 housley@vigilsec.com Tue Mar 14 10:23:29 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.12.8p2/8.12.8) with ESMTP id k2EFNTJw029950 for ; Tue, 14 Mar 2006 10:23:29 -0500 Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by fort-point-station.mit.edu (8.12.4/8.9.2) with SMTP id k2EFNOuM017809 for ; Tue, 14 Mar 2006 10:23:25 -0500 (EST) Received: (qmail 14604 invoked by uid 0); 14 Mar 2006 15:23:22 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (71.246.201.221) by woodstock.binhost.com with SMTP; 14 Mar 2006 15:23:22 -0000 Message-Id: <7.0.0.16.2.20060314102004.065a6258@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Tue, 14 Mar 2006 10:22:35 -0500 To: saag@mit.edu From: Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] Two NIST Draft documents: FIPS 186-3 and NIST SP 800-89 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2006 15:23:29 -0000 I encourage participants in the Security Area to review and comment on these documents. Russ -----Original Message----- From: Elaine Barker Sent: Monday, March 13, 2006 4:19 PM A draft of Federal Information Processing Standard (FIPS) 186-3, Digital Signature Standard (DSS), is available for public comment as announced in the Federal Register. The draft is available at http://csrc.nist.gov/publications/drafts.html. Please submit comments to ebarker@nist.gov with "Comments on Draft 186-3" in the subject line. The comment period closes on June 12, 2006. A draft of an accompanying document to the proposed FIPS 186-3, NIST Special Publication (SP) 800-89, Recommendation for Obtaining Assurances for Digital Signature Applications, is also available for public comment at http://csrc.nist.gov/publications/drafts.html. Please submit comments to ebarker@nist.gov with "Comments on SP 800-89" in the subject line. The comment period closes on April 28, 2006. From housley@vigilsec.com Tue Mar 14 10:30:42 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.12.8p2/8.12.8) with ESMTP id k2EFUgJw030706 for ; Tue, 14 Mar 2006 10:30:42 -0500 Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by fort-point-station.mit.edu (8.12.4/8.9.2) with SMTP id k2EFUhuM014623 for ; Tue, 14 Mar 2006 10:30:43 -0500 (EST) Received: (qmail 19011 invoked by uid 0); 14 Mar 2006 15:30:40 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (71.246.201.221) by woodstock.binhost.com with SMTP; 14 Mar 2006 15:30:40 -0000 Message-Id: <7.0.0.16.2.20060314102531.065aaa28@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Tue, 14 Mar 2006 10:29:58 -0500 To: saag@mit.edu From: Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] NIST SP 800-56A is Finally Available X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2006 15:30:43 -0000 The guidance in this document will impact implementors that are interested in FIPS 140 validation of their products. I suggest you take a look. Russ -----Original Message----- From: Elaine Barker Sent: Monday, March 13, 2006 4:19 PM NIST Special Publication (SP) 800-56A, Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography, has been posted as a final document at http://csrc.nist.gov/publications/nistpubs/index.html. From gregory.ietf@gmail.com Tue Mar 21 16:06:03 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.12.8p2/8.12.8) with ESMTP id k2LL63LE026649; Tue, 21 Mar 2006 16:06:03 -0500 Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id k2LL5rKf023500; Tue, 21 Mar 2006 16:05:53 -0500 (EST) Received: from [130.129.132.69] (helo=gregory-lt.earthlink.net) by elasmtp-banded.atl.sa.earthlink.net with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1FLmIW-0007kg-8a; Tue, 21 Mar 2006 14:13:41 -0500 Message-Id: <6.1.2.0.0.20060321111119.0446b3e0@popd.ix.netcom.com> X-Sender: gregory.ietf@gmail.com@pop.gmail.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 21 Mar 2006 11:13:34 -0800 To: secdir@mit.edu, saag@mit.edu From: "Gregory M. Lebovitz" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-ELNK-Trace: bb75549d41bf6763a56c75a03b4135ad4d2b10475b571120d572b6770bdd550fae0024f30fcb3f964fe681fbb0d747ff350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 130.129.132.69 X-Spam-Score: 1.379 X-Spam-Level: * (1.379) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 X-Mailman-Approved-At: Tue, 21 Mar 2006 16:51:33 -0500 Cc: Russ Housley , Paul Knight Subject: [saag] pki4ipsec WG summary IETF65 Dallas X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2006 21:06:03 -0000 IETF65 - Dallas PKI4IPSEC wg met for 1.5 hours on Tuesday morning. The major topic of discussion was the ikecert-profile document which profiles the use of certificates and PKI systems in IKE/IPsec. - Brian Korver: draft-ietf-pki4ipsec-ikecert-profile-09.txt Since IETF 64, this I-D has entered and passed WG Last Call, and is now in AD review. This meeting we addressed a few of the AD comments, and spent the remainder of the time debating how to address the Rescorla-Bellovin review for MD5/SHA1 use and protocol agility. This document addresses three populations: IKE/IPsec implementors, Cert/CA implementors, and deployers of both together. For the first, the current issues raised about MD5/SHA1 do not apply to HMAC, which is how IKE/IPsec uses the algo's in question, so no change is needed there. For the Cert/CA implementors, the issue is relevant, and will be addressed in PKIX WG. For the deployers, we added a section 4.3 in with four paragraphs that: - mandates support of MD5 and SHA1 as MUST for backward compatability with certs already issued - "Ecourages deployers not to issue new certificates with MD5" - encourages implementors and deployers to read current work on SHA256 and consider issuing new certs with this algo ACTIONS: - Brian Korver to propose new text for page 6, in the table, around "bitwise comparison". - BK to add sentence to in 3.1.2 to address Internationalization - BK to add "ecourage" text to sect 4.3 - BK to address other editorial nits from AD review, and issue -10, which will advance to IESG review. - draft-ietf-pki4ipsec-mgmt-profile-rqts-04.txt This doc was revised slightly since IETF64. It is currently in WG last call. No issues raised so far. No more reviews expected. Will close WG last call at end of IETF, and submit to ADs for advancement as Informational. Note: this document captures the needs and requirements of the IPsec implementor community. It was initially desired that the Cert/CA implementors would join the effort and we would create a profile of a cert management protocol as a guidance to the Cert/CA implementors, IPsec implementors, and deployers. However, Cert/CA implementors did not produce critical mass of involvement, and the work waned. The WG will capture these requirements in an informational RFC, in case interest should arise in the future. ACTIONS: - WG members to read the document and comment this week. - Chairs to close WG Last Call at end of this week, and advance to AD as Informational. This working group does not expect to meet in Montreal, and will close following publishing of these two RFCs. Gregory. +++++++++++++++++++++++ IETF-related email from Gregory M. Lebovitz g r e go r y d o t i e tf a t g m a i l do t c o m From lha@it.su.se Wed Mar 22 14:41:18 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.12.8p2/8.12.8) with ESMTP id k2MJfILE014567 for ; Wed, 22 Mar 2006 14:41:18 -0500 Received: from smtp1.su.se (smtp1.su.se [130.237.162.112]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id k2MJf19V023641; Wed, 22 Mar 2006 14:41:03 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp1.su.se (Postfix) with ESMTP id A80037406A; Wed, 22 Mar 2006 20:41:00 +0100 (CET) Received: from smtp1.su.se ([127.0.0.1]) by localhost (smtp1.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 05330-01-57; Wed, 22 Mar 2006 20:40:59 +0100 (CET) Received: from [130.129.131.232] (DHCP-Wireless-131-232.ietf65.org [130.129.131.232]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp1.su.se (Postfix) with ESMTP id D1D307400C; Wed, 22 Mar 2006 20:40:53 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-40--606993901" Message-Id: <81F8DFDB-0A48-4EFE-A550-24BA0EEFE217@it.su.se> Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?= Date: Wed, 22 Mar 2006 13:40:46 -0600 To: anonsec@postel.org X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.746.3) X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.665 tagged_above=-99 required=7 tests=[AWL=0.000, BAYES_00=-1.665] X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 X-Mailman-Approved-At: Wed, 22 Mar 2006 14:57:03 -0500 Cc: Security Area A Group , Sam Hartman , Russ Housley Subject: [saag] BTNS IETF65 session summary X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2006 19:41:19 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-40--606993901 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed IETF-65 BTNS Session Summary March 20, 9.00-11.30 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D BTNS held its third meeting in Dallas. Three documents where discussed during the meeting, the "Problem and Applicability Statement", "An Unauthenticated Mode of IPsec", and "IPsec Channels: Connection Latching", the two later accepted as working group document since the last meeting. Joe Touch talked about the Problem and Applicability Statement document. There are four outstanding issues, and hopefully next revision of the document can go to working group last call. Nicolas Williams made a presentation of his drafts "An Unauthenticated Mode of IPsec" and "IPsec Channels: Connection Latching". The group thought that direction of document was the right one. There was consensus that the document was too tense, and that Nicolas needed fill in more details how it should work and how it would fit into IPsec processing. There was a short discussion on how to proceed with the API item from the charter. Sam Hartman with help from David Black will present at next IETF. Michael Richardson promised to look at the old API requirements document that he and Bill Sommerfeld made for IPSP. Decisions =3D=3D=3D=3D=3D=3D=3D=3D=3D * Require support of bare keys, and add self-signed certificates as a =20= SHOULD. * The IKE extentions will be folded into the core document and Michael Richardson help Nicolas with document as a co editor. Action items =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D * Re-spin PS/AS document, submit document in May, and take to WG-LC * Address comments on Nicolas=92s drafts * Start up work on IPsec interfaces draft Updated milestones =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Done First version of SPD and/or PAD extensions draft May 06 WG LC on problem and applicability statement (a+b) Done First version of IKE extensions draft (if needed) May 06 First version of IPsec interfaces draft (e) May 06 Submit problem and applicability statement to IESG (a+b) Aug 06 WG LC on IKE extensions (c) Aug 06 WG LC on SPD and/or PAD extensions (d) Sep 06 Submit IKE extensions to the IESG Sep 06 Submit SPD and/or PAD extensions to the IESG Nov06 WG LC on IPsec interfaces draft Nov06 Submit IPsec interfaces draft to the IESG Mar 06 Recharter or close the WG --Apple-Mail-40--606993901 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEIahCJyok7cfdyBYRAvg1AKCwqNfYgmJVXEOwZ8lP3YgoFYo8uQCfceCk V68lOVA2Z89SmbExuTHAdxk= =oep3 -----END PGP SIGNATURE----- --Apple-Mail-40--606993901-- From jsalowey@cisco.com Thu Mar 23 00:08:57 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.12.8p2/8.12.8) with ESMTP id k2N58vLE005826 for ; Thu, 23 Mar 2006 00:08:57 -0500 Received: from test-iport-1.cisco.com (web-sjc-001.cisco.com [171.71.176.117] (may be forged)) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id k2N58k5D010953; Thu, 23 Mar 2006 00:08:46 -0500 (EST) Received: from sj-core-5.cisco.com ([171.71.177.238]) by test-iport-1.cisco.com with ESMTP; 22 Mar 2006 21:08:46 -0800 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k2N58j7T008175; Wed, 22 Mar 2006 21:08:46 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Wed, 22 Mar 2006 21:15:49 -0800 Message-ID: <7210B31550AC934A8637D6619739CE6906C6F905@e2k-sea-xch2.sea-alpha.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: EMU Working group summary Thread-Index: AcZON9t6OlLUcysKQzCEoccuwBcYdg== From: "Salowey, Joe" To: , "Russ Housley" , X-Spam-Score: -2.6 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id k2N58vLE005826 Cc: saag@mit.edu Subject: [saag] EMU Working group summary X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2006 05:08:57 -0000 EAP Method Update Working Group Summary TUESDAY, March 21, 2006 1. Strong Shared Secret Design Team Update The goal is to develop a simple EAP method based on strong shared secrets implementable is resource constrained environments. The approach is to develop a method that is not based on TLS, only require the use of symmetric crypto and operates between two parties. There is a desire to minimize the number of cryptographic primitives necessary. Algorithm agility is a requirement. + First draft of strong shared secret for working group consideration due before next IETF 2. EAP-TLS bis The goal is to bring EAP-TLS into standards track. EAP-TLS is an EAP mechanism based on TLS 1.x certificate based cipher suites with client side certificates. It shares the same algorithm agility and hash function properties as TLS. Working Group showed interest in draft-simon-emu-rfc2716bis-01.txt and there was some consensus to adopt draft as working group item. + People offered to review draft and provide implementation feedback From housley@vigilsec.com Thu Mar 23 10:24:47 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.12.8p2/8.12.8) with ESMTP id k2NFOlLE026145 for ; Thu, 23 Mar 2006 10:24:47 -0500 Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by fort-point-station.mit.edu (8.12.4/8.9.2) with SMTP id k2NFOkVb022674 for ; Thu, 23 Mar 2006 10:24:46 -0500 (EST) Received: (qmail 518 invoked by uid 0); 23 Mar 2006 15:24:43 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (130.129.134.249) by woodstock.binhost.com with SMTP; 23 Mar 2006 15:24:43 -0000 Message-Id: <7.0.0.16.2.20060323102009.02f0e020@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Thu, 23 Mar 2006 10:24:36 -0500 To: saag@mit.edu From: Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -1.11 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] SAAG Scribes X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2006 15:24:48 -0000 I am looking for two volunteers for the session this afternoon: one minute taker and one jabber scribe. Please let me know if you are willing to help. Russ From leiba@watson.ibm.com Thu Mar 23 10:30:43 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.12.8p2/8.12.8) with ESMTP id k2NFUhLE027573 for ; Thu, 23 Mar 2006 10:30:43 -0500 Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id k2NFUfVb012008 for ; Thu, 23 Mar 2006 10:30:41 -0500 (EST) Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41]) by igw2.watson.ibm.com (8.12.11/8.13.1/8.13.1-2005-04-25 igw) with ESMTP id k2NFUtMD032534; Thu, 23 Mar 2006 10:30:55 -0500 Received: from sp1n293en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id k2NFUc0193876; Thu, 23 Mar 2006 10:30:38 -0500 Received: from saturn.watson.ibm.com ([9.12.235.27]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id k2NFUbj209784; Thu, 23 Mar 2006 10:30:37 -0500 Date: Thu, 23 Mar 2006 10:30:01 -0500 From: DKIM Chair To: ietf-dkim@mipassoc.org Message-ID: <9FDEAD9885C9F556FFA13FF5@saturn.watson.ibm.com> X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: -2.6 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, dkim-ads@tools.ietf.org, dkim-chairs@tools.ietf.org Subject: [saag] DKIM Working Group Summary, IETF 65 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2006 15:30:57 -0000 This is a brief summary of what happened in the DKIM sessions at IETF 65. Detailed minutes will follow to the DKIM mailing list when I can get them cleaned up, probably early next week. Note that the reply-to for this message has been set to the DKIM mailing list, ietf-dkim@mipassoc.org ---------------------------------------------- Discussion of issues for draft-ietf-dkim-threats; few issues left, open issues covered, document should be ready for final version next week. Discussion of issues for draft-ietf-dkim-base. Several were minor. Main issues: * Issue: mailing-list considerations. Long discussion started on the mailing list, needs to be continued there. * Issue: "r=" tag, specifying a "report-to" entity. Defer consideration to SSP document, but then we considered whether to also have it in the key record (or something reachable through the selector). Further discussion to go to the mailing list. * Issue: transition plan for new crypto algorithms, and specifically, transition from SHA-1 to SHA-256 hashes. Some discussion here, but discussion ultimately deferred to the general issue of multiple signatures. Consensus among the security folks is to let the verifier decide which crypto is "best". * Issue: hashing the message separately and putting that hash into the header, then hashing and signing the header. Room consensus for, will take to the mailing list. * Issue: some popular mail implementations do things that make header canonicalization of "simple" problematic. Informative text will be added to suggest what the signer should watch for when using "simple" to sign. * Lots of other minor issues, as noted above. We briefly discussed splitting the base document (specifically to remove references to retrieving DNS records, but there may be other things that make sense to split out), and deferred some longer discussion to the mailing list. Jim Fenton introduced the signing policy/practices proposal and issues; after the base document, we'll be attacking this in earnest. The name is still in flux, with some thinking that "policy" is not the right term, others thinking that "practices" isn't either. We were pointed to some work called DDDS that's been introduced in the speermint working group, which might help us with the work (not with the naming), so we'll have a look at that. Tony Hansen introduced the DKIM Overview document that he's gotten Phillip and Dave to work on with him. The idea is that this document contain informative text to explain history and decisions that it doesn't make sense to put in the normative documents. There was discussion of what should go in here: some would like to have all informative text moved here, while others point out that implementors often don't read auxiliary documents, and everything should stay in the base doc. There's also the issue of how this dovetails with the DKIM Best Practices document that the AntiSpam Research Group is planning to do, and John Levine will work with Tony to sort that out. Doug Otis presented his proposal about opaque IDs and signing roles. Tony briefly talked about a test message corpus that's available for implementors to use to test their implementations. -- Barry Leiba, DKIM co-chair (leiba@watson.ibm.com) http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam From tim.polk@nist.gov Thu Mar 23 11:38:50 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.12.8p2/8.12.8) with ESMTP id k2NGcoLE006906 for ; Thu, 23 Mar 2006 11:38:50 -0500 Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id k2NGcmjB024715 for ; Thu, 23 Mar 2006 11:38:48 -0500 (EST) Received: from real2.localdomain ([192.168.2.11]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k2NGck95023177 for ; Thu, 23 Mar 2006 11:38:46 -0500 Received: from real2.localdomain (real2.localdomain [127.0.0.1]) by real2.localdomain (8.12.8/8.12.8) with ESMTP id k2NGckq0031218 for ; Thu, 23 Mar 2006 11:38:46 -0500 Received: (from apache@localhost) by real2.localdomain (8.12.8/8.12.8/Submit) id k2NGcjcT031216 for saag@mit.edu; Thu, 23 Mar 2006 11:38:45 -0500 Received: from DHCP-Wireless-129-112.ietf65.org (DHCP-Wireless-129-112.ietf65.org [130.129.129.112]) by webmail.nist.gov (IMP) with HTTP for ; Thu, 23 Mar 2006 11:38:45 -0500 Message-ID: <1143131925.4422cf15e491d@webmail.nist.gov> Date: Thu, 23 Mar 2006 11:38:45 -0500 From: tim.polk@nist.gov To: saag@mit.edu MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.1 X-Originating-IP: 130.129.129.112 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: tim.polk@nist.gov X-Spam-Score: 0.55 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] PKIX Working Group Summary, IETF 65 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2006 16:38:51 -0000 This is a brief summary of the PKIX session at IETF 65. ---------------------------------------------------------------------------- The majority of the PKIX session was devoted to algorithm agility. PKIX formats and protocols are basically algorithm neutral. Cryptographic algorithms are specified using globally unique algorithm identifiers, and there are no issues regarding key or signature sizes. The algorithm suite for PKIX is currently incomplete, though. While SHA-2 is well specified for RSA, the WG has not completed documents describing the use of DSA and ECDSA with SHA-2. Publication of the draft FIPS 186-3, which specifies DSA with larger key sizes, has removed a major impediment, so a new ID covering this topic will be published immediately following this meeting. However, the PKIX protocols do not, as a general rule, incorporate explicit techniques for signaling cryptographic requirements. Where protocol participants do not agree on algorithm selection, the error messages do not include any facilities for specifying acceptable algorithms. Since many PKIX protocol participants have out-of-band relationships, protocol designers had apparently assumed algorithm selection was known. The working group is currently discussing where algorithm agility is needed in the PKIX protocol suite. The draft SCVP protocol is a notable exception to this rule, but even this protocol has limitations in signaling. The editors have added explicit signaling covering signature generation, verification, hash selection, and kdfs for key management. Because OIDs are used for this signaling, there is no way to state key length constraints associated with given algorithms. For example, there is no way to say that a given server will not verify signatures generated with keys smaller (or larger) than some specified size. The to-do list for agility: think about signaling some more, develop a general strategy, apply to PKIX protocols, document the underlying assumptions about algorithm agility for our protocols. Beyond agility, the PKIX WG is focused on completion of SCVP and advancement of key specifications. Most current IDs are mature, and are either in Last Call or are about to be in Last Call. Compilation of interoperability reports for key specifications will probably be a focus area for Montreal. From ekr@networkresonance.com Thu Mar 23 11:40:58 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.12.8p2/8.12.8) with ESMTP id k2NGewLE007252 for ; Thu, 23 Mar 2006 11:40:58 -0500 Received: from delta.rtfm.com (DHCP-Wireless-132-45.ietf65.org [130.129.132.45]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id k2NGeqhe006349 for ; Thu, 23 Mar 2006 11:40:52 -0500 (EST) Received: from networkresonance.com (delta.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 02B8EB811; Thu, 23 Mar 2006 08:40:52 -0800 (PST) To: saag@mit.edu X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 18) Date: Thu, 23 Mar 2006 08:40:51 -0800 From: Eric Rescorla Message-Id: <20060323164052.02B8EB811@delta.rtfm.com> X-Spam-Score: -2.464 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: tls@ietf.org Subject: [saag] TLS WG Summary X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2006 16:40:58 -0000 The TLS WG met at 1:00 PM on Wed Mar 22. Topics covered: Brian Minard: draft-dugal-tls-ecmqv-00 Brian Minard presented an ECMQV cipher suite for TLS. ECMQV is an authenticated elliptic curve key establishment protocol that is part of NSA Suite B. Discussions centered around IPR issues for ECMQV: Certicom has an IPR statement that includes some royalty-free licensing, but it's not entirely clear what the status of certificates containing these keys is. Minard to check and report back. Nagendra Modadugu: draft-ietf-tls-ctr-00 TLS AES Counter Mode is already a work item of the WG. This document is ready modulo a Security Considerations section. A new draft will be generated and put out for WG Last Call. Russ Housley: draft-housley-tls-authz-extns-00 This draft is a mechanism for negotiating the carriage of some kinds of authentication data (Attribute Certs and SAML Assertions, etc.) in the TLS handshake. Russ presented a mechanism for a general payload type for all such data and then a specific set of extensions for particular types. This is also intended to resolve last call comments on draft-santesson-tls-ume, which can use the same payload type. Stefan Santesson will be drafting the draft for this payload. Yngve Petterson: Interoperability Yngve Petterson presented on a bunch of interop problems people are seeing in TLS 1.1, TLS 1.0, and extensions. It's a bit scary. There was some talk of him doing a draft on this, but no commitment. Magnus Westerland: draft-ietf-mmusic-rfc2326bis-12 RTSP makes some innovative uses of TLS. They would like review. People committed. EKR: draft-ietf-tls-rfc4346bis-00 TLS has a charter item for TLS 1.2 which is hash replacements, in particular for the PRF and digitally-signed messages. There had been discussion on the mailing list of whether this was a good idea. There was strong consensus in the room for both doing TLS 1.2 *and* being able to negotiate new PRFs such as NIST 800-56 and GOST. We agreed to confirm on the mailing list. -Ekr From quittek@netlab.nec.de Thu Mar 23 14:05:16 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.12.8p2/8.12.8) with ESMTP id k2NJ5GLE003758 for ; Thu, 23 Mar 2006 14:05:16 -0500 Received: from kyoto.netlab.nec.de (kyoto.netlab.nec.de [195.37.70.21]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id k2NJ53Zf014589; Thu, 23 Mar 2006 14:05:05 -0500 (EST) Received: from dhcp-wireless-132-169.ietf65.org (unknown [130.129.132.169]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 0F4601BAC9E; Thu, 23 Mar 2006 20:03:42 +0100 (CET) Date: Thu, 23 Mar 2006 20:05:05 +0100 From: Juergen Quittek To: housley@vigilsec.com, hartmans-ietf@mit.edu, isms@ietf.org Message-ID: X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: [saag] ISMS IETF65 session summary X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2006 19:05:16 -0000 The ISMS discussed the open issues concerning the transport mapping security model and SSH security model that were identified at the interim meeting in February. Most of them are concerning SNMP notifications. For all issues full or partial solutions were proposed and the documents will be updated accordingly. For the remaining two documents (radius integration and applicability statement), first versions are scheduled in April. Juergen From ldondeti@qualcomm.com Thu Mar 23 13:16:58 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.12.8p2/8.12.8) with ESMTP id k2NIGwLE026810 for ; Thu, 23 Mar 2006 13:16:58 -0500 Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id k2NIGvjB017839 for ; Thu, 23 Mar 2006 13:16:57 -0500 (EST) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k2NIGuad015981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 23 Mar 2006 10:16:56 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-69-55.qualcomm.com [10.50.69.55]) by magus.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k2NIGrme011604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 Mar 2006 10:16:54 -0800 (PST) Message-Id: <6.2.5.6.2.20060323101041.040d1ab8@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 23 Mar 2006 10:16:51 -0800 To: saag@mit.edu From: Lakshminath Dondeti In-Reply-To: <20060323164052.02B8EB811@delta.rtfm.com> References: <20060323164052.02B8EB811@delta.rtfm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id k2NIGwLE026810 X-Mailman-Approved-At: Thu, 23 Mar 2006 14:24:16 -0500 Cc: canetti Subject: [saag] MSEC report X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2006 18:16:58 -0000 MSEC has done the following since the Vancouver meeting: RFC Published: ­draft-ietf-msec-bootstrapping-tesla (RFC 4442) RFC Ed queue: ­draft-ietf-msec-policy-token-sec -draft-ietf-msec-newtype-keyid WGLC, in progress: -draft-ietf-msec-mikey-rsa-r Want to take this opportunity to thank Russ for being very proactive and being on top of things in helping us move our documents along. On behalf of the MSEC contributors, I appreciate that very much. Meeting update: ----------------- * MSEC IPsec extensions work is almost ready for IPSEC mailing list review. Stay tuned for that. * GDOI (RFC 3547) is being revised. Focused PSrev for algorithm agility, for providing clarifications, to fix a security hole and finally to introduce AH support. * Hash function analysis half-way done. GDOI, TESLA, some MIKEY mode related work is completed. GDOI requires a PSrev and that's being done. GSAKMP and MIKEY reviews are pending. * MIKEY applicability draft is being written to explain the various MIKEY modes and to provide guidance on what modes might be applicable in various use cases. * Some new TESLA related work is being taken up, and the chairs plan to write MSEC roadmap document. * We plan to meet in Montreal and at the next meeting also, and try to finish everything by the end of year. Action items: * IPsec extensions to be posted to IPSEC list * Update Milestones after we achieve WG consensus on new documents (MIKEY applicability, GDOI update, ALC/TESLA, MSEC roadmap, IPsec-TESLA) * RAI followup regarding MIKEY From paul.hoffman@vpnc.org Thu Mar 23 17:42:37 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.12.8p2/8.12.8) with ESMTP id k2NMgbLE015286 for ; Thu, 23 Mar 2006 17:42:37 -0500 Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id k2NMcH2D007917 for ; Thu, 23 Mar 2006 17:38:18 -0500 (EST) Received: from [198.18.100.117] ([12.5.73.162]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2NMcERG015425 for ; Thu, 23 Mar 2006 15:38:16 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Thu, 23 Mar 2006 16:38:19 -0600 To: saag@mit.edu From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] MOBIKE meeting summary X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2006 22:42:37 -0000 MOBIKE had a short meeting. Our document status is: - draft-ietf-mobike-protocol-08.txt accepted as a Proposed Standard on 3/3/06 - draft-ietf-mobike-design-08.txt being reviewed by Russ Housley, AD, as of 3/15/06 We had a presentation on BEET (draft-nikander-esp-beet-mode) as a possible fulfillment for our compressed header charter item. We discussed how to proceed as a Working Group. We discussed extending the WG charter to cover transport more IPsec. After an inconclusive consensus call, we agreed to discuss this on the mailing list. Our decision will be based whether people think it is actually feasible to use transport mode for a MOBIKE-like protocol, what the advantages of transport mode will be, and whether there will be document authors. --Paul Hoffman, Director --VPN Consortium From cwallace@orionsec.com Thu Mar 23 18:14:22 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.12.8p2/8.12.8) with ESMTP id k2NNEMLE019455 for ; Thu, 23 Mar 2006 18:14:22 -0500 Received: from EXVS01.ex.dslextreme.net (exvs01.ex.dslextreme.net [66.51.199.51]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id k2NNEF2D027841; Thu, 23 Mar 2006 18:14:15 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Thu, 23 Mar 2006 15:14:10 -0800 Message-ID: <82D5657AE1F54347A734BDD33637C87901DE9FAB@EXVS01.ex.dslextreme.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LTANS summary, IETF 65 thread-index: AcZOz34tplrDHu8hS0C3R2cJn8aKYA== From: "Carl Wallace" To: , X-Spam-Score: 0 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id k2NNEMLE019455 X-Mailman-Approved-At: Sun, 26 Mar 2006 00:24:20 -0500 Cc: hartmans-ietf@mit.edu, housley@vigilsec.com Subject: [saag] LTANS summary, IETF 65 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2006 23:14:22 -0000 During the LTANS session, three drafts were discussed, WG milestones were reset and work on notarization was suspended. The ERS status briefing highlighted changes that will be present in the upcoming -06 draft. These changes primarily address clarity with regard to the encryption mechanisms in the spec as well as support for multiple timestamp formats. A defect in the encoding of a sample message posted to the mailing list was discussed. The corresponding structure may be refactored for clarity (without changing the wire representation of the structures). The specification will be submitted for WG last call upon release. An XML corollary may be prepared after WG last call. No algorithm agility issues have been noted with regard to ERS. The LTAP specification was discussed. A high level system design was provided along with an abstract view of the contents of an archived data object. The specification currently features syntax in both XML and ASN.1. Work is ongoing with current focus on defining the data necessary for archiving and ensuring lifecycle requirements are accurately identified and addressed. Algorithm agility will be addressed as work on this specification progresses. A new draft that defines directory-based mechanisms for preserving PKI artifacts was discussed. Coordination with the PKIX working group is required if work defining extensions and semantics for use of an "historical CRL" is to proceed. The milestones for the WG will be reset. WG Last Call for ERS will commence immediately upon the release of version -06. A new version of LTAP will be produced by the end of April with WG Last Call sought by the end of the year. The PKI Artifact Retention and SCVP/ERS drafts will be revised by the end of April with WG Last Call targeted for August. Work on notary specifications has been suspended due to lack of interest. Assuming these goals are achieved, the working group will shutdown by April 2007. A summary of action items can be found in the meeting minutes here: http://tools.ietf.org/wg/ltans/minutes. The Jabber log for the session can be found here: http://www.ietf.org/meetings/ietf-logs/ltans@rooms.jabber.ietf.org/2006- 03-20.html. From hsantos@santronics.com Fri Mar 24 08:29:26 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.12.8p2/8.12.8) with ESMTP id k2ODTQLE028140 for ; Fri, 24 Mar 2006 08:29:26 -0500 Received: from winserver.com (winserver.com [208.247.131.9]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id k2ODTJcF001872 for ; Fri, 24 Mar 2006 08:29:19 -0500 (EST) Received: by winserver.com (Wildcat! SMTP Router v6.1.451.7) for saag@mit.edu; Fri, 24 Mar 2006 08:29:33 -0500 Received: from hdev1 ([72.144.139.172]) by winserver.com (Wildcat! SMTP v6.1.451.7) with ESMTP id 155394578; Fri, 24 Mar 2006 08:29:31 -0500 Message-ID: <003a01c64f46$dceb9710$0201a8c0@hdev1> From: "Hector Santos" To: "DKIM Chair" , "IETF-DKIM" References: <9FDEAD9885C9F556FFA13FF5@saturn.watson.ibm.com> Date: Fri, 24 Mar 2006 08:28:36 -0500 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: -2.6 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 X-Mailman-Approved-At: Sun, 26 Mar 2006 00:24:20 -0500 Cc: saag@mit.edu, dkim-ads@tools.ietf.org, dkim-chairs@tools.ietf.org Subject: Re: [saag] [ietf-dkim] DKIM Working Group Summary, IETF 65 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2006 13:29:55 -0000 Would it make sense to break these up into separate threads? Anyway, here is my comments on some of these issues. ----- Original Message ----- From: "DKIM Chair" To: > * Issue: "r=" tag, specifying a "report-to" entity. Defer consideration > to SSP document, but then we considered whether to also have it in the > key record (or something reachable through the selector). Further > discussion to go to the mailing list. Personally, I like the idea of having a possible (by default) fixed notification common name (user part), such as one of following names: DKIM-ABUSE (My preference, since ABUSE is already required) DKIM-POSTMASTER DKIM-ADMIN DKIM-SYSOP etc. Dave Crocker's RFC 2142 can serve as a guide. Just a small note about operation consideration: The r= report address must be legitimate and acceptable. If a DKIM verifier attempts to send a report, it can learn very quickly if it is just a fraudulent address. So if not acceptable, it can become a source for putting more weight on a bad message. Some guidance should be provided for possible actions to take, i.e, stop sending future reports. > * Issue: transition plan for new crypto algorithms, and specifically, > transition from SHA-1 to SHA-256 hashes. Some discussion here, but > discussion ultimately deferred to the general issue of multiple > signatures. Consensus among the security folks is to let the verifier > decide which crypto is "best". I like the idea or the potential to offer high-value domains the ability to secure their operations by doing one or more of the following: 1) Assign domain owned user addresses for communications, 2) Joint venture, collaborate, outsource with a ESP that has the DKIM security we are looking for, and assign the user a special ESP domain controlled address. 3) During the user account sign-up we will automatically find out if the target domain offers the security we are looking for. In my view, the idea that high-value domains will place their faith on signing messages and then "cross their fingers" that it will be correctly be supported seems me to be a little unrealistic. This touches base with the following: > Jim Fenton introduced the signing policy/practices proposal and issues; > after the base document, we'll be attacking this in earnest. The name > is still in flux, with some thinking that "policy" is not the right > term, others thinking that "practices" isn't either. We were pointed to > some work called DDDS that's been introduced in the speermint working > group, which might help us with the work (not with the naming), so > we'll have a look at that. Practice? I would hope that everyone practices a safe DKIM Sender Signing Policy! :-) Labeling it as a "Sender Signing Practice" doesn't sound right. hmmmm, maybe it is obvious by now, but it should be highlighted that there seems to be two camps here in regards to SSP: - Those who think SSP is not necessary - Those who think SSP is vital to DKIM I think it is required. The specs has a natural presumption of a SSP Neutral policy (Missing SSP key defaults to NEUTRAL, o=~, policy). This is very important. Even if a domain doesn't define a SSP key, he is telling the world he is NEUTRAL. He doesn't care what happens to the message. What I seek operationally, is that everyone follows SSP verification/authorization whether one defines SSP record or not. The protection in DKIM comes when every piece of software is expected to practice SAFE SSP. So that if a DOMAIN says: "We don't send mail" "We never sign mail" "No 3rd party SHOULD ever sign our messages" etc, etc, it is vitally important that the domain policy, definition, "practice" or requirement, whatever we wish to call it, that we honor that security. I don't understand why we would want to ignore this fundamental domain security? So whatever we want to call it, to me, it a small moot point over what how we expect to use it. If it isn't require to be honored than what's the point? That said, I think ideas like DDDS and similar concepts is a step in the right direction. SSP will offer ways to resolve so many issues of "expectation" in a highly chaotic world of mail transactions. So whether its DDDS, SSP or what I call TMS (Transaction Management System), domains can learn more about who they are sending data to, as well as domains can learn about those they are receiving mail from. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com From kent@bbn.com Mon Mar 27 12:12:17 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k2RHCHvt000696 for ; Mon, 27 Mar 2006 12:12:17 -0500 Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k2RHCH2P002726 for ; Mon, 27 Mar 2006 12:12:17 -0500 (EST) Received: from col-dhcp33-244-180.bbn.com ([128.33.244.180]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1FNvGL-00048Z-4F; Mon, 27 Mar 2006 12:12:17 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 27 Mar 2006 12:11:50 -0500 To: Paul Hoffman From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] MOBIKE meeting summary X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2006 17:12:21 -0000 At 4:38 PM -0600 3/23/06, Paul Hoffman wrote: >MOBIKE had a short meeting. > >Our document status is: >- draft-ietf-mobike-protocol-08.txt accepted as a Proposed Standard on 3/3/06 >- draft-ietf-mobike-design-08.txt being reviewed by Russ Housley, AD, >as of 3/15/06 > >We had a presentation on BEET (draft-nikander-esp-beet-mode) as a >possible fulfillment for our compressed header charter item. Ity might be helpful to review the HCoIPsec I-Ds, which plan to offer header compression for IPsec in general, and thus might be applicable to MOBIKE. Steve From housley@vigilsec.com Wed Mar 29 11:19:17 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k2TGJHRd011886 for ; Wed, 29 Mar 2006 11:19:17 -0500 Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by fort-point-station.mit.edu (8.13.6/8.9.2) with SMTP id k2TGJFEk027537 for ; Wed, 29 Mar 2006 11:19:15 -0500 (EST) Received: (qmail 30650 invoked by uid 0); 29 Mar 2006 16:19:11 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (71.246.201.221) by woodstock.binhost.com with SMTP; 29 Mar 2006 16:19:11 -0000 Message-Id: <7.0.0.16.2.20060329111745.05b8a5a8@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Wed, 29 Mar 2006 11:19:11 -0500 To: saag@mit.edu From: Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] Draft SAAG Meeting Minutes X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2006 16:19:17 -0000 Here are the draft minutes. Please post clarifications and corrections. Many thanks to George for the raw notes. Russ = = = = = = = = = = Security Area Advisory Group (SAAG) IETF65, Dallas, Texas Minutes compiled by George Jones and Russ Housley Agenda WG Session Reports - KRB-WG - LTANS - DKIM - BTNS - S/MIME - PKIX - PKI4IPsec - MSEC - MOBIKE - EMU - ISMS - TLS - SASL BOF Session Reports - HOAKEY Invited Presentations - CAPWAP Security (Scott Kelly) - Authentication for TCP-based Routing and Management Protocols (Ron Bonica) - OATH HOTP C/R (Johan Rydell) - CT-KIP (Dave Mitton) Open Microphone ------------------------------------------------------------------------ WG and BOF Session Reports As usual, the SAAG session began with Working Group and BoF Reports. Each working group or BoF that had a meeting at IETF 65 gave a very brief summary of the session. Please see the minutes for each of these sessions. The highlights are not repeated here. ------------------------------------------------------------------------ CAPWAP Security, Scott Kelly http://www3.ietf.org/proceedings/06mar/slides/saag-1.ppt Introduction - CAPWAP protocol to carry Access Point (AP) configuration/control, network access control decisions, cryptographic session keys, user data, etc. - Security matters, want to solicit security input - Asking for security advisor Background - Fat APs are standalone, individually managed network elements - Station (STA) -> AP -> AS/AAA + MGT CAPWAP Architecture - Combination of the Access Controller (AC) and the Wireless Termination Point (WTP) replace the "Fat AC" functionality - STA -> WTP -> AC -> AS/AAA + MGT - The CAPWAP protocol is used between the WTP and AC Complex Trust Relationships - AAA credential between AC and Authentication Server (AS) - EAP credentials between STA and AS - 802.11i security context (the PTK) between WTP and STA - CAPWAP credential between AC and WTP - Don't want to degrade security of surrounding components Multiple Deployment Models - Direct L2 connection - Routed L3 connection, one administrative domain - Routed L3 connection, over potentially hostile hops CAPWAP Threats - Direct L2 AC as switch: physical security is basic solution - Enterprise deployment: mobile systems invalidate many local LAN security assumptions - Other deployments: -- branch office WTP with central AC -- WTP in home with AC on corporate LAN -- hotspots -- using wireless links between WTP and AC - Threat mitigation requires strong crypto, mutual authentication, data integrity, and in many cases, confidentiality - CAPWAP not planning to secure data channel -- security only related to control plane -- some talk, but lots of resistance to securing data plane Additional Security Considerations - Need to get crypto keys into device over CAPWAP channel - We don't want CAPWAP to be weak channel/link Protocol Security Requirements - In scope: AC <-> WTP - NOT in scope: -- AC <-> AAA -- STA <-> AAA -- STA <-> WTP -- MGT <-> AC - CAPWAP is not running between STA and AP Current State - Started with 4 vendor proposals - Set up evaluation team, they chose one - Chose LWAPP, which has its own security mechanism, but it is being replaced with DTLS Comparison/Contrast: DTLS vs LWAPP - Most people persuaded Summary - In OPS area, straddles SEC area - IEEE 802 working around edges, IETF can't introduce weakness - Lots of interesting work, need a security POC David Perkins: - AC-to-AC not in charter, but not a big next step - Protocol designed to support things other than 802.11, but charter says 802.11 Dorothy Gellert (CAPWAP WG Co-chair): Some talk of AC-to-AC, but not in charter. No BOFs yet. Craig Labovitz (via Jabber): How realistic is it that people will deploy general (non vendor specific) solution? A: We want to make sure protocol is not the barrier Dorothy Gellert: Many vendors talk about the importance of interoperability. Russ Housley: Will be appointing security advisor in next few days. Volunteers? ------------------------------------------------------------------------ Authentication for TCP Routing and Authentication Protocols, Ron Bonica http://www3.ietf.org/proceedings/06mar/slides/saag-2.ppt Motivation - Most operators not authenticating BCP now - Blind insertion attacks possible - Major carriers and vendors got together, came up with this solution went to TCPM WG, and they asked authors to get input from SAAG RFC2385 current BCP -- TCP MD5 - does not fulfill operator requirements Why operators aren't using it? - CPU - Poor key management -- can cause BGP resets, so avoided - Weak crypto (MD5) Alternative Approaches - 3 possible places -- Application (BGP, TLS...) -- Transport (TCP) -- Network (IKE/IPsec) - Chose transport (TCP) Chosen Approach - New TCP option in all segments - Key ID -- identifies the shared secret - Sending station picks current key, generates MAC, puts key ID and MAC in TCP option - Can use stronger crypto Enhanced Authentication Option - Another draft talks about auto distribution solution Key Chain - What's in a key chain? 64 keys; id; shared secret; vector; out/in/both; two start times, one for send, one for receiving - Windows to compensate for rollover Coming Soon - No PSK, automatically generate a key, distribute Rejected Approach: BGP - Do it in the BGP protocol -- need protection of TCP header Rejected Approach: SSL, TLS - Would not protect TCP session itself - injection, resets still possible Rejected: IKE/IPSec - Most routers configured per interface. With BGP you have no idea which session it will traverse. Operationally complex. Q: (Eric Rescorla) key management good ... have one master key A: That's one possible configuration here Q: One set of keys for all routes, or key pairs per router, How do you handle BGP cross domain? A: All run-time decisions. Q: Does the router's key database say what keys to use for what sessions? A: Run-time decisions on operators part, configurable. Q: (Russ Housley) Are you really saying that IKE/IPsec was rejected because current router implementations are designed to protect user data, not traffic to the router itself. A: Yes. Q: IPSec does not have to be per interface Russ Housley: Implementation shortcoming, not specification shortcoming Q: (Eric Rescorla) Why not new session key on per flow basis? A: See draft-weis-tcp-auth-auto-ks-00; it does that Eric Rescorla: I like to see key management in protocol. Sam Hartman: I am in favor of reusing existing key management protocols. See RFC 4107 on key management, which is a BCP Eric Rescorla: Agree, don't make key management if you can steal one Brian Weis: question for Eric Rescorla Eric Rescorla: use key establishment protocols in TCP Ron Bonica: SSL does not protect TCP session itself. Elliot Lear: If working SSL over SCTP, check SCTPs bits Ron Bonica: Ron looking for go-ahead or objections Russ Housley: Please proceed to replacing TCP MD5, but make sure there is a clear way to transition to automatic key management Ron Bonica: Should we go ahead as interim? Russ Housley: Yes, incremental improvement good. --------------------------------------------------------------- OATH HOTP C/R, Johan Rydell http://www3.ietf.org/proceedings/06mar/slides/saag-3.ppt What is OATH? - Established in 2004 - 60+ members - Neutral stance enables coordination with multiple standard bodies such as IETF, OASIS, W3C, etc. - Goals: Get rid of static passwords -- ubiquitous -- encourage device innovation and embedding -- Reduce cost and complexity of deploying strong authentication -- Open and royalty-free specifications Benefits of open standards - Lots of closed specifications in this area - Openness will drive standard to be implemented and used - Two implementations already Mutual OATH - First presented in December - Based on RFC 4226 - Implemented in smartcards, cell phones, soft/hard tokens - Protect user, protect server - Possibility of doing signatures - Building block Algorithm Identifier - Digest function, truncation, PIN keys, challenge response, modes, key/keys - Current support for 3 Digest functions, more can be added - If you force user to enter long sequence, nobody will use it -- supports truncation - counter, transaction values in protocol Algorithm ID - two way values - Mode is a structure, either Plain or Chained Mode - Key is a structure, either Single, Dual-Computed, or Dual-Stored Standard HOPT - Token displays OTP to user - OTP is sent to server - Server validates OTP, and then accepts/denies - Accept/Deny notification sent to user Mutual Challenge-Response - Token displays OTP to user - Challenge from user to server - Server calculates response, and generates challenge - Server sends response to user challenge and the server's challenge to the user - User enters PIN at token, and then enters server challenge - Token displays response to server challenge - Response to server challenge is sent to server - Server validates response, and then accepts/denies - Accept/Deny notification sent to user Improvements: - Could introduce time-stamp - Could introduce checksum Q: (George Jones) usability question...does this mean user will have to key in two values from a token? A: It depends on your use case. Q: (Eliot Lear) Which of these communications are electrical? Is there a physical interface? A: No, not in standard. C: (Phillip Hallam-Baker) You could do two phase authentication, one to get into account, stronger to validate transfers. Q: (Sam Hartman) What about MITM attacks ? A: You need to have a secure channel Q: If I've had to authenticate the channel already, what do I get out of mutual authentication? A: Challenge itself could prevent MITM Q: Do you specify that? A: (Phillip Hallam-Baker) You're trying to secure two channels: communication and user. You've got two MITM cases: man in network and key-logger. Can use SSL, etc. But security under attack at all points. Can't have one point solution. Need end-to-end, where end is the human, not the computer. Q: (Eliott Lear) Are these standards in flux? How does one participate? A: 2nd draft. See the draft. Give authors feedback. Q: Is there a public mailing list? A: No. We could consider it. C: (Russ Housley) Please let me know now if there is any objection to this document becoming an Informational RFC. --------------------------------------------------------------------- Cryptographic Token Key Initialization Protocol (CT-KIP), Dave Mitton http://www3.ietf.org/proceedings/06mar/slides/saag-4.ppt Background - Client-server protocol for initializing tokens with shared keys - General protocol for setting up, secure provisioning of tokens Objectives - Secure, interoperable, - No PKI needed Message Flow - Optional trigger message - Client Hello - Server Hello - Client Nonce - Server Finished -- includes Server Nonce Principal of operation - Encryption. Server can have PK. Can do shared key. - Used to encrypt data out of server. Client uses servers PK. Status - Protocol for secret keys - Issue: are you erasing previous token - If data is on token, more handshaking OTPS - RSA Laboratories: One-Time Password Specifications (OTPS) program - Open process, no membership required - Open mailing list Other OTPS Documents - Addressing full life cycle -- Provisioning, Retrieval, Transport, Validation - Eight documents so far -- http://www.rsasecurity.com/rsalabs/ -- click OTPS on left side of page Future Work - http://www.ietf.org/internet-drafts/draft-nystrom-ct-kip-00.txt - Will be kept current C: (Russ Housley) A few weeks ago, I posted a notice about this document to the SAAG mail list. Please let me know now if there is any objection to this document becoming an Informational RFC. C: (Russ Housley) I chartered the ENROLL WG to deal with enrollment, including certificates and shared secrets. It failed, and it is now closed. This document deals with enrollment for OTP tokens. Q: (Eliot Lear) Good stuff. Binding to HTTP? How about abstracting so that you can use other protocols. A: Draft uses lots of XML, but not intended to be only web. Q: (Siddharth Bajaj) Interested in lighter weight version. A: (Russ Housley) Would you like WG? Lets talk about a BOF for next time. ----------------------------------------------------------------- Open Microphone Mike Myers: Can protocol authors expect guidance on hash issues? Russ Housley: We did that last time. SHA-1 is weaker than we expected. Dr. Wang now claims 2^62 attack (no paper yet). Last week folks in the Netherlands posted code to find MD5 collisions in less than one minute on a PC. Still headed for SHA-256. NIST not accepting SHA-1 for digital signatures after 2010. Goal to get specifications for SHA-256 in next 18-24 months, which allows time for vendors to ship products before the 2010 deadline. Siddharth Bajaj: Dynamic passwords in Kerberos? Has IETF looked at that? Sam Hartman: Very interested. There are drafts for using OTP with Kerberos. David Perkins: PANA WG should have been described here. Russ Housley: I learned about problems on PANA too late to include it on the agenda for today. Olafur Gudmundsson: Looking at use of ECC in DNSSec, working with IRTF CFRG. Russ Housley: Good posting to CFRG mail list. Hoping for good advice. Q: At RAI area meeting talked about security approaches. Russ Housley: RAI and SEC ADs are going to talk. We have reserved a day in May to get together. Hopefully we can at least frame issues. Q: Interested in small report of what happened at the RAI area meeting? Sam Hartman: Send email. We read it all. Q: HMAC-MD5? Russ Housley: We are out of time. But it is clear that MD5 without HMAC construction is in deep trouble. From hartmans@MIT.EDU Wed Apr 5 16:45:28 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k35KjSDS004998 for ; Wed, 5 Apr 2006 16:45:28 -0400 Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k35KjRwJ006449 for ; Wed, 5 Apr 2006 16:45:27 -0400 (EDT) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 8C246160059; Wed, 5 Apr 2006 16:42:56 -0400 (EDT) To: iab@ietf.org From: Sam Hartman Date: Wed, 05 Apr 2006 16:42:56 -0400 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 1.352 X-Spam-Level: * (1.352) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: [saag] Frameworks, multiple mechanisms and draft-iab-auth-mech-05.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2006 20:45:28 -0000 Hi. I'd like to bring up serious concerns about sections 11.2, 11.3 and 13.2-4 in draft-iab-auth-mech05.txt. I understand that document represents an IAB consensus not an IETF consensus. However I think it would be confusing to people if the IAB publishes recommendations and protocol designers get significant pushback (especially at the IETF last call and IESG review/wg chartering stages) for following the IAB recommendations. I believe that will happen in this instance. I would like to work with the IAB to get the recommendations in line with what I think the community is doing; if that proves impossible I would like to encourage the IAB to add a warning about the conflict. My main concern is that the IAB recommends choosing a small number of mechanisms and clearly stating this minimal set in the protocol specification. I believe that there are cases where it is appropriate to do that. For example, DKIM and most of DNSSEC require everyone on the Internet to use the same mechanisms for authentication. I expect we will see similar issues for infrastructure protocols like BGP. However there are a lot of protocols for which authentication happens within an organization or within a group of cooperating organizations. For these environments related protocol effects and deployment costs are important to consider and the existing IAB recommendations do not adequately address these issues. The major cost in deploying security is deploying new credentials and deploying security infrastructure. If some protocol or program requires my users to all change their passwords so it can store passwords with a different hash function, it will cost me more to deploy. If I'm using passwords and your protocol requires me to purchase tokens for all my users, that is a huge cost both in terms of tokens, user education, help desk costs, etc. Infrastructure cost is important too. If I run everything through radius for authorization and your protocol has an authentication scheme that doesn't work well with radius, that is a problem. I'm depending on radius for authorization, for my accounting and to give me one central location for my credentials. Similarly if all you support is RADIUS and I'm a Kerberos deployment, then I'm going to have huge costs deploying your protocol. (As a practical matter, supporting RADIUS means supporting http digest auth or plaintext passwords. I do realize that protocols do not typically support RADIUS directly.) The important thing to remember here is that these costs depend on what the organization considering adopting your protocol has already deployed. We have significant evidence that people will avoid security features in protocols rather than deploying new security infrastructure. I think it is true that people will even choose avoiding certain protocols rather than deploying new security but I have less evidence for that. We have many examples of protocols that started out with a small number of mechanisms just as the IAB suggests they should but that have had to add support for a framework so they would be deployable. An obvious example is SNMP. We formed the isms working group to add support for more authentication mechanisms because operators found that SNMP did not support the authentication mechanisms they were using. AS a result, we have added support for the ssh framework. The mechanisms in SNMP were not bad. It did use shared keys, but the key management was well designed. Operators simply did not have that infrastructure deployed and id not want to deploy a new security infrastructure when they already had one deployed. We've seen the need to add support for existing security infrastructures to other protocols. For example one of the things that Jabber wanted to do as part of the XMPP transition was add support for new security mechanisms. There existing mechanisms were weak. But they explicitly wanted to be able to have framework support so they could match security to what was available in deployed environments. Protocols like POP and IMAP started out with one simple mechanism: plaintext passwords. That is still the dominant mechanism used. However enough deployment environments have needed support for mechanisms specific to those environments that SASL was invented to solve a perceived need. Perhaps you can argue that SASL was unnecessary complexity and that IMAP should have just added an authchallenge and authkerberos command (with no specific command needed for certificates). But then why was SASL adopted in other protocols like POP and SMTP? Why has it been successful? Of course the apps and ops areas are not the only place where deployment constraints have made it useful to add support for authentication frameworks. IKE V2 ended up supporting EAP because it was needed for environments where certificate authentication was not sufficient. So, I think there is more work to do in these sections. In particular, I think that you should read this document and come away with the impression that it will be common for you to end up at SASL+TLS as a solution for typical client-server applications without special requirements and end up with EAP as a solution for network access applications. We can work through (or the IAB can work through without input) whether there are constraints I'm not aware of now, but the current text seems deeply suspect. If I follow the current text I would get the impression that either most of the existing work in the IETF is a corner case or it has been done wrong. I believe neither of those statements. Another problem is with the idea that protocols should support multiple mechanisms but that they should not use an existing framework. Designing facilities to allow multiple authentication mechanisms in a protocol is hard--I think possibly just as hard as designing an authentication mechanism. I am just as worried about a proliferation of mechanisms to select authentication mechanisms as I am about authentication mechanisms. If you need more than one authentication mechanism in your protocol, you should have good justification for why you are inventing negotiation yourself. It's taken a long time to get EAP, SASL and GSSAPI right; we should not encourage people to repeat this work badly unless their requirements are actually differently. I don't think simplicity is a sufficient argument in many cases, because we have a history over time of finding that the simple solutions are not good enough. So, here are some specific concerns: In section 11, the document claims that frameworks are attractive to protocol designers because they theoretically allow them to ignore security issues. I think that wording misses the actual benefits of the frameworks. When properly used, frameworks allow protocol designers to treat mechanism-specific details in an abstract manner. You need to deal with security issues: does your protocol require integrity? Is protection against active attacks important? What are the names of the endpoints of the connection? However you don't have to deal with details like how do I find that KDC or what is the information that the latest rev of example.com's proprietary authentication token requires? Note that this detail hiding is for protocol designers, not for implementers. It is possible to hide mechanism implementation details from protocol implementations but doing so requires a lot more work. For successful examples of this take a look at Windows SSPI or Cyrus SASL. (Windows is much more successful than Cyrus.) Another example of successfully using a framework to hide both implementation and protocol details is SAP R3. R3 uses GSS-API for its security services. The application successfully uses a wide variety of mechanisms not available to SAP. SAP provides a GSS conformance test; mechanisms that pass this test are likely to work. Frameworks are interesting to security designers because they can get support for their mechanism in multiple protocols by writing one specification. Having worked with Kerberos for 10 years, I can say that it is much easier to get support into frameworks than to write specifications for each protocol you might care about. Section 11.1: Another solution to downgrade attacks is to cache state about the endpoint. If an endpoint has previously offered a digest mechanism but now only offers plaintext passwords, then this indicates a problem. Another solution is to only offer mechanisms that cannot protect the negotiation over TLS or other channels where the server is authenticated. Section 11.2: The reason that you see similar mechanisms for things like otp, secureid, etc is that you have deployed infrastructure. Telling me to use digest when I have OTP credentials deployed everywhere is just not a reasonable option. Also, note that many of these mechanisms are not standards track. I strongly disagree with the following sentence because I believe it leads to protocols that cannot be deployed: > While the desire to support legacy authentication systems is under- > standable, it should be resisted to the extent possible. Also, I question the term legacy in this instance. Section 11.3: I believe almost all the specific examples are wrong here and so I question the general principle. I believe there is a strong consensus in the Kerberos community that GSSAPI should be used in preference to raw Kerberos where possible. The krb-priv and krb_safe messages in RFC 4120 are documented mostly for legacy reasons. There is significantly less implementation of these messages than RFC 4121 and RFC 1964. There are significant interoperability problems with krb_safe. So, where the GSS-API Kerberos mechanism is appropriate, it should be used. Using RFC 4121 is not less efficient than using raw kerberos. Often it decreases application and protocol design complexity and increases application portability. I see no evidence that GSS-API has increased deployment complexity over raw Kerberos. Note that the SASL Kerberos mechanisms are not on standards track. I don't think that the IETF would support publication of a kerberos_v5 mechanism as a standards track mechanism because of the existing gssapi mechanism. Similarly, SASL and GSS work quite well together. GSS is more flexible in what applications it supports: it supports datagram applications and applications for which tokens can be re-ordered. However SASL fills in a lot of details that will be static for client-server applications with single TCP connections. Also, SASL+GSS ends up being easier to integrate into protocol specifications than GSS. This is basically because GSS is more flexible. The strategy of designing GSS mechanisms but designing SASL applications works quite well. It is a bit harder than designing SASL mechanisms because GSS requires mechanism designers to think more about naming and handling of out-of-order packets than SASL. I have not heard significant claims that GSS over SASL is harder to deploy or implement than raw SASL. In fact there is evidence such as GNU's mailtools or Eudora's GSS support that suggests the opposite. Claiming that EAP TLS is a bad idea goes against a recent IETF consensus to move it onto the standards track. EAP TLS is explicitly a work item of EMU. The current text implies that in order to avoid layering new PPP authentication methods should not use EAP. I believe that goes against a strong internet area consensus and against IETF consensus. I disagree with the following text: > In accordance with the principle of having as few mechanisms as > pos- sible, frameworks should avoid mechanisms that are themselves > frame- > works, in favor of using the second framework's mechanisms > directly. > "We'll build ours on top of theirs" is a bad policy. I think a better approach is that there should only be one generally accepted path to a particular mechanism. I.E. There should be one way of doing Kerberos in SASL; it should be easy to find out what that is. There is not a good reason it needs to be Kerberos directly on top of SASL. Letting the framework communities design requirements for this is more appropriate than the IAB legislating requirements. Another requirement might be that if you are going to add a new mechanism it should be clear which layer you add it at. Section 11 is missing a discussion of the multi-layer negotiation problem. There is a significant possibility of downgrade attack or selection of the wrong mechanism if you use negotiations at multiple layers. This is why the SASL GSS mechanism recommends against use of the GSSAPI negotiation. Similarly this is why draft-ietf-secsh-gss-kex forbids the GSS negotiation mechanism. Section 11.4: You are missing Ssh and TLS as frameworks. I can see an argument that TLS is not a framework, but ssh clearly has two authentication frameworks: the key exchange mechanism and the userauth mechanisms. Section 13.2. I think I've outline why this argument does not lead to reasonable results previously. I would hold a discuss on a document that followed the advice in section 13.2 and limited the mechanisms that could be used from a generic framework to a specific set. It is fine to limit to mechanisms that meet certain requirements such as providing confidentiality or providing protection against active attacks. It is fine to have a mandatory to implement set of mechanisms. In the case of SASL I would argue it goes against the architecture to have mechanism-specific information such as specific mechanism restrictions in a protocol. In the case of GSS, the argument would be weaker. Such restrictions tend to lead to mechanism-specific details making their way into protocols. That layering violation makes it harder to revise mechanisms in the future or to change the set of appropriate mechanisms. Our experience has demonstrated that we are likely to need to change the set of mechanisms over time. Section 13.3 I think this advice needs to be constrained. As a deployment reality simple passwords are often a requirement. I think the best we can do is avoid simple passwords over unauthenticated channels. If we are going to avoid simple passwords, why do we explicitly charter new work like EMU's password mechanism? Section 13.4: Please warn people before recommending they just use IPsec to protect their channel. We've had significant trouble with doing this in the past. The OSPF authentication draft; L2TP's IPsec support; Iscsi's IPsec support; IPsec for L*VPN have all been challenging. Please at least include a pointer to draft-bellovin-use-ipsec (presumably informative so it does not block your document) and mention that many details need to be worked through and that IPsec is difficult to use for application security. --Sam From ekr@raman.networkresonance.com Wed Apr 5 17:34:32 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k35LYWZF013801 for ; Wed, 5 Apr 2006 17:34:32 -0400 Received: from raman.networkresonance.com (raman.networkresonance.com [198.144.196.3]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k35LYTw8016949; Wed, 5 Apr 2006 17:34:30 -0400 (EDT) Received: by raman.networkresonance.com (Postfix, from userid 1001) id F04561E8C1C; Wed, 5 Apr 2006 14:34:28 -0700 (PDT) To: Sam Hartman References: From: Eric Rescorla Date: Wed, 05 Apr 2006 14:34:28 -0700 In-Reply-To: (Sam Hartman's message of "Wed, 05 Apr 2006 16:42:56 -0400") Message-ID: <86psjvemfv.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.18 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, iab@ietf.org Subject: Re: [saag] Frameworks, multiple mechanisms and draft-iab-auth-mech-05.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Reply-To: EKR List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2006 21:34:33 -0000 Sam Hartman writes: > Hi. I'd like to bring up serious concerns about sections 11.2, 11.3 > and 13.2-4 in draft-iab-auth-mech05.txt. I understand that document > represents an IAB consensus not an IETF consensus. However I think it > would be confusing to people if the IAB publishes recommendations and > protocol designers get significant pushback (especially at the IETF > last call and IESG review/wg chartering stages) for following the IAB > recommendations. I believe that will happen in this instance. I > would like to work with the IAB to get the recommendations in line > with what I think the community is doing; if that proves impossible I > would like to encourage the IAB to add a warning about the conflict. I wanted to acknowledge your message here. Although I do agree with a fair bit of what you've written, needless to say I disagree with much of it as well. However, it's going to take me some time to get around to responding in the detail it deserves. One thing I think is worth noting right off the bat, however, is that a number of your arguments are of the form of "this document disrecommends X but we're doing X now". I certainly agree with that as a descriptive statement, but in many cases I think X is bad and we *shouldn't* be doing it now regardless of whether we are. So, I think the discussion will have to be on the merits of the practices themselves, rather than what the Security Area happens to have been willing to accept. -Ekr From nw141292@binky.Central.Sun.COM Wed Apr 5 17:53:48 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k35Lrm7J017254 for ; Wed, 5 Apr 2006 17:53:48 -0400 Received: from nwkea-mail-5.sun.com (nwkea-mail-5.sun.com [192.18.42.27]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k35LreLI021597; Wed, 5 Apr 2006 17:53:41 -0400 (EDT) Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-5.sun.com (8.12.10/8.12.9) with ESMTP id k35Lrd9F011080; Wed, 5 Apr 2006 14:53:39 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k35Lrccc023740; Wed, 5 Apr 2006 15:53:39 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k35Lrcl3005154; Wed, 5 Apr 2006 16:53:38 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k35Lrcoe005153; Wed, 5 Apr 2006 16:53:38 -0500 (CDT) Date: Wed, 5 Apr 2006 16:53:38 -0500 From: Nicolas Williams To: EKR Message-ID: <20060405215337.GJ2895@binky.Central.Sun.COM> References: <86psjvemfv.fsf@raman.networkresonance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86psjvemfv.fsf@raman.networkresonance.com> User-Agent: Mutt/1.5.7i X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, iab@ietf.org, Sam Hartman Subject: Re: [saag] Frameworks, multiple mechanisms and draft-iab-auth-mech-05.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2006 21:53:49 -0000 On Wed, Apr 05, 2006 at 02:34:28PM -0700, Eric Rescorla wrote: > One thing I think is worth noting right off the bat, however, > is that a number of your arguments are of the form of "this document > disrecommends X but we're doing X now". I certainly agree with > that as a descriptive statement, but in many cases I think X > is bad and we *shouldn't* be doing it now regardless of whether > we are. So, I think the discussion will have to be on the merits > of the practices themselves, rather than what the Security Area > happens to have been willing to accept. It may be that the IAB has discretion to make this kind of statement, but I think it'd be doing a great disservice to the IETF as a whole. I would much rather the IAB make statements like "X is applicable in Y situations" than recommend against X just because it doesn't apply (perhaps purely as a matter of perception, perhaps more concretely) to situations of interest to the IAB. Also, IF the applicability of X is changing as a result of ongoing work then recommending against X as though that work was not ongoing kicks the legs out from under those who are doing that work, unnecessarily so when the IAB could acknowledge that work and state something more like "X is not currently recommended for Y, but there is ongoing work at the IETF that may cause this recommendation to change in the future." Nico -- From ekr@raman.networkresonance.com Wed Apr 5 17:57:14 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k35LvEtT017741 for ; Wed, 5 Apr 2006 17:57:14 -0400 Received: from raman.networkresonance.com (raman.networkresonance.com [198.144.196.3]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k35LvAJt017058; Wed, 5 Apr 2006 17:57:11 -0400 (EDT) Received: by raman.networkresonance.com (Postfix, from userid 1001) id 819081E8C21; Wed, 5 Apr 2006 14:57:10 -0700 (PDT) To: Nicolas Williams References: <86psjvemfv.fsf@raman.networkresonance.com> <20060405215337.GJ2895@binky.Central.Sun.COM> From: Eric Rescorla Date: Wed, 05 Apr 2006 14:57:10 -0700 In-Reply-To: <20060405215337.GJ2895@binky.Central.Sun.COM> (Nicolas Williams's message of "Wed, 5 Apr 2006 16:53:38 -0500") Message-ID: <86ek0bele1.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.18 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, iab@ietf.org, Sam Hartman Subject: Re: [saag] Frameworks, multiple mechanisms and draft-iab-auth-mech-05.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Reply-To: EKR List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2006 21:57:15 -0000 Nicolas Williams writes: > On Wed, Apr 05, 2006 at 02:34:28PM -0700, Eric Rescorla wrote: >> One thing I think is worth noting right off the bat, however, >> is that a number of your arguments are of the form of "this document >> disrecommends X but we're doing X now". I certainly agree with >> that as a descriptive statement, but in many cases I think X >> is bad and we *shouldn't* be doing it now regardless of whether >> we are. So, I think the discussion will have to be on the merits >> of the practices themselves, rather than what the Security Area >> happens to have been willing to accept. > > It may be that the IAB has discretion to make this kind of statement, > but I think it'd be doing a great disservice to the IETF as a whole. I > would much rather the IAB make statements like "X is applicable in Y > situations" than recommend against X just because it doesn't apply > (perhaps purely as a matter of perception, perhaps more concretely) to > situations of interest to the IAB. > > Also, IF the applicability of X is changing as a result of ongoing work > then recommending against X as though that work was not ongoing kicks > the legs out from under those who are doing that work, unnecessarily so > when the IAB could acknowledge that work and state something more like > "X is not currently recommended for Y, but there is ongoing work at the > IETF that may cause this recommendation to change in the future." What I'm talking about is design decisions that were bad from day one and still are bad. The fact that they happen to be widely used doesn't make them any less bad. Case in point (though not strictly relevant to this document): WEP. -Ekr From nw141292@binky.Central.Sun.COM Wed Apr 5 18:00:39 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k35M0dW8018090 for ; Wed, 5 Apr 2006 18:00:39 -0400 Received: from nwkea-mail-5.sun.com (nwkea-mail-5.sun.com [192.18.42.27]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k35M0Zc7001261; Wed, 5 Apr 2006 18:00:36 -0400 (EDT) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-5.sun.com (8.12.10/8.12.9) with ESMTP id k35M0Z9F013658; Wed, 5 Apr 2006 15:00:35 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k35M0Vdc008938; Wed, 5 Apr 2006 16:00:35 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k35M0RJY005177; Wed, 5 Apr 2006 17:00:27 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k35M0Rxv005176; Wed, 5 Apr 2006 17:00:27 -0500 (CDT) Date: Wed, 5 Apr 2006 17:00:27 -0500 From: Nicolas Williams To: EKR Message-ID: <20060405220027.GL2895@binky.Central.Sun.COM> References: <86psjvemfv.fsf@raman.networkresonance.com> <20060405215337.GJ2895@binky.Central.Sun.COM> <86ek0bele1.fsf@raman.networkresonance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86ek0bele1.fsf@raman.networkresonance.com> User-Agent: Mutt/1.5.7i X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, iab@ietf.org, Sam Hartman Subject: Re: [saag] Frameworks, multiple mechanisms and draft-iab-auth-mech-05.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2006 22:00:39 -0000 On Wed, Apr 05, 2006 at 02:57:10PM -0700, Eric Rescorla wrote: > What I'm talking about is design decisions that were bad from > day one and still are bad. The fact that they happen to be widely > used doesn't make them any less bad. Case in point (though not > strictly relevant to this document): WEP. But I don't agree with your take re: the GSS-API and SASL, it's quite clearly inconsistent with the consensus of verious IETF WGs. Nico -- From aboba@internaut.com Wed Apr 5 18:01:21 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k35M1LPP018288 for ; Wed, 5 Apr 2006 18:01:21 -0400 Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k35Lx9BK029098; Wed, 5 Apr 2006 17:59:09 -0400 (EDT) Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1FRG1s-000KDN-SD; Wed, 05 Apr 2006 17:59:09 -0400 Received: by internaut.com (Postfix, from userid 1000) id 19D24496D5; Wed, 5 Apr 2006 14:59:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id 0AB05232A9; Wed, 5 Apr 2006 14:59:03 -0700 (PDT) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Wed, 5 Apr 2006 14:59:03 -0700 (PDT) From: Bernard Aboba To: Sam Hartman In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: -2.464 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, iab@ietf.org Subject: Re: [saag] Frameworks, multiple mechanisms and draft-iab-auth-mech-05.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2006 22:01:21 -0000 > I'd like to bring up serious concerns about sections 11.2, 11.3 > and 13.2-4 in draft-iab-auth-mech05.txt. . . . > So, I think there is more work to do in these sections. In > particular, I think that you should read this document and come away > with the impression that it will be common for you to end up at > SASL+TLS as a solution for typical client-server applications without > special requirements and end up with EAP as a solution for network > access applications. We can work through (or the IAB can work through > without input) whether there are constraints I'm not aware of now, but > the current text seems deeply suspect. If I follow the current text I > would get the impression that either most of the existing work in the > IETF is a corner case or it has been done wrong. I believe neither of > those statements. While I think that Sections 11 and 13 can probably be improved, I did not interpret them to be refuting the need for frameworks. As you point out, customers have shown a strong desire to maximize the usefulness of their existing security investments, and there is wide diversity in the security mechanisms that they are deploying today. This leads to a demand for diversity in authentication mechanisms that is best supported via frameworks. Section 13.2 appears to acknowledge this: The second is that users have widely different environments which for some reason cannot use the same authentication mechanism conveniently (e.g. some users have tokens and some do not). My own take on Section 11 is that it is trying to point out some of the problems that can result from diversity. Within an organization, frameworks can allow an organization to choose a single mechanism and then apply it widely for many uses, allowing them to leverage their investment. However, from an Internet-wide perspective, having many islands, each with their own security infrastructure, has some drawbacks. For example, witness what happens when Vendor A, who has deployed token cards, acquires Vendor B, who has deployed smartcards. My interpretation is that Section 11.2 attempts to point out the interoperability issues created by the proliferation of multiple authentication mechanisms with the same fundamental objective. This is particularly problematic where there is no single mandatory-to-implement or standardized mechanism of a given type. > Another problem is with the idea that protocols should support > multiple mechanisms but that they should not use an existing > framework. I would agree that this is problematic, but I could not find text in Section 11 or 13 which appears to advocate this. Section 13.4 is entitled "Avoid inventing something new" and so perhaps this could talk about the problems with inventing new frameworks as well as new mechanisms. I'd also prefer if this Section gave stronger advice about challenge/response mechanisms. A few other notes: Section 12.3 indicates that RADIUS server always supplies the authenticator with the client identity (User-Name) attribute. As pointed out in RFC 4372, this is not always the case. > Section 11.1: Another solution to downgrade attacks is to cache state > about the endpoint. If an endpoint has previously offered a digest > mechanism but now only offers plaintext passwords, then this indicates > a problem. > > Another solution is to only offer mechanisms that cannot protect the > negotiation over TLS or other channels where the server is > authenticated. Good points. Another approach is for each side to be configured with policy limiting the number of mechanisms that can be negotiated (preferrably only to highly secure mechanisms). > I strongly disagree with the following sentence because I believe it > leads to protocols that cannot be deployed: > > While the desire to support legacy authentication systems is under- > > standable, it should be resisted to the extent possible. I think it is worthwile to distinguish between legacy credentials and legacy authentication mechanisms. Within IPsec WG we had an argument over whether it was necessary to support CHAP within IKEv2, because users had deployed RADIUS. It was pointed out that all modern RADIUS servers support EAP at this point, so that in practice the issue was really support for password credentials, not support for algorithms using those credentials. > Claiming that EAP TLS is a bad idea goes against a recent IETF > consensus to move it onto the standards track. EAP TLS is explicitly > a work item of EMU. EAP-TLS does not in fact allow negotiation of multiple authentication mechanisms, it only supports certificate authentication, so the point was not correct. However, I don't interpret as saying that EAP-TLS is bad. > The current text implies that in order to avoid layering new PPP > authentication methods should not use EAP. I believe that goes > against a strong internet area consensus and against IETF consensus. It might have made more sense for the text to criticize PPP's insecure authentication mechanism negotiation. For example, 802.11 has its own negotiation as well as supporting EAP, but the 4-way handshake confirms the negotiated security mechanisms, so there is no security issue there. > I think a better approach is that there should only be one generally > accepted path to a particular mechanism. I.E. There should be one > way of doing Kerberos in SASL; it should be easy to find out what that > is. I think this is a valid point. > Section 11 is missing a discussion of the multi-layer negotiation > problem. There is a significant possibility of downgrade attack or > selection of the wrong mechanism if you use negotiations at multiple > layers. This is why the SASL GSS mechanism recommends against use of > the GSSAPI negotiation. Similarly this is why > draft-ietf-secsh-gss-kex forbids the GSS negotiation mechanism. This makes sense. > You are missing Ssh and TLS as frameworks. I can see an argument that > TLS is not a framework, but ssh clearly has two authentication > frameworks: the key exchange mechanism and the userauth mechanisms. TLS seems to rapidly moving toward becoming a framework if it is not one already. > Section 13.3 I think this advice needs to be constrained. As a > deployment reality simple passwords are often a requirement. Last time I looked, simple passwords were deployed in something like 70% of EAP installations. So as much as we might like to replace passwords, this has proven very difficult to achieve in practice. > Section 13.4: > > Please warn people before recommending they just use IPsec to protect > their channel. We've had significant trouble with doing this in the > past. The OSPF authentication draft; L2TP's IPsec support; Iscsi's > IPsec support; IPsec for L*VPN have all been challenging. Please at > least include a pointer to draft-bellovin-use-ipsec (presumably > informative so it does not block your document) and mention that many > details need to be worked through and that IPsec is difficult to use > for application security. Would a discussion of channel binding issues be appropriate here? From ekr@raman.networkresonance.com Wed Apr 5 18:06:57 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k35M6vmj019155 for ; Wed, 5 Apr 2006 18:06:57 -0400 Received: from raman.networkresonance.com (raman.networkresonance.com [198.144.196.3]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k35M6cd9008999; Wed, 5 Apr 2006 18:06:38 -0400 (EDT) Received: by raman.networkresonance.com (Postfix, from userid 1001) id AC5121E8C1F; Wed, 5 Apr 2006 15:06:37 -0700 (PDT) To: Nicolas Williams References: <86psjvemfv.fsf@raman.networkresonance.com> <20060405215337.GJ2895@binky.Central.Sun.COM> <86ek0bele1.fsf@raman.networkresonance.com> <20060405220027.GL2895@binky.Central.Sun.COM> From: Eric Rescorla Date: Wed, 05 Apr 2006 15:06:37 -0700 In-Reply-To: <20060405220027.GL2895@binky.Central.Sun.COM> (Nicolas Williams's message of "Wed, 5 Apr 2006 17:00:27 -0500") Message-ID: <86acazekya.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.18 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, iab@ietf.org, Sam Hartman Subject: Re: [saag] Frameworks, multiple mechanisms and draft-iab-auth-mech-05.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Reply-To: EKR List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2006 22:06:57 -0000 Nicolas Williams writes: > On Wed, Apr 05, 2006 at 02:57:10PM -0700, Eric Rescorla wrote: >> What I'm talking about is design decisions that were bad from >> day one and still are bad. The fact that they happen to be widely >> used doesn't make them any less bad. Case in point (though not >> strictly relevant to this document): WEP. > > But I don't agree with your take re: the GSS-API and SASL, it's quite > clearly inconsistent with the consensus of verious IETF WGs. What exactly do you believe my take on GSS-API and SASL to be and in what way do you disagree with it? -Ekr From nw141292@binky.Central.Sun.COM Wed Apr 5 18:40:35 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k35MeZBt024440 for ; Wed, 5 Apr 2006 18:40:35 -0400 Received: from nwkea-mail-5.sun.com (nwkea-mail-5.sun.com [192.18.42.27]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k35MeUIV026906; Wed, 5 Apr 2006 18:40:31 -0400 (EDT) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-5.sun.com (8.12.10/8.12.9) with ESMTP id k35MeU9F029832; Wed, 5 Apr 2006 15:40:30 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k35MeTdc024967; Wed, 5 Apr 2006 16:40:29 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k35MeTs4005221; Wed, 5 Apr 2006 17:40:29 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k35MeTaF005220; Wed, 5 Apr 2006 17:40:29 -0500 (CDT) Date: Wed, 5 Apr 2006 17:40:29 -0500 From: Nicolas Williams To: EKR Message-ID: <20060405224028.GP2895@binky.Central.Sun.COM> References: <86psjvemfv.fsf@raman.networkresonance.com> <20060405215337.GJ2895@binky.Central.Sun.COM> <86ek0bele1.fsf@raman.networkresonance.com> <20060405220027.GL2895@binky.Central.Sun.COM> <86acazekya.fsf@raman.networkresonance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86acazekya.fsf@raman.networkresonance.com> User-Agent: Mutt/1.5.7i X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, iab@ietf.org, Sam Hartman Subject: Re: [saag] Frameworks, multiple mechanisms and draft-iab-auth-mech-05.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2006 22:40:35 -0000 On Wed, Apr 05, 2006 at 03:06:37PM -0700, Eric Rescorla wrote: > Nicolas Williams writes: > > > On Wed, Apr 05, 2006 at 02:57:10PM -0700, Eric Rescorla wrote: > >> What I'm talking about is design decisions that were bad from > >> day one and still are bad. The fact that they happen to be widely > >> used doesn't make them any less bad. Case in point (though not > >> strictly relevant to this document): WEP. > > > > But I don't agree with your take re: the GSS-API and SASL, it's quite > > clearly inconsistent with the consensus of verious IETF WGs. > > What exactly do you believe my take on GSS-API and SASL > to be and in what way do you disagree with it? >11. Generic Authentication Mechanisms > > An approach that has lately gained currency is to use a generic > authentication negotiation system. ... "lately"?! Come on. > Generic authentication mechanisms are attractive to application pro- > tocol designers because they allow them--in theory--to add security "in theory"? Come on! SASL apps that work with multiple mechanisms exist. So do GSS-API applications. > to their protocols without having to directly deal with the security > issues. They simply specify that one should use a given framework. > They're attractive to security mechanism designers because it's rela- > tively easy to add new mechanisms. Section 11.1 describes a real problem correctly, but is silly nonetheless: even if there were a single universally agreed-to and deployed security mechanism the downgrade attack problem would nonetheless exist because of cryptographic algorithm agility. I.e., the downgrade attack problem is not specific to security frameworks that support mechanism negotiation but generic to any framework or mechanism that supports negotiation from mechanisms or cryptographic algorithms of varying strengths. Section 11.2, the answer to "why the proliferation of superficially redundant mechanisms?" is credential deployment: people want to be able to use the credentials they already have. The alternative to this "proliferation of superficially redundant mechanisms" is to extend existing mechanisms to support a variety of similar credential types. While the desire to support legacy authentication systems is under- standable, it should be resisted to the extent possible. ... Maybe so, but support for migrations from legacy is not so clearly something that should be resisted. I have a hard time seeing support for legacy credentials as not at all related to supporting migration from legacy credentials. Section 11.3: > Many of the legacy authentication mechanisms that users and adminis- > trators wish to support are themselves generic frameworks of one kind > or another. For instance, SASL allows the use of GSSAPI, which itself > is a generic framework for a number of mechanisms. This sort of lay- > ering dramatically increases both implementation and deployment com- > plexity. For instance, GSSAPI contains mechanisms that are essen- > tially equivalent to Kerberos, but SASL also supports Kerberos > directly. Under what conditions should clients use Kerberos directly > and under which should they use it through GSSAPI? SASL does NOT support Kerberos _V_ directly. SASL does support Kerberos _IV_, but: a) this is obsolete, b) there never was a standard GSS-API mechanism for using Kerberos _IV_. Thus question ending the above paragraph is not meaningful. Moreover, Sam, myself and others will tell you that we think that in the future all SASL mechanisms should be GSS-API mechanisms used through an appropriate SASL->GSS-API bridge (the original had some shortcommings that are being addressed in a new one). I agree about multi-level mechanism negotiation, but we can nonetheless live with framework bridges and what not and deal with the negotiation sanely. History is what it is and I too dislike some of it, but it does create real constraints on what can be done -- which does not mean that the end result must be gross. I've not read the whole document yet, but I think the above is a starter. Nico -- From ekr@raman.networkresonance.com Wed Apr 5 18:53:36 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k35MrabY026760 for ; Wed, 5 Apr 2006 18:53:36 -0400 Received: from raman.networkresonance.com (raman.networkresonance.com [198.144.196.3]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k35MrT3F000192; Wed, 5 Apr 2006 18:53:29 -0400 (EDT) Received: by raman.networkresonance.com (Postfix, from userid 1001) id 3A4811E8C21; Wed, 5 Apr 2006 15:53:29 -0700 (PDT) To: Nicolas Williams References: <86psjvemfv.fsf@raman.networkresonance.com> <20060405215337.GJ2895@binky.Central.Sun.COM> <86ek0bele1.fsf@raman.networkresonance.com> <20060405220027.GL2895@binky.Central.Sun.COM> <86acazekya.fsf@raman.networkresonance.com> <20060405224028.GP2895@binky.Central.Sun.COM> From: Eric Rescorla Date: Wed, 05 Apr 2006 15:53:29 -0700 In-Reply-To: <20060405224028.GP2895@binky.Central.Sun.COM> (Nicolas Williams's message of "Wed, 5 Apr 2006 17:40:29 -0500") Message-ID: <86y7yjbpna.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.18 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, iab@ietf.org, Sam Hartman Subject: Re: [saag] Frameworks, multiple mechanisms and draft-iab-auth-mech-05.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Reply-To: EKR List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2006 22:53:36 -0000 Nicolas Williams writes: > On Wed, Apr 05, 2006 at 03:06:37PM -0700, Eric Rescorla wrote: >> Nicolas Williams writes: >> >> > On Wed, Apr 05, 2006 at 02:57:10PM -0700, Eric Rescorla wrote: >> >> What I'm talking about is design decisions that were bad from >> >> day one and still are bad. The fact that they happen to be widely >> >> used doesn't make them any less bad. Case in point (though not >> >> strictly relevant to this document): WEP. >> > >> > But I don't agree with your take re: the GSS-API and SASL, it's quite >> > clearly inconsistent with the consensus of verious IETF WGs. >> >> What exactly do you believe my take on GSS-API and SASL >> to be and in what way do you disagree with it? > >>11. Generic Authentication Mechanisms >> >> An approach that has lately gained currency is to use a generic >> authentication negotiation system. ... > > "lately"?! Come on. I'll give you this one. This sentence was written about 4 years go. >> Generic authentication mechanisms are attractive to application pro- >> tocol designers because they allow them--in theory--to add security > > "in theory"? Come on! SASL apps that work with multiple mechanisms > exist. So do GSS-API applications. It's generally better to read the whole sentence before complaining about it. The "in theory" part refers to the fact that you don't in fact get to avoid dealing with the security issues. Given that not 6 months ago you and I had a long conversation about how to wire up SASL to HTTP, I don't really see how you can argue that this isn't an issue. >> to their protocols without having to directly deal with the security >> issues. They simply specify that one should use a given framework. >> They're attractive to security mechanism designers because it's rela- >> tively easy to add new mechanisms. > Section 11.1 describes a real problem correctly, but is silly > nonetheless: even if there were a single universally agreed-to and > deployed security mechanism the downgrade attack problem would > nonetheless exist because of cryptographic algorithm agility. > > I.e., the downgrade attack problem is not specific to security > frameworks that support mechanism negotiation but generic to any > framework or mechanism that supports negotiation from mechanisms or > cryptographic algorithms of varying strengths. Yes, it's just especially bad with frameworks because they tend to span a far wider range of cryptographic strengths. SASL is a case in point here. > Section 11.2, the answer to "why the proliferation of superficially > redundant mechanisms?" is credential deployment: people want to be able > to use the credentials they already have. The alternative to this > "proliferation of superficially redundant mechanisms" is to extend > existing mechanisms to support a variety of similar credential types. Yes, I said as much. But that's a bug, not a feature. > While the desire to support legacy authentication systems is under- > standable, it should be resisted to the extent possible. ... > > Maybe so, but support for migrations from legacy is not so clearly > something that should be resisted. I have a hard time seeing support > for legacy credentials as not at all related to supporting migration > from legacy credentials. Sorry, I don't understand what you mean here. > Section 11.3: > >> Many of the legacy authentication mechanisms that users and adminis- >> trators wish to support are themselves generic frameworks of one kind >> or another. For instance, SASL allows the use of GSSAPI, which itself >> is a generic framework for a number of mechanisms. This sort of lay- >> ering dramatically increases both implementation and deployment com- >> plexity. For instance, GSSAPI contains mechanisms that are essen- >> tially equivalent to Kerberos, but SASL also supports Kerberos >> directly. Under what conditions should clients use Kerberos directly >> and under which should they use it through GSSAPI? > > SASL does NOT support Kerberos _V_ directly. > > SASL does support Kerberos _IV_, but: a) this is obsolete, b) there > never was a standard GSS-API mechanism for using Kerberos _IV_. > > Thus question ending the above paragraph is not meaningful. I'll concede this point. > Moreover, Sam, myself and others will tell you that we think that in the > future all SASL mechanisms should be GSS-API mechanisms used through an > appropriate SASL->GSS-API bridge (the original had some shortcommings > that are being addressed in a new one). > > I agree about multi-level mechanism negotiation, but we can nonetheless > live with framework bridges and what not and deal with the negotiation > sanely. History is what it is and I too dislike some of it, but it does > create real constraints on what can be done -- which does not mean that > the end result must be gross. Apparently you and I have differences of opinion about whether the situation you describe above is gross. Other than that aesthetic issue, Nico, I'm not sure what you're disagreeing about here. I agree that the situation is as you say, but frankly, it's architecturally incredibly messy and we would be better if things were cleaner. Certainly, were we designing things from scratch, we would do so. Or do you disagree? Given that, the text you're complaining about is generally about how one ought to design systems in the future. I appreciate that there are constraints of the kind you describe, but the design choices they force are to be lamented rather than celebrated, which is precisely what this document intends to say. -Ekr From nw141292@binky.Central.Sun.COM Wed Apr 5 19:09:17 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k35N9H2F029962 for ; Wed, 5 Apr 2006 19:09:17 -0400 Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k35N96Wm007056; Wed, 5 Apr 2006 19:09:07 -0400 (EDT) Received: from centralmail1brm.Central.Sun.COM (centralmail1brm.central.sun.com [129.147.62.1]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k35N96JK017934; Wed, 5 Apr 2006 17:09:06 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k35N95ce022680; Wed, 5 Apr 2006 17:09:06 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k35N950p005261; Wed, 5 Apr 2006 18:09:05 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k35N952Y005260; Wed, 5 Apr 2006 18:09:05 -0500 (CDT) Date: Wed, 5 Apr 2006 18:09:04 -0500 From: Nicolas Williams To: Bernard Aboba Message-ID: <20060405230904.GS2895@binky.Central.Sun.COM> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, iab@ietf.org, Sam Hartman Subject: Re: [saag] Frameworks, multiple mechanisms and draft-iab-auth-mech-05.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2006 23:09:17 -0000 On Wed, Apr 05, 2006 at 02:59:03PM -0700, Bernard Aboba wrote: > EAP-TLS does not in fact allow negotiation of multiple authentication > mechanisms, it only supports certificate authentication, so the point was > not correct. However, I don't interpret as saying that EAP-TLS is bad. At the very least incorrect assertions must be corrected, such as the incorrect statement about support for Kerberos in SASL directly and through the SASL/GSS-API bridge, which is correct only if one ignores the difference between Kerberos IV and V (which, if stated directly should draw howls). > > The current text implies that in order to avoid layering new PPP > > authentication methods should not use EAP. I believe that goes > > against a strong internet area consensus and against IETF consensus. > > It might have made more sense for the text to criticize PPP's insecure > authentication mechanism negotiation. For example, 802.11 has its own > negotiation as well as supporting EAP, but the 4-way handshake confirms > the negotiated security mechanisms, so there is no security issue there. > > > I think a better approach is that there should only be one generally > > accepted path to a particular mechanism. I.E. There should be one > > way of doing Kerberos in SASL; it should be easy to find out what that > > is. > > I think this is a valid point. I second this. > > Section 13.4: > > > > Please warn people before recommending they just use IPsec to protect > > their channel. We've had significant trouble with doing this in the > > past. The OSPF authentication draft; L2TP's IPsec support; Iscsi's > > IPsec support; IPsec for L*VPN have all been challenging. Please at > > least include a pointer to draft-bellovin-use-ipsec (presumably > > informative so it does not block your document) and mention that many > > details need to be worked through and that IPsec is difficult to use > > for application security. > > Would a discussion of channel binding issues be appropriate here? Yes. Of course, the work in the area of IPsec channel binding is ongoing. Nico -- From jaltman@columbia.edu Wed Apr 5 19:11:46 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k35NBkjv030341 for ; Wed, 5 Apr 2006 19:11:46 -0400 Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k35NBjIH023792; Wed, 5 Apr 2006 19:11:45 -0400 (EDT) Received: from [192.168.1.13] (cpe-68-175-91-105.nyc.res.rr.com [68.175.91.105]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.6/8.13.6) with ESMTP id k35NBiS3009260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 5 Apr 2006 19:11:44 -0400 (EDT) Message-ID: <44344F37.5080505@columbia.edu> Date: Wed, 05 Apr 2006 19:13:59 -0400 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Nicolas Williams References: <86psjvemfv.fsf@raman.networkresonance.com> <20060405215337.GJ2895@binky.Central.Sun.COM> <86ek0bele1.fsf@raman.networkresonance.com> <20060405220027.GL2895@binky.Central.Sun.COM> <86acazekya.fsf@raman.networkresonance.com> <20060405224028.GP2895@binky.Central.Sun.COM> In-Reply-To: <20060405224028.GP2895@binky.Central.Sun.COM> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070908070702040909020801" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.42 X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: -2.6 X-Spam-Flag: NO Cc: saag@mit.edu, Sam Hartman , iab@ietf.org Subject: Re: [saag] Frameworks, multiple mechanisms and draft-iab-auth-mech-05.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2006 23:11:46 -0000 This is a cryptographically signed message in MIME format. --------------ms070908070702040909020801 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Nicolas Williams wrote: > Moreover, Sam, myself and others will tell you that we think that in the > future all SASL mechanisms should be GSS-API mechanisms used through an > appropriate SASL->GSS-API bridge (the original had some shortcommings > that are being addressed in a new one). > > I agree about multi-level mechanism negotiation, but we can nonetheless > live with framework bridges and what not and deal with the negotiation > sanely. History is what it is and I too dislike some of it, but it does > create real constraints on what can be done -- which does not mean that > the end result must be gross. > > I've not read the whole document yet, but I think the above is a > starter. > > Nico I have not had time to read the document yet either and I am going to refrain from putting forward a complete argument until I do. In the meantime, I agree with Sam and Nico. I want to see new application protocols develop with either SASL or GSS-API in mind depending on the level of flexibility that is required. I would like to see all new mechanisms be developed at the GSS-API layer and have them be accessed by SASL applications via the bridge. We are currently living in a world in which end users are being forced to understand to much about the underlying authentication mechanisms. This is partly because in order to deploy applications administrators are forced to deploy separate security frameworks for the various applications. The two most extreme examples are those that are X.509 certificate based vs those that are Kerberos vs those that are password based. The reason we have been unable to remove passwords from the authentication models of most applications deployed on the internet is because at the moment passwords are the only portable means of authentication that we have. I can't use Kerberos or smartcards or SRP at Kinkos or libraries or airport terminals but I can use passwords. The IETF has to tell a story that is inclusive of all of the security work that is going on outside the IETF. Work that I believe should be going on inside the IETF. SAML, WS*, Liberty, Globus GSS extensions, etc. The IETF needs to describe a roadmap that describes how we are going to integrate all of the protocols and frameworks into a cohesive picture so that end users can experience single sign-on. This must include support for the concepts of Federated identity and credential transformation such that an identity issued as an X.509 certificate can be used with applications that accept Kerberos credentials or SAML assertions. The broader security community including not just IETF but W3C, OASIS, Liberty, etc. must create a user experience that provides answers to the identity selection problems and provides user interface guidelines to implementors that can be used to help avoid phishing attacks. In addition we need solutions to the enrollment problems without which end users will always be vulnerable to phishing. I am more than willing to help write such a document. This is already much longer than I intended and I will put together a more cohesive response after I read the original document that started this thread. Jeffrey Altman --------------ms070908070702040909020801 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAw7NrDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNTI3MTc0MjQzWhcNMDYwNTI3MTc0MjQz WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+LutDu/YyHreNfoYd+ZtOjXsL h67F2cmcVuBPBz+ZGDA+WpVEHrqXaZZO8acXBR5uAVfiwA1acE/kvD/CN5kAqx1VJuQ8Pvyk iGHhUYTd27ZTliBIrptC7C/381gVwkS+a8jQFPJPO+OktZDzAYplGRY/MQCV8dIsvXUjucox 7TwTTdoLAJYRvHtfEcaCc6mO4ph6NeXQw8Grlx3IRAlTrkE5fBGyjH6R4fqnFTXRQAh1/bG+ i8hQvE6mud3mXdL2t7NP1Qxd9wW0/F/pnWY12IFP/luc3zEzIPvAe+nJluLuSEj0LZgP16mF xBj1p+u9HPWcHRVX6q7+MQ0RWOv1AgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAUDUuzxiq8bbI8vq2 swRK513RphZp+fepyKU5mwBI6aF4GcmqITQILtfTG2SXnjSeY99d+bjOdK1DJFvVh9aOy8mh 2NbEnqMnJIZtg5+eEU64DIV5bQdDRpi99H9vA0sRATIquut+3YHba+zArj0VkVof2VI+ToBu sHdtSrZYo0gwggL6MIICY6ADAgECAgMOzawwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MDUyNzE3NDI0M1oXDTA2 MDUyNzE3NDI0M1owazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvi7rQ7v2Mh63 jX6GHfmbTo17C4euxdnJnFbgTwc/mRgwPlqVRB66l2mWTvGnFwUebgFX4sANWnBP5Lw/wjeZ AKsdVSbkPD78pIhh4VGE3du2U5YgSK6bQuwv9/NYFcJEvmvI0BTyTzvjpLWQ8wGKZRkWPzEA lfHSLL11I7nKMe08E03aCwCWEbx7XxHGgnOpjuKYejXl0MPBq5cdyEQJU65BOXwRsox+keH6 pxU10UAIdf2xvovIULxOprnd5l3S9rezT9UMXfcFtPxf6Z1mNdiBT/5bnN8xMyD7wHvpyZbi 7khI9C2YD9ephcQY9afrvRz1nB0VV+qu/jENEVjr9QIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAFA1 Ls8YqvG2yPL6trMESudd0aYWafn3qcilOZsASOmheBnJqiE0CC7X0xtkl540nmPfXfm4znSt QyRb1YfWjsvJodjWxJ6jJySGbYOfnhFOuAyFeW0HQ0aYvfR/bwNLEQEyKrrrft2B22vswK49 FZFaH9lSPk6AbrB3bUq2WKNIMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMOzaww CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDYwNDA1MjMxMzU5WjAjBgkqhkiG9w0BCQQxFgQUJJiodKapVY6PxpSJk/H26YAnap4w UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrDB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMOzawwDQYJKoZIhvcNAQEBBQAEggEAY6bB2yjVY/ItUMzMBMU499Wg5Lj5TLcqN5OwahlH T8jAViqwX8UuTIcC+R4mdm0K19MxQDZFii+E2cW4Wb0Yc1iNihYuRND1cJ7ELQCwmf7vYWuF gmoA8Ii+/VawaiiP69zcIfaFsjM70oWcS4blQ4Pd7n3vvdPy8x66q3qABEVueT0D1RaxNFFG XyAV2tORjbbHRK+Cni+fXCYQiTkXuK+z02Tw//1GwkSUCfDH2VNswNAqoXPTeNxjY31Bk+CH kusBtNI7CUSWcS2yeHyil73zX6KF8Fu3vdZ5+EirlW0jl9r25HwBI4qDO/C5Qp1bTOQCDcKi i0LRmkscUBH7CQAAAAAAAA== --------------ms070908070702040909020801-- From nw141292@binky.Central.Sun.COM Wed Apr 5 19:27:11 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k35NRBsJ001093 for ; Wed, 5 Apr 2006 19:27:11 -0400 Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k35NRAnt001537; Wed, 5 Apr 2006 19:27:11 -0400 (EDT) Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k35NRAFu020153; Wed, 5 Apr 2006 17:27:10 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k35NR9cc029055; Wed, 5 Apr 2006 17:27:09 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k35NR9NC005270; Wed, 5 Apr 2006 18:27:09 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k35NR9Wj005269; Wed, 5 Apr 2006 18:27:09 -0500 (CDT) Date: Wed, 5 Apr 2006 18:27:09 -0500 From: Nicolas Williams To: EKR Message-ID: <20060405232708.GT2895@binky.Central.Sun.COM> References: <86psjvemfv.fsf@raman.networkresonance.com> <20060405215337.GJ2895@binky.Central.Sun.COM> <86ek0bele1.fsf@raman.networkresonance.com> <20060405220027.GL2895@binky.Central.Sun.COM> <86acazekya.fsf@raman.networkresonance.com> <20060405224028.GP2895@binky.Central.Sun.COM> <86y7yjbpna.fsf@raman.networkresonance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86y7yjbpna.fsf@raman.networkresonance.com> User-Agent: Mutt/1.5.7i X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, iab@ietf.org, Sam Hartman Subject: Re: [saag] Frameworks, multiple mechanisms and draft-iab-auth-mech-05.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2006 23:27:11 -0000 On Wed, Apr 05, 2006 at 03:53:29PM -0700, Eric Rescorla wrote: > Nicolas Williams writes: > > On Wed, Apr 05, 2006 at 03:06:37PM -0700, Eric Rescorla wrote: > > > > "lately"?! Come on. > > I'll give you this one. This sentence was written about 4 years go. Ah, I didn't have that context. This was one of the two things that rankled me... > >> Generic authentication mechanisms are attractive to application pro- > >> tocol designers because they allow them--in theory--to add security > > > > "in theory"? Come on! SASL apps that work with multiple mechanisms > > exist. So do GSS-API applications. > > It's generally better to read the whole sentence before complaining about it. > The "in theory" part refers to the fact that you don't in fact get > to avoid dealing with the security issues. I didn't read it that way. Frameworks deliver on this promise, by and large, except for the fragmented mechanisms availability issue, which I would concede (though only to also point out ongoing work in that space), and except for the fragmented uptake of frameworks. Thus to say that "in theory" SASL or the GSS-API allow one to add security to application protocols ignores very practical successes in adding security to a variety of applications. As to the point that use of these frameworks does not save the application protocol designer the bother of thinking about security, I agree wholeheartedly, but I do hope that it makes things easier for them. > Given that not > 6 months ago you and I had a long conversation about how to wire > up SASL to HTTP, I don't really see how you can argue that this > isn't an issue. That we've been talking about the failure of HTTP to adopt such frameworks does not make the success of these frameworks theoretical. > > >> to their protocols without having to directly deal with the security > >> issues. They simply specify that one should use a given framework. > >> They're attractive to security mechanism designers because it's rela- > >> tively easy to add new mechanisms. > > > > Section 11.1 describes a real problem correctly, but is silly > > nonetheless: even if there were a single universally agreed-to and > > deployed security mechanism the downgrade attack problem would > > nonetheless exist because of cryptographic algorithm agility. > > > > I.e., the downgrade attack problem is not specific to security > > frameworks that support mechanism negotiation but generic to any > > framework or mechanism that supports negotiation from mechanisms or > > cryptographic algorithms of varying strengths. > > Yes, it's just especially bad with frameworks because they tend > to span a far wider range of cryptographic strengths. SASL is a > case in point here. Really? Kerberos V, TLS, others have issues w.r.t. weak cryptographic algorithms, no? Many Kerberos V installations still deal with DES+crc32 for crying out loud :-( But, yes, SASL is a case in point, presumably that being a reference to the digest mechanisms... > > While the desire to support legacy authentication systems is under- > > standable, it should be resisted to the extent possible. ... > > > > Maybe so, but support for migrations from legacy is not so clearly > > something that should be resisted. I have a hard time seeing support > > for legacy credentials as not at all related to supporting migration > > from legacy credentials. > > Sorry, I don't understand what you mean here. I'll re-read and elaborate on this later. > > Moreover, Sam, myself and others will tell you that we think that in the > > future all SASL mechanisms should be GSS-API mechanisms used through an > > appropriate SASL->GSS-API bridge (the original had some shortcommings > > that are being addressed in a new one). > > > > I agree about multi-level mechanism negotiation, but we can nonetheless > > live with framework bridges and what not and deal with the negotiation > > sanely. History is what it is and I too dislike some of it, but it does > > create real constraints on what can be done -- which does not mean that > > the end result must be gross. > > Apparently you and I have differences of opinion about whether > the situation you describe above is gross. > > Other than that aesthetic issue, Nico, I'm not sure what you're > disagreeing about here. I agree that the situation is as you say, but > frankly, it's architecturally incredibly messy and we would be better > if things were cleaner. Certainly, were we designing things from > scratch, we would do so. Or do you disagree? If we were starting from scratch we'd be better off, yes, but we can't and we won't. So we need useful advice beyond "don't do this again" -- see Sam's point about having a unique path to any given mechanism from any given application, for example. > Given that, the text you're complaining about is generally about > how one ought to design systems in the future. I appreciate that > there are constraints of the kind you describe, but the design > choices they force are to be lamented rather than celebrated, > which is precisely what this document intends to say. Ah, well then let's distinguish (or did I miss that distinction? I was told to go read section 11, which I did; perhaps I jumped the gun...) between advice to designers of new application protocols and to designers working on improving existing application protocols where a mess has already been made. Nico -- From aboba@internaut.com Wed Apr 5 23:34:05 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k363Y5ib015548 for ; Wed, 5 Apr 2006 23:34:05 -0400 Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k363Y0Ws001729; Wed, 5 Apr 2006 23:34:00 -0400 (EDT) Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1FRLFt-0005RQ-I6; Wed, 05 Apr 2006 23:33:57 -0400 Received: by internaut.com (Postfix, from userid 1000) id BDF36496E5; Wed, 5 Apr 2006 20:33:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id B311B496E4; Wed, 5 Apr 2006 20:33:56 -0700 (PDT) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Wed, 5 Apr 2006 20:33:56 -0700 (PDT) From: Bernard Aboba To: Jeffrey Altman In-Reply-To: <44344F37.5080505@columbia.edu> Message-ID: References: <86psjvemfv.fsf@raman.networkresonance.com> <20060405215337.GJ2895@binky.Central.Sun.COM> <86ek0bele1.fsf@raman.networkresonance.com> <20060405220027.GL2895@binky.Central.Sun.COM> <86acazekya.fsf@raman.networkresonance.com> <20060405224028.GP2895@binky.Central.Sun.COM> <44344F37.5080505@columbia.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: -2.464 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, iab@ietf.org, Sam Hartman , Nicolas Williams Subject: Re: [saag] Frameworks, multiple mechanisms and draft-iab-auth-mech-05.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2006 03:34:05 -0000 > I can't use Kerberos or smartcards or SRP at Kinkos or libraries or > airport terminals but I can use passwords. Actually, this is more a statement about roaming agreements than it is a statement about authentication technology. Any wireless LAN network capable of supporting passwords in WPA/WPA2 could also support smartcards or any other authentication technology supported within the home authentication server, if a roaming agreement were in place. For example, the TMobile WLAN network currently supports WPA, as well as RFC 3579 (RADIUS/EAP). This means that the APs can pass-through any authentication mechanism, not just the EAP-TTLS method that is supported for TMobile's own customers. From jaltman@columbia.edu Thu Apr 6 03:27:42 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k367RgL3020540 for ; Thu, 6 Apr 2006 03:27:42 -0400 Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k367RTRh006090; Thu, 6 Apr 2006 03:27:29 -0400 (EDT) Received: from [192.168.1.13] (cpe-68-175-91-105.nyc.res.rr.com [68.175.91.105]) (user=jaltman mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.6/8.13.6) with ESMTP id k367R8lj017063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 6 Apr 2006 03:27:12 -0400 (EDT) Message-ID: <4434C353.3060101@columbia.edu> Date: Thu, 06 Apr 2006 03:29:23 -0400 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Bernard Aboba References: <86psjvemfv.fsf@raman.networkresonance.com> <20060405215337.GJ2895@binky.Central.Sun.COM> <86ek0bele1.fsf@raman.networkresonance.com> <20060405220027.GL2895@binky.Central.Sun.COM> <86acazekya.fsf@raman.networkresonance.com> <20060405224028.GP2895@binky.Central.Sun.COM> <44344F37.5080505@columbia.edu> In-Reply-To: X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050509090409070008080409" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.42 X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: -2.6 X-Spam-Flag: NO Cc: saag@mit.edu, iab@ietf.org, Sam Hartman , Nicolas Williams Subject: Re: [saag] Frameworks, multiple mechanisms and draft-iab-auth-mech-05.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2006 07:27:42 -0000 This is a cryptographically signed message in MIME format. --------------ms050509090409070008080409 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: >> I can't use Kerberos or smartcards or SRP at Kinkos or libraries or >> airport terminals but I can use passwords. > > Actually, this is more a statement about roaming agreements than it is a > statement about authentication technology. Any wireless LAN network > capable of supporting passwords in WPA/WPA2 could also support smartcards > or any other authentication technology supported within the home > authentication server, if a roaming agreement were in place. > > For example, the TMobile WLAN network currently supports WPA, as well as > RFC 3579 (RADIUS/EAP). This means that the APs can pass-through any > authentication mechanism, not just the EAP-TTLS method that is supported > for TMobile's own customers. Bernard: I beg to differ in opinion. The problem is not about roaming agreements. You are examining the problem from the perspective of someone who carries around your own device with you and whom wants to connect onto the network. I've been convinced that limiting the solution set to those who carry their own equipment with them means that we are failing to solve the problem for the vast majority of the world who does not own their own equipment. Instead we need to develop a set of authentication technologies that application developers will consistently utilize within their applications; user interface designs that will allow for secure selection and acquisition of credentials; guidelines for hardware manufacturers and operating system vendors so that the appropriate set of hardware devices will be available to users; BCPs for identity managers on how to securely enroll users and share utilize their credentials in federated communities; etc. We have failed in so many ways to provide a consistent infrastructure that is usable. Security must be implemented from the user to the Nth tier service. We no longer have the luxury of applying security one layer at a time and one application protocol at a time. At every workshop and conference I have been to in the last year from AFS to Kerberos to PKI to W3C to discussions with folks from OASIS and Liberty, the same themes come up over and over again: * how do we make all of our applications, security frameworks, authentication, and authorization infrastructures work together? * how do we reduce complexity so that average people can use it? * how do we design and deploy applications such that users don't have to be paranoid in order to be able to use them securely? At this point I believe the solutions are 10% technical, 30% political, and 60% evangelical. We don't need new frameworks or new authentication protocols. Nor do we need to get rid of ones that have been developed. However, we do have to provide glue mechanisms so they can seamlessly work together. Each standards organization has to some extent come to believe that they have to solve their security problems on their own. The W3C wants to solve the phishing problem but their focus is on web browser based applications. Therefore, the solutions that are proposed in their community not only do not scale to other applications utilizing HTTP but don't address any of the related issues in non-HTTP protocols. Microsoft's InfoCard is a wonderful gutsy attempt to address the need for a secure desktop identity selection model except for the fact that its only usable with a subset of the WS* protocols. What about the rest of the web and the rest of the user application space? The DiX BOF represents a community of users that desperately need an easy to deploy authentication framework that can be managed by the user. >From my work in the P2P space I believe the solution is not to develop another new set of application specific authentication tools but to extend the frameworks we already have to satisfy the needs of the end user. For example: * Is it possible for us to develop a small portable hardware device that users can carry with them that acts as a dual headed personal Certificate Authority and Kerberos KDC? * As an intermediary step, could the local password databases on each workstation and PDA be used as the basis for a KDC? The answer today is "I think so" but we have never focused our attention on this space so it is unclear. All of our existing authentication infrastructures have been designed with the enterprise as the focus. There is good reason for this. First, there is money there to pay for the development of solutions in that space. Second, solving the enterprise problems is the 80% solution. Third, its much easier to solve a problem that does not have to scale to billions of identity issuers. I foresee a world in which the identifications (certs, tickets, assertions) that end users manage will come from a small number of sources: * their government * their banks * their employers * their schools * their e-mail provider * themselves Users will select the identification they wish to use based upon the degree of trust the application service requires and their own personal preference. For their favorite blogs they may choose to authenticate with a personally managed identification but they could also choose to use one of the identifications they obtained from a more trusted source. The choice would be very similar to how users choose to pay for things. Will they use a credit card, a debit card, a check, cash, barter, etc? The most important thing for us as architects is to ensure that the same protocols and frameworks that can be used to support enterprise identification also support the individualistic peer to peer identification. If we can provide this, then we have given control and therefore power and privacy to the user. If we can provide convergence, interoperability, and scalability in our authentication infrastructure and can put forward a roadmap for hardware vendors, operating system vendors, database vendors, application developers, service providers, and organizations to follow, then perhaps in five to seven years we can reach a degree of uniformity and ubiquitous deployment that users truly can experience secure communication on an Internet scale without requiring a degree of paranoia. Jeffrey Altman --------------ms050509090409070008080409 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAw7NrDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNTI3MTc0MjQzWhcNMDYwNTI3MTc0MjQz WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+LutDu/YyHreNfoYd+ZtOjXsL h67F2cmcVuBPBz+ZGDA+WpVEHrqXaZZO8acXBR5uAVfiwA1acE/kvD/CN5kAqx1VJuQ8Pvyk iGHhUYTd27ZTliBIrptC7C/381gVwkS+a8jQFPJPO+OktZDzAYplGRY/MQCV8dIsvXUjucox 7TwTTdoLAJYRvHtfEcaCc6mO4ph6NeXQw8Grlx3IRAlTrkE5fBGyjH6R4fqnFTXRQAh1/bG+ i8hQvE6mud3mXdL2t7NP1Qxd9wW0/F/pnWY12IFP/luc3zEzIPvAe+nJluLuSEj0LZgP16mF xBj1p+u9HPWcHRVX6q7+MQ0RWOv1AgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAUDUuzxiq8bbI8vq2 swRK513RphZp+fepyKU5mwBI6aF4GcmqITQILtfTG2SXnjSeY99d+bjOdK1DJFvVh9aOy8mh 2NbEnqMnJIZtg5+eEU64DIV5bQdDRpi99H9vA0sRATIquut+3YHba+zArj0VkVof2VI+ToBu sHdtSrZYo0gwggL6MIICY6ADAgECAgMOzawwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MDUyNzE3NDI0M1oXDTA2 MDUyNzE3NDI0M1owazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvi7rQ7v2Mh63 jX6GHfmbTo17C4euxdnJnFbgTwc/mRgwPlqVRB66l2mWTvGnFwUebgFX4sANWnBP5Lw/wjeZ AKsdVSbkPD78pIhh4VGE3du2U5YgSK6bQuwv9/NYFcJEvmvI0BTyTzvjpLWQ8wGKZRkWPzEA lfHSLL11I7nKMe08E03aCwCWEbx7XxHGgnOpjuKYejXl0MPBq5cdyEQJU65BOXwRsox+keH6 pxU10UAIdf2xvovIULxOprnd5l3S9rezT9UMXfcFtPxf6Z1mNdiBT/5bnN8xMyD7wHvpyZbi 7khI9C2YD9ephcQY9afrvRz1nB0VV+qu/jENEVjr9QIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAFA1 Ls8YqvG2yPL6trMESudd0aYWafn3qcilOZsASOmheBnJqiE0CC7X0xtkl540nmPfXfm4znSt QyRb1YfWjsvJodjWxJ6jJySGbYOfnhFOuAyFeW0HQ0aYvfR/bwNLEQEyKrrrft2B22vswK49 FZFaH9lSPk6AbrB3bUq2WKNIMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMOzaww CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDYwNDA2MDcyOTIzWjAjBgkqhkiG9w0BCQQxFgQUXto7+DMnFTI0bShGal2yTMZ/hNgw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrDB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMOzawwDQYJKoZIhvcNAQEBBQAEggEABdV0IXlhyBCzgwkbLgngmend4MJHkJRMCUJVyN0U 6/8ldf3uNx17ROpe6kzVJFe2yXx//sxEvamGB/ZLOHeqjBB9F4Gj+OYK7OyCVkWEHmrrqRRl clP+z4QDaTxvgoLqNC9nrvREAIT3XOHSqs6az3J3/fNm/kQsBSyjgB80LnxaoYUQObfOQXt9 NciP/mnkxC6JXTM6PLot0APVK1oXZRsYlz2B9FlpzDJDd6uxBB1iXNlwlCaLeJ061QJF9yjL It8H/wwVqXgvkhCt32jPB+TwBpxuFDMMWvqvRcFUHzYEM2xSAIvL2gY/u6VwivGS1AliMtZd 76g/s2hEaEw/ygAAAAAAAA== --------------ms050509090409070008080409-- From brc@zurich.ibm.com Thu Apr 6 07:31:33 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k36BVWBp022506 for ; Thu, 6 Apr 2006 07:31:33 -0400 Received: from mtagate1.de.ibm.com (mtagate1.de.ibm.com [195.212.29.150]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k36BUpWH023576; Thu, 6 Apr 2006 07:30:52 -0400 (EDT) Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.13.6/8.13.6) with ESMTP id k36BUoHC165080; Thu, 6 Apr 2006 11:30:50 GMT Received: from d12av03.megacenter.de.ibm.com (d12av03.megacenter.de.ibm.com [9.149.165.213]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k36BVZI0194368; Thu, 6 Apr 2006 13:31:35 +0200 Received: from d12av03.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av03.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id k36BUoxV030283; Thu, 6 Apr 2006 13:30:50 +0200 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av03.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id k36BUnuX030271; Thu, 6 Apr 2006 13:30:49 +0200 Received: from zurich.ibm.com (sig-9-145-251-72.de.ibm.com [9.145.251.72]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA51134; Thu, 6 Apr 2006 13:30:48 +0200 Message-ID: <4434FBE8.4020303@zurich.ibm.com> Date: Thu, 06 Apr 2006 13:30:48 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: EKR References: <86psjvemfv.fsf@raman.networkresonance.com> In-Reply-To: <86psjvemfv.fsf@raman.networkresonance.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 X-Mailman-Approved-At: Thu, 06 Apr 2006 09:19:59 -0400 Cc: saag@mit.edu, iab@ietf.org, Sam Hartman Subject: Re: [saag] Frameworks, multiple mechanisms and draft-iab-auth-mech-05.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2006 11:31:33 -0000 Eric Rescorla wrote: > Sam Hartman writes: > >>Hi. I'd like to bring up serious concerns about sections 11.2, 11.3 >>and 13.2-4 in draft-iab-auth-mech05.txt. I understand that document >>represents an IAB consensus not an IETF consensus. However I think it >>would be confusing to people if the IAB publishes recommendations and >>protocol designers get significant pushback (especially at the IETF >>last call and IESG review/wg chartering stages) for following the IAB >>recommendations. I believe that will happen in this instance. I >>would like to work with the IAB to get the recommendations in line >>with what I think the community is doing; if that proves impossible I >>would like to encourage the IAB to add a warning about the conflict. > > > I wanted to acknowledge your message here. Although I do agree > with a fair bit of what you've written, needless to say I disagree > with much of it as well. However, it's going to take me some time > to get around to responding in the detail it deserves. > > One thing I think is worth noting right off the bat, however, > is that a number of your arguments are of the form of "this document > disrecommends X but we're doing X now". I certainly agree with > that as a descriptive statement, but in many cases I think X > is bad and we *shouldn't* be doing it now regardless of whether > we are. So, I think the discussion will have to be on the merits > of the practices themselves, rather than what the Security Area > happens to have been willing to accept. I dont't know if this will help, but seems like it might be useful to structure the observations in the document in three layers: 1. Where we would like to be in an ideal world (according to the IAB). 2. Where pragmatic considerations have brought us in the real world. 3. Practices that everybody agree must be avoided. Also, I would hate to see this go out in a state that will cause the SAAG to find it objectionable. Brian From jari.arkko@piuha.net Fri Apr 7 06:06:48 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k37A6m8J014405 for ; Fri, 7 Apr 2006 06:06:48 -0400 Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k37A6cZ7021795; Fri, 7 Apr 2006 06:06:38 -0400 (EDT) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 3E39D8988E; Fri, 7 Apr 2006 13:06:35 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id EDEAA89875; Fri, 7 Apr 2006 13:06:34 +0300 (EEST) Message-ID: <443639AA.4090604@piuha.net> Date: Fri, 07 Apr 2006 13:06:34 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, iab@ietf.org, Sam Hartman Subject: Re: [saag] Frameworks, multiple mechanisms and draft-iab-auth-mech-05.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2006 10:06:48 -0000 Bernard Aboba wrote: >>Section 13.4: >> >>Please warn people before recommending they just use IPsec to protect >>their channel. We've had significant trouble with doing this in the >>past. The OSPF authentication draft; L2TP's IPsec support; Iscsi's >>IPsec support; IPsec for L*VPN have all been challenging. Please at >>least include a pointer to draft-bellovin-use-ipsec (presumably >>informative so it does not block your document) and mention that many >>details need to be worked through and that IPsec is difficult to use >>for application security. >> >> > >Would a discussion of channel binding issues be appropriate here? > > That is one part of it. But there are also other issues, including authorization decisions that are often hard to do just by looking at the IP headers from an IPsec policy point of view, (in)ability of the application to know what protection (if any) its packets are getting, difficulties in getting the necessary configs in place either by the administrators or the applications, etc. Pointing to draft-bellovin-use-ipsec would be good. --Jari From nw141292@binky.Central.Sun.COM Fri Apr 7 12:28:58 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k37GSwNG015872 for ; Fri, 7 Apr 2006 12:28:58 -0400 Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k37GSuSv012892; Fri, 7 Apr 2006 12:28:57 -0400 (EDT) Received: from centralmail1brm.Central.Sun.COM (centralmail1brm.central.sun.com [129.147.62.1]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k37GSuZe006918; Fri, 7 Apr 2006 10:28:56 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k37GStce015557; Fri, 7 Apr 2006 10:28:56 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k37GSt0A008650; Fri, 7 Apr 2006 11:28:55 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k37GSp5D008649; Fri, 7 Apr 2006 11:28:51 -0500 (CDT) Date: Fri, 7 Apr 2006 11:28:51 -0500 From: Nicolas Williams To: Jari Arkko Message-ID: <20060407162851.GQ2895@binky.Central.Sun.COM> References: <443639AA.4090604@piuha.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <443639AA.4090604@piuha.net> User-Agent: Mutt/1.5.7i X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Sam Hartman , iab@ietf.org, Bernard Aboba Subject: Re: [saag] Frameworks, multiple mechanisms and draft-iab-auth-mech-05.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2006 16:28:58 -0000 On Fri, Apr 07, 2006 at 01:06:34PM +0300, Jari Arkko wrote: > Bernard Aboba wrote: > > >>Section 13.4: > >> > >>Please warn people before recommending they just use IPsec to protect > >>their channel. We've had significant trouble with doing this in the > >>past. The OSPF authentication draft; L2TP's IPsec support; Iscsi's > >>IPsec support; IPsec for L*VPN have all been challenging. Please at > >>least include a pointer to draft-bellovin-use-ipsec (presumably > >>informative so it does not block your document) and mention that many > >>details need to be worked through and that IPsec is difficult to use > >>for application security. > >> > >> > > > >Would a discussion of channel binding issues be appropriate here? > > > > > That is one part of it. But there are also other issues, including > authorization decisions that are often hard to do just by looking > at the IP headers from an IPsec policy point of view, (in)ability > of the application to know what protection (if any) its packets > are getting, difficulties in getting the necessary configs in > place either by the administrators or the applications, etc. > Pointing to draft-bellovin-use-ipsec would be good. You've been following BTNS WG, yes? :) From hartmans@MIT.EDU Fri Apr 7 18:18:18 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k37MIIIJ005215 for ; Fri, 7 Apr 2006 18:18:18 -0400 Received: from carter-zimmerman.mit.edu (carter-zimmerman.dyn.mit.edu [18.188.3.148]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k37MIALj016503 for ; Fri, 7 Apr 2006 18:18:14 -0400 (EDT) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 70B80E0053; Fri, 7 Apr 2006 18:18:05 -0400 (EDT) To: Leslie Daigle References: <4435ACC6.8040500@thinkingcat.com> From: Sam Hartman Date: Fri, 07 Apr 2006 18:18:05 -0400 In-Reply-To: <4435ACC6.8040500@thinkingcat.com> (Leslie Daigle's message of "Thu, 06 Apr 2006 20:05:26 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 1.217 X-Spam-Level: * (1.217) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, iab@ietf.org Subject: Re: [saag] Frameworks, multiple mechanisms and draft-iab-auth-mech-05.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2006 22:18:18 -0000 >>>>> "Leslie" == Leslie Daigle writes: Leslie> So, I agree with Bernard's point that the document is Leslie> aiming at protocol *designers*, not the system *deployers* Leslie> you describe as having issues in your preamble. Yes, yes! Leslie> Designed systems must be deployable! But the point is to Leslie> make protocol designers aware of what the ideals are. I Leslie> think that's addressable by a few more lines of context at Leslie> the beginning of the document making it plain who the Leslie> target audience is and how that might differ from Leslie> deployment experience. I agree that the document is aimed at protocol designers. however I claim that if you followed the ideals expressed in this document you would produce protocols that will not be deployed. I argue that ideals that produce results no one wants to use are too idealistic. I believe that if you target protocol designers, give them advice,and they follow tyour advice, you have done a bad job if they come back years later and claim that no one uses their protocol because the advice was too idealistic. (I also think I disagree with the ideals, but that's neither here nor there.) That said, I want to stress that 90% of the document is excellent stuff. When I said I have serious concerns with section 11 and 13, I meant just that. I think that sections 1-10 and 12 are great and that once we resolve 11 and 13 and adjust 14 it will be great too. --Sam From aboba@internaut.com Fri Apr 7 18:36:01 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k37Ma11T007792 for ; Fri, 7 Apr 2006 18:36:01 -0400 Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k37Ma0mh006571; Fri, 7 Apr 2006 18:36:00 -0400 (EDT) Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1FRzYd-000Fkw-Vh; Fri, 07 Apr 2006 18:36:00 -0400 Received: by internaut.com (Postfix, from userid 1000) id 3DAF549716; Fri, 7 Apr 2006 15:35:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id 310CB49712; Fri, 7 Apr 2006 15:35:59 -0700 (PDT) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Fri, 7 Apr 2006 15:35:59 -0700 (PDT) From: Bernard Aboba To: Sam Hartman In-Reply-To: Message-ID: References: <4435ACC6.8040500@thinkingcat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: -2.464 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Leslie Daigle , iab@ietf.org Subject: Re: [saag] Frameworks, multiple mechanisms and draft-iab-auth-mech-05.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2006 22:36:01 -0000 > That said, I want to stress that 90% of the document is excellent > stuff. When I said I have serious concerns with section 11 and 13, I > meant just that. I think that sections 1-10 and 12 are great and that > once we resolve 11 and 13 and adjust 14 it will be great too. >From what I can tell, most of the issues in Section 11 & 14 seem like problems of clarity. That is, I don't think that the document meaning would be changed much if Sam's suggestions were adopted, although the clarity would be improved. I do think that there is a genuine disagreement about Section 13, but that seems mostly like an argument about the 'ideal' rather than practical realities. One way to resolve this issue would be to incorporate the practical considerations that Sam and others have suggested into this Section, and clarifying the problems. From nw141292@binky.Central.Sun.COM Fri Apr 7 18:57:52 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k37MvqXT010765 for ; Fri, 7 Apr 2006 18:57:52 -0400 Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k37Mvk1j000726; Fri, 7 Apr 2006 18:57:47 -0400 (EDT) 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 k37MvkmU022339; Fri, 7 Apr 2006 16:57:46 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k37Mvide028034; Fri, 7 Apr 2006 16:57:46 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k37Mvi7r009453; Fri, 7 Apr 2006 17:57:44 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k37MvhHO009452; Fri, 7 Apr 2006 17:57:43 -0500 (CDT) Date: Fri, 7 Apr 2006 17:57:43 -0500 From: Nicolas Williams To: Bernard Aboba Message-ID: <20060407225743.GO8759@binky.Central.Sun.COM> References: <4435ACC6.8040500@thinkingcat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Leslie Daigle , Sam Hartman , iab@ietf.org Subject: Re: [saag] Frameworks, multiple mechanisms and draft-iab-auth-mech-05.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2006 22:57:52 -0000 On Fri, Apr 07, 2006 at 03:35:59PM -0700, Bernard Aboba wrote: > > That said, I want to stress that 90% of the document is excellent > > stuff. When I said I have serious concerns with section 11 and 13, I > > meant just that. I think that sections 1-10 and 12 are great and that > > once we resolve 11 and 13 and adjust 14 it will be great too. > > >From what I can tell, most of the issues in Section 11 & 14 seem like > problems of clarity. That is, I don't think that the document meaning > would be changed much if Sam's suggestions were adopted, although the > clarity would be improved. Fix the errors, remove bias, clarify :) > I do think that there is a genuine disagreement about Section 13, but > that seems mostly like an argument about the 'ideal' rather than practical > realities. One way to resolve this issue would be to incorporate the > practical considerations that Sam and others have suggested into this > Section, and clarifying the problems. Specifically section 13.2 is flat out bad advice. It's a recipe for a new SASL. I would replace it with "Where possible use a security framework that is applicable to the protocol." How about some advice to the IETF community? Noone should have to choose between EAP, SASL, SSHv2, IKEv2, TLS, or the GSS-API based on what authentication infrastructures their customers will have deployed, but the lack of mechanism specifications for a common set of credential types for all those frameworks means that designers do choose the wrong frameworks for the wrong reasons. Nico -- From ekr@raman.networkresonance.com Sat Apr 8 03:49:13 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k387nD6B013546 for ; Sat, 8 Apr 2006 03:49:13 -0400 Received: from raman.networkresonance.com (raman.networkresonance.com [198.144.196.3]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k387n1Gx020297; Sat, 8 Apr 2006 03:49:01 -0400 (EDT) Received: by raman.networkresonance.com (Postfix, from userid 1001) id 910551E8C1F; Sat, 8 Apr 2006 00:49:00 -0700 (PDT) To: Nicolas Williams References: <4435ACC6.8040500@thinkingcat.com> <20060407225743.GO8759@binky.Central.Sun.COM> From: Eric Rescorla Date: Sat, 08 Apr 2006 00:49:00 -0700 In-Reply-To: <20060407225743.GO8759@binky.Central.Sun.COM> (Nicolas Williams's message of "Fri, 7 Apr 2006 17:57:43 -0500") Message-ID: <868xqgmrrn.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.18 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Leslie Daigle , Sam Hartman , iab@ietf.org, Bernard Aboba Subject: Re: [saag] Frameworks, multiple mechanisms and draft-iab-auth-mech-05.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Reply-To: EKR List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Apr 2006 07:49:13 -0000 Nicolas Williams writes: > On Fri, Apr 07, 2006 at 03:35:59PM -0700, Bernard Aboba wrote: >> > That said, I want to stress that 90% of the document is excellent >> > stuff. When I said I have serious concerns with section 11 and 13, I >> > meant just that. I think that sections 1-10 and 12 are great and that >> > once we resolve 11 and 13 and adjust 14 it will be great too. >> >> >From what I can tell, most of the issues in Section 11 & 14 seem like >> problems of clarity. That is, I don't think that the document meaning >> would be changed much if Sam's suggestions were adopted, although the >> clarity would be improved. > > Fix the errors, remove bias, clarify :) You can call it bias. I call it judgement. >> I do think that there is a genuine disagreement about Section 13, but >> that seems mostly like an argument about the 'ideal' rather than practical >> realities. One way to resolve this issue would be to incorporate the >> practical considerations that Sam and others have suggested into this >> Section, and clarifying the problems. > > Specifically section 13.2 is flat out bad advice. It's a recipe for a > new SASL. > > I would replace it with > > "Where possible use a security framework that is applicable to the > protocol." Sorry,I can't agree with either of these statements. Having lots of authentication mechanisms, especially ones with essentially the same security properties is a bug not a feature. It may be one we're forced into by the current state of people's credentials, but as I indicated before, that's a necessary evil at best. > How about some advice to the IETF community? Noone should have to > choose between EAP, SASL, SSHv2, IKEv2, TLS, or the GSS-API based on > what authentication infrastructures their customers will have deployed, > but the lack of mechanism specifications for a common set of credential > types for all those frameworks means that designers do choose the wrong > frameworks for the wrong reasons. Well, I agree with part of this. Unfortunately, all authentication mechanisms aren't created equal and therefore I don't favor, for instance, putting Digest or Plain into TLS, regardless of what's supported by SASL. -Ekr From nw141292@binky.Central.Sun.COM Sat Apr 8 14:20:58 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k38IKwoI014475 for ; Sat, 8 Apr 2006 14:20:58 -0400 Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k38IKuSM013892; Sat, 8 Apr 2006 14:20:57 -0400 (EDT) Received: from centralmail1brm.Central.Sun.COM (centralmail1brm.central.sun.com [129.147.62.1]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k38IKuZe000142; Sat, 8 Apr 2006 12:20:56 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k38IKsce011834; Sat, 8 Apr 2006 12:20:55 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k38IKs0H010015; Sat, 8 Apr 2006 13:20:54 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k38IKq2x010014; Sat, 8 Apr 2006 13:20:52 -0500 (CDT) Date: Sat, 8 Apr 2006 13:20:52 -0500 From: Nicolas Williams To: EKR Message-ID: <20060408182052.GV8759@binky.Central.Sun.COM> References: <4435ACC6.8040500@thinkingcat.com> <20060407225743.GO8759@binky.Central.Sun.COM> <868xqgmrrn.fsf@raman.networkresonance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <868xqgmrrn.fsf@raman.networkresonance.com> User-Agent: Mutt/1.5.7i X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Leslie Daigle , Sam Hartman , iab@ietf.org, Bernard Aboba Subject: Re: [saag] Frameworks, multiple mechanisms and draft-iab-auth-mech-05.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Apr 2006 18:20:58 -0000 On Sat, Apr 08, 2006 at 12:49:00AM -0700, Eric Rescorla wrote: > Nicolas Williams writes: > > > > Specifically section 13.2 is flat out bad advice. It's a recipe for a > > new SASL. > > > > I would replace it with > > > > "Where possible use a security framework that is applicable to the > > protocol." > > Sorry,I can't agree with either of these statements. Having lots of > authentication mechanisms, especially ones with essentially the same > security properties is a bug not a feature. It may be one we're forced > into by the current state of people's credentials, but as I indicated > before, that's a necessary evil at best. It would be great to have a single mechanism that supports all the types of credentials that people have deployed. It would be even better if there were very, very few credential types deployed. That's NOT how authentication in this space has evolved. Far from it. Lacking such a single unified mechanism (which, incidentally, would have to know how to negotiate credential types, thus making it much like a *framework*), and lacking a single credential type that is universally deployed and applicable I think the advice given in section 13.2 is useless and won't be followed. And where it is followed the result will be the subsequent grafting of additional mechanisms or frameworks to the protocols whose designers followed that advice; that is, the advice in 13.2 is, IMO counter-productive. I understand the sentiment in 13.2, but it isn't practical. > > > How about some advice to the IETF community? Noone should have to > > choose between EAP, SASL, SSHv2, IKEv2, TLS, or the GSS-API based on > > what authentication infrastructures their customers will have deployed, > > but the lack of mechanism specifications for a common set of credential > > types for all those frameworks means that designers do choose the wrong > > frameworks for the wrong reasons. > > Well, I agree with part of this. Unfortunately, all authentication > mechanisms aren't created equal and therefore I don't favor, > for instance, putting Digest or Plain into TLS, regardless > of what's supported by SASL. But do you mind putting support for passwords as credentials into TLS? You could use a better version of digest (with support for legacy verifiers, I suppose), or PA-ENC-TIMESTAMP, or IAKERB, or SRP, or whatever you like. Nico -- From ekr@raman.networkresonance.com Sat Apr 8 14:33:49 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k38IXn7n016550 for ; Sat, 8 Apr 2006 14:33:49 -0400 Received: from raman.networkresonance.com (raman.networkresonance.com [198.144.196.3]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k38IXZuY029067; Sat, 8 Apr 2006 14:33:35 -0400 (EDT) Received: by raman.networkresonance.com (Postfix, from userid 1001) id C3DD51E8C1F; Sat, 8 Apr 2006 11:33:34 -0700 (PDT) To: Nicolas Williams References: <4435ACC6.8040500@thinkingcat.com> <20060407225743.GO8759@binky.Central.Sun.COM> <868xqgmrrn.fsf@raman.networkresonance.com> <20060408182052.GV8759@binky.Central.Sun.COM> From: Eric Rescorla Date: Sat, 08 Apr 2006 11:33:34 -0700 In-Reply-To: <20060408182052.GV8759@binky.Central.Sun.COM> (Nicolas Williams's message of "Sat, 8 Apr 2006 13:20:52 -0500") Message-ID: <86vetjlxxd.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.18 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Leslie Daigle , Sam Hartman , iab@ietf.org, Bernard Aboba Subject: Re: [saag] Frameworks, multiple mechanisms and draft-iab-auth-mech-05.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Reply-To: EKR List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Apr 2006 18:33:49 -0000 Nicolas Williams writes: > On Sat, Apr 08, 2006 at 12:49:00AM -0700, Eric Rescorla wrote: > Lacking such a single unified mechanism (which, incidentally, would have > to know how to negotiate credential types, thus making it much like a > *framework*), and lacking a single credential type that is universally > deployed and applicable I think the advice given in section 13.2 is > useless and won't be followed. And where it is followed the result will > be the subsequent grafting of additional mechanisms or frameworks to the > protocols whose designers followed that advice; that is, the advice in > 13.2 is, IMO counter-productive. > > I understand the sentiment in 13.2, but it isn't practical. I can't agree here. 13.2 explicitly acknowledges that there are cases where there are a variety of credential types. As noted before, it's talking about goals for future designs. >> > How about some advice to the IETF community? Noone should have to >> > choose between EAP, SASL, SSHv2, IKEv2, TLS, or the GSS-API based on >> > what authentication infrastructures their customers will have deployed, >> > but the lack of mechanism specifications for a common set of credential >> > types for all those frameworks means that designers do choose the wrong >> > frameworks for the wrong reasons. >> >> Well, I agree with part of this. Unfortunately, all authentication >> mechanisms aren't created equal and therefore I don't favor, >> for instance, putting Digest or Plain into TLS, regardless >> of what's supported by SASL. > > But do you mind putting support for passwords as credentials into TLS? > You could use a better version of digest (with support for legacy > verifiers, I suppose), or PA-ENC-TIMESTAMP, or IAKERB, or SRP, or > whatever you like. You do realize there's already an RFC on this, right? 4279 Pre-Shared Key Ciphersuites for Transport Layer Security (TLS). P. Eronen, Ed., H. Tschofenig, Ed.. December 2005. (Format: TXT=32160 bytes) (Status: PROPOSED STANDARD) The problem, of course, is that this doesn't help you if, for instance, you're using OTP rather than simple shared passwords. -Ekr From nw141292@binky.Central.Sun.COM Sat Apr 8 15:05:58 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k38J5weX021081 for ; Sat, 8 Apr 2006 15:05:58 -0400 Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k38J5plO023495; Sat, 8 Apr 2006 15:05:52 -0400 (EDT) Received: from centralmail1brm.Central.Sun.COM (centralmail1brm.central.sun.com [129.147.62.1]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k38J5pJO021701; Sat, 8 Apr 2006 13:05:51 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k38J5oce021686; Sat, 8 Apr 2006 13:05:51 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k38J5nWt010033; Sat, 8 Apr 2006 14:05:49 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k38J5nII010032; Sat, 8 Apr 2006 14:05:49 -0500 (CDT) Date: Sat, 8 Apr 2006 14:05:49 -0500 From: Nicolas Williams To: EKR Message-ID: <20060408190549.GW8759@binky.Central.Sun.COM> References: <4435ACC6.8040500@thinkingcat.com> <20060407225743.GO8759@binky.Central.Sun.COM> <868xqgmrrn.fsf@raman.networkresonance.com> <20060408182052.GV8759@binky.Central.Sun.COM> <86vetjlxxd.fsf@raman.networkresonance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86vetjlxxd.fsf@raman.networkresonance.com> User-Agent: Mutt/1.5.7i X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Leslie Daigle , Sam Hartman , iab@ietf.org, Bernard Aboba Subject: Re: [saag] Frameworks, multiple mechanisms and draft-iab-auth-mech-05.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Apr 2006 19:05:58 -0000 On Sat, Apr 08, 2006 at 11:33:34AM -0700, Eric Rescorla wrote: > Nicolas Williams writes: > > On Sat, Apr 08, 2006 at 12:49:00AM -0700, Eric Rescorla wrote: > > Lacking such a single unified mechanism (which, incidentally, would have > > to know how to negotiate credential types, thus making it much like a > > *framework*), and lacking a single credential type that is universally > > deployed and applicable I think the advice given in section 13.2 is > > useless and won't be followed. And where it is followed the result will > > be the subsequent grafting of additional mechanisms or frameworks to the > > protocols whose designers followed that advice; that is, the advice in > > 13.2 is, IMO counter-productive. > > > > I understand the sentiment in 13.2, but it isn't practical. > > I can't agree here. 13.2 explicitly acknowledges that there are cases > where there are a variety of credential types. As noted before, > it's talking about goals for future designs. >13. Guidance for Protocol Designer It's clear that the guidance is for _application_ protocol designers, not authentication protocol desginers. Guidance that can't be followed in "future designs" given current offerings in the authentication space. Which is why I ask for advice for the IETF community. > > >> > How about some advice to the IETF community? Noone should have to > >> > choose between EAP, SASL, SSHv2, IKEv2, TLS, or the GSS-API based on > >> > what authentication infrastructures their customers will have deployed, > >> > but the lack of mechanism specifications for a common set of credential > >> > types for all those frameworks means that designers do choose the wrong > >> > frameworks for the wrong reasons. > >> > >> Well, I agree with part of this. Unfortunately, all authentication > >> mechanisms aren't created equal and therefore I don't favor, > >> for instance, putting Digest or Plain into TLS, regardless > >> of what's supported by SASL. > > > > But do you mind putting support for passwords as credentials into TLS? > > You could use a better version of digest (with support for legacy > > verifiers, I suppose), or PA-ENC-TIMESTAMP, or IAKERB, or SRP, or > > whatever you like. > > You do realize there's already an RFC on this, right? > > 4279 Pre-Shared Key Ciphersuites for Transport Layer Security (TLS). > P. Eronen, Ed., H. Tschofenig, Ed.. December 2005. (Format: TXT=32160 > bytes) (Status: PROPOSED STANDARD) There's nothing there about deriving keys from shared passwords, so, I think RFC4279 is applicable. > The problem, of course, is that this doesn't help you if, for instance, > you're using OTP rather than simple shared passwords. It doesn't even apply to simple memorable passwords because there's no use of PBKDF or anything of the sort. Nico -- From nw141292@binky.Central.Sun.COM Sat Apr 8 15:27:18 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k38JRIMA024525 for ; Sat, 8 Apr 2006 15:27:18 -0400 Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k38JRJAF028847; Sat, 8 Apr 2006 15:27:19 -0400 (EDT) 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 k38JRImU012275; Sat, 8 Apr 2006 13:27:18 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k38JRHde007776; Sat, 8 Apr 2006 13:27:18 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k38JRHJK010047; Sat, 8 Apr 2006 14:27:17 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k38JRHoH010046; Sat, 8 Apr 2006 14:27:17 -0500 (CDT) Date: Sat, 8 Apr 2006 14:27:17 -0500 From: Nicolas Williams To: EKR Message-ID: <20060408192717.GX8759@binky.Central.Sun.COM> References: <4435ACC6.8040500@thinkingcat.com> <20060407225743.GO8759@binky.Central.Sun.COM> <868xqgmrrn.fsf@raman.networkresonance.com> <20060408182052.GV8759@binky.Central.Sun.COM> <86vetjlxxd.fsf@raman.networkresonance.com> <20060408190549.GW8759@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060408190549.GW8759@binky.Central.Sun.COM> User-Agent: Mutt/1.5.7i X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Leslie Daigle , Sam Hartman , iab@ietf.org, Bernard Aboba Subject: Re: [saag] Frameworks, multiple mechanisms and draft-iab-auth-mech-05.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Apr 2006 19:27:18 -0000 On Sat, Apr 08, 2006 at 02:05:49PM -0500, Nicolas Williams wrote: > There's nothing there about deriving keys from shared passwords, so, I > think RFC4279 is applicable. ^ not From ekr@raman.networkresonance.com Sat Apr 8 15:57:46 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k38Jvkxv028946 for ; Sat, 8 Apr 2006 15:57:46 -0400 Received: from raman.networkresonance.com (raman.networkresonance.com [198.144.196.3]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k38Jvfo2009068; Sat, 8 Apr 2006 15:57:42 -0400 (EDT) Received: by raman.networkresonance.com (Postfix, from userid 1001) id 0E6841E8C1F; Sat, 8 Apr 2006 12:57:41 -0700 (PDT) To: Nicolas Williams References: <4435ACC6.8040500@thinkingcat.com> <20060407225743.GO8759@binky.Central.Sun.COM> <868xqgmrrn.fsf@raman.networkresonance.com> <20060408182052.GV8759@binky.Central.Sun.COM> <86vetjlxxd.fsf@raman.networkresonance.com> <20060408190549.GW8759@binky.Central.Sun.COM> From: Eric Rescorla Date: Sat, 08 Apr 2006 12:57:40 -0700 In-Reply-To: <20060408190549.GW8759@binky.Central.Sun.COM> (Nicolas Williams's message of "Sat, 8 Apr 2006 14:05:49 -0500") Message-ID: <86r747lu17.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.18 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Leslie Daigle , Sam Hartman , iab@ietf.org, Bernard Aboba Subject: Re: [saag] Frameworks, multiple mechanisms and draft-iab-auth-mech-05.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Reply-To: EKR List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Apr 2006 19:57:47 -0000 Nicolas Williams writes: > On Sat, Apr 08, 2006 at 11:33:34AM -0700, Eric Rescorla wrote: >> You do realize there's already an RFC on this, right? >> >> 4279 Pre-Shared Key Ciphersuites for Transport Layer Security (TLS). >> P. Eronen, Ed., H. Tschofenig, Ed.. December 2005. (Format: TXT=32160 >> bytes) (Status: PROPOSED STANDARD) > > There's nothing there about deriving keys from shared passwords, so, I > think RFC4279 is applicable. I'm assuming you mean "don't think" here. Anyway, TLS PSK *is* compatible with shared passwords. You simply use the password as the PSK. That's why there's discussion of dictionary attacks in S 7.2. The keys are derived from the passwords in the usual way via the TLS PRF. Of course, this use is discouraged because like all non-ZKPP-based password authentication protocols it's susceptible to dictionary attacks if the server isn't authenticated. Note, however, that unlike Digest TLS PSK is secure against passive dictionary attacks. >> The problem, of course, is that this doesn't help you if, for instance, >> you're using OTP rather than simple shared passwords. > > It doesn't even apply to simple memorable passwords because there's no > use of PBKDF or anything of the sort. Huh? A PBKDF serves two major functions. First, it whitens the password into unstructured keying material. This is unnecessary in this case because, as mentioned above, the password is run through the TLS PRF, which provides whitening. The second is that some such functions provide defenses against dictionary attack, such as salting and iteration. TLS PSK already incorporates salting because it's generally used with ephemeral keying material in the form of the PMS. It doesn't provide iteration but then neither does (say) HTTP Digest, and I don't hear anyone saying that Digest can't be used with memorable passwords. Of course, because the PSK is simply a shared key that's established in an unspecified way, there's nothing stopping you from using any of the RFC 2898 PBKDF functions to derive the shared key used on either side, though as indicated above this is generally unnecessary. -Ekr From nw141292@binky.Central.Sun.COM Sat Apr 8 16:21:58 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k38KLwsi032742 for ; Sat, 8 Apr 2006 16:21:58 -0400 Received: from nwkea-mail-5.sun.com (nwkea-mail-5.sun.com [192.18.42.27]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k38KLieM010631; Sat, 8 Apr 2006 16:21:45 -0400 (EDT) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-5.sun.com (8.12.10/8.12.9) with ESMTP id k38KLcK7011635; Sat, 8 Apr 2006 13:21:43 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k38KLbde016401; Sat, 8 Apr 2006 14:21:38 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k38KLbEK010064; Sat, 8 Apr 2006 15:21:37 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k38KLbip010063; Sat, 8 Apr 2006 15:21:37 -0500 (CDT) Date: Sat, 8 Apr 2006 15:21:37 -0500 From: Nicolas Williams To: EKR Message-ID: <20060408202136.GY8759@binky.Central.Sun.COM> References: <4435ACC6.8040500@thinkingcat.com> <20060407225743.GO8759@binky.Central.Sun.COM> <868xqgmrrn.fsf@raman.networkresonance.com> <20060408182052.GV8759@binky.Central.Sun.COM> <86vetjlxxd.fsf@raman.networkresonance.com> <20060408190549.GW8759@binky.Central.Sun.COM> <86r747lu17.fsf@raman.networkresonance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86r747lu17.fsf@raman.networkresonance.com> User-Agent: Mutt/1.5.7i X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Leslie Daigle , Sam Hartman , iab@ietf.org, Bernard Aboba Subject: Re: [saag] Frameworks, multiple mechanisms and draft-iab-auth-mech-05.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Apr 2006 20:22:02 -0000 On Sat, Apr 08, 2006 at 12:57:40PM -0700, Eric Rescorla wrote: > Nicolas Williams writes: > > On Sat, Apr 08, 2006 at 11:33:34AM -0700, Eric Rescorla wrote: > >> You do realize there's already an RFC on this, right? > >> > >> 4279 Pre-Shared Key Ciphersuites for Transport Layer Security (TLS). > >> P. Eronen, Ed., H. Tschofenig, Ed.. December 2005. (Format: TXT=32160 > >> bytes) (Status: PROPOSED STANDARD) > > > > There's nothing there about deriving keys from shared passwords, so, I > > think RFC4279 is applicable. > > I'm assuming you mean "don't think" here. Yes. > Anyway, TLS PSK *is* compatible with shared passwords. You simply use > the password as the PSK. That's why there's discussion of dictionary > attacks in S 7.2. The keys are derived from the passwords in the > usual way via the TLS PRF. Of course, this use is discouraged because > like all non-ZKPP-based password authentication protocols it's > susceptible to dictionary attacks if the server isn't > authenticated. Note, however, that unlike Digest TLS PSK is secure > against passive dictionary attacks. Yeah, I see, sorry, braino. From nw141292@binky.Central.Sun.COM Sat Apr 8 16:29:22 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k38KTMXw001728 for ; Sat, 8 Apr 2006 16:29:22 -0400 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k38KTLfP022018; Sat, 8 Apr 2006 16:29:21 -0400 (EDT) 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 k38KTKO0004161; Sat, 8 Apr 2006 13:29:20 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k38KTJde017446; Sat, 8 Apr 2006 14:29:20 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k38KTJ0M010076; Sat, 8 Apr 2006 15:29:19 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k38KTJKX010075; Sat, 8 Apr 2006 15:29:19 -0500 (CDT) Date: Sat, 8 Apr 2006 15:29:19 -0500 From: Nicolas Williams To: EKR Message-ID: <20060408202919.GA9282@binky.Central.Sun.COM> References: <4435ACC6.8040500@thinkingcat.com> <20060407225743.GO8759@binky.Central.Sun.COM> <868xqgmrrn.fsf@raman.networkresonance.com> <20060408182052.GV8759@binky.Central.Sun.COM> <86vetjlxxd.fsf@raman.networkresonance.com> <20060408190549.GW8759@binky.Central.Sun.COM> <86r747lu17.fsf@raman.networkresonance.com> <20060408202136.GY8759@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060408202136.GY8759@binky.Central.Sun.COM> User-Agent: Mutt/1.5.7i X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Leslie Daigle , Sam Hartman , iab@ietf.org, Bernard Aboba Subject: Re: [saag] Frameworks, multiple mechanisms and draft-iab-auth-mech-05.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Apr 2006 20:29:22 -0000 On Sat, Apr 08, 2006 at 03:21:37PM -0500, Nicolas Williams wrote: > On Sat, Apr 08, 2006 at 12:57:40PM -0700, Eric Rescorla wrote: > > Nicolas Williams writes: > > > On Sat, Apr 08, 2006 at 11:33:34AM -0700, Eric Rescorla wrote: > > >> You do realize there's already an RFC on this, right? > > >> > > >> 4279 Pre-Shared Key Ciphersuites for Transport Layer Security (TLS). > > >> P. Eronen, Ed., H. Tschofenig, Ed.. December 2005. (Format: TXT=32160 > > >> bytes) (Status: PROPOSED STANDARD) > > > > > > There's nothing there about deriving keys from shared passwords, so, I > > > think RFC4279 is applicable. > > > > I'm assuming you mean "don't think" here. > > Yes. > > > Anyway, TLS PSK *is* compatible with shared passwords. You simply use > > the password as the PSK. That's why there's discussion of dictionary > > attacks in S 7.2. The keys are derived from the passwords in the > > usual way via the TLS PRF. Of course, this use is discouraged because > > like all non-ZKPP-based password authentication protocols it's > > susceptible to dictionary attacks if the server isn't > > authenticated. Note, however, that unlike Digest TLS PSK is secure > > against passive dictionary attacks. > > Yeah, I see, sorry, braino. OTOH, this requires both peers to know/store the same cleartext password, while it should be preferable for one (servers) to store a digest, salted. This is the sort of thing I'd expect of a TLS password authentication extension. Nico -- From ekr@raman.networkresonance.com Sat Apr 8 17:54:27 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k38LsRgG013697 for ; Sat, 8 Apr 2006 17:54:27 -0400 Received: from raman.networkresonance.com (raman.networkresonance.com [198.144.196.3]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k38LsNDW020318; Sat, 8 Apr 2006 17:54:23 -0400 (EDT) Received: by raman.networkresonance.com (Postfix, from userid 1001) id 5D4091E8C1F; Sat, 8 Apr 2006 14:54:22 -0700 (PDT) To: Nicolas Williams References: <4435ACC6.8040500@thinkingcat.com> <20060407225743.GO8759@binky.Central.Sun.COM> <868xqgmrrn.fsf@raman.networkresonance.com> <20060408182052.GV8759@binky.Central.Sun.COM> <86vetjlxxd.fsf@raman.networkresonance.com> <20060408190549.GW8759@binky.Central.Sun.COM> <86r747lu17.fsf@raman.networkresonance.com> <20060408202136.GY8759@binky.Central.Sun.COM> <20060408202919.GA9282@binky.Central.Sun.COM> From: Eric Rescorla Date: Sat, 08 Apr 2006 14:54:22 -0700 In-Reply-To: <20060408202919.GA9282@binky.Central.Sun.COM> (Nicolas Williams's message of "Sat, 8 Apr 2006 15:29:19 -0500") Message-ID: <86ek07lomp.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.18 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Leslie Daigle , Sam Hartman , iab@ietf.org, Bernard Aboba Subject: Re: [saag] Frameworks, multiple mechanisms and draft-iab-auth-mech-05.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Reply-To: EKR List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Apr 2006 21:54:28 -0000 Nicolas Williams writes: > On Sat, Apr 08, 2006 at 03:21:37PM -0500, Nicolas Williams wrote: >> On Sat, Apr 08, 2006 at 12:57:40PM -0700, Eric Rescorla wrote: >> > Nicolas Williams writes: >> > Anyway, TLS PSK *is* compatible with shared passwords. You simply use >> > the password as the PSK. That's why there's discussion of dictionary >> > attacks in S 7.2. The keys are derived from the passwords in the >> > usual way via the TLS PRF. Of course, this use is discouraged because >> > like all non-ZKPP-based password authentication protocols it's >> > susceptible to dictionary attacks if the server isn't >> > authenticated. Note, however, that unlike Digest TLS PSK is secure >> > against passive dictionary attacks. >> >> Yeah, I see, sorry, braino. > > OTOH, this requires both peers to know/store the same cleartext > password, while it should be preferable for one (servers) to store a > digest, salted. This is the sort of thing I'd expect of a TLS password > authentication extension. Yes, it's called HTTP Basic, SASL Plain, etc. At a high level, there are two basic types of non-ZKPP password authentication mechanisms [0]: 1. Ones in which the clients and servers store the same secret (TLS PSK, Digest, etc.) 2. Ones in which the server stores a digest value output and the client sends a preimage (Unix crypt, Basic, etc.) Mechanisms in the first category are vulnerable to keyfile compromise on the server because the verifier and the secret information are one in the same (password equivalence). Mechanisms in the second category are not. The password equivalence problem can be somewhat mitigated by using a shared secret that's a salted digest of the password so that the verifier is only weakly password equivalent. Mechanisms in the first category can be used for mutual authentication and key derivation. Mechanisms in the second category cannot and--because they require exposing the preimage--therefore require that one side be authenticated via some external mechanism (e.g., the stored public key of the server as in SSH). Without such authentication they are highly vulnerable to password capture via server spoofing. The reason that TLS PSK uses this design it does is that (1) The server key wasn't necessarily available for caching (2) mutual authentication was desired and (3) most applications already have some "plain" password authentication mechanism, which is safe when run over TLS, so this mechanism was intended to provide a feature with a different set of security properties. As it happens, these tradeoffs are discussed extensively in Sections 4 and 6 of draft-iab-auth-mech-05. -Ekr [0] ZKPPs can of course provide non-password-equivalence *and* mutual authentication, but the IPR situation is cluttered. From nw141292@binky.Central.Sun.COM Sat Apr 8 18:33:26 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k38MXQlP019494 for ; Sat, 8 Apr 2006 18:33:26 -0400 Received: from nwkea-mail-4.sun.com (nwkea-mail-4.sun.com [192.18.42.26]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k38MXEvV013949; Sat, 8 Apr 2006 18:33:14 -0400 (EDT) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k38MXDM5007673; Sat, 8 Apr 2006 15:33:13 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k38MXCde008629; Sat, 8 Apr 2006 16:33:13 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k38MXBcl010109; Sat, 8 Apr 2006 17:33:11 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k38MX9Df010108; Sat, 8 Apr 2006 17:33:09 -0500 (CDT) Date: Sat, 8 Apr 2006 17:33:09 -0500 From: Nicolas Williams To: EKR Message-ID: <20060408223308.GZ8759@binky.Central.Sun.COM> References: <20060407225743.GO8759@binky.Central.Sun.COM> <868xqgmrrn.fsf@raman.networkresonance.com> <20060408182052.GV8759@binky.Central.Sun.COM> <86vetjlxxd.fsf@raman.networkresonance.com> <20060408190549.GW8759@binky.Central.Sun.COM> <86r747lu17.fsf@raman.networkresonance.com> <20060408202136.GY8759@binky.Central.Sun.COM> <20060408202919.GA9282@binky.Central.Sun.COM> <86ek07lomp.fsf@raman.networkresonance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86ek07lomp.fsf@raman.networkresonance.com> User-Agent: Mutt/1.5.7i X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Leslie Daigle , Sam Hartman , iab@ietf.org, Bernard Aboba Subject: Re: [saag] Frameworks, multiple mechanisms and draft-iab-auth-mech-05.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Apr 2006 22:33:26 -0000 On Sat, Apr 08, 2006 at 02:54:22PM -0700, Eric Rescorla wrote: > The reason that TLS PSK uses this design it does is that ... None of this is relevant to my argument about section 13.2. I've said my piece on that. Nico -- From mcr@sandelman.ottawa.on.ca Sun Apr 9 17:54:37 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k39Lsa90028824 for ; Sun, 9 Apr 2006 17:54:37 -0400 Received: from lists.sandelman.ca (cod.sandelman.ca [192.139.46.139]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k39LsUP8023241 for ; Sun, 9 Apr 2006 17:54:33 -0400 (EDT) Received: from sandelman.ottawa.on.ca (dsl081-244-081.sfo1.dsl.speakeasy.net [64.81.244.81]) by lists.sandelman.ca (8.11.6p3/8.11.6) with ESMTP id k39LsOc13319 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Sun, 9 Apr 2006 17:54:28 -0400 (EDT) Received: from sandelman.ottawa.on.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id A7B9F3ADA9 for ; Sun, 9 Apr 2006 09:56:24 -0700 (PDT) To: saag@mit.edu In-Reply-To: Message from Juergen Quittek of "Thu, 23 Mar 2006 20:05:05 +0100." References: X-Mailer: MH-E 7.82; nmh 1.1; XEmacs 21.4 (patch 17) Date: Sun, 09 Apr 2006 09:56:24 -0700 Message-ID: <23638.1144601784@sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Score: 0 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] WG reports X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Apr 2006 21:54:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I very much like having all of the WG session summaries. I know that this isn't new, but it's now gotten universal and very useful. May I ask something minor: expand the WG name at least once Yeah, *I* know how to look up WG names to find the charter. (But, I can't on the airplane...) However, some of the people that I might forward the report to, in order to say "you need to be involved in this", will not know at all. - -- ] 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.4.1 (GNU/Linux) Comment: Finger me for keys iQEVAwUBRDk8t4CLcPvd0N1lAQJs4Qf5AaJ31dR2jAagX3YOBrs571NsftQJUirT Pk9ojpDNcKRvs4qpNatTRMhUChLsPKgnheeLgyqlw5jyQOkZIdYbLcckFx2S6KB9 7yeA7j97axUhbQzuHKWN1hnrBIc1OJzT53rJVRlUxBn/h4OCGTD0wn5WYGtQ+4ZY f7IXoMocBpyR8VWzuaEPx9B+VKPQ/o6PBCkFGh4TVNsk1gCzjnb1U8YSZ3CgdyI2 qltZS+av/MRLwCfowJQQQON05HeHOMLfGDS0/Llxy54hoYtMh6juJKRYK74VWS8x iUW6FueYLHxNrW4QnJvVjQ7O/FV1t9fs/pWUqkncAlG3zNiGaYArkQ== =Non7 -----END PGP SIGNATURE----- From jaltman@columbia.edu Mon Apr 10 02:11:17 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3A6BHnR007626 for ; Mon, 10 Apr 2006 02:11:17 -0400 Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k3A694uw025994; Mon, 10 Apr 2006 02:09:05 -0400 (EDT) Received: from [192.168.1.13] (cpe-68-175-91-105.nyc.res.rr.com [68.175.91.105]) (user=jaltman mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.6/8.13.6) with ESMTP id k3A68wIc017329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 10 Apr 2006 02:08:59 -0400 (EDT) Message-ID: <4439F703.3090108@columbia.edu> Date: Mon, 10 Apr 2006 02:11:15 -0400 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Jeffrey Altman References: <86psjvemfv.fsf@raman.networkresonance.com> <20060405215337.GJ2895@binky.Central.Sun.COM> <86ek0bele1.fsf@raman.networkresonance.com> <20060405220027.GL2895@binky.Central.Sun.COM> <86acazekya.fsf@raman.networkresonance.com> <20060405224028.GP2895@binky.Central.Sun.COM> <44344F37.5080505@columbia.edu> In-Reply-To: <44344F37.5080505@columbia.edu> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050909020607040607060907" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.42 X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: -2.6 X-Spam-Flag: NO Cc: saag@mit.edu, iab@ietf.org, Sam Hartman , Nicolas Williams Subject: Re: [saag] Frameworks, multiple mechanisms and draft-iab-auth-mech-05.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2006 06:11:17 -0000 This is a cryptographically signed message in MIME format. --------------ms050909020607040607060907 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Jeffrey Altman wrote: > I have not had time to read the document yet either and I am going to > refrain from putting forward a complete argument until I do. I have now had time to sit down and read the document. Let me start off by providing some comments on specific sections. Section 4.6. List of Systems that Use Passwords in the Clear * please qualify the TELNET entry with "when neither the AUTH nor START-TLS options are in use" * please add "FTP when none of GSSAPI-KRB5, SRP nor TLS are negotiated" Section 11.2. Multiple Equivalent Mechanisms I believe this section misrepresents the reasons why there are a proliferation of authentication mechanisms within organizations: (1) the vast majority of existing Internet protocols do not provide for a common subset of authentication mechanisms that can be used. simply by deploying application protocols organizations have been forced to implement a hodgepodge of mechanisms. (2) most large organizations are still struggling with the concept of "SINGLE PASSWORD" let alone "SINGLE AUTHENTICATION MECHANISM". Organizations are achieving "SINGLE PASSWORD" in many cases by implementing password validation through RADIUS or LDAP "simple" bind perhaps backed by a Kerberos AS / TGS authentication. (3) many large organizations that have accomplished "SINGLE PASSWORD" are considering the deployment of SecureID because they believe that doing so will provide them a fast track to closing the door against active attacks. Trojan SSH clients have been discovered on large numbers of unmanaged end user computers and they are being used to gather usernames, passwords and host information. As pointed out in this document SecureID and other OTPs can be deployed without requiring changes in the client software. As the end user machines are unmanaged it is impossible to ensure that they are updated. Forcing the use of GSS key exchange instead of passwords for SSH will only result in the "kinit" binary being trojan'd instead. Note that using private key authentication here does not help either because the trojan client can simply obtain the password for the private key file and then obtain the private key. In many ways this is a worse form of compromise because the private keys are not centrally managed and it is unknown how many systems might be vulnerable when a single private key is compromised. (4) organizations are desperate to be able to choose an appropriate set of authentication mechanisms. however, until the application protocols support a broad enough common subset it will be next to impossible for migration strategies to be implemented. 11.3. Excessive Layering (1) As pointed out previously, the last two sentences of paragraph one are factually wrong. (2) The PPP->EAP->TLS example is unfair. EAP is used in protocols other than PPP. While its creation may have been motivated by a to extend PPP's authentication model, EAP could not have been replaced by either SASL or GSS-API. Nor could it have been replaced directly by TLS. The communication flows within EAP are sufficiently distinct from SASL or GSS-API that it would be challenging to replace EAP with anything and still satisfy the requirements of the application protocols that use it. It is certainly a bad policy to intentionally build a new negotiation protocol on top of an existing framework that already supports one. In those circumstances it is crucial that the application protocol state which one will be used. Using both is the wrong answer in all cases because of the problems associated with analyzing the downgrade attacks. 11.4. List of Generic Authentication Systems I believe that SSH and TLS should both be added to the list. 12.2. Single Sign-On The fact that "users don't necessarily want to have to manually authenticate each time some service wants authentication" is not the reason we want to promote single sign-on. We don't want the user to manually authenticate every time because doing so trains the user to supply their credentials so frequently that they will not think it is strange when they are asked to provide them to an attacker. The only way to prevent phishing attacks are by training users that they only authenticate in very small number of circumstances that rarely occur. Paragraph two states "if certificate-based authentication is being used, this is relatively straightforward." I believe that this sentence is an example of a pro-PKI bias that exists throughout the document. Using certificates or public key is not a solution to all of the world's authentication problems. However, there is not a single discussion in this document describing the significant challenges associated with validating certificates and the complete inability to validate raw public keys. Last week's NIST PKI 2006 workshop was filled with presentations describing attempts to implement validation that have either failed outright or have had to be scaled back due to the severe impact that validation procedures have on the usability of applications. 12.4. Case Study: Kerberos Quote "Kerberos is a popular authentication/single sign-on service, especially in academic environments." While it is true that there are some particularly large Kerberos deployments in academia the most significant ones are those deployed within Microsoft Windows domains and forests of domains. There is also a significant deployment in multi-national corporations. I recommend removing the "especially in academic environments" qualification. 13.1.1. What is my threat model? I believe that most application protocol designers reading this text would not understand how to document a threat model because they will not look at their protocol the way an attacker would do so. It might be useful to provide a case study or two providing examples of what a real threat analysis might look like. 13.4. Avoid inventing something new The last sentence indicates that IPSec or TLS should be used when a channel security system is required. In order to utilize either protocol as a secure channel, the application must be able to bind its authentication to the channel. This requires that "channel bindings" be available. The internet draft "Clarifications and Extensions to the GSS-API for the Use of Channel Bindings", draft-ietf-kitten-gssapi-channel-bindings-01.txt, describes how channel bindings can be defined for SSH, TLS, and IPSec such that application protocols can in fact securely rely on the pre-existing protocols. This document should include a section describing what a channel binding is and why it is important. 14.1.2. One side has an authenticated key pair This section makes the assumption that the authentication of the key pair is able to perform a reasonable validation procedure. At the current time there do not exist deployable public key validation procedures. CRLs and OCSP simply have not yet been demonstrated to be practical in real life deployments. For example, Microsoft was forced to disable both CRL and OCSP validation in Windows and Internet Explorer because of the negative impact on end user experience. --------------ms050909020607040607060907 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAw7NrDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNTI3MTc0MjQzWhcNMDYwNTI3MTc0MjQz WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+LutDu/YyHreNfoYd+ZtOjXsL h67F2cmcVuBPBz+ZGDA+WpVEHrqXaZZO8acXBR5uAVfiwA1acE/kvD/CN5kAqx1VJuQ8Pvyk iGHhUYTd27ZTliBIrptC7C/381gVwkS+a8jQFPJPO+OktZDzAYplGRY/MQCV8dIsvXUjucox 7TwTTdoLAJYRvHtfEcaCc6mO4ph6NeXQw8Grlx3IRAlTrkE5fBGyjH6R4fqnFTXRQAh1/bG+ i8hQvE6mud3mXdL2t7NP1Qxd9wW0/F/pnWY12IFP/luc3zEzIPvAe+nJluLuSEj0LZgP16mF xBj1p+u9HPWcHRVX6q7+MQ0RWOv1AgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAUDUuzxiq8bbI8vq2 swRK513RphZp+fepyKU5mwBI6aF4GcmqITQILtfTG2SXnjSeY99d+bjOdK1DJFvVh9aOy8mh 2NbEnqMnJIZtg5+eEU64DIV5bQdDRpi99H9vA0sRATIquut+3YHba+zArj0VkVof2VI+ToBu sHdtSrZYo0gwggL6MIICY6ADAgECAgMOzawwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MDUyNzE3NDI0M1oXDTA2 MDUyNzE3NDI0M1owazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvi7rQ7v2Mh63 jX6GHfmbTo17C4euxdnJnFbgTwc/mRgwPlqVRB66l2mWTvGnFwUebgFX4sANWnBP5Lw/wjeZ AKsdVSbkPD78pIhh4VGE3du2U5YgSK6bQuwv9/NYFcJEvmvI0BTyTzvjpLWQ8wGKZRkWPzEA lfHSLL11I7nKMe08E03aCwCWEbx7XxHGgnOpjuKYejXl0MPBq5cdyEQJU65BOXwRsox+keH6 pxU10UAIdf2xvovIULxOprnd5l3S9rezT9UMXfcFtPxf6Z1mNdiBT/5bnN8xMyD7wHvpyZbi 7khI9C2YD9ephcQY9afrvRz1nB0VV+qu/jENEVjr9QIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAFA1 Ls8YqvG2yPL6trMESudd0aYWafn3qcilOZsASOmheBnJqiE0CC7X0xtkl540nmPfXfm4znSt QyRb1YfWjsvJodjWxJ6jJySGbYOfnhFOuAyFeW0HQ0aYvfR/bwNLEQEyKrrrft2B22vswK49 FZFaH9lSPk6AbrB3bUq2WKNIMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMOzaww CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDYwNDEwMDYxMTE1WjAjBgkqhkiG9w0BCQQxFgQUJzpDnx5xrDLSihZYJgepGXDl1YQw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrDB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMOzawwDQYJKoZIhvcNAQEBBQAEggEABN871kCckMnSQRKMZ2XS6ojy7zdVCf5YiPCvjHyQ k7uNtiSZSSbGKNlmz7eyEI+4gf+mKTE4mUH/O8Lb59MpAvwhXYa6myUq/onaHmQ1sig4oxks WrvtFoTUE+JGfOQqaHg3nPVwKf0XLMFeLOM5PR+NoMFnT68rkjEXXx8Fn5A+MKMcHoHgP9Wv SzG6vlZXAlZCdexSkml1u3ktPcRBe0dX1TjJrloBhvMGl6BDgxyukNK74SDUuRT7jg/FWBnk RbTFYskN6nv+FMG/zhY9TYKHpq0m+IMsWWEnSx7h2DZtpxacm7cuBFYrbNOyxYw6B1EfPLAE m42lssXpXiXaXgAAAAAAAA== --------------ms050909020607040607060907-- From pgut001@cs.auckland.ac.nz Mon Apr 10 09:20:18 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3ADKHed024010 for ; Mon, 10 Apr 2006 09:20:18 -0400 Received: from groucho.itss.auckland.ac.nz (groucho.itss.auckland.ac.nz [130.216.190.11]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k3ADK6lk028732; Mon, 10 Apr 2006 09:20:07 -0400 (EDT) Received: from localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) by groucho.itss.auckland.ac.nz (Postfix) with ESMTP id EF54C35537; Tue, 11 Apr 2006 01:20:05 +1200 (NZST) Received: from groucho.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03956-10; Tue, 11 Apr 2006 01:20:05 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by groucho.itss.auckland.ac.nz (Postfix) with ESMTP id 2C2A434512; Tue, 11 Apr 2006 01:20:04 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id C94563775D; Tue, 11 Apr 2006 01:20:04 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1FSwJR-0004PG-00; Tue, 11 Apr 2006 01:20:13 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: jaltman@columbia.edu In-Reply-To: <4439F703.3090108@columbia.edu> Message-Id: Sender: pgut001 Date: Tue, 11 Apr 2006 01:20:13 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, iab@ietf.org, hartmans-ietf@mit.edu, nicolas.williams@sun.com Subject: Re: [saag] Frameworks, multiple mechanisms and draft-iab-auth-mech-05.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2006 13:20:18 -0000 Jeffrey Altman writes: >Note that using private key authentication here does not help either because >the trojan client can simply obtain the password for the private key file and >then obtain the private key. In many ways this is a worse form of compromise >because the private keys are not centrally managed and it is unknown how many >systems might be vulnerable when a single private key is compromised. A recent study on SSH trusted host vulnerabilities found that *two thirds* of all SSH private keys were stored unencrypted, so you wouldn't even need to obtain the password, just read the plaintext private key from disk. (I've encountered this situation myself a number of times on various systems, users are required to use SSH public-key auth rather than passwords, but it's quite OK to store the private key in plaintext form on disk. I've queried the people who set this strange policy on a number of occasions and from my extremely non-rigorous checking it seems to be based on some voodoo belief that using public keys instead of passwords automatically makes the authentication mechanism secure. The first time I ran into it I thought it was just one sysadmin with funny ideas, but I've run into it again and again since then). Peter. From jaltman@columbia.edu Mon Apr 10 11:22:03 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3AFM3p8012920 for ; Mon, 10 Apr 2006 11:22:03 -0400 Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k3AFM0EV020733 for ; Mon, 10 Apr 2006 11:22:00 -0400 (EDT) Received: from [192.168.1.13] (cpe-68-175-91-105.nyc.res.rr.com [68.175.91.105]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.6/8.13.6) with ESMTP id k3AFLxap010431 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 10 Apr 2006 11:22:00 -0400 (EDT) Message-ID: <443A789F.8080607@columbia.edu> Date: Mon, 10 Apr 2006 11:24:15 -0400 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: saag@mit.edu References: <86psjvemfv.fsf@raman.networkresonance.com> <20060405215337.GJ2895@binky.Central.Sun.COM> <86ek0bele1.fsf@raman.networkresonance.com> <20060405220027.GL2895@binky.Central.Sun.COM> <86acazekya.fsf@raman.networkresonance.com> <20060405224028.GP2895@binky.Central.Sun.COM> <44344F37.5080505@columbia.edu> <4439F703.3090108@columbia.edu> In-Reply-To: <4439F703.3090108@columbia.edu> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000009060302020902030403" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.42 X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: -2.6 X-Spam-Flag: NO Subject: Re: [saag] Frameworks, multiple mechanisms and draft-iab-auth-mech-05.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2006 15:22:03 -0000 This is a cryptographically signed message in MIME format. --------------ms000009060302020902030403 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I forgot to add my comments on 13.2. 13.2. Use As Few Mechanisms as You Can While I agree that in an ideal world an application protocol would support a single authentication mechanism (or a carefully restricted set of mechanisms), the reality is that application protocols that interface with end users must be support the authentication methods used within the deploying organization. This section appears to argue that application protocol designers are supposed to restrict the authentication methods that can be deployed with the protocol. While I can agree with the notion that those who manage the applications in the field should not accept more than an single authentication mechanism (or perhaps one of each class of mechanisms as described in paragraph 2), I cannot agree that it is the application protocol designed who should be enforcing the restriction. The use of mechanism frameworks provide organizations the ability to transition from a weaker authentication mechanism to a stronger one. Mechanism agility does not have to mean susceptibility to downgrade attacks provided that weaker authentication mechanisms are not accepted. I believe this section should be re-written to argue in favor of mechanism agility within the protocol as well as the need for appropriate text providing advice to implementors and those who deploy within the protocol documentation. --------------ms000009060302020902030403 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC AvowggJjoAMCAQICAw7NrDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwNTI3MTc0MjQzWhcNMDYwNTI3MTc0MjQz WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+LutDu/YyHreNfoYd+ZtOjXsL h67F2cmcVuBPBz+ZGDA+WpVEHrqXaZZO8acXBR5uAVfiwA1acE/kvD/CN5kAqx1VJuQ8Pvyk iGHhUYTd27ZTliBIrptC7C/381gVwkS+a8jQFPJPO+OktZDzAYplGRY/MQCV8dIsvXUjucox 7TwTTdoLAJYRvHtfEcaCc6mO4ph6NeXQw8Grlx3IRAlTrkE5fBGyjH6R4fqnFTXRQAh1/bG+ i8hQvE6mud3mXdL2t7NP1Qxd9wW0/F/pnWY12IFP/luc3zEzIPvAe+nJluLuSEj0LZgP16mF xBj1p+u9HPWcHRVX6q7+MQ0RWOv1AgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAUDUuzxiq8bbI8vq2 swRK513RphZp+fepyKU5mwBI6aF4GcmqITQILtfTG2SXnjSeY99d+bjOdK1DJFvVh9aOy8mh 2NbEnqMnJIZtg5+eEU64DIV5bQdDRpi99H9vA0sRATIquut+3YHba+zArj0VkVof2VI+ToBu sHdtSrZYo0gwggL6MIICY6ADAgECAgMOzawwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MDUyNzE3NDI0M1oXDTA2 MDUyNzE3NDI0M1owazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvi7rQ7v2Mh63 jX6GHfmbTo17C4euxdnJnFbgTwc/mRgwPlqVRB66l2mWTvGnFwUebgFX4sANWnBP5Lw/wjeZ AKsdVSbkPD78pIhh4VGE3du2U5YgSK6bQuwv9/NYFcJEvmvI0BTyTzvjpLWQ8wGKZRkWPzEA lfHSLL11I7nKMe08E03aCwCWEbx7XxHGgnOpjuKYejXl0MPBq5cdyEQJU65BOXwRsox+keH6 pxU10UAIdf2xvovIULxOprnd5l3S9rezT9UMXfcFtPxf6Z1mNdiBT/5bnN8xMyD7wHvpyZbi 7khI9C2YD9ephcQY9afrvRz1nB0VV+qu/jENEVjr9QIDAQABozEwLzAfBgNVHREEGDAWgRRq YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAFA1 Ls8YqvG2yPL6trMESudd0aYWafn3qcilOZsASOmheBnJqiE0CC7X0xtkl540nmPfXfm4znSt QyRb1YfWjsvJodjWxJ6jJySGbYOfnhFOuAyFeW0HQ0aYvfR/bwNLEQEyKrrrft2B22vswK49 FZFaH9lSPk6AbrB3bUq2WKNIMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0 ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/ cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8 YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4 Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMOzaww CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDYwNDEwMTUyNDE1WjAjBgkqhkiG9w0BCQQxFgQUUI5TFdmOr/f+7PGv9OW/SSzU3mEw UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAw7NrDB6BgsqhkiG9w0B CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AgMOzawwDQYJKoZIhvcNAQEBBQAEggEAb3Exjuch1Zomjpdlfn9ohbtAxfvwZJZKLkKkih7b TvvRoY8IZ62dhwG4JbkUuKWTpfUhRJXRnpmJJpvCqwSYZnhN9tndNLQDcpzlBHq+pcEwv7D/ UH95OXtxysVLQaS3IZHDdx3JdQ+ujk/Ua24vuuirau6pPAHhKR3bdvr/FjbOX+cwYfWdJs6o zFDzRa1zXVlEZ12ewXcV3jRmzXWEv5Ninm8D+osjy79/q5fSBsr1pE6ff3uwBuAaCKMGxSSz HguygjkdutKmmgJy+tRjO0pd/2U6Xu1rktVDUdJrp5oy57aiNNhMvvmqC+qhJ1sdwsZFP8QK VPqpW0DsfKcOIAAAAAAAAA== --------------ms000009060302020902030403-- From mcr@sandelman.ottawa.on.ca Mon Apr 10 12:19:40 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3AGJeBA022806 for ; Mon, 10 Apr 2006 12:19:40 -0400 Received: from lists.sandelman.ca (cod.sandelman.ca [192.139.46.139]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k3AGHRTr012656 for ; Mon, 10 Apr 2006 12:17:30 -0400 (EDT) Received: from sandelman.ottawa.on.ca (67-134-5-248.dia.static.qwest.net [67.134.5.248]) by lists.sandelman.ca (8.11.6p3/8.11.6) with ESMTP id k3AGHE027676 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Mon, 10 Apr 2006 12:17:17 -0400 (EDT) Received: from sandelman.ottawa.on.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id A6BAA3AD9C; Mon, 10 Apr 2006 09:17:13 -0700 (PDT) To: pgut001@cs.auckland.ac.nz (Peter Gutmann) In-Reply-To: Message from pgut001@cs.auckland.ac.nz (Peter Gutmann) of "Tue, 11 Apr 2006 01:20:13 +1200." References: X-Mailer: MH-E 7.82; nmh 1.1; XEmacs 21.4 (patch 17) Date: Mon, 10 Apr 2006 09:17:13 -0700 Message-ID: <10268.1144685833@sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Score: -2.464 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, iab@ietf.org Subject: Re: [saag] Frameworks, multiple mechanisms and draft-iab-auth-mech-05.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2006 16:19:40 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Peter" == Peter Gutmann writes: Peter> (I've encountered this situation myself a number of times on Peter> various systems, users are required to use SSH public-key Peter> auth rather than passwords, but it's quite OK to store the Peter> private key in plaintext form on disk. I've queried the Peter> people who set this strange policy on a number of occasions It's this kind of elistism that keeps people from actually ever improving incrementally. let's see: a) public/private key pair system that has no active or passive attacks on the wire, with an end-host compromise a concern. b) a username/password system vulnerable to active dictionary attacks, unless the password is very strong, and therefore stored in a Word file and/or browser password manager, and therefore vulnerable to an end-host compromise. I pick (a) every time, because I know how to "upgrade" that to be better (trivial method: ssh-agent). (b) is already as good as it can be. - -- ] 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.4.1 (GNU/Linux) Comment: Finger me for keys iQEVAwUBRDqFBICLcPvd0N1lAQLjWAf/aeJ5ByqyfMn2CZzDMvpeviqWnM+c2OmS dSDhuq1xmxmX8U45Sv3UfXvtoE3SmvLPmJjhAjyzFjpM0bMCRkX1dzynJMFaH1YR YRQ5SkOSbdoR2e7SL2rO5qNrm0T6otstfnLLaE7PDgc9HdcJKI+iiaEvlkfL6XtB Jo+tma9pBlYwNIm3YV6jQCymgzi6L9kA3duc6gNtnZpnGDtvOmju+2rbmi2bUVfH liWDe4RLooCc1vWT4bI7qts8ZAibSBOOlk1mBIZM9Zf1htoQu88a7wXBX9pd8HpS gt1YLSWGZUkR2VerbXwyUJlKoPz01nrZRWSHOywI3JfCuSgHw+fDcg== =KJ+i -----END PGP SIGNATURE----- From mouse@Sparkle.Rodents.Montreal.QC.CA Mon Apr 10 12:26:47 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3AGQkkB023949 for ; Mon, 10 Apr 2006 12:26:47 -0400 Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k3AGQg3p002275 for ; Mon, 10 Apr 2006 12:26:42 -0400 (EDT) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id MAA17176; Mon, 10 Apr 2006 12:26:41 -0400 (EDT) From: der Mouse Message-Id: <200604101626.MAA17176@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. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Mon, 10 Apr 2006 12:21:21 -0400 (EDT) To: saag@mit.edu In-Reply-To: References: X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: Re: [saag] Frameworks, multiple mechanisms and draft-iab-auth-mech-05.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2006 16:26:47 -0000 > A recent study on SSH trusted host vulnerabilities found that *two > thirds* of all SSH private keys were stored unencrypted, [...] > ([...] seems to be based on some voodoo belief that using public keys > instead of passwords automatically makes the authentication mechanism > secure. [...]) Well, for some threat models it does. For cases where your threat consists of network sniffing, for example. Yes, that's not all cases. But it's not no cases, either. (Anytime I see something spoken of as "secure" without specyfing what it's putatively secure against, this little alert goes off in my mind....) I would hazard a guess that it's fewer cases than it once was, though. Likely, significantly fewer, even. /~\ 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 leslie@thinkingcat.com Thu Apr 6 20:05:37 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3705bmK031229 for ; Thu, 6 Apr 2006 20:05:37 -0400 Received: from zeke.ecotroph.net (zeke.blacka.com [69.31.8.124]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k3705YkA008175; Thu, 6 Apr 2006 20:05:35 -0400 (EDT) Received: from [192.168.0.101] ([::ffff:64.102.254.33]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Thu, 06 Apr 2006 20:04:35 -0400 id 015881A3.4435AC93.000043DC Message-ID: <4435ACC6.8040500@thinkingcat.com> Date: Thu, 06 Apr 2006 20:05:26 -0400 From: Leslie Daigle User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: Sam Hartman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.017 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 X-Mailman-Approved-At: Mon, 10 Apr 2006 13:34:05 -0400 Cc: saag@mit.edu, iab@ietf.org Subject: Re: [saag] Frameworks, multiple mechanisms and draft-iab-auth-mech-05.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2006 00:05:37 -0000 Security is not my claimed area of expertise. However, reading through this thread and re-reading the document, attempting to get some sense of where the IAB should go with this, my take is: 1/ Most of the *specific* comments that have been offered on the document are quite helpful -- clearly there are places where the document suffered from its four years of editing history; others where the current text must be misleading (as it's mislead readers here); and still others where there are simply good ideas of what to include. I'm sure Eric will continue to respond on point. 2/ Most of the disconnect & heat appears to be at the high level, which is misleading in and of itself -- as I read your opening paragraphs, I grew particularly concerned that we were completely on different pages. Which is belied by the point above! So, I agree with Bernard's point that the document is aiming at protocol *designers*, not the system *deployers* you describe as having issues in your preamble. Yes, yes! Designed systems must be deployable! But the point is to make protocol designers aware of what the ideals are. I think that's addressable by a few more lines of context at the beginning of the document making it plain who the target audience is and how that might differ from deployment experience. 3/ On the specific point of using frameworks: clearly, there is a difference of opinion about their utility (whether they are useful, and how to use them) -- I believe there will need to be some more discussion of that point within the IAB. Like Brian, I would hate for a document to go out that SAAG has big issues with, but my *job* is actually to make sure it's a document that the *IAB* is comfortable with. :-) Leslie. Sam Hartman wrote: > > Hi. I'd like to bring up serious concerns about sections 11.2, 11.3 > and 13.2-4 in draft-iab-auth-mech05.txt. I understand that document > represents an IAB consensus not an IETF consensus. However I think it > would be confusing to people if the IAB publishes recommendations and > protocol designers get significant pushback (especially at the IETF > last call and IESG review/wg chartering stages) for following the IAB > recommendations. I believe that will happen in this instance. I > would like to work with the IAB to get the recommendations in line > with what I think the community is doing; if that proves impossible I > would like to encourage the IAB to add a warning about the conflict. > > My main concern is that the IAB recommends choosing a small number of > mechanisms and clearly stating this minimal set in the protocol > specification. I believe that there are cases where it is appropriate > to do that. For example, DKIM and most of DNSSEC require everyone on > the Internet to use the same mechanisms for authentication. > I expect we will see similar issues for infrastructure protocols like BGP. > > > > However there are a lot of protocols for which authentication happens > within an organization or within a group of cooperating organizations. > For these environments related protocol effects and deployment costs > are important to consider and the existing IAB recommendations do not > adequately address these issues. > > The major cost in deploying security is deploying new credentials and > deploying security infrastructure. If some protocol or program > requires my users to all change their passwords so it can store > passwords with a different hash function, it will cost me more to > deploy. If I'm using passwords and your protocol requires me to > purchase tokens for all my users, that is a huge cost both in terms of > tokens, user education, help desk costs, etc. Infrastructure cost is > important too. If I run everything through radius for authorization > and your protocol has an authentication scheme that doesn't work well > with radius, that is a problem. I'm depending on radius for > authorization, for my accounting and to give me one central location > for my credentials. Similarly if all you support is RADIUS and I'm a > Kerberos deployment, then I'm going to have huge costs deploying your > protocol. > (As a practical matter, supporting RADIUS means supporting http digest > auth or plaintext passwords. I do realize that protocols do not > typically support RADIUS directly.) > > The important thing to remember here is that these costs depend on > what the organization considering adopting your protocol has already > deployed. We have significant evidence that people will avoid > security features in protocols rather than deploying new security > infrastructure. I think it is true that people will even choose > avoiding certain protocols rather than deploying new security but I > have less evidence for that. > > We have many examples of protocols that started out with a small > number of mechanisms just as the IAB suggests they should but that > have had to add support for a framework so they would be deployable. > An obvious example is SNMP. We formed the isms working group to add > support for more authentication mechanisms because operators found > that SNMP did not support the authentication mechanisms they were > using. AS a result, we have added support for the ssh framework. The > mechanisms in SNMP were not bad. It did use shared keys, but the key > management was well designed. Operators simply did not have that > infrastructure deployed and id not want to deploy a new security > infrastructure when they already had one deployed. > > We've seen the need to add support for existing security > infrastructures to other protocols. For example one of the things > that Jabber wanted to do as part of the XMPP transition was add > support for new security mechanisms. There existing mechanisms were > weak. But they explicitly wanted to be able to have framework support > so they could match security to what was available in deployed > environments. > > > Protocols like POP and IMAP started out with one simple mechanism: > plaintext passwords. That is still the dominant mechanism used. > However enough deployment environments have needed support for > mechanisms specific to those environments that SASL was invented to > solve a perceived need. > > Perhaps you can argue that SASL was unnecessary complexity and that > IMAP should have just added an authchallenge and authkerberos command > (with no specific command needed for certificates). But then why was > SASL adopted in other protocols like POP and SMTP? Why has it been > successful? > > Of course the apps and ops areas are not the only place where > deployment constraints have made it useful to add support for > authentication frameworks. IKE V2 ended up supporting EAP because it > was needed for environments where certificate authentication was not > sufficient. > > So, I think there is more work to do in these sections. In > particular, I think that you should read this document and come away > with the impression that it will be common for you to end up at > SASL+TLS as a solution for typical client-server applications without > special requirements and end up with EAP as a solution for network > access applications. We can work through (or the IAB can work through > without input) whether there are constraints I'm not aware of now, but > the current text seems deeply suspect. If I follow the current text I > would get the impression that either most of the existing work in the > IETF is a corner case or it has been done wrong. I believe neither of > those statements. > > > Another problem is with the idea that protocols should support > multiple mechanisms but that they should not use an existing > framework. Designing facilities to allow multiple authentication > mechanisms in a protocol is hard--I think possibly just as hard as > designing an authentication mechanism. I am just as worried about a > proliferation of mechanisms to select authentication mechanisms as I > am about authentication mechanisms. If you need more than one > authentication mechanism in your protocol, you should have good > justification for why you are inventing negotiation yourself. It's > taken a long time to get EAP, SASL and GSSAPI right; we should not > encourage people to repeat this work badly unless their requirements > are actually differently. I don't think simplicity is a sufficient > argument in many cases, because we have a history over time of finding > that the simple solutions are not good enough. > > > > So, here are some specific concerns: > > In section 11, the document claims that frameworks are attractive to > protocol designers because they theoretically allow them to ignore > security issues. I think that wording misses the actual benefits of > the frameworks. When properly used, frameworks allow protocol > designers to treat mechanism-specific details in an abstract manner. > You need to deal with security issues: does your protocol require > integrity? Is protection against active attacks important? What are > the names of the endpoints of the connection? However you don't have > to deal with details like how do I find that KDC or what is the > information that the latest rev of example.com's proprietary > authentication token requires? Note that this detail hiding is for > protocol designers, not for implementers. It is possible to hide > mechanism implementation details from protocol implementations but > doing so requires a lot more work. For successful examples of this > take a look at Windows SSPI or Cyrus SASL. (Windows is much more > successful than Cyrus.) > > Another example of successfully using a framework to hide both > implementation and protocol details is SAP R3. R3 uses GSS-API for > its security services. The application successfully uses a wide > variety of mechanisms not available to SAP. SAP provides a GSS > conformance test; mechanisms that pass this test are likely to work. > > Frameworks are interesting to security > designers because they can get support for their mechanism in multiple > protocols by writing one specification. Having worked with Kerberos > for 10 years, I can say that it is much easier to get support into > frameworks than to write specifications for each protocol you might > care about. > > > Section 11.1: Another solution to downgrade attacks is to cache state > about the endpoint. If an endpoint has previously offered a digest > mechanism but now only offers plaintext passwords, then this indicates > a problem. > > Another solution is to only offer mechanisms that cannot protect the > negotiation over TLS or other channels where the server is > authenticated. > > > Section 11.2: The reason that you see similar mechanisms for things > like otp, secureid, etc is that you have deployed infrastructure. > Telling me to use digest when I have OTP credentials deployed > everywhere is just not a reasonable option. > Also, note that many of these mechanisms are not standards track. > > I strongly disagree with the following sentence because I believe it > leads to protocols that cannot be deployed: >> While the desire to support legacy authentication systems is under- >> standable, it should be resisted to the extent possible. > Also, I question the term legacy in this instance. > > Section 11.3: I believe almost all the specific examples are wrong > here and so I question the general principle. > > I believe there is a strong consensus in the Kerberos community that > GSSAPI should be used in preference to raw Kerberos where possible. > The krb-priv and krb_safe messages in RFC 4120 are documented mostly > for legacy reasons. There is significantly less implementation of > these messages than RFC 4121 and RFC 1964. There are significant > interoperability problems with krb_safe. So, where the GSS-API > Kerberos mechanism is appropriate, it should be used. Using RFC 4121 > is not less efficient than using raw kerberos. Often it decreases > application and protocol design complexity and increases application > portability. > > I see no evidence that GSS-API has increased deployment complexity > over raw Kerberos. Note that the SASL Kerberos mechanisms are not on > standards track. I don't think that the IETF would support > publication of a kerberos_v5 mechanism as a standards track mechanism > because of the existing gssapi mechanism. > > > > Similarly, SASL and GSS work quite well together. GSS is more > flexible in what applications it supports: it supports datagram > applications and applications for which tokens can be re-ordered. > However SASL fills in a lot of details that will be static for > client-server applications with single TCP connections. Also, > SASL+GSS ends up being easier to integrate into protocol > specifications than GSS. This is basically because GSS is more > flexible. The strategy of designing GSS mechanisms but designing SASL > applications works quite well. It is a bit harder than designing SASL > mechanisms because GSS requires mechanism designers to think more > about naming and handling of out-of-order packets than SASL. I have > not heard significant claims that GSS over SASL is harder to deploy or > implement than raw SASL. In fact there is evidence such as GNU's > mailtools or Eudora's GSS support that suggests the opposite. > > > Claiming that EAP TLS is a bad idea goes against a recent IETF > consensus to move it onto the standards track. EAP TLS is explicitly > a work item of EMU. > > The current text implies that in order to avoid layering new PPP > authentication methods should not use EAP. I believe that goes > against a strong internet area consensus and against IETF consensus. > > I disagree with the following text: >> In accordance with the principle of having as few mechanisms as >> pos- sible, frameworks should avoid mechanisms that are themselves >> frame- >> works, in favor of using the second framework's mechanisms >> directly. >> "We'll build ours on top of theirs" is a bad policy. > > I think a better approach is that there should only be one generally > accepted path to a particular mechanism. I.E. There should be one > way of doing Kerberos in SASL; it should be easy to find out what that > is. There is not a good reason it needs to be Kerberos directly on > top of SASL. Letting the framework communities design requirements > for this is more appropriate than the IAB legislating requirements. > Another requirement might be that if you are going to add a new > mechanism it should be clear which layer you add it at. > > Section 11 is missing a discussion of the multi-layer negotiation > problem. There is a significant possibility of downgrade attack or > selection of the wrong mechanism if you use negotiations at multiple > layers. This is why the SASL GSS mechanism recommends against use of > the GSSAPI negotiation. Similarly this is why > draft-ietf-secsh-gss-kex forbids the GSS negotiation mechanism. > > Section 11.4: > > You are missing Ssh and TLS as frameworks. I can see an argument that > TLS is not a framework, but ssh clearly has two authentication > frameworks: the key exchange mechanism and the userauth mechanisms. > > > Section 13.2. > I think I've outline why this argument does not lead to reasonable > results previously. > > I would hold a discuss on a document that followed the advice in > section 13.2 and limited the mechanisms that could be used from a > generic framework to a specific set. It is fine to limit to > mechanisms that meet certain requirements such as providing > confidentiality or providing protection against active attacks. It is > fine to have a mandatory to implement set of mechanisms. In the case > of SASL I would argue it goes against the architecture to have > mechanism-specific information such as specific mechanism restrictions > in a protocol. In the case of GSS, the argument would be weaker. > Such restrictions tend to lead to mechanism-specific details making > their way into protocols. That layering violation makes it harder to > revise mechanisms in the future or to change the set of appropriate > mechanisms. Our experience has demonstrated that we are likely to > need to change the set of mechanisms over time. > > Section 13.3 I think this advice needs to be constrained. As a > deployment reality simple passwords are often a requirement. I think > the best we can do is avoid simple passwords over unauthenticated > channels. If we are going to avoid simple passwords, why do we > explicitly charter new work like EMU's password mechanism? > > > Section 13.4: > > Please warn people before recommending they just use IPsec to protect > their channel. We've had significant trouble with doing this in the > past. The OSPF authentication draft; L2TP's IPsec support; Iscsi's > IPsec support; IPsec for L*VPN have all been challenging. Please at > least include a pointer to draft-bellovin-use-ipsec (presumably > informative so it does not block your document) and mention that many > details need to be worked through and that IPsec is difficult to use > for application security. > > --Sam > > From pbaker@verisign.com Tue Apr 11 23:29:05 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3C3T5vR030885 for ; Tue, 11 Apr 2006 23:29:05 -0400 Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k3C3SxU2023445; Tue, 11 Apr 2006 23:28:59 -0400 (EDT) Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by robin.verisign.com (8.13.6/8.13.4) with ESMTP id k3C3StAZ004568; Tue, 11 Apr 2006 20:28:55 -0700 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Apr 2006 20:28:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 11 Apr 2006 20:28:54 -0700 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0120_01C65DBF.B2A6F260" Message-ID: <198A730C2044DE4A96749D13E167AD37A4973C@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [saag] Frameworks, multiple mechanisms and draft-iab-auth-mech-05.txt Thread-Index: AcZY/NsYXtt+B+UaRdaFIcjpud6ZJQE4r6Jw From: "Hallam-Baker, Phillip" To: "EKR" , "Nicolas Williams" X-OriginalArrivalTime: 12 Apr 2006 03:28:54.0927 (UTC) FILETIME=[3A0811F0:01C65DE1] X-Spam-Score: -2.465 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Sam Hartman , iab@ietf.org Subject: Re: [saag] Frameworks, multiple mechanisms and draft-iab-auth-mech-05.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2006 03:29:05 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0120_01C65DBF.B2A6F260 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > Behalf Of Eric Rescorla > What I'm talking about is design decisions that were bad from > day one and still are bad. The fact that they happen to be > widely used doesn't make them any less bad. Case in point > (though not strictly relevant to this document): WEP. WEP has two distinct sets of design flaws. The minor flaws hide the catastrophic flaw. The bungled crypto does not concern me very much. Bungled crypto gets fixed. What worries me far more is that six years later there is still no standard encryption mechanism for WiFi that is easy to use. Fixing crypto is important, but I have no security concerns running WEP when 60% of the nearby networks have no encryption at all. It was a good idea to fix WEP but not at the cost of ignoring the catastrophic usability failure for so long. I now have a WiFi access point that is in theory capable of simple configuration, but only if I use the same vendor's access cards. I can also configure it to use somewhat simpler to administer schemes than WEP but only if I switch the entire network at the same time (and I have a lot of machines). The point I want to make here is that the option to use sixteen different algorithms to secure a password auth scheme does me no good if I end up stuck with the configuration. Too much of what has been done seems to be multiplexing layers designed to allow everyone the opportunity to deploy their own pet algorithm. ------=_NextPart_000_0120_01C65DBF.B2A6F260 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUBDCCAoAw ggHpoAMCAQICEQCyNFw02+JxK/SJPVrL0W7rMA0GCSqGSIb3DQEBBAUAMFExCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UE AxMISVBTZWMgQ0EwHhcNOTkxMDIxMDAwMDAwWhcNMDkxMDIxMjM1OTU5WjBRMQswCQYDVQQGEwJV UzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xFjAUBgNVBAsTDUNvcnBvcmF0ZSBJU0cxETAPBgNV BAMTCElQU2VjIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8hbpukYQ9ZzsnCGcBfV9V 0S6dL6DmQTly99jiGKylKnrR6r+9IYn3p7paKD4hc5q7CuXwvkKGYKYewqmjjEE3ncwEt+Lb7d6T Rzw9q1Lktnerh+ZLZmmg66hqoJ0gvEufbhSZcaFfd+GOAwcc4gi9gms0QxRxT5iSt0GoqFaSRQID AQABo1gwVjAjBgNVHREEHDAapBgwFjEUMBIGA1UEAxMLT25zaXRlMi0xNDUwEQYJYIZIAYb4QgEB BAQDAgEGMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHid MZBUanCQ/uLOqKJkBYzqExOzrWw7hThsnrwLdkJMFIToG6zQCXF1kDhD5Dkvs62P/oDQaTz0THy7 D7L8pVmH5aXDIUQ6+0IiE5WTF8W1wy7sxXtRVtjaA5K0Ks3H/jYOTCcONZ23RKW+yzMWAUKI5neh leC1aZpra1xeCQv4MIIC6jCCAlOgAwIBAgIQbsSmTwagoePcKLXY2aPQwDANBgkqhkiG9w0BAQQF ADBRMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xFjAUBgNVBAsTDUNvcnBv cmF0ZSBJU0cxETAPBgNVBAMTCElQU2VjIENBMB4XDTA2MDExMTAwMDAwMFoXDTA3MDExMTIzNTk1 OVoweDEXMBUGA1UEChQOVmVyaVNpZ24sIEluYy4xGzAZBgNVBAsUElJlbW90ZSBBY2Nlc3MgVXNl cjEcMBoGA1UEAxMTUGhpbGlwIEhhbGxhbS1CYWtlcjEiMCAGCSqGSIb3DQEJARYTcGJha2VyQHZl cmlzaWduLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAzxhnkx3bovN4ayxbfh7jSdUX Zwu9vXe0jbEPJf6qQL1picRE3Z6Uf3WTCrIXtxq0fA3l1unByt3Ej2N4oqLPb+oUAWK8P+pHoom1 huJpEcKayU9aj+C5tj6/dytjRTvKmJTY2YK/gc8VKcCxIkk/W/YuScRFIlx5B5c5l/JlKVsCAwEA AaOBmzCBmDAJBgNVHRMEAjAAMAsGA1UdDwQEAwIFoDARBglghkgBhvhCAQEEBAMCB4AwWAYDVR0f BFEwTzBNoEugSYZHaHR0cDovL29uc2l0ZWNybC52ZXJpc2lnbi5jb20vVmVyaVNpZ25JbmNSZW1v dGVBY2Nlc3NVc2VyL0xhdGVzdENSTC5jcmwwEQYKYIZIAYb4RQEGCQQDAQH/MA0GCSqGSIb3DQEB BAUAA4GBAEbtIeGVxE1YBPgVjOy17U8r2oyX7XBSC7XmFPcZ3jVYivlHVGzBQIenSqo7xS9TxHDY rCxxTcMtx3j/knFVqpcQMGH38Aem+IuwQJAcCnTtnu8bP/IFnDh5+vnvPXF36ZI+qC9TUFttBPrF Bpc9CkvSPesoZKSfngGidzJUUK0LMIIDAzCCAmwCEQC5L2DMiJ+hekYJuFtwbIqvMA0GCSqGSIb3 DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xPDA6BgNVBAsT M0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMjE6MDgG A1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw05ODA1MTgwMDAwMDBaFw0yODA4MDEy MzU5NTlaMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xPDA6BgNVBAsT M0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMjE6MDgG A1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAp4gBIXQs5xoD8JjhlzwPIQjxnNuX6Zr8wgQGE75fUsjMHiwSViy4AWkszJkfrbCWrnkE8hM5 wXuYuggs6MKEEyyqaekJ9MepAqRCwiNPStjwDqL7MWzJ5m+ZJwf15vRMeJ5t60aG+rmGyVTyssSv 1EYcWskVMP8NbPUtDm3Of3cCAwEAATANBgkqhkiG9w0BAQUFAAOBgQByLvl/0fFx+8Se9sVeUYpA mLho+Jscg9jinb3/7aHmZuovCfTK1+qlK5X2JGCGTUQug6XELaDTrnhpb3LabK4I8GOSN+a7xDAX rXfMSTWqz9iP0b63GJZHc2pUIjRkLbYWm1lbtFFZOrMLFPQS32eg9K0yZF6xRnInjBJ7xUS0rjCC A6YwggMPoAMCAQICEHWNgosXAgaqes2nmr0jsCgwDQYJKoZIhvcNAQEFBQAwgcExCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE8MDoGA1UECxMzQ2xhc3MgMiBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEcyMTowOAYDVQQLEzEoYykgMTk5OCBWZXJp U2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyNDIzNTk1OVowga0xFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQL E0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBh LWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z56fy5WXixVcBTWLHP bxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiKQNKaiRMpqbbV26d+ 4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCBrTARBglghkgBhvhC AQEEBAMCAQYwDwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgB hvhFAQcXAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDQGA1Ud HwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzIuY3JsMA0GCSqGSIb3 DQEBBQUAA4GBAFJetpXbb3ymfgX2VIU72RqKRVlffMJl7vlA3lRux5ASgCQ8QKNj7IUf9R4bico9 juNLLt+cG+6O51S5VpP+29HERPjLnECdkqzFzgTxEUbsiLyYyIwhfTeczGu9NKWTjL2cOR3qp5wa zfVHbSxzE2NqIS5afYd9vEy+8scDwoy2MIIDwDCCAymgAwIBAgIQSsgAA2Nh1BUDFvGGNpu3zTAN BgkqhkiG9w0BAQUFADCBrTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJjAkBgNVBAMTHVZlcmlTaWduIENs YXNzIDIgUGVyc29ubmVsIENBMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyMzIzNTk1OVowgawxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkw RwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5j b20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBMIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDAitGHYaLqMANVawg28Jf6GlQ1JB/ofZ3Iw3PT2Eb1 kS3ZOO2U17Amcyrel1BN/yIcvXAAmAxYKrGkco+lufctfGDjtd/pfU4hIWHV/DtUyaQJnLsi+aK6 cGFPhkai/QVk7Ao/plh2V7sWc0R88KUNl8BspvFjCCWxBBeVoI3+fwIDAQABo4HfMIHcMCkGA1Ud EQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTExODARBglghkgBhvhCAQEEBAMCAQYw DwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAjAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDgGA1UdHwQxMC8wLaAr oCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNybDANBgkqhkiG9w0BAQUF AAOBgQA2GP0zYNYX0wS12FRfUhrlkggo9KJA2sNbjBqGl++uohX+bMTOL8gByjO+8nlYM5eXkkVw Wk4oHd33wYhOG4dXAj2TJdl+TnI1iUkXs7l3L20O+aSIJcHOdnNlaQWTd+f9k5YYOE1YbHqd6NKb 6NDbif1JwnUEA5el1JaB2CNB8DCCBBkwggOCoAMCAQICEF052qAxsWldLlk3EVCNpLEwDQYJKoZI hvcNAQEEBQAwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAy IEVtcGxveWVlIENBMB4XDTA1MDgxMDAwMDAwMFoXDTA2MDgxMDIzNTk1OVowbTERMA8GA1UEChMI VkVSSVNJR04xCzAJBgNVBAsTAkhRMRMwEQYDVQQDEwpSZWNpcGllbnRzMTYwNAYDVQQDEy1wYmFr ZXIgKEhhbGxhbS1CYWtlciBQaGlsbGlwLCBWZXJpU2lnbiwgSW5jLikwgZ8wDQYJKoZIhvcNAQEB BQADgY0AMIGJAoGBANQT8A2wsm52VpfNoc/FbBi07LKq8Q8ztSvZkocF+JRtdAbMtHn3PnO/UGqF Q1Td0has2t+XiV2xVax+/qEuAat5b20pRHj32whM/XcmMco7CHFH+TseTwChwJGt9fAVKjAGWRJq di8EISDmrRmxO3vbtIKNtzL10YHha+MRpPMbAgMBAAGjggF4MIIBdDAJBgNVHRMEAjAAMFkGA1Ud HwRSMFAwTqBMoEqGSGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL1ZlcmlTaWduSW5jRXhj aGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMLmNybDALBgNVHQ8EBAMCBaAwHgYDVR0RBBcwFYETcGJh a2VyQHZlcmlzaWduLmNvbTCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlT aWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIu IGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMB0GA1UdJQQWMBQGCCsGAQUF BwMEBggrBgEFBQcDAjANBgkqhkiG9w0BAQQFAAOBgQCrTQbYFsByl4BpUeoDHIAeqhBlPPPG/NcU uz0Edr7Eyv729E53LMbjHB8IUfHp4fN7fKD+NwS6uPMszKuczAhXMfG/YmBm/aod+VebYCw4TODA HE8c2E8AboGqFq6XVIRXjTvIFG6hZi4z4I9PN/emwSjlMe73wBeyBctUJ7O3YDGCAyAwggMcAgEB MIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBs b3llZSBDQQIQXTnaoDGxaV0uWTcRUI2ksTAJBgUrDgMCGgUAoIIBtDAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjA0MTIwMzI4NTRaMCMGCSqGSIb3DQEJBDEWBBQu crI+yE/nBvOHpjfDLV5tSFYGvzBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMAcGBSsOAwIa MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAK BggqhkiG9w0CBTB0BgkrBgEEAYI3EAQxZzBlMFExCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UEAxMISVBTZWMgQ0ECEG7E pk8GoKHj3Ci12Nmj0MAwdgYLKoZIhvcNAQkQAgsxZ6BlMFExCzAJBgNVBAYTAlVTMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UEAxMISVBTZWMg Q0ECEG7Epk8GoKHj3Ci12Nmj0MAwDQYJKoZIhvcNAQEBBQAEgYAlZ4T1PW7stwefSvKQMSVaW3Pt 0hFLNkxJ7zlogZixWLU91UPg+w5IlKw7v+5ZbyxVgWCxXtKLOCLxrbvcMls5VIIuvfA7cV1WAobL WEgamTROFCQNt8/Ogquaqu44nNv7QyOZyiq0hLMgvsg8238yunnoW56HgSpkJ4lbD/W8sAAAAAAA AA== ------=_NextPart_000_0120_01C65DBF.B2A6F260-- From pbaker@verisign.com Tue Apr 11 23:46:25 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3C3kPfK000630 for ; Tue, 11 Apr 2006 23:46:25 -0400 Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k3C3f6tZ007788; Tue, 11 Apr 2006 23:41:07 -0400 (EDT) Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by robin.verisign.com (8.13.6/8.13.4) with ESMTP id k3C3euJS005465; Tue, 11 Apr 2006 20:40:56 -0700 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Apr 2006 20:40:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 11 Apr 2006 20:40:56 -0700 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0125_01C65DC0.A7F03880" Message-ID: <198A730C2044DE4A96749D13E167AD37A4973D@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [saag] Frameworks, multiple mechanisms and draft-iab-auth-mech-05.txt Thread-Index: AcZcoqydHhjaimJdQMm/U8poNAHbxwBPt7aQ From: "Hallam-Baker, Phillip" To: "Peter Gutmann" , X-OriginalArrivalTime: 12 Apr 2006 03:40:56.0582 (UTC) FILETIME=[E82BE260:01C65DE2] X-Spam-Score: -2.465 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, hartmans-ietf@mit.edu, iab@ietf.org, nicolas.williams@sun.com Subject: Re: [saag] Frameworks, multiple mechanisms and draft-iab-auth-mech-05.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2006 03:46:25 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0125_01C65DC0.A7F03880 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > Behalf Of Peter Gutmann > I've queried the > people who set this strange policy on a number of occasions > and from my extremely non-rigorous checking it seems to be > based on some voodoo belief that using public keys instead > of passwords automatically makes the authentication > mechanism secure. The first time I ran into it I thought it > was just one sysadmin with funny ideas, but I've run into it > again and again since then). This scheme can be secure if it has the benefit of operating system support. For example on Windows private keys are stored 'securely' in the registry, access is cryptographically gated on the login credentials. At some point there is going to have to be some sort of effort to convince the UNIX community that there is a bit more to modern security practice than having successfully scrubbed the code of buffer overrun bugs. ------=_NextPart_000_0125_01C65DC0.A7F03880 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUBDCCAoAw ggHpoAMCAQICEQCyNFw02+JxK/SJPVrL0W7rMA0GCSqGSIb3DQEBBAUAMFExCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UE AxMISVBTZWMgQ0EwHhcNOTkxMDIxMDAwMDAwWhcNMDkxMDIxMjM1OTU5WjBRMQswCQYDVQQGEwJV UzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xFjAUBgNVBAsTDUNvcnBvcmF0ZSBJU0cxETAPBgNV BAMTCElQU2VjIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8hbpukYQ9ZzsnCGcBfV9V 0S6dL6DmQTly99jiGKylKnrR6r+9IYn3p7paKD4hc5q7CuXwvkKGYKYewqmjjEE3ncwEt+Lb7d6T Rzw9q1Lktnerh+ZLZmmg66hqoJ0gvEufbhSZcaFfd+GOAwcc4gi9gms0QxRxT5iSt0GoqFaSRQID AQABo1gwVjAjBgNVHREEHDAapBgwFjEUMBIGA1UEAxMLT25zaXRlMi0xNDUwEQYJYIZIAYb4QgEB BAQDAgEGMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHid MZBUanCQ/uLOqKJkBYzqExOzrWw7hThsnrwLdkJMFIToG6zQCXF1kDhD5Dkvs62P/oDQaTz0THy7 D7L8pVmH5aXDIUQ6+0IiE5WTF8W1wy7sxXtRVtjaA5K0Ks3H/jYOTCcONZ23RKW+yzMWAUKI5neh leC1aZpra1xeCQv4MIIC6jCCAlOgAwIBAgIQbsSmTwagoePcKLXY2aPQwDANBgkqhkiG9w0BAQQF ADBRMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xFjAUBgNVBAsTDUNvcnBv cmF0ZSBJU0cxETAPBgNVBAMTCElQU2VjIENBMB4XDTA2MDExMTAwMDAwMFoXDTA3MDExMTIzNTk1 OVoweDEXMBUGA1UEChQOVmVyaVNpZ24sIEluYy4xGzAZBgNVBAsUElJlbW90ZSBBY2Nlc3MgVXNl cjEcMBoGA1UEAxMTUGhpbGlwIEhhbGxhbS1CYWtlcjEiMCAGCSqGSIb3DQEJARYTcGJha2VyQHZl cmlzaWduLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAzxhnkx3bovN4ayxbfh7jSdUX Zwu9vXe0jbEPJf6qQL1picRE3Z6Uf3WTCrIXtxq0fA3l1unByt3Ej2N4oqLPb+oUAWK8P+pHoom1 huJpEcKayU9aj+C5tj6/dytjRTvKmJTY2YK/gc8VKcCxIkk/W/YuScRFIlx5B5c5l/JlKVsCAwEA AaOBmzCBmDAJBgNVHRMEAjAAMAsGA1UdDwQEAwIFoDARBglghkgBhvhCAQEEBAMCB4AwWAYDVR0f BFEwTzBNoEugSYZHaHR0cDovL29uc2l0ZWNybC52ZXJpc2lnbi5jb20vVmVyaVNpZ25JbmNSZW1v dGVBY2Nlc3NVc2VyL0xhdGVzdENSTC5jcmwwEQYKYIZIAYb4RQEGCQQDAQH/MA0GCSqGSIb3DQEB BAUAA4GBAEbtIeGVxE1YBPgVjOy17U8r2oyX7XBSC7XmFPcZ3jVYivlHVGzBQIenSqo7xS9TxHDY rCxxTcMtx3j/knFVqpcQMGH38Aem+IuwQJAcCnTtnu8bP/IFnDh5+vnvPXF36ZI+qC9TUFttBPrF Bpc9CkvSPesoZKSfngGidzJUUK0LMIIDAzCCAmwCEQC5L2DMiJ+hekYJuFtwbIqvMA0GCSqGSIb3 DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xPDA6BgNVBAsT M0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMjE6MDgG A1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw05ODA1MTgwMDAwMDBaFw0yODA4MDEy MzU5NTlaMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xPDA6BgNVBAsT M0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMjE6MDgG A1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAp4gBIXQs5xoD8JjhlzwPIQjxnNuX6Zr8wgQGE75fUsjMHiwSViy4AWkszJkfrbCWrnkE8hM5 wXuYuggs6MKEEyyqaekJ9MepAqRCwiNPStjwDqL7MWzJ5m+ZJwf15vRMeJ5t60aG+rmGyVTyssSv 1EYcWskVMP8NbPUtDm3Of3cCAwEAATANBgkqhkiG9w0BAQUFAAOBgQByLvl/0fFx+8Se9sVeUYpA mLho+Jscg9jinb3/7aHmZuovCfTK1+qlK5X2JGCGTUQug6XELaDTrnhpb3LabK4I8GOSN+a7xDAX rXfMSTWqz9iP0b63GJZHc2pUIjRkLbYWm1lbtFFZOrMLFPQS32eg9K0yZF6xRnInjBJ7xUS0rjCC A6YwggMPoAMCAQICEHWNgosXAgaqes2nmr0jsCgwDQYJKoZIhvcNAQEFBQAwgcExCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE8MDoGA1UECxMzQ2xhc3MgMiBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEcyMTowOAYDVQQLEzEoYykgMTk5OCBWZXJp U2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyNDIzNTk1OVowga0xFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQL E0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBh LWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z56fy5WXixVcBTWLHP bxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiKQNKaiRMpqbbV26d+ 4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCBrTARBglghkgBhvhC AQEEBAMCAQYwDwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgB hvhFAQcXAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDQGA1Ud HwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzIuY3JsMA0GCSqGSIb3 DQEBBQUAA4GBAFJetpXbb3ymfgX2VIU72RqKRVlffMJl7vlA3lRux5ASgCQ8QKNj7IUf9R4bico9 juNLLt+cG+6O51S5VpP+29HERPjLnECdkqzFzgTxEUbsiLyYyIwhfTeczGu9NKWTjL2cOR3qp5wa zfVHbSxzE2NqIS5afYd9vEy+8scDwoy2MIIDwDCCAymgAwIBAgIQSsgAA2Nh1BUDFvGGNpu3zTAN BgkqhkiG9w0BAQUFADCBrTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJjAkBgNVBAMTHVZlcmlTaWduIENs YXNzIDIgUGVyc29ubmVsIENBMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyMzIzNTk1OVowgawxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkw RwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5j b20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBMIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDAitGHYaLqMANVawg28Jf6GlQ1JB/ofZ3Iw3PT2Eb1 kS3ZOO2U17Amcyrel1BN/yIcvXAAmAxYKrGkco+lufctfGDjtd/pfU4hIWHV/DtUyaQJnLsi+aK6 cGFPhkai/QVk7Ao/plh2V7sWc0R88KUNl8BspvFjCCWxBBeVoI3+fwIDAQABo4HfMIHcMCkGA1Ud EQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTExODARBglghkgBhvhCAQEEBAMCAQYw DwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAjAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDgGA1UdHwQxMC8wLaAr oCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNybDANBgkqhkiG9w0BAQUF AAOBgQA2GP0zYNYX0wS12FRfUhrlkggo9KJA2sNbjBqGl++uohX+bMTOL8gByjO+8nlYM5eXkkVw Wk4oHd33wYhOG4dXAj2TJdl+TnI1iUkXs7l3L20O+aSIJcHOdnNlaQWTd+f9k5YYOE1YbHqd6NKb 6NDbif1JwnUEA5el1JaB2CNB8DCCBBkwggOCoAMCAQICEF052qAxsWldLlk3EVCNpLEwDQYJKoZI hvcNAQEEBQAwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAy IEVtcGxveWVlIENBMB4XDTA1MDgxMDAwMDAwMFoXDTA2MDgxMDIzNTk1OVowbTERMA8GA1UEChMI VkVSSVNJR04xCzAJBgNVBAsTAkhRMRMwEQYDVQQDEwpSZWNpcGllbnRzMTYwNAYDVQQDEy1wYmFr ZXIgKEhhbGxhbS1CYWtlciBQaGlsbGlwLCBWZXJpU2lnbiwgSW5jLikwgZ8wDQYJKoZIhvcNAQEB BQADgY0AMIGJAoGBANQT8A2wsm52VpfNoc/FbBi07LKq8Q8ztSvZkocF+JRtdAbMtHn3PnO/UGqF Q1Td0has2t+XiV2xVax+/qEuAat5b20pRHj32whM/XcmMco7CHFH+TseTwChwJGt9fAVKjAGWRJq di8EISDmrRmxO3vbtIKNtzL10YHha+MRpPMbAgMBAAGjggF4MIIBdDAJBgNVHRMEAjAAMFkGA1Ud HwRSMFAwTqBMoEqGSGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL1ZlcmlTaWduSW5jRXhj aGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMLmNybDALBgNVHQ8EBAMCBaAwHgYDVR0RBBcwFYETcGJh a2VyQHZlcmlzaWduLmNvbTCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlT aWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIu IGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMB0GA1UdJQQWMBQGCCsGAQUF BwMEBggrBgEFBQcDAjANBgkqhkiG9w0BAQQFAAOBgQCrTQbYFsByl4BpUeoDHIAeqhBlPPPG/NcU uz0Edr7Eyv729E53LMbjHB8IUfHp4fN7fKD+NwS6uPMszKuczAhXMfG/YmBm/aod+VebYCw4TODA HE8c2E8AboGqFq6XVIRXjTvIFG6hZi4z4I9PN/emwSjlMe73wBeyBctUJ7O3YDGCAyAwggMcAgEB MIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBs b3llZSBDQQIQXTnaoDGxaV0uWTcRUI2ksTAJBgUrDgMCGgUAoIIBtDAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjA0MTIwMzM1NDVaMCMGCSqGSIb3DQEJBDEWBBSN EsNH/yoVvI7BW22uX30fSQGIhzBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMAcGBSsOAwIa MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAK BggqhkiG9w0CBTB0BgkrBgEEAYI3EAQxZzBlMFExCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UEAxMISVBTZWMgQ0ECEG7E pk8GoKHj3Ci12Nmj0MAwdgYLKoZIhvcNAQkQAgsxZ6BlMFExCzAJBgNVBAYTAlVTMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UEAxMISVBTZWMg Q0ECEG7Epk8GoKHj3Ci12Nmj0MAwDQYJKoZIhvcNAQEBBQAEgYBA0f9MGIZenxKXI7MhZwLZ+Ns6 8LVuejv1Vq3n9KOn+KRUdhflPvko0EP8re/YY6wdq+w9yRkxbicni1V0huY4ibtZfpDlsAbA+8z9 cilBuG5S7Cs22sTymN9TTo7e1Dp7a5+sh/d9sQDtLF4w0htJJXJTCD7O2DHMDiWkQv4QFQAAAAAA AA== ------=_NextPart_000_0125_01C65DC0.A7F03880-- From aboba@internaut.com Wed Apr 12 02:14:07 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3C6E7Wn021741 for ; Wed, 12 Apr 2006 02:14:07 -0400 Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k3C6E81x006289 for ; Wed, 12 Apr 2006 02:14:08 -0400 (EDT) Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1FTYcC-0005yn-9o; Wed, 12 Apr 2006 02:14:08 -0400 Received: by internaut.com (Postfix, from userid 1000) id 5FEAF497AD; Tue, 11 Apr 2006 23:14:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id 522A1497AC; Tue, 11 Apr 2006 23:14:07 -0700 (PDT) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Tue, 11 Apr 2006 23:14:07 -0700 (PDT) From: Bernard Aboba To: "Hallam-Baker, Phillip" In-Reply-To: <198A730C2044DE4A96749D13E167AD37A4973C@MOU1WNEXMB04.vcorp.ad.vrsn.com> Message-ID: References: <198A730C2044DE4A96749D13E167AD37A4973C@MOU1WNEXMB04.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: -2.464 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, iab@ietf.org Subject: Re: [saag] Frameworks, multiple mechanisms and draft-iab-auth-mech-05.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2006 06:14:07 -0000 > The bungled crypto does not concern me very much. Bungled crypto gets fixed. > What worries me far more is that six years later there is still no standard > encryption mechanism for WiFi that is easy to use. I think you mean to say that there is no mandatory-to-implement authentication algorithm other than Pre-shared key (PSK). WPA2 does standardize two encryption transforms, TKIP and AES CCMP. > It was a good idea to fix WEP but not at the cost of ignoring the > catastrophic usability failure for so long. >From a usability point of view, WEP w/PSK is not much different from WPA2 PSK (or IKEv2 PSK, for that matter), although the security of WPA2 PSK is of course much better. > I now have a WiFi access point that is in theory capable of simple > configuration, but only if I use the same vendor's access cards. The WFA has agreed on a "Simple Config" standard that is not yet widely implemented. This is basically a PSK enrollment mechanism. > I can also configure it to use somewhat simpler to administer schemes > than WEP but only if I switch the entire network at the same time (and I > have a lot of machines). In practice 802.11 security transitions require implemention of "virtual APs" so that multiple configurations can be offered during the transition period. However, "virtual APs" are a relatively recent development and this capability is typically only available within enterprise-class devices. > The point I want to make here is that the option to use sixteen different > algorithms to secure a password auth scheme does me no good if I end up > stuck with the configuration. The configuration problem with WPA2 enterprise is different in character from the one you describe with WPA2 PSK. Here the issue is configuring the method settings rather than the PSK. While there are tools available to administrators for pushing down these kind of configuration settings, the issue is one of heterogeneity -- since configuration differs based on the EAP peer implementation, which is often specific to the chipset vendor. > Too much of what has been done seems to be > multiplexing layers designed to allow everyone the opportunity to deploy > their own pet algorithm. 802.11 is an example of what happens when a security standard does not include a mandatory-to-implement algorithm. The result has been excessive diversity within popular algorithm classes (e.g. 3 tunneled methods utilizing peer passwords + server certs, 3+ password-only algorithms, etc.) At the same time however, there is quite a bit of legitimate diversity in evidence, enough to justify the framework approach. For example, token cards (e.g. EAP-GTC, EAP-RSA) and smartcards (EAP-TLS) have garnered non-negligible market share. If we were to generalize from this experience, one might offer the following advice: a. Frameworks can be helpful, BUT b. A secure mandatory-to-implement algorithm is REQUIRED c. Support for a standarized password-based mechanism is RECOMMENDED From nw141292@binky.Central.Sun.COM Wed Apr 12 02:43:33 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3C6hWnm025886 for ; Wed, 12 Apr 2006 02:43:32 -0400 Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k3C6hTLN006121 for ; Wed, 12 Apr 2006 02:43:29 -0400 (EDT) Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k3C6hS3d016902 for ; Wed, 12 Apr 2006 00:43:29 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k3C6hRde001415 for ; Wed, 12 Apr 2006 00:43:28 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k3C6hRMY019036; Wed, 12 Apr 2006 01:43:27 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k3C6hP1N019035; Wed, 12 Apr 2006 01:43:25 -0500 (CDT) Date: Wed, 12 Apr 2006 01:43:25 -0500 From: Nicolas Williams To: Bernard Aboba Message-ID: <20060412064325.GQ15197@binky.Central.Sun.COM> References: <198A730C2044DE4A96749D13E167AD37A4973C@MOU1WNEXMB04.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, iab@ietf.org, "Hallam-Baker, Phillip" Subject: Re: [saag] Frameworks, multiple mechanisms and draft-iab-auth-mech-05.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2006 06:43:33 -0000 On Tue, Apr 11, 2006 at 11:14:07PM -0700, Bernard Aboba wrote: > If we were to generalize from this experience, one might offer the > following advice: > > a. Frameworks can be helpful, BUT > b. A secure mandatory-to-implement algorithm is REQUIRED Oh, I agree about (b), but I would go farther on (a). Keep in mind that a single ideal mechanism that extensibly supported multiple credential types would still be a framework involving negotiation and that we're not near to settling on a single ideal credential type. IOW, I believe we NEED frameworks. > c. Support for a standarized password-based mechanism is RECOMMENDED (c) is something that I think will be context dependent. We may need to recommend multiple mechanisms. Nico -- From pbaker@verisign.com Wed Apr 12 09:38:04 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3CDc4tk022547 for ; Wed, 12 Apr 2006 09:38:04 -0400 Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k3CDbxvH000970 for ; Wed, 12 Apr 2006 09:37:59 -0400 (EDT) Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by robin.verisign.com (8.13.6/8.13.4) with ESMTP id k3CDbtK2024982; Wed, 12 Apr 2006 06:37:55 -0700 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Apr 2006 06:37:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 12 Apr 2006 06:37:55 -0700 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0146_01C65E13.10324F80" Message-ID: <198A730C2044DE4A96749D13E167AD37A49752@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [saag] Frameworks, multiple mechanisms and draft-iab-auth-mech-05.txt Thread-Index: AcZd+FFLkAMAmgD8SDSBuKC7+NtD7AAOthyA From: "Hallam-Baker, Phillip" To: "Bernard Aboba" X-OriginalArrivalTime: 12 Apr 2006 13:37:55.0492 (UTC) FILETIME=[4DE7CE40:01C65E36] X-Spam-Score: -0.001 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, iab@ietf.org Subject: Re: [saag] Frameworks, multiple mechanisms and draft-iab-auth-mech-05.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2006 13:38:04 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0146_01C65E13.10324F80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > From: Bernard Aboba [mailto:aboba@internaut.com] > > The bungled crypto does not concern me very much. Bungled > crypto gets fixed. > > What worries me far more is that six years later there is still no > > standard encryption mechanism for WiFi that is easy to use. > > I think you mean to say that there is no > mandatory-to-implement authentication algorithm other than > Pre-shared key (PSK). WPA2 does standardize two encryption > transforms, TKIP and AES CCMP. This is diving too far down into the machinery which is my point. It is quite likely that my current hardware is capable of doing all this stuff. But the instructions provided with the consumer devices assume that the consumer doesn't understand any of this stuff so they provide absolutely no information whatsoever. Meanwhile one well known O/S manufacturer provides a lesson in how not to do security usability. To connect to a WEP encrypted access point I have to type in a 26 character hex key TWICE into a password form. Once is bad enough, but twice is utterly unnecessary, it should be possible to check the passkey against the access point. My point is that unless usability is considered an upfront requirement that is at least as important as getting the crypto right the result will be unacceptable. ------=_NextPart_000_0146_01C65E13.10324F80 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUBDCCAoAw ggHpoAMCAQICEQCyNFw02+JxK/SJPVrL0W7rMA0GCSqGSIb3DQEBBAUAMFExCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UE AxMISVBTZWMgQ0EwHhcNOTkxMDIxMDAwMDAwWhcNMDkxMDIxMjM1OTU5WjBRMQswCQYDVQQGEwJV UzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xFjAUBgNVBAsTDUNvcnBvcmF0ZSBJU0cxETAPBgNV BAMTCElQU2VjIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8hbpukYQ9ZzsnCGcBfV9V 0S6dL6DmQTly99jiGKylKnrR6r+9IYn3p7paKD4hc5q7CuXwvkKGYKYewqmjjEE3ncwEt+Lb7d6T Rzw9q1Lktnerh+ZLZmmg66hqoJ0gvEufbhSZcaFfd+GOAwcc4gi9gms0QxRxT5iSt0GoqFaSRQID AQABo1gwVjAjBgNVHREEHDAapBgwFjEUMBIGA1UEAxMLT25zaXRlMi0xNDUwEQYJYIZIAYb4QgEB BAQDAgEGMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHid MZBUanCQ/uLOqKJkBYzqExOzrWw7hThsnrwLdkJMFIToG6zQCXF1kDhD5Dkvs62P/oDQaTz0THy7 D7L8pVmH5aXDIUQ6+0IiE5WTF8W1wy7sxXtRVtjaA5K0Ks3H/jYOTCcONZ23RKW+yzMWAUKI5neh leC1aZpra1xeCQv4MIIC6jCCAlOgAwIBAgIQbsSmTwagoePcKLXY2aPQwDANBgkqhkiG9w0BAQQF ADBRMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xFjAUBgNVBAsTDUNvcnBv cmF0ZSBJU0cxETAPBgNVBAMTCElQU2VjIENBMB4XDTA2MDExMTAwMDAwMFoXDTA3MDExMTIzNTk1 OVoweDEXMBUGA1UEChQOVmVyaVNpZ24sIEluYy4xGzAZBgNVBAsUElJlbW90ZSBBY2Nlc3MgVXNl cjEcMBoGA1UEAxMTUGhpbGlwIEhhbGxhbS1CYWtlcjEiMCAGCSqGSIb3DQEJARYTcGJha2VyQHZl cmlzaWduLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAzxhnkx3bovN4ayxbfh7jSdUX Zwu9vXe0jbEPJf6qQL1picRE3Z6Uf3WTCrIXtxq0fA3l1unByt3Ej2N4oqLPb+oUAWK8P+pHoom1 huJpEcKayU9aj+C5tj6/dytjRTvKmJTY2YK/gc8VKcCxIkk/W/YuScRFIlx5B5c5l/JlKVsCAwEA AaOBmzCBmDAJBgNVHRMEAjAAMAsGA1UdDwQEAwIFoDARBglghkgBhvhCAQEEBAMCB4AwWAYDVR0f BFEwTzBNoEugSYZHaHR0cDovL29uc2l0ZWNybC52ZXJpc2lnbi5jb20vVmVyaVNpZ25JbmNSZW1v dGVBY2Nlc3NVc2VyL0xhdGVzdENSTC5jcmwwEQYKYIZIAYb4RQEGCQQDAQH/MA0GCSqGSIb3DQEB BAUAA4GBAEbtIeGVxE1YBPgVjOy17U8r2oyX7XBSC7XmFPcZ3jVYivlHVGzBQIenSqo7xS9TxHDY rCxxTcMtx3j/knFVqpcQMGH38Aem+IuwQJAcCnTtnu8bP/IFnDh5+vnvPXF36ZI+qC9TUFttBPrF Bpc9CkvSPesoZKSfngGidzJUUK0LMIIDAzCCAmwCEQC5L2DMiJ+hekYJuFtwbIqvMA0GCSqGSIb3 DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xPDA6BgNVBAsT M0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMjE6MDgG A1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw05ODA1MTgwMDAwMDBaFw0yODA4MDEy MzU5NTlaMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xPDA6BgNVBAsT M0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMjE6MDgG A1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAp4gBIXQs5xoD8JjhlzwPIQjxnNuX6Zr8wgQGE75fUsjMHiwSViy4AWkszJkfrbCWrnkE8hM5 wXuYuggs6MKEEyyqaekJ9MepAqRCwiNPStjwDqL7MWzJ5m+ZJwf15vRMeJ5t60aG+rmGyVTyssSv 1EYcWskVMP8NbPUtDm3Of3cCAwEAATANBgkqhkiG9w0BAQUFAAOBgQByLvl/0fFx+8Se9sVeUYpA mLho+Jscg9jinb3/7aHmZuovCfTK1+qlK5X2JGCGTUQug6XELaDTrnhpb3LabK4I8GOSN+a7xDAX rXfMSTWqz9iP0b63GJZHc2pUIjRkLbYWm1lbtFFZOrMLFPQS32eg9K0yZF6xRnInjBJ7xUS0rjCC A6YwggMPoAMCAQICEHWNgosXAgaqes2nmr0jsCgwDQYJKoZIhvcNAQEFBQAwgcExCzAJBgNVBAYT AlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE8MDoGA1UECxMzQ2xhc3MgMiBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEcyMTowOAYDVQQLEzEoYykgMTk5OCBWZXJp U2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyNDIzNTk1OVowga0xFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQL E0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBh LWtyIChjKTk5MSYwJAYDVQQDEx1WZXJpU2lnbiBDbGFzcyAyIFBlcnNvbm5lbCBDQTCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEApwRsD6Jyt0oGLvjXKSw0nYK8SJFKx6z56fy5WXixVcBTWLHP bxY7wUnVy/RuzOHMy7XHLk6IqjTpttBbfD4VVzThGLz/3fWvZ1kgCuU96oiKQNKaiRMpqbbV26d+ 4ec3JJP9lHRNeuQybUzoXBaXr92S2WaKFGbk6loDqD1f+wsCAwEAAaOBsDCBrTARBglghkgBhvhC AQEEBAMCAQYwDwYDVR0TBAgwBgEB/wIBATALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgB hvhFAQcXAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDQGA1Ud HwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzIuY3JsMA0GCSqGSIb3 DQEBBQUAA4GBAFJetpXbb3ymfgX2VIU72RqKRVlffMJl7vlA3lRux5ASgCQ8QKNj7IUf9R4bico9 juNLLt+cG+6O51S5VpP+29HERPjLnECdkqzFzgTxEUbsiLyYyIwhfTeczGu9NKWTjL2cOR3qp5wa zfVHbSxzE2NqIS5afYd9vEy+8scDwoy2MIIDwDCCAymgAwIBAgIQSsgAA2Nh1BUDFvGGNpu3zTAN BgkqhkiG9w0BAQUFADCBrTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJjAkBgNVBAMTHVZlcmlTaWduIENs YXNzIDIgUGVyc29ubmVsIENBMB4XDTk5MDIyNTAwMDAwMFoXDTA5MDIyMzIzNTk1OVowgawxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkw RwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5j b20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBMIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDAitGHYaLqMANVawg28Jf6GlQ1JB/ofZ3Iw3PT2Eb1 kS3ZOO2U17Amcyrel1BN/yIcvXAAmAxYKrGkco+lufctfGDjtd/pfU4hIWHV/DtUyaQJnLsi+aK6 cGFPhkai/QVk7Ao/plh2V7sWc0R88KUNl8BspvFjCCWxBBeVoI3+fwIDAQABo4HfMIHcMCkGA1Ud EQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTExODARBglghkgBhvhCAQEEBAMCAQYw DwYDVR0TBAgwBgEB/wIBADALBgNVHQ8EBAMCAQYwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXAjAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDgGA1UdHwQxMC8wLaAr oCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNybDANBgkqhkiG9w0BAQUF AAOBgQA2GP0zYNYX0wS12FRfUhrlkggo9KJA2sNbjBqGl++uohX+bMTOL8gByjO+8nlYM5eXkkVw Wk4oHd33wYhOG4dXAj2TJdl+TnI1iUkXs7l3L20O+aSIJcHOdnNlaQWTd+f9k5YYOE1YbHqd6NKb 6NDbif1JwnUEA5el1JaB2CNB8DCCBBkwggOCoAMCAQICEF052qAxsWldLlk3EVCNpLEwDQYJKoZI hvcNAQEEBQAwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAy IEVtcGxveWVlIENBMB4XDTA1MDgxMDAwMDAwMFoXDTA2MDgxMDIzNTk1OVowbTERMA8GA1UEChMI VkVSSVNJR04xCzAJBgNVBAsTAkhRMRMwEQYDVQQDEwpSZWNpcGllbnRzMTYwNAYDVQQDEy1wYmFr ZXIgKEhhbGxhbS1CYWtlciBQaGlsbGlwLCBWZXJpU2lnbiwgSW5jLikwgZ8wDQYJKoZIhvcNAQEB BQADgY0AMIGJAoGBANQT8A2wsm52VpfNoc/FbBi07LKq8Q8ztSvZkocF+JRtdAbMtHn3PnO/UGqF Q1Td0has2t+XiV2xVax+/qEuAat5b20pRHj32whM/XcmMco7CHFH+TseTwChwJGt9fAVKjAGWRJq di8EISDmrRmxO3vbtIKNtzL10YHha+MRpPMbAgMBAAGjggF4MIIBdDAJBgNVHRMEAjAAMFkGA1Ud HwRSMFAwTqBMoEqGSGh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL1ZlcmlTaWduSW5jRXhj aGFuZ2VFbXBsb3llZXMvTGF0ZXN0Q1JMLmNybDALBgNVHQ8EBAMCBaAwHgYDVR0RBBcwFYETcGJh a2VyQHZlcmlzaWduLmNvbTCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlT aWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIu IGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMB0GA1UdJQQWMBQGCCsGAQUF BwMEBggrBgEFBQcDAjANBgkqhkiG9w0BAQQFAAOBgQCrTQbYFsByl4BpUeoDHIAeqhBlPPPG/NcU uz0Edr7Eyv729E53LMbjHB8IUfHp4fN7fKD+NwS6uPMszKuczAhXMfG/YmBm/aod+VebYCw4TODA HE8c2E8AboGqFq6XVIRXjTvIFG6hZi4z4I9PN/emwSjlMe73wBeyBctUJ7O3YDGCAyAwggMcAgEB MIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBs b3llZSBDQQIQXTnaoDGxaV0uWTcRUI2ksTAJBgUrDgMCGgUAoIIBtDAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjA0MTIxMzI1MzlaMCMGCSqGSIb3DQEJBDEWBBRm B0JPzz+M+o+fyG/7Npb6n+HI1DBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMAcGBSsOAwIa MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAK BggqhkiG9w0CBTB0BgkrBgEEAYI3EAQxZzBlMFExCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UEAxMISVBTZWMgQ0ECEG7E pk8GoKHj3Ci12Nmj0MAwdgYLKoZIhvcNAQkQAgsxZ6BlMFExCzAJBgNVBAYTAlVTMRcwFQYDVQQK Ew5WZXJpU2lnbiwgSW5jLjEWMBQGA1UECxMNQ29ycG9yYXRlIElTRzERMA8GA1UEAxMISVBTZWMg Q0ECEG7Epk8GoKHj3Ci12Nmj0MAwDQYJKoZIhvcNAQEBBQAEgYDEICqLsux23ors3JYkyCCGe3Yb rlhGEVzfrwLGE4jjrZ/Udn9noY4K9GmrD694BW5cqgFrLYUMozxTAsUGC8RG2SaWm1MzRGt7dNgx phVkd+tBD2z1To9I/WQkgD2jLUpL7oGJSagSv9a9p0x/5wgIIkS1p2Y1lmrcVwmXYGBOSQAAAAAA AA== ------=_NextPart_000_0146_01C65E13.10324F80-- From pgut001@cs.auckland.ac.nz Wed Apr 12 19:50:41 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3CNofgK021621 for ; Wed, 12 Apr 2006 19:50:41 -0400 Received: from zeppo.itss.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.190.14]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k3CNoSRR009664; Wed, 12 Apr 2006 19:50:29 -0400 (EDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zeppo.itss.auckland.ac.nz (Postfix) with ESMTP id C6001348C7; Thu, 13 Apr 2006 11:50:27 +1200 (NZST) Received: from zeppo.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpd.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09611-08; Thu, 13 Apr 2006 11:50:27 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by zeppo.itss.auckland.ac.nz (Postfix) with ESMTP id 1D4E034462; Thu, 13 Apr 2006 11:50:26 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id E880737762; Thu, 13 Apr 2006 11:50:26 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1FTp6T-0003Ie-00; Thu, 13 Apr 2006 11:50:29 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: jaltman@columbia.edu, pbaker@verisign.com, pgut001@cs.auckland.ac.nz In-Reply-To: <198A730C2044DE4A96749D13E167AD37A4973D@MOU1WNEXMB04.vcorp.ad.vrsn.com> Message-Id: Sender: pgut001 Date: Thu, 13 Apr 2006 11:50:29 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: 0 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, iab@ietf.org, hartmans-ietf@mit.edu, nicolas.williams@sun.com Subject: Re: [saag] Frameworks, multiple mechanisms and draft-iab-auth-mech-05.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2006 23:50:41 -0000 "Hallam-Baker, Phillip" writes: >> Behalf Of Peter Gutmann >> I've queried the >> people who set this strange policy on a number of occasions >> and from my extremely non-rigorous checking it seems to be >> based on some voodoo belief that using public keys instead >> of passwords automatically makes the authentication >> mechanism secure. The first time I ran into it I thought it >> was just one sysadmin with funny ideas, but I've run into it >> again and again since then). > >This scheme can be secure if it has the benefit of operating system support. > >For example on Windows private keys are stored 'securely' in the registry, >access is cryptographically gated on the login credentials. Right, although even then any trojan that gets run on the machine has access to the keys. In this case though they were being stored on multiuser systems shared by dozens or in some cases hundreds of people and running a mishmash of old, unpatched OS versions and applications ("We've got it working, don't touch it any more!"). As if that wasn't bad enough, some of the users had their directories world-read/writeable so their friends could share their files. It really was pure wishful-thinking security on the part of the admins. >At some point there is going to have to be some sort of effort to convince >the UNIX community that there is a bit more to modern security practice than >having successfully scrubbed the code of buffer overrun bugs. Whaddya mean? We're using PKC pixie dust, we're secure now! Peter. From aboba@internaut.com Thu Apr 13 23:56:19 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3E3uJ5D030703 for ; Thu, 13 Apr 2006 23:56:19 -0400 Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k3E3uGqr007713 for ; Thu, 13 Apr 2006 23:56:16 -0400 (EDT) Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1FUFPs-000F4X-5U for saag@mit.edu; Thu, 13 Apr 2006 23:56:16 -0400 Received: by internaut.com (Postfix, from userid 1000) id 890C2497F1; Thu, 13 Apr 2006 20:56:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id 7C57C497F0 for ; Thu, 13 Apr 2006 20:56:15 -0700 (PDT) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Thu, 13 Apr 2006 20:56:15 -0700 (PDT) From: Bernard Aboba To: saag@mit.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: -2.464 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] FYI: EAP WG last call on the EAP Key Management Framework Document X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2006 03:56:19 -0000 FYI, the IETF EAP WG has announced WG last call on the EAP Key Management Framework document: http://lists.frascone.com/pipermail/eap/msg04208.html The WG last call will last until Monday May 1, 2006. Comments should be sent to the EAP WG mailing list (eap@frascone.com) in the format described on the EAP WG issues list: http://www.drizzle.com/~aboba/EAP/eapissues.html From housley@vigilsec.com Wed Apr 19 11:32:13 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3JFWCiM004216 for ; Wed, 19 Apr 2006 11:32:12 -0400 Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by fort-point-station.mit.edu (8.13.6/8.9.2) with SMTP id k3JFW9LP011279 for ; Wed, 19 Apr 2006 11:32:09 -0400 (EDT) Received: (qmail 26822 invoked by uid 0); 19 Apr 2006 15:32:05 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (64.241.37.140) by woodstock.binhost.com with SMTP; 19 Apr 2006 15:32:05 -0000 Message-Id: <7.0.0.16.2.20060419113041.06ace1c0@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Wed, 19 Apr 2006 11:31:57 -0400 To: saag@mit.edu From: Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -0.099 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] Fwd: Public mailing list to discuss OATH specs X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2006 15:32:13 -0000 >Date: Tue, 18 Apr 2006 19:29:20 -0700 >From: "Bajaj, Siddharth" >To: Russ Housley >CC: Stu Vaeth >Subject: Public mailing list to discuss OATH specs > > >Hi Russ, > >I wanted to follow up on one of the items that came out of the IETF >meetings in Dallas. >There was interest in having a public mailing list for the various >OATH specs. So, we >have gone ahead and created one. Anybody can join the list for the >discussion of the >past, current and future OATH specs. > >- HOTP (RFC 4226) >- Mutual OATH (draft-mraihi-mutual-oath-hotp-variants-02) >- Portable Symmetric Key Container >(draft-vassilev-portable-symmetric-key-container-00) >- XKMS Provisioning of OATH keys (draft-hallambaker-oathxkms-00) > >To join the list - > http://www.safehaus.org/mailman/listinfo/oath_ietf > >To post to this list, send your email to: > oath_ietf@safehaus.org > >General information about the mailing list is at: > http://www.safehaus.org/mailman/listinfo/oath_ietf > >You can also make such adjustments via email by sending a message to: > oath_ietf-request@safehaus.org > >Would appreciate if you can forward this message to the appropriate >lists (SAAG?). >Or if you point me to the right lists, I can forward it myself. > >Thanks, >Siddharth From pekkas@netcore.fi Wed Apr 19 13:28:49 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3JHSnDS028059 for ; Wed, 19 Apr 2006 13:28:49 -0400 Received: from netcore.fi (netcore.fi [193.94.160.1]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k3JHSBVw002237 for ; Wed, 19 Apr 2006 13:28:12 -0400 (EDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060308/8.12.11) with ESMTP id k3JHS6t8024409; Wed, 19 Apr 2006 20:28:06 +0300 Date: Wed, 19 Apr 2006 20:28:06 +0300 (EEST) From: Pekka Savola To: saag@mit.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.1/1407/Wed Apr 19 00:01:55 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on otso.netcore.fi X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: rpsec@ietf.org Subject: [saag] Backbone attacks and protections (fwd) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2006 17:28:49 -0000 Hi, As there was some discussion of TCP-MD5 and revisions at the last SAAG meeting, I claimed on jabber that getting a TCP-MD5 replacement is not really such a critical thing, as TCP-MD5 itself has rather limited applicability (and attack vector). I also promised to write an I-D. Well, here's a short I-D which gives an overview of my operator perspective (inputs from a couple of others have been incorporated) of main threats to backbone routers and their routing protocols in particular. Now would be a good time to read and comment, because I'm going to revise the doc in 2-3 weeks. I suggest directing followups to either: 1) rtgwg list (rtgwg@ietf.org) 2) saag list only 3) myself only ---------- Forwarded message ---------- Date: Fri, 31 Mar 2006 23:27:29 +0300 (EEST) From: Pekka Savola To: rtgwg@ietf.org Subject: Backbone attacks and protections (was: TCP-RST and GTSM) Hi, At IETF65, I raised the TCP-RST attack issue in GTSM, and Alex asked that I should talk with DaveM about it, work it out, and produce a draft. Well, I did.. and soon figured out I'll need to write a more generic but concise draft first on what I believe are the main attack vectors against routing protocols running on backbone networks today, so that we can balance the risks. Feedback is appreciated -- read it, it's only about 10 pages. I'll also send a pointer to RPsec and SAAG a bit later, because there has been some discussion on TCP-MD5 replacements there. http://www.ietf.org/internet-drafts/draft-savola-rtgwg-backbone-attacks-00.txt Abstract A number of protection mechanisms for attacks against service provider backbone network infrastructure have been specified or proposed, each of them usually targeting a subset of the problem space. There has never been a more generic analysis of the actual problems, and which protection techniques are even necessary (and where). This document tries to provide that higher-level view. ... Oh, if you're interested, below is what I suggest we do with GTSM (though I'm very much open to discussion about this -- the attack loses most of its usefulness especially if the router already implements the draft-ietf-tcpm-tcpsecure hack..): The open issue at the moment is how GTSM handles TCP RSTs. I.e., should it require that RSTs for a GTSM-enabled session should be sent with TTL=255 and verified to come with TTL=255 (or a configured value)? Do implementations already do this? Is there a sensible transition plan or need to make a change if any? Note that this has only limited impact on GTSM's security as other TCP RST mitigation techniques still apply. We suggest that the GTSM spec is amended that TCP RSTs relating to to a GTSM-enabled protocol port MUST be sent with TTL=255. (Note that this will require a kernel modification, and a means to specify to the kernel which ports relate to GTSM.). The recipients behaviour SHOULD be configurable, and it is RECOMMENDED that the default be to discard messages where TTL is not 255 (or 255-TrustRadius). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg From housley@vigilsec.com Thu Apr 20 09:57:57 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3KDvvhS031431 for ; Thu, 20 Apr 2006 09:57:57 -0400 Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by fort-point-station.mit.edu (8.13.6/8.9.2) with SMTP id k3KDvwrd017156 for ; Thu, 20 Apr 2006 09:57:58 -0400 (EDT) Received: (qmail 28161 invoked by uid 0); 20 Apr 2006 13:57:55 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.246.201.196) by woodstock.binhost.com with SMTP; 20 Apr 2006 13:57:55 -0000 Message-Id: <7.0.0.16.2.20060420095609.06191b18@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Thu, 20 Apr 2006 09:57:55 -0400 To: saag@mit.edu From: Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] Fwd: draft-bonica-tcp-auth X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2006 13:57:58 -0000 We had a presentation at the IETF 65 SAAG session about this document. What should we say to the TCPM folks? Russ >Date: Wed, 19 Apr 2006 13:01:22 -0400 >From: Ron Bonica >To: housley@vigilsec.com, Sam Hartman >Subject: draft-bonica-tcp-auth > > >Russ, Sam, > >Could SAAG send some feedback to TCPM regarding draft-bonica-tcp-auth? >TCPM is waiting for such feedback before deciding whether to adopt the >draft as a WG item. > > Ron From ekr@rtfm.com Thu Apr 20 10:29:19 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3KETJV3005526 for ; Thu, 20 Apr 2006 10:29:19 -0400 Received: from delta.rtfm.com (c-67-161-46-163.hsd1.ca.comcast.net [67.161.46.163]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k3KETLjA006041 for ; Thu, 20 Apr 2006 10:29:21 -0400 (EDT) Received: by delta.rtfm.com (Postfix, from userid 1001) id 1962FB832; Thu, 20 Apr 2006 07:29:21 -0700 (PDT) To: Russ Housley References: <7.0.0.16.2.20060420095609.06191b18@vigilsec.com> From: Eric Rescorla Date: Thu, 20 Apr 2006 07:29:20 -0700 In-Reply-To: <7.0.0.16.2.20060420095609.06191b18@vigilsec.com> (Russ Housley's message of "Thu, 20 Apr 2006 09:57:55 -0400") Message-ID: <863bg8pbgf.fsf@delta.rtfm.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.18 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 6.528 X-Spam-Level: ****** (6.528) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] Fwd: draft-bonica-tcp-auth X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Reply-To: EKR List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2006 14:29:20 -0000 Russ Housley writes: > We had a presentation at the IETF 65 SAAG session about this > document. What should we say to the TCPM folks? I don't have any opinion about what SAAG should say, but as I mentioned in the meeting (and later on in IM with Sam), I have serious concerns about this approach. So, I'll take this as a prod to write them up. -Ekr From kent@bbn.com Thu Apr 20 12:30:11 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3KGUB8E027938 for ; Thu, 20 Apr 2006 12:30:11 -0400 Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k3KGUEoj026648 for ; Thu, 20 Apr 2006 12:30:14 -0400 (EDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.1.38.141]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1FWc2n-0000vP-58; Thu, 20 Apr 2006 12:30:13 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <7.0.0.16.2.20060420095609.06191b18@vigilsec.com> References: <7.0.0.16.2.20060420095609.06191b18@vigilsec.com> Date: Thu, 20 Apr 2006 12:30:11 -0400 To: Russ Housley From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] Fwd: draft-bonica-tcp-auth X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2006 16:30:11 -0000 At 9:57 AM -0400 4/20/06, Russ Housley wrote: >We had a presentation at the IETF 65 SAAG session about this >document. What should we say to the TCPM folks? > >Russ > I have several concerns with the current proposal: 1. Parts of this proposal seem to focus on inter-router communication, specifically in support of BGP, but it should be a clearer re the scope of applicability. Alternatively, is this intended as a generic layer 4 integrity and key management mechanism? I would have a lot of additional concerns if it were proposed in the latter context, rather than as just a replacement for the TCP MD5 checksum option. 2. The notion of time-based key changeover seems a bit complex when one looks at the details. In the BGP border router context there may be substantial clock skew between peers, as an ISP operator noted when this presentation was made in the RPSEC WG. In anticipation of this sort of problem, the proposal allows setting the changeover to the equivalent of "forever," which then defeats the purpose of the mechanism. During the RPSEC WG discussion of the proposal, Ron suggested typical key change intervals might be monthly or semi-monthly, but an ISP operator scoffed at that suggestion, indicating that anything more frequent than an annual change would be too much work. This disparity between the protocol designer's notion of how the system would be managed, and that of a prospective user is worrisome, and relevant to my next concern. 3. On the RPSEC mailing list there was a discussion of whether this sort of replacement for the MD5 option was the right path, or whether IPsec should be used. (ESP with NULL encryption would offer equivalent security functionality for BGP sessions.) After several message exchanges it appears that the primary reason for not using IPsec is that current router IPsec implementations are designed to protect subscriber traffic (with the router acting as a security gateway), and this makes it hard to configure them to protect router management traffic, e.g., BGP sessions. Other concerns about using IPsec centered on the question of how to perform key management, e.g., using certs or PSKs. It was agreed that use of certs would clearly be better, but there are concerns over getting certs issued to routers for inter-AS use. (The PKI work in SIDR might offer a solution to this problem, but it is not a very near term solution.) If one uses PSKs for authentication (via IKE), then its seems appropriate to ask how the two mechanisms compare in operational terms. IKE generates a new key for each SA and transitions traffic from one SA to its re-keyed successor without interruption, achieving the same goal as this proposal. A BGP TCP session protected via IPsec would be disrupted only if the PSK used to authenticate two peers was changed at one peer but not the other AND the SA timed out and needed to be re-keyed while the two ends were not in sync re the PSKs. An SA can have a long lifetime, especially given the relatively low traffic volumes associated with a BGP session, which helps minimize the likelihood that the PSKs are out of sync AND an SA needs to be re-keyed. This is why it is important to ask what is the likely frequency of key change for this purpose. Because PSKs for IKE are not used to protect traffic, unlike the keys in this proposal, they should be changed based primarily on physical, procedural, and personnel security concerns, rather than on cryptanalytic concerns. That may make annual changes seem more reasonable for PSKs than for the keys used for traffic protection in the proposed mechanism. 4. There is a companion I-D that was generated slightly later than the proposal we're discussing (draft-weis-tcp-auth-auto-ks-00.txt). It gets closer to IKE-style key management for the proposed TCP integrity option. I think it should not be treated separately, but rather needs to be considered as part of a unified proposal. Only then can we make a fair comparison between IPsec and this proposal. Steve From ekr@networkresonance.com Thu Apr 20 21:46:02 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3L1k2Dw023703 for ; Thu, 20 Apr 2006 21:46:02 -0400 Received: from raman.networkresonance.com (raman.networkresonance.com [198.144.196.3]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k3L1k5ai029522 for ; Thu, 20 Apr 2006 21:46:05 -0400 (EDT) Received: by raman.networkresonance.com (Postfix, from userid 1001) id 79CA61E8C1F; Thu, 20 Apr 2006 18:46:04 -0700 (PDT) To: Russ Housley References: <7.0.0.16.2.20060420095609.06191b18@vigilsec.com> From: Eric Rescorla Date: Thu, 20 Apr 2006 18:46:04 -0700 In-Reply-To: <7.0.0.16.2.20060420095609.06191b18@vigilsec.com> (Russ Housley's message of "Thu, 20 Apr 2006 09:57:55 -0400") Message-ID: <867j5jzoo3.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] Fwd: draft-bonica-tcp-auth X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Reply-To: EKR List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2006 01:46:02 -0000 Russ Housley writes: > We had a presentation at the IETF 65 SAAG session about this > document. What should we say to the TCPM folks? As I indicated in SAAG, I'm fairly uncomfortable with this whole "64-key" thing. The rationale for multiple keys appears to be: 1. To limit the exposure if a key is compromised. 2. To limit the amount of material protected with a single key in order to prevent cryptanalytic attacks. These are two quite different purposes being bundled into one mechanism. In many other protocols they are separated. For instance, the security of a TLS connection often depends on a long-term RSA key, but the handshake ensures that each connection gets its own set of keys. The temporal limits used in this document are potentially applicable to use (1) but aren't really applicable to use (2) since the issue is the amount of data protected, not the amount of time that has passed. Incidentally, it's worth noting that attacks based on observing large amounts of ciphertext (or in this case protected traffic) are largely inapplicable to modern MAC algorithms. For instance, the CMAC security bound is 2^22 GBytes, or approximately one petabyte of traffic. An additional issue with the use of temporal rather than traffic based keys is that there is actually a reasonable probability that two separate connections with the same host/port quartet will use the same keys. Consider what happens with a connection between A and B where A did the active open. When A restarts, it reinitiates the same connection and there is a reasonable chance that it will use the same local port. If it is connecting to a well-known port on B, then you will have the same quartet. If the sequence numbers are randomly selected (as suggested by RFC 1948) and a lot of data is passed, then there is a reasonable chance of overlap. In my opinion, rather than using static temporal keys like this, it would be better to generate a per-connection key. Even if you want to use static keying, this can be done by simply feeding the static key and random nonces exchanged in the SYN (the ISN may be enough, but better to be safe and use a cookie) into a KDF and using the output as the MAC key. (Better yet, generate directional MAC keys). If you wish to have temporal keys, it's straightforward to pass a key-id in the initial exchange. A mechanism like this ensures unique keys for each connection and also limits the amount of material protected with a given traffic key. If you actually do reach the (very large) limits on key use, it's straightforward to tear down the connection or use a rollover counter which you feed back into the KDF. While we're on the topic of rollover counters, it seems like it might be desirable to include one in the MAC calculation in order to avoid substitution of messages from one pass through the sequence number space with another. -Ekr From ekr@networkresonance.com Thu Apr 20 21:55:29 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3L1tTVc025004 for ; Thu, 20 Apr 2006 21:55:29 -0400 Received: from raman.networkresonance.com (raman.networkresonance.com [198.144.196.3]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k3L1tW3W019302 for ; Thu, 20 Apr 2006 21:55:32 -0400 (EDT) Received: by raman.networkresonance.com (Postfix, from userid 1001) id 892DB1E8C1F; Thu, 20 Apr 2006 18:55:31 -0700 (PDT) To: Russ Housley References: <7.0.0.16.2.20060420095609.06191b18@vigilsec.com> <867j5jzoo3.fsf@raman.networkresonance.com> From: Eric Rescorla Date: Thu, 20 Apr 2006 18:55:31 -0700 In-Reply-To: <867j5jzoo3.fsf@raman.networkresonance.com> (Eric Rescorla's message of "Thu, 20 Apr 2006 18:46:04 -0700") Message-ID: <863bg7zo8c.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] Fwd: draft-bonica-tcp-auth X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Reply-To: EKR List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2006 01:55:29 -0000 Eric Rescorla writes: > instance, the CMAC security bound is 2^22 GBytes, or approximately one > petabyte of traffic. Should read "on the order of one petabyte". I calculate it as 4 PB. -Ekr From hartmans@MIT.EDU Sat Apr 22 13:55:30 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3MHtULg009685 for ; Sat, 22 Apr 2006 13:55:30 -0400 Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k3MHtV83014277 for ; Sat, 22 Apr 2006 13:55:32 -0400 (EDT) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 5F0D6E0004; Sat, 22 Apr 2006 13:55:17 -0400 (EDT) To: Russ Housley , saag@MIT.EDU References: <7.0.0.16.2.20060420095609.06191b18@vigilsec.com> From: Sam Hartman Date: Sat, 22 Apr 2006 13:55:17 -0400 In-Reply-To: (Stephen Kent's message of "Thu, 20 Apr 2006 12:30:11 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 1.352 X-Spam-Level: * (1.352) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: Re: [saag] Fwd: draft-bonica-tcp-auth X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Apr 2006 17:55:30 -0000 Personally, I would prefer something IPsec-based to this approach. I think it is important that we meet the following requirements roughly in this order: 1) Something that provides some form of integrity service 2) Something that ISPs will deploy 3) Something that is easy to use 4) Something that provides strong security guarantees. I realize these are vague and that in order to come to any conclusions we'd need to flesh out these requirements. However what I'm seeing from this is that I think we need to be focusing more on the usability of the solutions and on what the layer 9+ biases of the target deployment community are than on the communications security discussion we're currently falling into. If all else is equal, the current concerns should be addressed. From hartmans@MIT.EDU Sat Apr 22 16:00:35 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3MK0ZDX030230 for ; Sat, 22 Apr 2006 16:00:35 -0400 Received: from carter-zimmerman.mit.edu (STRATTON-FIVE-EIGHTY-TWO.MIT.EDU [18.187.7.71]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k3MK0XTl009724 for ; Sat, 22 Apr 2006 16:00:33 -0400 (EDT) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id C73B1E0004; Sat, 22 Apr 2006 16:00:26 -0400 (EDT) To: EKR References: <4435ACC6.8040500@thinkingcat.com> <20060407225743.GO8759@binky.Central.Sun.COM> <868xqgmrrn.fsf@raman.networkresonance.com> <20060408182052.GV8759@binky.Central.Sun.COM> <86vetjlxxd.fsf@raman.networkresonance.com> From: Sam Hartman Date: Sat, 22 Apr 2006 16:00:26 -0400 In-Reply-To: <86vetjlxxd.fsf@raman.networkresonance.com> (Eric Rescorla's message of "Sat, 08 Apr 2006 11:33:34 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 1.217 X-Spam-Level: * (1.217) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Leslie Daigle , iab@ietf.org, Nicolas Williams , Bernard Aboba Subject: Re: [saag] Frameworks, multiple mechanisms and draft-iab-auth-mech-05.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Apr 2006 20:00:35 -0000 >>>>> "Eric" == Eric Rescorla writes: Eric> Nicolas Williams writes: >> On Sat, Apr 08, 2006 at 12:49:00AM -0700, Eric Rescorla wrote: >> Lacking such a single unified mechanism (which, incidentally, >> would have to know how to negotiate credential types, thus >> making it much like a *framework*), and lacking a single >> credential type that is universally deployed and applicable I >> think the advice given in section 13.2 is useless and won't be >> followed. And where it is followed the result will be the >> subsequent grafting of additional mechanisms or frameworks to >> the protocols whose designers followed that advice; that is, >> the advice in 13.2 is, IMO counter-productive. >> >> I understand the sentiment in 13.2, but it isn't practical. Eric> I can't agree here. 13.2 explicitly acknowledges that there Eric> are cases where there are a variety of credential types. As Eric> noted before, it's talking about goals for future designs. The problem here is that future designs have to work with the current world. I can accept that the existing 13.2 would be reasonable advice in a world that did not have to interoperate with the Internet, deployed credentials or existing software. IETF protocol designers never operate under those constraints. If you want to talk about ideals, that's fine. However you also need to explicitly give the protocol designers practical advice for the constraints they are likely working under or let them know that your advice is blue sky and does not apply to their problems. The current 13.2 seems about as useful to me as the following camping advice. "Water and food take up weight. As a general rule, campers can travel faster and longer distances if they minimize what they carry. However some campers need water and food to survive. Except in instances where water and food are needed, we recommend against carrying them." The advice is 100% factually correct, but completely useless. I contend that the advice in 13.2 is not quite as useless as my camping advice, but it is flawed for a similar reason. Most protocol designers will be in situations where they need a framework and will need to support multiple mechanisms. The current text implies that you should avoid this situation and/or it will be rare. Text that pointed out why it would be nice if you could avoid the situation, why you can't in practice and what you should do instead would be much more realistic and useful. From hartmans@MIT.EDU Sat Apr 22 16:18:44 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3MKIi3F000933 for ; Sat, 22 Apr 2006 16:18:44 -0400 Received: from carter-zimmerman.mit.edu (STRATTON-FIVE-EIGHTY-TWO.MIT.EDU [18.187.7.71]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k3MKIlM3002057 for ; Sat, 22 Apr 2006 16:18:48 -0400 (EDT) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id D7911E0004; Sat, 22 Apr 2006 16:18:41 -0400 (EDT) To: Bernard Aboba References: From: Sam Hartman Date: Sat, 22 Apr 2006 16:18:41 -0400 In-Reply-To: (Bernard Aboba's message of "Wed, 5 Apr 2006 14:59:03 -0700 (PDT)") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 1.217 X-Spam-Level: * (1.217) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, iab@ietf.org Subject: Re: [saag] Frameworks, multiple mechanisms and draft-iab-auth-mech-05.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Apr 2006 20:18:44 -0000 >>>>> "Bernard" == Bernard Aboba writes: rds, this has proven very Bernard> difficult to achieve in practice. >> Section 13.4: >> >> Please warn people before recommending they just use IPsec to >> protect their channel. We've had significant trouble with >> doing this in the past. The OSPF authentication draft; L2TP's >> IPsec support; Iscsi's IPsec support; IPsec for L*VPN have all >> been challenging. Please at least include a pointer to >> draft-bellovin-use-ipsec (presumably informative so it does not >> block your document) and mention that many details need to be >> worked through and that IPsec is difficult to use for >> application security. Bernard> Would a discussion of channel binding issues be Bernard> appropriate here? I'd love to see such a discussion but I can see an argument that our thinking on channel binding is not mature enough to have specific recommendations for protocol designers. --Sam From ekr@networkresonance.com Sat Apr 22 16:29:57 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3MKTvjJ003039 for ; Sat, 22 Apr 2006 16:29:57 -0400 Received: from raman.networkresonance.com (raman.networkresonance.com [198.144.196.3]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k3MKT1nM014876; Sat, 22 Apr 2006 16:29:02 -0400 (EDT) Received: by raman.networkresonance.com (Postfix, from userid 1001) id C16FD1E8C1F; Sat, 22 Apr 2006 13:29:00 -0700 (PDT) To: Sam Hartman References: <4435ACC6.8040500@thinkingcat.com> <20060407225743.GO8759@binky.Central.Sun.COM> <868xqgmrrn.fsf@raman.networkresonance.com> <20060408182052.GV8759@binky.Central.Sun.COM> <86vetjlxxd.fsf@raman.networkresonance.com> From: Eric Rescorla Date: Sat, 22 Apr 2006 13:29:00 -0700 In-Reply-To: (Sam Hartman's message of "Sat, 22 Apr 2006 16:00:26 -0400") Message-ID: <86fyk5tkvn.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Leslie Daigle , iab@ietf.org, Nicolas Williams , Bernard Aboba Subject: Re: [saag] Frameworks, multiple mechanisms and draft-iab-auth-mech-05.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Reply-To: EKR List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Apr 2006 20:29:57 -0000 Sam Hartman writes: >>>>>> "Eric" == Eric Rescorla writes: > > Eric> Nicolas Williams writes: > >> On Sat, Apr 08, 2006 at 12:49:00AM -0700, Eric Rescorla wrote: > >> Lacking such a single unified mechanism (which, incidentally, > >> would have to know how to negotiate credential types, thus > >> making it much like a *framework*), and lacking a single > >> credential type that is universally deployed and applicable I > >> think the advice given in section 13.2 is useless and won't be > >> followed. And where it is followed the result will be the > >> subsequent grafting of additional mechanisms or frameworks to > >> the protocols whose designers followed that advice; that is, > >> the advice in 13.2 is, IMO counter-productive. > >> > >> I understand the sentiment in 13.2, but it isn't practical. > > Eric> I can't agree here. 13.2 explicitly acknowledges that there > Eric> are cases where there are a variety of credential types. As > Eric> noted before, it's talking about goals for future designs. > > > The problem here is that future designs have to work with the current > world. Yes, but that doesn't mean supporting every credential type that anyone has ever invented. > I can accept that the existing 13.2 would be reasonable advice in a > world that did not have to interoperate with the Internet, deployed > credentials or existing software. > > IETF protocol designers never operate under those constraints. Really? It seems to me that that's essentially the situation (at least with respect to credentials) that, for instance, the various Secure BGP designs are operating under, and in that environment it's quite reasonable to think in terms of only one credential type. > If you want to talk about ideals, that's fine. However you also need > to explicitly give the protocol designers practical advice for the > constraints they are likely working under or let them know that your > advice is blue sky and does not apply to their problems. > > The current 13.2 seems about as useful to me as the following camping > advice. > > "Water and food take up weight. As a general rule, campers can travel > faster and longer distances if they minimize what they carry. However > some campers need water and food to survive. Except in instances > where water and food are needed, we recommend against carrying them." > > The advice is 100% factually correct, but completely useless. Ah, the power of reasoning by analogy. As is so often the case, not only does the analogy fail to inform, it's not even really right on its own terms: backpackers are absolutely obsessed with the amount of weight they carry and once you've cut your gear down to the bare minimum, they represent a major fraction of the weight of your pack. Backpackers routinely minimize their food and water load intending to pick up additional supplies on the way. To the extent that your analogy is a helpful one, it makes my point, rather than yours. I never claimed that you shouldn't have ANY authentication but merely that you should minimize the number of authentication mechanisms you support, which is precisely analogous to the extremely useful advice of keeping down the amount of food and gear you have to carry. > I contend that the advice in 13.2 is not quite as useless as my > camping advice, but it is flawed for a similar reason. Most protocol > designers will be in situations where they need a framework and will > need to support multiple mechanisms. The current text implies that > you should avoid this situation and/or it will be rare. Text that > pointed out why it would be nice if you could avoid the situation, why > you can't in practice and what you should do instead would be much > more realistic and useful. Well, I don't agree that you "can't in practice". Sometimes you can and sometimes you can't. For instance, while SSH supports a broad variety of different client authentication schemes, it really only supports one server authentication scheme (pubkey). Much the same situation is true of TLS. So, I'm certainly not willing to rewrite this text along the lines of "this is a nice idea in principle but it can't ever happen in practice". I agree that the current text indicates that you should avoid this situation and I think that's correct. I don't agree that it implies that it's rare and if you want to provide some alternate text that you think corrects that impression, I'd certainly be willing to entertain it. -Ekr From hartmans@MIT.EDU Sat Apr 22 17:44:53 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3MLirC1017227 for ; Sat, 22 Apr 2006 17:44:53 -0400 Received: from carter-zimmerman.mit.edu (STRATTON-FIVE-EIGHTY-TWO.MIT.EDU [18.187.7.71]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k3MLiuos008068 for ; Sat, 22 Apr 2006 17:44:56 -0400 (EDT) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 1B04BE0004; Sat, 22 Apr 2006 17:44:49 -0400 (EDT) To: saag@MIT.EDU, anonsec@postel.org From: Sam Hartman Date: Sat, 22 Apr 2006 17:44:49 -0400 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 1.217 X-Spam-Level: * (1.217) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: townsley@cisco.com Subject: [saag] IPsec configuration via BGP--softwires to support overlay network confidentiality/integrity X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Apr 2006 21:44:54 -0000 Hi, folks. I'd like to describe some work that is proposed in the softwires working group. First though I'd like to review what we're trying to accomplish with security for Internet protocols and review how IPsec is being used in protocols over in the Internet area. Then I hope you'll join me in understanding that this work in softwires is a critical part of what we need to do in order to meet our goal of creating a usable security solution for overlay network protocols being developed in the Internet area. I hope you'll help make sure this work is a success. When we try and design security for a protocol, we start with a threat model and attempt to come up with a protocol design that provides security services adequate to address threats identified in the threat model. One of the key aspects of the success of this work is the deployability and usability of the security solutions. If the security solution is harder to configure than the rest of the protocol, then we have room for improvement. If the security solution has fundamentally different configuration scaling characteristics, then we have failed. As an example, consider a protocol intended to provide automated discovery. We cannot claim success if we only provide manually configured security for that protocol. Similarly we cannot claim success if the discovery mechanisms do not provide discovery for appropriate security parameters. Similarly, if we are designing security for a protocol where two parties who have no previous association will interact, we generally cannot assume any shared infrastructure or configuration for the security. We probably need to provide a mode of security that protects against passive attacks without infrastructure and/or a mode of security that depends on a PKI for protection against passive and active attacks. We have significant work to do in order to meet these goals of usability for some Internet Area protocols. Let me describe where things stand. The L3VPN working group was established to describe protocols for carrying customer IP traffic over a provider provisioned virtual private network. One use case is a customer who has multiple locations. The customer wishes to connect these locations together. The customer could get leased lines to each location, but instead hires the provider to provision an IP network . The provider wants to carry the customer traffic over the provider's existing network. However because everyone is using net 10 and for other reasons of isolation, the provider needs to tag the customer's packets with information about what addressing domain (which customer network) they belong to. For the networks under discussion MPLS is used. The L2VPN working group is doing similar things except they care about use cases where the provider wants to carry customer L2 packets over the provider's network. Similarly, the softwires working group supports a topology where you have a mesh of IPV6 tunnels over an IPV4 network or a mesh of IPV4 tunnels over an IPV6 network. The goal is to support cases where the core of a network is running a different version of IP than other parts. So, how do we provide confidentiality and integrity in these cases? We've decided that IPsec is the appropriate tool. RFC 4023 describes one of the basic encapsulations that would be used in these situations if you want to provide confidentiality or integrity. (Native MPLS over L2 does not typically support confidentiality or integrity) RFC 3931 describes L2TP V3, which provides another encapsulation that is useful in this space. Again, we have chosen IPsec as the confidentiality/integrity strategy. I know there are those here who believe that IPsec is the wrong strategy for application security. For these protocols, that ship has sailed: we have approved proposed standards that use IPsec. This predates my involvement in the IESG. Now we must provide usable security based on these existing decisions. Both RFC 4023 and 3931 provide reasonable security for the rest of the spec. IN particular, these specs provide for statically configured tunnels and provide for statically configured security. If you are specifying all the tunnel configuration by hand, it seems reasonable to specify the security configuration. I suspect the implementations are not all that usable: I suspect that you have to go to different parts of the configuration to set up the IPsec from the rest of the tunnel; I suspect that in practice there is no way to specify the tunnel endpoint once and have it apply both to the security configuration and the tunnel configuration. That's a problem but not a protocol problem. However all of these groups propose to provide automatic discovery of tunnels. For example RFC 4364 specifies a mechanism where BGP is used to discover and configure all the tunnels in an MPLS L3VPN. We need a security solution that is as easy to use as RFC 4364 in order to set up confidentiality and integrity for RFC 4364. The security requirements we're trying to deal with are outlined in RFC 4031 and its references. Roughly we're trying to provide confidentiality and integrity protection of the customer traffic. One controversial assumption I'm making here is that we can rely on the integrity of the signaling/discovery mechanism to give us integrity and confidentiality for the data plane. If the discovery were between the same two parties as the data traffic this would not be very controversial. However the discovery is carried over BGP. That means that the parties in the discovery may be different than the parties in the data plane exchange. Note that we've decided in the case of SIP, SDP and RTP that this model where hop-by-hop proxies are used to set up end-to-end confidentiality/integrity is OK. Without relying on the integrity of BGP, we'd have to require a PKI or preshared keys. A PKI is a non-starter for the deployment community--this is one of those layer 9 concerns that do establish requirements for engineering. The real problem with relying on BGP integrity is that it's kind of weak. The best case today is TCPMD5 and the worst case today is none. So, let's consider what we can get if we rely on BGP integrity and it happens not to be there. Well we can still get protection against passive attacks. So long as the attacker does not actually modify the BGP session, then we can negotiate end-to-end SAs authenticated with the right parties. If our BGP does happen to be integrity protected we get full protection against active attacks. If we do happen to have a PKI, our implementation supports using that and we have it configured, we end up getting optimal protection even if BGP is not properly integrity protected. My personal feeling is that deploying easy-to-use security that provides protection only against passive attacks is better than no security. Since the solution we're proposing does better than that I think it is a reasonable approach. Another thing to note about depending on BGP integrity. BGP will end up having to be used to configure whether a particular association is expected to have IPsec. As such anyone who can modify the BGP routes can disable security. So, what is the proposed solution? First, note that we are targeting the IPsec architecture described in RFC 2401. After discussing draft-bellovin-use-ipsec and my experiences with the OSPF V3 authentication draft, Russ and I have decided that we cannot ask people to use RFC 4301 to secure higher-layer protocols at this time. There aren't enough implementations and we really need guidance similar to draft-bellovin-use-ipsec targeted at 4301 before we could do that. People who are interested in seeing us move to 4301 should work on implementations and should work on BCPs and informational documents designed to make it easier to use in these situations. Russ and I both think that RFC 4301 is a significant improvement over RFC 2401. The idea is to include information in BGP routes used to set up the tunnels sufficient to let peers know that they want to use IPsec, know which identity to authenticate to and what IPsec parameters to use. Peers should already know what SPD entries to create because they should be able to identify what ports/protocols their tunnel traffic will use in order to establish that tunnel traffic. In practice this means that BGP would probably distribute a fingerprint of a certificate along with some very short identifier indicating any additional configuration information that is needed. The work on what to carry in BGP will be accompanied by a profile of IPsec which requires (probably by reference to the IPsec algorithms documents) appropriate mandatory algorithms and which specifies how to configure the SPD for this application. The work will take place in the softwires working group. They could of course use any IPsec help we are able to provide. Now is your chance to scream about the general approach. If you disagree, please explain how we can meet the requirements outlined in RFC 4031 and provide usable security solutions while still fixing the parts you disagree with. Thanks, --Sam From gis-saag@gmane.org Sat Apr 22 20:45:03 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3N0j301012568 for ; Sat, 22 Apr 2006 20:45:03 -0400 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k3N0j5vx005442 for ; Sat, 22 Apr 2006 20:45:05 -0400 (EDT) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1FXSik-0004nc-7h for saag@mit.edu; Sun, 23 Apr 2006 02:45:03 +0200 Received: from 24.244.240.254 ([24.244.240.254]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 23 Apr 2006 02:45:02 +0200 Received: from mcr by 24.244.240.254 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 23 Apr 2006 02:45:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: saag@mit.edu From: Michael Richardson Date: Sat, 22 Apr 2006 19:40:27 -0400 Lines: 72 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 24.244.240.254 User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Jumbo Shrimp, linux) Cancel-Lock: sha1:K6QzifDMVAoCoHH7ZHMhRr0GLNk= Sender: news X-Spam-Score: -1.1 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: anonsec@postel.org Subject: Re: [saag] IPsec configuration via BGP--softwires to support overlay network confidentiality/integrity X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Apr 2006 00:45:04 -0000 --=-=-= >>>>> "Sam" == Sam Hartman writes: Sam> First, note that we are targeting the IPsec architecture described Sam> in RFC 2401. After discussing draft-bellovin-use-ipsec and my Sam> experiences with the OSPF V3 authentication draft, Russ and I have Sam> decided that we cannot ask people to use RFC 4301 to secure Sam> higher-layer protocols at this time. There aren't enough To confirm: you telling people to say "RFC2401" rather than "RFC4301" (Alternative which you are not saying is "do not use IPsec") Sam> The idea is to include information in BGP routes used to set up the Sam> tunnels sufficient to let peers know that they want to use IPsec, Sam> know which identity to authenticate to and what IPsec parameters to Sam> use. Peers should already know what SPD entries to create because I question the need for all of these parameters in BGP. I haven't read the documents yet, but all *I* need to know if the public key (not certificate) (RSA preferred as I don't support DSA), and the end-point. The cryptographic algorithms are negotiable in IKE. If we don't have a common set, saying so in BGP won't help. The ID: it's the IP of the end-point. I suspect that we really want to negotiate a transport mode SA for IP protocol 4 (or 98 or 94..), not a tunnel mode SA. We might use MODECFG to assign IP addresses for the virtual interface that we are creating. In IKEv2, we can actually do that with the TS negotiation. Sam> The work on what to carry in BGP will be accompanied by a profile of Sam> IPsec which requires (probably by reference to the IPsec algorithms Sam> documents) appropriate mandatory algorithms and which specifies how Sam> to configure the SPD for this application. Of course, the set of algorithms that one requires will change over time, so the mandatory set will get stale. Of course, the document will specify at least 2 of each algorithm so that implementations will have to test actually switching. Sam> Now is your chance to scream about the general approach. If you I like it. PS: I'm curious Sam: are cleartext or MIME signatures easier for your text-to-speech to deal with? -- ] 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"); [ "The Microsoft _Get the Facts CD_ does not work on Linux." - orospakr --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iQEVAwUAREq+8ICLcPvd0N1lAQJ5sQf/Xxh+CZeakVj2/nAaV9SebNp636I/W5En b/TEsaUViCH97NyLpvygjsxuIlepsPOeS5w81uLSxhY6A+5LX0D99QT8dJEoWPi0 3J5q9/edD0Iu8ZLYlNuM0Q1Qx77RCTRSDd+nVi0E3Phl5h3DdkpyIrV+m9UJ/VT/ FAob6vHit2qh48KF5DR3hhOK+FhlC2o8L+kyWRERjHmJE1lf0ODMbtgmozxno8dB cAtpad5pvV0z2CuLImw8R+BztqujyjzJEGC9cqAtSg6S0cT0SXf9qJvRRCuisiID r/thPpdPSaTghgkA5PEiozD9crDr023HOTcTRNSlOM/6hII635581A== =Url0 -----END PGP SIGNATURE----- --=-=-=-- From hartmans@MIT.EDU Sun Apr 23 02:27:23 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3N6RN39004840 for ; Sun, 23 Apr 2006 02:27:23 -0400 Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k3N6RQhF013868 for ; Sun, 23 Apr 2006 02:27:26 -0400 (EDT) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 7225BE0006; Sun, 23 Apr 2006 02:27:18 -0400 (EDT) To: Michael Richardson References: From: Sam Hartman Date: Sun, 23 Apr 2006 02:27:18 -0400 In-Reply-To: (Michael Richardson's message of "Sat, 22 Apr 2006 19:40:27 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 1.352 X-Spam-Level: * (1.352) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, anonsec@postel.org Subject: Re: [saag] IPsec configuration via BGP--softwires to support overlay network confidentiality/integrity X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Apr 2006 06:27:27 -0000 >>>>> "Michael" == Michael Richardson writes: >>>>> "Sam" == Sam Hartman writes: Sam> First, note that we are targeting the IPsec architecture Sam> described in RFC 2401. After discussing Sam> draft-bellovin-use-ipsec and my experiences with the OSPF V3 Sam> authentication draft, Russ and I have decided that we cannot Sam> ask people to use RFC 4301 to secure higher-layer protocols Sam> at this time. There aren't enough Michael> To confirm: you telling people to say "RFC2401" rather Michael> than "RFC4301" (Alternative which you are not saying is Michael> "do not use IPsec") We're saying 2401 today; we'd love to get to 4301 as soon as we can. "no security," is a non-option. "Don't use IPsec" is an option in cases where we've already decided to use IPsec. Sam> The idea is to include information in BGP routes used to set Sam> up the tunnels sufficient to let peers know that they want to Sam> use IPsec, know which identity to authenticate to and what Sam> IPsec parameters to use. Peers should already know what SPD Sam> entries to create because Michael> I question the need for all of these parameters in BGP. Michael> I haven't read the documents yet, but all *I* need to Michael> know if the public key (not certificate) (RSA preferred Michael> as I don't support DSA), and the end-point. The Michael> cryptographic algorithms are negotiable in IKE. If we Michael> don't have a common set, saying so in BGP won't help. Michael> The ID: it's the IP of the end-point. Valid points. I think it is important to support certs; I don't much care whether we support public keys or not, or what we hash in BGP. You're right; we only need to negotiate parameters in BGP that will not be negotiated by IKE and for which negotiation is useful. Michael> PS: I'm curious Sam: are cleartext or MIME signatures Michael> easier for your text-to-speech to deal with? Both are fine, but mime work better with my mail reader. From shep@xplot.org Sun Apr 23 13:00:46 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3NH0kUV021620 for ; Sun, 23 Apr 2006 13:00:46 -0400 Received: from alva.home (dsl092-066-146.bos1.dsl.speakeasy.net [66.92.66.146]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k3NH0gL9012589; Sun, 23 Apr 2006 13:00:42 -0400 (EDT) Received: from shep (helo=alva.home) by alva.home with local-esmtp (Exim 3.36 #1 (Debian)) id 1FXhwb-0002EM-00; Sun, 23 Apr 2006 13:00:21 -0400 From: Tim Shepard To: Sam Hartman In-reply-to: Your message of Sat, 22 Apr 2006 16:00:26 -0400. Date: Sun, 23 Apr 2006 13:00:21 -0400 Message-Id: Sender: Tim Shepard X-Spam-Score: -2.464 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 X-Mailman-Approved-At: Sun, 23 Apr 2006 13:26:45 -0400 Cc: Leslie Daigle , iab@ietf.org, Nicolas Williams , Bernard Aboba , saag@mit.edu Subject: Re: [saag] Frameworks, multiple mechanisms and draft-iab-auth-mech-05.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Apr 2006 17:00:52 -0000 Sam said: > The problem here is that future designs have to work with the current > world. Not all future designs have to work with the current world (of networking and security protocols). > I can accept that the existing 13.2 would be reasonable advice in a > world that did not have to interoperate with the Internet, deployed > credentials or existing software. > > IETF protocol designers never operate under those constraints. You seem to be saying that IETF protocol designers must always be constrained to maintain compatibility with currently deployed protocols. Will the IETF still be relevant to the world of computer networking in 15 years? If it is to have a chance, then it must be sometimes allowed to attempt to design the right thing for the future, more or less unconstrained to remain compatible with details of the past. If the IETF is constrained to never break free from the past, then it will be irrelevant in the future (eventually). > If you want to talk about ideals, that's fine. However you also need > to explicitly give the protocol designers practical advice for the > constraints they are likely working under or let them know that your > advice is blue sky and does not apply to their problems. > > The current 13.2 seems about as useful to me as the following camping > advice. > > "Water and food take up weight. As a general rule, campers can travel > faster and longer distances if they minimize what they carry. However > some campers need water and food to survive. Except in instances > where water and food are needed, we recommend against carrying them." > > > The advice is 100% factually correct, but completely useless. I just re-read section 13.2, and it seems entirely reasonable, and it already contains a caveat along the lines of what you seem to want. In fact, most of the text in 13.2 is navigational advice for this issue. I wonder if you dislike section 13.2 because it is merely stating the obvious (to readers like us who already understand). Sometimes the obvious does need to be written down (for those for whom it is not obvious, and to provide a convenient reference in discussions). -Tim Shepard shep@alum.mit.edu From aboba@internaut.com Sun Apr 23 15:39:32 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3NJdWcn012441 for ; Sun, 23 Apr 2006 15:39:32 -0400 Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k3NJdVNh008306 for ; Sun, 23 Apr 2006 15:39:31 -0400 (EDT) Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1FXkQc-000Gii-T0; Sun, 23 Apr 2006 15:39:31 -0400 Received: by internaut.com (Postfix, from userid 1000) id ADC99708E1; Sun, 23 Apr 2006 12:39:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id A0305232C3; Sun, 23 Apr 2006 12:39:27 -0700 (PDT) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Sun, 23 Apr 2006 12:39:27 -0700 (PDT) From: Bernard Aboba To: Michael Richardson In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: -2.464 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, anonsec@postel.org Subject: Re: [saag] IPsec configuration via BGP--softwires to support overlay network confidentiality/integrity X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Apr 2006 19:39:37 -0000 > I question the need for all of these parameters in BGP. I agree with Michael here. Similar issues arose with RFC 3723, which proposed distributing security policy via iSNS. At that time it was found that only a minimal set of security parameters were required. > The cryptographic algorithms are negotiable in IKE. If we don't have a > common set, saying so in BGP won't help. > The ID: it's the IP of the end-point. I think this makes sense, assuming that the endpoints can be assumed to be using static addresses. Also I agree that IKE should be used for algorithm negotiation (though use of algorithms such as DES should probably be discouraged). > I suspect that we really want to negotiate a transport mode SA for IP > protocol 4 (or 98 or 94..), not a tunnel mode SA. Right. > We might use MODECFG to assign IP addresses for the virtual interface that > we are creating. In IKEv2, we can actually do that with the TS negotiation. If transport mode SAs are being negotiated, this will probably not be necessary. > Sam> The work on what to carry in BGP will be accompanied by a profile of > Sam> IPsec which requires (probably by reference to the IPsec algorithms > Sam> documents) appropriate mandatory algorithms and which specifies how > Sam> to configure the SPD for this application. This was the approach taken in RFC 3723. > Of course, the set of algorithms that one requires will change over time, > so the mandatory set will get stale. Of course, the document will specify at > least 2 of each algorithm so that implementations will have to test actually > switching. Yup. My suggestion would be to make sure that the two algorithms chosen are well supported. > I like it. I also think it makes sense at a high level. Of course, the devil is in the details. From mcgrew@cisco.com Mon Apr 24 08:45:44 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3OCjirl007978 for ; Mon, 24 Apr 2006 08:45:44 -0400 Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k3OCjgPg006280 for ; Mon, 24 Apr 2006 08:45:43 -0400 (EDT) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 24 Apr 2006 05:45:43 -0700 X-IronPort-AV: i="4.04,151,1144047600"; d="scan'208"; a="424953562:sNHT32502046" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k3OCjgw1008935; Mon, 24 Apr 2006 05:45:42 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 24 Apr 2006 05:45:41 -0700 Received: from [192.168.1.100] ([10.32.254.210]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 24 Apr 2006 05:45:41 -0700 In-Reply-To: <867j5jzoo3.fsf@raman.networkresonance.com> References: <7.0.0.16.2.20060420095609.06191b18@vigilsec.com> <867j5jzoo3.fsf@raman.networkresonance.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1B8D8BD9-15CF-47E6-A32E-34114F96DE23@cisco.com> Content-Transfer-Encoding: 7bit From: David McGrew Date: Mon, 24 Apr 2006 05:45:37 -0700 To: EKR X-Mailer: Apple Mail (2.746.3) X-OriginalArrivalTime: 24 Apr 2006 12:45:41.0292 (UTC) FILETIME=[FEBBD6C0:01C6679C] X-Spam-Score: -2.4 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Russ Housley Subject: Re: [saag] Fwd: draft-bonica-tcp-auth X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2006 12:45:44 -0000 Hi Eric, a few comments inline: On Apr 20, 2006, at 6:46 PM, Eric Rescorla wrote: > Russ Housley writes: >> We had a presentation at the IETF 65 SAAG session about this >> document. What should we say to the TCPM folks? > > As I indicated in SAAG, I'm fairly uncomfortable with this > whole "64-key" thing. The rationale for multiple keys appears > to be: > > 1. To limit the exposure if a key is compromised. > 2. To limit the amount of material protected with a single > key in order to prevent cryptanalytic attacks. > > These are two quite different purposes being bundled into one > mechanism. In many other protocols they are separated. For instance, > the security of a TLS connection often depends on a long-term RSA key, > but the handshake ensures that each connection gets its own set of > keys. The temporal limits used in this document are potentially > applicable to use (1) but aren't really applicable to use (2) since > the issue is the amount of data protected, not the amount of time that > has passed. Incidentally, it's worth noting that attacks based on > observing large amounts of ciphertext (or in this case protected > traffic) are largely inapplicable to modern MAC algorithms. For > instance, the CMAC security bound is 2^22 GBytes, or approximately one > petabyte of traffic. > > An additional issue with the use of temporal rather than traffic > based keys is that there is actually a reasonable probability > that two separate connections with the same host/port quartet will > use the same keys. Consider what happens with a connection between > A and B where A did the active open. When A restarts, it reinitiates > the same connection and there is a reasonable chance that it will > use the same local port. If it is connecting to a well-known port > on B, then you will have the same quartet. If the sequence > numbers are randomly selected (as suggested by RFC 1948) and > a lot of data is passed, then there is a reasonable chance of > overlap. > > In my opinion, rather than using static temporal keys like this, it > would be better to generate a per-connection key. Even if you want to > use static keying, this can be done by simply feeding the static key > and random nonces exchanged in the SYN (the ISN may be enough, but > better to be safe and use a cookie) into a KDF and using the output as > the MAC key. This method is similar to what's in draft-weis-tcp-auth-auto-ks, except that you're proposing deriving the session keys from nonces, while the draft is doing key transport. The key transport is a bit simpler, since it allows the session MAC key to be used to protect the very first message of the TCP connection. (Though I'm sure something based on derivation rather than transport could be made to work as well.) > (Better yet, generate directional MAC keys). If you wish > to have temporal keys, it's straightforward to pass a key-id in the > initial exchange. A mechanism like this ensures unique keys for each > connection and also limits the amount of material protected with > a given traffic key. If you actually do reach the (very large) > limits on key use, it's straightforward to tear down the connection > or use a rollover counter which you feed back into the KDF. I agree; it is desirable to build in a way to establish a session key based on a long term key. > > While we're on the topic of rollover counters, it seems like > it might be desirable to include one in the MAC calculation > in order to avoid substitution of messages from one pass through > the sequence number space with another. > You may be right about this. I have talked about the substitution attack with the other authors of draft-weis-tcp-auth-auto-ks and we decided to address the issue by mandating that session MAC keys are changed prior to the TCP SEQ wrap. This is a good technical solution, but it only applies to draft-weis and not all of draft- bonica. If a rollover counter were added to draft-bonica, it would address the issue regardless of whether or not draft-weis was used or not. David > -Ekr > > > > > > > > > > > > > > > > _______________________________________________ > saag mailing list > saag@mit.edu > http://mailman.mit.edu/mailman/listinfo/saag From kivinen@iki.fi Mon Apr 24 07:26:27 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3OBQRAv020659 for ; Mon, 24 Apr 2006 07:26:27 -0400 Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k3OBQKSm020117 for ; Mon, 24 Apr 2006 07:26:20 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.5.20060308/8.12.10) with ESMTP id k3OBPiqg019354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Apr 2006 14:25:44 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.5.20060308/8.12.11) id k3OBPhvD001639; Mon, 24 Apr 2006 14:25:43 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17484.46519.253835.420524@fireball.kivinen.iki.fi> Date: Mon, 24 Apr 2006 14:25:43 +0300 From: Tero Kivinen To: Stephen Kent In-Reply-To: References: <7.0.0.16.2.20060420095609.06191b18@vigilsec.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 8 min X-Total-Time: 8 min X-Spam-Score: -2.464 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 X-Mailman-Approved-At: Mon, 24 Apr 2006 09:18:50 -0400 Cc: saag@mit.edu, Russ Housley Subject: Re: [saag] Fwd: draft-bonica-tcp-auth X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2006 11:26:27 -0000 Stephen Kent writes: > 3. On the RPSEC mailing list there was a discussion of > whether this sort of replacement for the MD5 option was the right > path, or whether IPsec should be used. (ESP with NULL encryption > would offer equivalent security functionality for BGP sessions.) > After several message exchanges it appears that the primary reason > for not using IPsec is that current router IPsec implementations are > designed to protect subscriber traffic (with the router acting as a > security gateway), and this makes it hard to configure them to > protect router management traffic, e.g., BGP sessions. The concern with the current router IPsec implementations should only matter if we are comparing it to the protocol already in the router too. So is this proposed draft-bonica-tcp-auth already implemented and supported by the routers? If not then the router software requires to be updated. If the software is being updated then they can also update it with the better IPsec implementation, or even include support for the latest IPsec versions, i.e. IKEv2 and RFC4301, instead of the now obsoleted IKEv1 and RFC2401... As far as I have understood the proposed protocol is not implemented in the routers yet, and comparing that to the limited use IPsec implementations on the routers does not really matter. It should be compared latest IPsec protocol instead. The latest IPsec protocol is already out as an RFC, and there are several implementations and toolkits available that can support things needed for this. -- kivinen@safenet-inc.com From pekkas@netcore.fi Mon Apr 24 10:58:05 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3OEw4j1006234 for ; Mon, 24 Apr 2006 10:58:05 -0400 Received: from netcore.fi (netcore.fi [193.94.160.1]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k3OEvu7u012939 for ; Mon, 24 Apr 2006 10:57:57 -0400 (EDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060308/8.12.11) with ESMTP id k3OEvfCp004294; Mon, 24 Apr 2006 17:57:42 +0300 Date: Mon, 24 Apr 2006 17:57:41 +0300 (EEST) From: Pekka Savola To: David McGrew In-Reply-To: <1B8D8BD9-15CF-47E6-A32E-34114F96DE23@cisco.com> Message-ID: References: <7.0.0.16.2.20060420095609.06191b18@vigilsec.com> <867j5jzoo3.fsf@raman.networkresonance.com> <1B8D8BD9-15CF-47E6-A32E-34114F96DE23@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.1/1421/Sun Apr 23 21:31:05 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_20,NO_RELAYS autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on otso.netcore.fi X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Russ Housley Subject: Re: [saag] Fwd: draft-bonica-tcp-auth X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2006 14:58:05 -0000 On Mon, 24 Apr 2006, David McGrew wrote: (quoting EKR) >> (Better yet, generate directional MAC keys). If you wish >> to have temporal keys, it's straightforward to pass a key-id in the >> initial exchange. A mechanism like this ensures unique keys for each >> connection and also limits the amount of material protected with >> a given traffic key. If you actually do reach the (very large) >> limits on key use, it's straightforward to tear down the connection >> or use a rollover counter which you feed back into the KDF. > > I agree; it is desirable to build in a way to establish a session key > based on a long term key. I'm not sure if the length of the key is a concern in the operational community. The need to change the keys is based on other factors (such as, an employee leaving the company) rather than a fear of crypthographic brute-forcing. Generating temporal keys might not hurt, but doesn't fix the real problem. -- 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 ekr@networkresonance.com Mon Apr 24 11:54:43 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3OFshnM021418 for ; Mon, 24 Apr 2006 11:54:43 -0400 Received: from raman.networkresonance.com (raman.networkresonance.com [198.144.196.3]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k3OFsam4008860 for ; Mon, 24 Apr 2006 11:54:36 -0400 (EDT) Received: by raman.networkresonance.com (Postfix, from userid 1001) id C87601E8C1F; Mon, 24 Apr 2006 08:54:35 -0700 (PDT) To: Pekka Savola References: <7.0.0.16.2.20060420095609.06191b18@vigilsec.com> <867j5jzoo3.fsf@raman.networkresonance.com> <1B8D8BD9-15CF-47E6-A32E-34114F96DE23@cisco.com> From: Eric Rescorla Date: Mon, 24 Apr 2006 08:54:35 -0700 In-Reply-To: (Pekka Savola's message of "Mon, 24 Apr 2006 17:57:41 +0300 (EEST)") Message-ID: <864q0jj7es.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, David McGrew , Russ Housley Subject: Re: [saag] Fwd: draft-bonica-tcp-auth X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Reply-To: EKR List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2006 15:54:43 -0000 Pekka Savola writes: > On Mon, 24 Apr 2006, David McGrew wrote: (quoting EKR) >>> (Better yet, generate directional MAC keys). If you wish >>> to have temporal keys, it's straightforward to pass a key-id in the >>> initial exchange. A mechanism like this ensures unique keys for each >>> connection and also limits the amount of material protected with >>> a given traffic key. If you actually do reach the (very large) >>> limits on key use, it's straightforward to tear down the connection >>> or use a rollover counter which you feed back into the KDF. >> >> I agree; it is desirable to build in a way to establish a session key >> based on a long term key. > > I'm not sure if the length of the key is a concern in the operational > community. I can understand that, but substitution between sessions should be. > The need to change the keys is based on other factors (such as, an > employee leaving the company) rather than a fear of crypthographic > brute-forcing. > > Generating temporal keys might not hurt, but doesn't fix the real > problem. I think that's a reasonable point, but here again some kind of automatic key management is a part of that equation, I think, because it gives you the opportunity to do a smooth transition at a time of your choice (i.e., when the employee leaves) rather than on some pre-determined schedule. -Ekr From mcgrew@cisco.com Mon Apr 24 12:12:50 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3OGCoft024654 for ; Mon, 24 Apr 2006 12:12:50 -0400 Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k3OGCgG3011277 for ; Mon, 24 Apr 2006 12:12:43 -0400 (EDT) Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 24 Apr 2006 09:12:29 -0700 X-IronPort-AV: i="4.04,152,1144047600"; d="scan'208"; a="1798094600:sNHT3135156672" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k3OGCTVI011705; Mon, 24 Apr 2006 09:12:29 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 24 Apr 2006 09:12:29 -0700 Received: from [192.168.1.100] ([10.32.254.210]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 24 Apr 2006 09:12:28 -0700 In-Reply-To: References: <7.0.0.16.2.20060420095609.06191b18@vigilsec.com> <867j5jzoo3.fsf@raman.networkresonance.com> <1B8D8BD9-15CF-47E6-A32E-34114F96DE23@cisco.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: David McGrew Date: Mon, 24 Apr 2006 09:12:25 -0700 To: Pekka Savola X-Mailer: Apple Mail (2.746.3) X-OriginalArrivalTime: 24 Apr 2006 16:12:28.0776 (UTC) FILETIME=[E22BA680:01C667B9] X-Spam-Score: -2.4 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Russ Housley Subject: Re: [saag] Fwd: draft-bonica-tcp-auth X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2006 16:12:50 -0000 Hi Pekka, On Apr 24, 2006, at 7:57 AM, Pekka Savola wrote: > autolearn=ham version=3.1.1 > X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on > otso.netcore.fi > > On Mon, 24 Apr 2006, David McGrew wrote: (quoting EKR) >>> (Better yet, generate directional MAC keys). If you wish >>> to have temporal keys, it's straightforward to pass a key-id in the >>> initial exchange. A mechanism like this ensures unique keys for each >>> connection and also limits the amount of material protected with >>> a given traffic key. If you actually do reach the (very large) >>> limits on key use, it's straightforward to tear down the connection >>> or use a rollover counter which you feed back into the KDF. >> >> I agree; it is desirable to build in a way to establish a session key >> based on a long term key. > > I'm not sure if the length of the key is a concern in the > operational community. but that's not the only motivation for session keys. Please see Sections 3 and 6 of draft-weis-tcp-auth-auto-ks-00.txt. > > The need to change the keys is based on other factors (such as, an > employee leaving the company) rather than a fear of crypthographic > brute-forcing. > I agree that these operational access control issues often cause operators to need to change keys. These issues aren't addressed in the draft that I'd mentioned, nor do I think that they should be in scope even (can't solve every problem inside a TCP option :-) David > Generating temporal keys might not hurt, but doesn't fix the real > problem. > > -- > 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 nw141292@binky.Central.Sun.COM Mon Apr 24 12:35:49 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3OGZnXV032741 for ; Mon, 24 Apr 2006 12:35:49 -0400 Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k3OGZZf5019939; Mon, 24 Apr 2006 12:35:35 -0400 (EDT) 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 k3OGZZ8x017680; Mon, 24 Apr 2006 10:35:35 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k3OGZXde010210; Mon, 24 Apr 2006 10:35:34 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k3OGZWMo004033; Mon, 24 Apr 2006 11:35:32 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k3OGZVW3004032; Mon, 24 Apr 2006 11:35:31 -0500 (CDT) Date: Mon, 24 Apr 2006 11:35:31 -0500 From: Nicolas Williams To: Eric Rescorla Message-ID: <20060424163531.GB4000@binky.Central.Sun.COM> References: <4435ACC6.8040500@thinkingcat.com> <20060407225743.GO8759@binky.Central.Sun.COM> <868xqgmrrn.fsf@raman.networkresonance.com> <20060408182052.GV8759@binky.Central.Sun.COM> <86vetjlxxd.fsf@raman.networkresonance.com> <86fyk5tkvn.fsf@raman.networkresonance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86fyk5tkvn.fsf@raman.networkresonance.com> User-Agent: Mutt/1.5.7i X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Leslie Daigle , Sam Hartman , iab@ietf.org, Bernard Aboba Subject: Re: [saag] Frameworks, multiple mechanisms and draft-iab-auth-mech-05.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2006 16:35:49 -0000 On Sat, Apr 22, 2006 at 01:29:00PM -0700, Eric Rescorla wrote: > Sam Hartman writes: > > The problem here is that future designs have to work with the current > > world. > > Yes, but that doesn't mean supporting every credential type that > anyone has ever invented. No, but it does mean at least two credential types, no, for users anyways? Initial credential types (e.g., passwords, perhaps public keys derived therefrom, and so on) and non-initial types (e.g., Kerberos tickets, downloaded PKIX certs, SAML authentication statements....). There's a lot to choose from. Choose :) Nico -- From hartmans@MIT.EDU Mon Apr 24 15:16:04 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3OJG4XB030367 for ; Mon, 24 Apr 2006 15:16:04 -0400 Received: from carter-zimmerman.mit.edu (carter-zimmerman.dyn.mit.edu [18.188.3.148]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k3OJG1Qu000560 for ; Mon, 24 Apr 2006 15:16:01 -0400 (EDT) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id B910FE0053; Mon, 24 Apr 2006 15:15:54 -0400 (EDT) To: Tim Shepard References: From: Sam Hartman Date: Mon, 24 Apr 2006 15:15:54 -0400 In-Reply-To: (Tim Shepard's message of "Sun, 23 Apr 2006 13:00:21 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 1.217 X-Spam-Level: * (1.217) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: Leslie Daigle , iab@ietf.org, Nicolas Williams , Bernard Aboba , saag@mit.edu Subject: Re: [saag] Frameworks, multiple mechanisms and draft-iab-auth-mech-05.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2006 19:16:04 -0000 >>>>> "Tim" == Tim Shepard writes: Tim> Sam said: >> The problem here is that future designs have to work with the >> current world. Tim> Not all future designs have to work with the current world Tim> (of networking and security protocols). Please give some examples. It has generally been my experience that future design do have to work with the current world. >> I can accept that the existing 13.2 would be reasonable advice >> in a world that did not have to interoperate with the Internet, >> deployed credentials or existing software. >> >> IETF protocol designers never operate under those constraints. Tim> You seem to be saying that IETF protocol designers must Tim> always be constrained to maintain compatibility with Tim> currently deployed protocols. I am. I'm saying that we must evolve from where we are today to where we want to be. Today, this generally means supporting all the credential formats that exist. This is not about IETF protocols vs anything else: this is about deployability. There may be some specific cases where we don't care about deployed security mechanisms; DKIM and long-lived signatures in DNS are the only two examples I can think of. Note that even for DNS TSIG, we need to (and do) support a framework. --Sam From hartmans@MIT.EDU Mon Apr 24 15:31:41 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3OJVeSS000485 for ; Mon, 24 Apr 2006 15:31:40 -0400 Received: from carter-zimmerman.mit.edu (carter-zimmerman.dyn.mit.edu [18.188.3.148]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k3OJVXqx023839 for ; Mon, 24 Apr 2006 15:31:34 -0400 (EDT) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 9EEE4E0053; Mon, 24 Apr 2006 15:31:27 -0400 (EDT) To: EKR References: <4435ACC6.8040500@thinkingcat.com> <20060407225743.GO8759@binky.Central.Sun.COM> <868xqgmrrn.fsf@raman.networkresonance.com> <20060408182052.GV8759@binky.Central.Sun.COM> <86vetjlxxd.fsf@raman.networkresonance.com> <86fyk5tkvn.fsf@raman.networkresonance.com> From: Sam Hartman Date: Mon, 24 Apr 2006 15:31:27 -0400 In-Reply-To: <86fyk5tkvn.fsf@raman.networkresonance.com> (Eric Rescorla's message of "Sat, 22 Apr 2006 13:29:00 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 1.217 X-Spam-Level: * (1.217) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Leslie Daigle , iab@ietf.org, Nicolas Williams , Bernard Aboba Subject: Re: [saag] Frameworks, multiple mechanisms and draft-iab-auth-mech-05.txt X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2006 19:31:41 -0000 >>>>> "Eric" == Eric Rescorla writes: Eric> Sam Hartman writes: >>>>>>> "Eric" == Eric Rescorla >>>>>>> writes: >> Eric> Nicolas Williams writes: >> >> On Sat, Apr 08, 2006 at 12:49:00AM -0700, Eric Rescorla >> wrote: >> Lacking such a single unified mechanism (which, >> incidentally, >> would have to know how to negotiate credential >> types, thus >> making it much like a *framework*), and lacking >> a single >> credential type that is universally deployed and >> applicable I >> think the advice given in section 13.2 is >> useless and won't be >> followed. And where it is followed the >> result will be the >> subsequent grafting of additional >> mechanisms or frameworks to >> the protocols whose designers >> followed that advice; that is, >> the advice in 13.2 is, IMO >> counter-productive. >> >> >> >> I understand the sentiment in 13.2, but it isn't practical. >> Eric> I can't agree here. 13.2 explicitly acknowledges that there Eric> are cases where there are a variety of credential types. As Eric> noted before, it's talking about goals for future designs. >> >> >> The problem here is that future designs have to work with the >> current world. Eric> Yes, but that doesn't mean supporting every credential type Eric> that anyone has ever invented. No, but it does mean that you need to support any credential that is in use in the deployment environments where your protocol will be deployed. Otherwise you risk creating a need for multiple security infrastructures (which tends to create worse security practices than supporting multiple credentials) or risk your protocol not being deployed. >> I can accept that the existing 13.2 would be reasonable advice >> in a world that did not have to interoperate with the Internet, >> deployed credentials or existing software. >> >> IETF protocol designers never operate under those constraints. Eric> Really? It seems to me that that's essentially the situation Eric> (at least with respect to credentials) that, for instance, Eric> the various Secure BGP designs are operating under, and in Eric> that environment it's quite reasonable to think in terms of Eric> only one credential type. In the inter-AS case, that may be true. In the intra-AS case, I'm not at all sure that's the case. If you provide BGP security that works with my existing security infrastructure, I may use it; if you require me to deploy a new PKI, I probably will ignore your work. Now, since intra-AS BGP tends to also be involved in inter-AS BGP environments, the inter-AS security may give me enough of a justification to sign up to the single mechanism. I actually think DKIM and parts of dnssec are better examples of the point you are trying to make. However, most new security work within the IETF does not fall into one of these cases. New security work that is taking IAB recomendations as its basis especially is not going to be in the situation of paving new ground. The work like BGP security, DKIM etc will attract enough experts that we'll be able to evaluate the tradeoffs and come to reasonable recommendations no matter what you say here. The kind of work that is going to take your recommendations and try and blindly follow them is working groups like rmon with the raqmon protocol. They had a simple, well defined security problem (client-server security) and were looking for documentation of how to do it. Those are the people who are going to a take a document like the one you are writing and treat it as design advice without a lot of critical evaluation. Their assumption will be that they are not special and that any special considerations you call out probably do not apply to them. They would be surprised to find that the right solution for them would be to start from your recommendation of as few mechanisms as possible and end up at tls+sasl with no restrictions on the mechanisms they should be using. Yet that's the right solution for that case. Your document needs to be sufficiently clear that people are not surprised when they end up so far away from what you claim as an ideal. Finally, you need to make it clear that people need to follow the architectural requirements of any frameworks they are using. That means in the case of most of our frameworks not introducing arbitrary limits on what mechanisms can be used. --Sam From pekkas@netcore.fi Tue Apr 25 01:19:43 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3P5Jh8G014836 for ; Tue, 25 Apr 2006 01:19:43 -0400 Received: from netcore.fi (netcore.fi [193.94.160.1]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k3P5JWTG009918 for ; Tue, 25 Apr 2006 01:19:32 -0400 (EDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060308/8.12.11) with ESMTP id k3P5HBAa022986; Tue, 25 Apr 2006 08:17:11 +0300 Date: Tue, 25 Apr 2006 08:17:11 +0300 (EEST) From: Pekka Savola To: David McGrew In-Reply-To: Message-ID: References: <7.0.0.16.2.20060420095609.06191b18@vigilsec.com> <867j5jzoo3.fsf@raman.networkresonance.com> <1B8D8BD9-15CF-47E6-A32E-34114F96DE23@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.1/1424/Mon Apr 24 17:39:06 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on otso.netcore.fi X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Russ Housley Subject: Re: [saag] Fwd: draft-bonica-tcp-auth X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2006 05:19:43 -0000 On Mon, 24 Apr 2006, David McGrew wrote: >> The need to change the keys is based on other factors (such as, an >> employee leaving the company) rather than a fear of crypthographic >> brute-forcing. > > I agree that these operational access control issues often cause > operators to need to change keys. These issues aren't addressed in > the draft that I'd mentioned, nor do I think that they should be in > scope even (can't solve every problem inside a TCP option :-) IMHO, supporting administrative re-keying without session flap is a MUST for any replacement protocol whether based on IPsec/IKE or something else. If doing so isn't reasonable in a TCP option, that's IMHO a clear indication that an option isn't "good enough". -- 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 jari.arkko@piuha.net Tue Apr 25 03:41:43 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3P7fhQk032704 for ; Tue, 25 Apr 2006 03:41:43 -0400 Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k3P7fZLk020196; Tue, 25 Apr 2006 03:41:36 -0400 (EDT) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 9D1D3898C5; Tue, 25 Apr 2006 10:41:34 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 53F5D898C4; Tue, 25 Apr 2006 10:41:34 +0300 (EEST) Message-ID: <444DD2AB.2070606@piuha.net> Date: Tue, 25 Apr 2006 10:41:31 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Hartman References: <7.0.0.16.2.20060420095609.06191b18@vigilsec.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] Fwd: draft-bonica-tcp-auth X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2006 07:41:44 -0000 Sam Hartman wrote: >Personally, I would prefer something IPsec-based to this approach. > > Ok. Has someone worked out the details of that? Is there a draft that describes how IPsec is used for this purpose, along with a discussion of how the SPD, SAD, PAD etc. are set up? I have the personal experience that often you get surprises when you try to do this... although BGP appears to be a simple case, being run over TCP on a fixed port. Are the authorization issues that one needs to worry about? If you have a router that talks to a number of BGP peers, are all peers authorized to do the same things? If not, there probably needs to be an "application" layer component in the security solution that looks at what the messages say and makes decisions, and then you need to integrate that somehow to the underlying security (maybe via IP addresses or an API). Are there data object security requirements, i.e., do you trust the peer or do you also want to know whether his information came from a trusted source? (What people have said in this thread about IPsec sounds very reasonable to me, but I the devil is often in the details, so I was wondering if the details are already available somewhere...) --Jari From hartmans@MIT.EDU Tue Apr 25 06:01:37 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3PA1a3m002495 for ; Tue, 25 Apr 2006 06:01:36 -0400 Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k3PA1Xh5023117 for ; Tue, 25 Apr 2006 06:01:33 -0400 (EDT) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id B9B81E0053; Tue, 25 Apr 2006 06:01:26 -0400 (EDT) To: Jari Arkko References: <7.0.0.16.2.20060420095609.06191b18@vigilsec.com> <444DD2AB.2070606@piuha.net> From: Sam Hartman Date: Tue, 25 Apr 2006 06:01:26 -0400 In-Reply-To: <444DD2AB.2070606@piuha.net> (Jari Arkko's message of "Tue, 25 Apr 2006 10:41:31 +0300") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 1.352 X-Spam-Level: * (1.352) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] Fwd: draft-bonica-tcp-auth X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2006 10:01:37 -0000 >>>>> "Jari" == Jari Arkko writes: Jari> Sam Hartman wrote: >> Personally, I would prefer something IPsec-based to this >> approach. >> >> Jari> Ok. Has someone worked out the details of that? Is there a Jari> draft that describes how IPsec is used for this purpose, Jari> along with a discussion of how the SPD, SAD, PAD etc. are Jari> set up? I have the personal experience that often you get Jari> surprises when you try to do this... although BGP appears to Jari> be a simple case, being run over TCP on a fixed port. The issue in my mind is that the implementers and operators have said they cannot use IPsec for non-protocol issues. The implementations don't currently support using IPsec for control traffic. So, it may well be a non-starter. I want to see the problem solved far more than I want to see it solved with IPsec. But if I were starting from a clean slate I would prefer IPsec. From pekkas@netcore.fi Tue Apr 25 06:40:23 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3PAeNPA014981 for ; Tue, 25 Apr 2006 06:40:23 -0400 Received: from netcore.fi (netcore.fi [193.94.160.1]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k3PAeFRG021157; Tue, 25 Apr 2006 06:40:15 -0400 (EDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060308/8.12.11) with ESMTP id k3PAeDdN031070; Tue, 25 Apr 2006 13:40:13 +0300 Date: Tue, 25 Apr 2006 13:40:13 +0300 (EEST) From: Pekka Savola To: Jari Arkko In-Reply-To: <444DD2AB.2070606@piuha.net> Message-ID: References: <7.0.0.16.2.20060420095609.06191b18@vigilsec.com> <444DD2AB.2070606@piuha.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.1/1424/Mon Apr 24 17:39:06 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on otso.netcore.fi X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Sam Hartman Subject: Re: [saag] Fwd: draft-bonica-tcp-auth X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2006 10:40:23 -0000 On Tue, 25 Apr 2006, Jari Arkko wrote: > Sam Hartman wrote: >> Personally, I would prefer something IPsec-based to this approach. >> >> > Ok. Has someone worked out the details of that? Is there > a draft that describes how IPsec is used for this purpose, > along with a discussion of how the SPD, SAD, PAD etc. are > set up? draft-bellovin-useipsec-04.txt uses BGP as an example, though if that is (for some reason) not sufficient, the example should probably be enhanced as the doc is aiming BCP :-) -- 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 kivinen@iki.fi Tue Apr 25 07:21:53 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3PBLr0H021697 for ; Tue, 25 Apr 2006 07:21:53 -0400 Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k3PBLoA1019650; Tue, 25 Apr 2006 07:21:51 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.5.20060308/8.12.10) with ESMTP id k3PBLj4d001599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Apr 2006 14:21:45 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.5.20060308/8.12.11) id k3PBLiRo006303; Tue, 25 Apr 2006 14:21:44 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17486.1608.716952.420411@fireball.kivinen.iki.fi> Date: Tue, 25 Apr 2006 14:21:44 +0300 From: Tero Kivinen To: Sam Hartman In-Reply-To: References: <7.0.0.16.2.20060420095609.06191b18@vigilsec.com> <444DD2AB.2070606@piuha.net> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 5 min X-Total-Time: 4 min X-Spam-Score: -2.464 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Jari Arkko Subject: Re: [saag] Fwd: draft-bonica-tcp-auth X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2006 11:21:53 -0000 Sam Hartman writes: > The issue in my mind is that the implementers and operators have said > they cannot use IPsec for non-protocol issues. The implementations > don't currently support using IPsec for control traffic. So, it may > well be a non-starter. So is the draft-bonica-tcp-auth is already implemented by routers without any extra effort then? If it requires new implementations to support draft-bonica-tcp-auth then I think it would be more beneficial to fix their IPsec implementations to support protecting control traffic. There are implementations out there that can do that, there are toolkits out there to do that, I would guess it would be much faster to take existing implementation and fix that, or replace the implementation with one that support protecting control traffic, than to implement completely new protocol. > I want to see the problem solved far more than I want to see it solved > with IPsec. But if I were starting from a clean slate I would prefer > IPsec. If draft-bonica-tcp-auth is already supported by the routers without any extra implementation effort, then I do agree with you, but as far as I know it is currently just being defined as a protocol, and there are no implementations out there yet. I might be wrong also, so if there is implementations out there, then please tell so, and hopefully give some pointers to them also. -- kivinen@safenet-inc.com From jari.arkko@piuha.net Tue Apr 25 08:26:44 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3PCQiPK013108 for ; Tue, 25 Apr 2006 08:26:44 -0400 Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k3PCQaT7004963; Tue, 25 Apr 2006 08:26:36 -0400 (EDT) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id F0C29898C4; Tue, 25 Apr 2006 15:26:34 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id A9A0A898BC; Tue, 25 Apr 2006 15:26:34 +0300 (EEST) Message-ID: <444E1577.8000806@piuha.net> Date: Tue, 25 Apr 2006 15:26:31 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola References: <7.0.0.16.2.20060420095609.06191b18@vigilsec.com> <444DD2AB.2070606@piuha.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Sam Hartman Subject: Re: [saag] Fwd: draft-bonica-tcp-auth X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2006 12:26:44 -0000 > >draft-bellovin-useipsec-04.txt uses BGP as an example, though if that >is (for some reason) not sufficient, the example should probably be >enhanced as the doc is aiming BCP :-) > > Thanks for the pointer. From a quick look at Steven's document, I think the BGP case looks simple enough. But there's also some handwavy parts about identifying AS numbers or IP addresses and tying that into other BGP policies. It could be that its easy but like I said, I prefer seeing the details worked out before believing that it actually works :-) --Jari From pekkas@netcore.fi Tue Apr 25 08:50:56 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3PCouwf018349 for ; Tue, 25 Apr 2006 08:50:56 -0400 Received: from netcore.fi (netcore.fi [193.94.160.1]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k3PColEv017760; Tue, 25 Apr 2006 08:50:48 -0400 (EDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060308/8.12.11) with ESMTP id k3PCocvn002468; Tue, 25 Apr 2006 15:50:38 +0300 Date: Tue, 25 Apr 2006 15:50:38 +0300 (EEST) From: Pekka Savola To: Tero Kivinen In-Reply-To: <17486.1608.716952.420411@fireball.kivinen.iki.fi> Message-ID: References: <7.0.0.16.2.20060420095609.06191b18@vigilsec.com> <444DD2AB.2070606@piuha.net> <17486.1608.716952.420411@fireball.kivinen.iki.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.1/1424/Mon Apr 24 17:39:06 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on otso.netcore.fi X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Jari Arkko , Sam Hartman Subject: [saag] IPsec spec problems X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2006 12:50:56 -0000 On Tue, 25 Apr 2006, Tero Kivinen wrote: > So is the draft-bonica-tcp-auth is already implemented by routers > without any extra effort then? It is not generally implemented. IPsec for control plane protection has been implemented (e.g., for OSPFv3 protection), but I'm not sure how widely. Below is a digress on IPsec spec shortcomings.. > If it requires new implementations to support draft-bonica-tcp-auth > then I think it would be more beneficial to fix their IPsec > implementations to support protecting control traffic. There are > implementations out there that can do that, there are toolkits out > there to do that, I would guess it would be much faster to take > existing implementation and fix that, or replace the implementation > with one that support protecting control traffic, than to implement > completely new protocol. How about "fix the IPsec spec"? :-) I actually read RFC 4301 for the first time on a plane (for the record, I had not read any IPsec RFCs previously). The situation was much worse than I thought. One could say that the IPsec spec is not optimized for control plane protection with all of its crazy talk about protected/unprotected interfaces, non-native implementations, etc. My perception is that IPsec spec tries to address too many problems (minimal firewall policing through SPDs; control traffic protection; VPN protection), and the result is too complex that it isn't useful for anything except VPNs, and even that's pretty complicated due to all the baggage. I was also boggled by the notion that an IPsec implementation at a router would have to inspect ALL packets it forwards (whether IPsec or not) against SPD. That means IPsec would need to be implemented on all the linecards even if all you wanted is to protect the control plane. Saner alternative: whether to look for SPDs for particular packet should be keyed off from the routing table entries. That way IPsec is only consulted when it needs to be consulted. -- 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 kivinen@iki.fi Tue Apr 25 09:22:47 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3PDMjhE024795 for ; Tue, 25 Apr 2006 09:22:45 -0400 Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k3PDMfeY025368; Tue, 25 Apr 2006 09:22:42 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.5.20060308/8.12.10) with ESMTP id k3PDMa6p018555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Apr 2006 16:22:36 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.5.20060308/8.12.11) id k3PDMZSs009288; Tue, 25 Apr 2006 16:22:35 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17486.8859.889057.470740@fireball.kivinen.iki.fi> Date: Tue, 25 Apr 2006 16:22:35 +0300 From: Tero Kivinen To: Pekka Savola In-Reply-To: References: <7.0.0.16.2.20060420095609.06191b18@vigilsec.com> <444DD2AB.2070606@piuha.net> <17486.1608.716952.420411@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 17 min X-Total-Time: 16 min X-Spam-Score: -2.464 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Sam Hartman , Jari Arkko Subject: [saag] IPsec spec problems X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2006 13:22:47 -0000 Pekka Savola writes: > I actually read RFC 4301 for the first time on a plane (for the > record, I had not read any IPsec RFCs previously). The situation was > much worse than I thought. One could say that the IPsec spec is not > optimized for control plane protection with all of its crazy talk > about protected/unprotected interfaces, non-native implementations, > etc. The architecture document describes all possible ways you could use IPsec in various different places. For the control plane prorection you should concentrate on the host-to-host case, i.e. transport mode cases. Router protecting traffic originating to/from itself is considered as host in that case not as security gateway. I.e. see section 4.1 where it says o Where traffic is destined for a security gateway, e.g., Simple Network Management Protocol (SNMP) commands, the security gateway is acting as a host and transport mode is allowed. In this case, the SA terminates at a host (management) function within a security gateway and thus merits different treatment. > My perception is that IPsec spec tries to address too many problems > (minimal firewall policing through SPDs; control traffic protection; > VPN protection), and the result is too complex that it isn't useful > for anything except VPNs, and even that's pretty complicated due to > all the baggage. If you only implement control plane protection, i.e. host to host IPsec with transport mode, there is things you do not have to implement. If you want to combine both control plane protection (host to host IPsec) and security gateway features (i.e. VPN usage) then you need to implement more of the architecture described in the rfc4301. > I was also boggled by the notion that an IPsec implementation at a > router would have to inspect ALL packets it forwards (whether IPsec or > not) against SPD. That means IPsec would need to be implemented on > all the linecards even if all you wanted is to protect the control > plane. > > Saner alternative: whether to look for SPDs for particular packet > should be keyed off from the routing table entries. That way IPsec is > only consulted when it needs to be consulted. There is no reason why the SPD cannot be combined with the routing table as you described above. The SAD/SPD etc are used to describe how the system looks from the outside. The internal implementation can be completely different provided that to the outsider it can offer similar properties than the model described in the architecture document. I.e. it is completely ok to implement the SPD DISCARD rules in IP firewall module, which supports required actions, i.e. has at least the mandatory selectors and allows you to drop packets based on that. Same thing with BYPASS. There are some complications as the SPD is ordered but those can be taken care of for example by using decorrelation. Important thing about the RFC4301 is: The model described below is nominal; implementations need not match details of this model as presented, but the external behavior of implementations MUST correspond to the externally observable characteristics of this model in order to be compliant. -- kivinen@safenet-inc.com From Pasi.Eronen@nokia.com Tue Apr 25 09:43:25 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3PDhPLY028325 for ; Tue, 25 Apr 2006 09:43:25 -0400 Received: from mgw-ext11.nokia.com (mgw-ext11.nokia.com [131.228.20.170]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k3PDhGsJ003752 for ; Tue, 25 Apr 2006 09:43:17 -0400 (EDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k3PDeETe030651 for ; Tue, 25 Apr 2006 16:40:14 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Apr 2006 16:43:16 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Apr 2006 16:43:16 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 25 Apr 2006 16:43:12 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] IPsec spec problems Thread-Index: AcZoZ7YbEX55il6ZQOaazTobPXk5TwAAeSsA From: To: X-OriginalArrivalTime: 25 Apr 2006 13:43:16.0019 (UTC) FILETIME=[34531830:01C6686E] X-Spam-Score: -1.638 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id k3PDhPLY028325 Subject: Re: [saag] IPsec spec problems X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2006 13:43:25 -0000 Pekka Savola wrote: > > I actually read RFC 4301 for the first time on a plane (for the > record, I had not read any IPsec RFCs previously). The situation was > much worse than I thought. One could say that the IPsec spec is not > optimized for control plane protection with all of its crazy talk > about protected/unprotected interfaces, non-native implementations, > etc. > > My perception is that IPsec spec tries to address too many problems > (minimal firewall policing through SPDs; control traffic protection; > VPN protection), and the result is too complex that it isn't useful > for anything except VPNs, and even that's pretty complicated due to > all the baggage. > > I was also boggled by the notion that an IPsec implementation at a > router would have to inspect ALL packets it forwards (whether > IPsec or not) against SPD. That means IPsec would need to be > implemented on all the linecards even if all you wanted is to protect > the control plane. > > Saner alternative: whether to look for SPDs for particular packet > should be keyed off from the routing table entries. That way IPsec is > only consulted when it needs to be consulted. The situation is not this bad. Yes, you're required to inspect all packets crossing the IPsec boundary (between unprotected and protected interfaces), but where exactly this boundary is placed can vary. In a router that uses IPsec only for its control traffic (and thus is really a host instead of a gateway from IPsec perspective), the protected interface could be the part of the stack delivering packets to/from local control plane daemons. Thus, packets simply being forwarded by line cards would not cross the IPsec boundary at all. But yes, things get more complicated if the router also does IPsec for forwarded packets... although you might simplify things if you consider the router to have multiple logically separate IPsec implementations (as suggested in Section 3.3 of RFC 4301). Best regards, Pasi From ekr@networkresonance.com Tue Apr 25 10:11:24 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3PEBNcW004755 for ; Tue, 25 Apr 2006 10:11:23 -0400 Received: from raman.networkresonance.com (raman.networkresonance.com [198.144.196.3]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k3PEBGC2002166 for ; Tue, 25 Apr 2006 10:11:17 -0400 (EDT) Received: by raman.networkresonance.com (Postfix, from userid 1001) id D98611E8C1F; Tue, 25 Apr 2006 07:11:15 -0700 (PDT) To: Pekka Savola References: <7.0.0.16.2.20060420095609.06191b18@vigilsec.com> <867j5jzoo3.fsf@raman.networkresonance.com> <1B8D8BD9-15CF-47E6-A32E-34114F96DE23@cisco.com> From: Eric Rescorla Date: Tue, 25 Apr 2006 07:11:15 -0700 In-Reply-To: (Pekka Savola's message of "Tue, 25 Apr 2006 08:17:11 +0300 (EEST)") Message-ID: <86aca9iw3g.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, David McGrew , Russ Housley Subject: Re: [saag] Fwd: draft-bonica-tcp-auth X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Reply-To: EKR List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2006 14:11:24 -0000 Pekka Savola writes: > On Mon, 24 Apr 2006, David McGrew wrote: >>> The need to change the keys is based on other factors (such as, an >>> employee leaving the company) rather than a fear of crypthographic >>> brute-forcing. >> >> I agree that these operational access control issues often cause >> operators to need to change keys. These issues aren't addressed in >> the draft that I'd mentioned, nor do I think that they should be in >> scope even (can't solve every problem inside a TCP option :-) > > IMHO, supporting administrative re-keying without session flap is a > MUST for any replacement protocol whether based on IPsec/IKE or > something else. I think you need to be more clear about what you think the security and operational requirement/scenario is here. Let's take a step back. We've got a pair (for convenience) of routers: A and B. They share a key (K1) and establish a connection C1 using K1 as the establishing key for (I'm being intentionally vague about what establishing means for reasons that will become apparent in a bit). At some point, an employee leaves the operator of A and you'd like to change to key K2. Any disagreements so far? At this point, a number of things could happen operationally: 1. Connection C1 is unchanged but any new connections (C2, C3...) are established using K2. 2. Connection C1 is torn down and replaced with a new connection estbalished using K2. 3. Connection C1 is kept up but somehow we arrange for it to be "re-established" (there's that fuzziness about established again) using K2. This obviously means a more complicated protocol. Similarly from a security perspective, we could desire a number of different properties: 1. That someone who had access to K1 (but not K2) cannot interfere with/forge/etc. new connections. 2. That someone who had access to K1 cannot interfere with C1 after key rollover. 3. That someone who had access to K1 cannot interfere with C1 without internal level access to the implementation. This last one is the most complicated and accounts for the confusion over "established". The idea here is that you use K1 to authenticate a DH exchange so that the traffic keys aren't directly available to the attacker (though of course they are available in the router somewhere unless you have an HSM, but you can make it so you can't extract them via the router UI). So, can someone closer to the problem discuss what operational scenarios they can live with and which security properties they think are required? -Ekr From nw141292@binky.Central.Sun.COM Tue Apr 25 12:12:40 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3PGCe6p028994 for ; Tue, 25 Apr 2006 12:12:40 -0400 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k3PGCT0Q019536; Tue, 25 Apr 2006 12:12:30 -0400 (EDT) Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k3PGCTrM011254; Tue, 25 Apr 2006 09:12:29 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k3PGCScc010822; Tue, 25 Apr 2006 10:12:28 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k3PGCL3E004712; Tue, 25 Apr 2006 11:12:21 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k3PGCKXN004711; Tue, 25 Apr 2006 11:12:20 -0500 (CDT) Date: Tue, 25 Apr 2006 11:12:20 -0500 From: Nicolas Williams To: Pekka Savola Message-ID: <20060425161219.GR4000@binky.Central.Sun.COM> References: <7.0.0.16.2.20060420095609.06191b18@vigilsec.com> <444DD2AB.2070606@piuha.net> <17486.1608.716952.420411@fireball.kivinen.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Sam Hartman , Jari Arkko , Tero Kivinen Subject: Re: [saag] IPsec spec problems X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2006 16:12:40 -0000 On Tue, Apr 25, 2006 at 03:50:38PM +0300, Pekka Savola wrote: > My perception is that IPsec spec tries to address too many problems > (minimal firewall policing through SPDs; control traffic protection; > VPN protection), and the result is too complex that it isn't useful > for anything except VPNs, and even that's pretty complicated due to > all the baggage. Basically, without the APIs being discussed in the BTNS WG all IPsec does well is VPN. > I was also boggled by the notion that an IPsec implementation at a > router would have to inspect ALL packets it forwards (whether IPsec or > not) against SPD. That means IPsec would need to be implemented on > all the linecards even if all you wanted is to protect the control > plane. > > Saner alternative: whether to look for SPDs for particular packet > should be keyed off from the routing table entries. That way IPsec is > only consulted when it needs to be consulted. Er, I think RFC4301 actually allows this with its talk of decorrelated policy. Also, if you had only a BTNS PAD entry and were only doing application-driven end-to-end IPsec then you'd not have to consult the SPD for every incoming packet. Nico -- From mcgrew@cisco.com Tue Apr 25 12:20:05 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3PGK5YO030663 for ; Tue, 25 Apr 2006 12:20:05 -0400 Received: from test-iport-3.cisco.com (test-iport-3.cisco.com [171.71.176.78]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k3PGJwgF003963 for ; Tue, 25 Apr 2006 12:19:58 -0400 (EDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by test-iport-3.cisco.com with ESMTP; 25 Apr 2006 09:19:58 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k3PGJoRf008391; Tue, 25 Apr 2006 09:19:57 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Apr 2006 09:19:54 -0700 Received: from [192.168.1.100] ([10.32.254.210]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Apr 2006 09:19:53 -0700 In-Reply-To: References: <7.0.0.16.2.20060420095609.06191b18@vigilsec.com> <867j5jzoo3.fsf@raman.networkresonance.com> <1B8D8BD9-15CF-47E6-A32E-34114F96DE23@cisco.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: David McGrew Date: Tue, 25 Apr 2006 09:19:52 -0700 To: Pekka Savola X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 25 Apr 2006 16:19:54.0064 (UTC) FILETIME=[15FEF500:01C66884] X-Spam-Score: -2.4 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Russ Housley Subject: Re: [saag] Fwd: draft-bonica-tcp-auth X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2006 16:20:05 -0000 Pekka, On Apr 24, 2006, at 10:17 PM, Pekka Savola wrote: > > On Mon, 24 Apr 2006, David McGrew wrote: >>> The need to change the keys is based on other factors (such as, an >>> employee leaving the company) rather than a fear of crypthographic >>> brute-forcing. >> >> I agree that these operational access control issues often cause >> operators to need to change keys. These issues aren't addressed in >> the draft that I'd mentioned, nor do I think that they should be in >> scope even (can't solve every problem inside a TCP option :-) > > IMHO, supporting administrative re-keying without session flap is a > MUST for any replacement protocol whether based on IPsec/IKE or > something else. If doing so isn't reasonable in a TCP option, > that's IMHO a clear indication that an option isn't "good enough". I agree completely! What I'd meant is that the distribution of long- term keys should be out of scope for the TCP option. David From pekkas@netcore.fi Tue Apr 25 12:45:34 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3PGjYob006323 for ; Tue, 25 Apr 2006 12:45:34 -0400 Received: from netcore.fi (netcore.fi [193.94.160.1]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k3PGjPwW021488 for ; Tue, 25 Apr 2006 12:45:26 -0400 (EDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060308/8.12.11) with ESMTP id k3PGjKk4007783; Tue, 25 Apr 2006 19:45:21 +0300 Date: Tue, 25 Apr 2006 19:45:20 +0300 (EEST) From: Pekka Savola To: Eric Rescorla In-Reply-To: <86aca9iw3g.fsf@raman.networkresonance.com> Message-ID: References: <7.0.0.16.2.20060420095609.06191b18@vigilsec.com> <867j5jzoo3.fsf@raman.networkresonance.com> <1B8D8BD9-15CF-47E6-A32E-34114F96DE23@cisco.com> <86aca9iw3g.fsf@raman.networkresonance.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.1/1424/Mon Apr 24 17:39:06 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_05,NO_RELAYS autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on otso.netcore.fi X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, David McGrew , Russ Housley Subject: Re: [saag] Fwd: draft-bonica-tcp-auth X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2006 16:45:34 -0000 On Tue, 25 Apr 2006, Eric Rescorla wrote: > Let's take a step back. We've got a pair (for convenience) of routers: > A and B. They share a key (K1) and establish a connection C1 using K1 > as the establishing key for (I'm being intentionally vague about what > establishing means for reasons that will become apparent in a bit). > > At some point, an employee leaves the operator of A and you'd like > to change to key K2. Any disagreements so far? Fully agreed. > At this point, a number of things could happen operationally: > > 1. Connection C1 is unchanged but any new connections (C2, C3...) > are established using K2. > 2. Connection C1 is torn down and replaced with a new connection > estbalished using K2. > 3. Connection C1 is kept up but somehow we arrange for > it to be "re-established" (there's that fuzziness about > established again) using K2. This obviously means a > more complicated protocol. Yes, my point is that unless the new protocol (or new application of existing protocols) is able to do 3., it isn't sufficiently useful to be worth doing or adopting. > Similarly from a security perspective, we could desire a number > of different properties: > > 1. That someone who had access to K1 (but not K2) cannot interfere > with/forge/etc. new connections. > 2. That someone who had access to K1 cannot interfere with C1 > after key rollover. > 3. That someone who had access to K1 cannot interfere with C1 > without internal level access to the implementation. > This last one is the most complicated and accounts for the > confusion over "established". The idea here is that you use > K1 to authenticate a DH exchange so that the traffic > keys aren't directly available to the attacker (though of > course they are available in the router somewhere > unless you have an HSM, but you can make it so you can't > extract them via the router UI). >From the operational point of view, I think both 2 and 3 are OK. That is, if you use a password (K1) to kick off a DH (or some other) exchange, but you aren't able to see the actual DH keys [1] that should be OK. I don't claim perfect knowledge on all the ISPs' security requirements in this regard. Well protected ISPs don't need to use TCP-MD5 all that much in any case (mainly in Internet Exchanges, where the attack vector can be easily restricted to the IX link fabric). This is described in: draft-savola-rtgwg-backbone-attacks-00.txt [1] But how could you see the DH keys? Would it require looking at the memory of the router (root/kernel level access)? That would be a sufficiently high bar. If something would be exchanged on the wire in plain text (doubt it) or available through debugging commands, it might or might not be good enough. -- 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 ekr@networkresonance.com Tue Apr 25 13:19:24 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3PHJOwP016952 for ; Tue, 25 Apr 2006 13:19:24 -0400 Received: from raman.networkresonance.com (raman.networkresonance.com [198.144.196.3]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k3PHJHZK029991 for ; Tue, 25 Apr 2006 13:19:17 -0400 (EDT) Received: by raman.networkresonance.com (Postfix, from userid 1001) id AB6191E8C1F; Tue, 25 Apr 2006 10:19:14 -0700 (PDT) To: Pekka Savola References: <7.0.0.16.2.20060420095609.06191b18@vigilsec.com> <867j5jzoo3.fsf@raman.networkresonance.com> <1B8D8BD9-15CF-47E6-A32E-34114F96DE23@cisco.com> <86aca9iw3g.fsf@raman.networkresonance.com> From: Eric Rescorla Date: Tue, 25 Apr 2006 10:19:14 -0700 In-Reply-To: (Pekka Savola's message of "Tue, 25 Apr 2006 19:45:20 +0300 (EEST)") Message-ID: <8664kxine5.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, David McGrew , Russ Housley Subject: Re: [saag] Fwd: draft-bonica-tcp-auth X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Reply-To: EKR List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2006 17:19:24 -0000 Pekka Savola writes: > On Tue, 25 Apr 2006, Eric Rescorla wrote: >> At this point, a number of things could happen operationally: >> >> 1. Connection C1 is unchanged but any new connections (C2, C3...) >> are established using K2. >> 2. Connection C1 is torn down and replaced with a new connection >> estbalished using K2. >> 3. Connection C1 is kept up but somehow we arrange for >> it to be "re-established" (there's that fuzziness about >> established again) using K2. This obviously means a >> more complicated protocol. > > Yes, my point is that unless the new protocol (or new application of > existing protocols) is able to do 3., it isn't sufficiently useful to > be worth doing or adopting. OK. That seems like a key requirement. I'm ultimately willing to take your word for it, but I'd just like to push on it a little bit. Do employees really leave so often that it's a real hardship to just bounce the connection? > [1] But how could you see the DH keys? Would it require looking at > the memory of the router (root/kernel level access)? That would be a > sufficiently high bar. If something would be exchanged on the wire in > plain text (doubt it) or available through debugging commands, it > might or might not be good enough. Right. What I'm assuming is that the DH private keys would be stored in operating system memory and there wouldn't be a trivial call to get them out again. The DH public keys are of course on the wire, but that's fine. OTOH, you could argue that if you had a PK system for establishing the long-term symmetric keys you could apply the same logic to the symmetric keys, no? Just trying to work through the logic.... -Ekr From nw141292@binky.Central.Sun.COM Tue Apr 25 13:43:38 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3PHhcrB023397 for ; Tue, 25 Apr 2006 13:43:38 -0400 Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k3PHhViV015103 for ; Tue, 25 Apr 2006 13:43:32 -0400 (EDT) Received: from centralmail2brm.Central.Sun.COM (centralmail2brm.central.sun.com [129.147.62.14]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k3PHhTaN014033 for ; Tue, 25 Apr 2006 11:43:29 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k3PHhSdc010158 for ; Tue, 25 Apr 2006 11:43:29 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k3PHhSju004898; Tue, 25 Apr 2006 12:43:28 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k3PHhRdS004897; Tue, 25 Apr 2006 12:43:27 -0500 (CDT) Date: Tue, 25 Apr 2006 12:43:27 -0500 From: Nicolas Williams To: Eric Rescorla Message-ID: <20060425174327.GZ4000@binky.Central.Sun.COM> References: <7.0.0.16.2.20060420095609.06191b18@vigilsec.com> <867j5jzoo3.fsf@raman.networkresonance.com> <1B8D8BD9-15CF-47E6-A32E-34114F96DE23@cisco.com> <86aca9iw3g.fsf@raman.networkresonance.com> <8664kxine5.fsf@raman.networkresonance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8664kxine5.fsf@raman.networkresonance.com> User-Agent: Mutt/1.5.7i X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, David McGrew , Russ Housley , Pekka Savola Subject: Re: [saag] Fwd: draft-bonica-tcp-auth X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2006 17:43:38 -0000 On Tue, Apr 25, 2006 at 10:19:14AM -0700, Eric Rescorla wrote: > Right. What I'm assuming is that the DH private keys would be stored > in operating system memory and there wouldn't be a trivial call to > get them out again. The DH public keys are of course on the wire, > but that's fine. > > OTOH, you could argue that if you had a PK system for establishing > the long-term symmetric keys you could apply the same logic to > the symmetric keys, no? You might make a distinction between ephemeral DH keys that can be re-used for re-keying and session symmetric keys -- the first might live on a token, the second might not. But I think enterprises need to trust the OSes they run, and so there should be no need to change symmetric session keys because an employee left/was fired unless that employee was supposed to have the kind of access needed to retrieve them. But anyways, I think more TCP authentication is a bad idea. Use IPsec. Nico -- From kent@bbn.com Wed Apr 26 01:49:00 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3Q5n0PW001888 for ; Wed, 26 Apr 2006 01:49:00 -0400 Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k3Q5mrwj005534; Wed, 26 Apr 2006 01:48:53 -0400 (EDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[193.0.9.53]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1FYctR-0000oT-3j; Wed, 26 Apr 2006 01:48:53 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <444DD2AB.2070606@piuha.net> References: <7.0.0.16.2.20060420095609.06191b18@vigilsec.com> <444DD2AB.2070606@piuha.net> Date: Tue, 25 Apr 2006 04:12:21 -0400 To: Jari Arkko From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: -1.352 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Sam Hartman Subject: Re: [saag] Fwd: draft-bonica-tcp-auth X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2006 05:49:00 -0000 At 10:41 AM +0300 4/25/06, Jari Arkko wrote: >Sam Hartman wrote: > >>Personally, I would prefer something IPsec-based to this approach. >> >> >Ok. Has someone worked out the details of that? Is there >a draft that describes how IPsec is used for this purpose, >along with a discussion of how the SPD, SAD, PAD etc. are >set up? I have the personal experience that often you get >surprises when you try to do this... although BGP appears >to be a simple case, being run over TCP on a fixed port. one contributor on the RPSEC list said that he had looked at the config issues in detail and said that is was straightforward. the PAD details will depend on the authentication approach adopted by consenting ISP neighbors. the SPD needs to protect BGP traffic, but other traffic would be bypassed, e.g., SNMP and Kerberos or SSL-protected Telnet (which may be used for management). Remember that the security boundary here is for the management processor in the router, not for subscriber traffic. >Are the authorization issues that one needs to worry about? >If you have a router that talks to a number of BGP peers, are >all peers authorized to do the same things? not at the application layer, but the requirement here seems to be that each peer be correctly identified when its traffic arrives, an obvious IPsec integrity and authentication function. That's the level of authorization that makes sense to enforce at the IP layer. > If not, there >probably needs to be an "application" layer component >in the security solution that looks at what the messages >say and makes decisions, and then you need to integrate >that somehow to the underlying security (maybe via IP >addresses or an API). Are there data object security >requirements, i.e., do you trust the peer or do you also >want to know whether his information came from a >trusted source? IPsec is not a way to address transitive, application layer security issues. S-BGP,soBGP etc. are application layer security proposals for BGP. Steve From kent@bbn.com Wed Apr 26 07:51:15 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3QBpF1Q003319 for ; Wed, 26 Apr 2006 07:51:15 -0400 Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k3QBpEfm016228 for ; Wed, 26 Apr 2006 07:51:14 -0400 (EDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[193.0.9.53]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1FYiY5-0001yp-4f; Wed, 26 Apr 2006 07:51:13 -0400 Mime-Version: 1.0 Message-Id: Date: Wed, 26 Apr 2006 07:51:09 -0400 To: Pekka Savola From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: [saag] IPsec spec problems X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2006 11:51:15 -0000 Pekka, I think you seriously misread 4301, perhaps because, as you note, you have never read any IPsec RFCs previously. You are right that "IPsec spec is not optimized for control plane protection." The discussion of the IPsec boundary and the other features you criticized is far from "crazy talk;" they are directly applicable to the BGP security context. Specifically, one would want to define the boundary around a router's management processing, because the goal is to control which traffic flows across this boundary, and to ensure protection for BGP sessions. All of the examples you cited in your criticism "IPsec spec tries to address too many problems? are related. IPsec applies crypto-security to traffic on a selected basis, and that, in turn, requires an access control function directed by the SPD. Otherwise, one cannot reliably apply the crypto-security, cannot know what traffic is to be bypassed, etc. Also, IPsec is designed as THE IP layer security facility, so it needs to accommodate end system and intermediate system application contexts, which mandates the inclusion of features that you seem to think are excess baggage. Your assumption "that an IPsec implementation at a router would have to inspect ALL packets it forwards ..." is wrong, IF the goal is to protect BGP traffic originating and terminating at the router. Section 3.3 in RFC 4301 says "A security gateway might employ separate IPsec implementations to protect its management traffic and subscriber traffic." By defining the security boundary to encompass the management process in a router, but not the traffic forwarding function, there is no need to inspect ALL packets ... There is no need to consult routing table entries to decide what traffic is subjected to IPsec protection when the goal is BGP session security between a pair of border routers. if one also wants to protect subscriber traffic, then a separate security boundary is defined for that function and a separate implementation of IPsec might be employed for that high volume use. I think Tero's response was way too polite given your broad, largely inaccurate criticisms of a document that you appear to have not read very closely. Steve From pekkas@netcore.fi Wed Apr 26 08:34:38 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3QCYcZL021458 for ; Wed, 26 Apr 2006 08:34:38 -0400 Received: from netcore.fi (netcore.fi [193.94.160.1]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k3QCYVbr021807 for ; Wed, 26 Apr 2006 08:34:31 -0400 (EDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060308/8.12.11) with ESMTP id k3QCYOjk001258; Wed, 26 Apr 2006 15:34:24 +0300 Date: Wed, 26 Apr 2006 15:34:24 +0300 (EEST) From: Pekka Savola To: Eric Rescorla In-Reply-To: <8664kxine5.fsf@raman.networkresonance.com> Message-ID: References: <7.0.0.16.2.20060420095609.06191b18@vigilsec.com> <867j5jzoo3.fsf@raman.networkresonance.com> <1B8D8BD9-15CF-47E6-A32E-34114F96DE23@cisco.com> <86aca9iw3g.fsf@raman.networkresonance.com> <8664kxine5.fsf@raman.networkresonance.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.1/1425/Tue Apr 25 15:09:41 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on otso.netcore.fi X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, David McGrew , Russ Housley Subject: Re: [saag] Fwd: draft-bonica-tcp-auth X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2006 12:34:38 -0000 On Tue, 25 Apr 2006, Eric Rescorla wrote: >>> 3. Connection C1 is kept up but somehow we arrange for >>> it to be "re-established" (there's that fuzziness about >>> established again) using K2. This obviously means a >>> more complicated protocol. >> >> Yes, my point is that unless the new protocol (or new application of >> existing protocols) is able to do 3., it isn't sufficiently useful to >> be worth doing or adopting. > > OK. That seems like a key requirement. I'm ultimately willing to take > your word for it, but I'd just like to push on it a little bit. > Do employees really leave so often that it's a real hardship > to just bounce the connection? We don't have this problem, as the attack vector (when GTSM is used, IP spoofing prevention is employed, etc.) is basically just a single single link -- the Internet Exchange point. So I'm just reporting what I've heard from bigger ISPs, and I welcome corrections on this: The number of people who have access to configure peering session keys or to look at the router configuration is so large (in the order of multiple dozens, if not a hundred, people) that there's definitely some annual (and even monthly) turnover there. (I believe most ISPs don't currently change the keys under these circumstances, just complain that they'd like to be able to do so without disruption..) While service windows (e.g., upgrading the router software version) may require bouncing the session sometimes (e.g., 0.5-2 times a year), I'm told that in most cases the difference between the next (yet unscheduled) software upgrade and the need to change the keying material could grow rather long. There are also mechanisms like BGP graceful restart which obviate the need of session resets under certain conditions even with software upgrades. So, my personal take here is, that we either: 1) do something that can deal without disruptionless key changes (i.e., if we need to design something new, it doesn't seem to make sense to go only 1/3 or half the way), or 2) we do nothing, i.e., accept that the need is not great enough and the attack vector is extremely small for well-managed networks. Hope this helps -- I fear I'm not able to provide more reasoning. -- 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 hartmans@MIT.EDU Wed Apr 26 13:25:30 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3QHPU9h017837 for ; Wed, 26 Apr 2006 13:25:30 -0400 Received: from carter-zimmerman.mit.edu (carter-zimmerman.dyn.mit.edu [18.188.3.148]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k3QHNePI020017 for ; Wed, 26 Apr 2006 13:24:57 -0400 (EDT) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 7E202E0053; Wed, 26 Apr 2006 13:23:34 -0400 (EDT) To: Stephen Kent References: <7.0.0.16.2.20060420095609.06191b18@vigilsec.com> <444DD2AB.2070606@piuha.net> From: Sam Hartman Date: Wed, 26 Apr 2006 13:23:34 -0400 In-Reply-To: (Stephen Kent's message of "Tue, 25 Apr 2006 04:12:21 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 1.217 X-Spam-Level: * (1.217) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Jari Arkko Subject: Re: [saag] Fwd: draft-bonica-tcp-auth X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2006 17:25:30 -0000 >>>>> "Stephen" == Stephen Kent writes: Stephen> At 10:41 AM +0300 4/25/06, Jari Arkko wrote: >> Sam Hartman wrote: >>> Personally, I would prefer something IPsec-based to this >>> approach. >>> >>> >> Ok. Has someone worked out the details of that? Is there a >> draft that describes how IPsec is used for this purpose, along >> with a discussion of how the SPD, SAD, PAD etc. are set up? I >> have the personal experience that often you get surprises when >> you try to do this... although BGP appears to be a simple case, >> being run over TCP on a fixed port. Stephen> one contributor on the RPSEC list said that he had looked Stephen> at the config issues in detail and said that is was Stephen> straightforward. the PAD details will depend on the Stephen> authentication approach adopted by consenting ISP Stephen> neighbors. the SPD needs to protect BGP traffic, but Stephen> other traffic would be bypassed, e.g., SNMP and Kerberos Stephen> or SSL-protected Telnet (which may be used for Stephen> management). Remember that the security boundary here is Stephen> for the management processor in the router, not for Stephen> subscriber traffic. I have a bit of a concern with this boundary. In addition to describing this you somehow need to mandate that even if the box can also act as a security gateway (presumably with a different boundary) it can also act according to your spec. I.E. a box with one IPsec implementation and where I configure each real interface either protected or not protected needs to fail some requirement of the spec detailing how to use IPsec for BGP. From kent@bbn.com Wed Apr 26 16:13:55 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3QKDtUO014760 for ; Wed, 26 Apr 2006 16:13:55 -0400 Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k3QKDhlJ028970; Wed, 26 Apr 2006 16:13:43 -0400 (EDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[193.0.9.249]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1FYqOM-0000HR-6P; Wed, 26 Apr 2006 16:13:43 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <7.0.0.16.2.20060420095609.06191b18@vigilsec.com> <444DD2AB.2070606@piuha.net> Date: Wed, 26 Apr 2006 16:13:38 -0400 To: Sam Hartman From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Jari Arkko Subject: Re: [saag] Fwd: draft-bonica-tcp-auth X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2006 20:13:55 -0000 A >... > > Stephen> one contributor on the RPSEC list said that he had looked > Stephen> at the config issues in detail and said that is was > Stephen> straightforward. the PAD details will depend on the > Stephen> authentication approach adopted by consenting ISP > Stephen> neighbors. the SPD needs to protect BGP traffic, but > Stephen> other traffic would be bypassed, e.g., SNMP and Kerberos > Stephen> or SSL-protected Telnet (which may be used for > Stephen> management). Remember that the security boundary here is > Stephen> for the management processor in the router, not for > Stephen> subscriber traffic. > >I have a bit of a concern with this boundary. > >In addition to describing this you somehow need to mandate that even >if the box can also act as a security gateway (presumably with a >different boundary) it can also act according to your spec. see the text I cited from 4301 in my message to Pekka, which states precisely that capability. >I.E. a box with one IPsec implementation and where I configure each >real interface either protected or not protected needs to fail some >requirement of the spec detailing how to use IPsec for BGP. I don't understand the "fail some requirement ..." part of your comment. For the SG (vs. management host) IPsec SPD(s) I would specify BYPASS for traffic to/from my internal management host address from the neighbor address for each interface to a border router, with a next protocol field of ESP, and OPAQUE for port selectors. That would allow the protected BGP traffic to bypass the SG protection, while still applying other SPD rules to transit traffic. Is that what you were asking? Steve From hartmans@MIT.EDU Wed Apr 26 16:37:14 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3QKbEWA019069 for ; Wed, 26 Apr 2006 16:37:14 -0400 Received: from carter-zimmerman.mit.edu (carter-zimmerman.dyn.mit.edu [18.188.3.148]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k3QKb8ld003927 for ; Wed, 26 Apr 2006 16:37:08 -0400 (EDT) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 0DDE0E0053; Wed, 26 Apr 2006 16:37:01 -0400 (EDT) To: Stephen Kent References: <7.0.0.16.2.20060420095609.06191b18@vigilsec.com> <444DD2AB.2070606@piuha.net> From: Sam Hartman Date: Wed, 26 Apr 2006 16:37:01 -0400 In-Reply-To: (Stephen Kent's message of "Wed, 26 Apr 2006 16:13:38 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 1.217 X-Spam-Level: * (1.217) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Jari Arkko Subject: Re: [saag] Fwd: draft-bonica-tcp-auth X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2006 20:37:14 -0000 >>>>> "Stephen" == Stephen Kent writes: Stephen> A >> ... >> Stephen> one contributor on the RPSEC list said that he had looked Stephen> at the config issues in detail and said that is was Stephen> straightforward. the PAD details will depend on the Stephen> authentication approach adopted by consenting ISP Stephen> neighbors. the SPD needs to protect BGP traffic, but Stephen> other traffic would be bypassed, e.g., SNMP and Kerberos Stephen> or SSL-protected Telnet (which may be used for Stephen> management). Remember that the security boundary here is Stephen> for the management processor in the router, not for Stephen> subscriber traffic. >> I have a bit of a concern with this boundary. >> >> In addition to describing this you somehow need to mandate that >> even if the box can also act as a security gateway (presumably >> with a different boundary) it can also act according to your >> spec. Stephen> see the text I cited from 4301 in my message to Pekka, Stephen> which states precisely that capability. I'm familiar with the text in question. (We've had this discussion before) It describes an implementation strategy/capability; we need to mandate that implementations of BGP IPsec either support that capability or do not support SG functionality. From kivinen@iki.fi Thu Apr 27 04:20:52 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3R8KoqF005615 for ; Thu, 27 Apr 2006 04:20:50 -0400 Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k3R8JgMa006947 for ; Thu, 27 Apr 2006 04:19:43 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.5.20060308/8.12.10) with ESMTP id k3R8JXUF012992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Apr 2006 11:19:33 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.5.20060308/8.12.11) id k3R8JUYk015409; Thu, 27 Apr 2006 11:19:30 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17488.32402.588964.965896@fireball.kivinen.iki.fi> Date: Thu, 27 Apr 2006 11:19:30 +0300 From: Tero Kivinen To: Pekka Savola In-Reply-To: References: <7.0.0.16.2.20060420095609.06191b18@vigilsec.com> <867j5jzoo3.fsf@raman.networkresonance.com> <1B8D8BD9-15CF-47E6-A32E-34114F96DE23@cisco.com> <86aca9iw3g.fsf@raman.networkresonance.com> <8664kxine5.fsf@raman.networkresonance.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 25 min X-Total-Time: 25 min X-Spam-Score: -2.464 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, David McGrew , Russ Housley Subject: Re: [saag] Fwd: draft-bonica-tcp-auth X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2006 08:20:52 -0000 Pekka Savola writes: > 1) do something that can deal without disruptionless key changes > (i.e., if we need to design something new, it doesn't seem to make > sense to go only 1/3 or half the way), or Actually the description was little too much tied to the protocol where the key exchange and the connection are tied together. For IPsec this is not the case. The connection used for the BGP (TCP or whatever) is not necessarely broken when the IPsec connection (i.e IKE and IPsec SA) is restarted. I.e. you can tear down the IPsec and IKE SA, recreate them using new keys and the old BGP connection can start to use that newly created SA to protect its traffic. You can of course also do it other way around, i.e. first establish new IPsec SAs and only after they are up and running tear down the old ones, and with that you shouldn't even lose any packets in transit. Also if it is enough that we can trust that nobody of those who have already left the company can access the internal state of the router anymore (i.e. cannot get access to the Diffie-Hellman secret data), then doing rekeying of the IPsec SA with Diffie-Hellman exchange is enough. This is normally done automatically anyways and it does not disrupt the upper level connections in any way, so you just need to configure the system to IPsec SA lifetimes of one day or so and say that you do Diffie-Hellman exchange on rekeys. The authentication secret is only used during new connection establishment, so it is enough to change it, and keep old already existing connections intact. Next time routers need to recreate connections (regardless of reason) they will use the new authentication secret, thus the attacker knowing the old authentication secret cannot connect after the secret is changed. To summary for the IPsec the policy should be something like: 1) Make sure the IPsec SA rekey interval is short enough that employees leaving and stealing keying material from the internal state of router are not problem, i.e. 8-24 hours. Also force all rekeys to use new Diffie-Hellman exhange. 2) Every time employer leaves create new authentication secrets and communicate them to the other peers, but do not reset any connections. If public keys are used instead of shared secret (no need for PKI, bare RSA keys are good enough here), then just make sure the private key is not accessable at all, i.e. created on the router, and stored there, but not exported ever from the router. The problem with shared keys is that you need the out of band method of transfering those keys from one router to another, and the people involved in that out of band transfer do know the shared secrets. This is not true with the bare RSA keys, as we only need to transfer public part of the key. Of course the other benefits for the public keys are even more important, i.e. the need to have only one key per router, not separate key for each router pair, but I do not think we need to discuss those things here now. -- kivinen@safenet-inc.com From pekkas@netcore.fi Thu Apr 27 10:55:31 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3REtVMr003647 for ; Thu, 27 Apr 2006 10:55:31 -0400 Received: from netcore.fi (netcore.fi [193.94.160.1]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k3REtAaS016915; Thu, 27 Apr 2006 10:55:11 -0400 (EDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060308/8.12.11) with ESMTP id k3RErSXo006049; Thu, 27 Apr 2006 17:53:29 +0300 Date: Thu, 27 Apr 2006 17:53:28 +0300 (EEST) From: Pekka Savola To: Tero Kivinen In-Reply-To: <17486.8859.889057.470740@fireball.kivinen.iki.fi> Message-ID: References: <7.0.0.16.2.20060420095609.06191b18@vigilsec.com> <444DD2AB.2070606@piuha.net> <17486.1608.716952.420411@fireball.kivinen.iki.fi> <17486.8859.889057.470740@fireball.kivinen.iki.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.1/1426/Wed Apr 26 21:03:01 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on otso.netcore.fi X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Jari Arkko , Sam Hartman Subject: Re: [saag] IPsec spec problems X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2006 14:55:31 -0000 On Tue, 25 Apr 2006, Tero Kivinen wrote: > The architecture document describes all possible ways you could use > IPsec in various different places. That's exactly the problem. "All possible ways" and "various different places" create an architecture which apparently needs to be ambigious and generic to accommodate all those.. and in turn, such architecture appears to be very difficult to use (i.e., a failure) in many contexts. > If you only implement control plane protection, i.e. host to host > IPsec with transport mode, there is things you do not have to > implement. If you want to combine both control plane protection (host > to host IPsec) and security gateway features (i.e. VPN usage) then you > need to implement more of the architecture described in the rfc4301. In almost all the cases, I think all major implementations need to support both. > The model described below is nominal; implementations need not > match details of this model as presented, but the external behavior > of implementations MUST correspond to the externally observable > characteristics of this model in order to be compliant. That's nice -- unfortunately, unless the motivation of IPsec folks was to make it more difficult to create new (competing) implementations, leaving out important details on what the spec actually means and what's the best way to implement things may be an issue. -- 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 wes@hardakers.net Thu Apr 27 12:11:00 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3RGB0Hd018738 for ; Thu, 27 Apr 2006 12:11:00 -0400 Received: from wes.hardakers.net (dcn236-44.dcn.davis.ca.us [168.150.236.44]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k3RGAe4E027605; Thu, 27 Apr 2006 12:10:41 -0400 (EDT) Received: by dcn236-44.dcn.davis.ca.us (Postfix, from userid 274) id 1E7DE11D624; Thu, 27 Apr 2006 09:10:32 -0700 (PDT) From: Wes Hardaker To: Tero Kivinen Organization: Sparta References: <7.0.0.16.2.20060420095609.06191b18@vigilsec.com> <444DD2AB.2070606@piuha.net> <17486.1608.716952.420411@fireball.kivinen.iki.fi> <17486.8859.889057.470740@fireball.kivinen.iki.fi> Date: Thu, 27 Apr 2006 09:10:32 -0700 In-Reply-To: <17486.8859.889057.470740@fireball.kivinen.iki.fi> (Tero Kivinen's message of "Tue, 25 Apr 2006 16:22:35 +0300") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.4.19 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.464 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Jari Arkko , Sam Hartman , Pekka Savola Subject: Re: [saag] IPsec spec problems X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2006 16:11:00 -0000 >>>>> On Tue, 25 Apr 2006 16:22:35 +0300, Tero Kivinen said: Tero> There is no reason why the SPD cannot be combined with the routing Tero> table as you described above. The SAD/SPD etc are used to describe how Tero> the system looks from the outside. The internal implementation can be Tero> completely different provided that to the outsider it can offer Tero> similar properties than the model described in the architecture Tero> document. Tero> I.e. it is completely ok to implement the SPD DISCARD rules in IP Tero> firewall module, which supports required actions, i.e. has at least Tero> the mandatory selectors and allows you to drop packets based on that. Tero> Same thing with BYPASS. There are some complications as the SPD is Tero> ordered but those can be taken care of for example by using Tero> decorrelation. Tero> Important thing about the RFC4301 is: Tero> The model described below is nominal; implementations need not Tero> match details of this model as presented, but the external behavior Tero> of implementations MUST correspond to the externally observable Tero> characteristics of this model in order to be compliant. All of these points are what make RFC4301 good in many ways: you can implement whatever you want internally as long as you have an external interface that mimics the model described in 4301. The reality, though, is worse. I've worked with multiple architectures that internally do something very different and attempted to map the internal architecture onto the 2401 or 4301 "model". It's often theoretically possible but the hoops you have to jump through are often daunting. I've worked with many vendors who fall into the same category: they routinely question why they have to have to show a prioritized a list of firewall rules when all they want internally is a routing table. The reality is that vendors that want to offer protected traffic frequently only want to implement ESP and not offer a common management view of how stuff gets into and out of those protected packets. To some extent this it would be nice if the IPsec specs were broken into on-the-wire and what-gets-sent-protected-and-when, but the reality it when it comes to security policy you need to be able to agree on what should or must get sent through a tunnel. Because of this you either have to agree on what will be sent through a tunnel, or you have to put a lot of trust in the other side that they're doing the right thing with the selectors on their side because you don't understand them. If you don't care about checking the policy of a packet coming out of a tunnel, and you only care about sending packets based on your personal policies, things are a bit easier. -- "In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find." -- Terry Pratchett From kivinen@iki.fi Fri Apr 28 04:54:31 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3S8sVWG015864 for ; Fri, 28 Apr 2006 04:54:31 -0400 Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k3S8sM50004350; Fri, 28 Apr 2006 04:54:22 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.5.20060308/8.12.10) with ESMTP id k3S8sKOx008928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Apr 2006 11:54:20 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.5.20060308/8.12.11) id k3S8sJNB003670; Fri, 28 Apr 2006 11:54:19 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17489.55355.478392.483772@fireball.kivinen.iki.fi> Date: Fri, 28 Apr 2006 11:54:19 +0300 From: Tero Kivinen To: Pekka Savola In-Reply-To: References: <7.0.0.16.2.20060420095609.06191b18@vigilsec.com> <444DD2AB.2070606@piuha.net> <17486.1608.716952.420411@fireball.kivinen.iki.fi> <17486.8859.889057.470740@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 16 min X-Total-Time: 16 min X-Spam-Score: 0.135 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Sam Hartman , Jari Arkko Subject: Re: [saag] IPsec spec problems X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2006 08:54:31 -0000 Pekka Savola writes: > > The model described below is nominal; implementations need not > > match details of this model as presented, but the external behavior > > of implementations MUST correspond to the externally observable > > characteristics of this model in order to be compliant. > > That's nice -- unfortunately, unless the motivation of IPsec folks was > to make it more difficult to create new (competing) implementations, > leaving out important details on what the spec actually means and > what's the best way to implement things may be an issue. I do not think it is IETFs work to design software architecture for the implementations. The current specification is high level enough that vendors can do software architecture in multiple different ways, but can still be compatible with the IPsec architecture document. For example in our implementations the old IPsec Express toolkit and the newer Quicksec toolkit used completely different software architecture. Neither one of those used the exact model described in the architecture draft, but both of them should be compatible with it, i.e. matching the external behavior of the architecture document. Those two toolkits were designed for quite different scenarios in mind so that do affect the high level architecture, although both of them can also be used to do the same basic things described in the IPsec architecture. If the architecture document would go in to more detailed level, then doing those kind different software architectures would be harder and harder. Anyways, there has been multiple vendors who have managed to make internoperable implementations of the IPsec, so I think that proves that the documents are matching the requirements set by the IETF. At least I think that IETFs job is not to provide detailed software architectures how to implement things, but to provide good enough documentation that people can implement interoperable implementations of the protocols. The issues in the interoperability meetings have mostly been in the bits on the wire level or just normal software bugs, I do not think there have been that many problems in the architecture issues there. Of course testing there has mostly concentrated on the bits on the wire, not to the architecture... -- kivinen@safenet-inc.com From hartmans@MIT.EDU Fri Apr 28 08:26:58 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3SCQqH9026181 for ; Fri, 28 Apr 2006 08:26:52 -0400 Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k3SCQk6m023161 for ; Fri, 28 Apr 2006 08:26:47 -0400 (EDT) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 80193E0053; Fri, 28 Apr 2006 08:26:38 -0400 (EDT) To: Tero Kivinen References: <7.0.0.16.2.20060420095609.06191b18@vigilsec.com> <444DD2AB.2070606@piuha.net> <17486.1608.716952.420411@fireball.kivinen.iki.fi> <17486.8859.889057.470740@fireball.kivinen.iki.fi> <17489.55355.478392.483772@fireball.kivinen.iki.fi> From: Sam Hartman Date: Fri, 28 Apr 2006 08:26:38 -0400 In-Reply-To: <17489.55355.478392.483772@fireball.kivinen.iki.fi> (Tero Kivinen's message of "Fri, 28 Apr 2006 11:54:19 +0300") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 1.352 X-Spam-Level: * (1.352) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Jari Arkko , Pekka Savola Subject: Re: [saag] IPsec spec problems X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2006 12:26:59 -0000 >>>>> "Tero" == Tero Kivinen writes: Tero> Anyways, there has been multiple vendors who have managed to Tero> make internoperable implementations of the IPsec, so I think Tero> that proves that the documents are matching the requirements Tero> set by the IETF. I agree that RFC 4301 matches the requirements of the IPsec working group. However while we've had multiple interoperable implementations, I cannot say we've had reasonable success within the IETF at describing the security of higher level protocols in terms of RFC 2401 or 4301. I think this is a new requirement. I don't think this indicates a bug in 4301 or 2401. I think it simply means we have new work to do. My personal view on that ork is that we need to specify a model that is more useful to protocol designers but that can be implemented in terms of 4301. I.E. we don't make changes to 4301, but we provide a conceptual model. We may end up saying that features optional in 4301 (such as multiple SPDs and an SPD selection function that considers source interfaces) are required for implementations used to secure higher layer protocols. I guess it is always possible we would find bugs in 4301 while working on that effort. I don't think it is particularly more likely than with any other specification effort. From vishwas.ietf@gmail.com Fri Apr 28 09:31:36 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3SDVaKC006966 for ; Fri, 28 Apr 2006 09:31:36 -0400 Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.206]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k3SDTCRY007731 for ; Fri, 28 Apr 2006 09:29:20 -0400 (EDT) Received: by xproxy.gmail.com with SMTP id i29so1413542wxd for ; Fri, 28 Apr 2006 06:29:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=lEmMUxUYc19NyiF6WvcIMwGBGfCaMWlUESrzO4RN1diAzkD56UgHheSvxPAz/aPpmmrGgoi94Tvv4exGC+/NiU5AuJKaSg6+N5lWjrrvmp+aA1DZcAJVOs5LVqXzsnTCMhzEd0jp8N5SgInQzeBHvW1d/5ugG8uMFS+8pw/ZCek= Received: by 10.70.12.3 with SMTP id 3mr6523339wxl; Fri, 28 Apr 2006 06:29:17 -0700 (PDT) Received: by 10.70.34.10 with HTTP; Fri, 28 Apr 2006 06:29:17 -0700 (PDT) Message-ID: <77ead0ec0604280629r4ca4ae36ud6833ebecdad5964@mail.gmail.com> Date: Fri, 28 Apr 2006 06:29:17 -0700 From: "Vishwas Manral" To: "Pekka Savola" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_455_31570266.1146230957660" References: <7.0.0.16.2.20060420095609.06191b18@vigilsec.com> <444DD2AB.2070606@piuha.net> <17486.1608.716952.420411@fireball.kivinen.iki.fi> <17486.8859.889057.470740@fireball.kivinen.iki.fi> X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Sam Hartman , Jari Arkko , Tero Kivinen Subject: Re: [saag] IPsec spec problems X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2006 13:31:37 -0000 ------=_Part_455_31570266.1146230957660 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Pekka, I agree with you here. I had brought out a similar issue of supporting both the modes Tunnel and transport on most routers in the IPsec list. In my view the lesser the number of combinations the better it is in all respects. Is there a reason why we cannot have Tunnel mode a MUST and not Transport mode when working as a host. I know it saves on bytes in the header. Is it a big enough motivation to have to support 2 modes on most routers? Thanks, Vishwas On 4/27/06, Pekka Savola wrote: > > On Tue, 25 Apr 2006, Tero Kivinen wrote: > > The architecture document describes all possible ways you could use > > IPsec in various different places. > > That's exactly the problem. "All possible ways" and "various > different places" create an architecture which apparently needs to be > ambigious and generic to accommodate all those.. and in turn, such > architecture appears to be very difficult to use (i.e., a failure) in > many contexts. > > > If you only implement control plane protection, i.e. host to host > > IPsec with transport mode, there is things you do not have to > > implement. If you want to combine both control plane protection (host > > to host IPsec) and security gateway features (i.e. VPN usage) then you > > need to implement more of the architecture described in the rfc4301. > > In almost all the cases, I think all major implementations need to > support both. > > > The model described below is nominal; implementations need not > > match details of this model as presented, but the external behavior > > of implementations MUST correspond to the externally observable > > characteristics of this model in order to be compliant. > > That's nice -- unfortunately, unless the motivation of IPsec folks was > to make it more difficult to create new (competing) implementations, > leaving out important details on what the spec actually means and > what's the best way to implement things may be an issue. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > ------=_Part_455_31570266.1146230957660 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Pekka,
 
I agree with you here. I had brought out a similar issue of supporting= both the modes Tunnel and transport on most routers in the IPsec list.
 
In my view the lesser the number of combinations the better it is in a= ll respects. Is there a reason why we cannot have Tunnel mode a MUST and no= t Transport mode when working as a host. I know it saves on bytes in the he= ader. Is it a big enough motivation to have to support 2 modes on most rout= ers?
 
Thanks,
Vishwas
 
On 4/27/06, = Pekka Savola <pekkas@netcore.fi= > wrote:
On Tue, 25 Apr 2006, Tero Kivine= n wrote:
> The architecture document describes all possible ways you = could use
> IPsec in various different places.

That's exactly the probl= em.  "All possible ways" and "various
different= places" create an architecture which apparently needs to be
ambigi= ous and generic to accommodate all those.. and in turn, such
architecture appears to be very difficult to use (i.e., a failure) inmany contexts.

> If you only implement control plane protection= , i.e. host to host
> IPsec with transport mode, there is things you = do not have to
> implement. If you want to combine both control plane protection (h= ost
> to host IPsec) and security gateway features (i.e. VPN usage) t= hen you
> need to implement more of the architecture described in the= rfc4301.

In almost all the cases, I think all major implementations need to<= br>support both.

>   The model described below is nomin= al; implementations need not
>   match details of this mode= l as presented, but the external behavior
>   of implementations MUST correspond to the externally o= bservable
>   characteristics of this model in order to be = compliant.

That's nice -- unfortunately, unless the motivation of IP= sec folks was
to make it more difficult to create new (competing) implementations,
lea= ving out important details on what the spec actually means and
what's th= e best way to implement things may be an issue.

--
Pekka Savola&n= bsp;            = ;    "You each name yourselves king, yet the
Netcore Oy          &= nbsp;         kingdom bleeds.&= quot;
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kin= gs
------=_Part_455_31570266.1146230957660-- From rbonica@juniper.net Fri Apr 28 10:02:17 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3SE2Hud012919 for ; Fri, 28 Apr 2006 10:02:17 -0400 Received: from borg.juniper.net (borg.juniper.net [207.17.137.119]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k3SE2FMr008902 for ; Fri, 28 Apr 2006 10:02:15 -0400 (EDT) Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 28 Apr 2006 07:02:14 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,164,1144047600"; d="scan'208"; a="546672479:sNHT22960252" Received: from [172.25.42.210] ([172.25.42.210] RDNS failed) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Apr 2006 10:02:13 -0400 Message-ID: <44522062.5080007@juniper.net> Date: Fri, 28 Apr 2006 10:02:10 -0400 From: Ron Bonica User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: saag@mit.edu, Pekka Savola References: In-Reply-To: X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Apr 2006 14:02:13.0811 (UTC) FILETIME=[59BDA030:01C66ACC] X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: Re: [saag] Fwd: draft-bonica-tcp-auth X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2006 14:02:17 -0000 > Subject: > Re: [saag] Fwd: draft-bonica-tcp-auth > From: > Pekka Savola > Date: > Tue, 25 Apr 2006 08:17:11 +0300 (EEST) > To: > David McGrew > > To: > David McGrew > CC: > saag@mit.edu, Russ Housley > > > > On Mon, 24 Apr 2006, David McGrew wrote: > >>> The need to change the keys is based on other factors (such as, an >>> employee leaving the company) rather than a fear of crypthographic >>> brute-forcing. >> >> >> I agree that these operational access control issues often cause >> operators to need to change keys. These issues aren't addressed in >> the draft that I'd mentioned, nor do I think that they should be in >> scope even (can't solve every problem inside a TCP option :-) > > > IMHO, supporting administrative re-keying without session flap is a MUST > for any replacement protocol whether based on IPsec/IKE or something > else. If doing so isn't reasonable in a TCP option, that's IMHO a clear > indication that an option isn't "good enough". > > Pekka, Absolutely! In fact, the entire motivation for the draft was to provide a mechanism for updating keys without bouncing the TCP session. Section 13 of draft-bonica-tcp-auth-04 for a details on this procedure. Ron From kent@bbn.com Fri Apr 28 16:36:12 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3SKaAwa016224 for ; Fri, 28 Apr 2006 16:36:10 -0400 Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k3SKa856026953; Fri, 28 Apr 2006 16:36:08 -0400 (EDT) Received: from dhcp89-089-106.bbn.com ([128.89.89.106]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1FZZh9-0008CR-3p; Fri, 28 Apr 2006 16:36:07 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <77ead0ec0604280629r4ca4ae36ud6833ebecdad5964@mail.gmail.com> References: <7.0.0.16.2.20060420095609.06191b18@vigilsec.com> <444DD2AB.2070606@piuha.net> <17486.1608.716952.420411@fireball.kivinen.iki.fi> <17486.8859.889057.470740@fireball.kivinen.iki.fi> <77ead0ec0604280629r4ca4ae36ud6833ebecdad5964@mail.gmail.com> Date: Fri, 28 Apr 2006 16:34:34 -0400 To: "Vishwas Manral" From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Jari Arkko , Sam Hartman , Pekka Savola , Tero Kivinen Subject: Re: [saag] IPsec spec problems X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2006 20:36:12 -0000 At 6:29 AM -0700 4/28/06, Vishwas Manral wrote: >Pekka, > >I agree with you here. I had brought out a similar issue of >supporting both the modes Tunnel and transport on most routers in >the IPsec list. > >In my view the lesser the number of combinations the better it is in >all respects. Is there a reason why we cannot have Tunnel mode a >MUST and not Transport mode when working as a host. I know it saves >on bytes in the header. Is it a big enough motivation to have to >support 2 modes on most routers? > >Thanks, >Vishwas Vishwas, We had this discussion on the IPsec list several years ago. Everyone agreed that if we could mandate just one mode, that would be preferable, but the group was divided over which mode that was! Tunnel mode overhead is substantial compared to transport mode overhead and thus folks who are concerned about the per-packet overhead were not willing to give up transport mode for host-to-host communication. Let's not have this debate again. In general I feel that it's not fair to a WG to re-open discussions after the WG has closed, unless there is a serious technical error in the WG's documents. Otherwise we invite folks to wait for a WG to close and then pursue an agenda that was rejected by WG members during its lifetime. Steve From kent@bbn.com Fri Apr 28 16:40:45 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3SKejeg017151 for ; Fri, 28 Apr 2006 16:40:45 -0400 Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k3SKeXZw002889; Fri, 28 Apr 2006 16:40:33 -0400 (EDT) Received: from dhcp89-089-106.bbn.com ([128.89.89.106]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1FZZlR-0008JC-3v; Fri, 28 Apr 2006 16:40:33 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <7.0.0.16.2.20060420095609.06191b18@vigilsec.com> <444DD2AB.2070606@piuha.net> <17486.1608.716952.420411@fireball.kivinen.iki.fi> <17486.8859.889057.470740@fireball.kivinen.iki.fi> <17489.55355.478392.483772@fireball.kivinen.iki.fi> Date: Fri, 28 Apr 2006 16:38:44 -0400 To: Sam Hartman From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Jari Arkko , Pekka Savola , Tero Kivinen Subject: Re: [saag] IPsec spec problems X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2006 20:40:45 -0000 At 8:26 AM -0400 4/28/06, Sam Hartman wrote: ... Sam, I think your characterization is a good one, and I have a guess as to why application protocol developers are finding that they have to work hard to use IPsec in their environments. The IPsec WG, like most others, refined its documents based on feedback from list members. Most of these list members represented VPN vendors, but there were also host vendors represented. However, there were no OSPF folks involved, nor BGP folks (other than my interest in using IPsec to protect BGP). So it is not surprising that details related to other applications were not as well represented. Steve From nw141292@binky.Central.Sun.COM Fri Apr 28 17:54:47 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3SLskTS027253 for ; Fri, 28 Apr 2006 17:54:47 -0400 Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k3SLsgw0005206; Fri, 28 Apr 2006 17:54:42 -0400 (EDT) Received: from centralmail1brm.Central.Sun.COM (centralmail1brm.central.sun.com [129.147.62.1]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k3SLsf4d017672; Fri, 28 Apr 2006 15:54:42 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k3SLseMs014370; Fri, 28 Apr 2006 15:54:41 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k3SLsXPH013998; Fri, 28 Apr 2006 16:54:33 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k3SLsWEm013997; Fri, 28 Apr 2006 16:54:32 -0500 (CDT) Date: Fri, 28 Apr 2006 16:54:32 -0500 From: Nicolas Williams To: Stephen Kent Message-ID: <20060428215431.GH13896@binky.Central.Sun.COM> References: <444DD2AB.2070606@piuha.net> <17486.1608.716952.420411@fireball.kivinen.iki.fi> <17486.8859.889057.470740@fireball.kivinen.iki.fi> <17489.55355.478392.483772@fireball.kivinen.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Jari Arkko , Sam Hartman , Pekka Savola , Tero Kivinen Subject: Re: [saag] IPsec spec problems X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2006 21:54:47 -0000 On Fri, Apr 28, 2006 at 04:38:44PM -0400, Stephen Kent wrote: > At 8:26 AM -0400 4/28/06, Sam Hartman wrote: > ... > Sam, > > I think your characterization is a good one, and I have a guess as to > why application protocol developers are finding that they have to > work hard to use IPsec in their environments. > > The IPsec WG, like most others, refined its documents based on > feedback from list members. Most of these list members represented > VPN vendors, but there were also host vendors represented. However, > there were no OSPF folks involved, nor BGP folks (other than my > interest in using IPsec to protect BGP). So it is not surprising that > details related to other applications were not as well represented. That's a good guess, I'm sure, but from a technical perspective, as opposed to political/organizational, I think there are two problems: - the lack of the kind of interfaces described in the BTNS WG connection latching I-D[0]; - the lack of an ad-hoc enrolment/leap-of-faith facility for IPsec (which should be made possible by a combination of the BTNS core functionality, connection latching, and the interfaces described in [0]). [0] draft-ietf-btns-connection-latching-00.txt Nico -- From hartmans@MIT.EDU Fri Apr 28 18:21:17 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3SMLHlc030552 for ; Fri, 28 Apr 2006 18:21:17 -0400 Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k3SMLF07008827 for ; Fri, 28 Apr 2006 18:21:15 -0400 (EDT) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 653B0E0053; Fri, 28 Apr 2006 18:21:08 -0400 (EDT) To: Stephen Kent References: <7.0.0.16.2.20060420095609.06191b18@vigilsec.com> <444DD2AB.2070606@piuha.net> <17486.1608.716952.420411@fireball.kivinen.iki.fi> <17486.8859.889057.470740@fireball.kivinen.iki.fi> <17489.55355.478392.483772@fireball.kivinen.iki.fi> From: Sam Hartman Date: Fri, 28 Apr 2006 18:21:08 -0400 In-Reply-To: (Stephen Kent's message of "Fri, 28 Apr 2006 16:38:44 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 1.352 X-Spam-Level: * (1.352) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Jari Arkko , Pekka Savola , Tero Kivinen Subject: Re: [saag] IPsec spec problems X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2006 22:21:17 -0000 >>>>> "Stephen" == Stephen Kent writes: Stephen> At 8:26 AM -0400 4/28/06, Sam Hartman wrote: ... Sam, Stephen> I think your characterization is a good one, and I have a Stephen> guess as to why application protocol developers are Stephen> finding that they have to work hard to use IPsec in their Stephen> environments. Stephen> The IPsec WG, like most others, refined its documents Stephen> based on feedback from list members. Most of these list Stephen> members represented VPN vendors, but there were also host Stephen> vendors represented. However, there were no OSPF folks Stephen> involved, nor BGP folks (other than my interest in using Stephen> IPsec to protect BGP). So it is not surprising that Stephen> details related to other applications were not as well Stephen> represented. Absolutely. But we cannot always get all parties involved. So we work on incremental improvement. From hartmans@MIT.EDU Fri Apr 28 18:25:31 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3SMPVM9031136 for ; Fri, 28 Apr 2006 18:25:31 -0400 Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k3SMPQiI018241 for ; Fri, 28 Apr 2006 18:25:26 -0400 (EDT) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id BD7B4E006A; Fri, 28 Apr 2006 18:25:25 -0400 (EDT) To: Nicolas Williams References: <444DD2AB.2070606@piuha.net> <17486.1608.716952.420411@fireball.kivinen.iki.fi> <17486.8859.889057.470740@fireball.kivinen.iki.fi> <17489.55355.478392.483772@fireball.kivinen.iki.fi> <20060428215431.GH13896@binky.Central.Sun.COM> From: Sam Hartman Date: Fri, 28 Apr 2006 18:25:25 -0400 In-Reply-To: <20060428215431.GH13896@binky.Central.Sun.COM> (Nicolas Williams's message of "Fri, 28 Apr 2006 16:54:32 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 1.352 X-Spam-Level: * (1.352) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Jari Arkko , Tero Kivinen , Pekka Savola Subject: Re: [saag] IPsec spec problems X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2006 22:25:31 -0000 Nico, while I agree that work in BTNS is important, and while I agree that all needs to happen, I actually think that there is more to helping these requirements than a small number of technical point solutions. I'll note that the OSPF case was difficult even though it really didn't have connection latching issues (you protected all OSPF traffic) and did not require leap of faith. So, I agree that BTNS is part of the picture. But don't under estimate the importance of conceptual models, BCPs like Steve Bellovin's use IPsec document, etc. From nw141292@binky.Central.Sun.COM Fri Apr 28 18:42:37 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3SMgbgd001463 for ; Fri, 28 Apr 2006 18:42:37 -0400 Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k3SMgPo8010482; Fri, 28 Apr 2006 18:42:26 -0400 (EDT) Received: from centralmail2brm.Central.Sun.COM (centralmail2brm.central.sun.com [129.147.62.14]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k3SMgPaN029627; Fri, 28 Apr 2006 16:42:25 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k3SMgNWh008645; Fri, 28 Apr 2006 16:42:24 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k3SMgN5a014032; Fri, 28 Apr 2006 17:42:23 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k3SMgNCW014031; Fri, 28 Apr 2006 17:42:23 -0500 (CDT) Date: Fri, 28 Apr 2006 17:42:23 -0500 From: Nicolas Williams To: Sam Hartman Message-ID: <20060428224223.GK13896@binky.Central.Sun.COM> References: <17486.1608.716952.420411@fireball.kivinen.iki.fi> <17486.8859.889057.470740@fireball.kivinen.iki.fi> <17489.55355.478392.483772@fireball.kivinen.iki.fi> <20060428215431.GH13896@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Jari Arkko , Tero Kivinen , Pekka Savola Subject: Re: [saag] IPsec spec problems X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2006 22:42:37 -0000 On Fri, Apr 28, 2006 at 06:25:25PM -0400, Sam Hartman wrote: > Nico, while I agree that work in BTNS is important, and while I agree > that all needs to happen, I actually think that there is more to > helping these requirements than a small number of technical point > solutions. I'll note that the OSPF case was difficult even though it > really didn't have connection latching issues (you protected all OSPF > traffic) and did not require leap of faith. Oh, I didn't mean to say that there were only technical issues. Also, it's important to note that connection latching doesn't require TCP, SCTP connections -- a latch can encompass all traffic for OSPF between two nodes, for example. Easy credentialling via enrolment or LoF wouldn't help OSPF? > So, I agree that BTNS is part of the picture. But don't under > estimate the importance of conceptual models, BCPs like Steve > Bellovin's use IPsec document, etc. I don't, but I think many applications, such as iSCSI, BGP and maybe even OSPF, would greatly benefit from having better programmatic interfaces to IPsec, and that specifications for how to use IPsec with such applications would gain formalism from making reference to such programmatic interfaces. Nico -- From kent@bbn.com Sun Apr 30 22:28:12 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k412SAq9028954 for ; Sun, 30 Apr 2006 22:28:11 -0400 Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k412S7Kg024437; Sun, 30 Apr 2006 22:28:07 -0400 (EDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.84.131.37]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1FaO8s-0007Vy-6L; Sun, 30 Apr 2006 22:28:07 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20060428224223.GK13896@binky.Central.Sun.COM> References: <17486.1608.716952.420411@fireball.kivinen.iki.fi> <17486.8859.889057.470740@fireball.kivinen.iki.fi> <17489.55355.478392.483772@fireball.kivinen.iki.fi> <20060428215431.GH13896@binky.Central.Sun.COM> <20060428224223.GK13896@binky.Central.Sun.COM> Date: Sun, 30 Apr 2006 22:05:17 -0400 To: Nicolas Williams From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Jari Arkko , Sam Hartman , Pekka Savola , Tero Kivinen Subject: Re: [saag] IPsec spec problems X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2006 02:28:12 -0000 At 5:42 PM -0500 4/28/06, Nicolas Williams wrote: >On Fri, Apr 28, 2006 at 06:25:25PM -0400, Sam Hartman wrote: >> Nico, while I agree that work in BTNS is important, and while I agree >> that all needs to happen, I actually think that there is more to >> helping these requirements than a small number of technical point >> solutions. I'll note that the OSPF case was difficult even though it >> really didn't have connection latching issues (you protected all OSPF >> traffic) and did not require leap of faith. > >Oh, I didn't mean to say that there were only technical issues. > >Also, it's important to note that connection latching doesn't require >TCP, SCTP connections -- a latch can encompass all traffic for OSPF >between two nodes, for example. That was not the issue. One problem OSPF incurred is that they have an ill-defined set of peers, most of whom are not direct neighbors, for whom they would like to create a single multicast SA. >Easy credentialling via enrolment or LoF wouldn't help OSPF? Not clear. There are no people in the loop to make an LoF judgement call, unlike the SSH model we have cited as a good LoF example. > > So, I agree that BTNS is part of the picture. But don't under >> estimate the importance of conceptual models, BCPs like Steve >> Bellovin's use IPsec document, etc. > >I don't, but I think many applications, such as iSCSI, BGP and maybe >even OSPF, would greatly benefit from having better programmatic >interfaces to IPsec, and that specifications for how to use IPsec with >such applications would gain formalism from making reference to such >programmatic interfaces. Such an interface may help some folks. Steve From kent@bbn.com Sun Apr 30 22:28:17 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k412SERW028977 for ; Sun, 30 Apr 2006 22:28:14 -0400 Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k412S7vL026744; Sun, 30 Apr 2006 22:28:07 -0400 (EDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.84.131.37]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1FaO8s-0007Vy-3m; Sun, 30 Apr 2006 22:28:06 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20060428215431.GH13896@binky.Central.Sun.COM> References: <444DD2AB.2070606@piuha.net> <17486.1608.716952.420411@fireball.kivinen.iki.fi> <17486.8859.889057.470740@fireball.kivinen.iki.fi> <17489.55355.478392.483772@fireball.kivinen.iki.fi> <20060428215431.GH13896@binky.Central.Sun.COM> Date: Sun, 30 Apr 2006 22:01:55 -0400 To: Nicolas Williams From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Sam Hartman , Jari Arkko , Pekka Savola , Tero Kivinen Subject: Re: [saag] IPsec spec problems X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2006 02:28:17 -0000 At 4:54 PM -0500 4/28/06, Nicolas Williams wrote: >On Fri, Apr 28, 2006 at 04:38:44PM -0400, Stephen Kent wrote: >> At 8:26 AM -0400 4/28/06, Sam Hartman wrote: >> ... >> Sam, >> >> I think your characterization is a good one, and I have a guess as to >> why application protocol developers are finding that they have to >> work hard to use IPsec in their environments. >> >> The IPsec WG, like most others, refined its documents based on >> feedback from list members. Most of these list members represented >> VPN vendors, but there were also host vendors represented. However, >> there were no OSPF folks involved, nor BGP folks (other than my >> interest in using IPsec to protect BGP). So it is not surprising that >> details related to other applications were not as well represented. > >That's a good guess, I'm sure, but from a technical perspective, as >opposed to political/organizational, I think there are two problems: > > - the lack of the kind of interfaces described in the BTNS WG > connection latching I-D[0]; > > - the lack of an ad-hoc enrolment/leap-of-faith facility for IPsec > (which should be made possible by a combination of the BTNS core > functionality, connection latching, and the interfaces described in > [0]). > While I agree that these BTNS functions will help some set of apps, neither of them has anything to do with the OSPF example Sam and I dealt with. Steve From bgreene@cisco.com Mon May 1 12:47:37 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k41Glbta017186 for ; Mon, 1 May 2006 12:47:37 -0400 Received: from test-iport-2.cisco.com (test-iport-2.cisco.com [171.71.176.105]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k41GlXta024180 for ; Mon, 1 May 2006 12:47:33 -0400 (EDT) Received: from sj-core-1.cisco.com ([171.71.177.237]) by test-iport-2.cisco.com with ESMTP; 01 May 2006 09:47:33 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k41GlXw1006546; Mon, 1 May 2006 09:47:33 -0700 (PDT) Received: from xmb-sjc-227.amer.cisco.com ([128.107.191.43]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 May 2006 09:47:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 1 May 2006 09:47:23 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] IPsec spec problems Thread-Index: AcZoZ7YbEX55il6ZQOaazTobPXk5TwAAeSsAAAJahWA= From: "Barry Greene \(bgreene\)" To: , X-OriginalArrivalTime: 01 May 2006 16:47:32.0994 (UTC) FILETIME=[F1461620:01C66D3E] X-Spam-Score: -2.4 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id k41Glbta017186 Subject: Re: [saag] IPsec spec problems X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2006 16:47:37 -0000 [For some reason my subscription was not allowing my post through. Trying again.] > The situation is not this bad. It is worse. People ask me about doing IPSEC to protection routing protocols all the time. The irony is that you are better off NOT doing IPSEC to protect control plane protocols. The perceived risk you are protecting against (man in the middle snooping) eliminates all point protection to the control plane protocol. The multiple layers of classification, policing, and physical queues are all bypassed - with the IPSEC packet going all the way to the software on the Route Processor to de-encrypt the packet. The result is that the router is MORE vulnerable to attack with IPSEC protected control plane than with it turned on. The core principle to remember is that you cannot wait until the packet arrives to the core processes on the RP of the router before you classify, queue, and police the packet. In fact, router vendors should be doing this classify/queue/police multiple times (i.e. layered security) starting as close to the L2/L3 as possible (i.e. first phases of the ASIC). > -----Original Message----- > From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu] On > Behalf Of Pasi.Eronen@nokia.com > Sent: Tuesday, April 25, 2006 6:43 AM > To: saag@mit.edu > Subject: Re: [saag] IPsec spec problems > > Pekka Savola wrote: > > > > I actually read RFC 4301 for the first time on a plane (for the > > record, I had not read any IPsec RFCs previously). The > situation was > > much worse than I thought. One could say that the IPsec > spec is not > > optimized for control plane protection with all of its crazy talk > > about protected/unprotected interfaces, non-native implementations, > > etc. > > > > My perception is that IPsec spec tries to address too many problems > > (minimal firewall policing through SPDs; control traffic > protection; > > VPN protection), and the result is too complex that it isn't useful > > for anything except VPNs, and even that's pretty complicated due to > > all the baggage. > > > > I was also boggled by the notion that an IPsec implementation at a > > router would have to inspect ALL packets it forwards > (whether IPsec or > > not) against SPD. That means IPsec would need to be implemented on > > all the linecards even if all you wanted is to protect the control > > plane. > > > > Saner alternative: whether to look for SPDs for particular packet > > should be keyed off from the routing table entries. That > way IPsec is > > only consulted when it needs to be consulted. > > The situation is not this bad. Yes, you're required to > inspect all packets crossing the IPsec boundary (between > unprotected and protected interfaces), but where exactly this > boundary is placed can vary. > > In a router that uses IPsec only for its control traffic (and > thus is really a host instead of a gateway from IPsec > perspective), the protected interface could be the part of > the stack delivering packets to/from local control plane > daemons. Thus, packets simply being forwarded by line cards > would not cross the IPsec boundary at all. > > But yes, things get more complicated if the router also does > IPsec for forwarded packets... although you might simplify > things if you consider the router to have multiple logically > separate IPsec implementations (as suggested in Section 3.3 > of RFC 4301). > > Best regards, > Pasi > > _______________________________________________ > saag mailing list > saag@mit.edu > http://mailman.mit.edu/mailman/listinfo/saag > From mcgrew@cisco.com Tue May 2 11:15:46 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k42FFkdm004725 for ; Tue, 2 May 2006 11:15:46 -0400 Received: from test-iport-1.cisco.com (test-iport-1.cisco.com [171.71.176.117]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k42FFiZh006268 for ; Tue, 2 May 2006 11:15:44 -0400 (EDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by test-iport-1.cisco.com with ESMTP; 02 May 2006 08:15:44 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k42FFhRT012021; Tue, 2 May 2006 08:15:43 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 2 May 2006 08:15:43 -0700 Received: from [192.168.1.100] ([10.32.254.210]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 2 May 2006 08:15:43 -0700 Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: David McGrew Date: Tue, 2 May 2006 08:15:41 -0700 To: AVT X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 02 May 2006 15:15:43.0453 (UTC) FILETIME=[47BE98D0:01C66DFB] X-Spam-Score: -2.4 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, ietf-rtpsec@imc.org Subject: [saag] The use of AES-192 and AES-256 in Secure RTP X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2006 15:15:46 -0000 Hello, there has been some interest in using AES with larger key sizes in Secure RTP, and some implementations have gone in this direction in advance of any specification. I wrote up an internet draft to fill this gap (after trying unsuccessfully to get someone else to write it :-) and to provide usage guidance and (eventually) test vectors. It's online at http://www.ietf.org/internet-drafts/draft-mcgrew-srtp- big-aes-00.txt I propose that this draft be adopted for standards track, and I ask for your review (if you have an interest in Secure RTP). Please note the "Open Questions" section. The ietf-rtpsec list is copied since this draft is potentially interesting there, even though the draft has little architectural impact. Best regards, David From kent@bbn.com Tue May 2 12:22:03 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k42GM3Yi015146 for ; Tue, 2 May 2006 12:22:03 -0400 Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k42GLvFM008800 for ; Tue, 2 May 2006 12:21:57 -0400 (EDT) Received: from dhcp89-089-106.bbn.com ([128.89.89.106]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1FaxdL-0001dI-4H; Tue, 02 May 2006 12:21:55 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 2 May 2006 12:21:49 -0400 To: "Barry Greene \(bgreene\)" From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] IPsec spec problems X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2006 16:22:03 -0000 At 9:47 AM -0700 5/1/06, Barry Greene \(bgreene\) wrote: >[For some reason my subscription was not allowing my post through. >Trying again.] > >> The situation is not this bad. > >It is worse. People ask me about doing IPSEC to protection routing >protocols all the time. The irony is that you are better off NOT doing >IPSEC to protect control plane protocols. The perceived risk you are >protecting against (man in the middle snooping) presumably the concern is not so much snooping (which suggests passive wiretapping) as packet tampering (active wiretapping). > eliminates all point >protection to the control plane protocol. The multiple layers of >classification, policing, and physical queues are all bypassed - with >the IPSEC packet going all the way to the software on the Route >Processor to de-encrypt the packet. The proper term is decrypt. > The result is that the router is >MORE vulnerable to attack with IPSEC protected control plane than with >it turned on. A more accurate characterization of the concern you cite is that an implementation of IPsec in the control/management processor could create a type of DoS vulnerability, one that might be greater than the active wiretap concern alluded to above. But this potential DoS vulnerability is a function of the implementation strategy adopted by a vendor; it is not intrinsic. For example, if one believes that attackers are not capable of a MITM attack, then one could implement a simple, fast check of the SPI associated with each IPsec (ESP) packet, on a line card. Thus off-path attacks would be rejected efficiently. Alternatively, if future management processors had adequate horsepower to process IPsec traffic at high speeds, e.g., via hardware assist, then the problem would vanish as well. It is important to discuss the pros and cons of a given approach relative to a well-defined set of assumptions. >The core principle to remember is that you cannot wait until the packet >arrives to the core processes on the RP of the router before you >classify, queue, and police the packet. In fact, router vendors should >be doing this classify/queue/police multiple times (i.e. layered >security) starting as close to the L2/L3 as possible (i.e. first phases >of the ASIC). Applying checks at multiple layers is certainly a reasonable strategy, especially if DoS is a primary concern. However, one ought not assume that multiple, weak checks are superior to one strong check, all else being equal. Steve From ldondeti@qualcomm.com Tue May 2 12:50:52 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k42GoquX021627 for ; Tue, 2 May 2006 12:50:52 -0400 Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k42GoedW023849 for ; Tue, 2 May 2006 12:50:41 -0400 (EDT) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k42GoWIX005159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 2 May 2006 09:50:33 -0700 Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.20]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k42GoSTW002385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 2 May 2006 09:50:31 -0700 (PDT) Message-Id: <6.2.5.6.2.20060502093853.058c5948@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 02 May 2006 09:50:27 -0700 To: David McGrew , AVT From: Lakshminath Dondeti In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, ietf-rtpsec@imc.org Subject: Re: [saag] The use of AES-192 and AES-256 in Secure RTP X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2006 16:50:52 -0000 Hi David, As I read the email, I wondered about replacing HMAC-SHA-1 in 3711 also, and glad to see that your open questions lists that. I have a few questions: 1. Is the 112-bit salt sufficient even with longer keys? You might recall that we've (Mark B., you and I) had discussions on the master key and salt being input to a KDF that results in the derivation of the encr_key, integ_key and a salt, where the output might be longer than the input to the KDF. You are the expert in this area, but I am still wondering if it is an issue. Figure 2 applies to AES-128 only, right? 2. I would suggest that this draft include AES-based CMAC, so we can move away from SHA-1 and also use a single crypto primitive for encryption, and PRF and MAC computation (opinion on your open question). Q: What are the considerations in truncating cipher-based MAC outputs? Specifically, is truncating below half-the-size of the output (which I vaguely recall as relating to the birthday attack in case of hash-based MACs -- perhaps it is not) of the cipher-based MAC ok? What would be the strength of the MAC in that case. If we are making a case for AES-192 or AES-256, then we have a certain stronger adversary in mind (one that requires us to move away from AES-128). In that case, why is MAC truncation not an issue? Let's discuss those for now. I may have more later :-). Thanks for doing this! I was going to ask you about using CMAC in 3711! regards, Lakshminath At 08:15 AM 5/2/2006, David McGrew wrote: >Hello, > >there has been some interest in using AES with larger key sizes in >Secure RTP, and some implementations have gone in this direction in >advance of any specification. I wrote up an internet draft to fill >this gap (after trying unsuccessfully to get someone else to write >it :-) and to provide usage guidance and (eventually) test vectors. >It's online at >http://www.ietf.org/internet-drafts/draft-mcgrew-srtp- big-aes-00.txt > >I propose that this draft be adopted for standards track, and I ask >for your review (if you have an interest in Secure RTP). Please note >the "Open Questions" section. The ietf-rtpsec list is copied since >this draft is potentially interesting there, even though the draft >has little architectural impact. > >Best regards, > >David From mcgrew@cisco.com Tue May 2 16:42:01 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k42Kg1le027753 for ; Tue, 2 May 2006 16:42:01 -0400 Received: from test-iport-1.cisco.com (test-iport-1.cisco.com [171.71.176.117]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k42Kg0gd012802 for ; Tue, 2 May 2006 16:42:00 -0400 (EDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by test-iport-1.cisco.com with ESMTP; 02 May 2006 13:42:00 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k42KfwRV015462; Tue, 2 May 2006 13:42:00 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 2 May 2006 13:41:59 -0700 Received: from [192.168.1.100] ([10.32.254.210]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 2 May 2006 13:41:58 -0700 In-Reply-To: <6.2.5.6.2.20060502093853.058c5948@qualcomm.com> References: <6.2.5.6.2.20060502093853.058c5948@qualcomm.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: David McGrew Date: Tue, 2 May 2006 13:41:56 -0700 To: Lakshminath Dondeti X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 02 May 2006 20:41:58.0500 (UTC) FILETIME=[DB61BA40:01C66E28] X-Spam-Score: -2.4 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, ietf-rtpsec@imc.org, AVT Subject: Re: [saag] The use of AES-192 and AES-256 in Secure RTP X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2006 20:42:01 -0000 Hi Lakshminath, thanks for your comments, more inline: On May 2, 2006, at 9:50 AM, Lakshminath Dondeti wrote: > Hi David, > > As I read the email, I wondered about replacing HMAC-SHA-1 in 3711 > also, and glad to see that your open questions lists that. I have > a few questions: > > 1. Is the 112-bit salt sufficient even with longer keys? You might > recall that we've (Mark B., you and I) had discussions on the > master key and salt being input to a KDF that results in the > derivation of the encr_key, integ_key and a salt, where the output > might be longer than the input to the KDF. You are the expert in > this area, but I am still wondering if it is an issue. I think that the 112-bit salt is sufficient. The srtp salt is present so that the srtp use of counter mode is essentially as secure as CBC mode against attacks that amortize computational effort over multiple target keys. This property still holds for the larger key sizes. Besides, there's not much that we can do to increase the salt length, since there are only 16 more bits that we could possibly add. I also think that it is valuable to retain counter-format compatibility with the AES-128 counter mode. > > Figure 2 applies to AES-128 only, right? > No, it's for all of the key sizes. AES-192 and AES-256 still have 16 byte plaintexts. Or maybe I'm not understanding; did I mislabel something? > 2. I would suggest that this draft include AES-based CMAC, so we > can move away from SHA-1 and also use a single crypto primitive for > encryption, and PRF and MAC computation (opinion on your open > question). We think alike :-) I implemented AES CMAC for SRTP and found that it performs better than HMAC-SHA1 for very short packets (like those for conversational voice over a WAN) but not long packets (like video). It also has some other advantages. But OTOH there is a cost to proliferating cryptoalgorithms. Let's start up a separate thread on CMAC. > > Q: What are the considerations in truncating cipher-based MAC > outputs? Specifically, is truncating below half-the-size of the > output (which I vaguely recall as relating to the birthday attack > in case of hash-based MACs -- perhaps it is not) of the cipher- > based MAC ok? Ah, good points. The NIST CMAC specification disallows truncation to MACs shorter than 64 bits. This is not because CMAC is weaker than an ideal MAC with respect to truncation, though. CMAC has been shown to be a good pseudorandom function if AES is a good blockcipher (as long as some usage limits are respected), and a PRF essentially is an ideal MAC. I'm pretty sure that the CMAC specification insists on MACs of at least 64 bits because it feels that a per-MAC forgery probability greater than 2^64 is not acceptable. No doubt they were not considering the case of stateless codecs, which some SRTP users need only 32-bit MACs. It is an interesting question as to what tag sizes would be recommended for use with CMAC! > What would be the strength of the MAC in that case. If we are > making a case for AES-192 or AES-256, then we have a certain > stronger adversary in mind (one that requires us to move away from > AES-128). In that case, why is MAC truncation not an issue? That's a good question. I think that in some circumstances it could make sense to use a short authentication tag and a huge key. If some unanticipated advance in cryptanalysis enables us to break AES-128 but not AES-256, but some user is still okay with accepting one out of a billion forged g.711 packets, this scenario would fit the bill. So the cryptosuites defined in the draft might make sense. But I take your point that users concerned that AES-128 doesn't have enough security may well not be satisfied with a 32-bit MAC. It would be good to get some input from the Suite B community on this question. > > Let's discuss those for now. I may have more later :-). Thanks > for doing this! I was going to ask you about using CMAC in 3711! > Any thoughts on whether or not AES-192 should be included? David > regards, > Lakshminath > > At 08:15 AM 5/2/2006, David McGrew wrote: > >> Hello, >> >> there has been some interest in using AES with larger key sizes in >> Secure RTP, and some implementations have gone in this direction in >> advance of any specification. I wrote up an internet draft to fill >> this gap (after trying unsuccessfully to get someone else to write >> it :-) and to provide usage guidance and (eventually) test vectors. >> It's online at http://www.ietf.org/internet-drafts/draft-mcgrew- >> srtp- big-aes-00.txt >> >> I propose that this draft be adopted for standards track, and I ask >> for your review (if you have an interest in Secure RTP). Please note >> the "Open Questions" section. The ietf-rtpsec list is copied since >> this draft is potentially interesting there, even though the draft >> has little architectural impact. >> >> Best regards, >> >> David From hartmans@MIT.EDU Tue May 2 17:07:53 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k42L7rbm032652 for ; Tue, 2 May 2006 17:07:53 -0400 Received: from carter-zimmerman.mit.edu (carter-zimmerman.dyn.MIT.EDU [18.188.3.148]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k42L7mD3020391 for ; Tue, 2 May 2006 17:07:48 -0400 (EDT) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 8D55DE0053; Tue, 2 May 2006 17:07:41 -0400 (EDT) To: "Barry Greene (bgreene)" References: From: Sam Hartman Date: Tue, 02 May 2006 17:07:41 -0400 In-Reply-To: (Barry Greene's message of "Mon, 1 May 2006 09:47:23 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 1.217 X-Spam-Level: * (1.217) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] IPsec spec problems X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2006 21:07:53 -0000 >>>>> "Barry" == Barry Greene (bgreene) writes: Barry> [For some reason my subscription was not allowing my post Barry> through. Trying again.] >> The situation is not this bad. Barry> It is worse. People ask me about doing IPSEC to protection Barry> routing protocols all the time. The irony is that you are Barry> better off NOT doing IPSEC to protect control plane Barry> protocols. The perceived risk you are protecting against Barry> (man in the middle snooping) eliminates all point Barry> protection to the control plane protocol. The multiple Barry> layers of classification, policing, and physical queues are Barry> all bypassed - with the IPSEC packet going all the way to Barry> the software on the Route Processor to de-encrypt the Barry> packet. The result is that the router is MORE vulnerable Barry> to attack with IPSEC protected control plane than with it Barry> turned on. So, would you or someone at Cisco be willing to work on a document giving implementation guidance or perhaps better yet operational requirements for security solutions that protect against active attack and that have reasonable DOS properties? I think if we had a reasonable set of operational requirements we could work on getting customers to demand those requirements in products. From Eric.Gray@marconi.com Tue May 2 17:48:09 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k42Lm9mc006209 for ; Tue, 2 May 2006 17:48:09 -0400 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k42Lm39I015703; Tue, 2 May 2006 17:48:03 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k42Lm1x4000833; Tue, 2 May 2006 17:48:01 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA07526; Tue, 2 May 2006 17:48:01 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id ; Tue, 2 May 2006 17:48:01 -0400 Message-ID: <313680C9A886D511A06000204840E1CF0DDAF61E@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" To: Sam Hartman , "Barry Greene (bgreene)" Date: Tue, 2 May 2006 17:47:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] IPsec spec problems X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2006 21:48:09 -0000 Sam, I am reasonably sure that you didn't mean this the way it sounds, but I am also sure that we're not really all that interested in soliciting any particular vendor's proposed solution to this general problem - especially as a counter to existing proposals. Apparently, we have a proposal from one vendor, but it seems to be unacceptable because it is not based on IPSec. Now we hear from another vendor that there are a few reasons why an IPSec-based solution is not going to work. Perhaps it is time to look again at the proposal already on the table? -- Eric --> -----Original Message----- --> From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu] On --> Behalf Of Sam Hartman --> Sent: Tuesday, May 02, 2006 5:08 PM --> To: Barry Greene (bgreene) --> Cc: saag@mit.edu --> Subject: Re: [saag] IPsec spec problems --> --> >>>>> "Barry" == Barry Greene (bgreene) writes: --> --> Barry> [For some reason my subscription was not allowing my post --> Barry> through. Trying again.] --> --> >> The situation is not this bad. --> --> Barry> It is worse. People ask me about doing IPSEC to --> protection --> Barry> routing protocols all the time. The irony is that you are --> Barry> better off NOT doing IPSEC to protect control plane --> Barry> protocols. The perceived risk you are protecting against --> Barry> (man in the middle snooping) eliminates all point --> Barry> protection to the control plane protocol. The multiple --> Barry> layers of classification, policing, and physical --> queues are --> Barry> all bypassed - with the IPSEC packet going all the way to --> Barry> the software on the Route Processor to de-encrypt the --> Barry> packet. The result is that the router is MORE vulnerable --> Barry> to attack with IPSEC protected control plane than with it --> Barry> turned on. --> --> So, would you or someone at Cisco be willing to work on a document --> giving implementation guidance or perhaps better yet operational --> requirements for security solutions that protect against --> active attack and that have reasonable DOS properties? --> --> I think if we had a reasonable set of operational requirements we --> could work on getting customers to demand those requirements in --> products. --> --> _______________________________________________ --> saag mailing list --> saag@mit.edu --> http://mailman.mit.edu/mailman/listinfo/saag --> From ldondeti@qualcomm.com Tue May 2 18:12:21 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k42MCLCA010508 for ; Tue, 2 May 2006 18:12:21 -0400 Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k42MCFu2018107 for ; Tue, 2 May 2006 18:12:15 -0400 (EDT) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k42M8pMX008333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 2 May 2006 15:08:52 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-65-121.qualcomm.com [10.50.65.121]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k42M8nYj004144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 2 May 2006 15:08:50 -0700 (PDT) Message-Id: <6.2.5.6.2.20060502145206.05a6e4f8@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 02 May 2006 15:08:50 -0700 To: David McGrew From: Lakshminath Dondeti In-Reply-To: References: <6.2.5.6.2.20060502093853.058c5948@qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, ietf-rtpsec@imc.org, AVT Subject: Re: [saag] The use of AES-192 and AES-256 in Secure RTP X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2006 22:12:21 -0000 Hi David, Thanks for the clarifications. Please see inline for some follow-up notes: At 01:41 PM 5/2/2006, David McGrew wrote: >Hi Lakshminath, > >thanks for your comments, more inline: > >On May 2, 2006, at 9:50 AM, Lakshminath Dondeti wrote: > >>Hi David, >> >> As I read the email, I wondered about replacing HMAC-SHA-1 in 3711 >>also, and glad to see that your open questions lists that. I have >>a few questions: >> >>1. Is the 112-bit salt sufficient even with longer keys? You might >>recall that we've (Mark B., you and I) had discussions on the >>master key and salt being input to a KDF that results in the >>derivation of the encr_key, integ_key and a salt, where the output >>might be longer than the input to the KDF. You are the expert in >>this area, but I am still wondering if it is an issue. > >I think that the 112-bit salt is sufficient. The srtp salt is >present so that the srtp use of counter mode is essentially as secure >as CBC mode against attacks that amortize computational effort over >multiple target keys. This property still holds for the larger key >sizes. Besides, there's not much that we can do to increase the salt >length, since there are only 16 more bits that we could possibly >add. I also think that it is valuable to retain counter-format >compatibility with the AES-128 counter mode. Ok, I understand the limitation on the salt size (also see below about my misunderstanding of the block size in AES). I also understand the aspect of offsetting counter-mode's relative key strength using the salt and that for that purpose 112-bit salt is sufficient. What about using a 128, 192, or 256-bit master key and 112-bit salt to derive a 128, 192, 256-bit encryption key and a 160-bit, 256-bit (assuming SHA-1 or SHA-2) and a session salt key (this is 112-bits in size, right?)? Is entropy or lack thereof is a consideration. >>Figure 2 applies to AES-128 only, right? > >No, it's for all of the key sizes. AES-192 and AES-256 still have 16 >byte plaintexts. Or maybe I'm not understanding; did I mislabel >something? No, my mistake. I forgot that AES uses 128-bit blocks irrespective of the key size. Apologies. >>2. I would suggest that this draft include AES-based CMAC, so we >>can move away from SHA-1 and also use a single crypto primitive for >>encryption, and PRF and MAC computation (opinion on your open >>question). > >We think alike :-) I implemented AES CMAC for SRTP and found that it >performs better than HMAC-SHA1 for very short packets (like those for >conversational voice over a WAN) but not long packets (like video). >It also has some other advantages. But OTOH there is a cost to >proliferating cryptoalgorithms. Let's start up a separate thread on >CMAC. We did talk about it before. The concept of using the same crypto primitive came up elsewhere and that sounds like a good idea. Please start that thread of discussion. >>Q: What are the considerations in truncating cipher-based MAC >>outputs? Specifically, is truncating below half-the-size of the >>output (which I vaguely recall as relating to the birthday attack >>in case of hash-based MACs -- perhaps it is not) of the cipher- based MAC ok? > >Ah, good points. The NIST CMAC specification disallows truncation to >MACs shorter than 64 bits. This is not because CMAC is weaker than >an ideal MAC with respect to truncation, though. CMAC has been shown >to be a good pseudorandom function if AES is a good blockcipher (as >long as some usage limits are respected), and a PRF essentially is an >ideal MAC. I'm pretty sure that the CMAC specification insists on >MACs of at least 64 bits because it feels that a per-MAC forgery >probability greater than 2^64 is not acceptable. No doubt they were >not considering the case of stateless codecs, which some SRTP users >need only 32-bit MACs. It is an interesting question as to what tag >sizes would be recommended for use with CMAC! Let me think more about this. >>What would be the strength of the MAC in that case. If we are >>making a case for AES-192 or AES-256, then we have a certain >>stronger adversary in mind (one that requires us to move away from >>AES-128). In that case, why is MAC truncation not an issue? > >That's a good question. I think that in some circumstances it could >make sense to use a short authentication tag and a huge key. If some >unanticipated advance in cryptanalysis enables us to break AES-128 >but not AES-256, but some user is still okay with accepting one out >of a billion forged g.711 packets, this scenario would fit the bill. >So the cryptosuites defined in the draft might make sense. But I >take your point that users concerned that AES-128 doesn't have enough >security may well not be satisfied with a 32-bit MAC. It would be >good to get some input from the Suite B community on this question. Yes, we'll wait to hear from others. >>Let's discuss those for now. I may have more later :-). Thanks >>for doing this! I was going to ask you about using CMAC in 3711! > >Any thoughts on whether or not AES-192 should be included? I think the use of AES-192 should be specified (at the expense of more work for you :-) ), but let the "market" decide whether the switch is to 192 or 256-bit keys. regards, Lakshminath >David > >>regards, >>Lakshminath >> >>At 08:15 AM 5/2/2006, David McGrew wrote: >> >>>Hello, >>> >>>there has been some interest in using AES with larger key sizes in >>>Secure RTP, and some implementations have gone in this direction in >>>advance of any specification. I wrote up an internet draft to fill >>>this gap (after trying unsuccessfully to get someone else to write >>>it :-) and to provide usage guidance and (eventually) test vectors. >>>It's online at http://www.ietf.org/internet-drafts/draft-mcgrew- >>>srtp- big-aes-00.txt >>> >>>I propose that this draft be adopted for standards track, and I ask >>>for your review (if you have an interest in Secure RTP). Please note >>>the "Open Questions" section. The ietf-rtpsec list is copied since >>>this draft is potentially interesting there, even though the draft >>>has little architectural impact. >>> >>>Best regards, >>> >>>David From mcr@sandelman.ottawa.on.ca Tue May 2 22:09:00 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k4328vFD011629 for ; Tue, 2 May 2006 22:09:00 -0400 Received: from lists.sandelman.ca (cod.sandelman.ca [192.139.46.139]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k4328n3B026016 for ; Tue, 2 May 2006 22:08:49 -0400 (EDT) Received: from sandelman.ottawa.on.ca (postfix@wlan225.sandelman.ca [205.150.200.225]) by lists.sandelman.ca (8.11.6p3/8.11.6) with ESMTP id k4328eo29377 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Tue, 2 May 2006 22:08:43 -0400 (EDT) Received: from sandelman.ottawa.on.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 98AE03AD9C; Tue, 2 May 2006 22:08:40 -0400 (EDT) To: "Barry Greene (bgreene)" In-Reply-To: Message from "Barry Greene (bgreene)" of "Mon, 01 May 2006 09:47:23 PDT." References: X-Mailer: MH-E 7.82; nmh 1.1; XEmacs 21.4 (patch 17) Date: Tue, 02 May 2006 22:08:40 -0400 Message-ID: <7059.1146622120@sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Score: -2.464 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] IPsec spec problems X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2006 02:09:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "bgreene" == bgreene writes: bgreene> It is worse. People ask me about doing IPSEC to protection bgreene> routing protocols all the time. The irony is that you are bgreene> better off NOT doing IPSEC to protect control plane bgreene> protocols. The perceived risk you are protecting against bgreene> (man in the middle snooping) eliminates all point bgreene> protection to the control plane protocol. The multiple I'm not sure I understand the words "point protection" I think that you are assuming that if you do IPsec on control plane packets, that the work has to be performed by the routing plane. I'm asking for clarification here. - -- ] 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"); [ "The Microsoft _Get the Facts CD_ does not work on Linux." - orospakr -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Finger me for keys iQEVAwUBRFgQp4CLcPvd0N1lAQKpPwgAouSB/bFPlZBpE9SoQuuWO8VwRe+EXU8j XkOaWM98pecikFUTrWg0T4ai336PpSeWD+IqHH98yBNmSDsFQdkt2olywIa1+ThW ZUylPh2GY41qPWhUNTiFmLBZd4tPZu4nMCbkwO3Lrv6IG8QQ4tRc1jUnYcH3q7BK Cb/K/MJobrySCcoO93vG1+RDDhFzqWAfge3Y2CVBUq2PCYgnjbf9jPQosB+N1YaT g8w10y4U60JHBT4/2itiXX+CPyCS28HSHHxfuTpNz+HMjeIoadiXu2Jg77bpppiS 7dpXgqNt0TDP/WbPKYNq/G2XK5CGZ6Fje/jr8Ei+jv63SFdkrOUoog== =oi0x -----END PGP SIGNATURE----- From hartmans@MIT.EDU Tue May 2 22:38:06 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k432c697017061 for ; Tue, 2 May 2006 22:38:06 -0400 Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k432c6LI020621 for ; Tue, 2 May 2006 22:38:06 -0400 (EDT) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 4B859E0053; Tue, 2 May 2006 22:38:00 -0400 (EDT) To: "Gray, Eric" References: <313680C9A886D511A06000204840E1CF0DDAF61E@whq-msgusr-02.pit.comms.marconi.com> From: Sam Hartman Date: Tue, 02 May 2006 22:38:00 -0400 In-Reply-To: <313680C9A886D511A06000204840E1CF0DDAF61E@whq-msgusr-02.pit.comms.marconi.com> (Eric Gray's message of "Tue, 2 May 2006 17:47:59 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 1.352 X-Spam-Level: * (1.352) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] IPsec spec problems X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2006 02:38:06 -0000 >>>>> "Gray," == Gray, Eric writes: Gray,> Sam, I am reasonably sure that you didn't mean this the way Gray,> it sounds, but I am also sure that we're not really all Gray,> that interested in soliciting any particular vendor's Gray,> proposed solution to this general problem - especially as a Gray,> counter to existing proposals. I'm absolutely interested in anyone's ideas on what we need to do in order to design boxes where we can have control plane security and also have DOS protection. I don't care if they come from Cisco, some university, an operator or anyone else who has something interesting to say. We will take contributions as input from anyone. I'll also encourage anyone who has a problem with approaches we've taken to write up their problem in an actionable form so we can avoid making mistakes in the future. Even if Ipsec is not appropriate for BGP, there are cases where we have discussed using IPsec for control plane traffic. Also, long-term we're going to need control plane key management. The same issues that come up for IPsec will come up for that. So, regardless of our solution to this problem I at least am interested in what it would take to get IPsec for the control plane. Gray,> Apparently, we have a proposal from one vendor, but it Gray,> seems to be unacceptable because it is not based on IPSec. I think unacceptable is a strong word for the discussion to date. I don't think there is a clear consensus. Gray,> Now we hear from another vendor that there are a few Gray,> reasons why an IPSec-based solution is not going to work. Note we've heard from people that the same DOS issues apply to TCP-level solutions. At least I believe I've heard that; I don't remember if it is on a list. However I've said before and continue to believe that the goal is to provide some integrity protection but to focus on something operators will actually deploy. --Sam From bgreene@cisco.com Tue May 2 23:29:38 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k433Tc5B028371 for ; Tue, 2 May 2006 23:29:38 -0400 Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k433TaQK014320 for ; Tue, 2 May 2006 23:29:36 -0400 (EDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 02 May 2006 20:29:36 -0700 X-IronPort-AV: i="4.05,81,1146466800"; d="scan'208"; a="272371475:sNHT30223424" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k433TZRT012343; Tue, 2 May 2006 20:29:35 -0700 (PDT) Received: from xmb-sjc-227.amer.cisco.com ([128.107.191.43]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 2 May 2006 20:29:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 2 May 2006 20:29:35 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] IPsec spec problems Thread-Index: AcZuBP7+BpEqrBeqRlab1LQbk6cSzwAWiWag From: "Barry Greene \(bgreene\)" To: "Stephen Kent" X-OriginalArrivalTime: 03 May 2006 03:29:35.0617 (UTC) FILETIME=[CCF59F10:01C66E61] X-Spam-Score: -2.4 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id k433Tc5B028371 Cc: saag@mit.edu Subject: Re: [saag] IPsec spec problems X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2006 03:29:38 -0000 > For example, if one believes that attackers are not capable > of a MITM attack, then one could implement a simple, fast > check of the SPI associated with each IPsec (ESP) packet, on > a line card. Thus off-path attacks would be rejected > efficiently. Alternatively, if future management processors > had adequate horsepower to process IPsec traffic at high > speeds, e.g., via hardware assist, then the problem would > vanish as well. I've explored that path. Too complicated to code and high on the maintenance side (too big of OPEX increase). From bgreene@cisco.com Tue May 2 23:29:38 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k433TceU028374 for ; Tue, 2 May 2006 23:29:38 -0400 Received: from test-iport-1.cisco.com (test-iport-1.cisco.com [171.71.176.117]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k433TawF028665; Tue, 2 May 2006 23:29:36 -0400 (EDT) Received: from sj-core-1.cisco.com ([171.71.177.237]) by test-iport-1.cisco.com with ESMTP; 02 May 2006 20:29:36 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k433TZw1013042; Tue, 2 May 2006 20:29:35 -0700 (PDT) Received: from xmb-sjc-227.amer.cisco.com ([128.107.191.43]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 2 May 2006 20:29:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 2 May 2006 20:29:23 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Fwd: draft-bonica-tcp-auth Thread-Index: AcZmNjYhQAeDDa34TA2dlXcZYLOIlgIIsFog From: "Barry Greene \(bgreene\)" To: "Sam Hartman" , "Russ Housley" , X-OriginalArrivalTime: 03 May 2006 03:29:35.0789 (UTC) FILETIME=[CD0FDDD0:01C66E61] X-Spam-Score: -2.4 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id k433TceU028374 Subject: Re: [saag] Fwd: draft-bonica-tcp-auth X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2006 03:29:38 -0000 Context: draft-bonica-tcp-auth is now a collaboration work between BT (the facilitator), Juniper, and Cisco. What is in the draft is based on operational experience with SPs. So to put things in context, this document is what the operators and vendors have determined to work for them - code wise and operations wise. Now, why are we not going down a path of IPSEC to protect BGP? 1. MTTM is not a concern in the BGP world. Yes, there are people, papers, and RFC which talk about the theory of it being done. But, reality is a different matter. The attack testing in the lab has not found a realistic way for a miscreant to MTTM and insert mischievous data into the system. Turn on MD5 and the miscreant is SOL. It is far easier to break into a router already authenticated in the system. Please check the following for one piece of work on the subject. BGP Vulnerability Testing: Separating Fact from FUD http://www.nanog.org/mtg-0306/franz.html 2. So if MTTM is not a worry to the SPs, what is? Disruption of the system. Check out "Lack of Priority Queuing on Route Processors Considered Harmful" http://www.nanog.org/mtg-0302/gill.html. Before Vijay gave this talk, folks working on SP Security found that you are in big trouble if you allow a mischievous to get to the Route Processor. You need to classify, police, and queue the packet as close to the layer 2 - layer 3 conversion as possible. Some of my older public slides on this topic are at ftp://ftp-eng.cisco.com/cons/isp/security/CPN-Summit-2004/Paris-Sept-04/ SE14-BUILDING-SECURITY-INTO-THE%20HARDWARE-c1_8_30_04.pdf. The problem you have with IPSEC is that it is end-to-end security. You loose your ability to classification granularly in-flight (i.e. before the end point). Which means you need to move the packet through the router all the way to the RP before you really know if the packet should be processed on the RP. Once it is on the RP and you are processing it, your DOSed. This is equivalent to the MD5 overload attack vectors. Hence the path SP Operations community worked out - Generalized TTL Security Mechanism (GTSM) with MD5 (or its successor). It is simple, light weight, resistant to operational entropy (a really big issue with SPs), and doable now on today's equipment. So why do IPSEC to protect BGP? There is no exploitable attack vector which IPSEC protect BGP. With GTSM + MD5 there are cheaper (coding time, support, and the operators deployment/maintenance cost) ways of achieving the goals of an SP. All that was missing was a hitless way to change the MD5 keys which was supported by their two core routing vendors. Hence draft-bonica-tcp-auth. > -----Original Message----- > From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu] On > Behalf Of Sam Hartman > Sent: Saturday, April 22, 2006 10:55 AM > To: Russ Housley; saag@mit.edu > Subject: Re: [saag] Fwd: draft-bonica-tcp-auth > > Personally, I would prefer something IPsec-based to this approach. > > I think it is important that we meet the following > requirements roughly in this order: > > 1) Something that provides some form of integrity service > > 2) Something that ISPs will deploy > > 3) Something that is easy to use > > 4) Something that provides strong security guarantees. > > I realize these are vague and that in order to come to any > conclusions we'd need to flesh out these requirements. > However what I'm seeing from this is that I think we need to > be focusing more on the usability of the solutions and on > what the layer 9+ biases of the target deployment community > are than on the communications security discussion we're > currently falling into. If all else is equal, the current > concerns should be addressed. > > _______________________________________________ > saag mailing list > saag@mit.edu > http://mailman.mit.edu/mailman/listinfo/saag > From bgreene@cisco.com Tue May 2 23:29:42 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k433TgNq028381 for ; Tue, 2 May 2006 23:29:42 -0400 Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k433Ta3r028671; Tue, 2 May 2006 23:29:36 -0400 (EDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 02 May 2006 20:29:36 -0700 X-IronPort-AV: i="4.05,81,1146466800"; d="scan'208"; a="1800810294:sNHT28809382" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k433TaRT012346; Tue, 2 May 2006 20:29:36 -0700 (PDT) Received: from xmb-sjc-227.amer.cisco.com ([128.107.191.43]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 2 May 2006 20:29:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 2 May 2006 20:29:35 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] IPsec spec problems Thread-Index: AcZuLIC23gAAIL/pRliTzP/pz7/TaAAMt3/A From: "Barry Greene \(bgreene\)" To: "Sam Hartman" X-OriginalArrivalTime: 03 May 2006 03:29:36.0117 (UTC) FILETIME=[CD41EA50:01C66E61] X-Spam-Score: -2.4 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id k433TgNq028381 Cc: saag@mit.edu Subject: Re: [saag] IPsec spec problems X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2006 03:29:42 -0000 > So, would you or someone at Cisco be willing to work on a > document giving implementation guidance or perhaps better yet > operational requirements for security solutions that protect > against active attack and that have reasonable DOS properties? > > I think if we had a reasonable set of operational > requirements we could work on getting customers to demand > those requirements in products. Check out this RFC and talk George out to lunch at the next IETF to see how and why he is not a frequent IETFer. 3871 Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure. G. Jones, Ed.. September 2004. (Format: TXT=151101 bytes) (Status: INFORMATIONAL) You can also check out: ftp://ftp-eng.cisco.com/cons/isp/security/SP-Security-Empowerment-Materi als-1.pdf Which points to a whole bunch of work we're doing in the SP Security community (we're = to the larger SP Security community - not just Cisco). From hartmans@MIT.EDU Tue May 2 23:44:35 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k433iZtT030513 for ; Tue, 2 May 2006 23:44:35 -0400 Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k433iYR6003449 for ; Tue, 2 May 2006 23:44:34 -0400 (EDT) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 602D4E0053; Tue, 2 May 2006 23:44:28 -0400 (EDT) To: "Barry Greene (bgreene)" References: From: Sam Hartman Date: Tue, 02 May 2006 23:44:28 -0400 In-Reply-To: (Barry Greene's message of "Tue, 2 May 2006 20:29:23 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 1.352 X-Spam-Level: * (1.352) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Russ Housley Subject: Re: [saag] Fwd: draft-bonica-tcp-auth X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2006 03:44:36 -0000 I'm a bit confused by your context. I don't understand why a checksum at the TCP layer won't provide protection against man-in-the-middle attacks. --Sam From Eric.Gray@marconi.com Wed May 3 10:38:13 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k43EcDuN005480 for ; Wed, 3 May 2006 10:38:13 -0400 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k43Eao56008271; Wed, 3 May 2006 10:36:50 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k43ETJx4017901; Wed, 3 May 2006 10:29:19 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA27442; Wed, 3 May 2006 10:29:18 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id ; Wed, 3 May 2006 10:29:18 -0400 Message-ID: <313680C9A886D511A06000204840E1CF0DDAF64D@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" To: Sam Hartman , "Barry Greene (bgreene)" Date: Wed, 3 May 2006 10:29:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Russ Housley Subject: Re: [saag] Fwd: draft-bonica-tcp-auth X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2006 14:38:14 -0000 Sam, I don't understand this question. Barry said nothing about checksums in his last post on this topic and indicated that a man in the middle attack is not a threat that the industry is worried about. I have to assume this question stems from Barry's kast post as you did not include historical context below... -- Eric --> -----Original Message----- --> From: saag-bounces@MIT.EDU [mailto:saag-bounces@MIT.EDU] On --> Behalf Of Sam Hartman --> Sent: Tuesday, May 02, 2006 11:44 PM --> To: Barry Greene (bgreene) --> Cc: saag@MIT.EDU; Russ Housley --> Subject: Re: [saag] Fwd: draft-bonica-tcp-auth --> --> I'm a bit confused by your context. I don't understand why --> a checksum --> at the TCP layer won't provide protection against man-in-the-middle --> attacks. --> --> --> --Sam --> _______________________________________________ --> saag mailing list --> saag@mit.edu --> http://mailman.mit.edu/mailman/listinfo/saag --> From hartmans@MIT.EDU Wed May 3 12:16:28 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k43GGS3D022394 for ; Wed, 3 May 2006 12:16:28 -0400 Received: from carter-zimmerman.mit.edu (carter-zimmerman.dyn.mit.edu [18.188.3.148]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k43GGNQ8004791 for ; Wed, 3 May 2006 12:16:23 -0400 (EDT) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 463C9E006A; Wed, 3 May 2006 12:16:21 -0400 (EDT) To: "Gray, Eric" References: <313680C9A886D511A06000204840E1CF0DDAF64D@whq-msgusr-02.pit.comms.marconi.com> From: Sam Hartman Date: Wed, 03 May 2006 12:16:21 -0400 In-Reply-To: <313680C9A886D511A06000204840E1CF0DDAF64D@whq-msgusr-02.pit.comms.marconi.com> (Eric Gray's message of "Wed, 3 May 2006 10:29:14 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 1.217 X-Spam-Level: * (1.217) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Russ Housley Subject: Re: [saag] Fwd: draft-bonica-tcp-auth X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2006 16:16:29 -0000 >>>>> "Gray," == Gray, Eric writes: Gray,> Sam, I don't understand this question. Barry said nothing Gray,> about checksums in his last post on this topic and His entire post was about a mechanism using a MAC in TCP to protect BGP. Gray,> indicated that a man in the middle attack is not a threat Gray,> that the industry is worried about. And thus I was surprised that he was advocating a solution that seemed to protect against MITM. From kent@bbn.com Wed May 3 17:38:50 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k43LcoTZ009971 for ; Wed, 3 May 2006 17:38:50 -0400 Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k43Lcjj3002965 for ; Wed, 3 May 2006 17:38:45 -0400 (EDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.81.115.240]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1FbP3V-00015T-4D; Wed, 03 May 2006 17:38:45 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 3 May 2006 17:26:20 -0400 To: "Barry Greene \(bgreene\)" From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] IPsec spec problems X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2006 21:38:50 -0000 At 8:29 PM -0700 5/2/06, Barry Greene \(bgreene\) wrote: > > >> For example, if one believes that attackers are not capable >> of a MITM attack, then one could implement a simple, fast >> check of the SPI associated with each IPsec (ESP) packet, on >> a line card. Thus off-path attacks would be rejected >> efficiently. Alternatively, if future management processors >> had adequate horsepower to process IPsec traffic at high >> speeds, e.g., via hardware assist, then the problem would >> vanish as well. > >I've explored that path. Too complicated to code and high on the >maintenance side (too big of OPEX increase). > I appreciate your exploration of the option relative to your in-depth knowledge of Cisco implementations, but I hope you'll understand if I suggest that a broader evaluation of what is and is not viable is what is needed when we consider options for IETF standards. Steve From kent@bbn.com Wed May 3 17:38:53 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k43LcqM6009978 for ; Wed, 3 May 2006 17:38:52 -0400 Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k43LcowM013113 for ; Wed, 3 May 2006 17:38:51 -0400 (EDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.81.115.240]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1FbP3a-00015T-3r; Wed, 03 May 2006 17:38:50 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <6.2.5.6.2.20060502145206.05a6e4f8@qualcomm.com> References: <6.2.5.6.2.20060502093853.058c5948@qualcomm.com> <6.2.5.6.2.20060502145206.05a6e4f8@qualcomm.com> Date: Wed, 3 May 2006 17:28:56 -0400 To: Lakshminath Dondeti From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, ietf-rtpsec@imc.org, David McGrew , AVT Subject: Re: [saag] The use of AES-192 and AES-256 in Secure RTP X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2006 21:38:58 -0000 I'm not a cryptographer, but I generally advise against encouraging users to employ AES with 256-bit keys. The 256-bit key size is there primarily as a hedge against the future development of quantum computers. Since there are some performance costs with the use of big keys, it seems unnecessary to adopt them at this time. Steve From ho@alum.mit.edu Wed May 3 18:19:08 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k43MJ8WU016517 for ; Wed, 3 May 2006 18:19:08 -0400 Received: from mail.rfburst.com (mail.rfburst.com [66.119.143.51]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k43MJ2r7007060 for ; Wed, 3 May 2006 18:19:03 -0400 (EDT) Received: from localhost.localdomain (rfb135-195.radioburst.com [66.119.135.195] (may be forged)) by mail.rfburst.com (8.12.8/8.12.8) with ESMTP id k43MIsfx020996; Wed, 3 May 2006 16:18:54 -0600 Received: from localhost.localdomain (tobermory [127.0.0.1]) by localhost.localdomain (8.12.10/8.11.6) with ESMTP id k43MHISg012291; Wed, 3 May 2006 16:17:18 -0600 Received: (from ho@localhost) by localhost.localdomain (8.12.10/8.12.10/Submit) id k43MHI7Y012287; Wed, 3 May 2006 16:17:18 -0600 Date: Wed, 3 May 2006 16:17:18 -0600 Message-Id: <200605032217.k43MHI7Y012287@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: ietf-rtpsec@imc.org, saag@mit.edu In-reply-to: Yourmessage X-esmartscan-MailScanner-Information: Please contact the ISP for more information X-esmartscan-MailScanner: Found to be clean X-MailScanner-From: ho@alum.mit.edu X-Spam-Score: 1.352 X-Spam-Level: * (1.352) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: Re: [saag] The use of AES-192 and AES-256 in Secure RTP X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "The Purple Streak, Hilarie Orman" List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2006 22:19:09 -0000 I agree with Steve Kent on the issue of not encouraging use of AES with large key sizes. It gives the impression that there's some immediate need for larger keys. There isn't. Hilarie From ldondeti@qualcomm.com Wed May 3 18:25:51 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k43MPpMO017701 for ; Wed, 3 May 2006 18:25:51 -0400 Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k43MPnXa017291 for ; Wed, 3 May 2006 18:25:49 -0400 (EDT) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k43MPJUL018537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 3 May 2006 15:25:20 -0700 Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.20]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k43MPFgX002697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 May 2006 15:25:18 -0700 (PDT) Message-Id: <6.2.5.6.2.20060503152108.05722e58@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 03 May 2006 15:25:13 -0700 To: Stephen Kent From: Lakshminath Dondeti In-Reply-To: References: <6.2.5.6.2.20060502093853.058c5948@qualcomm.com> <6.2.5.6.2.20060502145206.05a6e4f8@qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, ietf-rtpsec@imc.org, David McGrew , AVT Subject: Re: [saag] The use of AES-192 and AES-256 in Secure RTP X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2006 22:25:51 -0000 Hi Steve, It all started with David's notes copy-pasted below: ++++++++ there has been some interest in using AES with larger key sizes in Secure RTP, and some implementations have gone in this direction in advance of any specification. I wrote up an internet draft to fill this gap (after trying unsuccessfully to get someone else to write it :-) and to provide usage guidance and (eventually) test vectors. +++++++ It looks like all we are doing at the IETF is to specify; business as usual :-). We could add a recommendation along the lines you propose below. regards, Lakshminath At 02:28 PM 5/3/2006, Stephen Kent wrote: >I'm not a cryptographer, but I generally advise against encouraging >users to employ AES with 256-bit keys. The 256-bit key size is there >primarily as a hedge against the future development of quantum >computers. Since there are some performance costs with the use of >big keys, it seems unnecessary to adopt them at this time. > >Steve From kent@bbn.com Wed May 3 18:31:06 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k43MV6d6018547 for ; Wed, 3 May 2006 18:31:06 -0400 Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k43MV4Ex023789 for ; Wed, 3 May 2006 18:31:04 -0400 (EDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.81.115.240]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1FbPs8-0001Zc-40; Wed, 03 May 2006 18:31:04 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <6.2.5.6.2.20060503152108.05722e58@qualcomm.com> References: <6.2.5.6.2.20060502093853.058c5948@qualcomm.com> <6.2.5.6.2.20060502145206.05a6e4f8@qualcomm.com> <6.2.5.6.2.20060503152108.05722e58@qualcomm.com> Date: Wed, 3 May 2006 18:31:00 -0400 To: Lakshminath Dondeti From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, ietf-rtpsec@imc.org, David McGrew , AVT Subject: Re: [saag] The use of AES-192 and AES-256 in Secure RTP X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2006 22:31:06 -0000 At 3:25 PM -0700 5/3/06, Lakshminath Dondeti wrote: >Hi Steve, > >It all started with David's notes copy-pasted below: > >++++++++ >there has been some interest in using AES with larger key sizes in >Secure RTP, and some implementations have gone in this direction in >advance of any specification. I wrote up an internet draft to fill >this gap (after trying unsuccessfully to get someone else to write >it :-) and to provide usage guidance and (eventually) test vectors. >+++++++ > >It looks like all we are doing at the IETF is to specify; business >as usual :-). We could add a recommendation along the lines you >propose below. > >regards, >Lakshminath If we decide that we need to specify how to use 256-bit keys, then we at least owe it to users to explain why they might not wish to take advantage of that capability. So, yes, adding suitable text would make me feel more comfortable. thanks, Steve From ldondeti@qualcomm.com Wed May 3 18:35:34 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k43MZYe4018920 for ; Wed, 3 May 2006 18:35:34 -0400 Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k43MZRwq018712 for ; Wed, 3 May 2006 18:35:28 -0400 (EDT) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k43MZDs4012371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 3 May 2006 15:35:13 -0700 Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.20]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k43MZBMC006413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 May 2006 15:35:12 -0700 (PDT) Message-Id: <6.2.5.6.2.20060503152702.05572e70@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 03 May 2006 15:35:08 -0700 To: "The Purple Streak, Hilarie Orman" , ietf-rtpsec@imc.org, saag@mit.edu From: Lakshminath Dondeti In-Reply-To: <200605032217.k43MHI7Y012287@localhost.localdomain> References: <200605032217.k43MHI7Y012287@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: Re: [saag] The use of AES-192 and AES-256 in Secure RTP X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2006 22:35:34 -0000 Following up further, I just checked if there is a precedence, and 3268 says the following: The AES supports key lengths of 128, 192 and 256 bits. However, this document only defines ciphersuites for 128- and 256-bit keys. This is to avoid unnecessary proliferation of ciphersuites. Rijndael actually allows for 192- and 256-bit block sizes as well as the 128- bit blocks mandated by the AES process. The ciphersuites defined here all use 128-bit blocks. (Note: some of that is relevant to the discussion on whether or not 192-bit keys need to be defined for SRTP. 3268 thought not, I think we should, but anyway, back to the matter at hand). 3268 defines AES-256 usage for TLS and that was in 2002! So, we are past giving any impressions, aren't we? 3686 is another example! regards, Lakshminath At 03:17 PM 5/3/2006, The Purple Streak, Hilarie Orman wrote: >I agree with Steve Kent on the issue of not encouraging use of AES >with large key sizes. It gives the impression that there's some >immediate need for larger keys. There isn't. > >Hilarie From smb@cs.columbia.edu Wed May 3 19:40:34 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k43NeXWM028743 for ; Wed, 3 May 2006 19:40:33 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k43NeVV4010954 for ; Wed, 3 May 2006 19:40:32 -0400 (EDT) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 72BBAFB2CE; Wed, 3 May 2006 19:40:30 -0400 (EDT) Received: by berkshire.machshav.com (Postfix, from userid 54047) id 629943C01D8; Wed, 3 May 2006 19:08:01 -0400 (EDT) Date: Wed, 3 May 2006 19:08:01 -0400 From: "Steven M. Bellovin" To: Stephen Kent Message-Id: <20060503190801.51649ebb.smb@cs.columbia.edu> In-Reply-To: References: <6.2.5.6.2.20060502093853.058c5948@qualcomm.com> <6.2.5.6.2.20060502145206.05a6e4f8@qualcomm.com> Organization: Columbia University X-Mailer: Sylpheed version 2.2.4 (GTK+ 2.8.17; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 1.217 X-Spam-Level: * (1.217) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, ietf-rtpsec@imc.org, mcgrew@cisco.com, ldondeti@qualcomm.com, avt@ietf.org Subject: Re: [saag] The use of AES-192 and AES-256 in Secure RTP X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2006 23:40:34 -0000 On Wed, 3 May 2006 17:28:56 -0400, Stephen Kent wrote: > I'm not a cryptographer, but I generally advise against encouraging > users to employ AES with 256-bit keys. The 256-bit key size is there > primarily as a hedge against the future development of quantum > computers. Since there are some performance costs with the use of big > keys, it seems unnecessary to adopt them at this time. > And even NSA recommends against 192-bit keys, preferring 128 for SECRET and 256 for TOP SECRET. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb From paul.hoffman@vpnc.org Wed May 3 20:53:47 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k440rlKb008154 for ; Wed, 3 May 2006 20:53:47 -0400 Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k440rh2e015997 for ; Wed, 3 May 2006 20:53:44 -0400 (EDT) Received: from [10.0.6.56] (host227.sprintnetops.net [63.164.47.227] (may be forged)) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k440rYYF057359; Wed, 3 May 2006 17:53:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <200605032217.k43MHI7Y012287@localhost.localdomain> References: <200605032217.k43MHI7Y012287@localhost.localdomain> Date: Wed, 3 May 2006 17:53:28 -0700 To: "The Purple Streak, Hilarie Orman" , ietf-rtpsec@imc.org, saag@mit.edu From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: Re: [saag] The use of AES-192 and AES-256 in Secure RTP X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2006 00:53:47 -0000 At 4:17 PM -0600 5/3/06, The Purple Streak, Hilarie Orman wrote: >I agree with Steve Kent on the issue of not encouraging use of AES >with large key sizes. It gives the impression that there's some >immediate need for larger keys. There isn't. lists the requirements for one particular customer of significant size who insists on the use of 256-bit (but not 192-bit) keys. --Paul Hoffman, Director --VPN Consortium From ho@alum.mit.edu Wed May 3 22:38:26 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k442cPKU027850 for ; Wed, 3 May 2006 22:38:25 -0400 Received: from mail.rfburst.com (mail.rfburst.com [66.119.143.51]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k442cO80012294 for ; Wed, 3 May 2006 22:38:24 -0400 (EDT) Received: from localhost.localdomain (rfb135-195.radioburst.com [66.119.135.195] (may be forged)) by mail.rfburst.com (8.12.8/8.12.8) with ESMTP id k442cGfx010385; Wed, 3 May 2006 20:38:16 -0600 Received: from localhost.localdomain (tobermory [127.0.0.1]) by localhost.localdomain (8.12.10/8.11.6) with ESMTP id k442afSg024547; Wed, 3 May 2006 20:36:41 -0600 Received: (from ho@localhost) by localhost.localdomain (8.12.10/8.12.10/Submit) id k442aeST024543; Wed, 3 May 2006 20:36:40 -0600 Date: Wed, 3 May 2006 20:36:40 -0600 Message-Id: <200605040236.k442aeST024543@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: paul.hoffman@vpnc.org In-reply-to: Yourmessage X-esmartscan-MailScanner-Information: Please contact the ISP for more information X-esmartscan-MailScanner: Found to be clean X-MailScanner-From: ho@alum.mit.edu X-Spam-Score: 1.352 X-Spam-Level: * (1.352) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, ietf-rtpsec@imc.org Subject: Re: [saag] The use of AES-192 and AES-256 in Secure RTP X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Reply-To: "The Purple Streak, Hilarie Orman" List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2006 02:38:27 -0000 The large customer behind Suite B can't provide much guidance to us re AES 256. Do they want more rounds or more entropy? Or just something different? Signup for zero crypto growth --- stop at 128! Hilarie From bgreene@cisco.com Tue Apr 25 10:36:41 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k3PEafOr009618 for ; Tue, 25 Apr 2006 10:36:41 -0400 Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k3PEZSUt013756 for ; Tue, 25 Apr 2006 10:35:28 -0400 (EDT) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 25 Apr 2006 07:35:28 -0700 X-IronPort-AV: i="4.04,153,1144047600"; d="scan'208"; a="425121104:sNHT34095972" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k3PEZSw1018378; Tue, 25 Apr 2006 07:35:28 -0700 (PDT) Received: from xmb-sjc-227.amer.cisco.com ([128.107.191.43]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Apr 2006 07:35:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 25 Apr 2006 07:35:27 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] IPsec spec problems Thread-Index: AcZoZ7YbEX55il6ZQOaazTobPXk5TwAAeSsAAAJahWA= From: "Barry Greene \(bgreene\)" To: , X-OriginalArrivalTime: 25 Apr 2006 14:35:28.0085 (UTC) FILETIME=[7F2E7050:01C66875] X-Spam-Score: -2.4 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id k3PEafOr009618 X-Mailman-Approved-At: Thu, 04 May 2006 05:39:05 -0400 Subject: Re: [saag] IPsec spec problems X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2006 14:36:41 -0000 > The situation is not this bad. It is worse. People ask me about doing IPSEC to protection routing protocols all the time. The irony is that you are better off NOT doing IPSEC - since the perceived risk you are protecting against (man in the middle snooping) eliminates all point protection to the control plane protocol. The result is that the router is MORE vulnerable to attack with IPSEC than with it turned on. You cannot wait until the packet arrives to the core processes on the RP of the router before you classify, queue, and police the packet. In fact, router vendors should be doing this classify/queue/police multiple times (i.e. layered security) starting as close to the L2/L3 as possible (i.e. first phases of the ASIC). One of these days people going to the IETF WGs will get out of the arm chairs, get in the lab, and attack routers to see how things really work. > -----Original Message----- > From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu] On > Behalf Of Pasi.Eronen@nokia.com > Sent: Tuesday, April 25, 2006 6:43 AM > To: saag@mit.edu > Subject: Re: [saag] IPsec spec problems > > Pekka Savola wrote: > > > > I actually read RFC 4301 for the first time on a plane (for the > > record, I had not read any IPsec RFCs previously). The > situation was > > much worse than I thought. One could say that the IPsec > spec is not > > optimized for control plane protection with all of its crazy talk > > about protected/unprotected interfaces, non-native implementations, > > etc. > > > > My perception is that IPsec spec tries to address too many problems > > (minimal firewall policing through SPDs; control traffic > protection; > > VPN protection), and the result is too complex that it isn't useful > > for anything except VPNs, and even that's pretty complicated due to > > all the baggage. > > > > I was also boggled by the notion that an IPsec implementation at a > > router would have to inspect ALL packets it forwards > (whether IPsec or > > not) against SPD. That means IPsec would need to be implemented on > > all the linecards even if all you wanted is to protect the control > > plane. > > > > Saner alternative: whether to look for SPDs for particular packet > > should be keyed off from the routing table entries. That > way IPsec is > > only consulted when it needs to be consulted. > > The situation is not this bad. Yes, you're required to > inspect all packets crossing the IPsec boundary (between > unprotected and protected interfaces), but where exactly this > boundary is placed can vary. > > In a router that uses IPsec only for its control traffic (and > thus is really a host instead of a gateway from IPsec > perspective), the protected interface could be the part of > the stack delivering packets to/from local control plane > daemons. Thus, packets simply being forwarded by line cards > would not cross the IPsec boundary at all. > > But yes, things get more complicated if the router also does > IPsec for forwarded packets... although you might simplify > things if you consider the router to have multiple logically > separate IPsec implementations (as suggested in Section 3.3 > of RFC 4301). > > Best regards, > Pasi > > _______________________________________________ > saag mailing list > saag@mit.edu > http://mailman.mit.edu/mailman/listinfo/saag > From rporter@covergence.com Wed May 3 22:20:35 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k442KZ5x025416 for ; Wed, 3 May 2006 22:20:35 -0400 Received: from mail.covergence.com ([63.110.43.12]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k442KZlm016939 for ; Wed, 3 May 2006 22:20:35 -0400 (EDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 3 May 2006 22:18:57 -0400 Message-ID: <0D1719326D64BD4E9F92A0C120237678CEEE6F@eserv.covergence.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] The use of AES-192 and AES-256 in Secure RTP Thread-Index: AcZvFY0LNUYOBIbmTluSEYNvWDYkCQAA/2Eg From: "Rick Porter" To: "Paul Hoffman" , "The Purple Streak, Hilarie Orman" , , X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id k442KZ5x025416 X-Mailman-Approved-At: Thu, 04 May 2006 05:39:05 -0400 Subject: Re: [saag] The use of AES-192 and AES-256 in Secure RTP X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2006 02:20:36 -0000 I was surprised to see Suite B appear on someone's radar... IMO, most aspects of SRTP would not meet the standards for Suite B certification. The key exchange seems to be the most blatantly lacking, but there are other aspects. Let me point out that the Suite B link does not even mention which mode(s) of AES are acceptable (e.g. counter, cbc, ecb, wrap). I do not have a strong opinion about whether or not to specify longer AES key lengths. However, I would not specify longer key lengths just to comply with the Suite B standards--NSA is probably going to require deviation from the IETF standard(s) anyway. NSA has its own set of requirements (and reasons for them), and they also have a number of government contractors who develop products to meet those requirements. Cheers, Rick From mcgrew@cisco.com Thu May 4 07:18:53 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k44BIqbi017817 for ; Thu, 4 May 2006 07:18:53 -0400 Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k44BEVAX015696 for ; Thu, 4 May 2006 07:14:31 -0400 (EDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 04 May 2006 04:14:31 -0700 X-IronPort-AV: i="4.05,87,1146466800"; d="scan'208"; a="1801274965:sNHT30355844" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k44BEURT021444; Thu, 4 May 2006 04:14:30 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 May 2006 04:14:30 -0700 Received: from [192.168.1.100] ([10.32.254.210]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 May 2006 04:14:29 -0700 In-Reply-To: References: <6.2.5.6.2.20060502093853.058c5948@qualcomm.com> <6.2.5.6.2.20060502145206.05a6e4f8@qualcomm.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5ABD5019-6481-45A1-A981-4BE362E190F8@cisco.com> Content-Transfer-Encoding: 7bit From: David McGrew Date: Thu, 4 May 2006 04:14:26 -0700 To: Stephen Kent X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 04 May 2006 11:14:29.0323 (UTC) FILETIME=[E95121B0:01C66F6B] X-Spam-Score: -0.001 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, ietf-rtpsec@imc.org, Lakshminath Dondeti , AVT Subject: Re: [saag] The use of AES-192 and AES-256 in Secure RTP X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2006 11:18:54 -0000 Hi Steve, I pretty much agree. The reason that I wrote up the draft is because it's been implemented (see http://sourceforge.net/mailarchive/ forum.php?thread_id=9620686&forum_id=9697) and it's been referred to in internet drafts (Section 4.1.3 of draft-zimmermann-avt- zrtp-01.txt), even though it's not been specified. There is an important implementation detail (when using AES-XYZ for encryption, use AES-XYZ for key derivation) that won't be obvious to every implementer, so a spec is going to provide some value (even if we do decide that we don't want for AES-256 in SRTP to become a standard). One reason that I can think of for implementing AES-256 in this case would be to conform to Suite B "TOP SECRET". But there are not many other good reasons for implementing that key size at the present time. The spec does promote algorithm agility, which is a good thing. I guess that the trick is to provide for that agility without making interoperability harder. I tried to do address the interoperability issue in the draft by pointing out that AES-256 is an addition to, not a replacement for, for AES-128. I also tried to write the security considerations in such a way that encourages the use of AES-128. The bigger key sizes are a hedge, as you put it, and for almost all uses they are not needed at present. At least I tried to convey that impression - I'd value comments from readers, and I'd be happy to add or modify text in this direction. David On May 3, 2006, at 2:28 PM, Stephen Kent wrote: > I'm not a cryptographer, but I generally advise against encouraging > users to employ AES with 256-bit keys. The 256-bit key size is > there primarily as a hedge against the future development of > quantum computers. Since there are some performance costs with the > use of big keys, it seems unnecessary to adopt them at this time. > > Steve From mcgrew@cisco.com Thu May 4 09:35:19 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k44DZJEu022372 for ; Thu, 4 May 2006 09:35:19 -0400 Received: from test-iport-2.cisco.com (test-iport-2.cisco.com [171.71.176.105]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k44DZ83T016288 for ; Thu, 4 May 2006 09:35:09 -0400 (EDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by test-iport-2.cisco.com with ESMTP; 04 May 2006 06:35:08 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k44DZ8h0010277; Thu, 4 May 2006 06:35:08 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 May 2006 06:35:08 -0700 Received: from [192.168.1.100] ([10.32.254.210]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 May 2006 06:35:07 -0700 In-Reply-To: <0D1719326D64BD4E9F92A0C120237678CEEE6F@eserv.covergence.com> References: <0D1719326D64BD4E9F92A0C120237678CEEE6F@eserv.covergence.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0F96E748-048A-4959-832F-6685E49E0EBE@cisco.com> Content-Transfer-Encoding: 7bit From: David McGrew Date: Thu, 4 May 2006 06:35:06 -0700 To: Rick Porter X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 04 May 2006 13:35:07.0964 (UTC) FILETIME=[8F238FC0:01C66F7F] X-Spam-Score: -2.6 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, ietf-rtpsec@imc.org, AVT Subject: Re: [saag] The use of AES-192 and AES-256 in Secure RTP X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2006 13:35:19 -0000 Hi Rick, On May 3, 2006, at 7:18 PM, Rick Porter wrote: > > I was surprised to see Suite B appear on someone's radar... > > IMO, most aspects of SRTP would not meet the standards for Suite B > certification. The key exchange seems to be the most blatantly > lacking, > but there are other aspects. you are right that there is probably no standardized way to provide keys to SRTP that would meet the Suite B guidelines. But this doesn't imply that we shouldn't specify a Suite B conformant profile for SRTP (since we don't want to create a chicken-or-egg-first? situation). Also, some of the proposed key management methods do incorporate or admit FIPS-140/Suite B approved key establishment methods (for example, DTLS-SRTP could be used with one of the ECC methods currently being drafted for TLS). > Let me point out that the Suite B link does > not even mention which mode(s) of AES are acceptable (e.g. counter, > cbc, > ecb, wrap). > You're right that Suite B is underspecified, and it would be reassuring to get more details about it. (I prefer "underspecified" to "overly narrow" though :-) > I do not have a strong opinion about whether or not to specify longer > AES key lengths. However, I would not specify longer key lengths > just to > comply with the Suite B standards--NSA is probably going to require > deviation from the IETF standard(s) anyway. NSA has its own set of > requirements (and reasons for them), and they also have a number of > government contractors who develop products to meet those > requirements. True, but I would rather work with Suite B and try to promote broader interoperability. I think that the big value of Suite B is that it will enable interoperability between the high-assurance implementations that you mention and commercial standards-based implementations. This is an obvious gain for the high-assurance community, and it could also benefit the commercial community. But I'm getting off topic here; Suite B is worth discussing, but the use of elliptic curve crypto is the most important topic there, not SRTP key sizes ;-) David > > > Cheers, > Rick From mcgrew@cisco.com Thu May 4 09:57:46 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k44Dvkiu026513 for ; Thu, 4 May 2006 09:57:46 -0400 Received: from test-iport-3.cisco.com (test-iport-3.cisco.com [171.71.176.78]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k44DvjdO028391 for ; Thu, 4 May 2006 09:57:46 -0400 (EDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by test-iport-3.cisco.com with ESMTP; 04 May 2006 06:57:45 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k44DvjRT009747; Thu, 4 May 2006 06:57:45 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 May 2006 06:57:45 -0700 Received: from [192.168.1.100] ([10.32.254.210]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 May 2006 06:57:44 -0700 In-Reply-To: <200605040236.k442aeST024543@localhost.localdomain> References: <200605040236.k442aeST024543@localhost.localdomain> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <73C7FC51-5717-46AB-8B4A-F3842C855D6D@cisco.com> Content-Transfer-Encoding: 7bit From: David McGrew Date: Thu, 4 May 2006 06:57:42 -0700 To: "The Purple Streak, Hilarie Orman" X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 04 May 2006 13:57:44.0730 (UTC) FILETIME=[B7D59FA0:01C66F82] X-Spam-Score: -2.4 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, ietf-rtpsec@imc.org Subject: Re: [saag] The use of AES-192 and AES-256 in Secure RTP X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2006 13:57:46 -0000 Hi Hilarie, On May 3, 2006, at 7:36 PM, The Purple Streak, Hilarie Orman wrote: > > The large customer behind Suite B can't provide much guidance > to us re AES 256. Do they want more rounds or more entropy? > Or just something different? > I believe that the best motivation for AES-256 is as a hedge, as Steve put it, in case of unforeseen advances in cryptanalysis (quantum computers, new attack algorithms, and so on). > Signup for zero crypto growth --- stop at 128! > Ha! I like that. For sure a 128-bit security level is a suitable goal. But the hedging is intended to provide us with protection in case AES-128 doesn't actually meet that security goal. That's my understanding anyway. But I think that your main point is that we don't need to implement AES-256 in order for it to have value as a hedge. This is valid. Perhaps the real motivation for the use of AES-256 by the high- assurance community is that, considering that their crypto gear is quite expensive due to their stringent development and manufacturing processes, the additional cost for supporting bigger key sizes is inconsequential ;-) David From mcgrew@cisco.com Thu May 4 10:11:45 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k44EBjJJ029029 for ; Thu, 4 May 2006 10:11:45 -0400 Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k44EBcoe008231 for ; Thu, 4 May 2006 10:11:39 -0400 (EDT) Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 04 May 2006 07:11:39 -0700 X-IronPort-AV: i="4.05,88,1146466800"; d="scan'208"; a="272699724:sNHT33693932" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k44EBcYg008628; Thu, 4 May 2006 07:11:38 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 May 2006 07:11:38 -0700 Received: from [192.168.1.100] ([10.32.254.210]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 May 2006 07:11:37 -0700 In-Reply-To: <6.2.5.6.2.20060502145206.05a6e4f8@qualcomm.com> References: <6.2.5.6.2.20060502093853.058c5948@qualcomm.com> <6.2.5.6.2.20060502145206.05a6e4f8@qualcomm.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <475941AD-07C3-47CE-9B0F-F8FE7616887E@cisco.com> Content-Transfer-Encoding: 7bit From: David McGrew Date: Thu, 4 May 2006 07:11:35 -0700 To: Lakshminath Dondeti X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 04 May 2006 14:11:37.0511 (UTC) FILETIME=[A835EB70:01C66F84] X-Spam-Score: -2.4 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, ietf-rtpsec@imc.org, AVT Subject: Re: [saag] The use of AES-192 and AES-256 in Secure RTP X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2006 14:11:45 -0000 Hi Lakshminath, a couple of comments inline: On May 2, 2006, at 3:08 PM, Lakshminath Dondeti wrote: > Hi David, > > Thanks for the clarifications. Please see inline for some follow- > up notes: > > At 01:41 PM 5/2/2006, David McGrew wrote: >> Hi Lakshminath, >> >> thanks for your comments, more inline: >> >> On May 2, 2006, at 9:50 AM, Lakshminath Dondeti wrote: >> >>> Hi David, >>> >>> As I read the email, I wondered about replacing HMAC-SHA-1 in 3711 >>> also, and glad to see that your open questions lists that. I have >>> a few questions: >>> >>> 1. Is the 112-bit salt sufficient even with longer keys? You might >>> recall that we've (Mark B., you and I) had discussions on the >>> master key and salt being input to a KDF that results in the >>> derivation of the encr_key, integ_key and a salt, where the output >>> might be longer than the input to the KDF. You are the expert in >>> this area, but I am still wondering if it is an issue. >> >> I think that the 112-bit salt is sufficient. The srtp salt is >> present so that the srtp use of counter mode is essentially as secure >> as CBC mode against attacks that amortize computational effort over >> multiple target keys. This property still holds for the larger key >> sizes. Besides, there's not much that we can do to increase the salt >> length, since there are only 16 more bits that we could possibly >> add. I also think that it is valuable to retain counter-format >> compatibility with the AES-128 counter mode. > > Ok, I understand the limitation on the salt size (also see below > about my misunderstanding of the block size in AES). I also > understand the aspect of offsetting counter-mode's relative key > strength using the salt and that for that purpose 112-bit salt is > sufficient. > > What about using a 128, 192, or 256-bit master key and 112-bit salt > to derive a 128, 192, 256-bit encryption key and a 160-bit, 256-bit > (assuming SHA-1 or SHA-2) and a session salt key (this is 112-bits > in size, right?)? Is entropy or lack thereof is a consideration. That's a good question. I believe that the way that there aren't any problems with the way that key derivation is defined, but it deserves some text in the security considerations. > > > >>> Figure 2 applies to AES-128 only, right? >> >> No, it's for all of the key sizes. AES-192 and AES-256 still have 16 >> byte plaintexts. Or maybe I'm not understanding; did I mislabel >> something? > > No, my mistake. I forgot that AES uses 128-bit blocks irrespective > of the key size. Apologies. > > >>> 2. I would suggest that this draft include AES-based CMAC, so we >>> can move away from SHA-1 and also use a single crypto primitive for >>> encryption, and PRF and MAC computation (opinion on your open >>> question). >> >> We think alike :-) I implemented AES CMAC for SRTP and found that it >> performs better than HMAC-SHA1 for very short packets (like those for >> conversational voice over a WAN) but not long packets (like video). >> It also has some other advantages. But OTOH there is a cost to >> proliferating cryptoalgorithms. Let's start up a separate thread on >> CMAC. > > We did talk about it before. The concept of using the same crypto > primitive came up elsewhere and that sounds like a good idea. > Please start that thread of discussion. Will do, but it may take a week. > > > >>> Q: What are the considerations in truncating cipher-based MAC >>> outputs? Specifically, is truncating below half-the-size of the >>> output (which I vaguely recall as relating to the birthday attack >>> in case of hash-based MACs -- perhaps it is not) of the cipher- >>> based MAC ok? >> >> Ah, good points. The NIST CMAC specification disallows truncation to >> MACs shorter than 64 bits. This is not because CMAC is weaker than >> an ideal MAC with respect to truncation, though. CMAC has been shown >> to be a good pseudorandom function if AES is a good blockcipher (as >> long as some usage limits are respected), and a PRF essentially is an >> ideal MAC. I'm pretty sure that the CMAC specification insists on >> MACs of at least 64 bits because it feels that a per-MAC forgery >> probability greater than 2^64 is not acceptable. No doubt they were >> not considering the case of stateless codecs, which some SRTP users >> need only 32-bit MACs. It is an interesting question as to what tag >> sizes would be recommended for use with CMAC! > > Let me think more about this. > > >>> What would be the strength of the MAC in that case. If we are >>> making a case for AES-192 or AES-256, then we have a certain >>> stronger adversary in mind (one that requires us to move away from >>> AES-128). In that case, why is MAC truncation not an issue? >> >> That's a good question. I think that in some circumstances it could >> make sense to use a short authentication tag and a huge key. If some >> unanticipated advance in cryptanalysis enables us to break AES-128 >> but not AES-256, but some user is still okay with accepting one out >> of a billion forged g.711 packets, this scenario would fit the bill. >> So the cryptosuites defined in the draft might make sense. But I >> take your point that users concerned that AES-128 doesn't have enough >> security may well not be satisfied with a 32-bit MAC. It would be >> good to get some input from the Suite B community on this question. > > Yes, we'll wait to hear from others. > > > >>> Let's discuss those for now. I may have more later :-). Thanks >>> for doing this! I was going to ask you about using CMAC in 3711! >> >> Any thoughts on whether or not AES-192 should be included? > > I think the use of AES-192 should be specified (at the expense of > more work for you :-) ), but let the "market" decide whether the > switch is to 192 or 256-bit keys. Actually, the draft does include AES-192, though at this point I'm inclined to remove it (TLS doesn't support it, as you pointed out :-) Not that it is a big deal, though. One approach that we could take would be to have the "big keys" draft say AES-256 is a MUST and AES-192 is a MAY. David > > regards, > Lakshminath > > >> David >> >>> regards, >>> Lakshminath >>> >>> At 08:15 AM 5/2/2006, David McGrew wrote: >>> >>>> Hello, >>>> >>>> there has been some interest in using AES with larger key sizes in >>>> Secure RTP, and some implementations have gone in this direction in >>>> advance of any specification. I wrote up an internet draft to fill >>>> this gap (after trying unsuccessfully to get someone else to write >>>> it :-) and to provide usage guidance and (eventually) test vectors. >>>> It's online at http://www.ietf.org/internet-drafts/draft-mcgrew- >>>> srtp- big-aes-00.txt >>>> >>>> I propose that this draft be adopted for standards track, and I ask >>>> for your review (if you have an interest in Secure RTP). Please >>>> note >>>> the "Open Questions" section. The ietf-rtpsec list is copied >>>> since >>>> this draft is potentially interesting there, even though the draft >>>> has little architectural impact. >>>> >>>> Best regards, >>>> >>>> David From kent@bbn.com Thu May 4 10:37:41 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k44Ebe0S002550 for ; Thu, 4 May 2006 10:37:40 -0400 Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k44EbJGJ019702 for ; Thu, 4 May 2006 10:37:20 -0400 (EDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.81.115.240]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1FbexC-0001Fe-6A; Thu, 04 May 2006 10:37:19 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <5ABD5019-6481-45A1-A981-4BE362E190F8@cisco.com> References: <6.2.5.6.2.20060502093853.058c5948@qualcomm.com> <6.2.5.6.2.20060502145206.05a6e4f8@qualcomm.com> <5ABD5019-6481-45A1-A981-4BE362E190F8@cisco.com> Date: Thu, 4 May 2006 10:36:39 -0400 To: David McGrew From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, ietf-rtpsec@imc.org, Lakshminath Dondeti , AVT Subject: Re: [saag] The use of AES-192 and AES-256 in Secure RTP X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2006 14:37:41 -0000 At 4:14 AM -0700 5/4/06, David McGrew wrote: >... >One reason that I can think of for implementing AES-256 in this case >would be to conform to Suite B "TOP SECRET". But there are not many >other good reasons for implementing that key size at the present >time. The spec does promote algorithm agility, which is a good >thing. I guess that the trick is to provide for that agility without >making interoperability harder. I tried to do address the >interoperability issue in the draft by pointing out that AES-256 is >an addition to, not a replacement for, for AES-128. I also tried to >write the security considerations in such a way that encourages the >use of AES-128. The bigger key sizes are a hedge, as you put it, and >for almost all uses they are not needed at present. At least I tried >to convey that impression - I'd value comments from readers, and I'd >be happy to add or modify text in this direction. David, I don't think Suite B is relevant here. To be approved for protecting classified data at the TS level, a product will have to meet a lot of requirements, and the algorithm and key size are two of the easiest ones to meet. SRTP is carefully engineered to minimize overhead, and for commercial applications the tradeoffs that were made re security seem reasonable. However, there is non indication that these tradeoffs are appropriate for use in the classified data protection area. I note that DoD folks are working hard on defining how to use ROHC with IPsec, and a primary motivation is to enable use of IPsec, as implemented in HAIPS-compliant devices, to protect voice traffic. That is indicative of the current view on the suitability of using SRTP as a primary security mechanism for classified VoIP apoplications. Steve From mcgrew@cisco.com Thu May 4 11:26:31 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k44FQVcs010867 for ; Thu, 4 May 2006 11:26:31 -0400 Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k44FQU3d009605 for ; Thu, 4 May 2006 11:26:30 -0400 (EDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 04 May 2006 08:26:30 -0700 X-IronPort-AV: i="4.05,89,1146466800"; d="scan'208"; a="426262600:sNHT31621694" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k44FQTRV004701; Thu, 4 May 2006 08:26:29 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 May 2006 08:26:29 -0700 Received: from [192.168.1.100] ([10.32.254.210]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 May 2006 08:26:28 -0700 In-Reply-To: References: <6.2.5.6.2.20060502093853.058c5948@qualcomm.com> <6.2.5.6.2.20060502145206.05a6e4f8@qualcomm.com> <5ABD5019-6481-45A1-A981-4BE362E190F8@cisco.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: David McGrew Date: Thu, 4 May 2006 08:26:25 -0700 To: Stephen Kent X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 04 May 2006 15:26:28.0886 (UTC) FILETIME=[1D475B60:01C66F8F] X-Spam-Score: -2.4 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, ietf-rtpsec@imc.org, AVT Subject: Re: [saag] The use of AES-192 and AES-256 in Secure RTP X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2006 15:26:32 -0000 Hi Steve, On May 4, 2006, at 7:36 AM, Stephen Kent wrote: > At 4:14 AM -0700 5/4/06, David McGrew wrote: >> ... >> One reason that I can think of for implementing AES-256 in this >> case would be to conform to Suite B "TOP SECRET". But there are >> not many other good reasons for implementing that key size at the >> present time. The spec does promote algorithm agility, which is a >> good thing. I guess that the trick is to provide for that agility >> without making interoperability harder. I tried to do address the >> interoperability issue in the draft by pointing out that AES-256 >> is an addition to, not a replacement for, for AES-128. I also >> tried to write the security considerations in such a way that >> encourages the use of AES-128. The bigger key sizes are a hedge, >> as you put it, and for almost all uses they are not needed at >> present. At least I tried to convey that impression - I'd value >> comments from readers, and I'd >> be happy to add or modify text in this direction. > > David, > > I don't think Suite B is relevant here. To be approved for > protecting classified data at the TS level, a product will have to > meet a lot of requirements, and the algorithm and key size are two > of the easiest ones to meet. I take your point here. At http://www.nsa.gov/ia/industry/ crypto_suite_b.cfm, we're told that a CMVP evaluation is all that's needed to protect unclassified information (at which level AES-128 is considered sufficient, but AES-256 is allowed), but an NSA evaluation is required for implementations that protect classified info (which would require AES-256). An important question is: will the adopters of Suite B for the protection of unclassified information regard AES-256 as desirable? > SRTP is carefully engineered to minimize overhead, and for > commercial applications the tradeoffs that were made re security > seem reasonable. However, there is non indication that these > tradeoffs are appropriate for use in the classified data protection > area. I note that DoD folks are working hard on defining how to > use ROHC with IPsec, and a primary motivation is to enable use of > IPsec, as implemented in HAIPS-compliant devices, to protect voice > traffic. For sure the interest in ROHC stems from a desire to protect VoIP with ESP, and IMO this makes good sense. > That is indicative of the current view on the suitability of using > SRTP as a primary security mechanism for classified VoIP > apoplications. > > Steve Perhaps, though SRTP is comparable to ESP transport mode, and header compression in ESP is applicable to tunnel mode. Also, I've heard that AES-256 in SRTP has been discussed in other US DoD contexts, FWIW. But at any rate, I can't speak for the Suite B community, and I'm glad to take input from them on the content of the draft. There has been a bunch of good discussion on this draft, and my feeling is that we ought to standardize how to use AES-256 as an option in SRTP, but provide lots of guidance about the sufficiency of AES-128. Given that TLS and IPsec provide AES-256 options, I don't see how we can argue otherwise, and I'm concerned that incompatible implementations would proliferate in the absence of a standard. If the reference to Suite B is inappropriate, then it can be amended or removed. David From jon@callas.org Thu May 4 13:51:53 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k44HprCi007811 for ; Thu, 4 May 2006 13:51:53 -0400 Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k44Hpo3U026639 for ; Thu, 4 May 2006 13:51:51 -0400 (EDT) Received: from keys.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server X 3.2.7); Thu, 4 May 2006 10:51:48 -0700 Received: from [63.73.97.189] ([63.73.97.189]) by keys.merrymeet.com (PGP Universal service); Thu, 04 May 2006 10:51:48 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Thu, 04 May 2006 10:51:48 -0700 In-Reply-To: References: <6.2.5.6.2.20060502093853.058c5948@qualcomm.com> <6.2.5.6.2.20060502145206.05a6e4f8@qualcomm.com> <5ABD5019-6481-45A1-A981-4BE362E190F8@cisco.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8DB7E403-39E1-4933-9435-2741DD492940@callas.org> Content-Transfer-Encoding: 7bit From: Jon Callas Date: Thu, 4 May 2006 10:51:41 -0700 To: David McGrew X-Mailer: Apple Mail (2.749.3) X-Spam-Score: -2.6 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, ietf-rtpsec@imc.org, AVT Subject: Re: [saag] The use of AES-192 and AES-256 in Secure RTP X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2006 17:51:53 -0000 I agree with the assessment that there's no security need for AES-256. Until we get quantum computers or something like them, 128 bits are enough. However, there are trends that make it so that AES-256 is now the norm, regardless of what we think. Here are a number of reasons: * The intelligent-but-naive populace will think that 256 is better than 128. Bigger is better. The intelligent-but-paranoid crowd who vaguely remember the crypto wars are often convinced that 128-bits is now "exportable" (meaning easily breakable by efforts similar to DeepCrack). I talk to these people all the time. Yes, they exist. In short, customers respond positively to the use of 256-bit keys. * Suite B, which specifies 192/256 for top secret data reinforces the above. After all, if the government recommends 128 for secret data, and 256 for top secret, what's good for them is good for me. * AES-256 is 20%-ish slower than AES-128. In real-world systems, this ends up being far less. I did a bit of googling as I composed this to look for charts and numbers. You can, too. But look at which has nice charts of a variety of ciphers in SCP/SSH performance. In short, the *cost* of implementing AES-256 is low. The effect of these together is that the costs of 256 bit keys are low, the benefits in marketing, perception, and merely being seen as up-to-date are high. You can also denigrate those who are not offering 256. That's why you're seeing it. These aren't security reasons, they're human reasons. Jon From mouse@Sparkle.Rodents.Montreal.QC.CA Thu May 4 15:01:34 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k44J1Xgi019796 for ; Thu, 4 May 2006 15:01:33 -0400 Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k44J1TjN005859 for ; Thu, 4 May 2006 15:01:29 -0400 (EDT) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id PAA29155; Thu, 4 May 2006 15:01:25 -0400 (EDT) From: der Mouse Message-Id: <200605041901.PAA29155@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. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Thu, 4 May 2006 14:57:20 -0400 (EDT) To: saag@mit.edu, ietf-rtpsec@imc.org In-Reply-To: <73C7FC51-5717-46AB-8B4A-F3842C855D6D@cisco.com> References: <200605040236.k442aeST024543@localhost.localdomain> <73C7FC51-5717-46AB-8B4A-F3842C855D6D@cisco.com> X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: Re: [saag] The use of AES-192 and AES-256 in Secure RTP X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2006 19:01:34 -0000 > But I think that your main point is that we don't need to implement > AES-256 in order for it to have value as a hedge. This is valid. Yes, as far as it goes - but (and here I speak as someone who's written a Rijndael implementation) having done AES-128, the incremental cost of doing AES-256 as well is minimal. The two can share almost all of their code. Unless, I suppose, you're doing it in silicon and hardwire in the shift and rounds values, or some such. /~\ 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 bgreene@cisco.com Thu May 4 15:12:10 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k44JC8St021418 for ; Thu, 4 May 2006 15:12:08 -0400 Received: from test-iport-2.cisco.com (test-iport-2.cisco.com [171.71.176.105]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k44JC6Xj020417 for ; Thu, 4 May 2006 15:12:07 -0400 (EDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by test-iport-2.cisco.com with ESMTP; 04 May 2006 12:12:06 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k44JC6RT007411; Thu, 4 May 2006 12:12:06 -0700 (PDT) Received: from xmb-sjc-227.amer.cisco.com ([128.107.191.43]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 May 2006 12:12:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 4 May 2006 12:12:05 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] IPsec spec problems Thread-Index: AcZu+fbkKTQ4al1BQtKR+LvCy2/i4wAqaKNg From: "Barry Greene \(bgreene\)" To: "Stephen Kent" X-OriginalArrivalTime: 04 May 2006 19:12:05.0956 (UTC) FILETIME=[A2005040:01C66FAE] X-Spam-Score: -2.4 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id k44JC8St021418 Cc: saag@mit.edu Subject: Re: [saag] IPsec spec problems X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2006 19:12:10 -0000 > I appreciate your exploration of the option relative to your > in-depth knowledge of Cisco implementations, but I hope > you'll understand if I suggest that a broader evaluation of > what is and is not viable is what is needed when we consider > options for IETF standards. I'm all for more empirical work in this area - as long as IETF "standards" work keep on the path of _working_ code. And from the operator's view point, operationally deployable code. This conversation started around questions on draft-bonica-tcp-auth. You have vendors and operators documenting what have found to be operationally deployable code that will meet their needs. There is a question of what SAAG "should we say to the TCPM folks." What's next? From mcgrew@cisco.com Thu May 4 15:15:15 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k44JFFWP022274 for ; Thu, 4 May 2006 15:15:15 -0400 Received: from test-iport-2.cisco.com (test-iport-2.cisco.com [171.71.176.105]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k44JFCST024765 for ; Thu, 4 May 2006 15:15:13 -0400 (EDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by test-iport-2.cisco.com with ESMTP; 04 May 2006 12:15:12 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k44JFCh0021814; Thu, 4 May 2006 12:15:12 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 May 2006 12:15:12 -0700 Received: from [192.168.1.100] ([10.32.254.210]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 May 2006 12:15:11 -0700 Mime-Version: 1.0 (Apple Message framework v749.3) Content-Transfer-Encoding: 7bit Message-Id: <1F80FC4D-1FD6-4C3E-89E1-B345ED358767@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: AVT , ietf-rtpsec@imc.org, saag@mit.edu From: David McGrew Date: Thu, 4 May 2006 12:15:10 -0700 X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 04 May 2006 19:15:11.0709 (UTC) FILETIME=[10B7F8D0:01C66FAF] X-Spam-Score: -2.4 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] The use of AES-192 and AES-256 in Secure RTP X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2006 19:15:15 -0000 Hello, here's some additional text that explains the "hedge" strategy. Perhaps it's worth adding to the draft. Comments welcome. David The main motivation for AES-192 and AES-256 is to provide alternative ciphers to AES-128 that can be adopted in event that unforeseen advances in cryptanalysis significantly erode the security level of AES-128. The main purpose of this specification is to provide algorithm agility to SRTP, to allow that protocol to easily adopt the alternative ciphers if the need arises in the future. It MUST NOT be interpreted as discouraging the use of AES-128. Implementers MAY support the alternative ciphers in advance of any need to replace AES-128, in order to facilitate a potential future 'hot swap' replacement, but those implementations MUST be prepared to interoperate with implementations that do not support the alternative ciphers. From bgreene@cisco.com Thu May 4 15:16:18 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k44JGIlJ022496 for ; Thu, 4 May 2006 15:16:18 -0400 Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k44JCAKD020502; Thu, 4 May 2006 15:12:10 -0400 (EDT) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 04 May 2006 12:12:09 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k44JC8w5013536; Thu, 4 May 2006 12:12:09 -0700 (PDT) Received: from xmb-sjc-227.amer.cisco.com ([128.107.191.43]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 May 2006 12:12:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 4 May 2006 12:12:08 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Fwd: draft-bonica-tcp-auth Thread-Index: AcZuzPE7fuIwdHRQR8Wi09xsrcqqvwA2HYhA From: "Barry Greene \(bgreene\)" To: "Sam Hartman" , "Gray, Eric" X-OriginalArrivalTime: 04 May 2006 19:12:08.0907 (UTC) FILETIME=[A3C299B0:01C66FAE] X-Spam-Score: -2.4 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id k44JGIlJ022496 Cc: saag@mit.edu, Russ Housley Subject: Re: [saag] Fwd: draft-bonica-tcp-auth X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2006 19:16:18 -0000 BGP has two macro MTTM attack vectors - surveillance and injecting bad information. IPSEC would protect both, MD5 protects against the injection of bad information. Since so much is already know with BGP (i.e. connect to Route-Views or the multitude of Looking Glases), surveillance is not even a minor worry to an SP. Hence, MD5 is "good enough" for today's SP MTTM worry around BGP. > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > Sent: Wednesday, May 03, 2006 9:16 AM > To: Gray, Eric > Cc: Barry Greene (bgreene); saag@mit.edu; Russ Housley > Subject: Re: [saag] Fwd: draft-bonica-tcp-auth > > >>>>> "Gray," == Gray, Eric writes: > > Gray,> Sam, I don't understand this question. Barry said nothing > Gray,> about checksums in his last post on this topic and > > His entire post was about a mechanism using a MAC in TCP to > protect BGP. > > Gray,> indicated that a man in the middle attack is not a threat > Gray,> that the industry is worried about. > > And thus I was surprised that he was advocating a solution > that seemed to protect against MITM. > From paul.hoffman@vpnc.org Thu May 4 15:31:19 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k44JVJJh027868 for ; Thu, 4 May 2006 15:31:19 -0400 Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k44JQNvk016734 for ; Thu, 4 May 2006 15:26:24 -0400 (EDT) Received: from [10.0.6.56] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k44JQHbt012278; Thu, 4 May 2006 12:26:17 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <1F80FC4D-1FD6-4C3E-89E1-B345ED358767@cisco.com> References: <1F80FC4D-1FD6-4C3E-89E1-B345ED358767@cisco.com> Date: Thu, 4 May 2006 12:26:17 -0700 To: David McGrew , AVT , ietf-rtpsec@imc.org, saag@mit.edu From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: Re: [saag] The use of AES-192 and AES-256 in Secure RTP X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2006 19:31:19 -0000 At 12:15 PM -0700 5/4/06, David McGrew wrote: >It MUST NOT be >interpreted as discouraging the use of AES-128. Half-nit: that's an improper use of MUST NOT according to RFC 2119. More important: you also don't want to encourage use of things other than AES-128 unless needed. Proposed change: It should not be interpreted as discouraging the use of AES-128, nor encouraging the use of AES-192 or AES-256 unless there is a strong cryptographic reason to do so. --Paul Hoffman, Director --VPN Consortium From jon@callas.org Thu May 4 16:42:25 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k44KgPRw011457 for ; Thu, 4 May 2006 16:42:25 -0400 Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k44KgOnv024085 for ; Thu, 4 May 2006 16:42:24 -0400 (EDT) Received: from keys.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server X 3.2.7); Thu, 4 May 2006 13:42:23 -0700 Received: from [63.251.255.205] ([63.251.255.205]) by keys.merrymeet.com (PGP Universal service); Thu, 04 May 2006 13:42:23 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Thu, 04 May 2006 13:42:23 -0700 In-Reply-To: References: <1F80FC4D-1FD6-4C3E-89E1-B345ED358767@cisco.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jon Callas Date: Thu, 4 May 2006 13:42:20 -0700 To: Paul Hoffman X-Mailer: Apple Mail (2.749.3) X-Spam-Score: -2.6 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, ietf-rtpsec@imc.org, David McGrew , AVT Subject: Re: [saag] The use of AES-192 and AES-256 in Secure RTP X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2006 20:42:26 -0000 > Proposed change: It should not be interpreted as discouraging the use > of AES-128, nor encouraging the use of AES-192 or AES-256 unless > there is a strong cryptographic reason to do so. How about "must not" rather than "should not." Yeah, it's not an appropriate use of MUST or SHOULD, but I think the emphasis should be there (and my use of "should" is also intentional). We need to fight the slide. I think Dave's paragraph is wonderful. Jon From hartmans@MIT.EDU Thu May 4 17:09:26 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k44L9QN0015794 for ; Thu, 4 May 2006 17:09:26 -0400 Received: from carter-zimmerman.mit.edu (carter-zimmerman.dyn.mit.edu [18.188.3.148]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k44L9PQ3000325 for ; Thu, 4 May 2006 17:09:25 -0400 (EDT) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 2800CE0053; Thu, 4 May 2006 17:09:13 -0400 (EDT) To: "Barry Greene (bgreene)" References: From: Sam Hartman Date: Thu, 04 May 2006 17:09:13 -0400 In-Reply-To: (Barry Greene's message of "Thu, 4 May 2006 12:12:08 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 1.217 X-Spam-Level: * (1.217) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, "Gray, Eric" , Russ Housley Subject: Re: [saag] Fwd: draft-bonica-tcp-auth X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2006 21:09:26 -0000 >>>>> "Barry" == Barry Greene (bgreene) writes: Barry> BGP has two macro MTTM attack vectors - surveillance and Barry> injecting bad information. IPSEC would protect both, MD5 Barry> protects against the injection of bad information. Since so Barry> much is already know with BGP (i.e. connect to Route-Views Barry> or the multitude of Looking Glases), surveillance is not Barry> even a minor worry to an SP. The security community would not consider surveillance an MITM vector. Surveillance is a passive attack MITM is active. I agree that surveillance is not an issue for BGP. I assume that people talking about IPsec for BGP are often talking about null encription. --Sam From Eric.Gray@marconi.com Thu May 4 17:24:29 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k44LOTsM017919 for ; Thu, 4 May 2006 17:24:29 -0400 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k44LOSSI019986; Thu, 4 May 2006 17:24:28 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k44LGvx4026627; Thu, 4 May 2006 17:16:57 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA02006; Thu, 4 May 2006 17:16:57 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id ; Thu, 4 May 2006 17:16:56 -0400 Message-ID: <313680C9A886D511A06000204840E1CF0DDAF6E9@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" To: Sam Hartman , "Barry Greene (bgreene)" Date: Thu, 4 May 2006 17:16:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Russ Housley Subject: Re: [saag] Fwd: draft-bonica-tcp-auth X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2006 21:24:29 -0000 Sam, I am not sure why MITM is not considered to be potentially a passive attack vector. What if someone is using a MITM to collect credit card or personal identification information (as I assume is the case in a phishing expedition)? I assume this is considered to be a passive attack during the collection phase... Barry's point is that nobody stands to gain very much by eaves-dropping on BGP peer-to-peer exchanges - except to the extent that doing so might position them for a replay attack. If that is not a risk, then the MITM atttack for BGP is the malicious BGP speaker that (perhaps acting as a route-reflector) provides harmful input into the route computation process, or causes frequent termination of peering relationships. -- Eric --> -----Original Message----- --> From: Sam Hartman [mailto:hartmans-ietf@mit.edu] --> Sent: Thursday, May 04, 2006 5:09 PM --> To: Barry Greene (bgreene) --> Cc: Gray, Eric; saag@mit.edu; Russ Housley --> Subject: Re: [saag] Fwd: draft-bonica-tcp-auth --> --> >>>>> "Barry" == Barry Greene (bgreene) writes: --> --> Barry> BGP has two macro MTTM attack vectors - surveillance and --> Barry> injecting bad information. IPSEC would protect both, MD5 --> Barry> protects against the injection of bad --> information. Since so --> Barry> much is already know with BGP (i.e. connect to --> Route-Views --> Barry> or the multitude of Looking Glases), surveillance is not --> Barry> even a minor worry to an SP. --> --> The security community would not consider surveillance an --> MITM vector. --> Surveillance is a passive attack MITM is active. --> --> --> I agree that surveillance is not an issue for BGP. I assume that --> people talking about IPsec for BGP are often talking about null --> encription. --> --> --> --Sam --> From mouse@Sparkle.Rodents.Montreal.QC.CA Thu May 4 17:31:35 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k44LVZ0n018877 for ; Thu, 4 May 2006 17:31:35 -0400 Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k44LVOb9020364 for ; Thu, 4 May 2006 17:31:26 -0400 (EDT) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id RAA00878; Thu, 4 May 2006 17:31:23 -0400 (EDT) From: der Mouse Message-Id: <200605042131.RAA00878@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. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Thu, 4 May 2006 17:28:49 -0400 (EDT) To: saag@mit.edu In-Reply-To: <313680C9A886D511A06000204840E1CF0DDAF6E9@whq-msgusr-02.pit.comms.marconi.com> References: <313680C9A886D511A06000204840E1CF0DDAF6E9@whq-msgusr-02.pit.comms.marconi.com> X-Spam-Score: -1.11 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: Re: [saag] Fwd: draft-bonica-tcp-auth X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2006 21:31:35 -0000 > I am not sure why MITM is not considered to be potentially a passive > attack vector. Because that's not what MitM is normally used to mean. It is normally used to mean an attacker pretending, to each party, to be the other. This is not a passive attack. > What if someone is using a MITM to [...]? I assume this is > considered to be a passive attack during the collection phase... If it's passive, it's not MitM. No matter what it's doing. It may be evil, it may be many things, but if it's a passive attack, MitM is a wrong term for it. Or at least that's how I learned to use the term. /~\ 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 nw141292@binky.Central.Sun.COM Thu May 4 17:36:21 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k44LaKfH019531 for ; Thu, 4 May 2006 17:36:20 -0400 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k44LaAQl027577; Thu, 4 May 2006 17:36:11 -0400 (EDT) Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k44LaAif023830; Thu, 4 May 2006 14:36:10 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k44LZvC5002312; Thu, 4 May 2006 15:35:58 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k44La8Ss023401; Thu, 4 May 2006 16:36:08 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k44La6k2023400; Thu, 4 May 2006 16:36:06 -0500 (CDT) Date: Thu, 4 May 2006 16:36:06 -0500 From: Nicolas Williams To: "Gray, Eric" Message-ID: <20060504213606.GB22986@binky.Central.Sun.COM> References: <313680C9A886D511A06000204840E1CF0DDAF6E9@whq-msgusr-02.pit.comms.marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <313680C9A886D511A06000204840E1CF0DDAF6E9@whq-msgusr-02.pit.comms.marconi.com> User-Agent: Mutt/1.5.7i X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Russ Housley , Sam Hartman Subject: Re: [saag] Fwd: draft-bonica-tcp-auth X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2006 21:36:21 -0000 On Thu, May 04, 2006 at 05:16:50PM -0400, Gray, Eric wrote: > I am not sure why MITM is not considered to be potentially > a passive attack vector. MITM == active attack != passive attack Nico -- From Eric.Gray@marconi.com Thu May 4 17:40:22 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k44LeM1n020211 for ; Thu, 4 May 2006 17:40:22 -0400 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k44LeL0D011023 for ; Thu, 4 May 2006 17:40:21 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k44LeKx4027045; Thu, 4 May 2006 17:40:20 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA04117; Thu, 4 May 2006 17:40:20 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id ; Thu, 4 May 2006 17:40:20 -0400 Message-ID: <313680C9A886D511A06000204840E1CF0DDAF6ED@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" To: Nicolas Williams Date: Thu, 4 May 2006 17:40:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] Fwd: draft-bonica-tcp-auth X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2006 21:40:23 -0000 Nico, You're saying this is "by definition"? If so, it is not obvious why this definition is assumed. Data collection is not obviously an active attack and - if it is - then surveillance is also an active attack. -- Eric --> -----Original Message----- --> From: Nicolas Williams [mailto:Nicolas.Williams@sun.com] --> Sent: Thursday, May 04, 2006 5:36 PM --> To: Gray, Eric --> Cc: Sam Hartman; Barry Greene (bgreene); saag@mit.edu; Russ Housley --> Subject: Re: [saag] Fwd: draft-bonica-tcp-auth --> --> On Thu, May 04, 2006 at 05:16:50PM -0400, Gray, Eric wrote: --> > I am not sure why MITM is not considered to be potentially --> > a passive attack vector. --> --> MITM == active attack != passive attack --> --> Nico --> -- --> From ekr@networkresonance.com Thu May 4 17:53:43 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k44LrhLG021943 for ; Thu, 4 May 2006 17:53:43 -0400 Received: from raman.networkresonance.com (raman.networkresonance.com [198.144.196.3]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k44LrbvQ027415 for ; Thu, 4 May 2006 17:53:38 -0400 (EDT) Received: by raman.networkresonance.com (Postfix, from userid 1001) id 0CFE61E8C1C; Thu, 4 May 2006 14:53:37 -0700 (PDT) To: "Gray, Eric" References: <313680C9A886D511A06000204840E1CF0DDAF6ED@whq-msgusr-02.pit.comms.marconi.com> From: Eric Rescorla Date: Thu, 04 May 2006 14:53:37 -0700 In-Reply-To: <313680C9A886D511A06000204840E1CF0DDAF6ED@whq-msgusr-02.pit.comms.marconi.com> (Eric Gray's message of "Thu, 4 May 2006 17:40:13 -0400") Message-ID: <86slnpcv8e.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Nicolas Williams Subject: Re: [saag] Fwd: draft-bonica-tcp-auth X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Reply-To: EKR List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2006 21:53:43 -0000 "Gray, Eric" writes: > Nico, > > You're saying this is "by definition"? > > If so, it is not obvious why this definition is assumed. > Data collection is not obviously an active attack and - if it > is - then surveillance is also an active attack. No, he's saying that MITM is a technical term for a specific kind of attack and that that attack is an active one. Surveillance is not a specific attack but rather an application that can be accomplished by a variety of techniques, some active and some passive. -Ekr From nw141292@binky.Central.Sun.COM Thu May 4 17:53:45 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k44LrjS6021951 for ; Thu, 4 May 2006 17:53:45 -0400 Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k44Lregt020811 for ; Thu, 4 May 2006 17:53:40 -0400 (EDT) Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k44LreKe017836 for ; Thu, 4 May 2006 15:53:40 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k44LrSQO007356 for ; Thu, 4 May 2006 15:53:28 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k44Lrd1i023418; Thu, 4 May 2006 16:53:39 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k44Lrd3B023417; Thu, 4 May 2006 16:53:39 -0500 (CDT) Date: Thu, 4 May 2006 16:53:39 -0500 From: Nicolas Williams To: "Gray, Eric" Message-ID: <20060504215339.GA23410@binky.Central.Sun.COM> References: <313680C9A886D511A06000204840E1CF0DDAF6ED@whq-msgusr-02.pit.comms.marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <313680C9A886D511A06000204840E1CF0DDAF6ED@whq-msgusr-02.pit.comms.marconi.com> User-Agent: Mutt/1.5.7i X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] Fwd: draft-bonica-tcp-auth X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2006 21:53:46 -0000 On Thu, May 04, 2006 at 05:40:13PM -0400, Gray, Eric wrote: > Nico, > > You're saying this is "by definition"? > > If so, it is not obvious why this definition is assumed. > Data collection is not obviously an active attack and - if it > is - then surveillance is also an active attack. :) MITM == Man In The Middle Getting in the middle is an active attack. An active attacker can act passively once it has gotten in the middle, yes, but the vector required being active. Now, the line gets blurred, but generally when we say MITM we mean active. E.g.: Without crypto a traditional wire tap is as much an active attack it is passive, but if you are using crypto then a plain wire tap is a passive attack. Now break and reterminate the wires and pretend to be the other endpoint to each of the endpoints of the wire you were snooping on and now you're an MITM, an active attacker, even if the endpoints were using crypto -- though you may fail authentication, in which case one, the other or both endpoints will detect you. Nico -- From jon@callas.org Thu May 4 18:24:17 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k44MOHGF025604 for ; Thu, 4 May 2006 18:24:17 -0400 Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k44MOFfj003066 for ; Thu, 4 May 2006 18:24:16 -0400 (EDT) Received: from keys.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server X 3.2.7) for ; Thu, 4 May 2006 15:24:15 -0700 Received: from [63.251.255.205] ([63.251.255.205]) by keys.merrymeet.com (PGP Universal service); Thu, 04 May 2006 15:24:15 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Thu, 04 May 2006 15:24:15 -0700 Mime-Version: 1.0 (Apple Message framework v749.3) In-Reply-To: <20060504215339.GA23410@binky.Central.Sun.COM> References: <313680C9A886D511A06000204840E1CF0DDAF6ED@whq-msgusr-02.pit.comms.marconi.com> <20060504215339.GA23410@binky.Central.Sun.COM> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <241F22F1-0A64-435D-BBB6-8436B98769A4@callas.org> Content-Transfer-Encoding: 7bit From: Jon Callas Date: Thu, 4 May 2006 15:24:11 -0700 To: saag@mit.edu X-Mailer: Apple Mail (2.749.3) X-Spam-Score: -2.6 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: Re: [saag] Fwd: draft-bonica-tcp-auth X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2006 22:24:17 -0000 I'm always happy to help with being pedantic! Think of a man-in-the-middle as an evil proxy firewall. It mediates the communications between Alice and Bob, and also lies, at the very least to cover its own tracks. All MITM attacks are active attacks. Not all active attacks are MITM attacks. Typically, a MITM attack is a surveillance attack. It could, for example be part of a fraud. Suppose Alice takes $100 out of her bank, but the MITM takes out $500, giving Alice her $100 and pocketing the rest. While, yes, this attack needed a certain form of surveillance, to call it a surveillance attack would be to misunderstand it. Nonetheless, surveillance can be either active or passive. Typically we think of it as passive. A MITM attack is also an impersonation attack. The MITM is impersonating Alice when talking to Bob and Bob while talking to Alice. But not all impersonations are MITM attacks. There is a tendency for people to mislabel impersonation attacks as MITMs, and also surveillance in general as MITM attacks. That's why we need a certain amount of pedantry, so we know we're talking about the same things. Jon From Eric.Gray@marconi.com Thu May 4 18:24:51 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k44MOpJc025689 for ; Thu, 4 May 2006 18:24:51 -0400 Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k44MOk8P003601 for ; Thu, 4 May 2006 18:24:46 -0400 (EDT) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.12.10+Sun/8.12.10) with ESMTP id k44MOjx4027613; Thu, 4 May 2006 18:24:46 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA07895; Thu, 4 May 2006 18:24:45 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2657.72) id ; Thu, 4 May 2006 18:24:45 -0400 Message-ID: <313680C9A886D511A06000204840E1CF0DDAF6F1@whq-msgusr-02.pit.comms.marconi.com> From: "Gray, Eric" To: EKR Date: Thu, 4 May 2006 18:24:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Nicolas Williams Subject: Re: [saag] Fwd: draft-bonica-tcp-auth X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2006 22:24:51 -0000 Eric, I imagine you didn't mean this to come across quite the way it does. :-) As I now understand it, what makes it an active attack is that at least some of the data is changed in a MITM attack. That this makes it an "active attack" is not obvious in the literature. Nor is it obvious at an intuitive level since it is quite possible for a MITM attack to occur without anyone having observed changes in the data either sent or received, except by direct comparison of the bits on the wire. Thanks to everyone that helped to clarify this for me! -- Eric --> -----Original Message----- --> From: Eric Rescorla [mailto:ekr@networkresonance.com] --> Sent: Thursday, May 04, 2006 5:54 PM --> To: Gray, Eric --> Cc: Nicolas Williams; saag@mit.edu --> Subject: Re: [saag] Fwd: draft-bonica-tcp-auth --> --> "Gray, Eric" writes: --> --> > Nico, --> > --> > You're saying this is "by definition"? --> > --> > If so, it is not obvious why this definition is assumed. --> > Data collection is not obviously an active attack and - if it --> > is - then surveillance is also an active attack. --> --> No, he's saying that MITM is a technical term for a specific kind of --> attack and that that attack is an active one. Surveillance is not a --> specific attack but rather an application that can be --> accomplished by --> a variety of techniques, some active and some passive. --> --> -Ekr --> From nw141292@binky.Central.Sun.COM Thu May 4 18:36:17 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k44MaGHN027309 for ; Thu, 4 May 2006 18:36:16 -0400 Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k44MaEmh016647 for ; Thu, 4 May 2006 18:36:15 -0400 (EDT) Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k44MaESX016041 for ; Thu, 4 May 2006 16:36:14 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k44Ma2Mc005204 for ; Thu, 4 May 2006 16:36:02 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k44MaD23023444; Thu, 4 May 2006 17:36:13 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k44MaDMf023443; Thu, 4 May 2006 17:36:13 -0500 (CDT) Date: Thu, 4 May 2006 17:36:13 -0500 From: Nicolas Williams To: "Gray, Eric" Message-ID: <20060504223613.GC23410@binky.Central.Sun.COM> References: <313680C9A886D511A06000204840E1CF0DDAF6F1@whq-msgusr-02.pit.comms.marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <313680C9A886D511A06000204840E1CF0DDAF6F1@whq-msgusr-02.pit.comms.marconi.com> User-Agent: Mutt/1.5.7i X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] Fwd: draft-bonica-tcp-auth X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2006 22:36:17 -0000 On Thu, May 04, 2006 at 06:24:37PM -0400, Gray, Eric wrote: > Eric, > > I imagine you didn't mean this to come across quite > the way it does. :-) This is way off-topic now, but... First, though I'm not Eric (EKR) I can tell you that he, like me, was being terse; we expect that in this community; read nothing more into it than that. > As I now understand it, what makes it an active attack > is that at least some of the data is changed in a MITM attack. > That this makes it an "active attack" is not obvious in the > literature. Second, I'm not going to go dig in the literature for a definition of MITM, but I can tell you that in *this* community (SAAG), the definition we've given you is consistent with how *we* use it. And if you really want any sort of documentary evidence check out RFC2828, page 105. Of course, you'll probably find conflicting definitions or usages elsewhere (though I can't think of any); the world of network security is larger than SAAG, after all. > Nor is it obvious at an intuitive level since it > is quite possible for a MITM attack to occur without anyone > having observed changes in the data either sent or received, > except by direct comparison of the bits on the wire. Cryptographic network protocols typically aim to make MITMs at least detectable, if not impossible (or, rather, highly improbable). There's no need for the parties in such protocols to get together and compare bits -- we build the protocols such that if an MITM changes the bits we'll detect it, and the only ways around this typically require breaking the crypto or the endpoints. Nico -- From ekr@networkresonance.com Thu May 4 18:36:37 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k44MabH2027381 for ; Thu, 4 May 2006 18:36:37 -0400 Received: from raman.networkresonance.com (raman.networkresonance.com [198.144.196.3]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k44Maa4c013518 for ; Thu, 4 May 2006 18:36:36 -0400 (EDT) Received: by raman.networkresonance.com (Postfix, from userid 1001) id 8CEF31E8C1C; Thu, 4 May 2006 15:36:35 -0700 (PDT) To: "Gray, Eric" References: <313680C9A886D511A06000204840E1CF0DDAF6F1@whq-msgusr-02.pit.comms.marconi.com> From: Eric Rescorla Date: Thu, 04 May 2006 15:36:35 -0700 In-Reply-To: <313680C9A886D511A06000204840E1CF0DDAF6F1@whq-msgusr-02.pit.comms.marconi.com> (Eric Gray's message of "Thu, 4 May 2006 18:24:37 -0400") Message-ID: <86hd45ct8s.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Nicolas Williams Subject: Re: [saag] Fwd: draft-bonica-tcp-auth X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Reply-To: EKR List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2006 22:36:37 -0000 "Gray, Eric" writes: > Eric, > > I imagine you didn't mean this to come across quite > the way it does. :-) Hmm... I don't know how you think it came across, so I really don't know what you're talking about here. > As I now understand it, what makes it an active attack > is that at least some of the data is changed in a MITM attack. > That this makes it an "active attack" is not obvious in the > literature. Well, like so much else in networking, things happen in layers. In some physics sense, even passive network sniffing on a wireless sense is "active" since it affects the transmitting and receiving system. But from the perspective of communications security protols, what distinguishes active from passive is that bits are injected, changed, deleted, etc. I'm not sure why you think that this isn't obvious from the literature. > Nor is it obvious at an intuitive level since it > is quite possible for a MITM attack to occur without anyone > having observed changes in the data either sent or received, > except by direct comparison of the bits on the wire. I don't really understand your point here. Yes, it's true that successful MITM attacks are undetectable by the communicating endpoints--that's the objective. But that's true by virtue of lack of authentication in the protocols, not by virtue of them actually being passive. Indeed, the fact that the bits on the wire *are* changed and it's not being detected is the weakness that's being exploited. -Ekr From smb@cs.columbia.edu Thu May 4 19:59:02 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k44Nx2fl005548 for ; Thu, 4 May 2006 19:59:02 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k44Nx0Eq024091 for ; Thu, 4 May 2006 19:59:00 -0400 (EDT) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id CFDDFFB2CA; Thu, 4 May 2006 19:58:57 -0400 (EDT) Received: by berkshire.machshav.com (Postfix, from userid 54047) id BFBB33C01F4; Thu, 4 May 2006 19:58:56 -0400 (EDT) Date: Thu, 4 May 2006 19:58:56 -0400 From: "Steven M. Bellovin" To: "Gray, Eric" Message-Id: <20060504195856.3b1efe21.smb@cs.columbia.edu> In-Reply-To: <313680C9A886D511A06000204840E1CF0DDAF6F1@whq-msgusr-02.pit.comms.marconi.com> References: <313680C9A886D511A06000204840E1CF0DDAF6F1@whq-msgusr-02.pit.comms.marconi.com> Organization: Columbia University X-Mailer: Sylpheed version 2.2.4 (GTK+ 2.8.17; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 1.217 X-Spam-Level: * (1.217) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, nicolas.williams@sun.com Subject: Re: [saag] Fwd: draft-bonica-tcp-auth X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2006 23:59:02 -0000 On Thu, 4 May 2006 18:24:37 -0400 , "Gray, Eric" wrote: > Eric, > > I imagine you didn't mean this to come across quite > the way it does. :-) > > As I now understand it, what makes it an active attack > is that at least some of the data is changed in a MITM attack. > That this makes it an "active attack" is not obvious in the > literature. Nor is it obvious at an intuitive level since it > is quite possible for a MITM attack to occur without anyone > having observed changes in the data either sent or received, > except by direct comparison of the bits on the wire. 'When _I_ use a word,' Humpty Dumpty said in rather a scornful tone, 'it means just what I choose it to mean--neither more nor less.' As Eric and others have said, it's a matter of definition. You may not like the definitions the security community uses, but to us they're a form of cleartext... More precisely -- eavesdropping is a goal. It can be accomplished via a MitM attack; it can also be accomplished by, say, a pair of alligator clips on a phone line, or by gently bending a fiber and connecting a receiver to it. In an active attack, the attacker is actually emitting packets of some sort, to impersonate one party and send the (possibly modified) packets on to the originally intended recipient. Let me give a concrete example; since we're talking here about routing, I'll phrase it in terms of an Ethernet-based exchange point. That is, assume a room with a lot of routers connected by a GigE Ethernet. Some but not all pairs of the routers have BGP associations between them. (Note to nitpickers: yes, I know that most exchange points don't operate this way. I also know that some do.) I'm router X; I want to see what routers A and B are saying to each other. There are two basic approaches. First, I could engage in classic wiretapping. Maybe I point a sensitive receiver at the twisted pair going to router A and pick up the (faint) RF signal emitted at the jack as it enters the router. (I once had an interesting conversation with someone who worked for, let us say, an Agency. He pointed to some wiring and said, "You call that an Ethernet. I call it an antenna.") The second was is an active attack at the Ethernet layer: I could answer A's ARP requests with my MAC address. (Yes, I'm oversimplifying.) I don't modify any the packets; I merely note their contents and send them along. But it's still an active attack. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb From kent@bbn.com Thu May 4 20:09:57 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k4509vh7006787 for ; Thu, 4 May 2006 20:09:57 -0400 Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k4509urR011290 for ; Thu, 4 May 2006 20:09:56 -0400 (EDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[45.13.10.243]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1FbntJ-000600-5t; Thu, 04 May 2006 20:09:54 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 4 May 2006 20:09:53 -0400 To: "Barry Greene \(bgreene\)" From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] IPsec spec problems X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2006 00:09:57 -0000 At 12:12 PM -0700 5/4/06, Barry Greene \(bgreene\) wrote: > > >> I appreciate your exploration of the option relative to your >> in-depth knowledge of Cisco implementations, but I hope >> you'll understand if I suggest that a broader evaluation of >> what is and is not viable is what is needed when we consider >> options for IETF standards. > >I'm all for more empirical work in this area - as long as IETF >"standards" work keep on the path of _working_ code. And from the >operator's view point, operationally deployable code. > >This conversation started around questions on draft-bonica-tcp-auth. You >have vendors and operators documenting what have found to be >operationally deployable code that will meet their needs. There is a >question of what SAAG "should we say to the TCPM folks." > >What's next? Barry, I apologize for not offering a more concrete suggestion. What I would suggest is a document, suitable for publication as an informational RFC, that explains the analysis that you cited and thus argues why a revised TCP MAC option is preferable to use of IPsec, in a vendor neutral fashion. As for alignment with operator requirements, I note that when Ron briefed this I-D to RPSEC attendees, he was told by an operator that any notion of changing keys more frequently than once a year was out of the question. This was prompted by Ron's comment that he made provision for 64 keys in the list so that one could change keys every month of so, and thus one could have up to two years of keys pre-loaded and ready to access. So, in at least this respect, it was not clear that the cited operations model matched operator perception of what is required/appropriate. Steve From kent@bbn.com Fri May 5 11:21:27 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k45FLRAE027959 for ; Fri, 5 May 2006 11:21:27 -0400 Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k45FLQgp005990; Fri, 5 May 2006 11:21:26 -0400 (EDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[45.13.10.243]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Fc27R-0004wr-4M; Fri, 05 May 2006 11:21:25 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 5 May 2006 11:21:21 -0400 To: "Barry Greene \(bgreene\)" From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, "Gray, Eric" , Russ Housley , Sam Hartman Subject: Re: [saag] Fwd: draft-bonica-tcp-auth X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2006 15:21:28 -0000 At 12:12 PM -0700 5/4/06, Barry Greene \(bgreene\) wrote: >BGP has two macro MTTM attack vectors - surveillance and injecting bad >information. IPSEC would protect both, MD5 protects against the >injection of bad information. Since so much is already know with BGP >(i.e. connect to Route-Views or the multitude of Looking Glases), >surveillance is not even a minor worry to an SP. > >Hence, MD5 is "good enough" for today's SP MTTM worry around BGP. You seem to be making an unwarranted an assumption about what sort of IPsec protection might be offered. What has been proposed in several published papers is use of ESP with NULL encryption, which does not provide confidentiality as a service. To minimize confusion, I suggest we stick with standard security service terminology for these discussions. So, for example, use of the TCP MD5 checksum provides data origin authentication and connection-oriented integrity. Thus it protects not only against injection of "bad information" but also against active wiretapping attacks of any sort on the TCP connection. If the keys were managed in a fashion better that what this option supports, peer entity authentication also would be provided. Steve From Black_David@emc.com Mon May 8 01:22:40 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k485Meg0003368 for ; Mon, 8 May 2006 01:22:40 -0400 Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [168.159.213.200]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k485MaqG029782 for ; Mon, 8 May 2006 01:22:36 -0400 (EDT) Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.11]) by mexforward.lss.emc.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k485MRXG013788; Mon, 8 May 2006 01:22:27 -0400 (EDT) Received: from MAHO3MSX2.corp.emc.com (maho3msx2.corp.emc.com [128.221.11.32]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k485MBDi021342; Mon, 8 May 2006 01:22:11 -0400 (EDT) Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 May 2006 01:22:11 -0400 Message-ID: From: Black_David@emc.com To: kent@bbn.com, ldondeti@qualcomm.com Date: Mon, 8 May 2006 01:22:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.3.0.1, Antispam-Data: 2006.5.7.215108 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, NO_REAL_NAME 0, __C230066_P5 0, __CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0' X-Spam-Score: -1.639 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, mcgrew@cisco.com Subject: [saag] AES-256 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2006 05:22:40 -0000 Hmm - the encrypted tape community seems to be favoring AES-256 based on the potentially long lifetime of stored data. If they should be talked out of this, what would you recommend as an authoritative reference to use for that purpose? See IEEE P1619.1 for some insight into what's going on here. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu] On > Behalf Of Stephen Kent > Sent: Wednesday, May 03, 2006 5:29 PM > To: Lakshminath Dondeti > Cc: saag@mit.edu; ietf-rtpsec@imc.org; David McGrew; AVT > Subject: Re: [saag] The use of AES-192 and AES-256 in Secure RTP > > I'm not a cryptographer, but I generally advise against encouraging > users to employ AES with 256-bit keys. The 256-bit key size is there > primarily as a hedge against the future development of quantum > computers. Since there are some performance costs with the use of big > keys, it seems unnecessary to adopt them at this time. > > Steve > _______________________________________________ > saag mailing list > saag@mit.edu > http://mailman.mit.edu/mailman/listinfo/saag > From paul.hoffman@vpnc.org Mon May 8 12:13:27 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k48GDIbu001623 for ; Mon, 8 May 2006 12:13:27 -0400 Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k48GDHp7007430 for ; Mon, 8 May 2006 12:13:17 -0400 (EDT) Received: from [10.20.30.249] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k48GBt3O051785; Mon, 8 May 2006 09:11:56 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <1F80FC4D-1FD6-4C3E-89E1-B345ED358767@cisco.com> References: <1F80FC4D-1FD6-4C3E-89E1-B345ED358767@cisco.com> Date: Mon, 8 May 2006 09:12:03 -0700 To: David McGrew , AVT , ietf-rtpsec@imc.org, saag@mit.edu From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: Re: [saag] The use of AES-192 and AES-256 in Secure RTP X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2006 16:13:27 -0000 At 12:15 PM -0700 5/4/06, David McGrew wrote: >The main motivation for AES-192 and AES-256 is to provide alternative >ciphers to AES-128 that can be adopted in event that unforeseen >advances in cryptanalysis significantly erode the security level of >AES-128. The downside of proposing multiple alternative ciphers, as compared to just one, is that it is likely that implementers will not do interop testing on all of them. It is much better to propose just one fall-back cipher. This is particularly true for AES, as we have discovered in the VPNC test lab. For IETF standards where AES-128 is a MUST-level requirement, there should be just one fall-back, AES-256, with wording like the "SHOULD+" definitions in RFC 4307. --Paul Hoffman, Director --VPN Consortium From mcgrew@cisco.com Mon May 8 12:18:03 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k48GI35v002911 for ; Mon, 8 May 2006 12:18:03 -0400 Received: from test-iport-1.cisco.com (test-iport-1.cisco.com [171.71.176.117]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k48GHwBo015289 for ; Mon, 8 May 2006 12:17:59 -0400 (EDT) Received: from sj-core-2.cisco.com ([171.71.177.254]) by test-iport-1.cisco.com with ESMTP; 08 May 2006 09:17:58 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k48GHwh0023731; Mon, 8 May 2006 09:17:58 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 8 May 2006 09:17:58 -0700 Received: from [192.168.1.100] ([10.32.254.210]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 8 May 2006 09:17:57 -0700 In-Reply-To: References: <1F80FC4D-1FD6-4C3E-89E1-B345ED358767@cisco.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: David McGrew Date: Mon, 8 May 2006 09:17:54 -0700 To: Paul Hoffman X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 08 May 2006 16:17:57.0633 (UTC) FILETIME=[F7F7BF10:01C672BA] X-Spam-Score: -2.4 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, ietf-rtpsec@imc.org, AVT Subject: Re: [saag] The use of AES-192 and AES-256 in Secure RTP X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2006 16:18:03 -0000 Paul, good points, I'm convinced that it would be better to dump AES-192 from the spec. David On May 8, 2006, at 9:12 AM, Paul Hoffman wrote: > At 12:15 PM -0700 5/4/06, David McGrew wrote: >> The main motivation for AES-192 and AES-256 is to provide >> alternative ciphers to AES-128 that can be adopted in event that >> unforeseen advances in cryptanalysis significantly erode the >> security level of >> AES-128. > > The downside of proposing multiple alternative ciphers, as compared > to just one, is that it is likely that implementers will not do > interop testing on all of them. It is much better to propose just > one fall-back cipher. This is particularly true for AES, as we have > discovered in the VPNC test lab. > > For IETF standards where AES-128 is a MUST-level requirement, there > should be just one fall-back, AES-256, with wording like the "SHOULD > +" definitions in RFC 4307. > > --Paul Hoffman, Director > --VPN Consortium From steffen.fries@siemens.com Mon May 8 06:33:32 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k48AXTcB020111 for ; Mon, 8 May 2006 06:33:29 -0400 Received: from gecko.sbs.de (gecko.sbs.de [194.138.37.40]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k48AXSYm018241 for ; Mon, 8 May 2006 06:33:29 -0400 (EDT) Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k48AXJYN024548; Mon, 8 May 2006 12:33:21 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k48AXILU018704; Mon, 8 May 2006 12:33:18 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 May 2006 12:33:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 8 May 2006 12:33:16 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVT] Re: The use of AES-192 and AES-256 in Secure RTP Thread-Index: AcZuNaVqXrztNxldS8SNUwPoGHdX3wESWgpA From: "Fries, Steffen" To: "Lakshminath Dondeti" , "David McGrew" X-OriginalArrivalTime: 08 May 2006 10:33:17.0904 (UTC) FILETIME=[D1E38500:01C6728A] X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id k48AXTcB020111 X-Mailman-Approved-At: Thu, 11 May 2006 10:28:27 -0400 Cc: saag@mit.edu, ietf-rtpsec@imc.org, AVT Subject: Re: [saag] [AVT] Re: The use of AES-192 and AES-256 in Secure RTP X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2006 10:33:32 -0000 Hi David, hi Lakshminath, sorry for the late response to that issue: > >>2. I would suggest that this draft include AES-based CMAC, so we > >>can move away from SHA-1 and also use a single crypto primitive for > >>encryption, and PRF and MAC computation (opinion on your open > >>question). > > > >We think alike :-) I implemented AES CMAC for SRTP and found that it > >performs better than HMAC-SHA1 for very short packets (like those for > >conversational voice over a WAN) but not long packets (like video). > >It also has some other advantages. But OTOH there is a cost to > >proliferating cryptoalgorithms. Let's start up a separate thread on > >CMAC. > > We did talk about it before. The concept of using the same crypto > primitive came up elsewhere and that sounds like a good idea. Please > start that thread of discussion. I assume that AES CMAC would go as an option into the draft, to be on one hand backward compatible and on the other hand be able to support different algorithms for MAC and encryption. BTW, is there a general opinion/advice, if it is better to use different mechanisms for different services (encryption, integrity) to not loose the complete security if one mechanism is broken? Regards Steffen > > > >>Q: What are the considerations in truncating cipher-based MAC > >>outputs? Specifically, is truncating below half-the-size of the > >>output (which I vaguely recall as relating to the birthday attack > >>in case of hash-based MACs -- perhaps it is not) of the > cipher- based MAC ok? > > > >Ah, good points. The NIST CMAC specification disallows truncation to > >MACs shorter than 64 bits. This is not because CMAC is weaker than > >an ideal MAC with respect to truncation, though. CMAC has been shown > >to be a good pseudorandom function if AES is a good blockcipher (as > >long as some usage limits are respected), and a PRF essentially is an > >ideal MAC. I'm pretty sure that the CMAC specification insists on > >MACs of at least 64 bits because it feels that a per-MAC forgery > >probability greater than 2^64 is not acceptable. No doubt they were > >not considering the case of stateless codecs, which some SRTP users > >need only 32-bit MACs. It is an interesting question as to what tag > >sizes would be recommended for use with CMAC! > > Let me think more about this. > > > >>What would be the strength of the MAC in that case. If we are > >>making a case for AES-192 or AES-256, then we have a certain > >>stronger adversary in mind (one that requires us to move away from > >>AES-128). In that case, why is MAC truncation not an issue? > > > >That's a good question. I think that in some circumstances it could > >make sense to use a short authentication tag and a huge key. If some > >unanticipated advance in cryptanalysis enables us to break AES-128 > >but not AES-256, but some user is still okay with accepting one out > >of a billion forged g.711 packets, this scenario would fit the bill. > >So the cryptosuites defined in the draft might make sense. But I > >take your point that users concerned that AES-128 doesn't have enough > >security may well not be satisfied with a 32-bit MAC. It would be > >good to get some input from the Suite B community on this question. > > Yes, we'll wait to hear from others. > > > > >>Let's discuss those for now. I may have more later :-). Thanks > >>for doing this! I was going to ask you about using CMAC in 3711! > > > >Any thoughts on whether or not AES-192 should be included? > > I think the use of AES-192 should be specified (at the expense of > more work for you :-) ), but let the "market" decide whether the > switch is to 192 or 256-bit keys. > > regards, > Lakshminath > > > >David > > > >>regards, > >>Lakshminath > >> > >>At 08:15 AM 5/2/2006, David McGrew wrote: > >> > >>>Hello, > >>> > >>>there has been some interest in using AES with larger key sizes in > >>>Secure RTP, and some implementations have gone in this direction in > >>>advance of any specification. I wrote up an internet draft to fill > >>>this gap (after trying unsuccessfully to get someone else to write > >>>it :-) and to provide usage guidance and (eventually) test vectors. > >>>It's online at http://www.ietf.org/internet-drafts/draft-mcgrew- > >>>srtp- big-aes-00.txt > >>> > >>>I propose that this draft be adopted for standards track, and I ask > >>>for your review (if you have an interest in Secure RTP). > Please note > >>>the "Open Questions" section. The ietf-rtpsec list is > copied since > >>>this draft is potentially interesting there, even though the draft > >>>has little architectural impact. > >>> > >>>Best regards, > >>> > >>>David > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > From hartmans@MIT.EDU Thu May 11 19:14:43 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k4BNEhGL012242 for ; Thu, 11 May 2006 19:14:43 -0400 Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k4BNEi1D006166 for ; Thu, 11 May 2006 19:14:44 -0400 (EDT) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 2862D160076; Thu, 11 May 2006 19:14:36 -0400 (EDT) To: saag@MIT.EDU From: Sam Hartman Date: Thu, 11 May 2006 19:14:36 -0400 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: message/rfc822 Content-Disposition: inline X-Spam-Score: 1.352 X-Spam-Level: * (1.352) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] Review of OASIS SAML work encouraged X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2006 23:14:43 -0000 Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.16-IPv6-Debian-2.1.16-10) with LMTP; Thu, 11 May 2006 17:37:40 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from south-station-annex.mit.edu (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by suchdamage.org (Postfix) with ESMTP id BA9FE1324F for ; Thu, 11 May 2006 17:37:39 -0400 (EDT) Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by south-station-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k4BLbdak003994 for ; Thu, 11 May 2006 17:37:39 -0400 (EDT) Received: from megatron.ietf.org (stiedprmman1.ietf.org [156.154.16.145]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k4BLbWEs004777 for ; Thu, 11 May 2006 17:37:32 -0400 (EDT) Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeIqi-0005ny-IN; Thu, 11 May 2006 17:37:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeIqh-0005ni-VZ; Thu, 11 May 2006 17:37:31 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeIqP-0007aR-4h; Thu, 11 May 2006 17:37:31 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k4BLb747007233; Thu, 11 May 2006 16:37:07 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 11 May 2006 23:37:06 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550A004F1D@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "IAB (E-mail)" , "Iesg (E-mail)" Date: Thu, 11 May 2006 23:37:05 +0200 X-Mailer: Internet Mail Service (5.5.2657.72) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: Subject: FW: [members] Public Review of SAML Profiles and Extensions X-BeenThere: iesg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: iesg.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: iesg-bounces@ietf.org X-Scanned-By: MIMEDefang 2.42 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on solipsist-nation.suchdamage.org X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 MIME-Version: 1.0 FYI -----Original Message----- From: Mary McRae [mailto:mary.mcrae@oasis-open.org] Sent: Thursday, May 11, 2006 19:49 To: members@lists.oasis-open.org; tc-announce@lists.oasis-open.org Cc: 'oasis sstc' Subject: [members] Public Review of SAML Profiles and Extensions TO: OASIS Members, public announce lists The OASIS Security Services TC recently has approved the following specification(s) as Committee Draft(s) and approved the package for public review. - Metadata Profile for the OASIS Security Assertion Markup Language (SAML) - SAML Attribute Sharing Profile for X.509 Authentication-Based Systems - SAML XPath Attribute Profile - SAML Metadata Extension for Query Requesters - SAML Protocol Extension for Third-Party Requests The public review starts today, 11 May 2006, and ends 10 July 2006. This is an open invitation to comment. Public review from potential users, developers and stakeholders is an important part of the OASIS process to assure interoperability and quality. Comments are solicited from all interested parties. Please feel free to distribute this announcement within your organization and to other appropriate mail lists. More non-normative information about the specification and the technical committee may be found at the public home page of the TC at http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security. Comments may be submitted to the TC by any person, by a web-form that can be reached either on that page, via the button marked "Send A Comment" at the top of that page, or directly at http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=security. Submitted comments (for this work as well as other works of that TC) are publicly archived and can be viewed at http://lists.oasis-open.org/archives/security-services-comment/. All comments submitted to OASIS are subject to the OASIS Feedback License, to assure that the comment may be freely re-used by the TC; the license terms can be found on the comment web-form. The specification document and related files are available here: 1. Metadata Profile for the OASIS Security Assertion Markup Language (SAML) V1.x PDF: http://www.oasis-open.org/committees/download.php/18043/sstc-saml1x-metadata-cd- 01.pdf HTML: http://www.oasis-open.org/committees/download.php/18045/sstc-saml1x-metadata-cd- 01.html OpenDocument: http://www.oasis-open.org/committees/download.php/18046/sstc-saml1x-metadata-cd- 01.odt Schema: http://www.oasis-open.org/committees/download.php/18048/sstc-saml1x-metadata.xsd 2. SAML Attribute Sharing Profile for X.509 Authentication-Based Systems PDF: http://www.oasis-open.org/committees/download.php/18058/sstc-saml-x509-authn-att rib-profile-cd-02.pdf HTML: http://www.oasis-open.org/committees/download.php/18056/sstc-saml-x509-authn-att rib-profile-cd-02.html OpenDocument: http://www.oasis-open.org/committees/download.php/18057/sstc-saml-x509-authn-att rib-profile-cd-02.odt 3. SAML XPath Attribute Profile PDF: http://www.oasis-open.org/committees/download.php/18061/sstc-saml-xpath-attribut e-profile-cd-01.pdf HTML: http://www.oasis-open.org/committees/download.php/18059/sstc-saml-xpath-attribut e-profile-cd-01.html OpenDocument: http://www.oasis-open.org/committees/download.php/18060/sstc-saml-xpath-attribut e-profile-cd-01.odt Schema: http://www.oasis-open.org/committees/download.php/18063/sstc-saml-xpath-attribut e-profile.xsd 4. SAML Metadata Extension for Query Requesters PDF: http://www.oasis-open.org/committees/download.php/18052/sstc-saml-metadata-ext-q uery-cd-01.pdf HTML: http://www.oasis-open.org/committees/download.php/18050/sstc-saml-metadata-ext-q uery-cd-01.html OpenDocument: http://www.oasis-open.org/committees/download.php/18051/sstc-saml-metadata-ext-q uery-cd-01.odt Schema: http://www.oasis-open.org/committees/download.php/18062/sstc-saml-metadata-ext-q uery.xsd 5. SAML Protocol Extension for Third-Party Requests PDF: http://www.oasis-open.org/committees/download.php/18055/sstc-saml-protocol-ext-t hirdparty-cd-01.pdf HTML: http://www.oasis-open.org/committees/download.php/18053/sstc-saml-protocol-ext-t hirdparty-cd-01.html OpenDocument: http://www.oasis-open.org/committees/download.php/18054/sstc-saml-protocol-ext-t hirdparty-cd-01.odt OASIS and the Security Services Technical Committee welcome your comments. Mary P McRae Manager of TC Administration, OASIS email: mary.mcrae@oasis-open.org OASIS Symposium: The Meaning of Interoperability, 9-12 May, San Francisco http://www.oasis-open.org/events/symposium_2006/ --------------------------------------------------------------------- This email list is used solely by OASIS for official consortium communications. Opt-out requests may be sent to member_services@oasis-open.org, however, all members are strongly encouraged to maintain a subscription to this list. From ietf@ietf.org Mon May 15 18:40:03 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k4FMdnP2027640 for ; Mon, 15 May 2006 18:40:03 -0400 Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k4FMdnfN013396 for ; Mon, 15 May 2006 18:39:49 -0400 (EDT) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k4FMdlXO008237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 15 May 2006 22:39:48 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fflj9-00015a-Qx; Mon, 15 May 2006 18:39:47 -0400 X-test-idtracker: no To: IETF-Announce , saag@mit.edu, ipsec@ietf.org From: The IESG Message-Id: Date: Mon, 15 May 2006 18:39:47 -0400 X-Spam-Score: -2.464 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] Last Call: 'GigaBeam High-Speed Radio Link Encryption' to Informational RFC (draft-housley-gigabeam-radio-link-encrypt) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Reply-To: iesg@ietf.org List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2006 22:40:03 -0000 The IESG has received a request from an individual submitter to consider the following document: - 'GigaBeam High-Speed Radio Link Encryption ' as an Informational RFC 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 2006-06-12. This document has already received review on the ipsec mailing list, and the author expects to make changes to address this review: http://www1.ietf.org/mail-archive/web/ipsec/current/msg02065.html The file can be obtained via http://www.ietf.org/internet-drafts/draft-housley-gigabeam-radio-link-encrypt-00.txt From laurent.pilati@mindspeed.com Fri May 19 11:07:42 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k4JF7fOA009476 for ; Fri, 19 May 2006 11:07:41 -0400 Received: from outbound1-cpk-R.bigfish.com (outbound-cpk.frontbridge.com [207.46.163.16]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k4JF7bA5008650 for ; Fri, 19 May 2006 11:07:38 -0400 (EDT) Received: from outbound1-cpk.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound1-cpk-R.bigfish.com (Postfix) with ESMTP id A2193A49666; Fri, 19 May 2006 15:07:37 +0000 (UTC) Received: from mail79-cpk-R.bigfish.com (unknown [192.168.21.3]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by outbound1-cpk.bigfish.com (Postfix) with ESMTP id 9AC4DA495CC; Fri, 19 May 2006 15:07:37 +0000 (UTC) Received: from mail79-cpk.bigfish.com (localhost.localdomain [127.0.0.1]) by mail79-cpk-R.bigfish.com (Postfix) with ESMTP id 89B8E4066BF; Fri, 19 May 2006 15:07:37 +0000 (UTC) X-BigFish: VP Received: by mail79-cpk (MessageSwitch) id 1148051257459585_6546; Fri, 19 May 2006 15:07:37 +0000 (UCT) Received: from mspdsmtp2.mindspeed.com (mspdsmtp2.mindspeed.com [199.33.64.93]) by mail79-cpk.bigfish.com (Postfix) with ESMTP id 2BE663FB408; Fri, 19 May 2006 15:07:37 +0000 (UTC) Received: from npblnh1.la.mindspeed.com (npblnh1.nb.mindspeed.com [10.1.16.81]) by mspdsmtp2.mindspeed.com (8.11.7p1+Sun/8.11.7) with ESMTP id k4JF7am17258; Fri, 19 May 2006 08:07:36 -0700 (PDT) Received: from sophiam1.nice.mindspeed.com ([10.1.124.21]) by npblnh1.la.mindspeed.com (Lotus Domino Release 6.5.3) with ESMTP id 2006051908072537-223966 ; Fri, 19 May 2006 08:07:25 -0700 To: David McGrew MIME-Version: 1.0 Sensitivity: X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: From: laurent.pilati@mindspeed.com Date: Fri, 19 May 2006 17:07:33 +0200 X-MIMETrack: Serialize by Router on SOPHIAM1/Server/Mindspeed(653HF723|September 16, 2005) at 05/19/2006 05:07:31 PM, Serialize complete at 05/19/2006 05:07:31 PM, Itemize by SMTP Server on NPBLNH1/Server/Conexant(Release 6.5.3|September 14, 2004) at 05/19/2006 08:07:25 AM, Serialize by Router on NPBLNH1/Server/Conexant(Release 6.5.3|September 14, 2004) at 05/19/2006 08:07:26 AM, Serialize complete at 05/19/2006 08:07:26 AM Content-Type: multipart/alternative; boundary="=_alternative 0053167AC1257173_=" X-Spam-Score: -1.006 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 X-Mailman-Approved-At: Fri, 19 May 2006 11:12:28 -0400 Cc: saag@mit.edu, ietf-rtpsec@imc.org, owner-ietf-rtpsec@mail.imc.org, AVT , Paul Hoffman Subject: Re: [saag] The use of AES-192 and AES-256 in Secure RTP X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2006 15:07:42 -0000 This is a multipart message in MIME format. --=_alternative 0053167AC1257173_= Content-Type: text/plain; charset="us-ascii" Hi all, As a suggestion, would it be also possible to use SSRC and RTP sequence number different of 0000 for the AES-CM Test Vectors section. This would avoid any endianess issue. Regards Laurent PILATI Tel. + 33 (0) 4 93 00 69 34 Design Center Mindspeed Technologies France David McGrew Sent by: owner-ietf-rtpsec@mail.imc.org 08/05/2006 18:17 To Paul Hoffman cc AVT , ietf-rtpsec@imc.org, saag@mit.edu Subject Re: [saag] The use of AES-192 and AES-256 in Secure RTP Paul, good points, I'm convinced that it would be better to dump AES-192 from the spec. David On May 8, 2006, at 9:12 AM, Paul Hoffman wrote: > At 12:15 PM -0700 5/4/06, David McGrew wrote: >> The main motivation for AES-192 and AES-256 is to provide >> alternative ciphers to AES-128 that can be adopted in event that >> unforeseen advances in cryptanalysis significantly erode the >> security level of >> AES-128. > > The downside of proposing multiple alternative ciphers, as compared > to just one, is that it is likely that implementers will not do > interop testing on all of them. It is much better to propose just > one fall-back cipher. This is particularly true for AES, as we have > discovered in the VPNC test lab. > > For IETF standards where AES-128 is a MUST-level requirement, there > should be just one fall-back, AES-256, with wording like the "SHOULD > +" definitions in RFC 4307. > > --Paul Hoffman, Director > --VPN Consortium --=_alternative 0053167AC1257173_= Content-Type: text/html; charset="us-ascii"
Hi all,

As a suggestion, would it be also possible to use SSRC and RTP sequence number different of  0000 for the AES-CM Test Vectors section.

This would avoid any endianess issue.

Regards

Laurent PILATI
Tel. + 33 (0) 4 93 00 69 34
Design Center
Mindspeed Technologies France


David McGrew <mcgrew@cisco.com>
Sent by: owner-ietf-rtpsec@mail.imc.org

08/05/2006 18:17

To
Paul Hoffman <paul.hoffman@vpnc.org>
cc AVT <avt@ietf.org>, ietf-rtpsec@imc.org, saag@mit.edu
Subject Re: [saag] The use of AES-192 and AES-256 in Secure RTP






Paul,

good points, I'm convinced that it would be better to dump AES-192  
from the spec.

David

On May 8, 2006, at 9:12 AM, Paul Hoffman wrote:

> At 12:15 PM -0700 5/4/06, David McGrew wrote:
>> The main motivation for AES-192 and AES-256 is to provide  
>> alternative ciphers to AES-128 that can be adopted in event that  
>> unforeseen advances in cryptanalysis significantly erode the  
>> security level of
>> AES-128.
>
> The downside of proposing multiple alternative ciphers, as compared  
> to just one, is that it is likely that implementers will not do  
> interop testing on all of them. It is much better to propose just  
> one fall-back cipher. This is particularly true for AES, as we have  
> discovered in the VPNC test lab.
>
> For IETF standards where AES-128 is a MUST-level requirement, there  
> should be just one fall-back, AES-256, with wording like the "SHOULD
> +" definitions in RFC 4307.
>
> --Paul Hoffman, Director
> --VPN Consortium

--=_alternative 0053167AC1257173_=-- From mcgrew@cisco.com Mon May 22 17:58:18 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k4MLwHlW031674 for ; Mon, 22 May 2006 17:58:17 -0400 Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k4MLwIcv025013 for ; Mon, 22 May 2006 17:58:18 -0400 (EDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 22 May 2006 14:57:57 -0700 X-IronPort-AV: i="4.05,157,1146466800"; d="scan'208,217"; a="1810771702:sNHT3581789784" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k4MLvvu3018351; Mon, 22 May 2006 14:57:57 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k4MLvvB9008503; Mon, 22 May 2006 14:57:57 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 22 May 2006 14:57:56 -0700 Received: from [192.168.1.100] ([10.32.254.210]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 22 May 2006 14:57:56 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v750) Content-Type: multipart/alternative; boundary=Apple-Mail-13-376666168 Message-Id: From: David McGrew Date: Mon, 22 May 2006 14:57:54 -0700 To: laurent.pilati@mindspeed.com X-Mailer: Apple Mail (2.750) X-OriginalArrivalTime: 22 May 2006 21:57:56.0728 (UTC) FILETIME=[C88F1F80:01C67DEA] DKIM-Signature: a=rsa-sha1; q=dns; l=6138; t=1148335077; x=1149199077; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mcgrew@cisco.com; z=From:David=20McGrew=20 |Subject:Re=3A=20[saag]=20The=20use=20of=20AES-192=20and=20AES-256=20in=20Secure= 20RTP; X=v=3Dcisco.com=3B=20h=3D1SRNnyOe4C6vJOekCLc6pGYvYYY=3D; b=Z78admRHovhcUyqeyRyB2eqnXnfvWx2qbu4VkZyY2Ow9/Uf9vgi+a6qWtbE3yLtre5+WZFqi 7PMAQJr7mLkXMoc2qh8n908BTcOKKNLiv2zrXmPk3P3/EAfKF2KJUwLl; Authentication-Results: sj-dkim-3.cisco.com; header.From=mcgrew@cisco.com; dkim=pass ( 29 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: -2.265 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, ietf-rtpsec@imc.org, owner-ietf-rtpsec@mail.imc.org, AVT , Paul Hoffman Subject: Re: [saag] The use of AES-192 and AES-256 in Secure RTP X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2006 21:58:18 -0000 --Apple-Mail-13-376666168 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi Laurent, using an SSRC different from 0x0000 in (at least one of) the test vectors is a very good suggestion! David On May 19, 2006, at 8:07 AM, laurent.pilati@mindspeed.com wrote: > > Hi all, > > As a suggestion, would it be also possible to use SSRC and RTP > sequence number different of 0000 for the AES-CM Test Vectors > section. > > This would avoid any endianess issue. > > Regards > > Laurent PILATI > Tel. + 33 (0) 4 93 00 69 34 > Design Center > Mindspeed Technologies France > > > David McGrew > Sent by: owner-ietf-rtpsec@mail.imc.org > 08/05/2006 18:17 > > To > Paul Hoffman > cc AVT , ietf-rtpsec@imc.org, saag@mit.edu > Subject Re: [saag] The use of AES-192 and AES-256 in Secure RTP > > > > > > > Paul, > > good points, I'm convinced that it would be better to dump AES-192 > from the spec. > > David > > On May 8, 2006, at 9:12 AM, Paul Hoffman wrote: > > > At 12:15 PM -0700 5/4/06, David McGrew wrote: > >> The main motivation for AES-192 and AES-256 is to provide > >> alternative ciphers to AES-128 that can be adopted in event that > >> unforeseen advances in cryptanalysis significantly erode the > >> security level of > >> AES-128. > > > > The downside of proposing multiple alternative ciphers, as compared > > to just one, is that it is likely that implementers will not do > > interop testing on all of them. It is much better to propose just > > one fall-back cipher. This is particularly true for AES, as we have > > discovered in the VPNC test lab. > > > > For IETF standards where AES-128 is a MUST-level requirement, there > > should be just one fall-back, AES-256, with wording like the "SHOULD > > +" definitions in RFC 4307. > > > > --Paul Hoffman, Director > > --VPN Consortium > > > > --Apple-Mail-13-376666168 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi Laurent,

using an SSRC different = from 0x0000 in (at least one of) the test vectors is a very good = suggestion!

David

On May 19, 2006, at 8:07 AM, laurent.pilati@mindspeed.com<= /A> wrote:


Hi all, =

As a suggestion, would it = be also possible to use SSRC and RTP sequence number different of =A00000 = for the AES-CM Test Vectors section.

This would avoid any endianess issue.
=
Regards

Laurent = PILATI
Tel. + 33 (0) 4 93 00 69 34
Design Center
Mindspeed = Technologies France


=
David McGrew <mcgrew@cisco.com> =
Sent by: owner-ietf-rtpsec@mail.imc.= org

08/05/2006 = 18:17

=
To
Paul Hoffman <paul.hoffman@vpnc.org>=
cc AVT <avt@ietf.org>, ietf-rtpsec@imc.org, saag@mit.edu
=
Subject Re: [saag] The use of AES-192 and AES-256 in Secure = RTP

=




Paul,

good points, I'm convinced that = it would be better to dump AES-192 =A0
from the spec.

= David

On May 8, 2006, at 9:12 AM, Paul Hoffman wrote:

= > At 12:15 PM -0700 5/4/06, David McGrew wrote:
>> The main = motivation for AES-192 and AES-256 is to provide =A0
>> = alternative ciphers to AES-128 that can be adopted in event that =A0
= >> unforeseen advances in cryptanalysis significantly erode the = =A0
>> security level of
>> AES-128.
>
= > The downside of proposing multiple alternative ciphers, as compared = =A0
> to just one, is that it is likely that implementers will = not do =A0
> interop testing on all of them. It is much better to = propose just =A0
> one fall-back cipher. This is particularly = true for AES, as we have =A0
> discovered in the VPNC test = lab.
>
> For IETF standards where AES-128 is a MUST-level = requirement, there =A0
> should be just one fall-back, AES-256, = with wording like the "SHOULD
> +" definitions in RFC = 4307.
>
> = --Paul Hoffman, Director
> --VPN Consortium


 =


= --Apple-Mail-13-376666168-- From hartmans@MIT.EDU Wed May 24 12:19:38 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k4OGJc5g015918 for ; Wed, 24 May 2006 12:19:38 -0400 Received: from carter-zimmerman.mit.edu (carter-zimmerman.dyn.mit.edu [18.188.3.148]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k4OGJZBk014500 for ; Wed, 24 May 2006 12:19:36 -0400 (EDT) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id ECC68E0074; Wed, 24 May 2006 12:19:27 -0400 (EDT) To: saag@MIT.EDU, ietf@ietf.org, dix@ietf.org From: Sam Hartman mail-copies-to: ietf-http-auth@lists.osafoundation.org mail-followups-to: ietf-http-auth@lists.osafoundation.org Date: Wed, 24 May 2006 12:19:27 -0400 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 1.217 X-Spam-Level: * (1.217) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] [Sam Hartman] [Ietf-http-auth] BOF Request: WARP - Web Authentication Resistant to Phishing X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2006 16:19:38 -0000 --=-=-= Hello. I'd like to draw your attention te the following BOF proposal. Please discuss on ietf-http-auth@ietf.org. I'd appreciate comments and indications of interest. I'd also like to draw your attention to two resources besides the BOF proposal: http://lists.osafoundation.org/pipermail/ietf-http-auth/2006-May/000241.html contains a better describption of what I think the BOF presentations should cover. http://www.ietf.org/internet-drafts/draft-hartman-webauth-phishing-00.txt contains my comments on anti-phishing requiremnts and I hope will be a starting point for what it means for web authentication to be resistant to phishing. I believe that similar requirements should apply to other proposals including things in the DIX space. --=-=-= Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from solipsist-nation ([unix socket]) by solipsist-nation (Cyrus v2.1.16-IPv6-Debian-2.1.16-10) with LMTP; Tue, 23 May 2006 17:34:25 -0400 X-Sieve: CMU Sieve 2.2 Return-Path: Received: from leilani.osafoundation.org (leilani.osafoundation.org [204.152.186.93]) by suchdamage.org (Postfix) with ESMTP id 9A2F0138B7 for ; Tue, 23 May 2006 17:34:24 -0400 (EDT) Received: from leilani.osafoundation.org (leilani.osafoundation.org [127.0.0.1]) by leilani.osafoundation.org (Postfix) with ESMTP id 61B1B7F851; Tue, 23 May 2006 14:34:21 -0700 (PDT) X-Original-To: ietf-http-auth@lists.osafoundation.org Delivered-To: ietf-http-auth@lists.osafoundation.org Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 0134C7F829 for ; Tue, 23 May 2006 14:34:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id E72FC142291 for ; Tue, 23 May 2006 14:34:19 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06285-02 for ; Tue, 23 May 2006 14:34:18 -0700 (PDT) Received: from carter-zimmerman.mit.edu (carter-zimmerman.dyn.mit.edu [18.188.3.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id F387614228B for ; Tue, 23 May 2006 14:34:17 -0700 (PDT) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id F2B6AE000E; Tue, 23 May 2006 17:34:09 -0400 (EDT) To: ietf-http-auth@lists.osafoundation.org From: Sam Hartman Date: Tue, 23 May 2006 17:34:09 -0400 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Subject: [Ietf-http-auth] BOF Request: WARP - Web Authentication Resistant to Phishing X-BeenThere: ietf-http-auth@osafoundation.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ietf-http-auth.osafoundation.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-http-auth-bounces@osafoundation.org Errors-To: ietf-http-auth-bounces@osafoundation.org X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on solipsist-nation.suchdamage.org X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 MIME-Version: 1.0 [Sent to the ADs; comments very much appreciated.] BOF Description: At IETF 65, the DIX BOF demonstrated a consensus to work on a solution to the problem that there are two many passwords for the web. This BOF proposes to develop a authentication architecture for the web and other HTTP-based applications using existing technology with at most small changes necessary to improve deployability that addresses this problem. One of the critical challenges facing the web today is the problem of phishing, where users are directed to fraudulent websites that request confidential information. Any solution to the phishing problem will require UI changes in web browsers. However the HTTP authentication architecture needs to work with these UI changes and provide clear technical requirements for the security features required from the UI. Proposed Charter: Web Authentication Resistant to Phishing (WARP) Applications Area Director(s): Ted Hardie Lisa Dusseault Applications Area Advisor: Lisa Dusseault Mailing Lists: General Discussion: ietf-http-auth@lists.osafoundation.org To Subscribe: ietf-http-auth-requst@lists.osafoundation.org In Body: In Body: subscribe Archive: http://www.imc.org/atom-syntax/mail-archive/ Description of Working Group: WARP is chartered to develop a method for using existing authentication technology to address two critical problems with authentication for the web and other HTTP-using applications. The first problem is that users must remember and maintain passwords for each HTTP service they use. The second problem is that of phishing. While browser UIs must change in order to combat the problem of phishing, WARP must work with these UI changes and must provide clear technical requirements for the security features needed from authentication UI. WARP will attack the problem of multiple passwords in two ways. First, it will be safe from a security standpoint to use the same password with multiple HTTP services. Second, WARP will support the concept of an identity provider, which is a service that clients can authenticate to and that can make assertions about their identity to third parties. Employers authenticating their employees to business partners, distributed communities that share a concept of identity and services like Microsoft's Passport service demonstrate the wide variety of identity providers. There will never be a single identity that a user can use on the web: many users would not choose to use the same identity in a work context that they use personally; similarly business relationships and policies will dictate what identities services can accept. However WARP will support the concept of identity providers so that when policies permit, users can minimize the number of identities they use. WARP must support identity providers associated with servers and should support identity providers that have relationships with users. WARP needs to support mobile users, including users that use HTTP services from computers they have never used before. WARP must not require per-service or per-identity-provider configuration. While WARP is focused on passwords as that is expected to be the primary means of authentication, WARP needs to support other credentials including smart cards, one-time passwords and zero-knowledge password protocols. It is desirable that WARP be able to carry assertions about identity such as Security Assertion Markup Language assertions. The WARP working group will first write a problem statement and a requirements draft describing what it means to produce an authentication solution that is resistant to phishing. Then WARP will choose a mandatory-to-implement authentication technology and protocol for the interaction between the identity provider and website. WARP will coordinate with W3C in working on the UI implications of phishing. WARP will not propose specific UI nor specific extensions to HTML, although WARP may recommend requirements for both as these requirements directly impact the security or deployability of WARP. Deliverables: * Problem statement for WARP * Requirements for authentication resistant to phishing * WARP protocol document describing how an existing authentication system is used to meet the requirements of WARP. This document may specify mandatory to implement modes in addition to those specified in the underlying system. * A proposed standard describing how an identity is registered with an identity provider or website. * A proposed standard describing how an identity associated with a user is linked to an HTTP service's concept of an account. BOF Agenda (2.5 hour slot requested): * Presentation on the multiple passwords problem (10 minutes) * Presentation on phishing (30 minutes) * Presentation arguing that existing technology is available (30 minutes) * Description of Charter (10 minutes) * Discussion _______________________________________________ Ietf-http-auth mailing list Ietf-http-auth@osafoundation.org http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-auth --=-=-=-- From housley@vigilsec.com Sat Jun 3 17:41:54 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k53LfsmV017504 for ; Sat, 3 Jun 2006 17:41:54 -0400 Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with SMTP id k53LfsLQ014851 for ; Sat, 3 Jun 2006 17:41:54 -0400 (EDT) Received: (qmail 22631 invoked by uid 0); 3 Jun 2006 21:41:47 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.246.224.46) by woodstock.binhost.com with SMTP; 3 Jun 2006 21:41:47 -0000 Message-Id: <7.0.0.16.2.20060603170701.06edf638@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Sat, 03 Jun 2006 17:36:49 -0400 To: saag@MIT.EDU From: Russ Housley In-Reply-To: <17486.1608.716952.420411@fireball.kivinen.iki.fi> References: <7.0.0.16.2.20060420095609.06191b18@vigilsec.com> <444DD2AB.2070606@piuha.net> <17486.1608.716952.420411@fireball.kivinen.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -2.599 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: rbonica@juniper.net Subject: Re: [saag] Fwd: draft-bonica-tcp-auth X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2006 21:41:54 -0000 I discussion that says "just use IPsec" is not going to change real implementations. We learned at the SAAG session in Dallas some significant router vendors support IPsec for transit traffic, not traffic that terminates in the router. Some router vendors might be able to change this more easily than others, but they all will have an easier time implementing a TCP authentication option. I have recently learned that more than one router vendor is doing experiments with this approach. Therefore, I suggest that we need to influence them with security requirements. My reading of this thread, these requirements include: - select a strong integrity check mechanism; - a scheme that will permit manual key management (it is used in a few places today); - a scheme that will support migration to automated key management; - a scheme that derives a per session key, even whin manual keys are used; - a scheme that permits key rollover while keeping the TCP session running; and - coordinate key rollover, but either party can decide that it has been in use for too long, and this includes polices based on time as well as traffic volume. I think we need to send a complete set of requirements in the next week or so. Russ From pbaker@verisign.com Sat Jun 10 10:01:53 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k5AE1rqB008156 for ; Sat, 10 Jun 2006 10:01:53 -0400 Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k5AE1wN9027216 for ; Sat, 10 Jun 2006 10:01:58 -0400 (EDT) Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id k5AE1v41009729 for ; Sat, 10 Jun 2006 07:01:58 -0700 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 10 Jun 2006 07:01:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C68C96.6AEAEDE6" Date: Sat, 10 Jun 2006 07:01:48 -0700 Message-ID: <198A730C2044DE4A96749D13E167AD37B559C1@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: VOIPSEC Thread-Index: AcaMlmo3Tv+b7ihxTFiRm7tuiACZ7g== From: "Hallam-Baker, Phillip" To: X-OriginalArrivalTime: 10 Jun 2006 14:01:49.0972 (UTC) FILETIME=[6B4B5540:01C68C96] X-Spam-Score: 0 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] VOIPSEC X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2006 14:01:53 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C68C96.6AEAEDE6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable So the latest Internet Crime news is that there have been indictments = for a VOIP scam, as reported in the NYT. Someone on the VOIPSEC list = posted the indictments which are also linked from my blog: =20 http://dotfuturemanifesto.blogspot.com/2006/06/indictments-in-voip-scam.h= tml =20 The indictments show that the scam was based on a brute force attack of = HTTP digest.=20 =20 Now HTTP Digest was originally designed in a couple of hours as an = attempt to forestall the deployment of BASIC. It was never intended to = be used where a single password was controlling an asset worth a million = dollars as in this case. The idea was that the need for DIGEST would go = away when public key was no longer encumbered. =20 So the lesson here is don't use a crypto protocol just because it is a = standard. A protocol that is designed to meet one set of requirements = may not be adequate in a different environment. We knew about the brute = force attack at the time, we did not know a way to address the problem = without using an encumbered technology. =20 If you want to have security you have to either use passwords that are = large enough to prevent the brute force attack - which is certainly = possible in an environment like SIP where these do not need to be = remembered by people. Or you use public key. =20 I spent this morning trying to work out a way round the public key = requirement involving injecting randomness into the mix. It is not = possible to brute force H (p, r) unless r is known. Unfortunately = getting r from one side to the other without using public key does not = seem to be possible. If you use E (r, p) you can now do a brute force = attack. The only way to prevent brute force is if verification requires = more information than is available to the client and that seems to = require public key which then gets you into all sorts of allegedly = encumbered technologies. =20 =20 =20 ------_=_NextPart_001_01C68C96.6AEAEDE6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
So the = latest=20 Internet Crime news is that there have been indictments for a VOIP scam, = as=20 reported in the NYT. Someone on the VOIPSEC list posted the indictments = which=20 are also linked from my blog:
 
 
The = indictments show=20 that the scam was based on a brute force attack of HTTP digest.=20
 
Now = HTTP Digest was=20 originally designed in a couple of hours as an attempt to forestall the=20 deployment of BASIC. It was never intended to be used where a single = password=20 was controlling an asset worth a million dollars as in this case. The = idea was=20 that the need for DIGEST would go away when public key was no longer=20 encumbered.
 
So the = lesson here=20 is don't use a crypto protocol just because it is a standard. A protocol = that is=20 designed to meet one set of requirements may not be adequate in a = different=20 environment. We knew about the brute force attack at the time, we did = not know a=20 way to address the problem without using an encumbered=20 technology.
 
If you = want to have=20 security you have to either use passwords that are large enough to = prevent the=20 brute force attack - which is certainly possible in an environment like = SIP=20 where these do not need to be remembered by people. Or you use public=20 key.
 
I spent this=20 morning trying to work out a way round the public key requirement = involving=20 injecting randomness into the mix. It is not possible to brute force H = (p, r)=20 unless r is known. Unfortunately getting r from one side to the other = without=20 using public key does not seem to be possible. If you use E (r, p) you = can now=20 do a brute force attack. The only way to prevent brute force is if = verification=20 requires more information than is available to the client and that seems = to=20 require public key which then gets you into all sorts of allegedly = encumbered=20 technologies.
 
 
 
------_=_NextPart_001_01C68C96.6AEAEDE6-- From mcr@sandelman.ottawa.on.ca Wed Jun 14 10:38:20 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k5EEcJxO007565 for ; Wed, 14 Jun 2006 10:38:20 -0400 Received: from lists.sandelman.ca (cod.sandelman.ca [192.139.46.139]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k5EEcOJ5026957 for ; Wed, 14 Jun 2006 10:38:25 -0400 (EDT) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) by lists.sandelman.ca (8.13.5.20060308/8.11.6) with ESMTP id k5EEc8Op007810 (using TLSv1/SSLv3 with cipher DHE-RSA-AES256-SHA (256 bits) verified OK); Wed, 14 Jun 2006 10:38:09 -0400 (EDT) Received: from sandelman.ottawa.on.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id DD7F73AE02; Sat, 10 Jun 2006 19:47:41 -0400 (EDT) From: Michael Richardson To: saag@MIT.EDU In-Reply-To: Message from Russ Housley of "Sat, 03 Jun 2006 17:36:49 EDT." <7.0.0.16.2.20060603170701.06edf638@vigilsec.com> References: <7.0.0.16.2.20060420095609.06191b18@vigilsec.com> <444DD2AB.2070606@piuha.net> <17486.1608.716952.420411@fireball.kivinen.iki.fi> <7.0.0.16.2.20060603170701.06edf638@vigilsec.com> X-Mailer: MH-E 7.82; nmh 1.1; XEmacs 21.4 (patch 17) Date: Sat, 10 Jun 2006 19:47:41 -0400 Message-ID: <13294.1149983261@sandelman.ottawa.on.ca> Sender: mcr@sandelman.ottawa.on.ca X-Spam-Score: 0.501 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: rbonica@juniper.net, Russ Housley Subject: Re: [saag] Fwd: draft-bonica-tcp-auth X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2006 14:38:20 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Russ" == Russ Housley writes: Russ> I discussion that says "just use IPsec" is not going to change real Russ> implementations. We learned at the SAAG session in Dallas some Russ> significant router vendors support IPsec for transit traffic, not Russ> traffic that terminates in the router. Some router vendors okay, but do they have a TCP/IP stack in the control plane, or do all of their socket operations happen in the forwarding plane? I.e. this isn't about upgrading their ASIC forwarding plane, and if they use connection latching, then for transport mode SAs, you don't really need to examine every packet --- only ones that had the right IPsec SA get accepted by TCP, and the rest get port-unreachable. I hope everyone realizes that for UDP-type traffic, you can actually do all of ESP in the application if you want. (You can do that for TCP too if you want, but nobody wants to reimplement TCP, while doing UDP is pretty trivial). I have long recommended people do this for things like radius. - -- ] 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.4.2.2 (GNU/Linux) Comment: Finger me for keys iQEVAwUBRItaE4CLcPvd0N1lAQKdbAgAi2q0FWJ6zHOwzWKwvelXi6ZEcctQuH9V ZyK6CLzs+nQ2rzxIOKNthv6q6EMaaNmORBm1VGD/PghM9Gh0wjirRI09lOCZ+yhW QhBt2bkcERem64MJKLsSkypN675k+jHMP74kw2WZ+r0LztAkEoT56SQjyjs2gjFE Kn5HGiiQIOC5bQNoMKJTrCdGn7jemP5i+24UPYRi+ZT4F+xaClsBEyRAdZzWHl+G 9EozBdVwONj3qlIZR3QiObfIaKBFVyU3ET/uYoCLqQp5f/W3XSpFRPBeYfkiTmZt a3JsoT6IRh7KrqtwXCEyqV9IaTvU5ebD/taonlJE21VhsDUNjaA5TQ== =5tVC -----END PGP SIGNATURE----- From Jeff.Hodges@KingsMountain.com Wed Jun 14 14:13:09 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k5EID9PU020233 for ; Wed, 14 Jun 2006 14:13:09 -0400 Received: from smtp3.stanford.edu (smtp3.Stanford.EDU [171.67.20.26]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k5EIDAVe005568 for ; Wed, 14 Jun 2006 14:13:10 -0400 (EDT) Received: from smtp3.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id CF7E94BEF8 for ; Wed, 14 Jun 2006 11:13:09 -0700 (PDT) Received: from networking.Stanford.EDU (networking.Stanford.EDU [171.64.20.23]) by smtp3.stanford.edu (Postfix) with ESMTP id 93D374BE25 for ; Wed, 14 Jun 2006 11:13:09 -0700 (PDT) Received: from networking.Stanford.EDU (hodges@localhost) by networking.Stanford.EDU (8.11.7/8.11.6) with ESMTP id k5EID9f04115 for ; Wed, 14 Jun 2006 11:13:09 -0700 (PDT) Message-Id: <200606141813.k5EID9f04115@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.2 To: Security Area Advisory Group From: Jeff.Hodges@KingsMountain.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 14 Jun 2006 11:13:09 -0700 X-Spam-Score: 1.929 X-Spam-Level: * (1.929) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] fyi: report on security risks of applying CALEA to VoIP X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Reply-To: Security Area Advisory Group List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2006 18:13:09 -0000 Of possible interest. I've reformatted Susan's msg wrt line breaks. Her post is archived here.. report on security risks of applying CALEA to VoIP http://www.interesting-people.org/archives/interesting-people/200606/ msg00089.html JeffH -------- Original Message ------- From: Susan Landau Date: June 13, 2006 10:35:37 AM EDT To: dave@farber.net Subject: report on security risks of applying CALEA to VoIP Tuesday 13 June 2006 at 10:35 Below you'll find an executive summary of "Security Implications of Applying the Communications Assistance for Law Enforcement Act to Voice over IP," by Steve Bellovin, Matt Blaze, Ernie Brickell, Clint Brooks, Vint Cerf, Whit Diffie, Susan Landau, Jon Peterson, John Treichler. The full report is at: http://www.itaa.org/news/docs/CALEAVOIPreport.pdf. Susan Security Implications of Applying the Communications Assistance to Law Enforcement Act to Voice over IP Steven Bellovin, Columbia University Matt Blaze, University of Pennsylvania Ernest Brickell, Intel Corporation Clinton Brooks, NSA (retired) Vinton Cerf, Google Whitfield Diffie, Sun Microsystems Susan Landau, Sun Microsystems Jon Peterson, NeuStar John Treichler, Applied Signal Technology Executive Summary For many people, Voice over Internet Protocol (VoIP) looks like a nimble way of using a computer to make phone calls. Download the software, pick an identifier and then wherever there is an Internet connection, you can make a phone call. From this perspective, it makes perfect sense that anything that can be done with a telephone, including the graceful accommodation of wiretapping, should be able to be done readily with VoIP as well. The FCC has issued an order for all ``interconnected'' and all broadband access VoIP services to comply with Communications Assistance for Law Enforcement Act (CALEA) --- without specific regulations on what compliance would mean. The FBI has suggested that CALEA should apply to all forms of VoIP, regardless of the technology involved in the VoIP implementation. Intercept against a VoIP call made from a fixed location with a fixed IP address directly to a big internet provider's access router is equivalent to wiretapping a normal phone call, and classical PSTN-style CALEA concepts can be applied directly. In fact, these intercept capabilities can be exactly the same in the VoIP case if the ISP properly secures its infrastructure and wiretap control process as the PSTN's central offices are assumed to do. However, the network architectures of the Internet and the Public Switched Telephone Network (PSTN) are substantially different, and these differences lead to security risks in applying the CALEA to VoIP. VoIP, like most Internet communications, are communications for a mobile environment. The feasibility of applying CALEA to more decentralized VoIP services is quite problematic. Neither the manageability of such a wiretapping regime nor whether it can be made secure against subversion seem clear. The real danger is that a CALEA-type regimen is likely to introduce serious vulnerabilities through its ``architected security breach.'' Potential problems include the difficulty of determining where the traffic is coming from (the VoIP provider enables the connection but may not provide the services for the actual conversation), the difficulty of ensuring safe transport of the signals to the law-enforcement facility, the risk of introducing new vulnerabilities into Internet communications, and the difficulty of ensuring proper minimization. VOIP implementations vary substantially across the Internet making it impossible to implement CALEA uniformly. Mobility and the ease of creating new identities on the Internet exacerbate the problem. Building a comprehensive VoIP intercept capability into the Internet appears to require the cooperation of a very large portion of the routing infrastructure, and the fact that packets are carrying voice is largely irrelevant. Indeed, most of the provisions of the wiretap law do not distinguish among different types of electronic communications. Currently the FBI is focused on applying CALEA's design mandates to VoIP, but there is nothing in wiretapping law that would argue against the extension of intercept design mandates to all types of Internet communications. Indeed, the changes necessary to meet CALEA requirements for VoIP would likely have to be implemented in a way that covered all forms of Internet communication. In order to extend authorized interception much beyond the easy scenario, it is necessary either to eliminate the flexibility that Internet communications allow, or else introduce serious security risks to domestic VoIP implementations. The former would have significant negative effects on U.S. ability to innovate, while the latter is simply dangerous. The current FBI and FCC direction on CALEA applied to VoIP carries great risks. --- end From jaltman@columbia.edu Wed Jul 12 15:40:10 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k6CJeAiZ027412 for ; Wed, 12 Jul 2006 15:40:10 -0400 Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k6CJe3Kv007147; Wed, 12 Jul 2006 15:40:03 -0400 (EDT) Received: from [132.219.7.235] (h07eb-net84db.lab.risq.net [132.219.7.235] (may be forged)) (user=jaltman mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k6CJdr5X003051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Jul 2006 15:39:57 -0400 (EDT) Message-ID: <44B5504B.7000304@columbia.edu> Date: Wed, 12 Jul 2006 15:40:59 -0400 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Kitten , saag@mit.edu, Sam Hartman , housley@vigilsec.com X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000808010102080507010002" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.42 X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: -0.001 X-Spam-Flag: NO Subject: [saag] IETF66 Summary of Kitten WG Meeting X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2006 19:40:10 -0000 This is a cryptographically signed message in MIME format. --------------ms000808010102080507010002 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The Kitten working group met at IETF66 on Monday afternoon session I. The presentation materials are available at: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=66 The Audio Stream is available at http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf66/ietf66-ch7-mon-afnoon.mp3.1 The Jabber Logs are available at: http://www.ietf.org/meetings/ietf-logs/kitten/2006-07-10.html =================================================================================== Document Status and Proposed Milestones --------------------------------------- Desired Enhancements to GSSAPI Version 3 Naming - draft-ietf-kitten-gss-naming-04.txt - Sent to IESG GSS-API Domain-Based Service Names - draft-ietf-kitten-gssapi-domain-based-names-04.txt - Ready for Working Group Last Call [Send to IESG - August 2006] GSS-API Domain-Based Service Names Mapping for the Kerberos V GSS Mechanism - draft-ietf-kitten-krb5-gssapi-domain-based-names-02.txt - Ready for Working Group Last Call [Send to IESG - August 2006] GSS-APIv2 Extension for Storing Delegated Credentials - draft-williams-gssapi-store-deleg-creds [Send to IESG - August 2006] Extended Generic Security Service Mechanism Inquiry APIs - draft-ietf-kitten-extended-mech-inquiry-02.txt - Ready for Working Group Last Call [Send to IESG - September 2006] Stackable Generic Security Service Pseudo-Mechanisms - draft-ietf-kitten-gssapi-stackable-pseudo-mechs-02.txt - Ready for Working Group Last Call [Send to IESG - September 2006] Clarifications and Extensions to the GSS-API for the Use of Channel Bindings - draft-ietf-kitten-gssapi-channel-bindings-02.txt - Ready for WGLC; blocked on draft-ietf-nfsv4-channel-bindings-04.txt [Send to IESG - September 2006] Namespace Considerations and Registries for GSS-API Extensions - draft-williams-gssapi-extensions-iana [Send to IESG - November 2006] GSS-API Naming Extensions - draft-ietf-kitten-gssapi-naming-exts-02.txt - active work item [Identify Open Issues - March 2007] GSS-API Internationalization - draft not published [Initial Draft March 2007] Guide to the GSS-APIv3 - draft-williams-gssapi-v3-guide-to [no milestone] Clarifications to GSS-API Version 2 Update 1 - not yet published [Send to IESG - before IETF67] Generic Security Service API Version 2 : Java Bindings Update - draft-ietf-kitten-rfc2853bis-01.txt - Next draft -02 Ready for Last Call??? [Send to IESG - October 2006] GSS_API V2: C# Bindings - draft-ietf-kitten-gssapi-csharp-bindings-00.txt [no milestone] ========================================================================= Proposed Charter Revision ------------------------- Revise the charter to include addressing internationalization issues. ========================================================================= Technical Discussion -------------------- * Discussed how Kerberos 5 Anonymous Names can interact with GSS export name and display name functions * Discussed draft-ietf-kitten-gssapi-naming-exts-02.txt. Requires much expert review. A significant open issue is whether or not OIDs should be used to identify "names" extracted from authorization attributes. * --------------ms000808010102080507010002 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJWTCC AwcwggJwoAMCAQICEDgwMdSemBfcGd6HY5Q4qrwwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloX DTA3MDUyNzIyMDMzMlowazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRt YW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAmFluisw/ NLjjXSHm0kgAgAMBknaWpJyDQlTpyzSswiSaDWINyEUzM/teBosk003zfyQdPONkWzclBRZ+ oGsYsAgxmyRe9tAJD7Jo6xp/6kCuF5nnaIyz91gWyuYZEeqQrfyFnWIfQu3fuoSeEIMLc9ac L9qhqnaTwCufH4v56CMftv6KFdf/k1CoLu/DL0ps5UOVwui+8iSWn3Qt6QfefDp9vbtBFPTV nZ7wGeewUJrO1LEC+x3gAOW+KxUcZMBax7tVygT5hDaQXm5lxUrlMQ/hLeWpv7LkVPD/ytoJ NCNzSnycrK4juG1CI12m5K1TNHZJ1uYjb7DUvMwOl6kQiQIDAQABozEwLzAfBgNVHREEGDAW gRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GB ACNK1Xef6H2YL02xqVthcdQgFuF0bENE1u7gX/hegF1awGERhaIJmKGWau4OiAeHnlFqWysP EFzVrSb6L+TF9YHd/bP8WtxccOFnZ1L6oe7KOiyNfXGPZKj/i7Gti+MF4RM1ReZncTC1zMmZ DbFkVhL92vSgDGl4+6IwzjmQVK3sMIIDBzCCAnCgAwIBAgIQODAx1J6YF9wZ3odjlDiqvDAN BgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRp bmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0EwHhcNMDYwNTI3MjIwMzMyWhcNMDcwNTI3MjIwMzMyWjBrMQ8wDQYDVQQEEwZBbHRt YW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMTSmVmZnJleSBFcmljIEFsdG1h bjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCYWW6KzD80uONdIebSSACAAwGSdpaknINCVOnLNKzCJJoNYg3I RTMz+14GiyTTTfN/JB0842RbNyUFFn6gaxiwCDGbJF720AkPsmjrGn/qQK4XmedojLP3WBbK 5hkR6pCt/IWdYh9C7d+6hJ4Qgwtz1pwv2qGqdpPAK58fi/noIx+2/ooV1/+TUKgu78MvSmzl Q5XC6L7yJJafdC3pB958On29u0EU9NWdnvAZ57BQms7UsQL7HeAA5b4rFRxkwFrHu1XKBPmE NpBebmXFSuUxD+Et5am/suRU8P/K2gk0I3NKfJysriO4bUIjXabkrVM0dknW5iNvsNS8zA6X qRCJAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB /wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAI0rVd5/ofZgvTbGpW2Fx1CAW4XRsQ0TW7uBf+F6A XVrAYRGFogmYoZZq7g6IB4eeUWpbKw8QXNWtJvov5MX1gd39s/xa3Fxw4WdnUvqh7so6LI19 cY9kqP+Lsa2L4wXhEzVF5mdxMLXMyZkNsWRWEv3a9KAMaXj7ojDOOZBUrewwggM/MIICqKAD AgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVy biBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5n MSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZy ZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoG A1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcN AQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHy v1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsY Pge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0T AQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20v VGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQe MBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD 6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZ GwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC 3CEZNd4ksdMdRv9dX2VPMYIDZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIElzc3VpbmcgQ0ECEDgwMdSemBfcGd6HY5Q4qrwwCQYFKw4DAhoFAKCCAcMw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYwNzEyMTk0MDU5 WjAjBgkqhkiG9w0BCQQxFgQUI0nbnpe5psJvalSooVg8/g2L64AwUgYJKoZIhvcNAQkPMUUw QzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcw DQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA4MDHUnpgX3Bneh2OUOKq8MIGHBgsqhkiG9w0B CRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA4MDHUnpgX3Bneh2OUOKq8MA0GCSqGSIb3DQEBAQUABIIBAArn1CyBKzBkbV7TDNUWYEwC TvQ3dHptROtRxevSIhLJtJiwezvyK00C/7a+ATnkDH6wWdjyqOBlYQTGeyjRHzpiv/P22Myx 4wcNH0kk9LHo0IFG3/Yjq63RI0NojHbgVi9Q1Ssa9maiS7UyXPXsYyzyMo00ogq1RAnDw1xG /WQotGmVR2tWF4Ywd5S0gI/K2i0yb/eOJnLRusCYEriIdtfICaInKlD5/6mpVRwLPcONeNCR Fq4p7FwWQjusE9zbNgQYBcpf4Xu8NQyT8Zuc4XNOBcC4+K8qKBk4PtDktABFHfhsvCs+zIFr weMMSjs2el1ktSNM4WywRLvsabxl5YwAAAAAAAA= --------------ms000808010102080507010002-- From stephen.farrell@cs.tcd.ie Wed Jul 12 16:11:06 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k6CKB600003267 for ; Wed, 12 Jul 2006 16:11:06 -0400 Received: from smtp.cs.tcd.ie (relay.cs.tcd.ie [134.226.32.56]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k6CKB0BB029640; Wed, 12 Jul 2006 16:11:01 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by relay.cs.tcd.ie (Postfix) with ESMTP id 37D093CAF; Wed, 12 Jul 2006 21:11:00 +0100 (IST) Received: from smtp.cs.tcd.ie ([127.0.0.1]) by localhost (smtp.cs.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29058-14; Wed, 12 Jul 2006 21:10:58 +0100 (IST) Received: from webmail.cs.tcd.ie (wilde.cs.tcd.ie [134.226.32.55]) by smtp.cs.tcd.ie (Postfix) with ESMTP id B15913665; Wed, 12 Jul 2006 21:10:58 +0100 (IST) Received: from 132.219.18.133 (SquirrelMail authenticated user sfarrel6) by webmail.cs.tcd.ie with HTTP; Wed, 12 Jul 2006 20:10:58 -0000 (GMT) Message-ID: <4776.132.219.18.133.1152735058.squirrel@webmail.cs.tcd.ie> Date: Wed, 12 Jul 2006 20:10:58 -0000 (GMT) From: stephen.farrell@cs.tcd.ie To: saag@mit.edu User-Agent: SquirrelMail/1.4.7 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: amavisd-new at cs.tcd.ie X-Spam-Score: 0.55 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: housley@vigilsec.com, hartmans-ietf@mit.edu, ietf-dkim@mipassoc.org Subject: [saag] DKIIM WG - quck summary for saag X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Reply-To: stephen.farrell@cs.tcd.ie List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2006 20:11:06 -0000 DKIM met twice at IETF-66, on Tuesday for an hour and Wed. for two hours. The WG chairs had asked for help from the DNS directorate about whether or not DKIM needs to define a new RR or is ok to use the current approach of a TXT record for the public key. The feedback is that although there's some unhappiness with the TXT approach, in this case it appears to work. So the WG approach for base will be to include the TXT record definition and not to define a new RR for public keys. The base spec is in WGLC, ending on Friday 21st July. Almost all issues are closed or should hopefully be closed in a -04 draft to be posted this week. The main issue remaining is whether or not the "relaxed" body canonicalization should remain in the base document or not, where we don't yet have clear consensus. We plan to try determine that on the list. We started discussion of SSP which is intended to allow signers to announce their DKIM related practices. A couple of drafts exist that outline proposals. Discussion here is just at the very start and there were some requests that we try to establish concrete requirements before going futher. We now have a draft of the DKIM overview document (intended to be informational) which is also up for discussion. Stephen & Barry. From warlord@MIT.EDU Wed Jul 12 18:58:39 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k6CMwdFc004833 for ; Wed, 12 Jul 2006 18:58:39 -0400 Received: from mail.ihtfp.org (MAIL.IHTFP.ORG [204.107.200.6]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k6CMwX1t006309 for ; Wed, 12 Jul 2006 18:58:33 -0400 (EDT) Received: from cliodev.pgp.com (unknown [132.219.19.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail.ihtfp.org (Postfix) with ESMTP id 9533BBD8387; Wed, 12 Jul 2006 18:58:33 -0400 (EDT) Received: (from warlord@localhost) by cliodev.pgp.com (8.13.6/8.13.1/Submit) id k6CMGjme006501; Wed, 12 Jul 2006 18:16:45 -0400 From: Derek Atkins To: saag@MIT.EDU, ietf-openpgp@imc.org Date: Wed, 12 Jul 2006 18:16:45 -0400 Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 3.548 X-Spam-Level: *** (3.548) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: @mit.edu, housley@vigilsec.com.and.hartmans-ietf Subject: [saag] OpenPGP Minutes / Quick Summary X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2006 22:58:40 -0000 OpenPGP TUESDAY, July 11, 2006 1850-1950 Afternoon Session IV Ten people showed up for the meeting. Only one person was am implementor, and that was in the past (he's not an OpenPGP implementor anymore). 2440bis has been submitted to Sam and he will review it and act on it in two weeks. He asked if we really still have enough interest to remain a working group. In particular do we have 10 reviewers working on the draft. The Chair was tasked with asking the mailing list and seeing how many reviewers we really have. If we do not have sufficient quorum then Sam will shut us down and ask that any future work be submitted as individual drafts (including taking 2440bis(ter?) to Draft Standard). Thomas Roessler gave a history of the Multiple Signature Draft. It's an extension to RFC1847 to allow the "signature" portion of the message to be a "multipart/mixed" and have a set of signatures on the signed data instead of just a single signature. This signature set could be a combination of OpenPGP and e.g. S/MIME signatures. An interop grilloff was proposed to start around October, 2006 and last about six months to take 2440bis to DRAFT, but we need people interested in the work to take it forward, be editors and reviewers, etc. PGP Corp may be willing to host a meeting if there is call and interest, and if the work cannot be done online. The OpenPGP Header work is on hold due to lack of time. It's stuck on an ABNF definition. New work proposed on the list: PFS, Deniable Authentication, V5 Keys, and Alternate Ciphers. Nobody in the room seemed interested. Charter and Milestone updates have been put on hold pending feedback that the working group is still viable. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From pekkas@netcore.fi Wed Jul 12 21:47:42 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k6D1lg4Z013528 for ; Wed, 12 Jul 2006 21:47:42 -0400 Received: from netcore.fi (netcore.fi [193.94.160.1]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k6D1leNJ029719 for ; Wed, 12 Jul 2006 21:47:41 -0400 (EDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id k6D1lcpE016605 for ; Thu, 13 Jul 2006 04:47:39 +0300 Date: Thu, 13 Jul 2006 04:47:38 +0300 (EEST) From: Pekka Savola To: saag@mit.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.2/1594/Wed Jul 12 18:04:34 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-0.0 required=5.0 tests=NO_RELAYS autolearn=failed version=3.1.2 X-Spam-Checker-Version: SpamAssassin 3.1.2 (2006-05-25) on otso.netcore.fi X-Spam-Score: 0 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] Remove tunnel mode from ipsec-tunnels-02? (fwd) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2006 01:47:42 -0000 FYI, There seem to be more generic complications in applying tunnel mode to v6-in-v4 tunnels, hence we're proposing to use only transport mode. Comments from (more) IPsec experts would also be welcome. ---------- Forwarded message ---------- Date: Wed, 12 Jul 2006 17:19:09 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: Remove tunnel mode from ipsec-tunnels-02? Hello, As proposed at the v6ops meeting [0], the authors of draft-ietf-v6ops-ipsec-tunnels-02 propose to remove support for tunnel mode in this particular context (securing v6-in-v4 configured tunnels). This is due to issues spotted by Francis [1] and Pasi [2]. Generic "::/0 -> ::/0" selectors could not be made to work without interface-specific SPDs, and those cannot be signalled in IKE (that's run on top of IPv4) when the tunnel would be IPv6 in a standardized way. Generic selectors are required for link-local traffic (e.g., ND) to work on the tunnel. If we go through with this proposed resolution, draft-ietf-v6ops-ipsec-tunnels would only describe transport mode. Comments are welcome. [0] http://www3.ietf.org/proceedings/06jul/slides/v6ops-4.pdf [1] http://ops.ietf.org/lists/v6ops/v6ops.2006/msg00159.html [2] http://ops.ietf.org/lists/v6ops/v6ops.2006/msg00230.html For the authors of draft-ietf-v6ops-ipsec-tunnels-02, -- 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 rdd@cert.org Thu Jul 13 09:20:07 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k6DDK7pX008667 for ; Thu, 13 Jul 2006 09:20:07 -0400 Received: from franclinus.red.cert.org (franclinus.red.cert.org [192.88.209.16]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k6DDHrfQ005307; Thu, 13 Jul 2006 09:17:53 -0400 (EDT) Received: from franclinus.red.cert.org (localhost [127.0.0.1]) by franclinus.red.cert.org (8.13.1/8.13.1/2.24) with ESMTP id k6DDHgTM020384; Thu, 13 Jul 2006 09:17:51 -0400 Received: (from defang@localhost) by franclinus.red.cert.org (8.13.1/8.13.1/Submit/1.1) id k6DDFwqZ020268; Thu, 13 Jul 2006 09:15:58 -0400 Received: from villemus.indigo.cert.org (villemus.indigo.cert.org [10.60.10.5]) by franclinus.red.cert.org (envelope-sender ) (MIMEDefang) with ESMTP id k6DDFehb020258; Thu, 13 Jul 2006 09:15:58 -0400 (EDT) Received: from localhost (magnum.yellow.cert.org [10.20.10.203]) by villemus.indigo.cert.org (8.12.11.20060308/8.12.11/2.64) with ESMTP id k6DDFXbu030217; Thu, 13 Jul 2006 09:15:35 -0400 Date: Thu, 13 Jul 2006 09:15:28 -0400 From: Roman Danyliw To: INCH Mailing List , saag@mit.edu Message-ID: X-Mailer: Mulberry/4.0.4 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, hits=0 required=5 checker=SpamAssassin version=3.000006 X-Spam-Score: 0 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: hartmans-ietf@mit.edu, housley@vigilsec.com Subject: [saag] INCH Report from IETF 66 (for SAAG) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2006 13:20:07 -0000 Extended Incident Handling (INCH) WG report Wednesday, July 12, 2006, 13.00-15.00 IETF 66: Montreal, USA The Montreal INCH meeting was a short and likely last gathering of the working group. The final items required to bring the various drafts to last call were reviewed and results from a recently conducted inter-op were presented. - A semantics inter-op with four implementers was conducted remotely this past month. It yielded valuable insight into areas of the data model that were in error or were incomplete in specification. - Another inter-op event is tentatively scheduled for late October or early November (before the IETF 67 meeting) to test RID implementations. Details will be forthcoming on the mailing list as everyone's calendar is consulted. - Based on substantial comments to the -07 version of the requirements draft [1] during last call, a new draft was produced. This -08 version will be run through another short last call. - Minor technical and editorial issues were raised by the inter-op will be reflected in an -08 draft of the data model [2]. This next draft will be the basis of a WG last call in early August. - An updated -07 draft of RID [3] and -02 draft of the SOAP binding [6] were produced to reflect changes in the data model. Both track the data model and are ready for last call. - Numerous outside reviewers provided feedback on the phishing extension [5] which is reflected in the -03 draft. This draft is ready for last call but relies on the core data model [2] as a normative reference. Relevant Documents [1] draft-ietf-inch-requirements-08 [2] draft-ietf-inch-iodef-07 [3] draft-ietf-inch-rid-07 [4] draft-ietf-inch-implement-01 [5] draft-ietf-inch-phishingextns-03 [6] draft-ietf-inch-rid-soap-02 From jsalowey@cisco.com Thu Jul 13 10:06:07 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k6DE67Fu018463 for ; Thu, 13 Jul 2006 10:06:07 -0400 Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k6DE61Cv003218; Thu, 13 Jul 2006 10:06:02 -0400 (EDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 13 Jul 2006 07:06:01 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6DE61I5003782; Thu, 13 Jul 2006 07:06:01 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6DE5uJw001737; Thu, 13 Jul 2006 07:06:01 -0700 (PDT) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 13 Jul 2006 07:05:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 13 Jul 2006 07:05:55 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF-66 EMU working group summary Thread-Index: AcamhXV6SrxUuJXTSMGKJdnu2wOCPQ== From: "Joseph Salowey \(jsalowey\)" To: , X-OriginalArrivalTime: 13 Jul 2006 14:05:57.0637 (UTC) FILETIME=[768BC350:01C6A685] DKIM-Signature: a=rsa-sha1; q=dns; l=1787; t=1152799561; x=1153663561; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:IETF-66=20EMU=20working=20group=20summary; X=v=3Dcisco.com=3B=20h=3DFAi8v2HQU2d91ZVfx1ZOVBA4b0U=3D; b=j6/nZBBRqIKCMIYfCpNgE6bMG2nzgjw9C3KqPpcwDshvxoDNlFtEueiiF+dDhklOuE7Q8BHj u48bhTTGaxjUeZB+FfY++rkGMNEBHCOdutMiYgTD99GdyCAszMD76Agb; Authentication-Results: sj-dkim-3.cisco.com; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.478 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id k6DE67Fu018463 Cc: hartmans-ietf@mit.edu, Russ Housley Subject: [saag] IETF-66 EMU working group summary X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2006 14:06:07 -0000 The EMU working group meet at 9AM on Wednesday The first topic of discussion was presented by Hannes Tschofenig on the draft Generalized Pre-shared key (GPSK) EAP method which specifies a PSK EAP Method. There was consensus in the room to take this on as a working group item to meet the PSK charter item with a modification to the defined cipersuites (switch AES-CCM for AES-EAX). The action is to solicit comments on if this should be accepted as a working group item on the EMU list. Next Bernard Aboba discussed the RFC2716bis (EAP-TLS) document. The presentation discussed some open issues of the draft. Interoperability problems with the TLS 3DES ciphersuites were discussed. It was noted that some variants of EAP methods based on TLS method used the same label strings in deriving the MSK from the TLS master secret. This is thought to lead to some potential problems so it might be advisable to use different label strings for this in the future. Lastly, identity privacy using TLS was discussed. The draft needs to be updated and listed as a working group draft on the charter page. Next we had some presentations on EAP-TLS related methods. Hannes Tschofenig presented on EAP-TLS-PSK which is an EAP method specifically for TLS PSK ciphersuites. Pascal Urien presented on an identity privacy scheme for TLS. The general feeling was this would be better evaluated by the TLS group. Hao Zhou presented on some possible enhancements for EAP-TLS. More discussion on enhanced EAP-TLS is needed on the list. Dave Mitton presented on issues implementing new EAP methods. One problem was that some access points don't pass some EAP types they don't know about. The action is to assist the WIFI alliance develop tests for this. From shanna@juniper.net Thu Jul 13 11:05:32 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k6DF5W9X032514 for ; Thu, 13 Jul 2006 11:05:32 -0400 Received: from kremlin.juniper.net (kremlin.juniper.net [207.17.137.120]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k6DF5Xdb009756; Thu, 13 Jul 2006 11:05:33 -0400 (EDT) Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 13 Jul 2006 08:05:33 -0700 X-IronPort-AV: i="4.06,236,1149490800"; d="scan'208"; a="562367625:sNHT28338808" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Thu, 13 Jul 2006 11:05:31 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF 66 NEA BOF Summary Thread-Index: AcalKRfO+PMqaWq2RTmBQ4LOO4SLUgBWMNIwAAJvx3A= From: "Stephen Hanna" To: , "Russ Housley" , "Sam Hartman" , X-Spam-Score: 0 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id k6DF5W9X032514 Subject: [saag] IETF 66 NEA BOF Summary X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2006 15:05:32 -0000 Summary of NEA BOF at IETF 66 The NEA BOF focussed on discussing and agreeing on a charter for a potential NEA WG. As part of this, there was considerable discussion of the NEA use case, architecture, and scope. The session was well attended (more than 100 people). Many good questions and issues were raised, all in a constructive manner. These concerns will be reviewed to determine whether architectural changes may be needed. At the end of the session, rough consensus was reached on a revised scope. The scope in the previously proposed charter will be modified to require that the WG identify a Mandatory To Implement transport (which may be developed by another WG). Also, vendor attributes would be required to be documented in an RFC. And the protocols developed must be designed to accomodate emerging technologies for addressing lying endpoints. With these changes, rough consensus was reached that the IETF should create a WG with this scope and the previously proposed goals. A substantial number of BOF participants indicated they would help edit and author documents. The BOF chairs will work with the ADs, the mailing list, and others to prepare a revised charter reflecting the BOF's rough consensus. This charter will be submitted to the IESG for consideration. From kent@bbn.com Thu Jul 13 11:13:29 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k6DFDSjC001621 for ; Thu, 13 Jul 2006 11:13:28 -0400 Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k6DFDQPe022369 for ; Thu, 13 Jul 2006 11:13:26 -0400 (EDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[198.18.104.95]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1G12sX-0000L2-5c for saag@mit.edu; Thu, 13 Jul 2006 11:13:26 -0400 Mime-Version: 1.0 Message-Id: Date: Thu, 13 Jul 2006 11:13:23 -0400 To: saag@mit.edu From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-1059318888==_ma============" X-Spam-Score: 0.257 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] PKIX highlights X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2006 15:13:29 -0000 --============_-1059318888==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" PKIX Highlights - Responses to IETG comments on the SIM I-D should be resolved by the end of this week, so that final IESG approval can be obtained. - OCSP Algorithm Agility: the OCSP RFC will not advance until the WG defines a way to address the need for hash algorithm agility. Nobody volunteered during the meeting to lead an effort on this, but the principal authors were not present. We will bring the request to the list to see if anyone volunteers. - Stefan Santesson completed a draft review for all three, revised CMC drafts, using material for two of them prepared by Tim Polk (former WG co-chair). After we coordinate this review internally, these drafts will be forwarded to the ADs. - SCVP revisions have been completed in response to additional WG comments. The document is already being evaluated by Sam Hartman, but we need to initiate the MIME types review before the IESG will consider it. Also, Sam will be forwarding his initial set of comments to us soon, with more to follow after he returns from vacation. - 3280bis has completed WG last call. One issue remains to be resolved, i.e., the range of name types for which a CA must be bale to impose name constraints. This will be resolved on the list, and we should be able to forward the document for AD evaluation next month. - We have an unresolved issue re the draft on Algorithm IDs for ECC. Specifically, the proposed convention makes use of the algorithm parameters field (in the subject public key info field of a certificate) to specify data that other PKIX documents have specified via the use of distinct algorithm OIDs. The proposed format is what has been adopted by the cognizant ANSI committee, but the cognizant security AD and the PKIX co-chairs are not comfortable with this change. There appears to be little interest from the rest of the WG membership re this topic. - There appears to be consensus to create a new access method in the AIA extension, for use with attribute certificates, to avoid overloading the id-caIssuers method. This will be confirmed via the mailing list. --============_-1059318888==_ma============ Content-Type: text/html; charset="us-ascii" PKIX highlights
PKIX Highlights

- Responses to IETG comments on the SIM I-D should be resolved by the end of this week, so that final IESG approval can be obtained.

        - OCSP Algorithm Agility: the OCSP RFC will not advance until the WG defines a way to address the need for hash algorithm agility. Nobody volunteered during the meeting to lead an effort on this, but the principal authors were not present. We will bring the request to the list to see if anyone volunteers.

        - Stefan Santesson completed a draft review for all three, revised CMC drafts, using material for two of them prepared by Tim Polk (former WG co-chair).  After we coordinate this review internally, these drafts will be forwarded to the ADs.

        - SCVP revisions have been completed in response to additional WG comments. The document is already being evaluated by Sam Hartman, but we need to initiate the MIME types review before the IESG will consider it. Also, Sam will be forwarding his initial set of comments to us soon, with more to follow after he returns from vacation.

        - 3280bis has completed WG last call. One issue remains to be resolved, i.e., the range of name types for which a CA must be bale to impose name constraints. This will be resolved on the list, and we should be able to forward the document for AD evaluation next month.

        - We have an unresolved issue re the draft on Algorithm IDs for ECC. Specifically, the proposed convention makes use of the algorithm parameters field (in the subject public key info field of a certificate) to specify data that other PKIX  documents have specified via the use of distinct algorithm OIDs. The proposed format is what has been adopted by the cognizant ANSI committee, but the cognizant security AD and the PKIX co-chairs are not comfortable with this change. There appears to be little interest from the rest of the WG membership re this topic.

        - There appears to be consensus to create a new access method in the AIA extension, for use with attribute certificates, to avoid overloading the id-caIssuers method.  This will be confirmed via the mailing list.
--============_-1059318888==_ma============-- From jhutz@cmu.edu Thu Jul 13 12:20:25 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k6DGKPR4016314 for ; Thu, 13 Jul 2006 12:20:25 -0400 Received: from chokecherry.srv.cs.cmu.edu (CHOKECHERRY.SRV.CS.CMU.EDU [128.2.185.41]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k6DGKIlw011113; Thu, 13 Jul 2006 12:20:19 -0400 (EDT) Received: from h0975-net84db.lab.risq.net (h0975-net84db.lab.risq.net [132.219.9.117] (may be forged)) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k6DGKAsM012966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Jul 2006 12:20:17 -0400 (EDT) Date: Thu, 13 Jul 2006 12:20:09 -0400 From: Jeffrey Hutzelman To: housley@vigilsec.com, hartmans-ietf@mit.edu, ietf-krb-wg@anl.gov, saag@mit.edu Message-ID: <1B892D2199A8223EB85F643F@bistromath.pc.cs.cmu.edu> Originator-Info: login-token=Mulberry:016f0EuFNleSw1SHw5HHs0J4BvO+NwMX1WcjIdH30=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline X-Spam-Score: 0 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id k6DGKPR4016314 Cc: Jeffrey Hutzelman Subject: [saag] krb-wg IETF66 meeting summary X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2006 16:20:25 -0000 Kerberos Working Group - IETF 66 meeting summary ACTION ITEMS: * chair: Update milestones * chair: Send ECC for PKINIT to IESG * chair: Send TCP extensions to IESG * chair: Start last call on Naming, Anonymous * nico: update Set/Change Password for last call MILESTONES: Jul 2006 Last Call on Naming Jul 2006 Last Call on Anonymous Aug 2006 Last Call on Referrals Sep 2006 Last Call on Change/Set password Oct 2006 Last Call on Extensions Nov 2006 Last Call on PKINIT Hash Agility Nov 2006 Last Call on GSS-API Mechanism Hash Agility + There was a brief summary of ongoing work: - Enctype Negotiation published as RFC4537 - PKINIT published as RFC4556 - OCSP for PKINIT published as RFC4557 - WGLC completed on ECC for PKINIT - WGLC completed on TCP Extensions - Most milestones on track + There was a brief summary of related work outside the WG + Shoichi Sakane gave a presentation on issues related to cross-realm authentication, which were the motiviation behind the XKDCP proposal. + Andrea Doherty gave a presentation on OTP work for Kerberos. + We had a discussion on updating our charter. Both the chair and AD would like to replace fairly open-ended language in the currnet WG charter with a more focused list of work. In addition to the eight items currently in the pipeline, discussion came up with four areas for additional work: Existing work items: - ECC for PKINIT - TCP Extensions - Naming - Anonymous - Set/Change Password - Referrals - Extensions - Hash Agility Areas for more work: - Cross-Realm - Preauth - OTP - Info Model + Larry Zhu presented open issues on the naming and anonymous documents. + Love Hörnquist-Åstrand presented open issues on PKINIT hash agility. From tlyu@MIT.EDU Thu Jul 13 12:45:18 2006 Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k6DGjIp3021918 for ; Thu, 13 Jul 2006 12:45:18 -0400 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id k6DGjLbW014518; Thu, 13 Jul 2006 12:45:21 -0400 (EDT) Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id k6DGjEVd015945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 13 Jul 2006 12:45:14 -0400 (EDT) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9) id k6DGjE6O009966; Thu, 13 Jul 2006 12:45:14 -0400 (EDT) To: saag@MIT.EDU, ietf-sasl@imc.org From: Tom Yu Date: Thu, 13 Jul 2006 12:45:14 -0400 Message-ID: Lines: 49 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 3.548 X-Spam-Level: *** (3.548) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: housley@vigilsec.com, hartmans-ietf@mit.edu Subject: [saag] IETF66 SASL summary X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2006 16:45:18 -0000 SASL WG Monday, July 10, 2006, at 1520-1720 SUMMARY ======= Thanks to Jeffrey Hutzelman for scribing. Document status: CRAM-MD5 - needs applicability statement GS2 - some open issues GSSAPI - sent to IESG PLAIN - approved rfc2831bis (DIGEST-MD5) - some open issues Discussion on DIGEST-MD5 open issues first because Alexey needs to leave early. Reuse same client nonce on fast re-auth? Probably OK, will check with ekr. "Server SHOULD verify authentication ID"? Really an issue for application profiles and base spec; use non-normative language. AES vs RC4 as mandatory-to-implement - no apparent objections to changing to AES. Some discussion about how changes in stringprep might affect things. Sam sees no applicability statement in latest CRAM-MD5 draft; Kurt will write one. GS2 - main open issue is channel bindings. Sam and others feel that channel bindings to TLS should be specified in a general way and not in this document. Nico kind of has an individual submission relating to this. TLS PRF is probably the way to handle channel bindings. Lengthy discussion about whether TLS implementations provide access to PRF. ACTION ITEMS ============ * Kurt will write applicability statement for CRAM-MD5 * Milestones: Aug 2006 WGLC for CRAM-MD5 Aug 2006 WGLC for GS2 Aug 2006 WGLC for DIGEST-MD5 Sep 2006 CRAM-MD5 to IESG Sep 2006 GS2 to IESG Sep 2006 DIGEST-MD5 to IESG Oct 2006 Implementation report plan Nov 2006 Revise charter or conclude From lha@it.su.se Thu Jul 13 12:55:12 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k6DGtC6n023791 for ; Thu, 13 Jul 2006 12:55:12 -0400 Received: from smtp3.su.se (smtp3.su.se [130.237.93.228]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k6DGt0Q5002957; Thu, 13 Jul 2006 12:55:05 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id E9CEC3BEA8; Thu, 13 Jul 2006 18:54:57 +0200 (CEST) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 32725-01-15; Thu, 13 Jul 2006 18:54:57 +0200 (CEST) Received: from [132.219.5.236] (unknown [132.219.5.236]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id 6CB243BE41; Thu, 13 Jul 2006 18:54:56 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-15-556311315" Message-Id: <55A9ED29-BA9C-41BE-B52E-3D5FDADE8C5D@it.su.se> Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?= Date: Thu, 13 Jul 2006 18:54:46 +0200 To: anonsec@postel.org X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.558 tagged_above=-99 required=7 tests=[AWL=0.107, BAYES_00=-1.665] X-Spam-Score: 0 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: Security Area General Directorate , Sam Hartman , Russ Housley Subject: [saag] btns - ietf66 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2006 16:55:12 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-15-556311315 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed BTNS meet on Tuesday on IETF66. We discussed the problem and applicability statement document. It should be done for WG-LC in August. One of the issues that came up is how to deal with credential caching and leap of faith (and to define that mean) and how much that that is in scope for BTNS. The core document describing BTNS have progress nicely and there are very few outstanding issues on the document. We have started to look at the API problem that the WG is charted to work on. There will probably be two documents describing the API, one for channel bindings and one for SPD/PAD manipulation. We had a decision if there was any overlap with the work from SHIM6 and HIP, but the WG thought there was none and that we didn't need to coordinate our efforts. Love --Apple-Mail-15-556311315 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEtnrbJyok7cfdyBYRAkvVAKCqlXA0ScxtQGtmzPFaqa0W2cV1zwCgip+C kPUuj/zytCY5dc/3MD8WgVE= =6C95 -----END PGP SIGNATURE----- --Apple-Mail-15-556311315-- From quittek@netlab.nec.de Thu Jul 13 13:21:18 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k6DHLIcf028641 for ; Thu, 13 Jul 2006 13:21:18 -0400 Received: from kyoto.netlab.nec.de (kyoto.netlab.nec.de [195.37.70.21]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k6DHLK0b016557 for ; Thu, 13 Jul 2006 13:21:20 -0400 (EDT) Received: from h0ad6-net84db.lab.risq.net (unknown [132.219.10.214]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 13D671BAC9E; Thu, 13 Jul 2006 19:06:47 +0200 (CEST) Date: Thu, 13 Jul 2006 19:21:10 +0200 From: Juergen Quittek To: saag@mit.edu, isms@ietf.org Message-ID: X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] IPFIX session summary X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2006 17:21:18 -0000 ISMS Session Summary Wednesday, July 12, 2006, 1510-1610 The two existing WG I-Ds on a transport mapping model and on an SSH security model for SNMP still have few remaining decisions to be made. There was consensus on clearly separating user authentication for establishing a transport session from authorization required for access control to MIB elements. The discussion on how to create sessions for notifications from a managed mode to a management system could still not get solved. From the management system point of view, there is a clear preference for initiating TLS sessions in 'reverse' direction. However, the security problems implied by this approach might be too severe to use it. Finally, the WG discussed RADIUS integration of the SSH security model. There seems to be different positions in the security community about whether or not 'authorization only' requests harmonize or dis-harmonize with the Kerberos architecture. From lha@it.su.se Thu Jul 13 13:31:45 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k6DHVjkv030655 for ; Thu, 13 Jul 2006 13:31:45 -0400 Received: from smtp3.su.se (smtp3.su.se [130.237.93.228]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k6DHVO8Z028112; Thu, 13 Jul 2006 13:31:24 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id DC1063BE54; Thu, 13 Jul 2006 19:31:23 +0200 (CEST) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 02378-01-6; Thu, 13 Jul 2006 19:31:23 +0200 (CEST) Received: from [132.219.5.236] (unknown [132.219.5.236]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id 26FC03BE51; Thu, 13 Jul 2006 19:31:21 +0200 (CEST) In-Reply-To: References: <55A9ED29-BA9C-41BE-B52E-3D5FDADE8C5D@it.su.se> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-16-558499855" Message-Id: <0EE60D29-C864-439C-9701-240183D9A99B@it.su.se> Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?= Date: Thu, 13 Jul 2006 19:31:14 +0200 To: Miika Komu X-Pgp-Agent: GPGMail 1.1.1 (Tiger) X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.573 tagged_above=-99 required=7 tests=[AWL=0.092, BAYES_00=-1.665] X-Spam-Score: 0 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: Security Area General Directorate , Russ Housley , anonsec@postel.org, Sam Hartman Subject: Re: [saag] [anonsec] btns - ietf66 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2006 17:31:46 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-16-558499855 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed 13 jul 2006 kl. 19.06 skrev Miika Komu: > On Thu, 13 Jul 2006, Love H=F6rnquist =C5strand wrote: > >> We have started to look at the API problem that the WG is charted to >> work on. There will probably be two documents describing the API, one >> for channel bindings and one for SPD/PAD manipulation. We had a >> decision if there was any overlap with the work from SHIM6 and HIP, >> but the WG thought there was none and that we didn't need to >> coordinate our efforts. > > I thought that the decision was that there is no overlap with SHIM6 =20= > and BTNS? At least we have been discussing with Michael that we =20 > could have some shared APIs with HIP and BTNS. My note is clearly wrong, I mis-understod what Micheal told us. There is overlap with HIP. Micheal and you seem to have this already =20 ironed out how to deal with it. Love --Apple-Mail-16-558499855 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEtoNlJyok7cfdyBYRAuowAKCi2Hh+CPArsRqqvO3NoRC3njEuigCguxXp HLM6ysThqri9zeS7pGVMqsk= =zzlA -----END PGP SIGNATURE----- --Apple-Mail-16-558499855-- From housley@vigilsec.com Thu Jul 13 14:09:16 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k6DI9G3i006386 for ; Thu, 13 Jul 2006 14:09:16 -0400 Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with SMTP id k6DI9KJC008502 for ; Thu, 13 Jul 2006 14:09:20 -0400 (EDT) Received: (qmail 6888 invoked by uid 0); 13 Jul 2006 18:09:15 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (132.219.17.242) by woodstock.binhost.com with SMTP; 13 Jul 2006 18:09:15 -0000 Message-Id: <7.0.0.16.2.20060713140820.07636f68@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Thu, 13 Jul 2006 14:09:17 -0400 To: saag@mit.edu From: Russ Housley In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] ISMS session summary X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2006 18:09:16 -0000 This was originally sent with the wrong subject line ... >ISMS Session Summary >Wednesday, July 12, 2006, 1510-1610 > >The two existing WG I-Ds on a transport mapping model and on an SSH >security model for SNMP still have few remaining decisions to be made. >There was consensus on clearly separating user authentication for >establishing a transport session from authorization required for >access control to MIB elements. >The discussion on how to create sessions for notifications from a >managed mode to a management system could still not get solved. From >the management system point of view, there is a clear preference for >initiating TLS sessions in 'reverse' direction. However, the security >problems implied by this approach might be too severe to use it. >Finally, the WG discussed RADIUS integration of the SSH security model. >There seems to be different positions in the security community about >whether or not 'authorization only' requests harmonize or dis-harmonize >with the Kerberos architecture. >_______________________________________________ >saag mailing list >saag@mit.edu >http://mailman.mit.edu/mailman/listinfo/saag From pbaker@verisign.com Thu Jul 13 18:12:24 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k6DMCOsP003951 for ; Thu, 13 Jul 2006 18:12:24 -0400 Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k6DMCJd9005904 for ; Thu, 13 Jul 2006 18:12:20 -0400 (EDT) Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by robin.verisign.com (8.13.6/8.13.4) with ESMTP id k6DMCITQ024019 for ; Thu, 13 Jul 2006 15:12:18 -0700 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Jul 2006 15:12:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C6A6C9.675D4B40" Date: Thu, 13 Jul 2006 15:10:49 -0700 Message-ID: <198A730C2044DE4A96749D13E167AD37BD633A@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ART analysis Thread-Index: AcamyTLlLy9WaIoST5m1ivonWE/JYw== From: "Hallam-Baker, Phillip" To: X-OriginalArrivalTime: 13 Jul 2006 22:12:18.0531 (UTC) FILETIME=[67B6D330:01C6A6C9] X-Spam-Score: 0 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] ART analysis X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2006 22:12:24 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C6A6C9.675D4B40 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C6A6C9.675D4B40" ------_=_NextPart_002_01C6A6C9.675D4B40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable As discussed in the SAAG. =20 =20 This document is rather old but it sets out the principles of structured = security analysis. =20 The document was written after spending a lot of time working on EASA = style requirements analysis. The idea was to get to a point where we = could reuse elements of a security analysis developed in one area in = other areas. =20 For example if one Eric's assets is a cookie there is always the risk it = is going to be stolen. That risk may be manifest in different ways = depending on the circumstances in which Eric is using the cookie. if he = is in a large conference hall there is a chance that all the cookies may = be eaten before he gets to the table, if the cookie is in a bank vault = that is not a likely threat but the cookie might be eaten by a mouse = living in the bank vault and so on... =20 Incidentally we have had endless discussion of whether risk or threat is = the term of art to be used in either case. I prefer to think of risk as = being the superset and threats as specific manifestations of a risk. At = the end of the day the residual risk is the set of threats that are not = effectively mitigated by controls. Attacks are an even more specific = manifestation of a threat. =20 As in EASA requirements work the consistency and completeness of the = analysis may be checked mechanically. So every asset is subject to = standard risks (which could be listed in a handbook similar to a process = handbook), within the context of specific use there are standard threats = to consider. The quality of the design can be verified by looking to see = which assets are not adequately protected by controls.=20 =20 Often I work forwards and backwards, thinking about an attack leads to = identification of a general threat, often resulting in a risk to an = previously omitted asset being added to the document. Then working = forward I note that the asset is subject to other risks, there are = additional threats to be listed etc. etc. =20 It is still necessary to have security expertise to check that the list = of assets is complete (in particular we have noticed that controls often = introduce additional assets and these must in turn be part of the = analysis), and that the list of threats is complete. The point is that = much of the grunt work can be done by less skilled hands and the expert = is only needed to validate the work =20 [Yes, at the time I was a security consultant trying to work out a = structured security methodology that I could build a practice around, = this was originally conceived as a means of allowing a single principle = to leverage the work of four to five juniors] =20 =20 I developed this scheme in 1996 when I was working on the security of a = US government Web site. At the time I was looking at deployment and = found it rather difficult to persuade people to take the time required = for such a comprehensive review. I have since applied it myself while = working on the design of several security protocols (XKMS, SAML,...) but = the results did not necessarily get formally written up. =20 As with Formal Methods a lot of the value comes from learning the way of = thinking rather than actually applying them religiously in every case. =20 The piece of work I have never got round to writing is the handbook = mapping assets to standard risks and risks to specific threats. ------_=_NextPart_002_01C6A6C9.675D4B40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
As = discussed in the=20 SAAG.
 
 
This = document is=20 rather old but it sets out the principles of structured security=20 analysis.
 
The = document was=20 written after spending a lot of time working on EASA style requirements=20 analysis. The idea was to get to a point where we could reuse elements = of a=20 security analysis developed in one area in other = areas.
 
For = example if=20 one Eric's assets is a cookie there is always the risk it is = going to=20 be stolen. That risk may be manifest in different ways depending on the=20 circumstances in which Eric is using the cookie. if he is in a large = conference=20 hall there is a chance that all the cookies may be eaten before he gets = to the=20 table, if the cookie is in a bank vault that is not a likely threat but = the=20 cookie might be eaten by a mouse living in the bank vault and so=20 on...
 
Incidentally we have=20 had endless discussion of whether risk or threat is the term of art to = be used=20 in either case. I prefer to think of risk as being the superset and = threats=20 as specific manifestations of a risk. At the end of the day the residual = risk is=20 the set of threats that are not effectively mitigated by controls. = Attacks are=20 an even more specific manifestation of a threat.
 
As in = EASA=20 requirements work the consistency and completeness of the analysis may = be=20 checked mechanically. So every asset is subject to standard risks (which = could=20 be listed in a handbook similar to a process handbook), within the = context=20 of specific use there are standard threats to consider. The quality of = the=20 design can be verified by looking to see which assets are not adequately = protected by controls.
 
Often = I work=20 forwards and backwards, thinking about an attack leads to identification = of a=20 general threat, often resulting in a risk to an previously omitted asset = being=20 added to the document. Then working forward I note that the asset is = subject to=20 other risks, there are additional threats to be listed etc.=20 etc.
 
It is = still=20 necessary to have security expertise to check that the list of assets is = complete (in particular we have noticed that controls often introduce = additional=20 assets and these must in turn be part of the analysis), and that the = list of=20 threats is complete. The point is that much of the grunt work can be = done by=20 less skilled hands and the expert is only needed to validate the=20 work
 
[Yes, = at the time I=20 was a security consultant trying to work out a structured security = methodology=20 that I could build a practice around, this was originally conceived as a = means=20 of allowing a single principle to leverage the work of four to five = juniors]
 
 
I = developed this=20 scheme in 1996 when I was working on the security of a US government Web = site.=20 At the time I was looking at deployment and found it rather difficult to = persuade people to take the time required for such a comprehensive = review. I=20 have since applied it myself while working on the design of several = security=20 protocols (XKMS, SAML,...) but the results did not necessarily get = formally=20 written up.
 
As = with Formal=20 Methods a lot of the value comes from learning the way of thinking = rather than=20 actually applying them religiously in every case.
 
The = piece of work I=20 have never got round to writing is the handbook mapping assets to = standard risks=20 and risks to specific threats.
------_=_NextPart_002_01C6A6C9.675D4B40-- ------_=_NextPart_001_01C6A6C9.675D4B40 Content-Type: application/octet-stream; name="StructuredSecurityPolicy.pdf" Content-Transfer-Encoding: base64 Content-Description: StructuredSecurityPolicy.pdf Content-Disposition: attachment; filename="StructuredSecurityPolicy.pdf" JVBERi0xLjQNJeLjz9MNCjMzIDAgb2JqIDw8L0xpbmVhcml6ZWQgMS9MIDQ0ODExL08gMzUvRSA5 MDk1L04gNy9UIDQ0MTA0L0ggWyA1OTYgMjk1XT4+DWVuZG9iag0gICAgICAgICAgICAgICAgICAg DQp4cmVmDQozMyAxNQ0KMDAwMDAwMDAxNiAwMDAwMCBuDQowMDAwMDAwODkxIDAwMDAwIG4NCjAw MDAwMDA5NzEgMDAwMDAgbg0KMDAwMDAwMTEwMCAwMDAwMCBuDQowMDAwMDAxMjMyIDAwMDAwIG4N CjAwMDAwMDEyNjYgMDAwMDAgbg0KMDAwMDAwMTM0MiAwMDAwMCBuDQowMDAwMDA0NDIzIDAwMDAw IG4NCjAwMDAwMDQ4ODQgMDAwMDAgbg0KMDAwMDAwNTI5NCAwMDAwMCBuDQowMDAwMDA1NzAyIDAw MDAwIG4NCjAwMDAwMDU5NDQgMDAwMDAgbg0KMDAwMDAwNjE3MSAwMDAwMCBuDQowMDAwMDA2NDI2 IDAwMDAwIG4NCjAwMDAwMDA1OTYgMDAwMDAgbg0KdHJhaWxlcg0KPDwvU2l6ZSA0OC9QcmV2IDQ0 MDkzL1Jvb3QgMzQgMCBSL0luZm8gMzIgMCBSL0lEWzw1RjREMTZDMkU5QUUwNTA1MjJBQzJDRjI1 RjM2ODUzMz48RTBCOUY2NDQ1MTQ3Q0M0RUJBMjhCRTRCRUVCODE4OEM+XT4+DQpzdGFydHhyZWYN CjANCiUlRU9GDQogICAgICAgICAgICAgDQo0NyAwIG9iajw8L0xlbmd0aCAyMDgvRmlsdGVyL0Zs YXRlRGVjb2RlL0kgMjQ2L0wgMjMwL1MgMTY4Pj5zdHJlYW0NCnjaYmBgYGZgYFrCwMLAwL2fgZcB AXgZWIGQhYFjApAz/0VP2zdDAwaBD+YMPgrHDRUgaiaEzHSXvnViXUAR12SNNxXPPbaBWIaPu1PZ FVYay1n56U6RaVpypibK0vGEls/xvskMaWlpDWCtHB1gWikNTAtCyFCIIJg0RrYTCIQZGMr7gDQP EIuCjVBi4GX6IdHAwLT0c9safcYytgYDx11LNsQ2NggdzGWTsDf7I86QDfWNDAPD7EQgzQTE1kAM 9MAqdSDNCMTvAQIMAMypPMQNCmVuZHN0cmVhbQ1lbmRvYmoNMzQgMCBvYmo8PC9NZXRhZGF0YSAz MSAwIFIvUGFnZXMgMzAgMCBSL1R5cGUvQ2F0YWxvZy9QYWdlTGFiZWxzIDI4IDAgUj4+DWVuZG9i ag0zNSAwIG9iajw8L0Nyb3BCb3hbMCAwIDYxMiA3OTJdL1BhcmVudCAzMCAwIFIvQ29udGVudHMg MzkgMCBSL1JvdGF0ZSAwL01lZGlhQm94WzAgMCA2MTIgNzkyXS9SZXNvdXJjZXMgMzYgMCBSL1R5 cGUvUGFnZT4+DWVuZG9iag0zNiAwIG9iajw8L0NvbG9yU3BhY2U8PC9DczYgMzcgMCBSPj4vRm9u dDw8L1RUMiA0MCAwIFIvVFQ0IDQxIDAgUi9UVDYgNDIgMCBSPj4vUHJvY1NldFsvUERGL1RleHRd L0V4dEdTdGF0ZTw8L0dTMSAzOCAwIFI+Pj4+DWVuZG9iag0zNyAwIG9ialsvSUNDQmFzZWQgNDYg MCBSXQ1lbmRvYmoNMzggMCBvYmo8PC9PUE0gMS9PUCBmYWxzZS9vcCBmYWxzZS9UeXBlL0V4dEdT dGF0ZS9TQSBmYWxzZS9TTSAwLjAyPj4NZW5kb2JqDTM5IDAgb2JqPDwvTGVuZ3RoIDMwMTEvRmls dGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJfFdNj123Dd2/X3GXttFci/rWsk2Lot2leUgWRRfB wHbc2gPEU6B/v+eQlK5m7BazeHOuJIrixyH59vunejw8HeHso4f81e/Tw+Pt7Z9/lOPD0y3Vo9Zx jqPkcMR8fHl3e38L58jj+HCT4+Nxa/Ec9Ugxn/X4fGvlxK4U69nj8enW6tkIh8OOTSnFMwP0cGai cgaF6WyE4ywKKzalLPwI1KBCyvlMugYxEXCc0dZwIhU5c7SDlFPyGarBwNV6Vj2aKajgZCcqpyRI qvFMQQ4s1lwA8QhcBEjBtZ8xHg/cPFI7UpMzhnjg2sTNLdjZQX2xVjr3GoLYS92WztANxqpwR5kH P82DRQ8OKNuB8HjqPsrJ68cZ4kIwYu+GoHHq0RejwULzA4ZToAF+otuPciG+9mXcMQ1f+DWH4Ivq lhziKQoFe3NIfJG6EMbNoVC8undwb7VVQKGk7quNQZDD4IMVwv1ZgnkYBlCIH95jcZQFZ/KKoxzl 3CQh5MqGmqF6JiKXCePkiCeozDSFDJWigbtkRr0wFosMQK6Na19y903YGBVLKMI25wvmdJZoGghQ 8UVD1VzmL87dXEaflwQMSb0ceEeGP3Khfcbh1ipwA8LLn6xomR3I7hzqQEC9xtLsgqJOKclDQU69 ZcJoZ5Fo/Rls+2b4d0NtLargF7CrilOJYVEEFemkGvjjtJBrMgS6qfUSVIXGox0qb+WVOWrq0HLm mM4Vfs0rKuAQRB3jSWkgVV1E4EaHmhBmQFtMUFmvSP20NNesg1hIIEVoYMB7OEh7EYF0wJDgAQtx 6oxVxgYFgUeElBYss3am/HR7/+b2G1OPegi5QJAK8KrAZLAViPbn4/EmSGySEOIKVvgMXI0TPN7W +sL5NNgVRaY2rC9VodLpIg3isD1chiY9WURNL33ocQ9mQt4FXoxzWbi9qhUX7BY8c/tknSmdSmRX TtfNCdScylzLZR433ZRVEgnScLO3NBqVWGmG67LBJdx242t2YYPUlI18eBdoTcTcSM16a8oNHSrr y2IhH5y9CLAmE5M+kO2JGd6G+XJ5RgrEqe+YbyLU3a3balfSFyQ3mSg56wuYQIxwim0vJIxFQILQ GNxfLQ0EYZYN22XIpyL8gGiUcUitZyl4XIK9UwGGeye94S2shZZVRU8HisVhB0UFNb0Z6Zx2zcrY 3kiA8q1PAmOUMZTrMuwuFWzG1AXXSTCVshELXk4dNKUneQgooGZlD3M1RZMWqsvO5JI4F5PhbJ4G bzDxKx0MiBZCYTciEqQzTFGrUY9AwVL1cI9+Ohg1VXuh1lVeJhO3i8fm8tQb7EBppXi6TZymqr7d Y3RC8fwpWqgW8xFHtZlLCyyVxGXXFU9oecdeboSFJQ+tRqUjiLGRwZxhkgEyk9xMHrSlD8wys3QJ /qlRcYibIXfsp31/vqQZJB3n6kyUra0okxvAshSPJ7o47TOmZXKw3V6lJI1nZYo4mqEtJpBKe2ki HuoWX/bt3b08xb3EYwaJtTk7bnWT58rO2/CWYZUw7aZ5iWu0sjDfvoIuWd9Uu68na2naZCemJhzG DxULksBSAXnZon6X2JWd2NFUenJicXlR9b7kRU27jEbWlgu7lHV7VCMzRSwFonHf0jaqyzas4bry TzQ8r8dK11Sv3l4KOry0mV4YL5eppBgxvMTVM0giWYuB8QJanKCuln51Ruu4h5XfPQsOVOs7HMq7 Kx39Jd/AFrLAY2tU1voMcRO/0tcNsdIXylSnRDteVdxsD4mlbhnkb+FMtMPo+WeGzLOyz9MLz+Vn h4OXFFud9cnPLmafmgcvUIgIl52eQ7sqqvWpWdgD6MLqrUvziSeTeHguu0e2nxvs2lRPM6JEx91s aL60IZ9mS9rYw2qmXNKmk/26vSUp0xP7dm/Sp7JJw3y91eGqgEl7lqtCeupimxkWG8kks7gC5muy ICSvQMUWn+NUt+1x+19eCA7eBExF1nq29SVazTBb52mlpSesuPUATiDrcGy2e7KHzkPzJixqNzM1 mZuDy1pQst+Mflk/RHYjbLGSrbNZccVwqiuXpWDjXXNpw2a4ahPejD0oHJ/h6kzVdcKreSMunxcm bwHKTH/mH6Ix1C0/8dlEg2vYo+BzmNzDrBCWzYuKkEmjP8dxhzqzLKQVfaKgHSzejM9lYZwNg10Y YFbJ+IddWBg2dEho2i0B282O0dz27JjVA9yoiobKBy/F0BLX7RkYmMRgssM6DW04aI/i28egH2iT TGHottnQgC8U2QgGNBQWW3R7jmSrwwTF/SR7fLWVAx3svHphPCCc1hjWFIWo7R5mCRb6iUzonAFx o55MrL5LgWB1C8MIW7VQrGwB6rxQ/WhhbxSqWdgfFpoNExg14ldobuXBNIbp02iJhB8thfgtHFGq dRlmnzS8WTSF5jwzkc1GQ0OTc1hCskiAabrNbSm3wz3M5a6dnQWAYw0gBcafMCRH2DnTIYo6RZdZ FDU2OQJ6HdEKe42IVkk4QaZZO4ZNmOlKomtahYMpDiOPH2eN5LDrpSHY9rgqC7YlNjK2rK1JYuMy Oxe8KLF16RcVJbYm9eKxhN7D2MLIJKGbMEZI2tYntg+T7EH+CRW8OZlzfmVp2brMxEI120LCeEGO nPipccM4ZTOndZUJUscmDcSdncAjleHUBu3Z5NUowFAulsObuASVg45MeHvoPI98qCBO2AoN65Fo A9CcF+0U1ZEPs6gTe2cl6nfQnQcFSYZQLg5JoEzru5AXlbGLdA1YYEDDJkkyLIUAhgESIoPRNrhD kdXjoLNcQhxZACH9VJB4AUawFoVlch1jl9leNzUvjPVI+Xh2SgddXovCkWk1rc9++8Ps/KnnGkMo vfiYqvOZPsomqqKJgij0iUvn3WUUtMRxNDMxmEQQtgO/ibUWrhNEuaj/rQ1vmm9XfDR2bomdh0Ht lxhNRtNVcwQJ7EyL25iJedI+opqZh8ZHda3aJKxYrVp+U4m+uuCYuHwNs+fF3F09DyZ2WpcqapfS 53G7Gz++n31DMv/WYmvd/Yt/kqawdQvI3d4spWF64cwiSgAoxIDFElz54DIhl1VY0y4PpOfubMMI IjsB9MB43TDZMzV3d+fnobhnOYSEmMdkI1CoJiSQqP9QTJiv1IGnAZnOgMZVg0VmyR7ZNk/NRjFh rvn7N7cfbnJ8UAKNLAI6un5eBIrza+LpX8PiA4xvnnPvhX2aMnZGRpbJ3rreqdyVTWPMdXTSSNB8 FQLWwzCxthleLiVcZXa1HHPIm/iZqFn22M/ok19qsbTcTaK2evv9E1zwdCBYRsehl79PD483KAcp JYcDkfPl3e397Q/329v7HZ487u9vou1QwJ/9JxgBkKytaGW/f74FeOM7UHLAw+4PgPf/3F6dx+v7 P/H/d6wUOR33P7741r7x7dm++5tvngi849X51alNg/8vwL/96X777eZvqew14CJ9ns4DMMPPxyMN 8T+eX42s9flLIcj8gWdS0AP4we6jIr1zDcLN1LLwX9iJ+gqN9fdXP72mb+XVu9dU9NWXjz9+/PB4 /OXxAbr+4/5XeiObN+AsFV1VdOHQNuXW2ijXDFHUC79/enr37+NvH5/+9bvj/uuXd7/8l+5q2W0Q BoK/4qP3QBQSHOgxVSv1goTaSj0kFwucxIobV8RVxd93bGxIKvWEBexjZtbetWN7vn1931PiBe1A RFr9/xdphqu+hq8Iuvm3BMKkIlLo4qH6E3rHtwQqBWe1cifbWWOPAzvYnjU9oXPn3DrbWsPeVPvd azeMQGNG2LJRUgExUlHtpvwow2biizsbz+VTzGYzEVwFXM1JG6O/WL14kcbIz+xRnlUfQcY6LxPG sCiwV8siDOsRYyyusMyTbipIRRmmOn4ZH5BtXLRzfjg9V+gQnmdvPesEHYOjNbJ/Jhw6vDuqH+mQ HNobZ42Rrbp1gxkruVnlN8x8kOdUEhoKP6uDVqa7i76czNYzDFGOxjVhuIFguMRyhg5cLan0SMiP K3gVHKG4fwUYAM6jIl8KDQplbmRzdHJlYW0NZW5kb2JqDTQwIDAgb2JqPDwvU3VidHlwZS9UcnVl VHlwZS9Gb250RGVzY3JpcHRvciA0MyAwIFIvTGFzdENoYXIgMTIyL1dpZHRoc1syNTAgMCAwIDAg MCAwIDAgMCAzMzMgMzMzIDAgMCAyNTAgMzMzIDI1MCAwIDUwMCA1MDAgNTAwIDUwMCAwIDUwMCA1 MDAgMCA1MDAgNTAwIDI3OCAwIDAgMCAwIDQ0NCAwIDcyMiAwIDY2NyA3MjIgNjExIDU1NiAwIDcy MiAzMzMgMCA3MjIgNjExIDg4OSA3MjIgMCA1NTYgMCA2NjcgNTU2IDYxMSAwIDcyMiA5NDQgMCAw IDYxMSAzMzMgMCAzMzMgMCAwIDAgNDQ0IDUwMCA0NDQgNTAwIDQ0NCAzMzMgNTAwIDUwMCAyNzgg Mjc4IDUwMCAyNzggNzc4IDUwMCA1MDAgNTAwIDUwMCAzMzMgMzg5IDI3OCA1MDAgNTAwIDcyMiA1 MDAgNTAwIDQ0NF0vQmFzZUZvbnQvVGltZXNOZXdSb21hblBTTVQvRmlyc3RDaGFyIDMyL0VuY29k aW5nL1dpbkFuc2lFbmNvZGluZy9UeXBlL0ZvbnQ+Pg1lbmRvYmoNNDEgMCBvYmo8PC9TdWJ0eXBl L1RydWVUeXBlL0ZvbnREZXNjcmlwdG9yIDQ0IDAgUi9MYXN0Q2hhciAxMjEvV2lkdGhzWzI3OCAw IDAgMCAwIDAgMCAwIDMzMyAzMzMgMCAwIDI3OCAwIDAgMCAwIDAgNTU2IDU1NiA1NTYgNTU2IDU1 NiA1NTYgMCAwIDAgMCAwIDAgMCAwIDAgNzIyIDAgMCA3MjIgMCA2MTEgMCAwIDI3OCAwIDAgMCAw IDAgMCA2NjcgMCA3MjIgNjY3IDYxMSA3MjIgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDU1NiAwIDU1 NiA2MTEgNTU2IDMzMyA2MTEgNjExIDI3OCAwIDU1NiAyNzggODg5IDYxMSA2MTEgNjExIDAgMzg5 IDU1NiAzMzMgNjExIDU1NiA3NzggMCA1NTZdL0Jhc2VGb250L0FyaWFsLUJvbGRNVC9GaXJzdENo YXIgMzIvRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL1R5cGUvRm9udD4+DWVuZG9iag00MiAwIG9i ajw8L1N1YnR5cGUvVHJ1ZVR5cGUvRm9udERlc2NyaXB0b3IgNDUgMCBSL0xhc3RDaGFyIDEyMS9X aWR0aHNbMjUwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDMzMyAyNTAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDY3NSAwIDAgMCA2MTEgNjExIDAgMCAwIDAgMCA3MjIgMCAwIDAgMCA4MzMg MCAwIDYxMSAwIDYxMSA1MDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA1MDAgNTAwIDQ0NCA1 MDAgNDQ0IDI3OCA1MDAgNTAwIDI3OCAwIDQ0NCAyNzggNzIyIDUwMCA1MDAgNTAwIDAgMzg5IDM4 OSAyNzggNTAwIDQ0NCAwIDQ0NCA0NDRdL0Jhc2VGb250L1RpbWVzTmV3Um9tYW5QUy1JdGFsaWNN VC9GaXJzdENoYXIgMzIvRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL1R5cGUvRm9udD4+DWVuZG9i ag00MyAwIG9iajw8L1N0ZW1WIDgyL0ZvbnROYW1lL1RpbWVzTmV3Um9tYW5QU01UL0ZvbnRTdHJl dGNoL05vcm1hbC9Gb250V2VpZ2h0IDQwMC9GbGFncyAzNC9EZXNjZW50IC0yMTYvRm9udEJCb3hb LTU2OCAtMzA3IDIwMDAgMTAwN10vQXNjZW50IDg5MS9Gb250RmFtaWx5KFRpbWVzIE5ldyBSb21h bikvQ2FwSGVpZ2h0IDY1Ni9YSGVpZ2h0IC01NDYvVHlwZS9Gb250RGVzY3JpcHRvci9JdGFsaWNB bmdsZSAwPj4NZW5kb2JqDTQ0IDAgb2JqPDwvU3RlbVYgMTM4L0ZvbnROYW1lL0FyaWFsLUJvbGRN VC9Gb250U3RyZXRjaC9Ob3JtYWwvRm9udFdlaWdodCA3MDAvRmxhZ3MgMzIvRGVzY2VudCAtMjEx L0ZvbnRCQm94Wy02MjggLTM3NiAyMDAwIDEwMTBdL0FzY2VudCA5MDUvRm9udEZhbWlseShBcmlh bCkvQ2FwSGVpZ2h0IDcxOC9YSGVpZ2h0IDUxNS9UeXBlL0ZvbnREZXNjcmlwdG9yL0l0YWxpY0Fu Z2xlIDA+Pg1lbmRvYmoNNDUgMCBvYmo8PC9TdGVtViA3MS43NDIvRm9udE5hbWUvVGltZXNOZXdS b21hblBTLUl0YWxpY01UL0ZvbnRTdHJldGNoL05vcm1hbC9Gb250V2VpZ2h0IDQwMC9GbGFncyA5 OC9EZXNjZW50IC0yMTYvRm9udEJCb3hbLTQ5OCAtMzA3IDExMjAgMTAyM10vQXNjZW50IDg5MS9G b250RmFtaWx5KFRpbWVzIE5ldyBSb21hbikvQ2FwSGVpZ2h0IDY1Ni9YSGVpZ2h0IC01NDYvVHlw ZS9Gb250RGVzY3JpcHRvci9JdGFsaWNBbmdsZSAtMTU+Pg1lbmRvYmoNNDYgMCBvYmo8PC9MZW5n dGggMjU3NS9GaWx0ZXIvRmxhdGVEZWNvZGUvTiAzL0FsdGVybmF0ZS9EZXZpY2VSR0I+PnN0cmVh bQ0KSImclnlUU3cWx39vyZ6QlbDDYw1bgLAGkDVsYZEdBFEISQgBEkJI2AVBRAUURUSEqpUy1m10 Rk9FnS6uY60O1n3q0gP1MOroOLQW146dFzhHnU5nptPvH+/3Ofd37+/d3733nfMAoCelqrXVMAsA jdagz0qMxRYVFGKkCQADCiACEQAyea0uLTshB+CSxkuwWtwJ/IueXgeQab0iTMrAMPD/iS3X6Q0A QBk4ByiUtXKcO3GuqjfoTPYZnHmllSaGURPr8QRxtjSxap6953zmOdrECo1WgbMpZ51CozDxaZxX 1xmVOCOpOHfVqZX1OF/F2aXKqFHj/NwUq1HKagFA6Sa7QSkvx9kPZ7o+J0uC8wIAyHTVO1z6DhuU DQbTpSTVuka9WlVuwNzlHpgoNFSMJSnrq5QGgzBDJq+U6RWYpFqjk2kbAZi/85w4ptpieJGDRaHB wUJ/H9E7hfqvm79Qpt7O05PMuZ5B/AtvbT/nVz0KgHgWr836t7bSLQCMrwTA8uZbm8v7ADDxvh2+ +M59+KZ5KTcYdGG+vvX19T5qpdzHVNA3+p8Ov0DvvM/HdNyb8mBxyjKZscqAmeomr66qNuqxWp1M rsSEPx3iXx3483l4ZynLlHqlFo/Iw6dMrVXh7dYq1AZ1tRZTa/9TE39l2E80P9e4uGOvAa/YB7Au 8gDytwsA5dIAUrQN34He9C2Vkgcy8DXf4d783M8J+vdT4T7To1atmouTZOVgcqO+bn7P9FkCAqAC JuABK2APnIE7EAJ/EALCQTSIB8kgHeSAArAUyEE50AA9qActoB10gR6wHmwCw2A7GAO7wX5wEIyD j8EJ8EdwHnwJroFbYBJMg4dgBjwFryAIIkEMiAtZQQ6QK+QF+UNiKBKKh1KhLKgAKoFUkBYyQi3Q CqgH6oeGoR3Qbuj30FHoBHQOugR9BU1BD6DvoJcwAtNhHmwHu8G+sBiOgVPgHHgJrIJr4Ca4E14H D8Gj8D74MHwCPg9fgyfhh/AsAhAawkccESEiRiRIOlKIlCF6pBXpRgaRUWQ/cgw5i1xBJpFHyAuU iHJRDBWi4WgSmovK0Rq0Fe1Fh9Fd6GH0NHoFnUJn0NcEBsGW4EUII0gJiwgqQj2hizBI2En4iHCG cI0wTXhKJBL5RAExhJhELCBWEJuJvcStxAPE48RLxLvEWRKJZEXyIkWQ0kkykoHURdpC2kf6jHSZ NE16TqaRHcj+5ARyIVlL7iAPkveQPyVfJt8jv6KwKK6UMEo6RUFppPRRxijHKBcp05RXVDZVQI2g 5lArqO3UIep+6hnqbeoTGo3mRAulZdLUtOW0IdrvaJ/Tpmgv6By6J11CL6Ib6evoH9KP07+iP2Ew GG6MaEYhw8BYx9jNOMX4mvHcjGvmYyY1U5i1mY2YHTa7bPaYSWG6MmOYS5lNzEHmIeZF5iMWheXG krBkrFbWCOso6wZrls1li9jpbA27l72HfY59n0PiuHHiOQpOJ+cDzinOXS7CdeZKuHLuCu4Y9wx3 mkfkCXhSXgWvh/db3gRvxpxjHmieZ95gPmL+ifkkH+G78aX8Kn4f/yD/Ov+lhZ1FjIXSYo3FfovL Fs8sbSyjLZWW3ZYHLK9ZvrTCrOKtKq02WI1b3bFGrT2tM63rrbdZn7F+ZMOzCbeR23TbHLS5aQvb etpm2TbbfmB7wXbWzt4u0U5nt8XulN0je759tH2F/YD9p/YPHLgOkQ5qhwGHzxz+ipljMVgVNoSd xmYcbR2THI2OOxwnHF85CZxynTqcDjjdcaY6i53LnAecTzrPuDi4pLm0uOx1uelKcRW7lrtudj3r +sxN4Jbvtspt3O2+wFIgFTQJ9gpuuzPco9xr3Efdr3oQPcQelR5bPb70hD2DPMs9RzwvesFewV5q r61el7wJ3qHeWu9R7xtCujBGWCfcK5zy4fuk+nT4jPs89nXxLfTd4HvW97VfkF+V35jfLRFHlCzq EB0Tfefv6S/3H/G/GsAISAhoCzgS8G2gV6AycFvgn4O4QWlBq4JOBv0jOCRYH7w/+EGIS0hJyHsh N8Q8cYa4V/x5KCE0NrQt9OPQF2HBYYawg2F/DxeGV4bvCb+/QLBAuWBswd0IpwhZxI6IyUgssiTy /cjJKMcoWdRo1DfRztGK6J3R92I8Yipi9sU8jvWL1cd+FPtMEiZZJjkeh8QlxnXHTcRz4nPjh+O/ TnBKUCXsTZhJDEpsTjyeREhKSdqQdENqJ5VLd0tnkkOSlyWfTqGnZKcMp3yT6pmqTz2WBqclp21M u73QdaF24Xg6SJemb0y/kyHIqMn4QyYxMyNzJPMvWaKslqyz2dzs4uw92U9zYnP6cm7luucac0/m MfOK8nbnPcuPy+/Pn1zku2jZovMF1gXqgiOFpMK8wp2Fs4vjF29aPF0UVNRVdH2JYEnDknNLrZdW Lf2kmFksKz5UQijJL9lT8oMsXTYqmy2Vlr5XOiOXyDfLHyqiFQOKB8oIZb/yXllEWX/ZfVWEaqPq QXlU+WD5I7VEPaz+tiKpYnvFs8r0yg8rf6zKrzqgIWtKNEe1HG2l9nS1fXVD9SWdl65LN1kTVrOp Zkafot9ZC9UuqT1i4OE/UxeM7saVxqm6yLqRuuf1efWHGtgN2oYLjZ6NaxrvNSU0/aYZbZY3n2xx bGlvmVoWs2xHK9Ra2nqyzbmts216eeLyXe3U9sr2P3X4dfR3fL8if8WxTrvO5Z13Vyau3Ntl1qXv urEqfNX21ehq9eqJNQFrtqx53a3o/qLHr2ew54deee8Xa0Vrh9b+uK5s3URfcN+29cT12vXXN0Rt 2NXP7m/qv7sxbePhAWyge+D7TcWbzg0GDm7fTN1s3Dw5lPpPAKQBW/6YuJkkmZCZ/JpomtWbQpuv nByciZz3nWSd0p5Anq6fHZ+Ln/qgaaDYoUehtqImopajBqN2o+akVqTHpTilqaYapoum/adup+Co UqjEqTepqaocqo+rAqt1q+msXKzQrUStuK4trqGvFq+LsACwdbDqsWCx1rJLssKzOLOutCW0nLUT tYq2AbZ5tvC3aLfguFm40blKucK6O7q1uy67p7whvJu9Fb2Pvgq+hL7/v3q/9cBwwOzBZ8Hjwl/C 28NYw9TEUcTOxUvFyMZGxsPHQce/yD3IvMk6ybnKOMq3yzbLtsw1zLXNNc21zjbOts83z7jQOdC6 0TzRvtI/0sHTRNPG1EnUy9VO1dHWVdbY11zX4Nhk2OjZbNnx2nba+9uA3AXcit0Q3ZbeHN6i3ynf r+A24L3hROHM4lPi2+Nj4+vkc+T85YTmDeaW5x/nqegy6LzpRunQ6lvq5etw6/vshu0R7ZzuKO60 70DvzPBY8OXxcvH/8ozzGfOn9DT0wvVQ9d72bfb794r4Gfio+Tj5x/pX+uf7d/wH/Jj9Kf26/kv+ 3P9t//8CDAD3hPP7Cg0KZW5kc3RyZWFtDWVuZG9iag0xIDAgb2JqPDwvQ3JvcEJveFswIDAgNjEy IDc5Ml0vUGFyZW50IDMwIDAgUi9Db250ZW50cyAzIDAgUi9Sb3RhdGUgMC9NZWRpYUJveFswIDAg NjEyIDc5Ml0vUmVzb3VyY2VzIDIgMCBSL1R5cGUvUGFnZT4+DWVuZG9iag0yIDAgb2JqPDwvQ29s b3JTcGFjZTw8L0NzNiAzNyAwIFI+Pi9Gb250PDwvVFQyIDQwIDAgUi9UVDQgNDEgMCBSL1RUNiA0 MiAwIFIvVFQ4IDIyIDAgUi9UVDkgMjAgMCBSPj4vUHJvY1NldFsvUERGL1RleHRdL0V4dEdTdGF0 ZTw8L0dTMSAzOCAwIFI+Pj4+DWVuZG9iag0zIDAgb2JqPDwvTGVuZ3RoIDMyMjEvRmlsdGVyL0Zs YXRlRGVjb2RlPj5zdHJlYW0NCkiJvFdLj+S2Eb7Pr+CRCrZlvR9AEGCzGwQ24HjjbSAH2weNxO7W rkbqFaUZt3996kW2pmdnkYMRDKYlkcViPb76WPzunx9jdbR3f9/ffbffVypW+8NdHIVRoiL447c6 UmWWhmWh9g93kTrC/77Fn6c7rYL9J1ya8NJdHqZVnahdUYV1lCVq//4qk7FMTaprlUZpWKg8C+Mq ilG1TlDwH2DKO1uo1qoorOoqyl48bTveZXEaVpUqIxgEOytVqNncHXjtu4+wFf59fPevu1j9APt9 UkmYqydVqR/VL79FqoPxXt3lSRxWCagpQM0O9exIEal34w93LkLiZlyHdcURorc4Ay9AOs/D2Edp B8GLQCHESocUg0jBWBonKYWFx/Z/uZnNt7PfXgFvEauXr5dbXoUhrl/unKEQtaRQGdlehFmGLv9H jejlK74VdYXxJt/8lqDz37TmBjGwRpXwChH0C8iINCIpeKBIkUeiEw0vigIF2YcM0fWLfmutWdTP vf38RgVxqfen2TSL+lW//TkoojDT+wA80b8GKvht/wOHq8ZYscL0CtS3YzNcbG8dGAvJZOG9LcRb lVeJxyTqyTiiaFcci11BDOHQ6keznKZuGqbjRR2mWX2Ygwws0NMytdOgPpp2nfvl4q2Lw7gsSmdg hupeMzDzxegMjLyBaRomiTMvLim+34/LPHVru/TT6HRIQcPGSRjlWeE2jvPsGmpx6d1qlyAPCz09 mFn9FFRhqu+DHYb3k4GJRLc83z/ypw3AnVKzb7BZ/XX2QIOzOglTDwXy969RVFZ/e25mmBUQkegZ abiKC9MUKoPmriCnt5Lt/zBPAdSsfgzA2UT3QQ2/HX8Y9RDE9NKMVi2TaoMyzPU0LiQ1Q6oMjfxO Ks70O/Fau9LXbBQLy7AKCj0DLm/dx5jURYaprhKE8fs/0enU4zBhp9+bQw+ZKvVolL3YxYCfnJRd oZu5PfWLaZcVjG8CEAJPUt2h6dMZHNZzs/TjkV0A/Bd5UvJuOxdZ3i6R7c7z1JoO1EEQIV6lPgU7 OBg0lOSDgUK1Hu+FPk7NYF9GpwK2qWMKDyLjzwxP7MMTib0fzEyJLwEOaOdCv2LmZuQiUG6nIIMI jdYElf6y4u/YgrMYsEOQa3Wm+RnENYvywMTraVkH4KogMDjejEccwmjhNrxE3eOYasYGHoPsjxN/ mO7/hSZf+QKnwtcQFDcAQavlBEmd+eO4Ds0yzRfVQnLN3DcYkFPjRO8Nv4wIhlgrwmCqDVBzoRfl ffoGo2VxHkb+JIjzwmdS2Gl/MgpYJ9dAqZCIFYkpgwJESqohfqAK0vNhaEb1fmpXGI31gxkXv3ny OjulNZS+2/srUaG9C+3JnHbpppacXtnpZz7DtsDjHKX+eBouyi7zylVWhlldbjCbeE9T3g2pqSZc gvLZ0FeH+KoQuPSJyMQnYJOeCoGV6ANKQfwtL274YagC4Dnytw1QKFTi1QQnFqg4NqyxJ5k/ZC1/ Tbz7SJtwQHfiB26ITwep2CculcTB4gx0HIIETVtO/ElbdzIH6aLnA/BrBSHEMxzBhGMLBBQdl3WT iA6dYumGpT+LWv5S5vezyPVtv2x2bQfZUw4vo3rIYuV3M/NuNgD2XsRGdf9M80LSTzCmjRk3iu3S LCADPYRzw6m0V0sLTuVGX7jtDLK09LDIvloAlC6ENqSrggelq5J0Vbp351ZM1ZhBhRA0MoQGBWYh U04sIUloSdVKcg/kH0OFw46j0zrQOjo5kL0IZSsvFGXPVYtBii0aeZDl2aDR8hSiMdUsbQgjY9tv vqzqSe/4tV2eO0A43xjfwKm3jW7toxvlvsQ5uNBUdj2UaXM+Yx1AR2DoMS7bBJVZkl/J0yM9ESXf Ix4QUCWGCmkBLGwG1TYWcgbcQNNw9kCMY+YNbCH4tDwjpzjSOEPdDxfHF3AHKTaEce3c8po3Vp2x wMwUmfMWCY8uTB2ncZuGlT9c0Dj0EjlsHjY67yWLR0YUzrKgT4O90JSVPIrSK1WQC7dJuHK8+HHb r+BJTATUUb+Wcr+G3ZqVaRsQ7fPsio0ZnAkzIABy2RkaPQN09XQxnWQSLjVJlBabYzCuPWdlLpNY pDX1eGd+nfGR6Aba65Zgx6Vfa8roKkKYTFkwkGnNRlPHrxM/WohYpWUhMkQulAEkg0DgIRF2SN45 61/wrueLRIJ5mM0XXJzxHsBXBMKRPzBAywzNcC9Ul7kZItRSD2+8yRmTFbQ3CIhS3/NgH8QICXoX IsyQYVdKgLIc7SosqmQb7cgfeLE07u5YhfRDZeTcU2IDX8HvElDb7jCB8yPPdwq60fOEtQU8DhA5 uWnE3tHYUEFFStjEjBuWfcEDyGlY9yeEEgKrn3lgpfO9BoQ36CjxEUq01AlXMCNLuMBpCQ/MPU0j MLDERY9M2kUdZlfn10C5m6aUh6DS8LFfcZnm1Drm1DoiG5uZAEUlXzMzNkIn9w2RLWynDiQ00ZqZ M4yvphUBfkwj35cAvwGe/J95mAgg1m+udX0N6haLHoq51PVAp65+6gkvmniQj9lHOklxt8jhLMWQ uaOT1mHvAM15o0i6oYTPvVk4cHAVzfL8W7cA7q4Vd/DUo79o/0ngzM04tuWjNPR03pSuv+fjT6GG Rx5peMnasCLq/0Pfc1avN7xJCc1AgbGSlrcofF+v31prwHlp34vXO9ckr8O0umohKm2dguftf7Jp PD3sJUN4VkLxlJwavNkaO60zoJvaa7VM4jr80uWJpcFVwULiusEyq/JvsJJ4hvl2THNR989Yhsi1 ETY6XrlGpAZ4NW884TTcaos4dUgi+CnY5UgcSFmPjp1g/rEZHCN+2w6/93U9z4xqmvGY92TaOB7s 7wejnhwXzrzfc15dnd2w/oZ6v9Kt7FyW5IDiKILHPa3J9TK7N9u3UGhw1Vj5+x4DQLXNZYbkBF2/ 2JqDrfwEixvOCmhyVJRm/8MdZeA7Smf4nMyYOJEwLvTBNw2+Q7QNS/Nem4uIYs6t3VLFFxGZdPcd bERgj5urDOS9u7mUkOUbmucAVj6A4sCBo4ZdeeYuG0ALfIHqoWmTkHAwYebETxjHfk6+3uBJBMTB J62c5tB8LT0cC2ZpQwzM96IcTg45EdO4zLb9x4squQV/+Qz8z23LwDa0aoPHg8BqZnjfnvBUJCIB zJois87mvDowv5R3ZygZ/gKdpQ+u8G07mGYGJFKUkE93MVcBEmSu+VB63ExyUeBtzDi5kZ+qPyi4 wD0QC4OsL1NUBStVxx898dHh0LfrAPe9SVZ/EcWNqFv6w+XVjv5Fme1PUja+Fcqpi0q0qyes6UoP 05m/HwCVtdgOpQknDvhqXX8jQtgY1mIRBANqGVu11a9yjT8wewlnma/CNHZcDZ1b3xxvb7zyPbe9 vbnVovlPclPtW3nZ3F35fio3XmhJzvw2I7rBHWt7UXSEorziQQzctvW358pygpvVYqlxK1FhQvcg /sQrku7gpLFymqgD9kqASrtI5fCNt/sv42WT2zYMROG9T6GlAwSBKTqSvQ2QC6TZZSXQbETUkALJ QtGePu8Nh6TqNGlXJkV6+Dfz5hs/MQM5mTXeWCK+y1JV14c1XuZHVGck6b5NYcQThN+4mEEEp4la ZQXyOtkA9QomcDNBcsrgY/pDWdNNvyQFZpHhmh/ioHBPo8A2X0L0O+EbG3MAQszr5TOYCwdJVxs6 85wKmziYAtcAibB3kpRMyMZUGdw4xC8umvGT9n1yLfi9+XBr0lTYJMWgzvu2QF3YALryOHIQeC98 uOY5ODR40PcwXirwwRteBv63Rm9d7FqTd1n1jKoe0Zjns1JJyrPM8S2wCh9qXhjggdUFmDtNFVyh R1luqHMODgPQ1Cm1+L8Kb93Y+08ICEEFX82AEElH4AeZyzOSz+PP24jvBAHm8lNYtE8gwB/68NoX tZTVroveQ6a8Fy50Y1OlUDM7r5Xp8F/K9A91mfsxtpY0DOxMWladA+4Z0KDueF88SBQjuHRx7bHZ FyVaPZ1qUi8A2TJjZ1R00ke4MpPM4RTHJ61PTszdVcfaiamROSzffTHE5R+fN0RdUyOJVraB4GIr d/sDC43Jb75vHp7/ysbGILPv1mzcFsL2WJF4nIwb5HH8IMU1NN4egemfGm9qTlvbF3faJmD/AvuP +Ot+Rf2t+MPL9inMP+YYo7l6+IL7W4hKOZfYUBNXyG927VodS20EAcvkL/gmfsIQGi7kn1PsdlES JexN6r3GMa9ySUfp46fqz4maq8tU1y2zV9OiXWar6yrCWwXEu/z27wIMALGGuXEKDQplbmRzdHJl YW0NZW5kb2JqDTQgMCBvYmo8PC9Dcm9wQm94WzAgMCA2MTIgNzkyXS9QYXJlbnQgMzAgMCBSL0Nv bnRlbnRzIDYgMCBSL1JvdGF0ZSAwL01lZGlhQm94WzAgMCA2MTIgNzkyXS9SZXNvdXJjZXMgNSAw IFIvVHlwZS9QYWdlPj4NZW5kb2JqDTUgMCBvYmo8PC9Gb250PDwvVFQyIDQwIDAgUi9UVDQgNDEg MCBSL1RUNiA0MiAwIFIvVFQ4IDIyIDAgUi9UVDkgMjAgMCBSL1RUMTEgMjYgMCBSPj4vUHJvY1Nl dFsvUERGL1RleHRdL0V4dEdTdGF0ZTw8L0dTMSAzOCAwIFI+Pj4+DWVuZG9iag02IDAgb2JqPDwv TGVuZ3RoIDM1NjQvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJlFfJjuTGEb33V+SRNNAU 90WAD2N5gXwy5IJ9EHxgs7KL9LDJMsnqVvnr9WJJklXdoxlhMNUkMzMy1hcvvvvbPyNzmh/+dHj4 7nAoTWQOzw9RGISxCfFPnqrQFGkSFLk5vDyE5oT/h4Z+3h484x/+S0dTORqax7wMqiiPzeHPulqx qMokYRLkJkuDqAwjEuUlejj++N4oTU2BxzLmi4MwjDK69Gfvp27+PJt6sn4eFJ7phmXq/DJIvcFP vLlrzDKa2vi5d57Gxs6znwUVlPnP4e+kYRSkaRWRgo8kNEzZHBJfifhDa81sGwhPvIsfB7k3dcvV nPt6MCQr81r+Ol56v/SOpu/mxTyPk7F105p6nu1iFsiYSM2Ar/3L4YHMyas0KFITh3ASTA3SoqpK M9mHZwrBvQOSLKZteQVFxPfv/L6FDHL0JJ74riIPSjpGVkZFRoe9T1PTdottlstkzdfdn2dVEOWr +2PnqTC59VQB/178NIjhKR9h9hb+vfInOI7f2HtFEMF79Jm8V+HzkQJ1tLNI0fNP1iy82vqIV+lZ RBunKg/q7y6wfKaRl8vEro6qICVVwzXCUeL0jkvR29Kdo/+YIsLPiGXqIWDyykvzdV6s/5hD6osP d0SUZLJu5ouee+6azurXxY9o01Fl+LgXOtZdT6l4dl8zXDS9dIu5yYmsQF0kqJuCMqKkhPxSRvD+ tAiKUErIFYWmxc/slkqclsGUY8fv8G0Jj1/muYNTK28c4MvMYyc8QyvE6ObgZGt5p3jBN7XsPxqR Mw4Li5nGXnehpLzbRE/zIAIoZPDDV62KURX5rV2crN+S5HFG97gsz9gXlJcTeTvyaooEhYeqdpZc Eu9/JfHDIsich+NUasfpkyvYBRUwcUuzuJLLKZMIcOBFeVjuLoyDpEz2CfoegkwHfGMAUsQ5M+LY pkPWGeRk5Nl6mM3T1by1nUBVK5hHqEN/X+qrQRlBi777vz0GYvZjEiRZlRAKFmmckQo7DRhbqKhv LYXXwjLdV1Qkps72lfwsAHlnZRKEVVburczXMozUyvEZOi8t5ZvhQisRMSo3Vr2p++bS14s9AlRx TcIZ+zz2/fg2f7+GUZVEjVVhGotlJVsmCjJ4/9G8wkmcEIQV/cXS5dQixsXyyiArS1f3pkfelwQQ 9GWezS+8w6CdPNVPXU8CcZqODkvHe51c04/Yf+eKwx/UAysQRQpEPw4cTAjny9C9Fpg925kbyEya pZ6aQM7id+cxaD9Y2XKU0/xpVHyJ0BFzRGoXtjUA2kifgEyCVnL2uHtf7MQhST2GPs/yIu166xgs PaPrrshaPU3J+ALEwMrSIYgMgN4kKiKF524cAvPjQkkuSelUReyiNCk2hdfCiLUwBH3TPfqmhL4e Aa39n66yRgVMUFhPBdbPo+7fDhYex1sXEDoyjp3/eiOqvzg5CAMd28vVtQE4KD6kBU7Yqb92etdJ /ig/qPXr0Uw1qXkjcSUqUVoVrkRd79JuMnHbGp/krda/mps3na3XVxhXN804aZPquBdr/zpB9YJ8 qE2uJo24VctlVv2RiD+Q6Lx82fdMRNq+u/rNvNj1wmg74tpqrQroHhLU7vU7tdvC1y0PzGFr4zsv JpsXXR7ZVxcnjq+rsPvQuvxZIcolxHVLLQ0lbX+6EepKavuiReW5pLBHlxWIjN4E8xJ3DD7zBpc5 pNu43bWl9rN+JWDsbrarsqpWD2l2A04UnDayLCkrBs48zG7RIkZrD8l9jNf/mOgmiNNMoEc6Jt4X fFAWEGcJkVckMHgNSIWJ0FHjLzObElS+NADuYG3nipcQUNEMQBr8qybkprTywS2QRvbYXV7wAuZA bLE7te80KMMAHVxVSPMvq1BFNGukOQB10yHZsSuqJMDfRwQiRecmBhLftbsiiMsq245Tk3gz25Nf knoeFwl9oSIpqUgSxz1L74YupkVJI0RSxkywYBXb44zNoyCOP/D3LtzvXY8rTZryTLK6fmOVq5Nv x4XozuiNAsF/YaZo1TMMjpSGEcx9AYEkJkzWgZzS2gVWSoVHCUKNGPLnEw9trRx8F1OaR3+vlVUA DpMmkSTYvZGSOjcmVkKVbixMxMA4V/teeO4kgwoxKFWDUAqtvJ8Y00IY8QjKRdPj/fc74+L8GxOW 0gFXhfkWtnVEi4r7YTbjYba8G2YLHmZLGWaRiffjLOgk7/pMKUmDQmtZFsGfjlshxtg9zyvWpq1V S+A5M3MAV20dOVVmajAP1VRXTMDgRe6+1FCIXOYrMt8UQQQ/mqRA6bjxIvptN4U4kOpogWiTaRRs Jy+UiQLJyfKKCm9flJfHtO1G5LdNK0lR0aObVvJYWPQPGKgmVyeR17/jjx9ZlECLDaXej7ifTKO9 eB1RqZ9O+rHnCcPMbjZdBwsqN1u7IVd6LfhJ/flmtB02qqBnOhBhouDCc1aeAG5DmdR3btuwLue0 zJzA8hTgqEa9BLvm7bj8o6PNYmaSiJl/ZTWQ1Jyt8qz82KcLVG7pcRVcdDOllCMUJTCKNBUmgtNz qzIvbjl3tA6rXB0u91EwCdB9x7CzVUHRz2oYMglD5pFalYYho1jDtVbXiMO++MgRtIFHGl+X7iQr xBH1CIUEdQiXyh49MGwbuyXwHytv49as5N3EF3F7koKNXMrMnU80NoW9J2rsRBkI3YiRmIaxe+TV YfGJqbic1Y2UCxRa2n7lfTTGWf4KXxe6bZQ1jHUkRQTKUbp+oZ9TvWwXO19neak4swPvYFV/zbOI /UGe0BeoSLg70TgA2EPkx0HZnaTbDzANEAirSg5Oz39nPwzSnRv5/h0rf7xVQ8GOoK3u55FMnxno zz7driVWz2fbCBoS3WQ0RTjn67xYrhEErsasRAo1bbc4kE3SItmD7DoZRcpoIfUyWZ2rcC/S6UTC AQB2qvv+ikwcXu3Q6cdFL6cih3sKzwLzLaWgGqx33o0h0TpEkgpCpc81hhi0QBjJ9AVxrajPUWZU wqOPFvBTYkiYOt54lv3yQikAnis+8aWEecFJ4LNUSbxP1ibeOMqOnj/NPAfenIRLyfmzlR2v+hnY xzIHeT+y4LujSPhiu0Gum+glxnlw67Oqw79HPTQ0qiwNA1YEvtEaoFNWBid3EC9NImZnwfvJ5eNM q4ejQt0c0H3/bu2k6VSbhh+os4zAetxI+cyQTDMXJ1USJGUS79ErX9FLa8oIrqBSpm6Ykb4I9cJz UivfAd1To8/dghwU0SAvWb4nBSsvSZQMA1wphjqs1ceR3s/0s3DZESHO2I0dJbSZ+cAzSqgjuHTb DOEpgQhv5sSN0YVSgMJ94r4HPPvLmfCo3lDPtPxHMOmN/MW5mHryna1lGGwF9RiwCKka+kX9cVtB FGjP67ZHBF5muk6R8SibkEmIe8NIN9HWJ/l+FEkCsa8dDY3uBEeXsfhjGA78jTP/NiGJM8AM+Wql JGtxa5h+snN3vLDGdW8O4oaJ4YVaLDLWfOJMG8RZNW/oSZnMu87dN3GZOEVR5aIGJ0u68fJPjlfl blitinzXBTbCmziyiS5WUse+QGOqD+649XKnSBaUNFbuIHVFNnKDZD/5enEBT4g/wer1S8xyTVsz nA/jAsy3zBYGXlv7USL96GiemHf8ynq1LLcJBMF7voIjOZhil8eyVa5cknwIRviRcsku9PDvp6dn gCW2Yh18koRmdpZ59HT3AsUymEZ0QIW6UFcp3UkwnmkQGr9NBIC2hKBJptcpnSRvbgplzv+8dFWU senW9LlljcwzkUmr1vn9d+EWeHumE9KJ6QRGGbp3OgEIIk3pcuK/wN4NZatnK0Cisttr8oDB/IeT fur/6jfyO3v+zjzslJOGURc1fpJ95fNXfabmT/y+f9hebswswYCEsvYpB/oyuXQ4CtPAgmWq5qZT GATqVrWzdC+hbLQoigTDVWshZMhVHb1OmPgdDuUz0UVoJX4nhAsvZFsBujDqgST7XmVTIpJ8WRfB ZxVUpZT8CpXkIjzaFQ7KMi4dyL6SGYiqAfzaXhbPRQjErELeNdrlUKERmzTayp3z4goh5QIaYAGt pn6H7D/B8x5QLqxqkLug+FgSpuThkQiJzSs/nq+BKAQpWp9cNqwx/bZ1OtRFEDMQz9nitQ1CyDPZ ODIvZDu7FzMX9itCaK+21CBiflLq8GwcgydwQWBAZHO0s8Ud//sz8yUxGKjdjjO1kY8XNc6Gx54m e3o9jJleQ2PaHSZy15f0ArJYfL5pMofuKlssklAILH/SZDVaEgJ1k8wV4+bCRy3DjW+I9bhA5wUL f327LcvQ/di0B0K2zkZsOWEuZFGh+xO0e8ddf/c6cbtJ+eC98jvlbZJhzW9kfkVrtQtpPaqoSHkv RjklpZOcPCnrO6vT+MZDjWIq8zvNFFbYoPFI8Xzsz/zfOHWfXmcYxsNBjzyvhPM8TgTrZr6BctNs n8YxRnxnrTIt1WyRtQrX95nHZAItP61m04qZqyAiuk9qCVhwIX59MTmBTbtO4G6rRICLJhvsvV9T wTAK/5zLbVpkzx2mPtYOfDJqh6BfPm4Wsblc24q1ZTXEEOtwGj/QF7OM2G2q4lpBcO/ra2as6lox cxCsst3/P2F4ex8aVkWm+Quq8o5QkLmAEfW20HXVH6QyPamDrnHjFv1Jd7wtcCUjk2B3FOJLhz0f kixMpCl65Fk5wPimjGRxOhD/H+kka5tkRvWZDuhgUXbquMl9BC5mvgJZlMSHGC+vtSqinFmMRWw/ hjYc+VeAAQB1xbXpCg0KZW5kc3RyZWFtDWVuZG9iag03IDAgb2JqPDwvQ3JvcEJveFswIDAgNjEy IDc5Ml0vUGFyZW50IDMwIDAgUi9Db250ZW50cyA5IDAgUi9Sb3RhdGUgMC9NZWRpYUJveFswIDAg NjEyIDc5Ml0vUmVzb3VyY2VzIDggMCBSL1R5cGUvUGFnZT4+DWVuZG9iag04IDAgb2JqPDwvRm9u dDw8L1RUMiA0MCAwIFIvVFQ0IDQxIDAgUi9UVDggMjIgMCBSL1RUOSAyMCAwIFI+Pi9Qcm9jU2V0 Wy9QREYvVGV4dF0vRXh0R1N0YXRlPDwvR1MxIDM4IDAgUj4+Pj4NZW5kb2JqDTkgMCBvYmo8PC9M ZW5ndGggMzQ4My9GaWx0ZXIvRmxhdGVEZWNvZGU+PnN0cmVhbQ0KSIm8V1tv3LoRfvev4KNUeHVE kboVRYE0SYv2qTjZPgV9kCWuV7UsLSStHffXn7lR0nrjxAcoCsMrihoOh8OZb7755W9ftLqfbv6y v/llvy+UVvvDjY6jOFEx/PGojFVuTZRnav94E6t7+N/X+PN8E6hw/x9cmvDSXRqZokzULiuiMraJ 2n9aZSzLlKS6VCY2UaZSG+ki1qg6sCK42lEW3g4YaWtVrvUivwPrdJaQMVEcxzla9DX4ODyeOhfa yAaz6+nJb1O4S6I0mFTFs436GGYwMYQ7HfRbkXaaeUlfv6jw3/t/bI742jtoVVbiUcQksMmbZDSb tD+GOxtlgVP1wKPHsIyK4MQvnUNDWSIEFWUwTWo4qBnMK4Jl7eTqM4/Hdn5RfnEYg1Al6xUrrljN i7rzavEQuoiSzKRgOlwLmRov3tPiPeWequ5cwfnRNY0Ks+DuBX/ro6sf2hBUgK92Bh73aj5WM1iJ c0eecyg6uq6a26GfwjTKg2N7Yh/u/P47uENb5qsVBq34Gty5+dnhxuB4VU2Tm1FDFtyqseXRA+5i gumWdtW8q4ENKxHF7au+AT/38zh0k2onMn7wDsh1krED6NTpEspfKQQgPEIN+7ehwWug8UxjFyZ4 dH6JUOnfD7fwqw6wcUJBBKtHelHuW/UY6gQkTx2vVpWqyVFgGFxRGYB19EVtt0K1jZtYcuQvd64h w1Yn0hleO1GOEpE38TgzBU4awBU1Aw8dOaOXt1k9tnN776XQRL8GHYqi7YwO9LMQvtXkKCxLcL1m 5a5dvo+oQr6uerwdGJNFQCbcyQKe4uBP6fRi25MXQHeO3SDTD9vp5mrVSHe0sZdcFrOvTL7ceomu 4tCz7CyMlxAS2tC9WHjCveAD76WgPaYzTMCFOrgciPEDi/HkQL9njAEdTNFmX2tLveyrF6yyHhgo rcMc9kBNmi89pZhLgxeaUtORnsO5g8jxSQmXQcso8MqAwi1FRMG3jpY7sn3ejAH6GtZZD/TsJ94P jhnMpJ0Fe16lpjDnY5UAALySvxx5suK3P9KBP+9vCA2hWACwJCaOLORaZAs87+huDlhnXuOnyS2K ZRZurOAKc1VdSqkuiUGXFgm679PNnwDyiz9flAzcEbwcX9QdD9yRManZgJ+2/jqSkq/jM4Ud1IuR IA9Q5wGdT3PDmZ9dw88F6CAhBpmqBLYWb0B1yhIb5WCeKSEW0Bt5CbXsTW/EGDKwKIuM/Yk3dLog QYF+/x+4JF5coheXoDMAbRlrLad0R3gMYeoaxSP5CjHawOGqDha0/0VIQSde+CPOoFbqNIt08nN3 ANppXAOP7GfuyCOT58n/L0IAM/gFkANgQ8IDfQNukYiYjldxA5kaQ33ZgfcYfC2Br6xHCAPwcR1J sGx/JSUziIMgPIys1KtwgoBWCuPG+2lRRCZTSQ6V5aepaU0KUmkB5Sp5w/n2baqWZnAhC09L8wX7 Enblv6a2vw9TgmvE6i/EOIDjAATisWYgNhYgUOND/bMDigPCnwYgQeAYh28s8h6GltoSsxAPsTA0 jnh9icSFYDpmf4hXawmFoc5DJYc76KlEDyIIbjdQvlAK+BitwpKWU0HIsIoxmbBYrHDoAFARVyvC 8GrCT1QRD7xipLEYgGqPjnYaN8aRotfWjSz3hNPuWXYZyZGOQqo51y0GSc/r73nZsDVaVayD5vgL mY4/vSzYVtQthbsCjhkc2hObM3h4BAeCkUHGBJ8nBBOUfB7GBwVsA8kPHK2A+gZldLNbbpN0zcsf MGzQe/I0WSjyMLmFJIB3wR0asVoYc3VueCRkR8SYis1ufGw9N5e0kl0ady/b4ImA4jnk7FuSTvQd mHpVy7rWPXk+noINsm+E6zVt+IGIxnt4Psg9Vi/fuY5L3PLhfaiwzhdEDIAGULRBEKmZ2gUq5ngf jlg1hbJlZgHmTLz0jtcKw68wxAywWemb8OUWw0gYwqKUb4TXSuOliKxgl4I38cJz4Q6ZKS/FJceK bHlyzHakkyN+3xzZzpEfjWzIZ7p9tb2c6OcG3Ald3P9Bgsws4F+wEzkQTFCdTjzo2rq6kyHSAAkQ IwEiY/RKFvgl4CnNoWgQ3CDtsIa+YMe5y6gz1OREEaHg8nkHFT8zNpf+Zcm4dM04Ch+IuzxAHMXo 6Sp6xZ6Nzo3JD1QcgeEFz9z2LH84uHrG/s4CAIDV0QKrxdsYb3Mg4tkC8tnSTsbSTn44N9BjEHiA iz80x5Dr1g5vjy+jDncJ8U7LEGGF1PqxLFFfWKI+c+ji4bAovAf9bZpHWeLNjJMFPqyHjwE94sEg ZTCAOOOxY66LBtN7vdw1fZWcTzcJm1LCwmYJZSypXuUrvkywKc+yLd24irgzB4FEUjtLpYf4kC/T rE4+zFJ0y2EYfQRVEq5qkMFuaoFCPImykHoVOOcsoUYYKeE8ufHJ+Y5TDH3dRV2BzPPRCZ64kQDu NRLUlIycpz1/Y0GBGk5SbLnAmoZTl+oB4Y/Pdn7tfbxcYg15FpqxPNY/5LWcF4byAvXU9CbFaRwd s9rT0Dd41yxbh9ggzueqU6exgmypfZbs/JZUqYq1UiVLywesizb+K4UahL9yVBdS6cZo0PNjDrkT 5bdONTxwVILRIXfbCfmqWn+gVKrJLOrXCNWbCNVUUowEqPYBiuKSBZojbpL5QVQAw/f2PsJ1m0DU VUI8WUe4GOaYcdBFZqv43A6Lrd+vYiuaGPbdPV490CoHIFoGRMWeeWqmXwoD7HJrjMMsgJuieSpo CWIpxjx+NcRtDCXzu5DOlHYDITpbIETr10gHOAcFwiIAYHmBGgEvd0IFO/Q/ZADQEDKGQM4iyAnE EcD9PngzeYZmenj7DjsavsN1VjIj9Sxb61m2GCqUiRgOs9Z30ZN2JvKDhKprH2Sj7mXZtLrYX/Qt tg0jX23XKc+9XHPBzE5bHgWg55lYIkFZbAjeZVVfIFaqJi6FpEk26EjYaAUbcbeahB65FcGtKdbf ZKdXXeNe2jHnL8DiIaVFI58e5c03i2Ee+H7RfZP276IZXHs8SrUP0+Tm6Vb92k4P0y2jYLFpdS+O HsvR1Z7ICOhJqFMMEfsmALucCAMwf1I91jRBYi3JsKSr+XkeHQkAytBTpll06Km9GQ4Q5jnDtWVV S3kRO19l/2ou+hPNndwFp8ESAAlWBu/LX202OaLTcukA06sERkMRmdLg8+EQeqClgxEoPrmeJ6YJ KT/PIvmiNV8I5By3VGBxSHSC0/93JHVSghqLXvCsZcnqdENaPGXxGQ1ESjnmck/01tPvNEkHlGIy +2pfqWcHOfYMXp1Z0FeKtU5QZluuEgH1asuGpA7rA1UGqAskAnp5T0hZQvhA8j4NVoa91kauz1Ic mwEpQhGcIdYNksIe4THF2oYPfpkgWV13+EF7mC+uSrYJmK8JmPsEzAOkVCU8K+ScL2pEmDqf+Bsz J4rbjFOAtayhyDPoI9DQq8OiVLYhqoulTyS56lHwUE2iAFqtkzTGFgsyWQQFynLMx6tKuXuVLOLJ aqyPgGf1DNkZQaJTcTRc3UPsMzDasbhDeAJ/Gs6dKAe/43WsLcbXgBuEb9hBVNJBQNdAsbA/InCA xR/h3rAdnKmDGIduUr7xAP6qfnVT2yBxAksYcgxBzqR8u0K/6J3J4wIbcnXUpbolekFwQ0XKeBZj fN85ut9or5IdtYEges9X+EgOIG809ijKaBSNRG458AMOdoCI2BaL+f28qldt94RDkDK5DJ5eqmt9 9arvTpeHACJNQR3Sqd6mLurh8nWojtdKKZfhBFk9m9jXX71+VVL4BbBCujx7ZywZrHySt6Nvp46H eeQsOAbIqLn7AlcIWRESv6V4tNPlTINpYvSNI4V+2VemTfMQsMT5IikCYJmQJVl5ZIkkKktMgvAl ZhjYjd4osU0RuxRvY3DUVEhnfSW2/iA56GFZd0blI/9Uwp4SYIDNPFmyyqeeFI8jT2KlqlYiUdB0 tE9oXe34+LhiwR0O6DizG3lW4zvp9ahHaxXR8UKL9GtOT7oxOqmkk+ZeK5x0iSvGzI9Fo0+YZYvP m59B+sRBY4U07nmPL7JsmYVD3ejddBWCUToCtSJzyzVDgKfoBQTD1hqN8k0BW3ejQztwq+MP6AL+ Dv64Jlz97FmAS+IiUCgd0TE3l4vkdXU28m7eHfhdSas+Xv0G4ix8RP45nC+Hlp87/pjy0dbkVG+3 hdzW2hyfP0p1l7OJAaiOfx0w19XAIRBKHIJZkUNgOBfuRm+FI+X3htdbjotMIl1BLktWd4MWYS4a Kom8S5XFqnS5aAqsyN83U4JaKHymNFqImBamRPHNwZJE2i3P3CJdRnYw8uiVS1cGD/h4X9Tkk1QG BNbXbVNLRBKBKRU5dzOKFMyH4zTUOxPfHFn5IEItUEFiK9RdKmuUcuc2RH2ZZf/Tb28s3OxDK+g8 8dzcmfF7GqYtSIxxk+7rSi8NqL/mxitsctYf3SIul0UAYRN82pgqaeZkQBUPyxCkXdHR44l5HJwj 5aMwMEmZ23JLcpv+5q09pZgK7k661ZCpFdQQnVOOfga2InQatFqdIK+LQo9m+T8E6g++59wUp7ZR ykdXk/51RvtOSk46AbQSIOfJX9TbRq/MG/1Gb9U8Z93+dfPhtwADAMPruJcKDQplbmRzdHJlYW0N ZW5kb2JqDTEwIDAgb2JqPDwvQ3JvcEJveFswIDAgNjEyIDc5Ml0vUGFyZW50IDMwIDAgUi9Db250 ZW50cyAxMiAwIFIvUm90YXRlIDAvTWVkaWFCb3hbMCAwIDYxMiA3OTJdL1Jlc291cmNlcyAxMSAw IFIvVHlwZS9QYWdlPj4NZW5kb2JqDTExIDAgb2JqPDwvRm9udDw8L1RUMiA0MCAwIFIvVFQ0IDQx IDAgUi9UVDggMjIgMCBSL1RUOSAyMCAwIFIvVFQxMSAyNiAwIFI+Pi9Qcm9jU2V0Wy9QREYvVGV4 dF0vRXh0R1N0YXRlPDwvR1MxIDM4IDAgUj4+Pj4NZW5kb2JqDTEyIDAgb2JqPDwvTGVuZ3RoIDI2 NzkvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJrFdbb+O6EX7Pr+CjVGx0ROq+KAqkeylO sQWKXT91z3lQZNlWjyOlkpzE/77fzJD0JfbutlgEsUSRnMvH4cw3v/zti1br6eavi5tfFotSabVY 3eg4io2K8SdvVayKNImKXC0ebmK1xv+ioZ/nm0CFi3/T1lS2xuo2L6NK50Yt3tvZikVVKomTKFdZ Guky1iQqyGgaOqrSacObTlNVaB1pQ2tuYYHOUlJIrzHtfL75Grxvn9ptmEV5MDzikQRdv+anwm8W 1OpLixcTNLux42VzGEdFsA81PdTn9kk+y6rn8LaMNPb+vvj7ERDwxkRxlubkjFhSeNe/Bp/q+zCN qqDdQrnfay6DSG7lBTz0bsU6YWF4M6VIvJvUvGlVmAd9eJvCm508HshsHdzLqA2xPQ9GWjfIp1Vo ojRQrd02d3PXTmp5sn5qxs5LyLDcTquuh1Y7oaa2sUrHbt6rsX2SURfiSIL2mZSeSGmGExudMrWt x7UT2s2qm9TmxJxtWGD5o7Xf6tyq2YpT9dK+2SUzGyAw42AwSKvCHUysK4dlkgqWtWoGhqMKnuTR 4rTKwH6bOzdLHq0GeR9h9r1bDR0moLO161q/ldGd7R51fyxeNaP9PoW3Jphux5ZN1iUuUJwhHrzJ r45/1Y7uBJt2qVbjYEFVFor+BEE6K7hhp15Hw+mh8nGyKbfOFgYxOQIx8yCKQQx9JmIzQNHsrdcZ zqe3b3SzqmDTjpE6Op0iLTMv2Hi5mQj+iL0Z0G5f6Fk/hBUMfqT3LaSlMJmMz/Csd/ScNwMWv1rG UnCnEW61nFwm55bYc4OdDS/qn3iuZ2GdfELg8woA98zauoYfqq3tC2bcFoCHEO6Wx2JWXbt06+6d KQDmapBqf+K54MBhT7dAA8JHGbScmEbV1BOngsexXXUvMidX2q2ZunUv43ru7NuatsjJY5mNWS0O NPXcrgf5MIa3CRDc0/LfkHimdn6jPnfTHzL9hr4vNmNb43M7N9FvIX2prbgl8HZZSjsvOFgRbmPX nCAgEcbZ2weCthE27VZwTi3bqQtLuLTu65lfOsQwFKyVDOGQwe0SQOpx7prdlidqxEWYA71eVpCj kfryn109tup+rJt2YlsMgkIX6dH9i/390/b+qRqSUoKGdLOu3YSLOA8wkKf6YW45RSPY2u0kqbNl G+lQKCZfZnvLnMajKGBlxaGYGdE7rDiTQgzBuJEAZvVLfCkozOlLswPCCSui+93LchxPBNtMsJaH +srC7rgaxjEL0L/zN7tgsWlhL/SJWit9y9Lk13567iT94CaRFDXt+IkTk+8vyII1ixolIyHeeGjt fLTS9rytXb7loa+UuA5SKoF2nhacNSgtWaAMn08amcrdlnc1OzW3YRWshxG/e/Vlt6L83bGKF5H9 YXGTpBVSkMqKhIiEjjKliwiFfGxvVsR2zsuzodKssqyKEi7QR9eVeQ5fEEd2bImHp8hxRAuMt5mZ SnDHK2GGycFGYIWOwIjKjEwiW9gKrTp1k2QoMt7Oh5ukwnzuxtvDmCVsD+vteOU9JWLlHM2Md/QY 58s+pzoqnctyQQPKA9929vZwQsFn560zJcmjPL0A+vdtMahXqTeGb4rNQj9gTqxl/bk5ujqKgf8J mjiPSh8OMVdHROEQJih7/TyCwRi6K4aK4zkB/AZg784tjHGa/4+BaYl4PQtXstRSoM+UVcnW5Y6z V73lkVqElPo3nK5ATwqkzXr+EfvjoxvxrzMn0hIBeOnULzHhFPFb5Qcm/Iq9/cqMcX2BuMlgrLfb vVRDT9WmbnTkjehBZlkEjeHeDAiywI5b1ViW1jtyeJEXQjKdMRGPTOqzk22374UWW0OsEkcMX3FJ yqD8odmcs8lpM9i57fKgv7ei5gOZXdGDeGkzX+MZr+jWcyd0yrMqSLtEiL7BsCzToVIoLIvybc/T KIlNN9dOCv0Q9wUukfpVKBa8Y8JnqbyUtttMxDcsi3me6LdWTcrZPQgJFKYuOtk6p39ypId8Y1AW f7KRVXgszBHlKshC7QjFIJ9Am6nGPcoIFCsYqWeyY5izsgvHg7+MwkSxOraNHT+QFwV7wd3m0gl0 fUCVH/OQV6x7GZFRd9u5HXuh2NCFdndvY8bSURtdmbQDZQA6QooR7DLeq9N5Zdk8Mz94PnlpEr5Z cNQekImv2gMfV6YQS4V0ArX7wUYlupbBfqSGDVPPm27bHgNmArtgEpahiKmB5Fp7jLPHcGd64JmU aunIRuaZBtnMHogXKBojn8lKnzur0iUgvHEC0rhLLv/orPSp057Bp26aQTZM0DH5AXp3nEJtYIMM 8KwdnufO1ykPYa2SKo+KQ6nVQm/KUlt6s9g/tmihbvOqSoMPL+iKtKa0s6X4trwGBwKSpNK4pPyJ O1DyD0kTUnEyn2rwpbMVWQbafCyhqKrLQpIyoTzOSkzmaIuBzNNJ2neYTxJkzON5ln+Yt/qvzl+s GAwfSl55KBnMtBK4l2sLX91zvUiD7l6eiLt/buR1P3UNAgYZQsdU784BTUpDoXEAjK06QSMrHNoX 0DhMXkbDz19B49r8dTTS9IibcCyhC0pSG0vqY8dFvq/7Rt5qXI4i2PI7cNAG/Un+GoesuBg1bjqh +n4FAz93GQI3fQWBK9PXAUCaKpkrou0rc+v3r/1cM6Hp1x0X7XsEAYoQNR7IFvSg/GEkqQ49kEiv IAGDoOxbYMTZyf3IT+E4zDo88lNA/ALvcn4KydUFV0FBr3Qg89KMUFS42qc+SycWcne2mzmz1fLo +HfglpBgybKcScgZKnH6nXtiispDcmGqMKe7LFpul4XqMJtTu0Oz2vB5nGy2SNrNDqXj2UI2G4PM f7bZonxl84XZk91XiK3JqWWg+/hAPNmRZde9fKMiGXRNppSdXJTy1BelSo7vw1O93dUhlzqpS4aO NEcR7aiWVsH0x/T9WgRduDt56nNp7DVpq+njMKq2blj0Rk2o3e1S1RPKHlFHdBUlsRpKJe34NiwP BTAVpRUrrFiZrgo0dQfHoNyq07G9tZKlExDNgqmZDjhb34Umlpqb4YJC+cG56rpzusBNiM+P4M9o J8u/nJwCZOdompiJBWf9JYhJkiXHLC33LM3WmzvuHPKg7iwTy4NuC2L2Vn0aZDhNnl3moF3MFJYy ArskGjGPOxk3lhyB67w537+iX7uOOVPhWO4VwBG62jdXHu04L+3hdtyl9LXwi76R+2+HW54k7D1H Q1zxklYGs4x+6CxSMDXzc08i9s2iSQ8nkRDxlZOg16OToOE0Ear+PBLuoww5sbMLwuw7oOLKVMbH sPEhXLrCI2QU/PqBKlDmO0kBMxYwM+j84UCOOTn8VPDMoTe0HP4d9VDEoVfdUt64/eIcUxOKMnir 3ndTs7WLqY+l59ieO0LhaZuHkpyA4p9ivctOjfiRp77eh5Q52hAZLViPHY/k2x6/VfCW34lWB+9r mahx9Cj44AHgj8GwlE0reTR2kYwGXMd/+PqYBNPYolVhZehXrLiZGpLDDjWw4hW1XeBagzVqTbcH mU0W9zJ6wyUZmLNJjzveaQ06M8SX4v8KMAB01LjWCg0KZW5kc3RyZWFtDWVuZG9iag0xMyAwIG9i ajw8L0Nyb3BCb3hbMCAwIDYxMiA3OTJdL1BhcmVudCAzMCAwIFIvQ29udGVudHMgMTUgMCBSL1Jv dGF0ZSAwL01lZGlhQm94WzAgMCA2MTIgNzkyXS9SZXNvdXJjZXMgMTQgMCBSL1R5cGUvUGFnZT4+ DWVuZG9iag0xNCAwIG9iajw8L0ZvbnQ8PC9UVDIgNDAgMCBSL1RUNCA0MSAwIFIvVFQ4IDIyIDAg Ui9UVDkgMjAgMCBSPj4vUHJvY1NldFsvUERGL1RleHRdL0V4dEdTdGF0ZTw8L0dTMSAzOCAwIFI+ Pj4+DWVuZG9iag0xNSAwIG9iajw8L0xlbmd0aCAzNzc1L0ZpbHRlci9GbGF0ZURlY29kZT4+c3Ry ZWFtDQpIiaxXyY7jyBG991fkkTRaHO7LwDDQ7h4b49OgLcCHgQ8UlSpxzCY1JFVl+ev9YskUq6o3 wEahxFwiMyJjeRHxw1//npiH5c2f929+2O9rk5j96U0SR3FqYvzJqIlNlWdRVZr9pzexecD/vqOf pzeBCfe/0dFUju6KKKub1OzKOmriPDX7D3eaXGgavroxWZxFpSnyKKnjhK4OSiVsPi9HkuemwpCJ /xjHVf0noVe54ygvkwTkW6YqWBJlWZHJ3g63xUnOj8AobeglvwbvHsNdHuVB2w/tQYb90K+3H80H O+o8TIJ2MNPJLHZW8r6zb83+LBN7Cv+5/9ubBOOm2nIrHLdMmK0mLIOJDhXBKUyjNPBXFmBTRk1A 9/4y925tsA8ysiGurAO64Bm93jaEMSbt2ut8lI9hwV5bgZRa1nVUk1JJ1jR1siaJCvvRXsJdEVzD JKqCla4ezbswaTBbwl0ZZcFi18Vz+Ir5ygqiqx85H/qfLdl43eYi73t+ehOMp/4oIzFgE6x9SyaV yY/m/VVGy6onPoUNaXg2F5nP9ElZwYVoG6rtbi+fuoNimjI3+Nb0TIj2f3xf5j21lvf9zK/JglVc IiMxEUsBO+vPn0KKkeAiW+wtZTAvkx5i88nQP+Me+E3tLIYRWyzDZalzjqRMnTBxJcJ8sEs3h4h7 aIn0EBxCCRWejA88Mys+dXC25p3Qdud+tbzVhbsUyhUC2CMJZusFS7/iSgmO5U4wKMcJlmwF68Ma 9jtYs54tG9G0M/Pu1iv4yPZI6qMIhGgVZEghyenUd70dOU6PdgUoiFBJFVVZWYh9mF1JjEWGRIM7 zCkaE3o4jl/sDJuQfnLeMvaxHfC9tjSjVcQTwcGJVUO6Cs5yfLYQkGyGpcW0I5QEcUzHq9O4wtTB PNFlC4KzCCIRcuekJBvkdeFl9aIWhYi6h0mOdunDDNxgK9IFNIGoDtqwIgNi7UhC0xIoO16d5cBl 5Y9MJjoNbISMFT2C1s50m5XrZjnKS3JCaGAK/l5nPmnfip7rqEAquet5Y2CFJdh0tu1KejmS/jqB QWilJo+fBuzw0kwulgRi7pKfCAvbBZtJ0LWX9jDcTD+uVqh3qkOVADpMCM2/nDlmO7SrPUoKMEs/ duxv7GqaJNjhZMzBWpFWoFBNGxSkgFZ2lDjoNd3YBdfokB1JxpN8YPzAJSbCNU9LSgkBzebJce/O xt1paMtJMppvCLDlT0qJRRtZdYc4zW6kh050n4vuIfBoO7tQVAE1Q2Iw3yAUidMi+IQWDIBSYEv+ vtjhEa9uTTc5L4ir5KtewCehm2nUaEV2lmBvONh5cBaTu7iPxEf3IeUu3bOznDmJs0wqYOn3jXcL FumVW7yCaWf+zPGFjY4MSorNWyQug6d+GNRMUMijOym1SIa8DobBzXuNh3a68OBWWGlNlDbIhV8p PwwlOjIKlxJaItwYQowd7CerS6tzooKcSCsJst1ltosngqI2BYj31AKuTpWNrj8rVo4vahlRrQq+ US3rM/G5VH0MWaAQ3MN3CVOHe7EAXlrcX175l6cueZJz7cgBSAmVyFoFg/23DMxyWwAFO7e/mH41 /WKWZ6eYYEWWI8j2Swmoj0Ims34W+1Vcl1HUr3qNN2QFldDW43biLykCjUE66zyq2nrUlp3zrcr7 Fhj1OiArVYFjL7MnmsHbn4X31qs5u/0qSirFYQCR6/IWQRpycNA6CV0HDzozg7hvKfZtApTMbmF+ 3J6wT5TUdpLVWq8Sf5DyrtUlycT+iaV/omxNMqRiOgkYfhels12PZG56slLtXjIIfypfpeyrFUxL qXBlqCsRQXbCbNAMkFBa7e7/IFh0r4o0wJYrZbtG8jgcvF2M5YXfQyoor5QAKUxo8gmWgJTjymuc LAFqKas7oTL2emqRIxssALv4lpmuhb3fcsVilHw62kHuGIWLMNfdg8zsrIVEGnDWhFvTmNJ2E4gI TxTh1F7YmVcXhh4RWahHhncRXIS88bqRC/TVdjQHkfcz2WO3CW0Kz9LFN4VUgtpdc9coc/KCgi3L oD252Vm30T4BGhwRJuQdz2GhLl64NfNNPCwIAKCOsK8cTP1+QJ3QqWs89yZ31oHH3asWjT/sPblo QQKE4Jrg0qbJv9rOsC0enjUkyPB2EdwtJAYBv7o3XZX2rE0PUjDhlzvKhfbvsqX9j/Q3ngDaIucA 7Ek/hNdXWLmZg14oFPeEyE94aduk9g/RoOBAruX4BhtrDsbSY6P0totYoSbuRD7jyVC/IAtWB3a+ q6Nh73X1Sh1oYXjRO4a+87w2bFa+Q49Yj2c1o1OpeFZ7PPOiDx6J601pV4sGyRnb8ehY3G//AsK+ snenzeiMHKt96DRqI9uPalwSdlXLu8fKTD/+yc39yU3w3GWsgGLhz4SxJOWKYYl2rDqRB8Um0BUG xfy7msg8y2jomsjCJ+VYk/JP6IiuasSee8aGyjMWlHO91U2apsHyPQ1inpTR1/rDv0yzsW0n+jDL SiW8mfvlXwjxcZHO8CidoZ25Fky5WKW54aoTg+7cjv0ioYyYT1gK120Vm7qFQZigVGqkwy10tRIK YoBmE3TCgSFUE0dBnV+m1p6FDPLpXS1XV3oRWlxSEl0xMJ1Q/8cefU+o8r3Ewm9phupBfS2ha0H2 JyWshirt52qRertwC71sS9FtZGsKqZqGgo9WUSeLCknYrnqtsrjYIGLsG65EGy5qKdhppX/k9A5W YEuJTsJB+gwIz/niU0iujGXuDtqVyW9MfrH38pM5vyg/BcdYklKB7Nw+WryskGR9sDIZFRZPLN0k syvD7ci/RyV4vA5UwiKN2rnlo4eB06fl+1YeT3zky4Xtq3bjoz2hh9H+AR3oos3HdNUG4njvNXy/ wB0EOVQM3Gpl+ry9AHQoiGHJDIA7IDHM+VbNVUV5XKXbBPYK918A+dp31y3utzNwHVinqHyd0TRy BlAqh7RURGH5/U8f92/NRwSqLC/OfCrJS4B96d/Bh/4ByRMF2dpBvfvfvgFeWVZEderBy1cOsXa9 v8zThYwFgQW6oLOWP+MR1aLsdDM7RS9RfQilBObJyJMH7YTeTzJfFficL9Hm8F24l1FCvgOfr7DS wlc6bO+cS+YAZUTXLtA4Gxkm5vTDIA8hoFM0WjQeOJ3OYvQ0glayrdFf9VmTNiJz31Jenow0SdLe rNI3afv0IJRE10IMil8Gxn4YzGHT3hjxiCp40BMwIzBbSah9zbbdkrtJvENFfuUdPo4SjiNg1mKH U2TYM17HnXemTNX5D6pAOU3i95F/Zzyjm3hlDWPVYIGqAVXYRcaXMOEaFlBGMM3VbaCNZsh9B+5B HCztfKPkrchYlHWzRUbvjKmWsXT4ejmyymE8gcTcI3MiyFxu+kffVTH5hWpestZsTwNI7tDIrLfQ 6PWmiiAE78duuDKwVwrpKKenkdIAaQF1E2+NYYb6krk4fyqbvNy+LPWgmyuK7CyKBM4nV8ku9EjG S/ChvA0H7bppPkrq1iz1MNyi7ylR0gKNQ03R8uU4t4vV4ESgm3d4CiVbDuJV4nwe22309o+ybN5J HHdnZMRC8iEvKDpE3xPXaVZFZXyX8DNAi9Du7Iz+dFTE7LnA1RlKHB0RwGp1X/6X8mpZbhuGgfd+ hY5yD55Ylh859tBDz8kPMLYcqXVNjx7OOF9fLBakHo4900NikQRBAgQWiwDLxu4jx03+i63/7sIZ 1eE6IL1TJXqf91O/MYC7HxJv3G90ubGaJNrXHyQdXyDhVXtNzkcXD/mad/fAuLDW8+2aHKpa8PAM RFcGuEzloZ2Qw9rpzT+UCS1Td9IOwLJIaqELjl6ijh5Dvj7li2G+ZpHJLI3JXD/Z4OYAQfyAoKcl vzV9zp6DtjDBtpKsbU3EqD8b3zyN80FYNWiB0qFWKFsIia13nDZvt5zLKedN/V7YloCuU1olDU8m +bzTQUk+FpwiwbelR3LBgPrsY+3YbtePCYNrrc+R59tZZNhzsmUTKJGk+XEUMmLzsiX0aOwMh1H4 Mg4O+GREQEKoTBJiEryCkZMUiaVFLZryxnWEsCdDZ2F2JPZaZztCRl0w0LAoPls8kUiiMsuMxJLU XnwIkC9VQyV/AtKOWLTnE89QSKXmYso3VLmnnmSnIzvYWVhTpBkTzEFb8CW63FCyBwDTu78t6Fhz OlpJBmF8WqXFEU/Ck3OX+TzkvCZFr7suLkPkaBCadbgeQ9FeHj8LVMLT/nFoWWiQg4qCKog1IywZ ZEvWswJroRrNw0zJ90rLxJrtJAbGwFdsqVA+gDCeqSmywobZJtpqU4HnzJOXbmdq8fhRlednPYOs 6XDaFZoQXJOln04tWbE2hs17myLlPtmoNZ4in5egY2BAuLXsOPCmfvYUfCzzDijGvlCdYPO+s9uV vYH4fxles/jA0pqWmfYvMLwnnZEvWIaR5Cy0XUE+bJRE50yOjSVHzuRYMjmQTy17IEEWVdGIN9fp XM1IfqmCk+1Avrna5CuV3inL6rjV1Um4hp4uEE2VSmrLsAPHlgBVLRmq4KobkjdgJ4TsRG43K/Yq 0+3GViCibPfEBQ/to2Nfv0cixyheB2eCm5Z8bMlhAbpnyYijTl9sGpVaFxygfqs2MDTEDFlJ/aVQ QlZzn58xXvD/j+nQ9T0H9zveWJIyK0mvmua5IYwA55nj1lnOso3RumjjRHqKjp8o6qTJYuJCGQ2b WxYSqLXdDmwOTYv4XSXrwvIOqwfYvUkNLTrSD1s7VjsrIzmSBlouo9FRdPrz38JOapOmtK12SwiY gsRh0ARLZgaNUdc9prOI6JQZOgmTVUjB9kw8TkdmSJiOXzUtyCROLI6CwZkYnDHJ4cEP7SUzq6GS K2dToELeRmNlsAOiApLGk7Ll82rICG6e+r5Tbt2Ad7r73OFl2uhy0KnAHnMSBHaOTc+R9H5T9Imd YwAfVJYc2XjSHw9rN5pFeiv8eApIiyTlUlJTztP5NwTi83zDbNvQ39KXcfVdd524hJWS840pra8q MIcDMouDn6/f/gkwAEgLh1UKDQplbmRzdHJlYW0NZW5kb2JqDTE2IDAgb2JqPDwvQ3JvcEJveFsw IDAgNjEyIDc5Ml0vUGFyZW50IDMwIDAgUi9Db250ZW50cyAxOCAwIFIvUm90YXRlIDAvTWVkaWFC b3hbMCAwIDYxMiA3OTJdL1Jlc291cmNlcyAxNyAwIFIvVHlwZS9QYWdlPj4NZW5kb2JqDTE3IDAg b2JqPDwvRm9udDw8L1RUMiA0MCAwIFIvVFQ0IDQxIDAgUi9UVDggMjIgMCBSL1RUMTEgMjYgMCBS Pj4vUHJvY1NldFsvUERGL1RleHRdL0V4dEdTdGF0ZTw8L0dTMSAzOCAwIFI+Pj4+DWVuZG9iag0x OCAwIG9iajw8L0xlbmd0aCAzMTMwL0ZpbHRlci9GbGF0ZURlY29kZT4+c3RyZWFtDQpIiYRXyZLb yBG991fUEYgYcrAvR81I4ZDtcEyMeLI0BxAASVggQGPpHs7X++VSIMhWt0OhZlUhK7fK5eXPf/vi m+P49Mvu6efdLjO+2R2efG/rBcbDP1nlnkmjcJsmZnd+8swR/3cl/Xl5coy7+w9djeSqZzZJts39 JDC7j/o1Z1a5Cb1wm5g42vqZ5xMrJ9XLN7l5ZuVi5UeRSX1/od9AGz/OWPjW87yQNPjqfOiK9upm 28z5y90EW99puqP53U22uVO7uJM4Y1PNbgSCojW7E6+GWg6m0bh/7P5OWgQ/tp60SHJSXVXw/MSq EPqiAphuIgiqjZs4l1k2w0V++5GPe9kdXFLRFGasS0vYTFdz0e9tU15NM5pJ96bURSc/k+uR+pYa ZmaOGZrxu2mUwhR2UZd9p4RnNwdhw5dLcyhG1bix3Lek4+eJRA/FULdXNkUtkJ8RLgvhzL2VTcxq 8R8eHg8V5Sm9O3uJ3ky8RP4iL029qdvm7OJJQzxSMdWieA0j2L4QnpkaEr41HzphDOI0jmI8Bxgz t3AJgED4FggAF/HpXEVB198GMJVOZG16/nBwN/A8Xj6DEfy5mvWmmeCf1IFTIA7BUUxyXZxAlwc3 dvrnhsmqejQFuJh9MVo5Kck5EJHywFLldvz32Mvl7shb0eOZ18KjfhGLN9bkR4/6gbU8SMVyfpiA YwrSppNsa44tiSo5UTqKrZ9M0bb9C3JEzsjCwyzria3QzcBRaznJW2TbKFs9xeqJI1HIyPPGzmXo n2td191E8Uzs9pIhQ4N8ZVcFyFLwb/6qK7iUgvkih2AAMsQIBYP6RcSTe6MgvgXaEhB+ZtOxZmaR BFWIvL+OCOz+AK9TMUAdmE78yhkl43jq55aXlRknisuyFYNT1KFADGZZwSIrVFl1MSBXyPUxBEHu OM6UbD4ZQkcT/eScej5ZHHNE8M9Ipkb8BLNS9/qJzl6UaVPqwjScn+RHOSgo1uiRKiUo9HplXSYG rCKJ/RQvBRxZieDLJfLxVFRuIiw6/lvJacMkQijrvqOIV9WVFvFMYSOaC1nJRydjZUQsYqyflXbN +Mpf8UZuTGF5f+VOSU3PHA/HSggRPWGOw+oWZ0O9EUHPnOY5hTYx0OvyreLb21UZSynKlqRbXjzI 1sWe37qT1WN42VMbZCkFGdX060U+NShLvlMiEzl0NNRSL0lWsaavtF0aHef1JBUbL0TyptOSpXK6 6iWx9JKXk2w4itjF0OTMrlKycbpFC+vA4RIu4eJFS4JpvzugeJFR/53lt5tgCLwNaytuJMhAsboY Sl6cKNTRbiZYMA9icSievlnsLRYH1mJqnAfqlteR/MgtPUaVQGnxKALcTWLXBTIscK4Gb48k3re1 QQlCFUCckfCMmi4HRVtMzTN1uPrPqe4qoamoUsA56gnV7f+XYK2wjDTI/VxCtd5WeObM4XdqWEnQ bd1NRg1ntxRrVehWu58fWOJFwYJV5+Jla3GcZPnae7dnykU3G4D03r7PDgrhoPJUdEdx7XM9mPNc npBJMWSdyAmR0w9TzXl8qYemr+TbrQiz3IeS4i2YyFPh1moyxOfaNJqOelyC/JuK8rtZfZxOJCYh MdAOPkSNPNb8KzHOJgPSeVHwrsloG/ti37TqtAu1ATRvFHokwNwWw+ISsWoWi8uyris0JWkYkXM0 clG3SzlVDVYJ8gYitKjtfK6HskEpGGfIGEfzzaKpASisaeeh/uaaUtFYIV05kbfPgT8m7olrePms pELRzqtPXBDsfu4qXaJBNZYx9ad6Gt8ud0tLDxS1CSacx1pQgg/c58uzyLYe6kMPsIAGLwgUhU27 J/BhiI7pveMnVZ8yJYLSC4a92UHo7nV5TW7ldVwR1+PUUIEInDPaOO7cge69bqeTfU/V8DHNg8UL YbKkeQwWg0v9tt/LrtBfDTfZHJiEw7yTk0rhga/zgRKi9uiC87LhgOOOHiFzKxUhe6rXy8ejMpOd EpqymGXFqAKJZT9YuOCjxXLNRDVVUg7Jg25aVsBIcurdqb8Xthgibb6x+7WFq3FglSJeugSWFneC AVzc6NG4PKZkIY04BKAJiujpZZ7q6ieDMNNCEKwC68dAtP6zsEgUjQAlRAalQ8/gl9EnpkQGexov C1a1PUWQDyHr42my4PRSy2IQJxtlJZhVpjr+Prs0zLB5GmrBq1CzWVbeUo9DrW9dkhwDPhF4vaJQ IaDQpygG0LiolveU/hHCMuZqETLmozudUPv8k/NfpLedcSGDh1w0llCKeOZl0e2RctIG6c0akjL/ LKgC5gBULVoW0k227KQgpI75O41wOE0ieqrfaDLlC4BVkWNvC07lPJET4yI6QP9RKc7FURZc+Wgs 8eMY379QN+TzYXWXrPm0e2IWiYkD3ABywnTAf6gtDPXT4eF7mOGNHijiIKFPNw5p/khimXgBKqUI AU6KA/2aRczg9pWCcUUQ5ME9AUtYEcBx7xNEQfq+iChNHjR8ILBWvinilx0FRyCxgZTzqMl6RlYI 121kohwbIOCzVsglnSNN56/II+ffAvOAkyirUucPRIaPucz5h5SHrn/RhbkIRUvvjdLWdLKfZF// qdtVPUr15aOtF/n5HUpdkiiKRZviCI4Atr99/hfnM+V/iuQInXK4XgCiu7tCtUrIaOGVKKb45sTI o8hJzL5BVGfQkf4y34+fuAB8QRO3PS9NkVF49DyMFqbBwtTTxIJiLgFZUxFPQHg0TVxOJLMzVHGa R2fZDDSqMNr1vYCQe8t3lBSYahPFIVWgMyATGUtrZYxpFGg24ctRIIX+/vJDNnnBq2zx71IhSvxt IJ8Mkh5UP/iKD/HDbUmV1W36tGYAAsSnEvgex+cdC02mGwsO5BULIrixSP1XHDTb3uZABDcOSfCK g6bj22YQwY0Dksd75CD5+g6HFCLe46AJ/bYVPya444Gcf53pEApx/pLmq8aqQOgDzxIMRihau+II LDBQegGaNvULkKadSgmtIW7RmWaANTqgVsF4jsN5lFIPaGcnmjy7Q/fLsOVr0hQHGkwA5nGNZxUe mFwqDbNLI54CmtZcWuS/EGLK0yIychePnaNclQ21+MChWrEMOKTGq8kvXPBLJsp8/PSFQRCDylCQ bIjkonG3ko1pgP913QDVAM9NNHh+l6NOfnrGOy8KY+HZyUzMRfeCGmU9QFsMaHuCnszVQk/aHMiu RKtkgOD3Y3EnPEc8xlkmywX20YbgfHCDfXRkRh1Oe0tTmb0dSnkWxNMCOvGsK/YFPN+JB1Xyuj7f OdDTjnHmmoxiRaWKwACVqoDKPIDeqQHcSfFUZNiJ8APOC5nQaF3xBziKLur3QnY4zG+HFCCsJ+QQ 4GQSIbwKD1grz6DP6HNbClmIyCUIjeGEz1R+6TIIBOItRlTnhbSgD2U/AIrpkb1G3I/tSvDWQh0F Z9nSfylXJSupT1NWeoBaiU1LP741KU9R468nGh5jzohfYXAoBT5gQBjwjAE82vOmXUS+2fIjNIB4 mwck8ja5fXV2ktoYB3ngdGW62nhsOo+nNaf8gNSP9HtnSj7rkZC+ByXQgBx+lZg9gcBER3VqalSE qCNUBl+ijEaAlLoano9rBGphEuerIhEsYRVqXjKQCGUuCmVwwYC5JeU+y/zXuaJvd8XUBEtOhEoi ipVnvTSsxlA+MF/qcpa1fmNon/yP7irabRCGgb+Sx02aELAV0b/YL6RJKpAQTIRpv78726G03Z5a B+digu07v3wuujqNYZf6FuRjAey9tLYhJS4Bl9Bb3svw8UpJrRnZsPw+hK+5KNkEDRAWWTRXP8rP LPOmUzjdjHRIYj7sWEW8LIo22XnqGdRDIaGQvIXDejppPUGIO3We1YyCjUlKwzkikAnud3p9XTXV 1Z5piCwo5Gc29sBn/zo+tiPzKKgXDT79I+TqPTEa6zecHzkJ4tOHAaFQDrImcVDHOhRi4wyK/o1q n13yYWAocaU30hx19FYgIlq5bSz0xZMO9PV+U6UWAYmRYB16+FWl8pbdT1qTiMn8fZEYGiSXYPZV f27vMJ/4eEvR8cUOFCztatmG0o676swInhhtp9fW6HWctZWDZO2fn8BWfi4tHsAU5n/6qBHpsxl9 JFdc2CFOqOOmlk4sVlbaanETrWQZLmdlBXJtFFZKuJpc7Qr1V4ABACyOQXkKDQplbmRzdHJlYW0N ZW5kb2JqDTE5IDAgb2JqPDwvU3RlbVYgODgvRm9udE5hbWUvQXJpYWxNVC9Gb250U3RyZXRjaC9O b3JtYWwvRm9udFdlaWdodCA0MDAvRmxhZ3MgMzIvRGVzY2VudCAtMjExL0ZvbnRCQm94Wy02NjUg LTMyNSAyMDAwIDEwMDZdL0FzY2VudCA5MDUvRm9udEZhbWlseShBcmlhbCkvQ2FwSGVpZ2h0IDcx OC9YSGVpZ2h0IDUxNS9UeXBlL0ZvbnREZXNjcmlwdG9yL0l0YWxpY0FuZ2xlIDA+Pg1lbmRvYmoN MjAgMCBvYmo8PC9TdWJ0eXBlL1R5cGUwL0Rlc2NlbmRhbnRGb250c1syMSAwIFJdL0Jhc2VGb250 L0lLSVBQSStTeW1ib2xNVC9Ub1VuaWNvZGUgMjQgMCBSL0VuY29kaW5nL0lkZW50aXR5LUgvVHlw ZS9Gb250Pj4NZW5kb2JqDTIxIDAgb2JqPDwvU3VidHlwZS9DSURGb250VHlwZTIvRm9udERlc2Ny aXB0b3IgMjMgMCBSL0Jhc2VGb250L0lLSVBQSStTeW1ib2xNVC9XWzEyMFs0NTldXS9DSURTeXN0 ZW1JbmZvPDwvU3VwcGxlbWVudCAwL09yZGVyaW5nKElkZW50aXR5KS9SZWdpc3RyeShBZG9iZSk+ Pi9EVyAxMDAwL1R5cGUvRm9udD4+DWVuZG9iag0yMiAwIG9iajw8L1N1YnR5cGUvVHJ1ZVR5cGUv Rm9udERlc2NyaXB0b3IgMTkgMCBSL0xhc3RDaGFyIDEyMi9XaWR0aHNbMjc4IDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMjc4IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDY2 NyAwIDcyMiA3MjIgNjY3IDAgMCAwIDI3OCAwIDAgNTU2IDAgMCA3NzggNjY3IDAgNzIyIDY2NyA2 MTEgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNTU2IDU1NiA1MDAgNTU2IDU1NiAyNzggNTU2IDU1 NiAyMjIgMjIyIDUwMCAyMjIgODMzIDU1NiA1NTYgNTU2IDAgMzMzIDUwMCAyNzggNTU2IDUwMCAw IDAgNTAwIDUwMF0vQmFzZUZvbnQvQXJpYWxNVC9GaXJzdENoYXIgMzIvRW5jb2RpbmcvV2luQW5z aUVuY29kaW5nL1R5cGUvRm9udD4+DWVuZG9iag0yMyAwIG9iajw8L1N0ZW1WIDAvRm9udE5hbWUv SUtJUFBJK1N5bWJvbE1UL0ZvbnRTdHJldGNoL05vcm1hbC9Gb250RmlsZTIgMjUgMCBSL0ZvbnRX ZWlnaHQgNDAwL0ZsYWdzIDQvRGVzY2VudCAtMjE5L0ZvbnRCQm94WzAgLTIyMCAxMTEzIDEwMDVd L0FzY2VudCAxMDA1L0ZvbnRGYW1pbHkoU3ltYm9sKS9DYXBIZWlnaHQgMC9UeXBlL0ZvbnREZXNj cmlwdG9yL0l0YWxpY0FuZ2xlIDA+Pg1lbmRvYmoNMjQgMCBvYmo8PC9MZW5ndGggMjE3L0ZpbHRl ci9GbGF0ZURlY29kZT4+c3RyZWFtDQpIiVRQPU/FMAzc8ys8ghiSFyEBUtXlsXTgQ7Sw5yVuiUSd yE2H/nuSqH2IwbZ89unOlufuuSOfQL5zsD0mGD05xiWsbBEuOHmCkwbnbdq7mu1sIshM7rcl4dzR GKBphPzIwyXxBjfD8HSnbkG+sUP2NGXkXn9+ZaRfY/zBGSmBgrYFh6OQ5xcTX82MICvxDxy2iKBr f9q1g8MlGotsaEJolHp4bI+C5P7PD9ZltN+GxbGtldatyNs7XnjlpqsPuzJni/XwaqRY8ITX38QQ i1oJ8SvAAO2MapgKDQplbmRzdHJlYW0NZW5kb2JqDTI1IDAgb2JqPDwvTGVuZ3RoIDY5ODgvRmls dGVyL0ZsYXRlRGVjb2RlL0xlbmd0aDEgMTEwNDA+PnN0cmVhbQ0KSIncVwtUE2cWnjyBRF5NUNel +gNFBZIwAUF5WUMIOC4kmISI1romYSDRvJgZQIoKiYqg1VJFfFJRW1ERX8XH9mxdPLo+qFB8VXR9 raxbrY9qfQvo/gNV0Nbdc/ac3bNnZ85/Zu79v3v/7//vvbkThIEgSD+kBGEhY5I0WMrFwuaJUHMc QYRClSY8Yu796wR8vwJ1OmM+BUIPdcxDEL9RCMJhZztyrA/RQ7kIMigeyt45lsLsLfPqDyBIMI3f ZcL1WX+un4wjSOh1KEeboMJbzHIiyJBUKL9nslIzCtKx0VB2IAiz02I36gfGD4S+hlYiCMNl1c9w MFmcWmh/FOKBTW/FB2wzQX/DB0L8NgeBO2Z7H4ByoAVBWJAHwui+6Sci6IJPIdJ9CR6iLsE9rkdo 6djSx54MN2aNS3AVqi4xGQypF9qP694zw+RwEHQqlxfGZbAZrpFMBrtGjaajoj4a//WDS/yR+O5b hRgQErEjFgRHKDhG0zcKXvfH9llSN/9aM69zafy5lLrn8bJDNS7v91EXsxGOEKZQUN5wYsH12kNf Rx1ZvaisaUiTRvcp6vmKK4MNKTk/kw5B3+WyMtg8QX8dTpg15hwb0BJ5JAWUOFVgJ6ZLB6B+NIAv 8HoJEAHMZpRIRWhoz0RQr6XZigMNpbc6zLYcoMGJfLMRB2q7nZKOQCN60GFKFUjFZIlYKqadCGRy uSJdq0gSgeHGkJiR4PU10MEDPGNGolHSCHQkCq9JUIyRRkRKfxb/9zfgXNv3zBkchOVcBM+9nOl0 Iqck4K5ppkgscfrv5O6q5e/19ZxwXtOW134sMnTX6UceH4y4f6PiuUe/1r/8dtIfmr9/VLazunF+ 8M1ZmT7ktBnf5Pp1Hc58FFKXOaWK3SU2+GY6/ZtyK88EZoafOS7kzI3+qnJLQ9q4G3fiAut1K2cH rLGUNo5LWT6tYWP0mU4P8amGmNVMFkzqN1KCBXnF+q6Zxxl98kZJR9GZzQ+2FnZyOpcl5AZtDht+ +WMBXv5cNJ/xyaRVhibf2pIHe/cL957QrZzublAcXv/F+ahiTuAlQswu5dTO9Oi/VCi/+7h/2ndu i1f7WDKf86KWN5Wvvcx2rAmdpV984Do/d9WmI9mGxIRllYERKwLLFzzLcn/v4clnMH+b4Yhm+iFf +646L78d0JGcObe8KbmsIviOcOr/XxJvlQ5Dg3scD/7nNF7ulP/Wnf5bFF+eD+8X5+OLetMTbgJ3 zEbhhA2nUGf1L1J6IYzCfDql6/S3G+oXVaRUXGjwnWK+wCs2VHClzS0vyj5NPovFVt44zX2/un79 jEm3nnYaFap9fBv64/roOrHH5Xv2YXWe46dyolTFLVpV615RYhu/ddG+KS/2lLS2VzUUB2KJPpZT K3YwdBsOfitZG/ugeFPmxrOB+LWP62as+eO5lETTB+JZXbuZDNavJLR1asfK339u/vJUkSPMEDQ4 CYzfHuR3hGI+xX4aNmjy1tLcKPewR59curK76vrC2t+1k0fHelTvOL/wvN+SJtY1j2Ad93vl5ylf nJiQfHqU7mFA88GhceLgiJbVV/80JuWHNmtK/rVGdIN3SUtxW9zsmqfLQqVhfs+OCm9f3HEjQ+ZI Fotmoy6PjXB417CYDCbTpzC7yjZnR+sexju26sYGPLcvYyZMaP2vnPrbIxSJSnsCHvoqI+R2qxUn jGa9BWjs2VSBnsBBep7BYiZNOEECuaw7JUehI6TRKPoqJWkxIjIqJipmEupifPgfJyFNRpN6jBIK Cgok+dCQhIYSo90aDjuwnTRTdqIwXJ6uodewEw4JMBQCNZ4tEdF5LUnVJtG5HC0djcb3+IlKMueY KbgglgTkFj1JgkggBmlmI2EnIYVeHjq9xZylp8x2G8iPkPJRD9qeK2BmaKQC1JcW3AW8CXrSBEuP stukPqhXz1G4qfEsq92WJR2M+tMaltCv170ccrQT3W5fzvPfMg8PGLxZRS6GJwL17kwXg4E0VJwc uinr7zf9Dr6wFslUvKf20NwWyUDNxojoK6dNf43qwt5pq+rEv9UIwX72sY8eHnNYK28d/3J7KLoq InPmns3Tg3NWNl4t+IFz7cf2qsf1/N9s3BY/13H1iX2yapbdW61Y4HcWvxAHOO0J6yzLY734wYLb Ad+AxTEfGeZwjgUN6lRXb61OrTobr8xMcBXd8YjS7TY1JirWx0k3dLQt68g4Itq04WCIquXB0rus IUX3/GI3P9mSPodjNdxdKCgbda7d34s8wB3z1fCDN5uX5B7Zn71rnTbwO37OzCfzC8u3ZvO2jH/W RQR0ln54+ME4r1uZ+qC01p2xWVcEn005Os+a2n97ghss5A0uzkXUxTnXHZ13BWwmiqB8+tWbzWYx OTWos4yWGGxnCTq7xKeo6m8n5F2mFfdHHbfF/cR3rTP+FwrJxWE2wK9CNIBmwmYwXrAHoEKU/vLr /bLrz2K6lSAw2hDCY3NRSJ47BnWxo/tgeLSpix0E1UNqQkqGmSjKQcaGh/+LwljnYu1zulgNWpOZ BEacoMzZZqOewoG5u2DoZMNJumoIPBsncJsRFwG9LQuYKRLkkRBGApIizEbKUsgj8wzTcCMFKLsI UCYc9B7CK790vaQTeiNFN0TYmijcitsoMBwyCeFBmiQNkEpQuEi+3mzRGyw0k9e99W4A6KlY3ts2 GkezVoit0A3EAbiCmMBz83CSIse8jrMTPAh9CXw9piIQERUTCcOohx1Slo9DRZo9z0bpISudGS8Q wRCCmBHoiEhehkYGcY5CwpxjougmKY2JiX7DHQAyiwWoaQQJf4hI2JPxLAmQK9RaGabkTZCp1TKl FlNoQBKmkafKsDRFEpApk/r04VQsDYNtWMKj0UpMmRILtGMVIEOjAKpk+Ipput1hyZhcplUAKGq0 akyuTZ0INBmJ4xRyLdCqaBOeTqHG4B8rZR88plKCdLVMrsXkCmgHHaQplFpIm14C02gy4HpA9g/m qzwsquuKn3vvezM4qCiICxgdRQTU0MEFF5TIMiyyygiKqGVYRYFRtoCAGUa0gMrimiCKuJZgFJKg aKIIqaAVqxVDDVETUcFS9SOJu2FezoCApe339a9+fWfezNz77rn3/H5nuff5L3Lz8UNbJD1GKnoQ SN29fD3d39osX+LrJ1copH2okARvJ09/Z90sfb0StNtL7ufkhs0elD5+Uhf3Rd46dRf87yD1dUAb nfw9Hfykvv5+vj4K+ZSuRRa7e3pKvX0WSRzlXSR5yrsUnHy8FfKF/mi8u4PnFFTxdl/kHvBWp8dY H0TlJ3V28HJwlSuspQq5XKLDqdsvdHM4y3GUpwKZdlJh7seiy1QR/WMxMioey0J4mDRWFasLq4io 8DBFdyI4JGBmhCRiAknCk1G/K7iTlNGJ4dL4lUqMg1hVgjQkXBqqwkdhXZMo46XK0NDEuO4MjFDF xXTljCSpe7vBERipOgvcHawlB23V0/+bNO/pj1ZFqqwjoyJkGSd0lUTKZRyVqWVqkX7wJjey6aWc iAnBDkuRHlYVnscKOnz0f5wfSZKF9I6ksgCZ8fB+9VCGhxViMq+n0yK+i9movp24t6ZIo6OUIdbS 6ATMhX8+XULXJRv+TqUz5fRkIqx2+Ol37tGd1HZ6Hkjxb05Yttm89oi0I7rqi1SX1H3F686sFbkZ G4Y3LLd6udAue23F02GzkpvzjuurbfOXu+2+ALMkiur5M4UcI4sYcJ3+ws3TOu7nusb1nc6q8Xl/ 3VZ8b8fjNgEu1T6JG/1dEYs9WROaOjXZ2W7fxpw3mZtmWlq3HZk10/7Mr79ozGw03HiswWMQuizx f7B//JvD4ECRXjcplOdhf8Yx2ahelgYwm3c3Fg7PGH0tfZt+245sbJ8iZ2PIDeH/ED+1wau86nL7 82Ox9YNOynzfGT7QxlE2f/9I9XBQQArEQAioIBqkEIG/sZBQMkE9XhdNb4MppudQ0xVNCXGJ4Qkp a8J/1+9Iw2kILK03ql/Vtjdb+eOZMY/zyyWVRab2j0ocRrhEhNflXtxwSrPcMS/nUf6VeT8u2Pj5 ulEnfio6xl4HniuKuZdwraXZ6acwy+rkVz6rto845TXoyv2ckK2rPxuyd/xK8Q/DRqVkTwh8bJEZ YjYqOZFys4o95ptU/00eYG/pPVL8XqhF7NJJO/++7HXq3i/jxqSXHn2uGLrnWesWTWN2cc24dQYt 7XeilgRPK/Sg59w+/fhQ1qaHdne0PnuutzXXt0RPunE2+Ku6lTcKLZSWF9MblfcLAq4aRxu6B98n Me7xRp/sDTa6e9iscV1dqrTKaN2RkQIkZTe0Fty9HJjbopl7Ke9olvbymdQH025OtizRkGt4qmvo 84XIRkPOYtdpXZBlVP3fv79SYzg7tLDZ6fG4Ny5LMrP/7JKVb/5kWHC/QA2UjXw3TvV7G2KCYdr7 hLcx0L162MjwXUNmM2Pa9KX/EqbtBfmDbhyQVKzfLrww2mng0T+oMtTy1PUxQTEzHFOTvntwc80r 46EeBYFNDek1QqSPffyztFsRM8Srw+XDBpvCR8Lrs4WlVkVJrZUpwvG56d8v2/n0iTq+eGjpAJP0 zZfGZU7NGFZz9YE0s7l9alZQyt2bgmnpjgJ7TU6Q+bbbB5/JDB1L1o/3yRzg9usZ2z12X3/a6N26 pSxeV9QId4XkAw/AF/LTsGne/cv2QwQ1HMh4nlAiFlFeDP0uL1WsCuZ3SDsEfovWhUzT0ye16t6n /HKw4T1hLN6j2Q4wBRDuvr3vawOFx/xqMNOuEm5ZGODgL9/e3ZcSzGEFWMECqIUOOEcmgS+cF65B KCyhH8L72J8Hp+A83AFnCAMKJiQNpEIRbIGJsAH2w2zORKgET3ioZwDDYQLMISoQgTFEwj5yC9zB A+ewA1fIhjj8Xoj9L8gsfEJAAstx9R2wB87BX+AHGIUzWkMTuv6F8BU4YUUJhVQ4DXd4R34zGEEB HIVSqIEHxJocIu3siVApNAj/QC0rsAFbCMLqEwLboATHHYXL1IwdFEyEVOGPwkUYjdaXIeoauIBr PSdSEkBC6RGWon0txAplyMNAtBmtR3FANN6QAIdxZBO8IQNQNFRKP6Ch2qHCCBDDWKxwk9E+f6x4 6yELtiKKQiiGE/CQfEBWkivkCR1E1bSa9xV7i70HVHd+K7gKz3GNgTAOrV0MqyEZNbfBdtiFmiW4 1p9QOqCT2BI7Yk/ciR/JI5vIYfKSTqbf0zdsMDNgU1ggC2ZprIW90uM7fbS7tdcEXyEZuSTIuQQ9 6YQ4F8EyWAPx8CGkgRqty0XJR/bKUMqRz2qUb+A23ENphYfwCGOOR4wSMglFhmJH5pMFxJ/8nkSS eLKbnCRV5By5QNrJUzqd2tLZ1If60Ui6hibQfFpOK2g1vU9/QSvnMDmLZx+xMlbLLrLrrJkDbgGn 5KK4RG4HV859y3VwTzktD7wZijWv5Pd3HtB6aIOEiYKdECJsFfJRHiLHYxDNRLBAPL7o1VDcUSIR 1RpYi5KC3G1ERLtgH3KnY+8kVMHXGKW16N86uAbNiO82tMALeIXk6PAZk3HkfWKD/M4jrihL0U9J JI2oSS4pRJ4rSCXKeXILUWoRYQANpCtoEk2jW+luuoeepudpE3pCYCL0xEjmyjzYYhbEVrAEtot9 zD5h+1gxq2LnWR1HuTmcLxfHbeDyuQPcCa6ea+Ru8TLejs9BKecr+bN8q8hQZCqaLlKIqsQivRS9 Nj0tfAH1UAGV/XOfZJEhpAI+I22MY2raQJdQfdpENNxVYoEemEuAz8Xd9me08D1ync4ki1koWYr8 aUgECYK9bDQ7wBZAAx9LFMyXhIGC2w2/8t+Aks+hnzPK57BO8oqWwUrIpas7S4VAMhgU5BA9ghGT DnPBijOBJjqbO03MqRWtFh8nVWAvFrHZbI6eAbYOsXtopkLPgLSDkrVg/vxGfrXFNpGd4f/MjGcm zgXHhMSJCR4z2NnEcULCJTc3sWM7sJhkkzhQD7CtHcc0QZREy6VKKZQuStmaJfJqJVj1oq4qtN3N rtrjAJWz2tK8tS/7hJRWpQ9QLu1DKasVS9Utwf3P2AnJFrV9rNSxv/Pfz/+fy8yZuY331iD3Dj4T 7pM/SC9hdYv8z9HnFHSSy09L4T2DxkXJeu4y2b14dvF3/A+yPyaV3B8BFksXfZwfd9ye7Ax3HR7C pad/F27Bde4m7MGnRly/cz7Fe+8b+KTZC0+4YryfwvgcmfB2dXV+ydPR3tbasm3rluamzY0N7npX Xe0LNU7HJnWjXbFtqF5vraq0VJSvK1trLjWtKSkuKjQWyJJoEPCtFeqDak9Uoc4oFZzqzp1uJqsx VMRWKKJUQVXPah+qRHU3ZbWnFz0PfsHTm/P0LnsSk+IBj7teCaoK/TigKhmybyCC/IWAqin0gc73 6rzg1IViFOx2jFCCltGAQklUCdKeE6PJYDSA/aULjX7VnzC66yFtLES2EDlaoU6kSUUn0RmuItie 5kAuxqpolRoI0ko1wEqgvCMYG6H9A5FgwGq3a+56SvxxdZiC2k3XuHQX8OtpqOinkp5GGWPDgfNK un4++XrGBMNRV9GIOhI7EKF8TGM5Sl2YN0ArvnnX8kzEzs3+yLmVViufDFrGFCYmk+cU+vZAZKXV zlpNwz4wlnP0RJM9mPp1nMVQWMFs3JQWoWQKUypsJGxUufEl1CDTRA8ptEDtVkeTh6K4NlVJCoOT 9tmqKu9c9hZUBZXkUES10y6rqsUC69NlkBycvFLpVSpXW9z1aVNpbmLTJWvyTFHxSiaxbNM53Z1x ocHlmSWsIvVF3BFUiStYSUTFMbWyJtEKyXgruuGlEYyiI7giY7TAH02a2pmexVODw6Qqyc8Ad4D6 4C+rNbG8RnSYPgPGsn2yvNfQvsRTl4vW1bEtIvlxTbHGTl3e5q4/keF86oRJQYLTB/04tzGtvRGn 325nC3w+44VhFOiZgUhOVmDYOgveRpdGuSizzC9Z1u1hljNLluXwqIo7+SqeXwDrqOxc/q8xla8N jrZTUv5vzImcPRRWQwP7IkowGc3PbWholZSzty7b8hxd64/wVi7PcVZet+KmPLDszIRIERUc+Bf1 TT2SkWTclbqGKD3UFN2ZazWj3f5fBmWyn7AonTwLy5dJ212r5Y5V8qryipI8Fiw4udDQvmTSuNIG bNLkwqed2O59+v6TBvmYPo0rr+vCx3iqsutzwFc7xAzcNVyFmADgEEZgQJyBHWIb7OTPQjvahhBu tL2BNgf6H8nTN7i2bBb1uxCfIOoRYYSCGEZoiN2IbyEGuDb4AHEeYz0snlH+AkQYb/g1lBn2wkak ZuEeVAl3oEa0wk7hBqioc2L+LYYi6EPeYTgFZVI1i8n+GeXdogN9/oo1HAWn8BG0YmyHYQrKsfYd aGs11EK3eADz3YFy7Oen4p/IIaS7DAHUQfahAPzvse8hrGMS0cM/giDGvii4YAe/C8d3A9zcT8CP NIj2dYgm4Yc4Jhe8gDyrvwV5DekY+vRhrAvtO3A+fVhrP/8p7EfaiP3u538LN8j34TLSBfTfKjyG teRzPa+H4GphzHacKxBFmBNFshnp3xCP5b1QK92DEPb/8hLlt8BBNnd4wo/l53QS4w9iHh//MziU n2OGTSyXDHBfuMG1yZC9gGNXxIu45qfAjXPzFekeeRXnqk/HRYgh7WXA/loRLYiOPNoNV4kRUYj2 MMq7xEGIM0g2aMbYBsw1xPYG2jZjnTry9e/O169TrLMR59W3FC/ugjqMcfFmCK8ALOMRvm88wu8c nZLLGHMc4zu5JvwOOsW9kwP4eXP2Td7MvZyjoCL/HZ1iLLkM633rwMzV4M/JOWGclOPd8VW9fUlv u/S2kbVc42yjzZbhGmbfZqR+troWySZv4e0qW1ON2eapYXKFt+Nwre3WTKXtNuL9mmbba55m21lE I+IEysyvZqbWNl4z/vXx746fE1qgvBxX2VwqezPkzi/2lBWUFbSkMuRX3jYp9UspdUVKfU1KjUip L0upHim1XUo1SCmXlHJIqU1SmWyWTXKJXCQbZVkWZUHmZJDLMtlbXhe7+ctEEyOiwFpB500ca9mN jk8Cjsgcft3RtXyIC4W7aasrlJGyg7TFFaJS//5ImpBpDbWUey1DYCiSIVmmmrKyU3sOCMlOXbDm qaaREJ2PQ2hYoY/DaoYY8UFlULsJNYcgNNRtgfITXZYuc2dpW0/gOU0037qeXRbXyivUP/kR2Mhx 9vFFjl2RbG9KTBtGbUrXppg2pWst1fRiKByhM9UabWZMtlojV3zXvCfZe0BUDSYQUXr+xKiFnhlW lLT3Wv4FwRkdjo8yGkvQa2oiQL1qQEn7Tj7HfJKZfWogDSeDQ5H0SW8iMOvz+oJqLKDNQR8ZTtdN r0r3vaV0c1BHhv+1xwwZZl3WsYx908/JOM3MfSzjNMs4zTL2efv0jMGxcDcJ9UfSMnRrePjo9ApX aMSlilrtWne5aaJTX7cOu+W09UMByLtQiGdxEb7XFSOYye1z+5gJNwwzlbBXvrzJcrrDbv2QvJs3 mVBdqnaD67jrC9dRdoElOBZgwErmsvPcmVmzrdmlsXOGY0cQfv3hbYyL1uHdIEpx1BmEOA9G0RDn ea6qQBLiBCrl2laLq8/0yNO76OkzPfb0mhY90OVZ9DA0bbaX2ksd2ODehicKP//Ea4B/4Ikzr59y N7ib+OwrBPsc8OSqt6RAgqpisbKo+KGddevqu2u6D129D5o2kzJR3ejctnX7luZy7ubCpbcWFt66 tMD5cnRBPx2b/89+2v/Yj11GOL38/vLt3BMM2C5ag1KOF5CfzvMi8j9CKwgFKD2FD/I8gQ1kJs9z UEJ+k+d51C/keQH5R3lehA2ceWhyInEwFk8o7ylDowmld/zI+DFUKf7xVybGX4kdGxs/okwcjjco gdix2H9wamSdKeHxw8eZ5qjyT1KpnjVhKIoeBCHgYP9A4e2i1UCH0FIqdujDBkLMLrGmUXh+kKRC tv6WdurYzh36I/wDnTp17KqeXK1jHeRxv879OPfB1VP2tRynWaeyG6ptjPLH8ShLlR+lUbKIhrqr PU/XevlkMDNu8H+IADnmiPCAEPe0Cq+UACPxXcwwpWS7KoUOo4R+oUPiY6lQRAz7G/RuBA+PnHS2 30yhx4zB474mJaZpt3wtOHxN1HeeLWibHYbWZ0/MHTLp8jkvpSRYUA85pUvx+DRq5MkxwUDYXPIX 1TF5DfdLDtQek91e5ye5ynKNJZzw/9f0fspVQYp86Qlvz+d2v3r5a51aAr/cflwU9v1u+bVer66s b6vCsPJ3+RsBBgAcHDLMCg0KZW5kc3RyZWFtDWVuZG9iag0yNiAwIG9iajw8L1N1YnR5cGUvVHJ1 ZVR5cGUvRm9udERlc2NyaXB0b3IgMjcgMCBSL0xhc3RDaGFyIDEyMS9XaWR0aHNbMjUwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCA3MjIgMCA3MjIgNzIyIDAgMCAwIDAgMCAwIDAgNjY3IDAgMCAwIDYxMSAwIDcyMiA1NTYgNjY3 IDAgNzIyIDAgMCAwIDAgMCAwIDAgMCAwIDAgNTAwIDU1NiAwIDU1NiA0NDQgMzMzIDUwMCA1NTYg Mjc4IDAgNTU2IDI3OCA4MzMgNTU2IDUwMCAwIDAgNDQ0IDM4OSAzMzMgNTU2IDUwMCA3MjIgNTAw IDUwMF0vQmFzZUZvbnQvVGltZXNOZXdSb21hblBTLUJvbGRNVC9GaXJzdENoYXIgMzIvRW5jb2Rp bmcvV2luQW5zaUVuY29kaW5nL1R5cGUvRm9udD4+DWVuZG9iag0yNyAwIG9iajw8L1N0ZW1WIDEz Ni9Gb250TmFtZS9UaW1lc05ld1JvbWFuUFMtQm9sZE1UL0ZvbnRTdHJldGNoL05vcm1hbC9Gb250 V2VpZ2h0IDcwMC9GbGFncyAzNC9EZXNjZW50IC0yMTYvRm9udEJCb3hbLTU1OCAtMzA3IDIwMDAg MTAyNl0vQXNjZW50IDg5MS9Gb250RmFtaWx5KFRpbWVzIE5ldyBSb21hbikvQ2FwSGVpZ2h0IDY1 Ni9YSGVpZ2h0IC01NDYvVHlwZS9Gb250RGVzY3JpcHRvci9JdGFsaWNBbmdsZSAwPj4NZW5kb2Jq DTI4IDAgb2JqPDwvTnVtc1swIDI5IDAgUl0+Pg1lbmRvYmoNMjkgMCBvYmo8PC9TL0Q+Pg1lbmRv YmoNMzAgMCBvYmo8PC9Db3VudCA3L1R5cGUvUGFnZXMvS2lkc1szNSAwIFIgMSAwIFIgNCAwIFIg NyAwIFIgMTAgMCBSIDEzIDAgUiAxNiAwIFJdPj4NZW5kb2JqDTMxIDAgb2JqPDwvU3VidHlwZS9Y TUwvTGVuZ3RoIDM1NTUvVHlwZS9NZXRhZGF0YT4+c3RyZWFtDQo8P3hwYWNrZXQgYmVnaW49Iu+7 vyIgaWQ9Ilc1TTBNcENlaGlIenJlU3pOVGN6a2M5ZCI/Pgo8eDp4bXBtZXRhIHhtbG5zOng9ImFk b2JlOm5zOm1ldGEvIiB4OnhtcHRrPSIzLjEtNzAxIj4KICAgPHJkZjpSREYgeG1sbnM6cmRmPSJo dHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjIj4KICAgICAgPHJkZjpE ZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6cGRmPSJodHRwOi8vbnMu YWRvYmUuY29tL3BkZi8xLjMvIj4KICAgICAgICAgPHBkZjpQcm9kdWNlcj5BY3JvYmF0IERpc3Rp bGxlciA3LjAgKFdpbmRvd3MpPC9wZGY6UHJvZHVjZXI+CiAgICAgIDwvcmRmOkRlc2NyaXB0aW9u PgogICAgICA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIgogICAgICAgICAgICB4bWxuczp4 YXA9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8iPgogICAgICAgICA8eGFwOkNyZWF0b3JU b29sPlBTY3JpcHQ1LmRsbCBWZXJzaW9uIDUuMi4yPC94YXA6Q3JlYXRvclRvb2w+CiAgICAgICAg IDx4YXA6TW9kaWZ5RGF0ZT4yMDA2LTA3LTEzVDE3OjM3OjU1LTA0OjAwPC94YXA6TW9kaWZ5RGF0 ZT4KICAgICAgICAgPHhhcDpDcmVhdGVEYXRlPjIwMDYtMDctMTNUMTc6Mzc6NTUtMDQ6MDA8L3hh cDpDcmVhdGVEYXRlPgogICAgICA8L3JkZjpEZXNjcmlwdGlvbj4KICAgICAgPHJkZjpEZXNjcmlw dGlvbiByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6ZGM9Imh0dHA6Ly9wdXJsLm9yZy9k Yy9lbGVtZW50cy8xLjEvIj4KICAgICAgICAgPGRjOmZvcm1hdD5hcHBsaWNhdGlvbi9wZGY8L2Rj OmZvcm1hdD4KICAgICAgICAgPGRjOnRpdGxlPgogICAgICAgICAgICA8cmRmOkFsdD4KICAgICAg ICAgICAgICAgPHJkZjpsaSB4bWw6bGFuZz0ieC1kZWZhdWx0Ij5NaWNyb3NvZnQgV29yZCAtIFN0 cnVjdHVyZWRTZWN1cml0eVBvbGljeS5kb2M8L3JkZjpsaT4KICAgICAgICAgICAgPC9yZGY6QWx0 PgogICAgICAgICA8L2RjOnRpdGxlPgogICAgICAgICA8ZGM6Y3JlYXRvcj4KICAgICAgICAgICAg PHJkZjpTZXE+CiAgICAgICAgICAgICAgIDxyZGY6bGk+cGJha2VyPC9yZGY6bGk+CiAgICAgICAg ICAgIDwvcmRmOlNlcT4KICAgICAgICAgPC9kYzpjcmVhdG9yPgogICAgICA8L3JkZjpEZXNjcmlw dGlvbj4KICAgICAgPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1s bnM6eGFwTU09Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9tbS8iPgogICAgICAgICA8eGFw TU06RG9jdW1lbnRJRD51dWlkOjcyOTNiM2UwLTZmY2ItNDFmNC05MGE4LTg4MzA3NmIzOTg1Mzwv eGFwTU06RG9jdW1lbnRJRD4KICAgICAgICAgPHhhcE1NOkluc3RhbmNlSUQ+dXVpZDoyMTFiYTZi MS1hYjAyLTQ4YTUtYmJmMS1iMTMwYTBhZTVjM2E8L3hhcE1NOkluc3RhbmNlSUQ+CiAgICAgIDwv cmRmOkRlc2NyaXB0aW9uPgogICA8L3JkZjpSREY+CjwveDp4bXBtZXRhPgogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgCjw/eHBhY2tldCBlbmQ9Inci Pz4NCmVuZHN0cmVhbQ1lbmRvYmoNMzIgMCBvYmo8PC9DcmVhdGlvbkRhdGUoRDoyMDA2MDcxMzE3 Mzc1NS0wNCcwMCcpL0F1dGhvcihwYmFrZXIpL0NyZWF0b3IoUFNjcmlwdDUuZGxsIFZlcnNpb24g NS4yLjIpL1Byb2R1Y2VyKEFjcm9iYXQgRGlzdGlsbGVyIDcuMCBcKFdpbmRvd3NcKSkvTW9kRGF0 ZShEOjIwMDYwNzEzMTczNzU1LTA0JzAwJykvVGl0bGUoTWljcm9zb2Z0IFdvcmQgLSBTdHJ1Y3R1 cmVkU2VjdXJpdHlQb2xpY3kuZG9jKT4+DWVuZG9iag14cmVmDQowIDMzDQowMDAwMDAwMDAwIDY1 NTM1IGYNCjAwMDAwMDkwOTUgMDAwMDAgbg0KMDAwMDAwOTIyMSAwMDAwMCBuDQowMDAwMDA5Mzc0 IDAwMDAwIG4NCjAwMDAwMTI2NjQgMDAwMDAgbg0KMDAwMDAxMjc5MCAwMDAwMCBuDQowMDAwMDEy OTI5IDAwMDAwIG4NCjAwMDAwMTY1NjIgMDAwMDAgbg0KMDAwMDAxNjY4OCAwMDAwMCBuDQowMDAw MDE2ODA0IDAwMDAwIG4NCjAwMDAwMjAzNTYgMDAwMDAgbg0KMDAwMDAyMDQ4NSAwMDAwMCBuDQow MDAwMDIwNjE0IDAwMDAwIG4NCjAwMDAwMjMzNjMgMDAwMDAgbg0KMDAwMDAyMzQ5MiAwMDAwMCBu DQowMDAwMDIzNjA5IDAwMDAwIG4NCjAwMDAwMjc0NTQgMDAwMDAgbg0KMDAwMDAyNzU4MyAwMDAw MCBuDQowMDAwMDI3NzAxIDAwMDAwIG4NCjAwMDAwMzA5MDEgMDAwMDAgbg0KMDAwMDAzMTEyMiAw MDAwMCBuDQowMDAwMDMxMjUyIDAwMDAwIG4NCjAwMDAwMzE0MzYgMDAwMDAgbg0KMDAwMDAzMTgz NSAwMDAwMCBuDQowMDAwMDMyMDY0IDAwMDAwIG4NCjAwMDAwMzIzNTAgMDAwMDAgbg0KMDAwMDAz OTQyMiAwMDAwMCBuDQowMDAwMDM5ODI0IDAwMDAwIG4NCjAwMDAwNDAwNzIgMDAwMDAgbg0KMDAw MDA0MDEwNyAwMDAwMCBuDQowMDAwMDQwMTMxIDAwMDAwIG4NCjAwMDAwNDAyMjIgMDAwMDAgbg0K MDAwMDA0Mzg1NCAwMDAwMCBuDQp0cmFpbGVyDQo8PC9TaXplIDMzPj4NCnN0YXJ0eHJlZg0KMTE2 DQolJUVPRg0K ------_=_NextPart_001_01C6A6C9.675D4B40-- From hartmans@MIT.EDU Fri Jul 14 10:12:34 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k6EECXDo029475 for ; Fri, 14 Jul 2006 10:12:33 -0400 Received: from carter-zimmerman.mit.edu (h1f54-net84db.lab.risq.net [132.219.31.84] (may be forged)) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k6EECW9F020955 for ; Fri, 14 Jul 2006 10:12:32 -0400 (EDT) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 925B5E0079; Fri, 14 Jul 2006 10:12:59 -0400 (EDT) From: Sam Hartman To: Ian G References: <44B7A402.6070607@systemics.com> Date: Fri, 14 Jul 2006 10:12:59 -0400 In-Reply-To: <44B7A402.6070607@systemics.com> (Ian G.'s message of "Fri, 14 Jul 2006 16:02:42 +0200") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 3.548 X-Spam-Level: *** (3.548) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, housley@vigilsec.com, Derek Atkins , ietf-openpgp@imc.org Subject: Re: [saag] OpenPGP Minutes / Quick Summary X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2006 14:12:34 -0000 >>>>> "Ian" == Ian G writes: Ian> Derek Atkins wrote: >> OpenPGP TUESDAY, July 11, 2006 1850-1950 Afternoon Session IV >> Ten people showed up for the meeting. Only one person was am >> implementor, and that was in the past (he's not an OpenPGP >> implementor anymore). 2440bis has been submitted to Sam and he >> will review it and act on it Ian> Sorry, who is Sam? Sam Hartman, the IESG member responsible for openpgp. From yaronf@checkpoint.com Fri Jul 14 10:49:14 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k6EEnETl003460 for ; Fri, 14 Jul 2006 10:49:14 -0400 Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k6EEnCVr025069 for ; Fri, 14 Jul 2006 10:49:12 -0400 (EDT) Received: from ysheffer (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id k6EEn8Rk017142; Fri, 14 Jul 2006 17:49:10 +0300 (IDT) From: "Yaron Sheffer" To: "'Pekka Savola'" , Date: Fri, 14 Jul 2006 10:49:08 -0400 Message-ID: <002e01c6a754$aa8a0020$cc05db84@ad.checkpoint.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 In-Reply-To: Thread-Index: Acamnv5sPRLYqt6ITCqui6r6DDgzVQAtNVGw X-Spam-Score: -0.001 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: Re: [saag] Remove tunnel mode from ipsec-tunnels-02? (fwd) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2006 14:49:14 -0000 Hi Pekka, After having a few words with Pasi and Hannes, I believe there is a slight misunderstanding here. Pasi's comments imply that the document should be fixed to support tunnel-mode v6-in-v4. His comments *do not* rule out this solution. In fact this mode is a very likely direction for existing VPN gateways to protect v6 traffic. So I would hate to see it disappear. Thanks, Yaron > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Wednesday, July 12, 2006 21:48 > To: saag@mit.edu > Subject: [saag] Remove tunnel mode from ipsec-tunnels-02? (fwd) > > FYI, > > There seem to be more generic complications in applying tunnel mode > to v6-in-v4 tunnels, hence we're proposing to use only transport mode. > > Comments from (more) IPsec experts would also be welcome. > > ---------- Forwarded message ---------- > Date: Wed, 12 Jul 2006 17:19:09 +0300 (EEST) > From: Pekka Savola > To: v6ops@ops.ietf.org > Subject: Remove tunnel mode from ipsec-tunnels-02? > > Hello, > > As proposed at the v6ops meeting [0], the authors of > draft-ietf-v6ops-ipsec-tunnels-02 propose to remove support for tunnel > mode in this particular context (securing v6-in-v4 configured > tunnels). > > This is due to issues spotted by Francis [1] and Pasi [2]. Generic > "::/0 -> ::/0" selectors could not be made to work without > interface-specific SPDs, and those cannot be signalled in IKE (that's > run on top of IPv4) when the tunnel would be IPv6 in a standardized > way. Generic selectors are required for link-local traffic (e.g., ND) > to work on the tunnel. > > If we go through with this proposed resolution, > draft-ietf-v6ops-ipsec-tunnels would only describe transport mode. > > Comments are welcome. > > [0] http://www3.ietf.org/proceedings/06jul/slides/v6ops-4.pdf > [1] http://ops.ietf.org/lists/v6ops/v6ops.2006/msg00159.html > [2] http://ops.ietf.org/lists/v6ops/v6ops.2006/msg00230.html > > For the authors of draft-ietf-v6ops-ipsec-tunnels-02, > > -- > 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 pekkas@netcore.fi Fri Jul 14 11:35:25 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k6EFZPkh011148 for ; Fri, 14 Jul 2006 11:35:25 -0400 Received: from netcore.fi (netcore.fi [193.94.160.1]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k6EFZSle008553 for ; Fri, 14 Jul 2006 11:35:28 -0400 (EDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id k6EFZFXG014103; Fri, 14 Jul 2006 18:35:15 +0300 Date: Fri, 14 Jul 2006 18:35:15 +0300 (EEST) From: Pekka Savola To: Yaron Sheffer In-Reply-To: <002e01c6a754$aa8a0020$cc05db84@ad.checkpoint.com> Message-ID: References: <002e01c6a754$aa8a0020$cc05db84@ad.checkpoint.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.2/1598/Thu Jul 13 14:38:16 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.2 X-Spam-Checker-Version: SpamAssassin 3.1.2 (2006-05-25) on otso.netcore.fi X-Spam-Score: 0 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] Remove tunnel mode from ipsec-tunnels-02? (fwd) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jul 2006 15:35:25 -0000 On Fri, 14 Jul 2006, Yaron Sheffer wrote: > After having a few words with Pasi and Hannes, I believe there is a slight > misunderstanding here. Pasi's comments imply that the document should be > fixed to support tunnel-mode v6-in-v4. His comments *do not* rule out this > solution. > > In fact this mode is a very likely direction for existing VPN gateways to > protect v6 traffic. So I would hate to see it disappear. Can you describe how you believe that would work, e.g., by describing what the SPDs would look like? >> -----Original Message----- >> From: Pekka Savola [mailto:pekkas@netcore.fi] >> Sent: Wednesday, July 12, 2006 21:48 >> To: saag@mit.edu >> Subject: [saag] Remove tunnel mode from ipsec-tunnels-02? (fwd) >> >> FYI, >> >> There seem to be more generic complications in applying tunnel mode >> to v6-in-v4 tunnels, hence we're proposing to use only transport mode. >> >> Comments from (more) IPsec experts would also be welcome. >> >> ---------- Forwarded message ---------- >> Date: Wed, 12 Jul 2006 17:19:09 +0300 (EEST) >> From: Pekka Savola >> To: v6ops@ops.ietf.org >> Subject: Remove tunnel mode from ipsec-tunnels-02? >> >> Hello, >> >> As proposed at the v6ops meeting [0], the authors of >> draft-ietf-v6ops-ipsec-tunnels-02 propose to remove support for tunnel >> mode in this particular context (securing v6-in-v4 configured >> tunnels). >> >> This is due to issues spotted by Francis [1] and Pasi [2]. Generic >> "::/0 -> ::/0" selectors could not be made to work without >> interface-specific SPDs, and those cannot be signalled in IKE (that's >> run on top of IPv4) when the tunnel would be IPv6 in a standardized >> way. Generic selectors are required for link-local traffic (e.g., ND) >> to work on the tunnel. >> >> If we go through with this proposed resolution, >> draft-ietf-v6ops-ipsec-tunnels would only describe transport mode. >> >> Comments are welcome. >> >> [0] http://www3.ietf.org/proceedings/06jul/slides/v6ops-4.pdf >> [1] http://ops.ietf.org/lists/v6ops/v6ops.2006/msg00159.html >> [2] http://ops.ietf.org/lists/v6ops/v6ops.2006/msg00230.html >> >> For the authors of draft-ietf-v6ops-ipsec-tunnels-02, >> >> -- >> Pekka Savola "You each name yourselves king, yet the >> Netcore Oy kingdom bleeds." >> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > -- 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 mcr@sandelman.ottawa.on.ca Mon Jul 17 19:45:41 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k6HNjdr4030483 for ; Mon, 17 Jul 2006 19:45:39 -0400 Received: from cod.sandelman.ca (newcod.sandelman.ca [192.139.46.42]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k6HNjc2p002637 for ; Mon, 17 Jul 2006 19:45:39 -0400 (EDT) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marajade.sandelman.ca.", Issuer "Michael Richardson" (verified OK)) by cod.sandelman.ca (Postfix) with ESMTP id 2E83F120FA; Mon, 17 Jul 2006 19:45:38 -0400 (EDT) Received: from sandelman.ottawa.on.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id E333D3AD9E; Mon, 17 Jul 2006 19:45:32 -0400 (EDT) From: Michael Richardson To: Pekka Savola In-Reply-To: Message from Pekka Savola of "Fri, 14 Jul 2006 18:35:15 +0300." References: <002e01c6a754$aa8a0020$cc05db84@ad.checkpoint.com> X-Mailer: MH-E 7.82; nmh 1.1; XEmacs 21.4 (patch 17) Date: Mon, 17 Jul 2006 19:45:32 -0400 Message-ID: <24082.1153179932@sandelman.ottawa.on.ca> Sender: mcr@sandelman.ottawa.on.ca X-Spam-Score: 0 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Yaron Sheffer Subject: Re: [saag] Remove tunnel mode from ipsec-tunnels-02? (fwd) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2006 23:45:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Pekka" == Pekka Savola writes: >> After having a few words with Pasi and Hannes, I believe there is >> a slight misunderstanding here. Pasi's comments imply that the >> document should be fixed to support tunnel-mode v6-in-v4. His >> comments *do not* rule out this solution. >> >> In fact this mode is a very likely direction for existing VPN >> gateways to protect v6 traffic. So I would hate to see it >> disappear. Pekka> Can you describe how you believe that would work, e.g., by Pekka> describing what the SPDs would look like? Linux KLIPS: 2001:4830:1217::/64 -> 2001:4830:1615:1::/64 => tun0x1020@205.150.200.134 KAME: 2001:4830:1217::/64[any] 2001:4830:1615:1::/64[any] any out ipsec esp/tunnel/205.150.200.247-205.150.200.134/require created: Jul 15 03:31:15 2006 lastused: Jul 17 00:42:11 2006 lifetime: 0(s) validtime: 0(s) spid=16391 seq=3 pid=16383 refcnt=1 - -- ] 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"); [ "The Microsoft _Get the Facts CD_ does not work on Linux." - orospakr -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Finger me for keys iQEVAwUBRLwhGYCLcPvd0N1lAQL2BQf/YGubws4yTdVtB80iA5KPOQI+cIMe3Ck3 oEpRYmMIb8HUgfO89HbdbMYxLGTEcYPLnVb5/cSVSLKhX0yjpnCdtxmpOgKbFO2m gw/z/73g8dJX1duJ8ucfh8MUi7L7mxHuJChO/r6FFiIMxsmQkO40f4X1GLU08iTH R5GIRv5KZy+x8NJXTyZHgRPISlhrY8j6dHnTZBb7ZhWhz+YY0OpcmILYLmMV3Bn1 zoMLTSQP9oRxj5WStAytlT6hyMeIk6h5F3qOZHP+DAaTHC3yZa0cmN3LAfhpD9Eb IxA+dEA+yIMelYgjrTuXzLL8Kw4KLGlFyeCLNG39pVk/894WA8dqrg== =31ze -----END PGP SIGNATURE----- From pekkas@netcore.fi Tue Jul 18 01:00:14 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k6I50EYL030265 for ; Tue, 18 Jul 2006 01:00:14 -0400 Received: from netcore.fi (netcore.fi [193.94.160.1]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k6I50H9e026229 for ; Tue, 18 Jul 2006 01:00:18 -0400 (EDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id k6I4xwSc024965; Tue, 18 Jul 2006 08:00:03 +0300 Date: Tue, 18 Jul 2006 07:59:58 +0300 (EEST) From: Pekka Savola To: Michael Richardson In-Reply-To: <24082.1153179932@sandelman.ottawa.on.ca> Message-ID: References: <002e01c6a754$aa8a0020$cc05db84@ad.checkpoint.com> <24082.1153179932@sandelman.ottawa.on.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.2/1600/Sat Jul 15 18:03:46 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.2 X-Spam-Checker-Version: SpamAssassin 3.1.2 (2006-05-25) on otso.netcore.fi X-Spam-Score: 0 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Eric Vyncke , Yaron Sheffer Subject: Re: [saag] Remove tunnel mode from ipsec-tunnels-02? (fwd) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2006 05:00:15 -0000 (Added Eric to Cc: as he commented on this issue on v6ops.) On Mon, 17 Jul 2006, Michael Richardson wrote: > Pekka> Can you describe how you believe that would work, e.g., by > Pekka> describing what the SPDs would look like? > > Linux KLIPS: > 2001:4830:1217::/64 -> 2001:4830:1615:1::/64 => tun0x1020@205.150.200.134 > > KAME: > 2001:4830:1217::/64[any] 2001:4830:1615:1::/64[any] any > out ipsec > esp/tunnel/205.150.200.247-205.150.200.134/require > created: Jul 15 03:31:15 2006 lastused: Jul 17 00:42:11 2006 > lifetime: 0(s) validtime: 0(s) > spid=16391 seq=3 pid=16383 > refcnt=1 What does the packet look on the wire? Does this incur double encapsulation (which we considered a big no-no)? If not, this is probably the "specific SPD, tunnel not modelled as an interface" scenario that we described in Appendix A. You cannot run IGP routing protocols, multicast or the like over such a tunnel, but that may be an acceptable tradeoff. We received comments doubting whether SSPD no-interface model was common enough but if we have two implementations already, maybe that's a sufficient proof of running code. -- 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 mcr@sandelman.ottawa.on.ca Tue Jul 18 08:28:52 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k6ICSpif000574 for ; Tue, 18 Jul 2006 08:28:52 -0400 Received: from cod.sandelman.ca (newcod.sandelman.ca [192.139.46.42]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k6ICSgPl027283 for ; Tue, 18 Jul 2006 08:28:42 -0400 (EDT) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marajade.sandelman.ca.", Issuer "Michael Richardson" (verified OK)) by cod.sandelman.ca (Postfix) with ESMTP id 906B3120FA; Tue, 18 Jul 2006 08:28:39 -0400 (EDT) Received: from sandelman.ottawa.on.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 61A0B3AD9E; Tue, 18 Jul 2006 08:28:38 -0400 (EDT) From: Michael Richardson To: Pekka Savola In-Reply-To: Message from Pekka Savola of "Tue, 18 Jul 2006 07:59:58 +0300." References: <002e01c6a754$aa8a0020$cc05db84@ad.checkpoint.com> <24082.1153179932@sandelman.ottawa.on.ca> X-Mailer: MH-E 7.82; nmh 1.1; XEmacs 21.4 (patch 17) Date: Tue, 18 Jul 2006 08:28:38 -0400 Message-ID: <24217.1153225718@sandelman.ottawa.on.ca> Sender: mcr@sandelman.ottawa.on.ca X-Spam-Score: 0 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Eric Vyncke , Yaron Sheffer Subject: Re: [saag] Remove tunnel mode from ipsec-tunnels-02? (fwd) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2006 12:28:52 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Pekka" == Pekka Savola writes: Pekka> What does the packet look on the wire? Does this incur Pekka> double encapsulation Pekka> (which we considered a big no-no)? It does not. ESP, next header = 41. Pekka> routing protocols, multicast or the like over such a tunnel, Pekka> but that may be Pekka> an acceptable tradeoff. We received comments doubting whether SSPD Well, we are working towards an implementation that permits interfaces to be created on a per-SPD, per-SPD-group or not at all. If you think of a tunnel interface as being like a NBMA ATM interface, it starts to make a lot of sense. - -- ] 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"); [ "The Microsoft _Get the Facts CD_ does not work on Linux." - orospakr -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Finger me for keys iQEVAwUBRLzT84CLcPvd0N1lAQLSoQf/d4RPwgtOpyWS1/+51LSwENxu4pyJXizq u0JN90FGN+slfjZXSeERO6jxWA7tWskAHr5MiVCx5yjKOaJvX21ACbhEGTnk9QcC kqqzp6NRnTnOTTTePjNspqMg7uF7iWJ+JzSrSdwFw4/65jGfFCEqlqtFJncPiXx/ Q+3Qmbjv7xl7VsR5QduTvCScrr7v1OegOlihaZSohzeEgCAgjQpBZ/uF+wW91Ng3 NxnnRZtv62HrsyWfbcI2+O2WqrRbwTYztfQ/cnhYv8eLENt9g/GgRvQR/4bvLWxG 3Y5HTgSbWgW5RQ7DvauHjT9MMLGvXP1duAlKZoFODIl2jCokNLs6IQ== =29B/ -----END PGP SIGNATURE----- From pekkas@netcore.fi Tue Jul 18 14:50:32 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k6IIoOYM027251 for ; Tue, 18 Jul 2006 14:50:24 -0400 Received: from netcore.fi (netcore.fi [193.94.160.1]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k6IIoSgD022653 for ; Tue, 18 Jul 2006 14:50:29 -0400 (EDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id k6IIoAvr015493; Tue, 18 Jul 2006 21:50:13 +0300 Date: Tue, 18 Jul 2006 21:50:10 +0300 (EEST) From: Pekka Savola To: Michael Richardson In-Reply-To: <24217.1153225718@sandelman.ottawa.on.ca> Message-ID: References: <002e01c6a754$aa8a0020$cc05db84@ad.checkpoint.com> <24082.1153179932@sandelman.ottawa.on.ca> <24217.1153225718@sandelman.ottawa.on.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.2/1600/Sat Jul 15 18:03:46 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.2 X-Spam-Checker-Version: SpamAssassin 3.1.2 (2006-05-25) on otso.netcore.fi X-Spam-Score: 0 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Eric Vyncke , Yaron Sheffer Subject: Re: [saag] Remove tunnel mode from ipsec-tunnels-02? (fwd) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jul 2006 18:50:33 -0000 On Tue, 18 Jul 2006, Michael Richardson wrote: > Pekka> routing protocols, multicast or the like over such a tunnel, > Pekka> but that may be > Pekka> an acceptable tradeoff. We received comments doubting whether SSPD > > Well, we are working towards an implementation that permits interfaces > to be created on a per-SPD, per-SPD-group or not at all. First off, this has a number of potential issues. For example, IPv6 architecture requires that each interface has a link-local address. But the SPD you mentioned does not match link-local traffic. If you want to ping ff02::1 or the link-local address of the remote end of the tunnel, how would that work out (especially when at least one end of the tunnel would have multiple tunnels)? That's exactly the problem we've came across. For further information, have a look at (now expired) http://www.watersprings.org/pub/id/draft-duffy-ppvpn-ipsec-vlink-00.txt > If you think of a tunnel interface as being like a NBMA ATM > interface, it starts to make a lot of sense. Unfortunately, I don't think it's quite that simple. Think about address resolution with ICMPv6, for instance. A point-to-multipoint link might work if all the IPsec endpoints were using shared secrets, static keying or some such, but otherwise the security side might get extremely complicated. Even the NBMA ATM interface analogy is not a very good one. Folks that used LANE and other NBMA ATM technologies have almost completely turned off (due to complexity, unreliability of just-in-time signaling, difficulty in debugging, etc.) such methods years ago, and have never looked back. I've yet to see a succesful NBMA technology where the lower layer didn't rely on (broad|multi)casting. Hence, I'd be very cautious before creating similar approaches in IP (or IPsec). I'd be happy to be proven wrong on this... -- 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 bora@broadcom.com Wed Jul 19 23:43:03 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k6K3gvQA031883 for ; Wed, 19 Jul 2006 23:43:00 -0400 Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k6K3bsrO025562 for ; Wed, 19 Jul 2006 23:37:55 -0400 (EDT) Received: from 10.10.64.154 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Wed, 19 Jul 2006 20:37:39 -0700 X-Server-Uuid: F962EFE0-448C-40EE-8100-87DF498ED0EA Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id D374F2AE; Wed, 19 Jul 2006 20:37:38 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id AA9192B0; Wed, 19 Jul 2006 20:37:38 -0700 (PDT) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id DZQ58922; Wed, 19 Jul 2006 20:37:27 -0700 (PDT) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 6FFEC20501; Wed, 19 Jul 2006 20:37:27 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 19 Jul 2006 20:37:33 -0700 Message-ID: <03235919BBDE634289BB6A0758A20B36827D80@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: [saag] Remove tunnel mode from ipsec-tunnels-02? (fwd) Thread-Index: AcaqJ1dGZYWZh8BKR4WlR0FI4Xw+XABhl1FQ From: "Bora Akyol" To: "Pekka Savola" , "Michael Richardson" X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006071913; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230342E34344245463746442E303043352D412D; ENG=IBF; TS=20060720033742; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006071913_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 68A025090HW58672599-01-01 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id k6K3gvQA031883 Cc: saag@mit.edu, Eric Vyncke , Yaron Sheffer Subject: Re: [saag] Remove tunnel mode from ipsec-tunnels-02? (fwd) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2006 03:43:03 -0000 > What does the packet look on the wire? Does this incur > double encapsulation (which we considered a big no-no)? > Why is tunneling a big no-no? 100% of VPN gateways and clients use tunneling mode. In fact transport mode only works for the originator of the traffic. Bora From pekkas@netcore.fi Thu Jul 20 01:45:13 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k6K5jDhv032300 for ; Thu, 20 Jul 2006 01:45:13 -0400 Received: from netcore.fi (netcore.fi [193.94.160.1]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k6K5jCAS016944 for ; Thu, 20 Jul 2006 01:45:13 -0400 (EDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id k6K5iq0L003765; Thu, 20 Jul 2006 08:44:53 +0300 Date: Thu, 20 Jul 2006 08:44:52 +0300 (EEST) From: Pekka Savola To: Bora Akyol In-Reply-To: <03235919BBDE634289BB6A0758A20B36827D80@NT-SJCA-0751.brcm.ad.broadcom.com> Message-ID: References: <03235919BBDE634289BB6A0758A20B36827D80@NT-SJCA-0751.brcm.ad.broadcom.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.2/1609/Wed Jul 19 15:13:27 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.2 X-Spam-Checker-Version: SpamAssassin 3.1.2 (2006-05-25) on otso.netcore.fi X-Spam-Score: 0 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Michael Richardson , Eric Vyncke , Yaron Sheffer Subject: Re: [saag] Remove tunnel mode from ipsec-tunnels-02? (fwd) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jul 2006 05:45:14 -0000 On Wed, 19 Jul 2006, Bora Akyol wrote: >> What does the packet look on the wire? Does this incur >> double encapsulation (which we considered a big no-no)? > > Why is tunneling a big no-no? > 100% of VPN gateways and clients use tunneling mode. Tunneling is not, but we considered that _double encapsulation_ (IPv4 + ESP + IPv4 + IPv6 + payload instead of IPv4 + ESP + IPv6 + payload) to be highly undesirable. > In fact transport mode only works for the originator of the traffic. It's legal to use transport mode between a node and a security gateway. The point with using transport mode is that it would be used to secure an IPv6-over-IPv4 tunnel traffic (which is point-to-point) so transport mode is equally applicable as for securing, say, GRE or L2TP traffic. For more discussion, take a look at section 6 of (expired): http://www.watersprings.org/pub/id/draft-duffy-ppvpn-ipsec-vlink-00.txt -- 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 housley@vigilsec.com Mon Jul 24 14:25:39 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k6OIPdWd005995 for ; Mon, 24 Jul 2006 14:25:39 -0400 Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with SMTP id k6OIPeeL018091 for ; Mon, 24 Jul 2006 14:25:40 -0400 (EDT) Received: (qmail 19758 invoked by uid 0); 24 Jul 2006 18:25:35 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.83.235.104) by woodstock.binhost.com with SMTP; 24 Jul 2006 18:25:35 -0000 Message-Id: <7.0.0.16.2.20060724142355.072d02c8@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Mon, 24 Jul 2006 14:25:32 -0400 To: saag@mit.edu From: Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: hartmans-ietf@mit.edu Subject: [saag] IETF66 SAAG minutes X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2006 18:25:39 -0000 I have posted the draft minutes. Let me know about any problems. http://www3.ietf.org/proceedings/06jul/minutes/saag.txt Many thanks to Pasi for his help with these minutes. Russ From townsley@cisco.com Mon Jul 10 18:30:40 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k6AMUeKC005589 for ; Mon, 10 Jul 2006 18:30:40 -0400 Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k6AMUdwQ028394; Mon, 10 Jul 2006 18:30:39 -0400 (EDT) Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 10 Jul 2006 18:30:39 -0400 X-IronPort-AV: i="4.06,226,1149480000"; d="scan'208"; a="92258167:sNHT36760356" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6AMUdel004371; Mon, 10 Jul 2006 18:30:39 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6AMUbdW026054; Mon, 10 Jul 2006 18:30:39 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 10 Jul 2006 18:30:38 -0400 Received: from [132.219.22.209] ([10.82.224.238]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 10 Jul 2006 18:30:37 -0400 Message-ID: <44B2D50C.5020508@cisco.com> From: Mark Townsley User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: Sam Hartman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jul 2006 22:30:37.0902 (UTC) FILETIME=[77C046E0:01C6A470] DKIM-Signature: a=rsa-sha1; q=dns; l=9776; t=1152570639; x=1153434639; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=townsley@cisco.com; z=From:Mark=20Townsley=20 |Subject:Re=3A=20IPsec=20configuration=20via=20BGP--softwires=20to=20support=20ov erlay=20network=0A=20confidentiality/integrity |To:Sam=20Hartman=20; X=v=3Dcisco.com=3B=20h=3DehYwWjNebOmg65vye3NDUyw2fN8=3D; b=b2DQj4zSn4jrqoZ3ybnbfNXjYRkf4LnMZjkfa0KuPw/NMcSfKkyvsHRO/BP5cdjezv0ZF847 9vEConWLXXVg2/vAgVJ4AavO+WvNVqNmgPjIP7QwB580/f1/bH66KoCg; Authentication-Results: rtp-dkim-2.cisco.com; header.From=townsley@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -0.001 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 X-Mailman-Approved-At: Sun, 30 Jul 2006 12:31:17 -0400 Cc: saag@mit.edu, anonsec@postel.org, softwire-chairs@tools.ietf.org Subject: Re: [saag] IPsec configuration via BGP--softwires to support overlay network confidentiality/integrity X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Mon, 10 Jul 2006 22:30:41 -0000 X-Original-Date: Mon, 10 Jul 2006 18:30:36 -0400 X-List-Received-Date: Mon, 10 Jul 2006 22:30:41 -0000 Sam, was there any response to this? Thanks. Sam Hartman wrote: > Hi, folks. I'd like to describe some work that is proposed in the > softwires working group. First though I'd like to review what we're > trying to accomplish with security for Internet protocols and review > how IPsec is being used in protocols over in the Internet area. Then > I hope you'll join me in understanding that this work in softwires is > a critical part of what we need to do in order to meet our goal of > creating a usable security solution for overlay network protocols > being developed in the Internet area. I hope you'll help make sure > this work is a success. > > > When we try and design security for a protocol, we start with a threat > model and attempt to come up with a protocol design that provides > security services adequate to address threats identified in the threat > model. One of the key aspects of the success of this work is the > deployability and usability of the security solutions. If the > security solution is harder to configure than the rest of the > protocol, then we have room for improvement. If the security solution > has fundamentally different configuration scaling characteristics, > then we have failed. > > As an example, consider a protocol intended to provide automated > discovery. We cannot claim success if we only provide manually > configured security for that protocol. Similarly we cannot claim > success if the discovery mechanisms do not provide discovery for > appropriate security parameters. Similarly, if we are designing > security for a protocol where two parties who have no previous > association will interact, we generally cannot assume any shared > infrastructure or configuration for the security. We probably need to > provide a mode of security that protects against passive attacks > without infrastructure and/or a mode of security that depends on a PKI > for protection against passive and active attacks. > > We have significant work to do in order to meet these goals of > usability for some Internet Area protocols. Let me describe where > things stand. > > The L3VPN working group was established to describe protocols for > carrying customer IP traffic over a provider provisioned virtual > private network. One use case is a customer who has multiple > locations. The customer wishes to connect these locations together. > The customer could get leased lines to each location, but instead > hires the provider to provision an IP network . The provider wants to > carry the customer traffic over the provider's existing network. > However because everyone is using net 10 and for other reasons of > isolation, the provider needs to tag the customer's packets with > information about what addressing domain (which customer network) they > belong to. For the networks under discussion MPLS is used. > > The L2VPN working group is doing similar things except they care about > use cases where the provider wants to carry customer L2 packets over > the provider's network. > > Similarly, the softwires working group supports a topology where you > have a mesh of IPV6 tunnels over an IPV4 network or a mesh of IPV4 > tunnels over an IPV6 network. The goal is to support cases where the > core of a network is running a different version of IP than other > parts. > > So, how do we provide confidentiality and integrity in these cases? > We've decided that IPsec is the appropriate tool. RFC 4023 describes > one of the basic encapsulations that would be used in these > situations if you want to provide confidentiality or integrity. > (Native MPLS over L2 does not typically support confidentiality or > integrity) > > RFC 3931 describes L2TP V3, which provides another encapsulation that > is useful in this space. Again, we have chosen IPsec as the > confidentiality/integrity strategy. > > I know there are those here who believe that IPsec is the wrong > strategy for application security. For these protocols, that ship has > sailed: we have approved proposed standards that use IPsec. This > predates my involvement in the IESG. Now we must provide usable > security based on these existing decisions. > > > Both RFC 4023 and 3931 provide reasonable security for the rest of the > spec. IN particular, these specs provide for statically configured > tunnels and provide for statically configured security. If you are > specifying all the tunnel configuration by hand, it seems reasonable > to specify the security configuration. I suspect the implementations > are not all that usable: I suspect that you have to go to different > parts of the configuration to set up the IPsec from the rest of the > tunnel; I suspect that in practice there is no way to specify the > tunnel endpoint once and have it apply both to the security > configuration and the tunnel configuration. That's a problem but not > a protocol problem. > > However all of these groups propose to provide automatic discovery of > tunnels. For example RFC 4364 specifies a mechanism where BGP is used > to discover and configure all the tunnels in an MPLS L3VPN. > We need a security solution that is as easy to use as RFC 4364 in > order to set up confidentiality and integrity for RFC 4364. > > The security requirements we're trying to deal with are outlined in > RFC 4031 and its references. Roughly we're trying to provide > confidentiality and integrity protection of the customer traffic. > > One controversial assumption I'm making here is that we can rely on > the integrity of the signaling/discovery mechanism to give us > integrity and confidentiality for the data plane. If the discovery > were between the same two parties as the data traffic this would not > be very controversial. However the discovery is carried over BGP. > That means that the parties in the discovery may be different than the > parties in the data plane exchange. Note that we've decided in the > case of SIP, SDP and RTP that this model where hop-by-hop proxies are > used to set up end-to-end confidentiality/integrity is OK. Without > relying on the integrity of BGP, we'd have to require a PKI or > preshared keys. A PKI is a non-starter for the deployment > community--this is one of those layer 9 concerns that do establish > requirements for engineering. The real problem with relying on BGP > integrity is that it's kind of weak. The best case today is TCPMD5 > and the worst case today is none. > > So, let's consider what we can get if we rely on BGP integrity and it > happens not to be there. Well we can still get protection against > passive attacks. So long as the attacker does not actually modify the > BGP session, then we can negotiate end-to-end SAs authenticated with > the right parties. If our BGP does happen to be integrity protected > we get full protection against active attacks. If we do happen to > have a PKI, our implementation supports using that and we have it > configured, we end up getting optimal protection even if BGP is not > properly integrity protected. My personal feeling is that deploying > easy-to-use security that provides protection only against passive > attacks is better than no security. Since the solution we're > proposing does better than that I think it is a reasonable approach. > > Another thing to note about depending on BGP integrity. BGP will end > up having to be used to configure whether a particular association is > expected to have IPsec. As such anyone who can modify the BGP routes > can disable security. > > > So, what is the proposed solution? > > First, note that we are targeting the IPsec architecture described in > RFC 2401. After discussing draft-bellovin-use-ipsec and my > experiences with the OSPF V3 authentication draft, Russ and I have > decided that we cannot ask people to use RFC 4301 to secure > higher-layer protocols at this time. There aren't enough > implementations and we really need guidance similar to > draft-bellovin-use-ipsec targeted at 4301 before we could do that. > People who are interested in seeing us move to 4301 should work on > implementations and should work on BCPs and informational documents > designed to make it easier to use in these situations. Russ and I > both think that RFC 4301 is a significant improvement over RFC 2401. > > The idea is to include information in BGP routes used to set up the > tunnels sufficient to let peers know that they want to use IPsec, know > which identity to authenticate to and what IPsec parameters to use. > Peers should already know what SPD entries to create because they > should be able to identify what ports/protocols their tunnel traffic > will use in order to establish that tunnel traffic. > > In practice this means that BGP would probably distribute a > fingerprint of a certificate along with some very short identifier > indicating any additional configuration information that is needed. > > The work on what to carry in BGP will be accompanied by a profile of > IPsec which requires (probably by reference to the IPsec algorithms > documents) appropriate mandatory algorithms and which specifies how to > configure the SPD for this application. > > The work will take place in the softwires working group. They could > of course use any IPsec help we are able to provide. > > > Now is your chance to scream about the general approach. If you > disagree, please explain how we can meet the requirements outlined in > RFC 4031 and provide usable security solutions while still fixing the > parts you disagree with. > > > Thanks, > > --Sam > > From lear@cisco.com Thu Jul 13 14:39:20 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k6DIdKaH011880 for ; Thu, 13 Jul 2006 14:39:20 -0400 Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k6DIdNAV014523 for ; Thu, 13 Jul 2006 14:39:24 -0400 (EDT) Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 13 Jul 2006 11:39:23 -0700 X-IronPort-AV: i="4.06,238,1149490800"; d="scan'208"; a="305585302:sNHT23913432" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6DIdNi3002564; Thu, 13 Jul 2006 11:39:23 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k6DIdMHS028842; Thu, 13 Jul 2006 11:39:22 -0700 (PDT) Received: from [212.254.247.5] (ams3-vpn-dhcp4642.cisco.com [10.61.82.33]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k6DIXKNf013075; Thu, 13 Jul 2006 11:33:21 -0700 Message-ID: <44B69357.6050507@cisco.com> From: Eliot Lear User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: Juergen Quittek References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-5.cisco.com; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=1301; t=1152815963; x=1153679963; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20 |Subject:Re=3A=20[Isms]=20ISMS=20session=20summary; X=v=3Dcisco.com=3B=20h=3DaltBINBw6kSzwe40Zm4S1Rxpfvw=3D; b=D1hkgRCSkou+LcQYjC1hcAHva293kfTJEjG1FIrIytZCLjxw8CAADC9D31QZCqj1T/feJ4oY DjqGhpUOrq8LgjM7SKhNeEIoMXAvDVpyuap9yEjjZxUEIrGxMzJjoNmi; X-Spam-Score: 0.478 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 X-Mailman-Approved-At: Sun, 30 Jul 2006 12:31:17 -0400 Cc: saag@mit.edu, isms@ietf.org Subject: Re: [saag] [Isms] ISMS session summary X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Thu, 13 Jul 2006 18:39:20 -0000 X-Original-Date: Thu, 13 Jul 2006 20:39:19 +0200 X-List-Received-Date: Thu, 13 Jul 2006 18:39:20 -0000 Juergen, > ISMS Session Summary > Wednesday, July 12, 2006, 1510-1610 > > The two existing WG I-Ds on a transport mapping model and on an SSH > security model for SNMP still have few remaining decisions to be made. > There was consensus on clearly separating user authentication for > establishing a transport session from authorization required for > access control to MIB elements. > The discussion on how to create sessions for notifications from a > managed mode to a management system could still not get solved. From > the management system point of view, there is a clear preference for > initiating TLS sessions in 'reverse' direction. However, the security > problems implied by this approach might be too severe to use it. Could someone elaborate on what they think those implications are? > Finally, the WG discussed RADIUS integration of the SSH security model. > There seems to be different positions in the security community about > whether or not 'authorization only' requests harmonize or dis-harmonize > with the Kerberos architecture. A simple approach to take here would be to say that if you're using Kerberos to authenticate you must fill in appropriate VACM tables OOB. This would, therefore, involve a bunch of null functions for Kerberos. Eliot From mouse@Sparkle.Rodents.Montreal.QC.CA Sun Jul 30 13:46:17 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k6UHkHQP006919 for ; Sun, 30 Jul 2006 13:46:17 -0400 Received: from Sparkle.Rodents.Montreal.QC.CA (Sparkle.Rodents.Montreal.QC.CA [216.46.5.7]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k6UHkOh3012428 for ; Sun, 30 Jul 2006 13:46:24 -0400 (EDT) Received: (from mouse@localhost) by Sparkle.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id NAA01619; Sun, 30 Jul 2006 13:46:23 -0400 (EDT) From: der Mouse Message-Id: <200607301746.NAA01619@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. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. Date: Sun, 30 Jul 2006 13:42:48 -0400 (EDT) To: saag@mit.edu In-Reply-To: <44B2D50C.5020508@cisco.com> References: <44B2D50C.5020508@cisco.com> X-Spam-Score: 0 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: Re: [saag] IPsec configuration via BGP--softwires to support overlay network confidentiality/integrity X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jul 2006 17:46:17 -0000 >> I know there are those here who believe that IPsec is the wrong >> strategy for application security. For these protocols, that ship >> has sailed: we have approved proposed standards that use IPsec. >> This predates my involvement in the IESG. Now we must provide >> usable security based on these existing decisions. Now first, I want to be clear that I have no opinion on whether IPsec actually *is* a wrong strategy for application security; I do not know enough to consider myself competent to hold an opinion on that. But it does seem to me that there *always* needs to be a mechanism for backing out of past mistakes, if they prove to be mistakes - and this appears to be saying that there is none here. Surely *that* needs to be fixed first? Or am I wrong, and the IETF considers itself unable to rectify past mistakes? /~\ 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 hartmans@MIT.EDU Mon Jul 31 09:11:08 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k6VDB712010271 for ; Mon, 31 Jul 2006 09:11:07 -0400 Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k6VDB6Ak022010 for ; Mon, 31 Jul 2006 09:11:06 -0400 (EDT) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 7876EE00C1; Mon, 31 Jul 2006 09:11:57 -0400 (EDT) From: Sam Hartman To: Mark Townsley References: <44B2D50C.5020508@cisco.com> Date: Mon, 31 Jul 2006 09:11:57 -0400 In-Reply-To: <44B2D50C.5020508@cisco.com> (Mark Townsley's message of "Mon, 10 Jul 2006 18:30:36 -0400") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 3.548 X-Spam-Level: *** (3.548) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, anonsec@postel.org, softwire-chairs@tools.ietf.org Subject: Re: [saag] IPsec configuration via BGP--softwires to support overlay network confidentiality/integrity X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 13:11:08 -0000 >>>>> "Mark" == Mark Townsley writes: Mark> Sam, was there any response to this? Yes. The responses were all positive. From nw141292@binky.Central.Sun.COM Mon Jul 31 12:46:33 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k6VGkXsu005795 for ; Mon, 31 Jul 2006 12:46:33 -0400 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k6VGkZwH001047 for ; Mon, 31 Jul 2006 12:46:35 -0400 (EDT) Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by nwkea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k6VGkY96005013 for ; Mon, 31 Jul 2006 09:46:35 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k6VGhA0m020259 for ; Mon, 31 Jul 2006 10:43:10 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k6VGkYDS017698; Mon, 31 Jul 2006 11:46:34 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k6VGkXJp017697; Mon, 31 Jul 2006 11:46:33 -0500 (CDT) Date: Mon, 31 Jul 2006 11:46:33 -0500 From: Nicolas Williams To: der Mouse Message-ID: <20060731164633.GD17587@binky.Central.Sun.COM> Mail-Followup-To: Nicolas Williams , der Mouse , saag@mit.edu References: <44B2D50C.5020508@cisco.com> <200607301746.NAA01619@Sparkle.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200607301746.NAA01619@Sparkle.Rodents.Montreal.QC.CA> User-Agent: Mutt/1.5.7i X-Spam-Score: 0 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] IPsec configuration via BGP--softwires to support overlay network confidentiality/integrity X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 16:46:33 -0000 On Sun, Jul 30, 2006 at 01:42:48PM -0400, der Mouse wrote: > >> I know there are those here who believe that IPsec is the wrong > >> strategy for application security. For these protocols, that ship > >> has sailed: we have approved proposed standards that use IPsec. > >> This predates my involvement in the IESG. Now we must provide > >> usable security based on these existing decisions. > > Now first, I want to be clear that I have no opinion on whether IPsec > actually *is* a wrong strategy for application security; I do not know > enough to consider myself competent to hold an opinion on that. > > But it does seem to me that there *always* needs to be a mechanism for > backing out of past mistakes, if they prove to be mistakes - and this > appears to be saying that there is none here. There always is such a mechanism: specify a new version of the thing that had a mistake in it and implement it, then deploy it. The worst case is you need flag days. Usually we find ways to avoid flag days, because flag days are really, really inconvenient, to the point of being utterly impractical. Now, in the case of applications that rely on IPsec and which do so in poor ways, there will likely be ways to fix them that do not require flag days. Specifically the work of the BTNS WG, namely, the work on IPsec APIs, should provide an upgrade path for such applications that does not involve flag days. > Surely *that* needs to be fixed first? Or am I wrong, and the IETF > considers itself unable to rectify past mistakes? "First"? Before... what, figuring out how to use IPsec in softwires? I think the applications that Sam was talking about (e.g., iSCSI, I think) and softwires are sufficiently different that fixing those applications should have no impact on the softwares w/ IPsec work, thus there'd be no benefit to fixing those applications first. Nico -- From shanna@juniper.net Mon Jul 31 15:50:31 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k6VJoVkc002454 for ; Mon, 31 Jul 2006 15:50:31 -0400 Received: from borg.juniper.net (borg.juniper.net [207.17.137.119]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k6VJoRK1020709; Mon, 31 Jul 2006 15:50:27 -0400 (EDT) Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 31 Jul 2006 12:50:30 -0700 X-IronPort-AV: i="4.07,199,1151910000"; d="scan'208"; a="572916140:sNHT46238500" x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 31 Jul 2006 15:50:36 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] IETF 66 NEA BOF Summary Thread-Index: AcalKRfO+PMqaWq2RTmBQ4LOO4SLUgBWMNIwAAJvx3ADYxPloAAkOBwQ From: "Stephen Hanna" To: "Khosravi, Hormuzd M" , , "Russ Housley" , "Sam Hartman" , X-Spam-Score: 0 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id k6VJoVkc002454 Subject: Re: [saag] [Nea] IETF 66 NEA BOF Summary X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 19:50:31 -0000 Sorry for the gap in communications. Travel slowed things down. Susan and I are working on the revised charter. I hope we'll have something back to the NEA list within a few weeks. The timeline for an eventual IESG decision is more uncertain but I expect it would not be more than a month or two. Thanks, Steve -----Original Message----- From: Khosravi, Hormuzd M [mailto:hormuzd.m.khosravi@intel.com] Sent: Sunday, July 30, 2006 4:39 PM To: Stephen Hanna; nea@ietf.org; Russ Housley; Sam Hartman; saag@mit.edu Subject: RE: [Nea] IETF 66 NEA BOF Summary Hi Steve Any news on the formation of the WG? By when will we get the final word? The BoF was successful, but we haven't heard of anything after that. Thanks Hormuzd -----Original Message----- From: Stephen Hanna [mailto:shanna@juniper.net] Sent: Thursday, July 13, 2006 8:06 AM To: nea@ietf.org; Russ Housley; Sam Hartman; saag@mit.edu Subject: [Nea] IETF 66 NEA BOF Summary Summary of NEA BOF at IETF 66 The NEA BOF focussed on discussing and agreeing on a charter for a potential NEA WG. As part of this, there was considerable discussion of the NEA use case, architecture, and scope. The session was well attended (more than 100 people). Many good questions and issues were raised, all in a constructive manner. These concerns will be reviewed to determine whether architectural changes may be needed. At the end of the session, rough consensus was reached on a revised scope. The scope in the previously proposed charter will be modified to require that the WG identify a Mandatory To Implement transport (which may be developed by another WG). Also, vendor attributes would be required to be documented in an RFC. And the protocols developed must be designed to accomodate emerging technologies for addressing lying endpoints. With these changes, rough consensus was reached that the IETF should create a WG with this scope and the previously proposed goals. A substantial number of BOF participants indicated they would help edit and author documents. The BOF chairs will work with the ADs, the mailing list, and others to prepare a revised charter reflecting the BOF's rough consensus. This charter will be submitted to the IESG for consideration. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From vishwas.ietf@gmail.com Tue Aug 15 02:18:42 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k7F6Ig1O022122 for ; Tue, 15 Aug 2006 02:18:42 -0400 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k7F6Ilsp029657 for ; Tue, 15 Aug 2006 02:18:47 -0400 (EDT) X-Barracuda-Connect: wx-out-0506.google.com[66.249.82.233] X-Barracuda-Start-Time: 1155622724 Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.233]) by mit.edu (Spam Firewall) with ESMTP id A2E71CBEDB for ; Tue, 15 Aug 2006 02:18:44 -0400 (EDT) Received: by wx-out-0506.google.com with SMTP id t11so128945wxc for ; Mon, 14 Aug 2006 23:18:44 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=bQO31KnhRAcHB+mslDyBvdgWPMpKGHrBXyTM1AFUd7nE1oSzrP93M5r5snX6pWnjkTrpcl4gl2/4Q/fzZo5YIl66Sfo/CHtjhQylEYxA0a3oPSPb3oYg1Uh1H00nBw017TAVgXOjwyOSE5+MIOHGfd4yr38FEvDqs9unUizL45w= Received: by 10.70.77.2 with SMTP id z2mr11231948wxa; Mon, 14 Aug 2006 23:18:44 -0700 (PDT) Received: by 10.70.33.3 with HTTP; Mon, 14 Aug 2006 23:18:44 -0700 (PDT) Message-ID: <77ead0ec0608142318r1805433ci466838b0dcff03e6@mail.gmail.com> Date: Tue, 15 Aug 2006 11:48:44 +0530 From: "Vishwas Manral" To: saag@mit.edu MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_45105_28146549.1155622724225" X-Barracuda-Virus-Scanned: by Barracuda Spam Firewall at edu X-Spam-Score: 0.12 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] Checksum and Md5/ SHA-1 hashing X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2006 06:18:42 -0000 ------=_Part_45105_28146549.1155622724225 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi folks, In a lot of specs for control protocols I figured out that, in case Hash based authentication is done using MD5/ SHA-1 etc, the checksum field which is in the content of the packet (so as to be able to detect data corruption), is not used for hashing at all and not calculated at all. This is because the hash algorithms themselves provide a mechanism to detect any data corruption. What I am proposing is that if we have checksum in the packet and the checksum is part of the hash calculations. It helps reduce the effects of collision. I am attaching the draft, which I have not yet posted. Do let me know what you think? Thanks, Vishwas ------=_Part_45105_28146549.1155622724225 Content-Type: text/plain; name="draft-manral-security-hash-collision-issues-00.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-manral-security-hash-collision-issues-00.txt" X-Attachment-Id: f_eqvvx1f9 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICANCg0KTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgVi4gTWFucmFsDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIElQIEluZnVzaW9uLCBJbmMNCkV4cGlyZXM6IEZl YnJ1YXJ5IDE0LCAyMDA3ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0K DQoNCg0KDQoNCiAgICAgICAgICAgICAgICAgICAgIENoZWNrc3VtIGZpZWxkIGluIHBhY2tldHMg bWluaW1pemVzIGlzc3VlcyBjYXVzZWQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIGJ5IGNvbGxpc2lvbiANCiAgICAgICAgICAgICAgICAgICAgICAgZHJhZnQtbWFucmFsLXNl Y3VyaXR5LWhhc2gtY29sbGlzaW9uLWlzc3Vlcy0wMA0KDQpTdGF0dXMgb2YgdGhpcyBNZW1vDQoN CiAgIEJ5IHN1Ym1pdHRpbmcgdGhpcyBJbnRlcm5ldC1EcmFmdCwgZWFjaCBhdXRob3IgcmVwcmVz ZW50cyB0aGF0IGFueQ0KICAgYXBwbGljYWJsZSBwYXRlbnQgb3Igb3RoZXIgSVBSIGNsYWltcyBv ZiB3aGljaCBoZSBvciBzaGUgaXMgYXdhcmUNCiAgIGhhdmUgYmVlbiBvciB3aWxsIGJlIGRpc2Ns b3NlZCwgYW5kIGFueSBvZiB3aGljaCBoZSBvciBzaGUgYmVjb21lcw0KICAgYXdhcmUgd2lsbCBi ZSBkaXNjbG9zZWQsIGluIGFjY29yZGFuY2Ugd2l0aCBTZWN0aW9uIDYgb2YgQkNQIDc5Lg0KDQog ICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBF bmdpbmVlcmluZw0KICAgVGFzayBGb3JjZSAoSUVURiksIGl0cyBhcmVhcywgYW5kIGl0cyB3b3Jr aW5nIGdyb3Vwcy4gIE5vdGUgdGhhdA0KICAgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1 dGUgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtDQogICBEcmFmdHMuDQoNCiAgIEludGVy bmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4 IG1vbnRocw0KICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5 IG90aGVyIGRvY3VtZW50cyBhdCBhbnkNCiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRv IHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlDQogICBtYXRlcmlhbCBvciB0byBjaXRl IHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iDQoNCiAgIFRoZSBsaXN0IG9m IGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAgaHR0cDovL3d3 dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0Lg0KDQogICBUaGUgbGlzdCBvZiBJbnRl cm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMgY2FuIGJlIGFjY2Vzc2VkIGF0DQogICBodHRw Oi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sLg0KDQogICBUaGlzIEludGVybmV0LURyYWZ0IHdp bGwgZXhwaXJlIG9uIEp1bHkgMTQsIDIwMDcuDQoNCkNvcHlyaWdodCBOb3RpY2UNCg0KICAgQ29w eXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAoMjAwNikuDQoNCkFic3RyYWN0DQoNCiAg IEEgbG90IG9mIHByb3RvY29scyBzdXBwb3J0IHRoZSBjaGVja3N1bSBmaWVsZCB0byBkZXRlY3Qg Y29ycnVwdGlvbiBvZg0KICAgY29udGVudCB0byB0aGUgcGFja2V0cy4gDQoNCiAgIEhhdmluZyB0 aGUgY2hlY2tzdW0gZmllbGQgaW4gdGhlIHBhY2tldCBjb250ZW50LCBldmVuIHdoZW4gZG9pbmcg DQogICBhdXRoZW50aWNhdGlvbiBjYW4gZ3JlYXRseSByZWR1Y2UgdGhlIGVmZmVjdHMgb2YgaGFz aCBjb2xsaXNpb24gZGV0ZWN0ZWQgaW4NCiAgIGF1dGhlbnRpY2F0aW9uIHByb3RvY29scyBsaWtl IE1ENSBhbmQgU0hBLTEuDQoNCk1hbnJhbCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAxXQ0KDA0KSU5URVJORVQtRFJB RlQgICAgICAgICBDaGVja3N1bSBmaWVsZCBpbiBwYWNrZXRzICAgICAgICAgIEF1Z3VzdCwgMjAw Ng0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoN ClJlcXVpcmVtZW50cyBMYW5ndWFnZQ0KDQogICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1Qg Tk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsDQogICAiU0hPVUxEIiwgIlNI T1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJT05BTCIgaW4gdGhpcw0K ICAgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBSRkMgMjEx OSBbUkZDMjExOV0uDQoNCg0KDQoNCjEuICBQcm9ibGVtIFN0YXRlbWVudA0KDQogICBBIGxvdCBv ZiBjb250cm9sIHByb3RvY29scyB1c2UgY2hlY2tzdW0gZmllbGRzIGluIHBhY2tldHMgdG8gZW5h YmxlIA0KICAgdGhlIHJlY2VpdmVyIG9mIHRoZSBwYWNrZXQgdG8gZGV0ZWN0IHBhY2tldCBjb3Jy dXB0aW9uLiBUaGUgY2hlY2tzdW0gDQogICBhbGdvcml0aG0gZ2VuZXJhbGx5IHVzZWQgaXMgdGhl IENSQy4gDQoNCiAgIFRoZSBzYW1lIHByb3RvY29scyBhbHNvIHByb3ZpZGVzIGZvciBhdXRoZW50 aWNhdGlvbiBvZiB0aGUgcm91dGluZyANCiAgIHVwZGF0ZXMuIFRoZSBwcm90b2NvbHMgdXNlZCBm b3IgY2FsY3VsYXRpbmcgYSBoYXNoIHVzZWQgZm9yIHN1Y2ggDQogICBhdXRoZW50aWNhdGlvbiBp bmNsdWRlIE1ENSwgU0hBLTEsIFNIQS0yNTYgZXRjLg0KDQogICBIb3dldmVyIGEgbG90IG9mIHRo ZSBwcm90b2NvbHMgZG8gbm90IHVzZSB0aGUgY2hlY2tzdW0gZmllbGQsIA0KICAgd2hpbGUgY2Fs Y3VsYXRpbmcgdGhlIGF1dGhlbnRpY2F0aW9uIGhhc2guIEluc3RlYWQgaWYgdGhlIGhhc2ggZmll bGQgDQogICBpbmNsdWRlcyB0aGUgcGFja2V0IGNoZWNrc3VtLCB0aGUgaGFzaCBlZmZlY3Qgb2Yg aGFzaCBjb2xsaXNpb24gY2FuIGJlIA0KICAgZ3JlYXRseSByZWR1Y2VkLg0KDQoNCjIuICBIYXNo IENvbGxpc2lvbiBhbmQgcG9zc2libGUgYXRhdGNrcw0KDQogICAgQSBoYXNoIGNvbGxpc2lvbiBv Y2N1cnMgaW4gYSBzaXR1YXRpb24gdGhhdCBvY2N1cnMgd2hlbiB0d28gZGlzdGluY3QNCiAgICBp bnB1dHMgaW50byBhIGhhc2ggZnVuY3Rpb24gcHJvZHVjZSBpZGVudGljYWwgb3V0cHV0cy4gDQoN CiAgICBJbiB0aGUgY3J5cHRvZ3JhcGhpYyBhdXRoZW50aWNhdGlvbiBzY2hlbWUsIHRoZSByb3V0 ZXJzIG9uIGEgDQogICAgY29tbW9uIG5ldHdvcmsvc3VibmV0IHNoYXJlIGEgc2VjcmV0IGtleSB3 aGljaCBpcyB1c2VkIHRvIGdlbmVyYXRlIGEgDQogICAga2V5ZWQgaGFzaCBkaWdlc3QgZm9yIGVh Y2ggcGFja2V0LiANCiAgICANCiAgICBUaGlzIGlzbid0IGdvb2QgZW5vdWdoIGFzIHRoZXJlIGhh dmUgcmVjZW50bHkgYmVlbiByZXBvcnRzIGFib3V0IA0KICAgIGF0dGFja3Mgb24gdGhlIGNvbGxp c2lvbiByZXNpc3RhbmNlIHByb3BlcnRpZXMgb2YgTUQ1IFtNRDUtYXR0YWNrXSANCiAgICBhbmQg U0hBLTEgW1JGQzMxNzRdW1NIQS0xLWF0dGFja10gaGFzaCBmdW5jdGlvbnMuIE1ENUNSSywgd2Fz IGEgDQogICAgZGlzdHJpYnV0ZWQgY29tcHV0aW5nIHByb2plY3QgdG8gYnJlYWsgdGhlIE1ENSBo YXNoIGFsZ29yaXRobSBpbiBhIA0KICAgIHNob3J0IHBlcmlvZCBvZiB0aW1lLiBUaGUgcHJvamVj dCBjbG9zZWQgZG93biB3aXRoIHRoZSBwdWJsaWNhdGlvbiBvZiANCiAgICB0aGUgcGFwZXIgW01E NS1hdHRhY2tdLiANCiAgDQogICAgSXQgd2FzIGRpc2NvdmVyZWQgdGhhdCBjb2xsaXNpb25zIGNh biBiZSBmb3VuZCBpbiBNRDUgYWxnb3JpdGhtIGluIA0KICAgIGxlc3MgdGhhbiAyNCBob3Vycywg bWFraW5nIE1ENSB2ZXJ5IGluc2VjdXJlLiBGdXJ0aGVyIHJlc2VhcmNoIGhhcyANCiAgICB2ZXJp ZmllZCB0aGlzIHJlc3VsdCBhbmQgc2hvd24gb3RoZXIgd2F5cyB0byBmaW5kIGNvbGxpc2lvbnMg aW4gTUQ1IA0KICAgIGhhc2hlcy4gIA0KIA0KICAgDQoNCk1hbnJhbCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAyXQ0K DA0KSU5URVJORVQtRFJBRlQgICAgICAgICBDaGVja3N1bSBmaWVsZCBpbiBwYWNrZXRzICAgICAg ICAgIEF1Z3VzdCwgMjAwNg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIA0KDQoNCjUuIFByb3Bvc2VkIHNvbHV0aW9uIHRvIHRoZSBwcm9ibGVtDQoNCiAg IENvbnRyb2wgcHJvdG9jb2xzIHdoaWNoIGhhdmUgY2hlY2tzdW0gZmllbGQgY3VycmVudGx5IGRv IG5vdCB1c2UgdGhlDQogICBjaGVja3N1bSBmaWVsZCBpbiB0aGUgcGFja2V0IHRvIGNvbXB1dGUg dGhlIGF1dGhlbnRpY2F0aW9uIGhhc2ggb2YgdGhlIA0KICAgcGFja2V0LiBUaGUgY2hlY2tzdW0g ZmllbGQgaXMgbm90IGNhbGN1bGF0ZWQgd2hlbiBjYWxjdWxhdGluZyB0aGUgcGFja2V0DQogICBo YXNoLg0KDQogICBVc2luZyB0aGUgY29ycmVjdCBjaGVja3N1bSBmaWVsZCB3aGVuIGNhbGN1bGF0 aW5nIHRoZSBoYXNoIGNhbiBncmVhdGx5DQogICByZWR1Y2UgdGhlIGVmZmVjdHMgb2YgY29sbGlz aW9uLiBVc2luZyB0aGUgY2hlY2tzdW0gcHJvdmlkZXMgYQ0KDQo2LiBEZXRhaWxzIG9mIHRoZSBz b2x1dGlvbg0KDQogICBBc3N1bWUgYSBwYWNrZXQgd2l0aCBjb250ZW50IE0uIFRoZSBoYXNoIG9m IHRoZSBwYWNrZXQgaXMgY2FsY3VsYXRlZCB1c2luZw0KICAgdGhlIGhhc2ggYWxnb3JpdGhtICJI QVNIIiwgdXNpbmcgdGhlIGtleSBvZiB2YWx1ZSAiayIuDQoNCiAgIEggPSBIQVNIIGsgKE0pDQoN CiAgIHdoZXJlIEggaXMgdGhlIG91dHB1dCBvZiB0aGUgaGFzaCBmdW5jdGlvbi4NCg0KICAgQ29s bGlzaW9uIHJlc2lzdGFuY2UgbWVhbnMgdGhhdCBpdCBpcyBpbmZlYXNpYmxlIHRvIGZpbmQgdHdv IGRpZmZlcmVudCBpbnB1dHMNCiAgIE0gYW5kIE0nIHdpdGggdGhlIHNhbWUgaGFzaCBIQVNIIChN KSA9IEhBU0ggKE0nKS4gDQoNCiAgIEl0IGlzIHRob3VnaHQgdGhhdCBpdCBpcyBwb3NzaWJsZSB0 byBmaW5kIGEgY29sbGlzaW9uIGluIFNIQS0xIGluIDJeNjMgb3BlcmF0aW9ucy4NCiAgIEJlc2lk ZXMgMl42MyBpcyB3aXRoaW4gcmVhY2ggb2YgYSBkaXN0cmlidXRlZCBjb21wdXRpbmcgZWZmb3J0 LiBJdCB3aWxsIG5vdCBiZQ0KICAgc3VycHJpc2luZyBpZiBmdXJ0aGVyIGltcHJvdmVtZW50cyB0 byBTSEEtMSBjb2xsaXNpb24gYXR0YWNrcyBhcHBlYXIgaW4gdGhlDQogICBjb21pbmcgbW9udGhz LltXWVldIA0KDQogICBBc3N1bWluZyBhIDMyIGJpdCBjaGVja3N1bSBmaWVsZCBpbiB0aGUgbWVz c2FnZSwgd2hpY2ggaXMgcGFydCBvZiB0aGUgY29udGVudA0KICAgb2YgdGhlIHBhY2tldC4NCg0K ICAgQXNzdW1lIHRoYXQgYSBjb2xsaXNpb24gb2NjdXJzIGluIDJeWCBhdHRlbXB0cyBmb3IgYSBw YXJ0aWN1bGFyIEhhc2ggYWxnb3JpdGhtLiANCiAgIEFzIHRoZSBjb250ZW50IG92ZXIgd2hpY2gg dGhlIEhhc2ggaXMgY2FsY3VsYXRlZCBpbiBzdWNoIGEgY2FzZSBpcyB0b3RhbGx5IA0KICAgcmFu ZG9tLiBUaGUgY2hlY2tzdW0gZmllbGQgaW4gdGhpcyBjYXNlIHdvdWxkIGJlIG9uZSBvZiAwIHRv IDJeMzIgLSAxLiBUaGUgDQogICB2YWx1ZSBvZiB0aGUgY2hlY2tzdW0gaW4gc3VjaCBhIGNhc2Ug d291bGQgYmUgY29ycmVjdCBpbiBvbmx5IDEgb2YgdGhlIDJeIDMyIA0KICAgY2FzZXMuIFRoaXMg d291bGQgbWVhbiB0aGF0IDEgb2YgdGhlIDJeMzIgYXR0ZW1wdHMgdGhhdCByZXN1bHQgaW4gYSBj b2xsaXNpb24NCiAgIHdpbGwgYWxzbyByZXN1bHQgaW4gdGhlIGNvcnJlY3QgY2hlY2tzdW0uDQoN CiAgIFRoaXMgbWVhbnMgdGhhdCB0aGUgbnVtYmVyIG9mIGF0dGVtcHRzIHdvdWxkIGJlICAyIF4g KDMyICsgWCkuIEZvciBTSEEtMSBpdCB3b3VsZA0KICAgYmUgMiBeICgzMiArIDYyKS4NCg0KICAg Q2hlY2tzdW0gdGh1cyBwcm92aWRlcyBhIHNlY29uZCBmYWN0b3Igb2Ygc2VjdXJpdHkuIFRoaXMg Z3JlYXRseSByZWR1Y2VzIHRoZSANCiAgIGVmZmVjdCBvZiBjb2xsaXNpb24gYXR0YWNrcy4NCg0K ICANCg0KNy4gIElBTkEgQ29uc2lkZXJhdGlvbnMNCg0KICAgVGhpcyBkb2N1bWVudCBtYWtlcyBu byByZXF1ZXN0IG9mIElBTkEuDQoNCiAgIE5vdGUgdG8gUkZDIEVkaXRvcjogdGhpcyBzZWN0aW9u IG1heSBiZSByZW1vdmVkIG9uIHB1YmxpY2F0aW9uIGFzIGFuDQogICBSRkMuDQoNCg0KDQoNCg0K DQoNCk1hbnJhbCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBbUGFnZSAzXQ0KDA0KSU5URVJORVQtRFJBRlQgICAgICAgICBDaGVj a3N1bSBmaWVsZCBpbiBwYWNrZXRzICAgICAgICAgIEF1Z3VzdCwgMjAwNg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNCg0KOC4gIFNlY3VyaXR5 IENvbnNpZGVyYXRpb25zDQoNCiAgIFRoaXMgZHJhZnQgb3V0bGluZXMgc2VjdXJpdHkgaXNzdWVz IHRoYXQgYXJpc2UgZHVlIHRvIGNvbGxpc2lvbiBvZiBoYXNoIA0KICAgZnVuY3Rpb25zLiBJdCBk ZXRhaWxzIHRoZSBzb2x1dGlvbiBmb3IgcmVkdWNpbmcgdGhlIGVmZmVjdCBvZiBhIGNvbGxpc2lv bi4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpNYW5yYWwgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1Bh Z2UgNF0NCgwNCklOVEVSTkVULURSQUZUICAgICAgICAgQ2hlY2tzdW0gZmllbGQgaW4gcGFja2V0 cyAgICAgICAgICBBdWd1c3QsIDIwMDYNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICANCg0KOS4gIEFja25vd2xlZGdlbWVudHMNCiAgICAgDQogICBUQkQN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KTWFucmFsICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDVd DQoMDQpJTlRFUk5FVC1EUkFGVCAgICAgICAgIENoZWNrc3VtIGZpZWxkIGluIHBhY2tldHMgICAg ICAgICAgQXVndXN0LCAyMDA2DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgDQoNCg0KMTAuICBSZWZlcmVuY2VzDQoNCjEwLjEgIEluZm9ybWF0aXZlIFJl ZmVyZW5jZXMNCg0KICBbV1lZXSBYLiBXYW5nLCBZLkwuIFlpbiwgYW5kIEguIFl1LiwgRmluZGlu ZyBDb2xsaXNpb25zIGluIHRoZSBGdWxsIFNIQS0xLCANCiAgICAgICAgQWR2YW5jZXMgaW4gQ3J5 cHRvbG9neSAtLSBDcnlwdG8nMDUuDQoNCiAgIFtNRDUtYXR0YWNrXSAgIFdhbmcsIFguIGV0IGFs LiwgIkNvbGxpc2lvbnMgZm9yIEhhc2ggRnVuY3Rpb25zIE1ENCwgICANCiAgICAgICAgICAgICAg ICAgIE1ENSwgSEFWQUwtMTI4IGFuZCBSSVBFTUQiLCBBdWd1c3QgMjAwNCwgIA0KICAgICAgICAg ICAgICAgICAgaHR0cDovL2VwcmludC5pYWNyLm9yZy8yMDA0LzE5OSAgDQogICAgDQogICBbUkZD MzE3NF0gICAgICBFYXN0bGFrZSAzcmQsIEQuLEpvbmVzLCBQLiwgIlVTIFNlY3VyZSBIYXNoIEFs Z29yaXRobSAgDQogICAgICAgICAgICAgICAgICAxIChTSEExKSIsIFJGQyAzMTc0LCBTZXB0ZW1i ZXIgMjAwMS4gICAgIA0KICAgICAgICANCiAgIFtTSEEtMS1hdHRhY2tdIFdhbmcsIFguIGV0IGFs LiwgIkNvbGxpc2lvbiBTZWFyY2ggQXR0YWNrcyBvbiBTSEExIiwgIA0KICAgICAgICAgICAgICAg ICAgRmVicnVhcnkgMjAwNSwgIA0KICAgICAgICAgICAgICAgICAgaHR0cDovL3RoZW9yeS5jc2Fp bC5taXQuZWR1L355aXF1bi9zaGFub3RlLnBkZiAgDQoNCg0KDQpBdXRob3JzJyBBZGRyZXNzZXMN Cg0KICAgVmlzaHdhcyBNYW5yYWwNCiAgIElQIEluZnVzaW9uIENvcnAsDQogICBCYW5nYWxvcmUN CiAgIEluZGlhDQoNCiAgIFBob25lOiArOTEtODAtNDExMy0xMjY4DQogICAgICAgICAgKzEtNDA4 LTc5NC0xNTE2DQogICBFbWFpbDogdmlzaHdhc0BpcGluZnVzaW9uLmNvbQ0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpNYW5yYWwgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgNl0NCgwNCklOVEVS TkVULURSQUZUICAgICAgICAgQ2hlY2tzdW0gZmllbGQgaW4gcGFja2V0cyAgICAgICAgICBBdWd1 c3QsIDIwMDYNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICANCg0KDQpJbnRlbGxlY3R1YWwgUHJvcGVydHkgU3RhdGVtZW50DQoNCiAgIFRoZSBJRVRGIHRh a2VzIG5vIHBvc2l0aW9uIHJlZ2FyZGluZyB0aGUgdmFsaWRpdHkgb3Igc2NvcGUgb2YgYW55DQog ICBJbnRlbGxlY3R1YWwgUHJvcGVydHkgUmlnaHRzIG9yIG90aGVyIHJpZ2h0cyB0aGF0IG1pZ2h0 IGJlIGNsYWltZWQgdG8NCiAgIHBlcnRhaW4gdG8gdGhlIGltcGxlbWVudGF0aW9uIG9yIHVzZSBv ZiB0aGUgdGVjaG5vbG9neSBkZXNjcmliZWQgaW4NCiAgIHRoaXMgZG9jdW1lbnQgb3IgdGhlIGV4 dGVudCB0byB3aGljaCBhbnkgbGljZW5zZSB1bmRlciBzdWNoIHJpZ2h0cw0KICAgbWlnaHQgb3Ig bWlnaHQgbm90IGJlIGF2YWlsYWJsZTsgbm9yIGRvZXMgaXQgcmVwcmVzZW50IHRoYXQgaXQgaGFz DQogICBtYWRlIGFueSBpbmRlcGVuZGVudCBlZmZvcnQgdG8gaWRlbnRpZnkgYW55IHN1Y2ggcmln aHRzLiAgSW5mb3JtYXRpb24NCiAgIG9uIHRoZSBwcm9jZWR1cmVzIHdpdGggcmVzcGVjdCB0byBy aWdodHMgaW4gUkZDIGRvY3VtZW50cyBjYW4gYmUNCiAgIGZvdW5kIGluIEJDUCA3OCBhbmQgQkNQ IDc5Lg0KDQogICBDb3BpZXMgb2YgSVBSIGRpc2Nsb3N1cmVzIG1hZGUgdG8gdGhlIElFVEYgU2Vj cmV0YXJpYXQgYW5kIGFueQ0KICAgYXNzdXJhbmNlcyBvZiBsaWNlbnNlcyB0byBiZSBtYWRlIGF2 YWlsYWJsZSwgb3IgdGhlIHJlc3VsdCBvZiBhbg0KICAgYXR0ZW1wdCBtYWRlIHRvIG9idGFpbiBh IGdlbmVyYWwgbGljZW5zZSBvciBwZXJtaXNzaW9uIGZvciB0aGUgdXNlIG9mDQogICBzdWNoIHBy b3ByaWV0YXJ5IHJpZ2h0cyBieSBpbXBsZW1lbnRlcnMgb3IgdXNlcnMgb2YgdGhpcw0KICAgc3Bl Y2lmaWNhdGlvbiBjYW4gYmUgb2J0YWluZWQgZnJvbSB0aGUgSUVURiBvbi1saW5lIElQUiByZXBv c2l0b3J5IGF0DQogICBodHRwOi8vd3d3LmlldGYub3JnL2lwci4NCg0KICAgVGhlIElFVEYgaW52 aXRlcyBhbnkgaW50ZXJlc3RlZCBwYXJ0eSB0byBicmluZyB0byBpdHMgYXR0ZW50aW9uIGFueQ0K ICAgY29weXJpZ2h0cywgcGF0ZW50cyBvciBwYXRlbnQgYXBwbGljYXRpb25zLCBvciBvdGhlciBw cm9wcmlldGFyeQ0KICAgcmlnaHRzIHRoYXQgbWF5IGNvdmVyIHRlY2hub2xvZ3kgdGhhdCBtYXkg YmUgcmVxdWlyZWQgdG8gaW1wbGVtZW50DQogICB0aGlzIHN0YW5kYXJkLiAgUGxlYXNlIGFkZHJl c3MgdGhlIGluZm9ybWF0aW9uIHRvIHRoZSBJRVRGIGF0DQogICBpZXRmLWlwckBpZXRmLm9yZy4N Cg0KDQpEaXNjbGFpbWVyIG9mIFZhbGlkaXR5DQoNCiAgIFRoaXMgZG9jdW1lbnQgYW5kIHRoZSBp bmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGFyZSBwcm92aWRlZCBvbiBhbg0KICAgIkFTIElT IiBiYXNpcyBhbmQgVEhFIENPTlRSSUJVVE9SLCBUSEUgT1JHQU5JWkFUSU9OIEhFL1NIRSBSRVBS RVNFTlRTDQogICBPUiBJUyBTUE9OU09SRUQgQlkgKElGIEFOWSksIFRIRSBJTlRFUk5FVCBTT0NJ RVRZIEFORCBUSEUgSU5URVJORVQNCiAgIEVOR0lORUVSSU5HIFRBU0sgRk9SQ0UgRElTQ0xBSU0g QUxMIFdBUlJBTlRJRVMsIEVYUFJFU1MgT1IgSU1QTElFRCwNCiAgIElOQ0xVRElORyBCVVQgTk9U IExJTUlURUQgVE8gQU5ZIFdBUlJBTlRZIFRIQVQgVEhFIFVTRSBPRiBUSEUNCiAgIElORk9STUFU SU9OIEhFUkVJTiBXSUxMIE5PVCBJTkZSSU5HRSBBTlkgUklHSFRTIE9SIEFOWSBJTVBMSUVEDQog ICBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBPUiBGSVRORVNTIEZPUiBBIFBBUlRJQ1VM QVIgUFVSUE9TRS4NCg0KDQpDb3B5cmlnaHQgU3RhdGVtZW50DQoNCiAgIENvcHlyaWdodCAoQykg VGhlIEludGVybmV0IFNvY2lldHkgKDIwMDUpLiAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0DQog ICB0byB0aGUgcmlnaHRzLCBsaWNlbnNlcyBhbmQgcmVzdHJpY3Rpb25zIGNvbnRhaW5lZCBpbiBC Q1AgNzgsIGFuZA0KICAgZXhjZXB0IGFzIHNldCBmb3J0aCB0aGVyZWluLCB0aGUgYXV0aG9ycyBy ZXRhaW4gYWxsIHRoZWlyIHJpZ2h0cy4NCg0KDQpBY2tub3dsZWRnbWVudA0KDQogICBGdW5kaW5n IGZvciB0aGUgUkZDIEVkaXRvciBmdW5jdGlvbiBpcyBjdXJyZW50bHkgcHJvdmlkZWQgYnkgdGhl DQogICBJbnRlcm5ldCBTb2NpZXR5Lg0KDQoNCk1hbnJhbCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSA3XQ0KDQoNCg== ------=_Part_45105_28146549.1155622724225-- From nw141292@binky.Central.Sun.COM Tue Aug 15 18:45:53 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k7FMjqVW001113 for ; Tue, 15 Aug 2006 18:45:52 -0400 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k7FMk1w2013102 for ; Tue, 15 Aug 2006 18:46:02 -0400 (EDT) X-Barracuda-Connect: nwkea-mail-5.sun.com[192.18.42.27] X-Barracuda-Start-Time: 1155681961 Received: from nwkea-mail-5.sun.com (nwkea-mail-5.sun.com [192.18.42.27]) by mit.edu (Spam Firewall) with ESMTP id 746353DEA3 for ; Tue, 15 Aug 2006 18:46:01 -0400 (EDT) Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by nwkea-mail-5.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7FMjutC027910 for ; Tue, 15 Aug 2006 15:46:00 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k7FMjsXk001146 for ; Tue, 15 Aug 2006 16:45:55 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7FMjsP8006840; Tue, 15 Aug 2006 17:45:54 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7FMjsO0006839; Tue, 15 Aug 2006 17:45:54 -0500 (CDT) Date: Tue, 15 Aug 2006 17:45:54 -0500 From: Nicolas Williams To: ietf-sasl@imc.org, kitten@ietf.org, nfsv4@ietf.org Message-ID: <20060815224553.GD4099@binky.Central.Sun.COM> Mail-Followup-To: ietf-sasl@imc.org, kitten@ietf.org, nfsv4@ietf.org, saag@mit.edu References: <20060815150854.GM4099@binky.Central.Sun.COM> <20060815194615.GT4099@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060815194615.GT4099@binky.Central.Sun.COM> User-Agent: Mutt/1.5.7i X-Barracuda-Virus-Scanned: by Barracuda Spam Firewall at edu X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] draft-williams-on-channel-binding-00.txt is in the I-D repository X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2006 22:45:53 -0000 On Tue, Aug 15, 2006 at 02:46:15PM -0500, Nicolas Williams wrote: > What mailing list would be approapriate to host reviews of this draft? > > NFSv4's does not seem apropriate, but then, neither do the other two > (SASL, KITTEN). Perhaps SASL, because we've been discussing channel > binding issues in the context of SASL/GS2 there. Sam suggests the SAAG list (duh!). Reply-to set. Nico -- From jas@extundo.com Wed Aug 16 04:47:37 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k7G8lbuV030904 for ; Wed, 16 Aug 2006 04:47:37 -0400 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k7G8lknl025980 for ; Wed, 16 Aug 2006 04:47:46 -0400 (EDT) X-Barracuda-Connect: 178.230.13.217.in-addr.dgcsystems.net[217.13.230.178] X-Barracuda-Start-Time: 1155718045 X-Barracuda-Encrypted: DHE-RSA-AES256-SHA Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 09CF32A92A for ; Wed, 16 Aug 2006 04:47:26 -0400 (EDT) Received: from localhost.localdomain (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k7G8lC7j008584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 16 Aug 2006 10:47:18 +0200 X-Hashcash: 1:22:060816:saag@mit.edu::V4ST3GqQy9E6MG5D:RQJU From: Simon Josefsson To: saag@mit.edu References: <20060815150854.GM4099@binky.Central.Sun.COM> <87ac663pzs.fsf@latte.josefsson.org> <20060815173622.GQ4099@binky.Central.Sun.COM> <87wt993kam.fsf@latte.josefsson.org> <20060815192759.GR4099@binky.Central.Sun.COM> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:060816:kitten@ietf.org::Pi3rc6qpJ5zv/ExE:2Sma X-Hashcash: 1:22:060816:ietf-sasl@imc.org::A33COEKdlIX7P3uV:2hc7 X-Hashcash: 1:22:060816:nfsv4@ietf.org::c6eVzp0M0e5eIZMC:9Bxy Date: Wed, 16 Aug 2006 10:47:12 +0200 In-Reply-To: <20060815192759.GR4099@binky.Central.Sun.COM> (Nicolas Williams's message of "Tue, 15 Aug 2006 14:28:00 -0500") Message-ID: <87odul2hkf.fsf@latte.josefsson.org> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on yxa-iv X-Virus-Status: Clean X-Barracuda-Virus-Scanned: by Barracuda Spam Firewall at edu X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: Re: [saag] draft-williams-on-channel-binding-00.txt is in the I-D repository X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2006 08:47:37 -0000 I'm moving this discussion from SASL+Kitten+NFSv4 to SAAG, as suggested by Sam. Nicolas Williams writes: > On Tue, Aug 15, 2006 at 08:50:41PM +0200, Simon Josefsson wrote: >> Nicolas Williams writes: >> >> [...] >> I'm using IMAP with SASL over TLS over port-forwarded SSH to read my >> mail every day, and I imagine this (TLS over VPN) isn't too uncommon. >> Adding IPSEC doesn't seem entirely far fetched, especially if >> usability of IPSEC improves. > > VPNs aren't "channels" as far as this spec goes. They're not end2end Perhaps I was using the term VPN improperly. I meant host-based VPNs, such as SSH port-forwarding between the mail client host and the mail server, or TLS-based host-to-host VPNs. After re-reading the definition of "secure channel" in the document, I don't understand how those would differ from, e.g., IPSEC between the mail client host and the mail server. Being able to bind to a SSH or TLS-based VPN channel might be acceptable, especially considering the alternative of using GSS_Wrap, so maybe we should consider relaxing the definition of "channel". >> > It seems to me that the right thing would be to bind each channel to the >> > one below, so here the SSHv2 channel would be bound to the IPsec >> > channel, and the TLS channel to the SSHv2 channel and SASL/GS2 to the >> > TLS channel, and the only channel that would provide cryptographic >> > session protection would be IPsec. >> >> Sounds OK to me, but I'm not sure it is the only solution. > > I think it's the simplest, if indeed this is what you want and if the > SSHv2 session ID can be obtained by both, the IMAP client and the IMAP > server. As it is you called it a VPN, which, IMO, rules channel binding > out. I'm not sure I see the difference between how the IMAP server would get the channel binding from a VPN and from IPSEC. >> > And with port-forwarding the channel binding to SSHv2 would require that >> > the TLS peers know about the SSHv2 channel and its session ID, at which >> > point one might dispense with TLS altogether and just use SASL/GS2 with >> > channel binding to SSHv2 >> >> Implementing all this seems complex. Applications or TLS libraries >> typically have no idea that it is running over SSH port-forwarding. > > You'd have to make them aware of what's below. That's one of the > problems with channel binding to IPsec: the lack of a) IPsec channels, > b) IPsec APIs relevant to IPsec channels. > > Yes, channel binding requires new interfaces. You've discovered this > already in the context of TLS. But it's a generic requirement: any > channel you might want to bind to has to export its channel bindings, > a minimum of information about what security services it provides, and > maybe even more (see security considerations text about cryptographic > profiles). Right. They probably have to export some information that lets the application makes sure the connection actually originated from that secure channel too. E.g., in the case of IPSEC, the application must make sure the connection came from a IPSEC protected interface, or similar. Which is the same for the host-based VPNs I'm talking about above. >> > Also, we'd have to explain how to bind TLS and SSHv2 to other channels... >> >> ...that seem to require some additional specification work. > > But noone is asking for that. I'll wait for you to digest my comment > about VPNs before counting you as wanting TLS/SSHv2 channel binding. I realize binding to VPN channels may be out of scope, but it appears to me that it would not be difficult to make our solution apply to them as well. Another approach, that avoids TLS/SSHv2 channel bindings, would for the channel bindings used by GS2 be [TLS channel bindings]|[SSH channel bindings]|[IPSEC channel bindings]. The application would be responsible for collecting that data from the appropriate layer. However, the problem is how the client and server negotiate which channels to bind to. >> [...] >> >> SSH host keys are usually verified out of band, if I'm not mistaken. > > Irrelevant for either of the two types of channel bindings described in > the draft: a) because an MITM can't obtain the private key to a server's > host public key and this public key is worked into the session ID > computation, b) because SSHv2 uses ephemeral-ephemeral Diffie-Hellman > for key exchange and the result of the initial key exchange too is > worked into the session ID computation. > > So whether you're using an SSHv2 host public key or an SSHv2 session ID > as a channel binding an MITM cannot make this binding agree for both, > its connection to the client and its connection to the server. > >> I think authentication of (the source to) keying material in TLS-PSK >> and TLS-OpenPGP also happens out of band. > > Irrelevant, for similar reasons. Agreed. /Simon From jaltman@columbia.edu Wed Aug 16 08:39:28 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k7GCdSbi008716 for ; Wed, 16 Aug 2006 08:39:28 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k7GCdXcO013822 for ; Wed, 16 Aug 2006 08:39:33 -0400 (EDT) X-Barracuda-Connect: brinza.cc.columbia.edu[128.59.29.8] X-Barracuda-Start-Time: 1155731973 X-Barracuda-Encrypted: DHE-RSA-AES256-SHA Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 4A3812DD238 for ; Wed, 16 Aug 2006 08:39:33 -0400 (EDT) Received: from [70.195.204.109] (109.sub-70-195-204.myvzw.com [70.195.204.109]) (user=jaltman mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k7GCd6u6025974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 16 Aug 2006 08:39:17 -0400 (EDT) Message-ID: <44E31249.2070506@columbia.edu> Date: Wed, 16 Aug 2006 08:40:41 -0400 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Simon Josefsson References: <20060815150854.GM4099@binky.Central.Sun.COM> <87ac663pzs.fsf@latte.josefsson.org> <20060815173622.GQ4099@binky.Central.Sun.COM> <87wt993kam.fsf@latte.josefsson.org> <20060815192759.GR4099@binky.Central.Sun.COM> <87odul2hkf.fsf@latte.josefsson.org> In-Reply-To: <87odul2hkf.fsf@latte.josefsson.org> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000302000306020103050208" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.42 X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Barracuda-Virus-Scanned: by Barracuda Spam Firewall at edu X-Spam-Score: 0.00 X-Spam-Flag: NO Cc: saag@mit.edu Subject: Re: [saag] draft-williams-on-channel-binding-00.txt is in the I-D repository X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2006 12:39:28 -0000 This is a cryptographically signed message in MIME format. --------------ms000302000306020103050208 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Simon Josefsson wrote: > Perhaps I was using the term VPN improperly. I meant host-based VPNs, > such as SSH port-forwarding between the mail client host and the mail > server, or TLS-based host-to-host VPNs. After re-reading the > definition of "secure channel" in the document, I don't understand how > those would differ from, e.g., IPSEC between the mail client host and > the mail server. > > Being able to bind to a SSH or TLS-based VPN channel might be > acceptable, especially considering the alternative of using GSS_Wrap, > so maybe we should consider relaxing the definition of "channel". Here is the problem. VPNs or SSH tunneling is designed to be transparent to the application. You, as the user who established the tunnel, are aware that they exist but from the perspective of the application they do not. The application believes that it has a direct end-to-end connection that is established using only the protocol stacks that it is aware of. In the case of IMAP/SASL over TLS over SSH over IPSec over TCP/IP, from the perspective of the application the only protocols that exist are IMAP/SASL over TLS over TCP/IP. Therefore it is impossible for the application to bind to the SSH channel. The other problem that you are experiencing in your model is that the endpoints of the SSH tunnel do not match up with the application endpoints. In order to be able to perform a binding of the TLS session to SSH channel there endpoints either need to match or you require a protocol similar to SOCKS5 that can transport the necessary endpoint binding data to the application endpoint. Without that the is nothing for the application to bind to. In the case of IPSec the endpoints are the same but at the moment there is no channel for which a name can be assigned for the purpose of performing a binding from a higher level protocol. Another of Nico's drafts is meant to provide the necessary definition of an IPSec channel and the specification of how a name can be derived. Jeffrey Altman --------------ms000302000306020103050208 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJWTCC AwcwggJwoAMCAQICEDgwMdSemBfcGd6HY5Q4qrwwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloX DTA3MDUyNzIyMDMzMlowazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRt YW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAmFluisw/ NLjjXSHm0kgAgAMBknaWpJyDQlTpyzSswiSaDWINyEUzM/teBosk003zfyQdPONkWzclBRZ+ oGsYsAgxmyRe9tAJD7Jo6xp/6kCuF5nnaIyz91gWyuYZEeqQrfyFnWIfQu3fuoSeEIMLc9ac L9qhqnaTwCufH4v56CMftv6KFdf/k1CoLu/DL0ps5UOVwui+8iSWn3Qt6QfefDp9vbtBFPTV nZ7wGeewUJrO1LEC+x3gAOW+KxUcZMBax7tVygT5hDaQXm5lxUrlMQ/hLeWpv7LkVPD/ytoJ NCNzSnycrK4juG1CI12m5K1TNHZJ1uYjb7DUvMwOl6kQiQIDAQABozEwLzAfBgNVHREEGDAW gRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GB ACNK1Xef6H2YL02xqVthcdQgFuF0bENE1u7gX/hegF1awGERhaIJmKGWau4OiAeHnlFqWysP EFzVrSb6L+TF9YHd/bP8WtxccOFnZ1L6oe7KOiyNfXGPZKj/i7Gti+MF4RM1ReZncTC1zMmZ DbFkVhL92vSgDGl4+6IwzjmQVK3sMIIDBzCCAnCgAwIBAgIQODAx1J6YF9wZ3odjlDiqvDAN BgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRp bmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0EwHhcNMDYwNTI3MjIwMzMyWhcNMDcwNTI3MjIwMzMyWjBrMQ8wDQYDVQQEEwZBbHRt YW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMTSmVmZnJleSBFcmljIEFsdG1h bjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCYWW6KzD80uONdIebSSACAAwGSdpaknINCVOnLNKzCJJoNYg3I RTMz+14GiyTTTfN/JB0842RbNyUFFn6gaxiwCDGbJF720AkPsmjrGn/qQK4XmedojLP3WBbK 5hkR6pCt/IWdYh9C7d+6hJ4Qgwtz1pwv2qGqdpPAK58fi/noIx+2/ooV1/+TUKgu78MvSmzl Q5XC6L7yJJafdC3pB958On29u0EU9NWdnvAZ57BQms7UsQL7HeAA5b4rFRxkwFrHu1XKBPmE NpBebmXFSuUxD+Et5am/suRU8P/K2gk0I3NKfJysriO4bUIjXabkrVM0dknW5iNvsNS8zA6X qRCJAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB /wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAI0rVd5/ofZgvTbGpW2Fx1CAW4XRsQ0TW7uBf+F6A XVrAYRGFogmYoZZq7g6IB4eeUWpbKw8QXNWtJvov5MX1gd39s/xa3Fxw4WdnUvqh7so6LI19 cY9kqP+Lsa2L4wXhEzVF5mdxMLXMyZkNsWRWEv3a9KAMaXj7ojDOOZBUrewwggM/MIICqKAD AgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVy biBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5n MSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZy ZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoG A1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcN AQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHy v1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsY Pge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0T AQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20v VGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQe MBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD 6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZ GwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC 3CEZNd4ksdMdRv9dX2VPMYIDZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIElzc3VpbmcgQ0ECEDgwMdSemBfcGd6HY5Q4qrwwCQYFKw4DAhoFAKCCAcMw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYwODE2MTI0MDQx WjAjBgkqhkiG9w0BCQQxFgQUeWxWRB4dlqbNLXDVofAS8UqkCwcwUgYJKoZIhvcNAQkPMUUw QzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcw DQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA4MDHUnpgX3Bneh2OUOKq8MIGHBgsqhkiG9w0B CRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA4MDHUnpgX3Bneh2OUOKq8MA0GCSqGSIb3DQEBAQUABIIBADrdz8kEEw2u4lVJ0Jl7b7RZ pfbBZ7NwGzdOwPvKG2hJaF4lRAK1AfhfYDlqWges62qykiS8//wxIa+B505+FQQVyzqDix52 2mWAcEjKvl109vSozTtsdN7jBlHZMrCnga5YW6pcr2lxUB3SMYA+i+h/ZRz9EqrNitJKCHDf Kh42mZcAzFX8/pUAB2tjVQJH2Z4VzFUPjRB46ErdCWNPvY099a/9tEiz9mZ86/aa1M0EdXKy KjtL5zzkcuK30au4CkAZ9Jvtkilli6XzpmkcZowHewaQkBqUGNoruOeL6me/dh2uhEOCHli9 uJ8GpwkZgr5CmkG7YHoKnAlkRIAQmc0AAAAAAAA= --------------ms000302000306020103050208-- From jas@extundo.com Wed Aug 16 09:05:55 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k7GD5t5d014887 for ; Wed, 16 Aug 2006 09:05:55 -0400 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k7GD64vu020224 for ; Wed, 16 Aug 2006 09:06:04 -0400 (EDT) X-Barracuda-Connect: 178.230.13.217.in-addr.dgcsystems.net[217.13.230.178] X-Barracuda-Start-Time: 1155733561 X-Barracuda-Encrypted: DHE-RSA-AES256-SHA Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 11DBFF74D6 for ; Wed, 16 Aug 2006 09:06:02 -0400 (EDT) Received: from localhost.localdomain (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k7GD5mPV010311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Aug 2006 15:05:49 +0200 From: Simon Josefsson To: Jeffrey Altman References: <20060815150854.GM4099@binky.Central.Sun.COM> <87ac663pzs.fsf@latte.josefsson.org> <20060815173622.GQ4099@binky.Central.Sun.COM> <87wt993kam.fsf@latte.josefsson.org> <20060815192759.GR4099@binky.Central.Sun.COM> <87odul2hkf.fsf@latte.josefsson.org> <44E31249.2070506@columbia.edu> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:060816:jaltman@columbia.edu::wCLkb7rTyiTQ0ACx:7U4k X-Hashcash: 1:22:060816:saag@mit.edu::eYCBxmpCv9FNIZDX:JQCd Date: Wed, 16 Aug 2006 15:05:48 +0200 In-Reply-To: <44E31249.2070506@columbia.edu> (Jeffrey Altman's message of "Wed, 16 Aug 2006 08:40:41 -0400") Message-ID: <873bbw3k5v.fsf@latte.josefsson.org> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on yxa-iv X-Virus-Status: Clean X-Barracuda-Virus-Scanned: by Barracuda Spam Firewall at edu X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] draft-williams-on-channel-binding-00.txt is in the I-D repository X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2006 13:05:55 -0000 Jeffrey Altman writes: > Simon Josefsson wrote: >> Perhaps I was using the term VPN improperly. I meant host-based VPNs, >> such as SSH port-forwarding between the mail client host and the mail >> server, or TLS-based host-to-host VPNs. After re-reading the >> definition of "secure channel" in the document, I don't understand how >> those would differ from, e.g., IPSEC between the mail client host and >> the mail server. >> >> Being able to bind to a SSH or TLS-based VPN channel might be >> acceptable, especially considering the alternative of using GSS_Wrap, >> so maybe we should consider relaxing the definition of "channel". > > Here is the problem. VPNs or SSH tunneling is designed to be > transparent to the application. You, as the user who established the > tunnel, are aware that they exist but from the perspective of the > application they do not. The application believes that it has a > direct end-to-end connection that is established using only the > protocol stacks that it is aware of. > > In the case of IMAP/SASL over TLS over SSH over IPSec over TCP/IP, from > the perspective of the application the only protocols that exist are > IMAP/SASL over TLS over TCP/IP. Therefore it is impossible for the > application to bind to the SSH channel. Right, agreed. > The other problem that you are experiencing in your model is that the > endpoints of the SSH tunnel do not match up with the application > endpoints. In order to be able to perform a binding of the TLS session > to SSH channel there endpoints either need to match or you require a > protocol similar to SOCKS5 that can transport the necessary endpoint > binding data to the application endpoint. Without that the is nothing > for the application to bind to. Right. > In the case of IPSec the endpoints are the same but at the moment there > is no channel for which a name can be assigned for the purpose of > performing a binding from a higher level protocol. Another of Nico's > drafts is meant to provide the necessary definition of an IPSec channel > and the specification of how a name can be derived. The same could be done for SSH too, right? If the answer is yes, then the application knows the channel bindings for the SSH and IPSEC layers, and the question is what the channel bindings is in GS2? If the answer is no (which would surprise me), consider GS2 over TLS over IPSEC. What channel binding should be used in GS2? /Simon From jaltman@columbia.edu Wed Aug 16 09:13:36 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k7GDDZOZ017300 for ; Wed, 16 Aug 2006 09:13:35 -0400 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k7GDDjpv000875 for ; Wed, 16 Aug 2006 09:13:46 -0400 (EDT) X-Barracuda-Connect: jalapeno.cc.columbia.edu[128.59.29.5] X-Barracuda-Start-Time: 1155734025 X-Barracuda-Encrypted: DHE-RSA-AES256-SHA Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 8D9D2326FC for ; Wed, 16 Aug 2006 09:13:45 -0400 (EDT) Received: from [70.195.204.109] (109.sub-70-195-204.myvzw.com [70.195.204.109]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k7GDDWTd021264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 16 Aug 2006 09:13:34 -0400 (EDT) Message-ID: <44E31A6B.3070709@columbia.edu> Date: Wed, 16 Aug 2006 09:15:23 -0400 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Simon Josefsson References: <20060815150854.GM4099@binky.Central.Sun.COM> <87ac663pzs.fsf@latte.josefsson.org> <20060815173622.GQ4099@binky.Central.Sun.COM> <87wt993kam.fsf@latte.josefsson.org> <20060815192759.GR4099@binky.Central.Sun.COM> <87odul2hkf.fsf@latte.josefsson.org> <44E31249.2070506@columbia.edu> <873bbw3k5v.fsf@latte.josefsson.org> In-Reply-To: <873bbw3k5v.fsf@latte.josefsson.org> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010600060608000308010207" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.42 X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Barracuda-Virus-Scanned: by Barracuda Spam Firewall at edu X-Spam-Score: 0.00 X-Spam-Flag: NO Cc: saag@mit.edu Subject: Re: [saag] draft-williams-on-channel-binding-00.txt is in the I-D repository X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2006 13:13:36 -0000 This is a cryptographically signed message in MIME format. --------------ms010600060608000308010207 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Simon Josefsson wrote: > Jeffrey Altman writes: >> In the case of IPSec the endpoints are the same but at the moment there >> is no channel for which a name can be assigned for the purpose of >> performing a binding from a higher level protocol. Another of Nico's >> drafts is meant to provide the necessary definition of an IPSec channel >> and the specification of how a name can be derived. > > The same could be done for SSH too, right? The same cannot be done for SSH because the SSH tunnel does not necessarily exist on the same machine as the application endpoints. Even if the SSH tunnel endpoints are on the same machine they are not on the same IP Address:Port combination as the application. > If the answer is yes, then the application knows the channel bindings > for the SSH and IPSEC layers, and the question is what the channel > bindings is in GS2? > > If the answer is no (which would surprise me), consider GS2 over TLS > over IPSEC. What channel binding should be used in GS2? As Nico explained in one of his earlier messages, if you want to support SASL-GSS over TLS over IPSec, SASL-GSS would bind to TLS and TLS would have to bind to IPSec. Jeffrey Altman --------------ms010600060608000308010207 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJWTCC AwcwggJwoAMCAQICEDgwMdSemBfcGd6HY5Q4qrwwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloX DTA3MDUyNzIyMDMzMlowazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRt YW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAmFluisw/ NLjjXSHm0kgAgAMBknaWpJyDQlTpyzSswiSaDWINyEUzM/teBosk003zfyQdPONkWzclBRZ+ oGsYsAgxmyRe9tAJD7Jo6xp/6kCuF5nnaIyz91gWyuYZEeqQrfyFnWIfQu3fuoSeEIMLc9ac L9qhqnaTwCufH4v56CMftv6KFdf/k1CoLu/DL0ps5UOVwui+8iSWn3Qt6QfefDp9vbtBFPTV nZ7wGeewUJrO1LEC+x3gAOW+KxUcZMBax7tVygT5hDaQXm5lxUrlMQ/hLeWpv7LkVPD/ytoJ NCNzSnycrK4juG1CI12m5K1TNHZJ1uYjb7DUvMwOl6kQiQIDAQABozEwLzAfBgNVHREEGDAW gRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GB ACNK1Xef6H2YL02xqVthcdQgFuF0bENE1u7gX/hegF1awGERhaIJmKGWau4OiAeHnlFqWysP EFzVrSb6L+TF9YHd/bP8WtxccOFnZ1L6oe7KOiyNfXGPZKj/i7Gti+MF4RM1ReZncTC1zMmZ DbFkVhL92vSgDGl4+6IwzjmQVK3sMIIDBzCCAnCgAwIBAgIQODAx1J6YF9wZ3odjlDiqvDAN BgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRp bmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0EwHhcNMDYwNTI3MjIwMzMyWhcNMDcwNTI3MjIwMzMyWjBrMQ8wDQYDVQQEEwZBbHRt YW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMTSmVmZnJleSBFcmljIEFsdG1h bjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCYWW6KzD80uONdIebSSACAAwGSdpaknINCVOnLNKzCJJoNYg3I RTMz+14GiyTTTfN/JB0842RbNyUFFn6gaxiwCDGbJF720AkPsmjrGn/qQK4XmedojLP3WBbK 5hkR6pCt/IWdYh9C7d+6hJ4Qgwtz1pwv2qGqdpPAK58fi/noIx+2/ooV1/+TUKgu78MvSmzl Q5XC6L7yJJafdC3pB958On29u0EU9NWdnvAZ57BQms7UsQL7HeAA5b4rFRxkwFrHu1XKBPmE NpBebmXFSuUxD+Et5am/suRU8P/K2gk0I3NKfJysriO4bUIjXabkrVM0dknW5iNvsNS8zA6X qRCJAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB /wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAI0rVd5/ofZgvTbGpW2Fx1CAW4XRsQ0TW7uBf+F6A XVrAYRGFogmYoZZq7g6IB4eeUWpbKw8QXNWtJvov5MX1gd39s/xa3Fxw4WdnUvqh7so6LI19 cY9kqP+Lsa2L4wXhEzVF5mdxMLXMyZkNsWRWEv3a9KAMaXj7ojDOOZBUrewwggM/MIICqKAD AgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVy biBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5n MSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZy ZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoG A1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcN AQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHy v1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsY Pge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0T AQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20v VGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQe MBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD 6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZ GwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC 3CEZNd4ksdMdRv9dX2VPMYIDZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIElzc3VpbmcgQ0ECEDgwMdSemBfcGd6HY5Q4qrwwCQYFKw4DAhoFAKCCAcMw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYwODE2MTMxNTIz WjAjBgkqhkiG9w0BCQQxFgQUkSKvGlgDySM6hTCaP4ds6rtYNGowUgYJKoZIhvcNAQkPMUUw QzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcw DQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA4MDHUnpgX3Bneh2OUOKq8MIGHBgsqhkiG9w0B CRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA4MDHUnpgX3Bneh2OUOKq8MA0GCSqGSIb3DQEBAQUABIIBAE+Ba+11tcQE7MoWfhkJW49D eTaZEbuT6juiTHkXfR6ynXscRrhV2ZnAKnVL6jjvE7P0nXJGW9CE+fERl5ZXDaFTXtu/dxtm cpVDlGyyzHyXcmX7af4wft+Q7fhB4TiQSCuMDIM8babjzJqmgJvaCH/mF8c8oGDakvA1i0VX dlfEBtKUbACboJKhK3SOh68v8A7SobqPR1/tiijNPGjJoGKMhlIP0o+blVyNAM7KtxvCW7gR d1HjCcM4bnffzbSOEbpqpo4EZadkk/HIxWeBADYQtjdBI992C3Altb9CGrWzUZpnpPJP9QiJ QCqoS262vzAgOfoPrfiL5EtyjTkBQw4AAAAAAAA= --------------ms010600060608000308010207-- From jas@extundo.com Wed Aug 16 10:27:07 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k7GER7t3002352 for ; Wed, 16 Aug 2006 10:27:07 -0400 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k7GERAmk014501 for ; Wed, 16 Aug 2006 10:27:10 -0400 (EDT) X-Barracuda-Connect: 178.230.13.217.in-addr.dgcsystems.net[217.13.230.178] X-Barracuda-Start-Time: 1155738428 X-Barracuda-Encrypted: DHE-RSA-AES256-SHA Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 6A02E497D3 for ; Wed, 16 Aug 2006 10:27:08 -0400 (EDT) Received: from localhost.localdomain (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k7GEQmxQ017311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Aug 2006 16:26:48 +0200 From: Simon Josefsson To: Jeffrey Altman References: <20060815150854.GM4099@binky.Central.Sun.COM> <87ac663pzs.fsf@latte.josefsson.org> <20060815173622.GQ4099@binky.Central.Sun.COM> <87wt993kam.fsf@latte.josefsson.org> <20060815192759.GR4099@binky.Central.Sun.COM> <87odul2hkf.fsf@latte.josefsson.org> <44E31249.2070506@columbia.edu> <873bbw3k5v.fsf@latte.josefsson.org> <44E31A6B.3070709@columbia.edu> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:060816:jaltman@columbia.edu::mQDUI7ap0ghLeXY1:3jsw X-Hashcash: 1:22:060816:saag@mit.edu::qXEWnmsxvBnMeQZI:JK8f Date: Wed, 16 Aug 2006 16:26:47 +0200 In-Reply-To: <44E31A6B.3070709@columbia.edu> (Jeffrey Altman's message of "Wed, 16 Aug 2006 09:15:23 -0400") Message-ID: <87y7to21ug.fsf@latte.josefsson.org> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on yxa-iv X-Virus-Status: Clean X-Barracuda-Virus-Scanned: by Barracuda Spam Firewall at edu X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] draft-williams-on-channel-binding-00.txt is in the I-D repository X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2006 14:27:07 -0000 Jeffrey Altman writes: > Simon Josefsson wrote: >> Jeffrey Altman writes: > >>> In the case of IPSec the endpoints are the same but at the moment there >>> is no channel for which a name can be assigned for the purpose of >>> performing a binding from a higher level protocol. Another of Nico's >>> drafts is meant to provide the necessary definition of an IPSec channel >>> and the specification of how a name can be derived. >> >> The same could be done for SSH too, right? > > The same cannot be done for SSH because the SSH tunnel does not > necessarily exist on the same machine as the application endpoints. > Even if the SSH tunnel endpoints are on the same machine they are > not on the same IP Address:Port combination as the application. OpenSSH supports so called TUN-based VPN's as well, and there is pppd over ssh too, so I don't think this holds in general. These are too minor to warrant further consideration, so I'll drop SSH from the stack. >> If the answer is yes, then the application knows the channel bindings >> for the SSH and IPSEC layers, and the question is what the channel >> bindings is in GS2? >> >> If the answer is no (which would surprise me), consider GS2 over TLS >> over IPSEC. What channel binding should be used in GS2? > > As Nico explained in one of his earlier messages, if you want to support > SASL-GSS over TLS over IPSec, SASL-GSS would bind to TLS and TLS would > have to bind to IPSec. My point is that it appear to be possible to support this in Nico's current draft without modifications in TLS, by having the channel binding in GS2 be a concatenation of both the TLS channel bindings and the IPSEC channel bindings. /Simon From jaltman@columbia.edu Wed Aug 16 10:52:50 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k7GEqogR008012 for ; Wed, 16 Aug 2006 10:52:50 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k7GEr0RL022579 for ; Wed, 16 Aug 2006 10:53:00 -0400 (EDT) X-Barracuda-Connect: jalapeno.cc.columbia.edu[128.59.29.5] X-Barracuda-Start-Time: 1155739979 X-Barracuda-Encrypted: DHE-RSA-AES256-SHA Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id C72772F2F2E for ; Wed, 16 Aug 2006 10:52:59 -0400 (EDT) Received: from [70.221.53.36] (36.sub-70-221-53.myvzw.com [70.221.53.36]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k7GEqi6U010975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 16 Aug 2006 10:52:48 -0400 (EDT) Message-ID: <44E331AB.3000704@columbia.edu> Date: Wed, 16 Aug 2006 10:54:35 -0400 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Simon Josefsson References: <20060815150854.GM4099@binky.Central.Sun.COM> <87ac663pzs.fsf@latte.josefsson.org> <20060815173622.GQ4099@binky.Central.Sun.COM> <87wt993kam.fsf@latte.josefsson.org> <20060815192759.GR4099@binky.Central.Sun.COM> <87odul2hkf.fsf@latte.josefsson.org> <44E31249.2070506@columbia.edu> <873bbw3k5v.fsf@latte.josefsson.org> <44E31A6B.3070709@columbia.edu> <87y7to21ug.fsf@latte.josefsson.org> In-Reply-To: <87y7to21ug.fsf@latte.josefsson.org> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030309070602090402040101" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.42 X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Barracuda-Virus-Scanned: by Barracuda Spam Firewall at edu X-Spam-Score: 0.00 X-Spam-Flag: NO Cc: saag@mit.edu Subject: Re: [saag] draft-williams-on-channel-binding-00.txt is in the I-D repository X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2006 14:52:50 -0000 This is a cryptographically signed message in MIME format. --------------ms030309070602090402040101 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Simon Josefsson wrote: > Jeffrey Altman writes: > >> Simon Josefsson wrote: >>> Jeffrey Altman writes: >>>> In the case of IPSec the endpoints are the same but at the moment there >>>> is no channel for which a name can be assigned for the purpose of >>>> performing a binding from a higher level protocol. Another of Nico's >>>> drafts is meant to provide the necessary definition of an IPSec channel >>>> and the specification of how a name can be derived. >>> The same could be done for SSH too, right? >> The same cannot be done for SSH because the SSH tunnel does not >> necessarily exist on the same machine as the application endpoints. >> Even if the SSH tunnel endpoints are on the same machine they are >> not on the same IP Address:Port combination as the application. > > OpenSSH supports so called TUN-based VPN's as well, and there is pppd > over ssh too, so I don't think this holds in general. These are too > minor to warrant further consideration, so I'll drop SSH from the > stack. > >>> If the answer is yes, then the application knows the channel bindings >>> for the SSH and IPSEC layers, and the question is what the channel >>> bindings is in GS2? >>> >>> If the answer is no (which would surprise me), consider GS2 over TLS >>> over IPSEC. What channel binding should be used in GS2? >> As Nico explained in one of his earlier messages, if you want to support >> SASL-GSS over TLS over IPSec, SASL-GSS would bind to TLS and TLS would >> have to bind to IPSec. > > My point is that it appear to be possible to support this in Nico's > current draft without modifications in TLS, by having the channel > binding in GS2 be a concatenation of both the TLS channel bindings and > the IPSEC channel bindings. > > /Simon You could define a new channel binding for TLS+IPsec provided that both the TLS and IPsec channel binding values are available to the application. There are stacks which will hide the IPsec beneath the TLS. This knowledge would have to be available to both application endpoints and the application would need to know to use the TLS+IPsec binding instead of the TLS binding. Jeffrey Altman --------------ms030309070602090402040101 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJWTCC AwcwggJwoAMCAQICEDgwMdSemBfcGd6HY5Q4qrwwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloX DTA3MDUyNzIyMDMzMlowazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRt YW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAmFluisw/ NLjjXSHm0kgAgAMBknaWpJyDQlTpyzSswiSaDWINyEUzM/teBosk003zfyQdPONkWzclBRZ+ oGsYsAgxmyRe9tAJD7Jo6xp/6kCuF5nnaIyz91gWyuYZEeqQrfyFnWIfQu3fuoSeEIMLc9ac L9qhqnaTwCufH4v56CMftv6KFdf/k1CoLu/DL0ps5UOVwui+8iSWn3Qt6QfefDp9vbtBFPTV nZ7wGeewUJrO1LEC+x3gAOW+KxUcZMBax7tVygT5hDaQXm5lxUrlMQ/hLeWpv7LkVPD/ytoJ NCNzSnycrK4juG1CI12m5K1TNHZJ1uYjb7DUvMwOl6kQiQIDAQABozEwLzAfBgNVHREEGDAW gRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GB ACNK1Xef6H2YL02xqVthcdQgFuF0bENE1u7gX/hegF1awGERhaIJmKGWau4OiAeHnlFqWysP EFzVrSb6L+TF9YHd/bP8WtxccOFnZ1L6oe7KOiyNfXGPZKj/i7Gti+MF4RM1ReZncTC1zMmZ DbFkVhL92vSgDGl4+6IwzjmQVK3sMIIDBzCCAnCgAwIBAgIQODAx1J6YF9wZ3odjlDiqvDAN BgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRp bmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0EwHhcNMDYwNTI3MjIwMzMyWhcNMDcwNTI3MjIwMzMyWjBrMQ8wDQYDVQQEEwZBbHRt YW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMTSmVmZnJleSBFcmljIEFsdG1h bjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCYWW6KzD80uONdIebSSACAAwGSdpaknINCVOnLNKzCJJoNYg3I RTMz+14GiyTTTfN/JB0842RbNyUFFn6gaxiwCDGbJF720AkPsmjrGn/qQK4XmedojLP3WBbK 5hkR6pCt/IWdYh9C7d+6hJ4Qgwtz1pwv2qGqdpPAK58fi/noIx+2/ooV1/+TUKgu78MvSmzl Q5XC6L7yJJafdC3pB958On29u0EU9NWdnvAZ57BQms7UsQL7HeAA5b4rFRxkwFrHu1XKBPmE NpBebmXFSuUxD+Et5am/suRU8P/K2gk0I3NKfJysriO4bUIjXabkrVM0dknW5iNvsNS8zA6X qRCJAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB /wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAI0rVd5/ofZgvTbGpW2Fx1CAW4XRsQ0TW7uBf+F6A XVrAYRGFogmYoZZq7g6IB4eeUWpbKw8QXNWtJvov5MX1gd39s/xa3Fxw4WdnUvqh7so6LI19 cY9kqP+Lsa2L4wXhEzVF5mdxMLXMyZkNsWRWEv3a9KAMaXj7ojDOOZBUrewwggM/MIICqKAD AgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVy biBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5n MSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZy ZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoG A1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcN AQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHy v1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsY Pge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0T AQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20v VGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQe MBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD 6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZ GwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC 3CEZNd4ksdMdRv9dX2VPMYIDZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIElzc3VpbmcgQ0ECEDgwMdSemBfcGd6HY5Q4qrwwCQYFKw4DAhoFAKCCAcMw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYwODE2MTQ1NDM1 WjAjBgkqhkiG9w0BCQQxFgQUVkXUoa9jzCYtDODKWvLvaYddgCEwUgYJKoZIhvcNAQkPMUUw QzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcw DQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA4MDHUnpgX3Bneh2OUOKq8MIGHBgsqhkiG9w0B CRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA4MDHUnpgX3Bneh2OUOKq8MA0GCSqGSIb3DQEBAQUABIIBAIPZrGlntSeUQTwlzRUUm3n9 Kor+2XkLPuxXRfTuyk1ZoEvP/MlgzdCHWbpW0M5xy/wqR9ATetdsALafEJenRv2RzNJPdrEz AVLtbclCJQldR9ndmNsx+IEHqtJ7SuN5rv+GmQtBpLqd2Xrzf0xvG0q1iKrBV1XpfxjkFivX VRlwKfiDJ2v7yRb0zkBrUkwNVJd0NQ84P0LT02rL0FsvqNURtdSTCmQwHVM0VmiibYc6BFhn X5CNJrvLBelRa3miBV6NLf+YyxEtEYGLa482OW/cU8XVlhHHs1fCqe/53oz8SwAeus+xY0ho l7eMw+g1TmRwDHfQVVI+y4cTYv848Y8AAAAAAAA= --------------ms030309070602090402040101-- From jas@extundo.com Wed Aug 16 11:18:46 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k7GFIk9g012197 for ; Wed, 16 Aug 2006 11:18:46 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k7GFIulI001105 for ; Wed, 16 Aug 2006 11:18:56 -0400 (EDT) X-Barracuda-Connect: 178.230.13.217.in-addr.dgcsystems.net[217.13.230.178] X-Barracuda-Start-Time: 1155741533 X-Barracuda-Encrypted: DHE-RSA-AES256-SHA Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 7B4E834EEEB for ; Wed, 16 Aug 2006 11:18:54 -0400 (EDT) Received: from localhost.localdomain (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k7GFIUpp022414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Aug 2006 17:18:30 +0200 From: Simon Josefsson To: Jeffrey Altman References: <20060815150854.GM4099@binky.Central.Sun.COM> <87ac663pzs.fsf@latte.josefsson.org> <20060815173622.GQ4099@binky.Central.Sun.COM> <87wt993kam.fsf@latte.josefsson.org> <20060815192759.GR4099@binky.Central.Sun.COM> <87odul2hkf.fsf@latte.josefsson.org> <44E31249.2070506@columbia.edu> <873bbw3k5v.fsf@latte.josefsson.org> <44E31A6B.3070709@columbia.edu> <87y7to21ug.fsf@latte.josefsson.org> <44E331AB.3000704@columbia.edu> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:060816:saag@mit.edu::2o8R1JJncv/UPwtJ:V/1 X-Hashcash: 1:22:060816:jaltman@columbia.edu::4sh4SMUec0iUBxiy:61Gm Date: Wed, 16 Aug 2006 17:18:29 +0200 In-Reply-To: <44E331AB.3000704@columbia.edu> (Jeffrey Altman's message of "Wed, 16 Aug 2006 10:54:35 -0400") Message-ID: <87k6581zga.fsf@latte.josefsson.org> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on yxa-iv X-Virus-Status: Clean X-Barracuda-Virus-Scanned: by Barracuda Spam Firewall at edu X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] draft-williams-on-channel-binding-00.txt is in the I-D repository X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2006 15:18:46 -0000 Jeffrey Altman writes: > You could define a new channel binding for TLS+IPsec provided that both > the TLS and IPsec channel binding values are available to the > application. There are stacks which will hide the IPsec beneath the TLS. > > This knowledge would have to be available to both application endpoints > and the application would need to know to use the TLS+IPsec binding > instead of the TLS binding. Right, and I'm wondering whether negotiating which channel binding should be used is something that we could add to Nico's draft, or possibly to the protocols that use channel bindings, such as GS2. I think it at least partially belongs to Nico's draft, since any protocol that use channel bindings over multiple security channels have the same concern, and we shouldn't have to invent the wheel over and over. Negotiation complicates things, but it may be warranted. For example, optimizing away an unnecessary extra TLS channel when the underlying channel is already appropriately protected by SSH or IPSEC seems useful to me. Of course, it is critical that the negotiation make sure that the "appropriately protected" property holds, and determining that is not simple. If we don't add the negotiation, and protocols such as GS2 only bind to the "closest" secure channel, the document should mention that clients and servers that have access to all of the TLS, SSH and IPSEC channel bindings (which the client/server will have access to if it supports all of those protocols as the closest secure channel) has to make sure it knows which of the channels bindings it should use. /Simon From jaltman@columbia.edu Wed Aug 16 11:23:34 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k7GFNY1p013196 for ; Wed, 16 Aug 2006 11:23:34 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k7GFNdfi008062 for ; Wed, 16 Aug 2006 11:23:39 -0400 (EDT) X-Barracuda-Connect: jalapeno.cc.columbia.edu[128.59.29.5] X-Barracuda-Start-Time: 1155741818 X-Barracuda-Encrypted: DHE-RSA-AES256-SHA Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 1550C35137F for ; Wed, 16 Aug 2006 11:23:39 -0400 (EDT) Received: from [70.221.53.36] (36.sub-70-221-53.myvzw.com [70.221.53.36]) (user=jaltman mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k7GFNRGM017077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 16 Aug 2006 11:23:29 -0400 (EDT) Message-ID: <44E338DF.1080001@columbia.edu> Date: Wed, 16 Aug 2006 11:25:19 -0400 From: Jeffrey Altman Organization: No Longer Affiliated with Columbia University in the City of New York User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Simon Josefsson References: <20060815150854.GM4099@binky.Central.Sun.COM> <87ac663pzs.fsf@latte.josefsson.org> <20060815173622.GQ4099@binky.Central.Sun.COM> <87wt993kam.fsf@latte.josefsson.org> <20060815192759.GR4099@binky.Central.Sun.COM> <87odul2hkf.fsf@latte.josefsson.org> <44E31249.2070506@columbia.edu> <873bbw3k5v.fsf@latte.josefsson.org> <44E31A6B.3070709@columbia.edu> <87y7to21ug.fsf@latte.josefsson.org> <44E331AB.3000704@columbia.edu> <87k6581zga.fsf@latte.josefsson.org> In-Reply-To: <87k6581zga.fsf@latte.josefsson.org> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040300050202000507040203" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.42 X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Barracuda-Virus-Scanned: by Barracuda Spam Firewall at edu X-Spam-Score: 0.00 X-Spam-Flag: NO Cc: saag@mit.edu Subject: Re: [saag] draft-williams-on-channel-binding-00.txt is in the I-D repository X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2006 15:23:34 -0000 This is a cryptographically signed message in MIME format. --------------ms040300050202000507040203 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Simon Josefsson wrote: > Right, and I'm wondering whether negotiating which channel binding > should be used is something that we could add to Nico's draft, or > possibly to the protocols that use channel bindings, such as GS2. > > I think it at least partially belongs to Nico's draft, since any > protocol that use channel bindings over multiple security channels > have the same concern, and we shouldn't have to invent the wheel over > and over. > > Negotiation complicates things, but it may be warranted. For example, > optimizing away an unnecessary extra TLS channel when the underlying > channel is already appropriately protected by SSH or IPSEC seems > useful to me. Of course, it is critical that the negotiation make > sure that the "appropriately protected" property holds, and > determining that is not simple. > > If we don't add the negotiation, and protocols such as GS2 only bind > to the "closest" secure channel, the document should mention that > clients and servers that have access to all of the TLS, SSH and IPSEC > channel bindings (which the client/server will have access to if it > supports all of those protocols as the closest secure channel) has to > make sure it knows which of the channels bindings it should use. > > /Simon I don't believe this is a requirement for Nico's draft. If I remember correctly when we designed SASL-GSSv2 we provided the ability for the client to specify what channel bindings it was using. This was done by labeling the channel bindings with a TLS specific prefix. If the client specifies a different channel binding prefix the server will have to match with something else. The prefix was necessary in order to deal with the situation in which one side understood the TLS channel bindings and the other side did not. Jeffrey Altman --------------ms040300050202000507040203 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJWTCC AwcwggJwoAMCAQICEDgwMdSemBfcGd6HY5Q4qrwwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloX DTA3MDUyNzIyMDMzMlowazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRt YW5AY29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAmFluisw/ NLjjXSHm0kgAgAMBknaWpJyDQlTpyzSswiSaDWINyEUzM/teBosk003zfyQdPONkWzclBRZ+ oGsYsAgxmyRe9tAJD7Jo6xp/6kCuF5nnaIyz91gWyuYZEeqQrfyFnWIfQu3fuoSeEIMLc9ac L9qhqnaTwCufH4v56CMftv6KFdf/k1CoLu/DL0ps5UOVwui+8iSWn3Qt6QfefDp9vbtBFPTV nZ7wGeewUJrO1LEC+x3gAOW+KxUcZMBax7tVygT5hDaQXm5lxUrlMQ/hLeWpv7LkVPD/ytoJ NCNzSnycrK4juG1CI12m5K1TNHZJ1uYjb7DUvMwOl6kQiQIDAQABozEwLzAfBgNVHREEGDAW gRRqYWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GB ACNK1Xef6H2YL02xqVthcdQgFuF0bENE1u7gX/hegF1awGERhaIJmKGWau4OiAeHnlFqWysP EFzVrSb6L+TF9YHd/bP8WtxccOFnZ1L6oe7KOiyNfXGPZKj/i7Gti+MF4RM1ReZncTC1zMmZ DbFkVhL92vSgDGl4+6IwzjmQVK3sMIIDBzCCAnCgAwIBAgIQODAx1J6YF9wZ3odjlDiqvDAN BgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRp bmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0EwHhcNMDYwNTI3MjIwMzMyWhcNMDcwNTI3MjIwMzMyWjBrMQ8wDQYDVQQEEwZBbHRt YW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMTSmVmZnJleSBFcmljIEFsdG1h bjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5lZHUwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCYWW6KzD80uONdIebSSACAAwGSdpaknINCVOnLNKzCJJoNYg3I RTMz+14GiyTTTfN/JB0842RbNyUFFn6gaxiwCDGbJF720AkPsmjrGn/qQK4XmedojLP3WBbK 5hkR6pCt/IWdYh9C7d+6hJ4Qgwtz1pwv2qGqdpPAK58fi/noIx+2/ooV1/+TUKgu78MvSmzl Q5XC6L7yJJafdC3pB958On29u0EU9NWdnvAZ57BQms7UsQL7HeAA5b4rFRxkwFrHu1XKBPmE NpBebmXFSuUxD+Et5am/suRU8P/K2gk0I3NKfJysriO4bUIjXabkrVM0dknW5iNvsNS8zA6X qRCJAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29sdW1iaWEuZWR1MAwGA1UdEwEB /wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAI0rVd5/ofZgvTbGpW2Fx1CAW4XRsQ0TW7uBf+F6A XVrAYRGFogmYoZZq7g6IB4eeUWpbKw8QXNWtJvov5MX1gd39s/xa3Fxw4WdnUvqh7so6LI19 cY9kqP+Lsa2L4wXhEzVF5mdxMLXMyZkNsWRWEv3a9KAMaXj7ojDOOZBUrewwggM/MIICqKAD AgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVy biBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5n MSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZy ZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoG A1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcN AQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHy v1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsY Pge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0T AQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20v VGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQe MBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD 6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZ GwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC 3CEZNd4ksdMdRv9dX2VPMYIDZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIElzc3VpbmcgQ0ECEDgwMdSemBfcGd6HY5Q4qrwwCQYFKw4DAhoFAKCCAcMw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYwODE2MTUyNTE5 WjAjBgkqhkiG9w0BCQQxFgQUyAqfG04mPbJpxY2rlh5L1GKgdKowUgYJKoZIhvcNAQkPMUUw QzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcw DQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA4MDHUnpgX3Bneh2OUOKq8MIGHBgsqhkiG9w0B CRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA4MDHUnpgX3Bneh2OUOKq8MA0GCSqGSIb3DQEBAQUABIIBAH9zL8YtJWgr8wstXVTvH0kY 7uiZidNEqOgY+ZI9950S61jpELvkI+RHNM8uKO/uwVKCYV8wT2pK/LHxQ7GMC3daIUJvIiRt jBv7CacS/sWpGzzUTbu0IIhI/zYOkv22ItR9hNEvP8Oa+StEHvItAQm3UkbcWN6Ux1YebUQv Qm9GNFNes8N4Z6wUcQL64UpNoSMSbnbAkng0tvz5xOlV4VNhZMMbgOj/si56lLowJUM1Dv1R BPrIb3GWBtXSvnrwvZMJJnG7RFUjNqhSR7PZJhY3Efc5FOOSZQh2OHFbj0bZVHabIHPgS9Q0 YmgUkLBvBV8f5IJ3GRsXO8piUroPDgwAAAAAAAA= --------------ms040300050202000507040203-- From jas@extundo.com Wed Aug 16 11:42:45 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k7GFgj0I016095 for ; Wed, 16 Aug 2006 11:42:45 -0400 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k7GFgnFa007884 for ; Wed, 16 Aug 2006 11:42:49 -0400 (EDT) X-Barracuda-Connect: 178.230.13.217.in-addr.dgcsystems.net[217.13.230.178] X-Barracuda-Start-Time: 1155742967 X-Barracuda-Encrypted: DHE-RSA-AES256-SHA Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id CF0A1C249D for ; Wed, 16 Aug 2006 11:42:48 -0400 (EDT) Received: from localhost.localdomain (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k7GFgQcu024589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Aug 2006 17:42:30 +0200 From: Simon Josefsson To: Jeffrey Altman References: <20060815150854.GM4099@binky.Central.Sun.COM> <87ac663pzs.fsf@latte.josefsson.org> <20060815173622.GQ4099@binky.Central.Sun.COM> <87wt993kam.fsf@latte.josefsson.org> <20060815192759.GR4099@binky.Central.Sun.COM> <87odul2hkf.fsf@latte.josefsson.org> <44E31249.2070506@columbia.edu> <873bbw3k5v.fsf@latte.josefsson.org> <44E31A6B.3070709@columbia.edu> <87y7to21ug.fsf@latte.josefsson.org> <44E331AB.3000704@columbia.edu> <87k6581zga.fsf@latte.josefsson.org> <44E338DF.1080001@columbia.edu> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:060816:jaltman@columbia.edu::iZftDa1dii/1DC3v:q9X X-Hashcash: 1:22:060816:saag@mit.edu::BrBdIvTtEtAvz7Hm:CBLM Date: Wed, 16 Aug 2006 17:42:26 +0200 In-Reply-To: <44E338DF.1080001@columbia.edu> (Jeffrey Altman's message of "Wed, 16 Aug 2006 11:25:19 -0400") Message-ID: <87bqqk1ycd.fsf@latte.josefsson.org> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on yxa-iv X-Virus-Status: Clean X-Barracuda-Virus-Scanned: by Barracuda Spam Firewall at edu X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] draft-williams-on-channel-binding-00.txt is in the I-D repository X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2006 15:42:45 -0000 Jeffrey Altman writes: > Simon Josefsson wrote: > >> Right, and I'm wondering whether negotiating which channel binding >> should be used is something that we could add to Nico's draft, or >> possibly to the protocols that use channel bindings, such as GS2. >> >> I think it at least partially belongs to Nico's draft, since any >> protocol that use channel bindings over multiple security channels >> have the same concern, and we shouldn't have to invent the wheel over >> and over. >> >> Negotiation complicates things, but it may be warranted. For example, >> optimizing away an unnecessary extra TLS channel when the underlying >> channel is already appropriately protected by SSH or IPSEC seems >> useful to me. Of course, it is critical that the negotiation make >> sure that the "appropriately protected" property holds, and >> determining that is not simple. >> >> If we don't add the negotiation, and protocols such as GS2 only bind >> to the "closest" secure channel, the document should mention that >> clients and servers that have access to all of the TLS, SSH and IPSEC >> channel bindings (which the client/server will have access to if it >> supports all of those protocols as the closest secure channel) has to >> make sure it knows which of the channels bindings it should use. >> >> /Simon > > I don't believe this is a requirement for Nico's draft. If I remember > correctly when we designed SASL-GSSv2 we provided the ability for the > client to specify what channel bindings it was using. This was done > by labeling the channel bindings with a TLS specific prefix. If the > client specifies a different channel binding prefix the server will > have to match with something else. I don't believe any version of GS2 has said that, although I recall discussing this approach. Anyway, as far as I have understood, there was a decision that channel bindings should not be designed in the SASL WG, so the GS2 document now defer most things related to channel bindings to Nico's draft. > The prefix was necessary in order to deal with the situation in which > one side understood the TLS channel bindings and the other side did not. I don't think the prefix is necessary for that: if the bindings doesn't match (a NULL channel bindings won't match a non-NULL channel bindings), GS2 will typically fall back to use GSS_Wrap. However, prefixes is one way to negotiate channel bindings. A channel binding could then become TLS+IPSEC:[TLScb][IPSECcb]. Both peers are responsible for finding the channel binding data from the appropriate stacks, or if it cannot, signal that the channel bindings mismatch. /Simon From nw141292@binky.Central.Sun.COM Wed Aug 16 11:43:43 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k7GFhhVw016222 for ; Wed, 16 Aug 2006 11:43:43 -0400 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k7GFhprq027839 for ; Wed, 16 Aug 2006 11:43:52 -0400 (EDT) X-Barracuda-Connect: nwkea-mail-4.sun.com[192.18.42.26] X-Barracuda-Start-Time: 1155743023 Received: from nwkea-mail-4.sun.com (nwkea-mail-4.sun.com [192.18.42.26]) by mit.edu (Spam Firewall) with ESMTP id 48DEF5CE18 for ; Wed, 16 Aug 2006 11:43:43 -0400 (EDT) Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by nwkea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7GFhgSD019521 for ; Wed, 16 Aug 2006 08:43:43 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k7GFdgkX019321 for ; Wed, 16 Aug 2006 09:39:42 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7GFhfIe007396; Wed, 16 Aug 2006 10:43:41 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7GFhfIk007395; Wed, 16 Aug 2006 10:43:41 -0500 (CDT) Date: Wed, 16 Aug 2006 10:43:41 -0500 From: Nicolas Williams To: Simon Josefsson Message-ID: <20060816154339.GD7357@binky.Central.Sun.COM> References: <20060815150854.GM4099@binky.Central.Sun.COM> <87ac663pzs.fsf@latte.josefsson.org> <20060815173622.GQ4099@binky.Central.Sun.COM> <87wt993kam.fsf@latte.josefsson.org> <20060815192759.GR4099@binky.Central.Sun.COM> <87odul2hkf.fsf@latte.josefsson.org> <44E31249.2070506@columbia.edu> <873bbw3k5v.fsf@latte.josefsson.org> <44E31A6B.3070709@columbia.edu> <87y7to21ug.fsf@latte.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87y7to21ug.fsf@latte.josefsson.org> User-Agent: Mutt/1.5.7i X-Barracuda-Virus-Scanned: by Barracuda Spam Firewall at edu X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Jeffrey Altman Subject: Re: [saag] draft-williams-on-channel-binding-00.txt is in the I-D repository X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2006 15:43:43 -0000 On Wed, Aug 16, 2006 at 04:26:47PM +0200, Simon Josefsson wrote: > Jeffrey Altman writes: > > > Simon Josefsson wrote: > >> Jeffrey Altman writes: > > > >>> In the case of IPSec the endpoints are the same but at the moment there > >>> is no channel for which a name can be assigned for the purpose of > >>> performing a binding from a higher level protocol. Another of Nico's > >>> drafts is meant to provide the necessary definition of an IPSec channel > >>> and the specification of how a name can be derived. > >> > >> The same could be done for SSH too, right? SSHv2 is a channel. SSHv2 port-forwarding can't be a channel that you can bind to unless the two end-points at the application layer are on the same hosts as at the SSHv2 layer. It's the same thing with IPsec. You can't bind to IPsec VPNs -- where one end-point at the IPsec layer is an SG. You just can't bind to VPNs. > > The same cannot be done for SSH because the SSH tunnel does not > > necessarily exist on the same machine as the application endpoints. > > Even if the SSH tunnel endpoints are on the same machine they are > > not on the same IP Address:Port combination as the application. > > OpenSSH supports so called TUN-based VPN's as well, and there is pppd > over ssh too, so I don't think this holds in general. These are too > minor to warrant further consideration, so I'll drop SSH from the > stack. Yes, it does hold generally. If you have this: <-> . . <-> <-> where there might be a multitude of servers, then how can you make sure that: a) the servers can obtain the channel bindings for the client<->SG channel and b) everyone is happy with the security of the network behind the SG? (b) is easy, in a way -- we deal with that in Leif's upcomming HTTP authentication with channel binding to TLS between the client's last proxy and the server's first proxy. (a) is hard! It requires making clients and servers, from IP to applications, aware of middle boxes! Specifically you just can't do (a) without some protocol by which servers can discover that there's a gateway, which gateway and what the channel bindings are. Manually providing channel bindings won't cut it, particularly if you're trying to do that on the client side (if you don't do it under the protection of the app-layer security service you open yourself to the very MITM attacks that you're trying to defeat by using channel binding). > >> If the answer is yes, then the application knows the channel bindings > >> for the SSH and IPSEC layers, and the question is what the channel > >> bindings is in GS2? > >> > >> If the answer is no (which would surprise me), consider GS2 over TLS > >> over IPSEC. What channel binding should be used in GS2? > > > > As Nico explained in one of his earlier messages, if you want to support > > SASL-GSS over TLS over IPSec, SASL-GSS would bind to TLS and TLS would > > have to bind to IPSec. > > My point is that it appear to be possible to support this in Nico's > current draft without modifications in TLS, by having the channel > binding in GS2 be a concatenation of both the TLS channel bindings and > the IPSEC channel bindings. "Each layer binds to the one below" is much easier than "the top layer binds to them all" -- the latter requires that the top layer be able to talk to all the other layers, which screams abstraction violation to me. Nico -- From nw141292@binky.Central.Sun.COM Wed Aug 16 11:50:51 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k7GFooTt017370 for ; Wed, 16 Aug 2006 11:50:50 -0400 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k7GFotSA020374 for ; Wed, 16 Aug 2006 11:50:56 -0400 (EDT) X-Barracuda-Connect: nwkea-mail-4.sun.com[192.18.42.26] X-Barracuda-Start-Time: 1155743454 Received: from nwkea-mail-4.sun.com (nwkea-mail-4.sun.com [192.18.42.26]) by mit.edu (Spam Firewall) with ESMTP id C6B28B24FE for ; Wed, 16 Aug 2006 11:50:54 -0400 (EDT) Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by nwkea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7GForDX024348 for ; Wed, 16 Aug 2006 08:50:53 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k7GFkrsq022744 for ; Wed, 16 Aug 2006 09:46:53 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7GFoqMx007405; Wed, 16 Aug 2006 10:50:52 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7GFoqOB007404; Wed, 16 Aug 2006 10:50:52 -0500 (CDT) Date: Wed, 16 Aug 2006 10:50:52 -0500 From: Nicolas Williams To: Simon Josefsson Message-ID: <20060816155052.GE7357@binky.Central.Sun.COM> References: <20060815173622.GQ4099@binky.Central.Sun.COM> <87wt993kam.fsf@latte.josefsson.org> <20060815192759.GR4099@binky.Central.Sun.COM> <87odul2hkf.fsf@latte.josefsson.org> <44E31249.2070506@columbia.edu> <873bbw3k5v.fsf@latte.josefsson.org> <44E31A6B.3070709@columbia.edu> <87y7to21ug.fsf@latte.josefsson.org> <44E331AB.3000704@columbia.edu> <87k6581zga.fsf@latte.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87k6581zga.fsf@latte.josefsson.org> User-Agent: Mutt/1.5.7i X-Barracuda-Virus-Scanned: by Barracuda Spam Firewall at edu X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Jeffrey Altman Subject: Re: [saag] draft-williams-on-channel-binding-00.txt is in the I-D repository X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2006 15:50:51 -0000 On Wed, Aug 16, 2006 at 05:18:29PM +0200, Simon Josefsson wrote: > Jeffrey Altman writes: > > > You could define a new channel binding for TLS+IPsec provided that both > > the TLS and IPsec channel binding values are available to the > > application. There are stacks which will hide the IPsec beneath the TLS. > > > > This knowledge would have to be available to both application endpoints > > and the application would need to know to use the TLS+IPsec binding > > instead of the TLS binding. > > Right, and I'm wondering whether negotiating which channel binding > should be used is something that we could add to Nico's draft, or > possibly to the protocols that use channel bindings, such as GS2. > > I think it at least partially belongs to Nico's draft, since any > protocol that use channel bindings over multiple security channels > have the same concern, and we shouldn't have to invent the wheel over > and over. First of all, my draft does not explicitly deal with multiple layers of channel binding. Second, analysis of layer-by-layer channel binding is easy once you have an analysis of channel binding between each pair of layers, but the same is not true for all-at-one-layer channel binding like you suggest. Third, it's reasonable to expect any one layer to be aware of the one below it for channel binding, but it's not reasonable to expect the application to be aware of all the layers below it that are suitable for channel binding -- think of the OSI model. Nico -- From nw141292@binky.Central.Sun.COM Wed Aug 16 11:58:44 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k7GFwitk018274 for ; Wed, 16 Aug 2006 11:58:44 -0400 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k7GFwo68001175 for ; Wed, 16 Aug 2006 11:58:50 -0400 (EDT) X-Barracuda-Connect: nwkea-mail-2.sun.com[192.18.42.14] X-Barracuda-Start-Time: 1155743928 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by mit.edu (Spam Firewall) with ESMTP id 54C983D8CB for ; Wed, 16 Aug 2006 11:58:48 -0400 (EDT) Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by nwkea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7GFwmHB014039 for ; Wed, 16 Aug 2006 08:58:48 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k7GFsl38026971 for ; Wed, 16 Aug 2006 09:54:48 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7GFwlvY007438; Wed, 16 Aug 2006 10:58:47 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7GFwkcn007437; Wed, 16 Aug 2006 10:58:46 -0500 (CDT) Date: Wed, 16 Aug 2006 10:58:46 -0500 From: Nicolas Williams To: Jeffrey Altman Message-ID: <20060816155846.GG7357@binky.Central.Sun.COM> References: <87wt993kam.fsf@latte.josefsson.org> <20060815192759.GR4099@binky.Central.Sun.COM> <87odul2hkf.fsf@latte.josefsson.org> <44E31249.2070506@columbia.edu> <873bbw3k5v.fsf@latte.josefsson.org> <44E31A6B.3070709@columbia.edu> <87y7to21ug.fsf@latte.josefsson.org> <44E331AB.3000704@columbia.edu> <87k6581zga.fsf@latte.josefsson.org> <44E338DF.1080001@columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44E338DF.1080001@columbia.edu> User-Agent: Mutt/1.5.7i X-Barracuda-Virus-Scanned: by Barracuda Spam Firewall at edu X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Simon Josefsson Subject: Re: [saag] draft-williams-on-channel-binding-00.txt is in the I-D repository X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2006 15:58:44 -0000 On Wed, Aug 16, 2006 at 11:25:19AM -0400, Jeffrey Altman wrote: > The prefix was necessary in order to deal with the situation in which > one side understood the TLS channel bindings and the other side did not. Technically it protects against an MITM switch channel types where the MITM could somehow make the channel bindings of the two channels match. But as long as neither the client nor the server use channel binding to channels where an MITM could force the channel bindings to be specific values then this just can't happen, thus the prefix is not needed at all. But it does not harm anything. From mcr@sandelman.ottawa.on.ca Wed Aug 16 13:48:06 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k7GHm61g013084 for ; Wed, 16 Aug 2006 13:48:06 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k7GHmAL8010621 for ; Wed, 16 Aug 2006 13:48:11 -0400 (EDT) X-Barracuda-Connect: newcod.sandelman.ca[192.139.46.42] X-Barracuda-Start-Time: 1155750432 Received: from cod.sandelman.ca (newcod.sandelman.ca [192.139.46.42]) by mit.edu (Spam Firewall) with ESMTP id 5D1B734894B for ; Wed, 16 Aug 2006 13:47:12 -0400 (EDT) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "marajade.sandelman.ca.", Issuer "Michael Richardson" (verified OK)) by cod.sandelman.ca (Postfix) with ESMTP id 5EFC0125BE for ; Wed, 16 Aug 2006 13:47:11 -0400 (EDT) Received: from sandelman.ottawa.on.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 48CA63AD96 for ; Wed, 16 Aug 2006 13:47:10 -0400 (EDT) From: Michael Richardson To: saag@mit.edu In-Reply-To: Message from Simon Josefsson of "Wed, 16 Aug 2006 10:47:12 +0200." <87odul2hkf.fsf@latte.josefsson.org> References: <20060815150854.GM4099@binky.Central.Sun.COM> <87ac663pzs.fsf@latte.josefsson.org> <20060815173622.GQ4099@binky.Central.Sun.COM> <87wt993kam.fsf@latte.josefsson.org> <20060815192759.GR4099@binky.Central.Sun.COM> <87odul2hkf.fsf@latte.josefsson.org> X-Mailer: MH-E 7.82; nmh 1.1; XEmacs 21.4 (patch 17) Date: Wed, 16 Aug 2006 13:47:10 -0400 Message-ID: <26507.1155750430@sandelman.ottawa.on.ca> Sender: mcr@sandelman.ottawa.on.ca X-Barracuda-Virus-Scanned: by Barracuda Spam Firewall at edu X-Spam-Score: 0.13 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: Re: [saag] draft-williams-on-channel-binding-00.txt is in the I-D repository X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2006 17:48:06 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 To me, and I think most everyone else who truly cares, VPN has a threat model that says that it has to resist things like TCP RST attacks. If you are sure that nobody can see your traffic, such that your TCP header is safe, then you didn't need to encrypt anything in the first place. So an SSH port-forward, or a TLS-TCP based channel is not a VPN. It's just a protected channel of some kind. I use SSH as a secure authentication mechanism, and TLS+SMTP as a secure way to authenticate relaying. The fact that I get some privacy is a nice bonus. - -- ] 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"); [ "The Microsoft _Get the Facts CD_ does not work on Linux." - orospakr -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Finger me for keys iQEVAwUBRONaHICLcPvd0N1lAQIeCgf/dYesrEsk81338z0OcBtHefu/leyah2d0 digRspJs9za6l2OMEzU0fMyM/lgoTRoQjeNECcVSTRWbB7MfKPRSFBTANmzPGqg9 fFu2jflf2hl3y0D4r68fFkiVSputh0pD1gEuq6Zlj0mTla/+L/YBBOmU/3Egmj+v qMJsx6UNxwWYqBqCqDXciRz7K6rpgBHDc46LoOKM7vH5y3bEz32oNIqNwVG5Saik HF7haNJJscsVIQfTBB79E6uO8pWhOG8mbAtNjio1hVyjFSO5lb8YrK8wPQxHfNNI Dxy7q//SMPGrviXudZgW0Owx2AotMsdQCPRQWHemCp+E2cVZEBMt7A== =919W -----END PGP SIGNATURE----- From nw141292@binky.Central.Sun.COM Wed Aug 16 15:16:06 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k7GJG6IV031839 for ; Wed, 16 Aug 2006 15:16:06 -0400 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k7GJGF8A024967 for ; Wed, 16 Aug 2006 15:16:15 -0400 (EDT) X-Barracuda-Connect: brmea-mail-3.Sun.COM[192.18.98.34] X-Barracuda-Start-Time: 1155755653 Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by mit.edu (Spam Firewall) with ESMTP id 7B346B7413 for ; Wed, 16 Aug 2006 15:14:13 -0400 (EDT) Received: from centralmail3brm.Central.Sun.COM ([129.147.62.199]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7GJECSl017537 for ; Wed, 16 Aug 2006 13:14:12 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail3brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k7GJACXd005883 for ; Wed, 16 Aug 2006 13:10:12 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7GJEBMG007807; Wed, 16 Aug 2006 14:14:11 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7GJEBuM007806; Wed, 16 Aug 2006 14:14:11 -0500 (CDT) Date: Wed, 16 Aug 2006 14:14:11 -0500 From: Nicolas Williams To: Michael Richardson Message-ID: <20060816191410.GE7647@binky.Central.Sun.COM> References: <20060815150854.GM4099@binky.Central.Sun.COM> <87ac663pzs.fsf@latte.josefsson.org> <20060815173622.GQ4099@binky.Central.Sun.COM> <87wt993kam.fsf@latte.josefsson.org> <20060815192759.GR4099@binky.Central.Sun.COM> <87odul2hkf.fsf@latte.josefsson.org> <26507.1155750430@sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <26507.1155750430@sandelman.ottawa.on.ca> User-Agent: Mutt/1.5.7i X-Barracuda-Virus-Scanned: by Barracuda Spam Firewall at edu X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] draft-williams-on-channel-binding-00.txt is in the I-D repository X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2006 19:16:06 -0000 On Wed, Aug 16, 2006 at 01:47:10PM -0400, Michael Richardson wrote: > To me, and I think most everyone else who truly cares, VPN has a threat > model that says that it has to resist things like TCP RST attacks. But more fundamentally, when people say "VPN" they mean "my client connects to some gateway and then I have access to all of my network." There's a channel between the client and the gateway, but not between the client and its peers behind the gateway, not just because of the VPN anyways. Channel binding being about end-2-end security _generally_[*] requires an end-2-end channel, "VPN" isn't one. [*] Now, I'll grant you that one can do something to make channel binding to channels between gateways work, and in fact Leif's upcomming I-D specifies just that: channel binding HTTP authentication to the one TLS channel that we care about. A requirement that can lead to this is proxy traversal with application protocol data in cleartext relative to friendly proxies. But even in the proxy traversal situation we need a way for servers ensure that they know or can validate channel bindings, which is markedly different from the traditional channel binding model of the GSS-API where the two end-points at the application layer observe, and pass to the GSS mechanism, the channel bindings for the channel between them. So, yes, there may be room for channel binding to SSHv2 connections that are doing port forwarding (which can be end-2-end anyways). And there may be room for channel binding to multiple channels, each at different network layers. But this is out of scope for my I-D, at least until the ADs/IESG say otherwise. Anyone who is interested in specifying channel binding to port forwardinng channels, VPNs, or multiple channels is welcome to write separate I-Ds. Yes, there is an informative discussion in this I-D, in section 5, of the HTTP channel binding w/ proxies, but it is merely informative. The document that specifies that will have to deal with issues that this I-D does not, and it will be a separate I-D, and it won't rely on this I-D being sufficiently generic to cover channel binding with proxies. Nico -- From roessler@does-not-exist.org Sat Aug 5 17:39:30 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k75LdSnc006893 for ; Sat, 5 Aug 2006 17:39:30 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k75Ldafc013116 for ; Sat, 5 Aug 2006 17:39:36 -0400 (EDT) Received: from kamino.does-not-exist.org (kamino.does-not-exist.org [217.160.221.198]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id E7B6929A188 for ; Sat, 5 Aug 2006 17:39:38 -0400 (EDT) Received: from lavazza.does-not-exist.org (ip-83-99-58-85.dyn.luxdsl.pt.lu [83.99.58.85]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by kamino.does-not-exist.org (Postfix) with ESMTP id 4B98E193742; Sat, 5 Aug 2006 23:39:33 +0200 (CEST) Received: from roessler by lavazza.does-not-exist.org with local (Exim 4.62) (envelope-from ) id 1G9Trn-0003ig-Vj; Sat, 05 Aug 2006 23:39:31 +0200 Date: Sat, 5 Aug 2006 23:39:31 +0200 From: Thomas Roessler To: Derek Atkins Message-ID: <20060805213931.GA14257@lavazza.does-not-exist.org> Mail-Followup-To: Derek Atkins , saag@MIT.EDU, ietf-openpgp@imc.org, "housley@vigilsec.com.and.hartmans-ietf"@MIT.EDU References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.12 (2006-07-18) X-Spam-Score: 0.12 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id k75LdSnc006893 X-Mailman-Approved-At: Thu, 17 Aug 2006 09:53:57 -0400 Cc: saag@mit.edu, "housley@vigilsec.com.and.hartmans-ietf"@mit.edu, ietf-openpgp@imc.org Subject: Re: [saag] OpenPGP Minutes / Quick Summary X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Aug 2006 21:39:30 -0000 On 2006-07-12 18:16:45 -0400, Derek Atkins wrote: > Thomas Roessler gave a history of the Multiple Signature > Draft. It's an extension to RFC1847 to allow the > "signature" portion of the message to be a "multipart/mixed" > and have a set of signatures on the signed data instead of > just a single signature. This signature set could be a > combination of OpenPGP and e.g. S/MIME signatures. As a status update, I've dug out the (quite short) draft from that old backup; before re-submitting it, I'm waiting for my co-authors from back then to give me new contact information and to ok submitting with the new IETF IPR boilerplate. Regards, -- Thomas Roessler · Personal soap box at . From jas@extundo.com Fri Aug 18 08:31:10 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k7ICVAcQ017304 for ; Fri, 18 Aug 2006 08:31:10 -0400 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k7ICVKcH020034 for ; Fri, 18 Aug 2006 08:31:21 -0400 (EDT) X-Barracuda-Connect: 178.230.13.217.in-addr.dgcsystems.net[217.13.230.178] X-Barracuda-Start-Time: 1155904278 X-Barracuda-Encrypted: DHE-RSA-AES256-SHA Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id C84ED50388 for ; Fri, 18 Aug 2006 08:31:19 -0400 (EDT) Received: from localhost.localdomain (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k7ICV2Rj001376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Aug 2006 14:31:03 +0200 X-Hashcash: 1:22:060818:nicolas.williams@sun.com::WqFVDQhMOKx6fMuk:RDz0 X-Hashcash: 1:22:060818:saag@mit.edu::/4b8nMyfqUVkr71U:DaEQ From: Simon Josefsson To: Nicolas Williams References: <20060815150854.GM4099@binky.Central.Sun.COM> <87ac663pzs.fsf@latte.josefsson.org> <20060815173622.GQ4099@binky.Central.Sun.COM> <87wt993kam.fsf@latte.josefsson.org> <20060815192759.GR4099@binky.Central.Sun.COM> <87odul2hkf.fsf@latte.josefsson.org> <44E31249.2070506@columbia.edu> <873bbw3k5v.fsf@latte.josefsson.org> <44E31A6B.3070709@columbia.edu> <87y7to21ug.fsf@latte.josefsson.org> <20060816154339.GD7357@binky.Central.Sun.COM> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:060818:jaltman@columbia.edu::5EoH6DASSQVZ7aJo:6uZ4 Date: Fri, 18 Aug 2006 14:31:02 +0200 In-Reply-To: <20060816154339.GD7357@binky.Central.Sun.COM> (Nicolas Williams's message of "Wed, 16 Aug 2006 10:43:41 -0500") Message-ID: <87fyfucjjt.fsf@latte.josefsson.org> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on yxa-iv X-Virus-Status: Clean X-Barracuda-Virus-Scanned: by Barracuda Spam Firewall at edu X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Jeffrey Altman Subject: Re: [saag] draft-williams-on-channel-binding-00.txt is in the I-D repository X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2006 12:31:11 -0000 Nicolas Williams writes: >> > As Nico explained in one of his earlier messages, if you want to support >> > SASL-GSS over TLS over IPSec, SASL-GSS would bind to TLS and TLS would >> > have to bind to IPSec. >> >> My point is that it appear to be possible to support this in Nico's >> current draft without modifications in TLS, by having the channel >> binding in GS2 be a concatenation of both the TLS channel bindings and >> the IPSEC channel bindings. > > "Each layer binds to the one below" is much easier than "the top layer > binds to them all" -- the latter requires that the top layer be able to > talk to all the other layers, which screams abstraction violation to me. I disagree. Every implementation of a user authentication protocol (I'm thinking GS2, but it holds generally) that supports multiple secure channels require an interface to the implementation of that secure channel, to get the channel bindings. This means that the user authentication protocol implementation (think GS2) needs to be able to retrieve the channel bindings for all the secure channels that it supports. Consequently, if the GS2 library supports binding directly onto TLS, SSH and IPSEC channels, it will need an API that talks to the TLS, SSH, and IPSEC implementations. Thus, from my point of view, the layer abstraction violation already seems inherent in this design -- the GS2 library needs to be able to talk with the implementation of all supported secure channels anyway -- so which of the two approaches you mention we chose doesn't seem like a big difference to me. It seems that this discussion isn't going anywhere, and consequently, that this draft won't support compound channel bindings that allow user authentication protocols to bind to multiple secure channels. Perhaps that conclusion from this discussion can be noted in the draft, a'la: This document does not describe how to create channel bindings that are strongly bound to multiple secure channels (e.g., TLS over IPSEC). As a reference for further study, we note two ideas that would solve this problem. One solution is to, for each secure channel protocol (e.g., TLS, SSH, and IPSEC), define a mechanism to strongly bind that channel to another secure channel beneath it. Another solution would be to describe a syntax of these compound channel bindings that use a prefix to the channel bindings that reflect the channel stack, and to concatenate the channel bindings for those channels; for example, 'TLS+IPSEC:[TLS channel binding][IPSEC channel binding]'. Thanks, Simon From nw141292@binky.Central.Sun.COM Fri Aug 18 11:07:04 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k7IF74AC009370 for ; Fri, 18 Aug 2006 11:07:04 -0400 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k7IF797n000583 for ; Fri, 18 Aug 2006 11:07:10 -0400 (EDT) X-Barracuda-Connect: nwkea-mail-2.sun.com[192.18.42.14] X-Barracuda-Start-Time: 1155913627 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by mit.edu (Spam Firewall) with ESMTP id 605F9B4C40 for ; Fri, 18 Aug 2006 11:07:07 -0400 (EDT) Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by nwkea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7IF7710002601 for ; Fri, 18 Aug 2006 08:07:07 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k7IF75Vf021346 for ; Fri, 18 Aug 2006 09:07:06 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k7IF75Sw010224; Fri, 18 Aug 2006 10:07:05 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k7IF75V3010223; Fri, 18 Aug 2006 10:07:05 -0500 (CDT) Date: Fri, 18 Aug 2006 10:07:05 -0500 From: Nicolas Williams To: Simon Josefsson Message-ID: <20060818150704.GB10208@binky.Central.Sun.COM> References: <20060815173622.GQ4099@binky.Central.Sun.COM> <87wt993kam.fsf@latte.josefsson.org> <20060815192759.GR4099@binky.Central.Sun.COM> <87odul2hkf.fsf@latte.josefsson.org> <44E31249.2070506@columbia.edu> <873bbw3k5v.fsf@latte.josefsson.org> <44E31A6B.3070709@columbia.edu> <87y7to21ug.fsf@latte.josefsson.org> <20060816154339.GD7357@binky.Central.Sun.COM> <87fyfucjjt.fsf@latte.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87fyfucjjt.fsf@latte.josefsson.org> User-Agent: Mutt/1.5.7i X-Barracuda-Virus-Scanned: by Barracuda Spam Firewall at edu X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Jeffrey Altman Subject: Re: [saag] draft-williams-on-channel-binding-00.txt is in the I-D repository X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2006 15:07:05 -0000 On Fri, Aug 18, 2006 at 02:31:02PM +0200, Simon Josefsson wrote: > Nicolas Williams writes: > > "Each layer binds to the one below" is much easier than "the top layer > > binds to them all" -- the latter requires that the top layer be able to > > talk to all the other layers, which screams abstraction violation to me. > > I disagree. > > Every implementation of a user authentication protocol (I'm thinking > GS2, but it holds generally) that supports multiple secure channels > require an interface to the implementation of that secure channel, to > get the channel bindings. So far so good. > This means that the user authentication protocol implementation (think > GS2) needs to be able to retrieve the channel bindings for all the > secure channels that it supports. Consequently, if the GS2 library > supports binding directly onto TLS, SSH and IPSEC channels, it will > need an API that talks to the TLS, SSH, and IPSEC implementations. It's not the GS2 library that will do it, it's the application. And I believe it will be much easier for each layer do talk to the layer below to do its own binding -- assuming anyone really wants multi-layer binding. In any case, multi-layer channel binding is out of scope for this draft, for now anyways as I see no need to include it. It's being out of scope does not prevent you from writing a draft that describes multi-layer channel binding. > Thus, from my point of view, the layer abstraction violation already > seems inherent in this design -- the GS2 library needs to be able to > talk with the implementation of all supported secure channels anyway > -- so which of the two approaches you mention we chose doesn't seem > like a big difference to me. There is no circumstance in which we want a security mechanism (SASL, or GSS) interfacing to channels being bound to. I suggest you read what RFCs 2743, 2744 and 1964 have to say about channel bindings. Then this should be clear. GS2 implementations WILL NOT interface to the channels being bound. > It seems that this discussion isn't going anywhere, and consequently, > that this draft won't support compound channel bindings that allow > user authentication protocols to bind to multiple secure channels. No, this draft won't support multi-layer channel binding. > Perhaps that conclusion from this discussion can be noted in the > draft, a'la: > > This document does not describe how to create channel bindings > that are strongly bound to multiple secure channels (e.g., TLS > over IPSEC). Full stop. There's no need for this: > As a reference for further study, we note two ideas > that would solve this problem. One solution is to, for each > secure channel protocol (e.g., TLS, SSH, and IPSEC), define a > mechanism to strongly bind that channel to another secure channel > beneath it. Another solution would be to describe a syntax of > these compound channel bindings that use a prefix to the channel > bindings that reflect the channel stack, and to concatenate the > channel bindings for those channels; for example, 'TLS+IPSEC:[TLS > channel binding][IPSEC channel binding]'. Nico -- From shanna@juniper.net Fri Aug 18 11:29:37 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k7IFTa60013606 for ; Fri, 18 Aug 2006 11:29:36 -0400 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k7IFTlSx021965 for ; Fri, 18 Aug 2006 11:29:47 -0400 (EDT) X-Barracuda-Connect: borg.juniper.net[207.17.137.119] X-Barracuda-Start-Time: 1155914985 Received: from borg.juniper.net (borg.juniper.net [207.17.137.119]) by mit.edu (Spam Firewall) with ESMTP id B1475541C4; Fri, 18 Aug 2006 11:29:45 -0400 (EDT) Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 18 Aug 2006 08:28:03 -0700 X-IronPort-AV: i="4.08,146,1154934000"; d="scan'208"; a="578681729:sNHT72412360" x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 18 Aug 2006 11:29:39 -0400 Message-ID: In-Reply-To: <126EBB1F0092E14B9E595D03263235AAC0048F@SCES1.sc.nevisnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PING: [Nea] IETF 66 NEA BOF Summary Thread-Index: AcalKRfO+PMqaWq2RTmBQ4LOO4SLUgBWMNIwAAJvx3ADYxPloANm8kYgACP/LvA= From: "Stephen Hanna" To: "Joseph Tardo" , "Khosravi, Hormuzd M" , , "Russ Housley" , "Sam Hartman" , X-Barracuda-Virus-Scanned: by Barracuda Spam Firewall at edu X-Spam-Score: 0.60 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id k7IFTa60013606 Subject: Re: [saag] PING: [Nea] IETF 66 NEA BOF Summary X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Aug 2006 15:29:37 -0000 There's an echo in here, I think. ;-) My response to Hormuzd's earlier email was: > Susan and I are working on the revised charter. I hope we'll have > something back to the NEA list within a few weeks. The timeline for > an eventual IESG decision is more uncertain but I expect it would not > be more than a month or two. I'm afraid that report is still pretty much accurate. I'm sorry things are taking longer than I hoped. I guess that's the downside of being an engineer. My estimates are usually far too optimistic. And August is not the best time to do this. People take vacations. Let me assure you that we are making progress. I'll get a revised charter out to the nea@ietf.org list ASAP. And I promise to keep you posted as things move along. Thanks, Steve -----Original Message----- From: Joseph Tardo [mailto:joseph.tardo@nevisnetworks.com] Sent: Thursday, August 17, 2006 12:16 AM To: Khosravi, Hormuzd M; Stephen Hanna; nea@ietf.org; Russ Housley; Sam Hartman; saag@mit.edu Subject: PING: [Nea] IETF 66 NEA BOF Summary Hi Steve Any news on the formation of the WG? By when will we get the final word? The BoF was successful, but we haven't heard of anything after that. Thanks Joe -----Original Message----- From: Khosravi, Hormuzd M [mailto:hormuzd.m.khosravi@intel.com] Sent: Sunday, July 30, 2006 1:39 PM To: Stephen Hanna; nea@ietf.org; Russ Housley; Sam Hartman; saag@mit.edu Subject: RE: [Nea] IETF 66 NEA BOF Summary Hi Steve Any news on the formation of the WG? By when will we get the final word? The BoF was successful, but we haven't heard of anything after that. Thanks Hormuzd -----Original Message----- From: Stephen Hanna [mailto:shanna@juniper.net] Sent: Thursday, July 13, 2006 8:06 AM To: nea@ietf.org; Russ Housley; Sam Hartman; saag@mit.edu Subject: [Nea] IETF 66 NEA BOF Summary Summary of NEA BOF at IETF 66 The NEA BOF focussed on discussing and agreeing on a charter for a potential NEA WG. As part of this, there was considerable discussion of the NEA use case, architecture, and scope. The session was well attended (more than 100 people). Many good questions and issues were raised, all in a constructive manner. These concerns will be reviewed to determine whether architectural changes may be needed. At the end of the session, rough consensus was reached on a revised scope. The scope in the previously proposed charter will be modified to require that the WG identify a Mandatory To Implement transport (which may be developed by another WG). Also, vendor attributes would be required to be documented in an RFC. And the protocols developed must be designed to accomodate emerging technologies for addressing lying endpoints. With these changes, rough consensus was reached that the IETF should create a WG with this scope and the previously proposed goals. A substantial number of BOF participants indicated they would help edit and author documents. The BOF chairs will work with the ADs, the mailing list, and others to prepare a revised charter reflecting the BOF's rough consensus. This charter will be submitted to the IESG for consideration. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From housley@vigilsec.com Wed Aug 23 14:37:36 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k7NIbauv004665 for ; Wed, 23 Aug 2006 14:37:36 -0400 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k7NIbUbZ011204 for ; Wed, 23 Aug 2006 14:37:30 -0400 (EDT) X-Barracuda-Connect: woodstock.binhost.com[66.150.120.2] X-Barracuda-Start-Time: 1156358209 Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by mit.edu (Spam Firewall) with SMTP id 76449A914B for ; Wed, 23 Aug 2006 14:36:49 -0400 (EDT) Received: (qmail 30460 invoked by uid 0); 23 Aug 2006 18:36:42 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (169.231.68.207) by woodstock.binhost.com with SMTP; 23 Aug 2006 18:36:42 -0000 Message-Id: <7.0.0.16.2.20060823141834.03f5fdd8@vigilsec.com> Message-Id: <7.0.0.16.2.20060823121907.079b6d30@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Wed, 23 Aug 2006 14:20:21 -0400 To: saag@mit.edu From: Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Barracuda-Virus-Scanned: by Barracuda Spam Firewall at edu X-Spam-Score: 0.01 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] FYI: IEEE 802.1AE published X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2006 18:37:36 -0000 A standard for the security of IEEE 802 LAN frames has just been published. Russ >Date: Wed, 23 Aug 2006 12:45:21 +0100 >Reply-To: Tony Jeffree >Sender: "IEEE 802.1 list-owner" >From: Tony Jeffree >Subject: [802.1 - 557] 802.1AE published >To: STDS-802-1-L@LISTSERV.IEEE.ORG > >I am pleased to be able to announce that IEEE Std 802.1AE was >published on 18th August. My thanks and congratulations to all of >the WG participants that contributed to this important project. > >Regards, >Tony From mcgrew@cisco.com Mon Aug 28 16:08:25 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k7SK8PJG009595 for ; Mon, 28 Aug 2006 16:08:25 -0400 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k7SK8Jbj024052 for ; Mon, 28 Aug 2006 16:08:19 -0400 (EDT) X-Barracuda-Connect: sj-iport-6.cisco.com[171.71.176.117] X-Barracuda-Start-Time: 1156795698 Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mit.edu (Spam Firewall) with ESMTP id D50F6F373B for ; Mon, 28 Aug 2006 16:08:18 -0400 (EDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 28 Aug 2006 13:08:18 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7SK8I4h022471; Mon, 28 Aug 2006 13:08:18 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k7SK8HQV020425; Mon, 28 Aug 2006 13:08:17 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Aug 2006 13:08:17 -0700 Received: from [192.168.1.100] ([10.32.254.211]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 28 Aug 2006 13:08:16 -0700 In-Reply-To: <77ead0ec0608142318r1805433ci466838b0dcff03e6@mail.gmail.com> References: <77ead0ec0608142318r1805433ci466838b0dcff03e6@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1362466B-6BB2-445A-AFDE-7CCF0ABA9FFA@cisco.com> Content-Transfer-Encoding: 7bit From: David McGrew Date: Mon, 28 Aug 2006 13:08:14 -0700 To: Vishwas Manral X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 28 Aug 2006 20:08:16.0899 (UTC) FILETIME=[B3286530:01C6CADD] DKIM-Signature: a=rsa-sha1; q=dns; l=2256; t=1156795698; x=1157659698; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mcgrew@cisco.com; z=From:David=20McGrew=20 |Subject:Re=3A=20[saag]=20Checksum=20and=20Md5/=20SHA-1=20hashing; X=v=3Dcisco.com=3B=20h=3DDGOhXuNmZxGDbKOu8cH+A5IgB1o=3D; b=eccJjB/rUNjygJbGuHF27rh6P8EJdFZpYsIn1w3f4AlJ6O5AnnPoX6GgIL7JxWVWZBOo/DGc fD0oa4nWg2GePvyo6WO9T1BYtZ7cp7yTFO/uVnXzxTzVEv2JeSXrYhBE; Authentication-Results: sj-dkim-3.cisco.com; header.From=mcgrew@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Barracuda-Virus-Scanned: by Barracuda Spam Firewall at edu X-Spam-Score: 0.13 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] Checksum and Md5/ SHA-1 hashing X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2006 20:08:25 -0000 Hi Vishwas, from Section 6: Assuming a 32 bit checksum field in the message, which is part of the content of the packet. Assume that a collision occurs in 2^X attempts for a particular Hash algorithm. As the content over which the Hash is calculated in such a case is totally random. The checksum field in this case would be one of 0 to 2^32 - 1. The value of the checksum in such a case would be correct in only 1 of the 2^ 32 cases. This would mean that 1 of the 2^32 attempts that result in a collision will also result in the correct checksum. This means that the number of attempts would be 2 ^ (32 + X). For SHA-1 it would be 2 ^ (32 + 62). Checksum thus provides a second factor of security. This greatly reduces the effect of collision attacks. What assumptions are you making about the hash function? AFAICT what you're describing isn't true even for unbroken hash functions. An attacker can find collisions in a strong hash function with an n-bit output in O(2^(n/2)) work, even if the inputs to the hash function include a checksum, just by providing 2^(n/2) inputs that include a checksum and looking for collisions. Am I misunderstanding your proposal? David On Aug 14, 2006, at 11:18 PM, Vishwas Manral wrote: > Hi folks, > > In a lot of specs for control protocols I figured out that, in case > Hash based authentication is done using MD5/ SHA-1 etc, the checksum > field which is in the content of the packet (so as to be able to > detect data corruption), is not used for hashing at all and not > calculated at all. > > This is because the hash algorithms themselves provide a mechanism to > detect any data corruption. > > What I am proposing is that if we have checksum in the packet and the > checksum is part of the hash calculations. It helps reduce the effects > of collision. > > I am attaching the draft, which I have not yet posted. Do let me know > what you think? > > Thanks, > Vishwas > > _______________________________________________ > saag mailing list > saag@mit.edu > http://mailman.mit.edu/mailman/listinfo/saag From vishwas.ietf@gmail.com Tue Aug 29 01:20:04 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k7T5K350013322 for ; Tue, 29 Aug 2006 01:20:04 -0400 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k7T5I0nq029913 for ; Tue, 29 Aug 2006 01:18:00 -0400 (EDT) X-Barracuda-Connect: wx-out-0506.google.com[66.249.82.233] X-Barracuda-Start-Time: 1156828679 Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.233]) by mit.edu (Spam Firewall) with ESMTP id F3E33105382 for ; Tue, 29 Aug 2006 01:17:59 -0400 (EDT) Received: by wx-out-0506.google.com with SMTP id t11so2721372wxc for ; Mon, 28 Aug 2006 22:17:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=PqLj8QOyhegWNyDUTppqJMKE0lJzLborKM9lVyeXgXtLWD4dm3S8qXuXZo98wQhvMEgee0rGbc3fg9KKZOcrVm6HX25/JG/y/XOlIGYGc51tfwl/gyqh2vdN5NXHiixC9mnsYWukSZH7UeZTF6n6QiqEat00UaKgHRMN0g3GELg= Received: by 10.70.14.20 with SMTP id 20mr10675657wxn; Mon, 28 Aug 2006 22:17:59 -0700 (PDT) Received: by 10.70.33.3 with HTTP; Mon, 28 Aug 2006 22:17:59 -0700 (PDT) Message-ID: <77ead0ec0608282217h33ce1784nf03ef21390f2e57@mail.gmail.com> Date: Tue, 29 Aug 2006 10:47:59 +0530 From: "Vishwas Manral" To: "David McGrew" In-Reply-To: <1362466B-6BB2-445A-AFDE-7CCF0ABA9FFA@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <77ead0ec0608142318r1805433ci466838b0dcff03e6@mail.gmail.com> <1362466B-6BB2-445A-AFDE-7CCF0ABA9FFA@cisco.com> X-Barracuda-Virus-Scanned: by Barracuda Spam Firewall at edu X-Spam-Score: 0.479 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] Checksum and Md5/ SHA-1 hashing X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2006 05:20:04 -0000 Hi David, I was also thinking of the same problem from the signed documents case. And I think having a checksum of the document which is part of the hash, would increase the effort resulting from collision attacks. I agree having some constant field (example amount field of $10,000) in the document and then creating collisions should require the same effort as nopt having them. However having checksum in the content which includes the entire content will increase the effort considerably, in my view. As teh checksum itself cannot be made a constant (a second hash e.g. SHA-1, MD5 other than the checksum itself could be even better). Am I missing the point here? I guess the value 2^32 is wrong(I noticed that later), but I guess even a 2^16 effort increase is a lot. Thanks, Vishwas On 8/29/06, David McGrew wrote: > Hi Vishwas, > > from Section 6: > > Assuming a 32 bit checksum field in the message, which is part of > the content > of the packet. > > Assume that a collision occurs in 2^X attempts for a particular > Hash algorithm. > As the content over which the Hash is calculated in such a case > is totally > random. The checksum field in this case would be one of 0 to 2^32 > - 1. The > value of the checksum in such a case would be correct in only 1 > of the 2^ 32 > cases. This would mean that 1 of the 2^32 attempts that result in > a collision > will also result in the correct checksum. > > This means that the number of attempts would be 2 ^ (32 + X). > For SHA-1 it would > be 2 ^ (32 + 62). > > Checksum thus provides a second factor of security. This greatly > reduces the > effect of collision attacks. > > What assumptions are you making about the hash function? > > AFAICT what you're describing isn't true even for unbroken hash > functions. An attacker can find collisions in a strong hash function > with an n-bit output in O(2^(n/2)) work, even if the inputs to the > hash function include a checksum, just by providing 2^(n/2) inputs > that include a checksum and looking for collisions. Am I > misunderstanding your proposal? > > David > > > On Aug 14, 2006, at 11:18 PM, Vishwas Manral wrote: > > > Hi folks, > > > > In a lot of specs for control protocols I figured out that, in case > > Hash based authentication is done using MD5/ SHA-1 etc, the checksum > > field which is in the content of the packet (so as to be able to > > detect data corruption), is not used for hashing at all and not > > calculated at all. > > > > This is because the hash algorithms themselves provide a mechanism to > > detect any data corruption. > > > > What I am proposing is that if we have checksum in the packet and the > > checksum is part of the hash calculations. It helps reduce the effects > > of collision. > > > > I am attaching the draft, which I have not yet posted. Do let me know > > what you think? > > > > Thanks, > > Vishwas > > From hartmans@MIT.EDU Tue Aug 29 12:39:01 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k7TGd18g029900 for ; Tue, 29 Aug 2006 12:39:01 -0400 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k7TGd1CS007824 for ; Tue, 29 Aug 2006 12:39:02 -0400 (EDT) X-Barracuda-Connect: carter-zimmerman.suchdamage.org[69.25.196.178] X-Barracuda-Start-Time: 1156869541 X-Barracuda-Encrypted: DHE-RSA-AES256-SHA Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id AE6A213B774 for ; Tue, 29 Aug 2006 12:39:01 -0400 (EDT) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id A0AE0E00C0; Tue, 29 Aug 2006 12:39:04 -0400 (EDT) From: Sam Hartman To: Simon Josefsson References: <20060815150854.GM4099@binky.Central.Sun.COM> <87ac663pzs.fsf@latte.josefsson.org> <20060815173622.GQ4099@binky.Central.Sun.COM> <87wt993kam.fsf@latte.josefsson.org> <20060815192759.GR4099@binky.Central.Sun.COM> <87odul2hkf.fsf@latte.josefsson.org> <44E31249.2070506@columbia.edu> <873bbw3k5v.fsf@latte.josefsson.org> <44E31A6B.3070709@columbia.edu> <87y7to21ug.fsf@latte.josefsson.org> <20060816154339.GD7357@binky.Central.Sun.COM> <87fyfucjjt.fsf@latte.josefsson.org> Date: Tue, 29 Aug 2006 12:39:04 -0400 In-Reply-To: <87fyfucjjt.fsf@latte.josefsson.org> (Simon Josefsson's message of "Fri, 18 Aug 2006 14:31:02 +0200") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Barracuda-Virus-Scanned: by Barracuda Spam Firewall at edu X-Spam-Score: 0 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Jeffrey Altman , Nicolas Williams Subject: Re: [saag] draft-williams-on-channel-binding-00.txt is in the I-D repository X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2006 16:39:02 -0000 For what it's worth, I tend to believe that multi-layer channel binding should be out of scope. If we are going to do multi-layer binding I prefer binding to the layer below only. Sam, speaking as an individual. From fenton@cisco.com Thu Aug 31 16:27:32 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k7VKRWQs002805 for ; Thu, 31 Aug 2006 16:27:32 -0400 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k7VKRWdp012773 for ; Thu, 31 Aug 2006 16:27:32 -0400 (EDT) X-Barracuda-Connect: sj-iport-6.cisco.com[171.71.176.117] X-Barracuda-Start-Time: 1157056051 Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mit.edu (Spam Firewall) with ESMTP id 37F0B10D2BD for ; Thu, 31 Aug 2006 16:27:32 -0400 (EDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 31 Aug 2006 13:27:31 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7VKRVXh025818 for ; Thu, 31 Aug 2006 13:27:31 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k7VKRVQV027923 for ; Thu, 31 Aug 2006 13:27:31 -0700 (PDT) Received: from [171.71.97.128] (dhcp-171-71-97-128.cisco.com [171.71.97.128]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k7VKISZw000678 for ; Thu, 31 Aug 2006 13:18:28 -0700 Message-ID: <44F74633.3030904@cisco.com> Date: Thu, 31 Aug 2006 13:27:31 -0700 From: Jim Fenton User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: saag@mit.edu X-Enigmail-Version: 0.93.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-2.cisco.com; header.From=fenton@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=715; t=1157056051; x=1157920051; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fenton@cisco.com; z=From:Jim=20Fenton=20 |Subject:Threat=20analyses=20-=20guidance=20for=20future=20authors; X=v=3Dcisco.com=3B=20h=3DCwrPzD9PYkV5DtfO0ckhYGzJlak=3D; b=X2oT9EXmCSXUE5OWlKOhCsgMGDqCkRj0WIxb0OfkOOyE1EW2vNO0TZqU8C/s5ZWGF+c47mv2 9b604vSmUf1C+4NGnMW7V/OIMvKzU/jH0Zl5opuiMYecoLU+wox9YC/C; X-Barracuda-Virus-Scanned: by Barracuda Spam Firewall at edu X-Spam-Score: 0.479 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] Threat analyses - guidance for future authors X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2006 20:27:32 -0000 At the time a few of us started the DKIM Threat Analysis, we looked around to try to figure out what a threat analysis is supposed to say. The guidance that was available in the form of IETF-published threat analyses was inconsistent, so not surprisingly our first shot at it was not really in the right direction. If others are interested in collaborating, I'd be willing to lead/edit the creation of an internet-draft describing the suggested content and format of security threat analyses, for the benefit of future authors. I'm not saying that the DKIM threat analysis is necessarily the model here; in fact, it may be a bit of a special case. Are others interested in working on this? -Jim From mbaugher@cisco.com Thu Aug 31 17:49:31 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k7VLnVTW013460 for ; Thu, 31 Aug 2006 17:49:31 -0400 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k7VLnVY9002021 for ; Thu, 31 Aug 2006 17:49:31 -0400 (EDT) X-Barracuda-Connect: sj-iport-4.cisco.com[171.68.10.86] X-Barracuda-Start-Time: 1157060963 Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mit.edu (Spam Firewall) with ESMTP id 46ED410FD29 for ; Thu, 31 Aug 2006 17:49:23 -0400 (EDT) Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 31 Aug 2006 14:49:23 -0700 X-IronPort-AV: i="4.08,195,1154934000"; d="scan'208"; a="1851567500:sNHT31370512" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7VLnNOB023322 for ; Thu, 31 Aug 2006 14:49:23 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k7VLnNw7000324 for ; Thu, 31 Aug 2006 14:49:23 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Aug 2006 14:49:23 -0700 Received: from [192.168.0.10] ([10.21.83.75]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Aug 2006 14:49:23 -0700 In-Reply-To: <44F74633.3030904@cisco.com> References: <44F74633.3030904@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <858D8BB5-1A19-491E-8C3C-DA3D06A8F357@cisco.com> Content-Transfer-Encoding: 7bit From: Mark Baugher Date: Thu, 31 Aug 2006 14:49:21 -0700 To: Jim Fenton X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 31 Aug 2006 21:49:23.0103 (UTC) FILETIME=[5222EAF0:01C6CD47] DKIM-Signature: a=rsa-sha1; q=dns; l=1140; t=1157060963; x=1157924963; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mbaugher@cisco.com; z=From:Mark=20Baugher=20 |Subject:Re=3A=20[saag]=20Threat=20analyses=20-=20guidance=20for=20future=20autho rs; X=v=3Dcisco.com=3B=20h=3DFS99GIehnqMxOL8DVreW6RO6Asc=3D; b=rqXlsXbI7P1UNB7rv6PN6Y5iSV5GS90f1htn6mrdSbloOg2VHoK4y98xqeSvl7/UYL4LUQ9f lB4jkvKC6D06cCY5mAgSuaIdAMM8TznfgK9L46erTSWuN02TH3aXhrUx; Authentication-Results: sj-dkim-7.cisco.com; header.From=mbaugher@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Barracuda-Virus-Scanned: by Barracuda Spam Firewall at edu X-Spam-Score: 0.13 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] Threat analyses - guidance for future authors X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2006 21:49:31 -0000 PHB posted an asset, risks, threat analysis guide to this list during the Montreal meeting. I have used this method a few times with good overall results. This might be a good place to start. Mark On Aug 31, 2006, at 1:27 PM, Jim Fenton wrote: > At the time a few of us started the DKIM Threat Analysis, we looked > around to try to figure out what a threat analysis is supposed to say. > The guidance that was available in the form of IETF-published threat > analyses was inconsistent, so not surprisingly our first shot at it > was > not really in the right direction. > > If others are interested in collaborating, I'd be willing to lead/edit > the creation of an internet-draft describing the suggested content and > format of security threat analyses, for the benefit of future authors. > I'm not saying that the DKIM threat analysis is necessarily the model > here; in fact, it may be a bit of a special case. > > Are others interested in working on this? > > -Jim > _______________________________________________ > saag mailing list > saag@mit.edu > http://mailman.mit.edu/mailman/listinfo/saag From cchander@ida.org Thu Aug 31 18:04:20 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k7VM4Kkb015672 for ; Thu, 31 Aug 2006 18:04:20 -0400 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k7VM4KdV029627 for ; Thu, 31 Aug 2006 18:04:20 -0400 (EDT) X-Barracuda-Connect: exim2-out.ida.org[129.246.101.14] X-Barracuda-Start-Time: 1157061859 Received: from exim2-out.ida.org (exim2-out.ida.org [129.246.101.14]) by mit.edu (Spam Firewall) with ESMTP id F3FD57252B for ; Thu, 31 Aug 2006 18:04:19 -0400 (EDT) Received: by exim2-out.ida.org with local-smtp for ; Thu, 31 Aug 2006 18:04:12 -0400 Received: by exim2-out.ida.org with esmtp ; Thu, 31 Aug 2006 18:04:12 -0400 Received: from exch3k2.ida.org ([129.246.101.152]) by ex2kmail.ida.org with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Aug 2006 18:03:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Thu, 31 Aug 2006 18:03:45 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Threat analyses - guidance for future authors Thread-Index: AcbNR60uldBiEPxKTsyDv+hXMdLt8wAAZ6ug From: "Chandersekaran, Coimbatore" To: "Mark Baugher" , "Jim Fenton" X-OriginalArrivalTime: 31 Aug 2006 22:03:46.0430 (UTC) FILETIME=[54B829E0:01C6CD49] X-Barracuda-Virus-Scanned: by Barracuda Spam Firewall at edu X-Spam-Score: 0.72 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id k7VM4Kkb015672 Cc: saag@mit.edu Subject: Re: [saag] Threat analyses - guidance for future authors X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2006 22:04:20 -0000 Can you repost it please? -----Original Message----- From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu] On Behalf Of Mark Baugher Sent: Thursday, August 31, 2006 5:49 PM To: Jim Fenton Cc: saag@mit.edu Subject: Re: [saag] Threat analyses - guidance for future authors PHB posted an asset, risks, threat analysis guide to this list during the Montreal meeting. I have used this method a few times with good overall results. This might be a good place to start. Mark On Aug 31, 2006, at 1:27 PM, Jim Fenton wrote: > At the time a few of us started the DKIM Threat Analysis, we looked > around to try to figure out what a threat analysis is supposed to say. > The guidance that was available in the form of IETF-published threat > analyses was inconsistent, so not surprisingly our first shot at it > was > not really in the right direction. > > If others are interested in collaborating, I'd be willing to lead/edit > the creation of an internet-draft describing the suggested content and > format of security threat analyses, for the benefit of future authors. > I'm not saying that the DKIM threat analysis is necessarily the model > here; in fact, it may be a bit of a special case. > > Are others interested in working on this? > > -Jim > _______________________________________________ > saag mailing list > saag@mit.edu > http://mailman.mit.edu/mailman/listinfo/saag _______________________________________________ saag mailing list saag@mit.edu http://mailman.mit.edu/mailman/listinfo/saag From pekkas@netcore.fi Fri Sep 1 01:19:18 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k815JIED030879 for ; Fri, 1 Sep 2006 01:19:18 -0400 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k815JGj5029812 for ; Fri, 1 Sep 2006 01:19:19 -0400 (EDT) X-Barracuda-Connect: netcore.fi[193.94.160.1] X-Barracuda-Start-Time: 1157087952 Received: from netcore.fi (netcore.fi [193.94.160.1]) by mit.edu (Spam Firewall) with ESMTP id 1ED1CD122F for ; Fri, 1 Sep 2006 01:19:13 -0400 (EDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id k815J6Ri012543 for ; Fri, 1 Sep 2006 08:19:07 +0300 Date: Fri, 1 Sep 2006 08:19:06 +0300 (EEST) From: Pekka Savola To: saag@mit.edu In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Status: Clean X-Spam-Status: No, score=-0.0 required=5.0 tests=NO_RELAYS autolearn=failed version=3.1.4 X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-25) on otso.netcore.fi X-Barracuda-Virus-Scanned: by Barracuda Spam Firewall at edu X-Spam-Score: 0.12 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: Re: [saag] Remove tunnel mode from ipsec-tunnels-02? (fwd) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2006 05:19:18 -0000 On Thu, 13 Jul 2006, Pekka Savola wrote: > There seem to be more generic complications in applying tunnel mode > to v6-in-v4 tunnels, hence we're proposing to use only transport mode. > > Comments from (more) IPsec experts would also be welcome. Hello again, Unless we hear more comments on this, we propose to go forward with the initial suggestion of removing tunnel mode from the main specification. As there is indication of at least two implementations supporting "Specific-SPD, no-interface" modelling, that will likely still be mentioned in an appendix due to its more limited applicability. If you think the tunnel mode support should stay, you should describe how to make link-local traffic work in presence of multiple tunnels. If you have comments, please respond within a week. For the authors, > ---------- Forwarded message ---------- > Date: Wed, 12 Jul 2006 17:19:09 +0300 (EEST) > From: Pekka Savola > To: v6ops@ops.ietf.org > Subject: Remove tunnel mode from ipsec-tunnels-02? > > Hello, > > As proposed at the v6ops meeting [0], the authors of > draft-ietf-v6ops-ipsec-tunnels-02 propose to remove support for tunnel > mode in this particular context (securing v6-in-v4 configured > tunnels). > > This is due to issues spotted by Francis [1] and Pasi [2]. Generic > "::/0 -> ::/0" selectors could not be made to work without > interface-specific SPDs, and those cannot be signalled in IKE (that's > run on top of IPv4) when the tunnel would be IPv6 in a standardized > way. Generic selectors are required for link-local traffic (e.g., ND) > to work on the tunnel. > > If we go through with this proposed resolution, > draft-ietf-v6ops-ipsec-tunnels would only describe transport mode. > > Comments are welcome. > > [0] http://www3.ietf.org/proceedings/06jul/slides/v6ops-4.pdf > [1] http://ops.ietf.org/lists/v6ops/v6ops.2006/msg00159.html > [2] http://ops.ietf.org/lists/v6ops/v6ops.2006/msg00230.html > > For the authors of draft-ietf-v6ops-ipsec-tunnels-02, > > -- 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 marc.kolenko@gd-ais.com Fri Sep 1 12:32:49 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k81GWnXO009490 for ; Fri, 1 Sep 2006 12:32:49 -0400 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k81GWelU005298 for ; Fri, 1 Sep 2006 12:32:42 -0400 (EDT) X-Barracuda-Connect: mnbm01-relay1.mnb.gd-ais.com[206.11.149.22] X-Barracuda-Start-Time: 1157128104 X-Barracuda-Encrypted: DHE-RSA-AES256-SHA Received: from mnb.gd-ais.com (mnbm01-relay1.mnb.gd-ais.com [206.11.149.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id B0619CA1C8 for ; Fri, 1 Sep 2006 12:28:25 -0400 (EDT) Received: from ([10.13.13.25]) by mnbm01-relay1.mnb.gd-ais.com with SMTP id 5202712.3610693; Fri, 01 Sep 2006 11:25:58 -0500 Received: from vach02-mail01.ad.gd-ais.com ([10.5.1.58]) by vaff01-fes01.ad.gd-ais.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Sep 2006 12:27:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 1 Sep 2006 12:27:51 -0400 Message-ID: In-Reply-To: <44F74633.3030904@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Threat analyses - guidance for future authors Thread-Index: AcbN45HkH/jIscCVTBOrA3jXOPsHrA== From: "Kolenko, Marc" To: "Jim Fenton" , X-OriginalArrivalTime: 01 Sep 2006 16:27:52.0077 (UTC) FILETIME=[9233B3D0:01C6CDE3] X-Barracuda-Virus-Scanned: by Barracuda Spam Firewall at edu X-Spam-Score: 0.60 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id k81GWnXO009490 Subject: Re: [saag] Threat analyses - guidance for future authors X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2006 16:32:49 -0000 I would be very interested in participating, having worked on some similar initiatives here within General Dynamics. We are currently adopting aspects of X.805/X.800. What would be the easiest way to review what's currently in the DKIM? ____________________________________ Marc M. Kolenko, CISSP, NCTS General Dynamics Advanced Information Systems Office: 703.383.3602 Cell: 703.298.4521 GDAIS Private Information If you are not the addressee or authorized by the addressee to receive this e-mail, you may not disclose, copy, distribute or use this e-mail. If you have received this e-mail in error, please notify the sender immediately by reply e-mail or by telephone at (703) 807-5672 and destroy this message and any copies. Thank you -----Original Message----- From: Jim Fenton [mailto:fenton@cisco.com] Sent: Thursday, August 31, 2006 4:28 PM To: saag@mit.edu Subject: [saag] Threat analyses - guidance for future authors At the time a few of us started the DKIM Threat Analysis, we looked around to try to figure out what a threat analysis is supposed to say. The guidance that was available in the form of IETF-published threat analyses was inconsistent, so not surprisingly our first shot at it was not really in the right direction. If others are interested in collaborating, I'd be willing to lead/edit the creation of an internet-draft describing the suggested content and format of security threat analyses, for the benefit of future authors. I'm not saying that the DKIM threat analysis is necessarily the model here; in fact, it may be a bit of a special case. Are others interested in working on this? -Jim From marc.kolenko@gd-ais.com Fri Sep 1 12:34:35 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k81GYZGL009808 for ; Fri, 1 Sep 2006 12:34:35 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k81GYabk009277 for ; Fri, 1 Sep 2006 12:34:36 -0400 (EDT) X-Barracuda-Connect: mnbm01-relay1.mnb.gd-ais.com[206.11.149.22] X-Barracuda-Start-Time: 1157128475 X-Barracuda-Encrypted: DHE-RSA-AES256-SHA Received: from mnb.gd-ais.com (mnbm01-relay1.mnb.gd-ais.com [206.11.149.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 3F2E05361B for ; Fri, 1 Sep 2006 12:34:36 -0400 (EDT) Received: from ([160.207.224.15]) by mnbm01-relay1.mnb.gd-ais.com with SMTP id 5202712.3611182; Fri, 01 Sep 2006 11:34:20 -0500 Received: from vach02-mail01.ad.gd-ais.com ([10.5.1.58]) by mnbm01-fes01.ad.gd-ais.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Sep 2006 11:34:20 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 1 Sep 2006 12:34:18 -0400 Message-ID: In-Reply-To: <2E97C20EAEB9084682223727AB90F74A02878610@vach02-mail01.ad.gd-ais.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Threat analyses - guidance for future authors Thread-Index: AcbN45HkH/jIscCVTBOrA3jXOPsHrAAAF2JA From: "Kolenko, Marc" To: "Jim Fenton" , X-OriginalArrivalTime: 01 Sep 2006 16:34:20.0505 (UTC) FILETIME=[79B91C90:01C6CDE4] X-Barracuda-Virus-Scanned: by Barracuda Spam Firewall at edu X-Spam-Score: 0.60 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id k81GYZGL009808 Subject: Re: [saag] Threat analyses - guidance for future authors X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2006 16:34:35 -0000 ...Forgot to mention Jim that VOIPSA has done something similar in terms of publishing a draft entitled VoIP Security and Privacy, Threat Taxonomy Public Release 1.0, 24 October 2005... developed portions of this...which features some threat analysis, and mitigation/remediation recommendations... Cheers Marc -----Original Message----- From: Kolenko, Marc Sent: Friday, September 01, 2006 12:28 PM To: Jim Fenton; saag@mit.edu Subject: RE: [saag] Threat analyses - guidance for future authors I would be very interested in participating, having worked on some similar initiatives here within General Dynamics. We are currently adopting aspects of X.805/X.800. What would be the easiest way to review what's currently in the DKIM? ____________________________________ Marc M. Kolenko, CISSP, NCTS General Dynamics Advanced Information Systems Office: 703.383.3602 Cell: 703.298.4521 GDAIS Private Information If you are not the addressee or authorized by the addressee to receive this e-mail, you may not disclose, copy, distribute or use this e-mail. If you have received this e-mail in error, please notify the sender immediately by reply e-mail or by telephone at (703) 807-5672 and destroy this message and any copies. Thank you -----Original Message----- From: Jim Fenton [mailto:fenton@cisco.com] Sent: Thursday, August 31, 2006 4:28 PM To: saag@mit.edu Subject: [saag] Threat analyses - guidance for future authors At the time a few of us started the DKIM Threat Analysis, we looked around to try to figure out what a threat analysis is supposed to say. The guidance that was available in the form of IETF-published threat analyses was inconsistent, so not surprisingly our first shot at it was not really in the right direction. If others are interested in collaborating, I'd be willing to lead/edit the creation of an internet-draft describing the suggested content and format of security threat analyses, for the benefit of future authors. I'm not saying that the DKIM threat analysis is necessarily the model here; in fact, it may be a bit of a special case. Are others interested in working on this? -Jim From fenton@cisco.com Fri Sep 1 13:28:47 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k81HSjw0020759 for ; Fri, 1 Sep 2006 13:28:45 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k81HSfAl018824 for ; Fri, 1 Sep 2006 13:28:41 -0400 (EDT) X-Barracuda-Connect: sj-iport-1-in.cisco.com[171.71.176.70] X-Barracuda-Start-Time: 1157131717 Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by mit.edu (Spam Firewall) with ESMTP id B9E4F2190F for ; Fri, 1 Sep 2006 13:28:37 -0400 (EDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 01 Sep 2006 10:28:37 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k81HSbiW023201; Fri, 1 Sep 2006 10:28:37 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k81HSaYp003904; Fri, 1 Sep 2006 10:28:37 -0700 (PDT) Received: from [171.71.97.128] (dhcp-171-71-97-128.cisco.com [171.71.97.128]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k81HJUU8028635; Fri, 1 Sep 2006 10:19:30 -0700 Message-ID: <44F86DC4.6050507@cisco.com> Date: Fri, 01 Sep 2006 10:28:36 -0700 From: Jim Fenton User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: "Kolenko, Marc" References: In-Reply-To: X-Enigmail-Version: 0.93.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-2.cisco.com; header.From=fenton@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=2759; t=1157131717; x=1157995717; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fenton@cisco.com; z=From:Jim=20Fenton=20 |Subject:Re=3A=20[saag]=20Threat=20analyses=20-=20guidance=20for=20future=20autho rs; X=v=3Dcisco.com=3B=20h=3Dm8N4hPEM8g1M0R3TuvLFsrCMCuU=3D; b=g2+KU5OyvcEAQoEY6hroLB66gtwd3W5Zc6bpxChfmPUhdywyawtAzD7MC4cWCYWGnBAT//9Q e0lJZWhdVwH9sBdAPj7++ZSlyV/VSOLmZ4MhoDgWKlin2Yy4sJ6yCZj3; X-Barracuda-Virus-Scanned: by Barracuda Spam Firewall at edu X-Spam-Score: 0.12 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] Threat analyses - guidance for future authors X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2006 17:28:49 -0000 Marc, It looks like there's enough interest that I will be putting together a mailing list, so stand by for an announcement on that. The DKIM threat analysis can be found at: http://www.ietf.org/internet-drafts/draft-ietf-dkim-threats-03.txt or the prettier HTML version is at http://mipassoc.org/dkim/specs/draft-ietf-dkim-threats-03.html Do you have a pointer to the document you mention below? -Jim Kolenko, Marc wrote: > ...Forgot to mention Jim that VOIPSA has done something similar in terms > of publishing a draft entitled VoIP Security and Privacy, Threat > Taxonomy > Public Release 1.0, 24 October 2005... developed portions of > this...which features some threat analysis, and mitigation/remediation > recommendations... > Cheers > Marc > > > -----Original Message----- > From: Kolenko, Marc > Sent: Friday, September 01, 2006 12:28 PM > To: Jim Fenton; saag@mit.edu > Subject: RE: [saag] Threat analyses - guidance for future authors > > I would be very interested in participating, having worked on some > similar initiatives here within General Dynamics. We are currently > adopting aspects of X.805/X.800. > > What would be the easiest way to review what's currently in the DKIM? > > ____________________________________ > > Marc M. Kolenko, CISSP, NCTS > General Dynamics > Advanced Information Systems > Office: 703.383.3602 Cell: 703.298.4521 > > GDAIS Private Information > > If you are not the addressee or authorized by the addressee to receive > this e-mail, you may not disclose, copy, distribute or use this e-mail. > If you have received this e-mail in error, please notify the sender > immediately by reply e-mail or by telephone at (703) 807-5672 and > destroy this message and any copies. Thank you > > -----Original Message----- > From: Jim Fenton [mailto:fenton@cisco.com] > Sent: Thursday, August 31, 2006 4:28 PM > To: saag@mit.edu > Subject: [saag] Threat analyses - guidance for future authors > > At the time a few of us started the DKIM Threat Analysis, we looked > around to try to figure out what a threat analysis is supposed to say. > The guidance that was available in the form of IETF-published threat > analyses was inconsistent, so not surprisingly our first shot at it was > not really in the right direction. > > If others are interested in collaborating, I'd be willing to lead/edit > the creation of an internet-draft describing the suggested content and > format of security threat analyses, for the benefit of future authors. > I'm not saying that the DKIM threat analysis is necessarily the model > here; in fact, it may be a bit of a special case. > > Are others interested in working on this? > > -Jim > > From marc.kolenko@gd-ais.com Fri Sep 1 14:16:57 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k81IGvXV028054 for ; Fri, 1 Sep 2006 14:16:57 -0400 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k81IGm3g028646 for ; Fri, 1 Sep 2006 14:16:48 -0400 (EDT) X-Barracuda-Connect: CAMV02-RELAY2.CASC.GD-AIS.COM[192.5.164.99] X-Barracuda-Start-Time: 1157134602 X-Barracuda-Encrypted: DHE-RSA-AES256-SHA Received: from casc.gd-ais.com (CAMV02-RELAY2.CASC.GD-AIS.COM [192.5.164.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 772C5D7503 for ; Fri, 1 Sep 2006 14:16:43 -0400 (EDT) Received: from ([10.73.100.22]) by camv02-relay2.casc.gd-ais.com with SMTP id 5202701.3356211; Fri, 01 Sep 2006 11:16:19 -0700 Received: from vach02-mail01.ad.gd-ais.com ([10.5.1.58]) by camv02-fes01.ad.gd-ais.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Sep 2006 11:16:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 1 Sep 2006 14:16:15 -0400 Message-ID: In-Reply-To: <44F86DC4.6050507@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Threat analyses - guidance for future authors Thread-Index: AcbN7BsAn928KNATQeOlxVJ+l0/EKAABl2vA From: "Kolenko, Marc" To: "Jim Fenton" X-OriginalArrivalTime: 01 Sep 2006 18:16:19.0028 (UTC) FILETIME=[B8A5A140:01C6CDF2] X-Barracuda-Virus-Scanned: by Barracuda Spam Firewall at edu X-Spam-Score: 0.72 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id k81IGvXV028054 Cc: saag@mit.edu Subject: Re: [saag] Threat analyses - guidance for future authors X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2006 18:16:57 -0000 I'll include a link to VOIPSA here... http://www.voipsa.org/Activities/ cheers Marc ____________________________________ -----Original Message----- From: Jim Fenton [mailto:fenton@cisco.com] Sent: Friday, September 01, 2006 1:29 PM To: Kolenko, Marc Cc: saag@mit.edu Subject: Re: [saag] Threat analyses - guidance for future authors Marc, It looks like there's enough interest that I will be putting together a mailing list, so stand by for an announcement on that. The DKIM threat analysis can be found at: http://www.ietf.org/internet-drafts/draft-ietf-dkim-threats-03.txt or the prettier HTML version is at http://mipassoc.org/dkim/specs/draft-ietf-dkim-threats-03.html Do you have a pointer to the document you mention below? -Jim Kolenko, Marc wrote: > ...Forgot to mention Jim that VOIPSA has done something similar in terms > of publishing a draft entitled VoIP Security and Privacy, Threat > Taxonomy > Public Release 1.0, 24 October 2005... developed portions of > this...which features some threat analysis, and mitigation/remediation > recommendations... > Cheers > Marc > > > -----Original Message----- > From: Kolenko, Marc > Sent: Friday, September 01, 2006 12:28 PM > To: Jim Fenton; saag@mit.edu > Subject: RE: [saag] Threat analyses - guidance for future authors > > I would be very interested in participating, having worked on some > similar initiatives here within General Dynamics. We are currently > adopting aspects of X.805/X.800. > > What would be the easiest way to review what's currently in the DKIM? > > ____________________________________ > > Marc M. Kolenko, CISSP, NCTS > General Dynamics > Advanced Information Systems > Office: 703.383.3602 Cell: 703.298.4521 > > GDAIS Private Information > > If you are not the addressee or authorized by the addressee to receive > this e-mail, you may not disclose, copy, distribute or use this e-mail. > If you have received this e-mail in error, please notify the sender > immediately by reply e-mail or by telephone at (703) 807-5672 and > destroy this message and any copies. Thank you > > -----Original Message----- > From: Jim Fenton [mailto:fenton@cisco.com] > Sent: Thursday, August 31, 2006 4:28 PM > To: saag@mit.edu > Subject: [saag] Threat analyses - guidance for future authors > > At the time a few of us started the DKIM Threat Analysis, we looked > around to try to figure out what a threat analysis is supposed to say. > The guidance that was available in the form of IETF-published threat > analyses was inconsistent, so not surprisingly our first shot at it was > not really in the right direction. > > If others are interested in collaborating, I'd be willing to lead/edit > the creation of an internet-draft describing the suggested content and > format of security threat analyses, for the benefit of future authors. > I'm not saying that the DKIM threat analysis is necessarily the model > here; in fact, it may be a bit of a special case. > > Are others interested in working on this? > > -Jim > > From rlmorgan@washington.edu Fri Sep 15 13:03:13 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k8FH3Drs031530 for ; Fri, 15 Sep 2006 13:03:13 -0400 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k8FH3Bc7012088 for ; Fri, 15 Sep 2006 13:03:12 -0400 (EDT) Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu [140.142.32.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 2C088131DD4 for ; Fri, 15 Sep 2006 13:03:10 -0400 (EDT) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout1.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k8FH39FQ001448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 15 Sep 2006 10:03:09 -0700 X-Auth-Received: from [192.168.1.104] (c-67-170-100-234.hsd1.wa.comcast.net [67.170.100.234]) (authenticated authid=rlmorgan) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.03) with ESMTP id k8FH38Ew014693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 15 Sep 2006 10:03:09 -0700 Date: Fri, 15 Sep 2006 10:03:18 -0700 (PDT) From: "RL 'Bob' Morgan" X-X-Sender: rlmorgan@perf.cac.washington.edu To: SAAG list Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.2.0.266434, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.9.15.94443 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.12 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] [Public Review of WS-SX WS-SecureConversation v1.3 and WS-Trust v1.3] X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2006 17:03:13 -0000 FYI. These specs-for-review are part of the overall WS-* suite. WS-Trust is, more or less, a protocol for exchange of security tokens (I have X, I show X to a security server and get a Y, to present to an application server). WS-SecureConversation has been described as "TLS in SOAP". For those who might have heard of Microsoft's upcoming Cardspace component, it relies heavily on WS-Trust. Review is encouraged. (And to be clear, I wasn't involved in developing these, nor do I speak for the TC, though I am on the TC mailing list.) - RL "Bob" ---------- Forwarded message ---------- Date: Fri, 15 Sep 2006 12:04:52 -0400 From: Mary McRae To: members@lists.oasis-open.org, tc-announce@lists.oasis-open.org Cc: ws-sx@lists.oasis-open.org Subject: [ws-sx] FW: Public Review of WS-SX WS-SecureConversation v1.3 and WS-Trust v1.3 To OASIS members, Public Announce Lists: The OASIS Web Services Secure Exchange (WS-SX) TC has recently approved the following specifications as Committee Drafts and approved the package for public review: WS-SecureConversation 1.3 WS-Trust 1.3 The public review starts today, 15 September 2006, and ends 14 November 2006. This is an open invitation to comment. We strongly encourage feedback from potential users, developers and others, whether OASIS members or not, for the sake of improving the interoperability and quality of OASIS work. More non-normative information about the specification and the technical committee may be found at the public home page of the TC at http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-sx. Comments may be submitted to the TC by any person through the use of the OASIS TC Comment Facility which can be located via the button marked "Send A Comment" at the top of that page, or directly at http://www.oasis-open.org/committees/comments/index.php?wg_abbrev=ws-sx. Submitted comments (for this work as well as other works of that TC) are publicly archived and can be viewed at http://lists.oasis-open.org/archives/ws-sx-comment/. All comments submitted to OASIS are subject to the OASIS Feedback License, which ensures that the feedback you provide carries the same obligations at least as the obligations of the TC members. The specification document and related files are available here: WS-SecureConversation 1.3 Editable Source: http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512/ws-secureconversat ion-1.3-spec-cd-01.doc PDF: http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512/ws-secureconversat ion-1.3-spec-cd-01.pdf HTML: http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512/ws-secureconversat ion-1.3-spec-cd-01.html The schema files, that are included normatively in the specification document, are available as separate files at: Schema: http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512/ws-secureconversat ion-1.3.xsd WS-Trust 1.3 Editable Source: http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-spec-cd-01.doc PDF: http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-spec-cd-01.pdf HTML: http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-spec-cd-01.html The schema files, that are included normatively in the specification document, are available as separate files at: Schema: http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3.xsd WSDL: http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3.wsdl OASIS and the WS-SX TC welcome your comments. --------------------------------------------------- Mary P McRae Manager of TC Administration, OASIS email: mary.mcrae@oasis-open.org web: www.oasis-open.org From housley@vigilsec.com Mon Sep 18 13:42:13 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k8IHgBEv013181 for ; Mon, 18 Sep 2006 13:42:13 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k8IHgDsF001388 for ; Mon, 18 Sep 2006 13:42:13 -0400 (EDT) Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by mit.edu (Spam Firewall) with SMTP id D31D6838B8 for ; Mon, 18 Sep 2006 13:42:12 -0400 (EDT) Received: (qmail 5626 invoked by uid 0); 18 Sep 2006 17:42:08 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.83.235.104) by woodstock.binhost.com with SMTP; 18 Sep 2006 17:42:08 -0000 Message-Id: <7.0.0.16.2.20060918133548.07e7e8b8@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Mon, 18 Sep 2006 13:42:05 -0400 To: saag@mit.edu From: Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.13 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] KeyProv BoF has been Requested X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2006 17:42:13 -0000 The Security Area Directors have received a request for a BOF at IETF 67 on the Provisioning of Symmetric Keys (KEYPROV). The members of the KEYPROV mailing list have proposed a WG charter in response to feedback received at an informal meeting at IETF 66. BOF name: Provisioning of Symmetric Keys (KEYPROV) Area: Security Area BOF Chair Names: Phillip Hallam-Baker (VeriSign) Shuh Chang (GemAlto) Mailing list: ietf-keyprov at safehaus.org Please join the mail list if this topic is of interest to you. Russ -------- Proposed Charter -------- Provisioning of Symmetric Keys (KEYPROV) Background Current developments in inter-domain One Time Password (OTP) token and inter-domain use of Kerberos have highlighted the need for a standard protocol for provisioning symmetric keys. The need for provisioning protocols in PKI architectures has been recognized for some time. Although the existence and architecture of these protocols provides a feasibility proof for the KEYPROV work assumptions built into these protocol mean that it is not possible to apply them without substantial modification. In particular the ability to provision symmetric keys and associated attributes dynamically to already issued devices such as cell phones and USB drives is highly desirable. The working group will develop the necessary protocols and data formats required to support provisioning and management of symmetric key authentication tokens, both proprietary and standards based. Input Documents The following documents have been proposed by their authors as input documents: Portable Symmetric Key Container http://www.ietf.org/internet-drafts/draft-vassilev-portable-symmetric-key-container-00.txt Extensions to CT-KIP to support one- and two-pass key initialization http://www.ietf.org/internet-drafts/draft-nystrom-ct-kip-two-pass-00.txt Scope and Deliverables The scope of the working group shall be to define protocols and data formats necessary for provisioning of symmetric cryptographic keys and associated attributes. The working group will produce the following deliverables: Portable Symmetric Key Container Dynamic Symmetric Key Provisioning Protocol From housley@vigilsec.com Fri Sep 22 14:56:05 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k8MIu11O021347 for ; Fri, 22 Sep 2006 14:56:05 -0400 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k8MIu5DN004981 for ; Fri, 22 Sep 2006 14:56:05 -0400 (EDT) Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by mit.edu (Spam Firewall) with SMTP id 56194195A31 for ; Fri, 22 Sep 2006 14:56:03 -0400 (EDT) Received: (qmail 13426 invoked by uid 0); 22 Sep 2006 18:55:57 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.83.235.104) by woodstock.binhost.com with SMTP; 22 Sep 2006 18:55:57 -0000 Message-Id: <7.0.0.16.2.20060922145432.0416a560@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Fri, 22 Sep 2006 14:56:00 -0400 To: saag@mit.edu From: Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.13 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] Call for Participation: KeyProv BoF X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Sep 2006 18:56:05 -0000 I have just approved the KeyProv BOF for the San Diego IETF meeting. Again, if you are interested in this topic, please join the mail list. Russ >Date: Mon, 18 Sep 2006 13:42:05 -0400 >To: saag@mit.edu >From: Russ Housley >Subject: KeyProv BoF has been Requested > >The Security Area Directors have received a request for a BOF at >IETF 67 on the Provisioning of Symmetric Keys (KEYPROV). The >members of the KEYPROV mailing list have proposed a WG charter in >response to feedback received at an informal meeting at IETF 66. > >BOF name: Provisioning of Symmetric Keys (KEYPROV) >Area: Security Area >BOF Chair Names: > Phillip Hallam-Baker (VeriSign) > Shuh Chang (GemAlto) >Mailing list: ietf-keyprov at safehaus.org > >Please join the mail list if this topic is of interest to you. > >Russ > > >-------- Proposed Charter -------- > >Provisioning of Symmetric Keys (KEYPROV) > >Background > >Current developments in inter-domain One Time Password (OTP) token >and inter-domain use of Kerberos have highlighted the need for a >standard protocol for provisioning symmetric keys. > >The need for provisioning protocols in PKI architectures has been >recognized for some time. Although the existence and architecture of >these protocols provides a feasibility proof for the KEYPROV work >assumptions built into these protocol mean that it is not possible >to apply them without substantial modification. > >In particular the ability to provision symmetric keys and associated >attributes dynamically to already issued devices such as cell phones >and USB drives is highly desirable. The working group will develop >the necessary protocols and data formats required to support >provisioning and management of symmetric key authentication tokens, >both proprietary and standards based. > >Input Documents >The following documents have been proposed by their authors as input >documents: > >Portable Symmetric Key Container > >http://www.ietf.org/internet-drafts/draft-vassilev-portable-symmetric-key-container-00.txt > > >Extensions to CT-KIP to support one- and two-pass key initialization > >http://www.ietf.org/internet-drafts/draft-nystrom-ct-kip-two-pass-00.txt > >Scope and Deliverables >The scope of the working group shall be to define protocols and data >formats necessary for provisioning of symmetric cryptographic keys >and associated attributes. > >The working group will produce the following deliverables: > >Portable Symmetric Key Container >Dynamic Symmetric Key Provisioning Protocol From mnystrom@rsasecurity.com Mon Sep 25 08:20:36 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k8PCKasr030672 for ; Mon, 25 Sep 2006 08:20:36 -0400 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k8PCKeUS002183 for ; Mon, 25 Sep 2006 08:20:41 -0400 (EDT) Received: from tholian.rsasecurity.com (tholian.rsasecurity.com [216.162.240.129]) by mit.edu (Spam Firewall) with ESMTP id 2F22713BA59 for ; Mon, 25 Sep 2006 08:20:40 -0400 (EDT) Received: from hyperion.rsasecurity.com by tholian.rsasecurity.com via smtpd (for M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) with ESMTP; Mon, 25 Sep 2006 08:20:24 -0400 Received: from sdtihq24.securid.com (sdtihq24.na.rsa.net [10.100.8.152]) by hyperion.na.rsa.net (MOS 3.7.4b-GA) with ESMTP id CSD26230; Mon, 25 Sep 2006 08:32:20 +0500 (GMT-5) Received: from rsana-ex-hq2.NA.RSA.NET (rsana-ex-hq2.na.rsa.net [10.100.8.51]) by sdtihq24.securid.com (8.12.10/8.12.9) with ESMTP id k8PCKViQ027758 for ; Mon, 25 Sep 2006 08:20:37 -0400 (EDT) Received: from rsana-ex-sm1.NA.RSA.NET ([10.80.211.17]) by rsana-ex-hq2.NA.RSA.NET with Microsoft SMTPSVC(6.0.3790.211); Mon, 25 Sep 2006 08:20:32 -0400 Received: from localhost ([10.133.240.22]) by rsana-ex-sm1.NA.RSA.NET with Microsoft SMTPSVC(6.0.3790.211); Mon, 25 Sep 2006 05:20:50 -0700 Date: Mon, 25 Sep 2006 14:19:38 +0200 (W. Europe Daylight Time) From: =?iso-8859-1?Q?Magnus_Nystr=F6m?= To: saag@mit.edu Message-ID: X-X-Sender: mnystrom@[10.80.211.17] MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 25 Sep 2006 12:20:50.0329 (UTC) FILETIME=[09AA7090:01C6E09D] X-Spam-Score: 0.12 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] Draft amendment to PKCS #5 v2.0 for XMLDsig and XMLEnc X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Reply-To: magnus@rsasecurity.com List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2006 12:20:36 -0000 Dear All, I just wanted to inform the SAAG about the existence of this draft amendment, available from: http://www.rsasecurity.com/rsalabs/node.asp?id=2127 and solicit feedback on the proposal - feedback would preferably sent to the pkcs-editor@rsasecurity.com or to the pkcs-tng mailing list (pkcs-tng@rsasecurity.com). The intent with this amendment is as follows: PKCS #5 Version 2.0 defines a number of functions and schemes related to password-based cryptography. To make use of these constructs in an interoperable manner, PKCS #5 v2.0 provides an ASN.1 module containing object identifiers identifying the defined algorithms and ASN.1 type definitions for their parameters. This enables the exchange of PKCS #5-derived data in ASN.1-oriented environments. What's been missing is an XML schema for these constructs, enabling use of PKCS #5 in XML-oriented environments. An example of this is when XML encryption is used to protect data and keys that protect the data are derived from pass-phrases. This amendment tries to bridge this gap. Regards, -- Magnus From housley@vigilsec.com Thu Sep 28 14:51:22 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k8SIpMoS008066 for ; Thu, 28 Sep 2006 14:51:22 -0400 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k8SIpM7o002931 for ; Thu, 28 Sep 2006 14:51:23 -0400 (EDT) Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by mit.edu (Spam Firewall) with SMTP id 62BB6135950 for ; Thu, 28 Sep 2006 14:51:21 -0400 (EDT) Received: (qmail 6160 invoked by uid 0); 28 Sep 2006 18:51:15 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.126.161.75) by woodstock.binhost.com with SMTP; 28 Sep 2006 18:51:15 -0000 Message-Id: <7.0.0.16.2.20060928144913.0419a610@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Thu, 28 Sep 2006 14:50:00 -0400 To: saag@mit.edu From: Russ Housley Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" X-Spam-Score: 0.14 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] Fwd: Reminder: security activity proposal X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2006 18:51:22 -0000 Some people on this list may be interested ...

Resent-From: public-usable-authentication@w3.org
From: Thomas Roessler <tlr@w3.org>
Date: September 28, 2006 12:56:32 AM PDT
To: public-usable-authentication@w3.org
Subject: Reminder: security activity proposal

Hello,

this is a quick reminder that the security activity proposal (i.e.,
the formal stuff around the proposed Web Security Context WG [1]) is
up for AC review through 6 October.

Those of you who want to participate in this work and haven't talked
to their W3C AC reps, yet, should do so soon; I'm very happy to help
find the relevant contact information if needed.

If you do not have an AC representative, yet, and want to
participate, pleae contact me off-list.

1. http://www.w3.org/2005/Security/wsc-charter

Thanks,
--
Thomas Roessler, W3C   <tlr@w3.org>

From hartmans@MIT.EDU Fri Sep 29 14:33:51 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k8TIXpFS000708 for ; Fri, 29 Sep 2006 14:33:51 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k8TIXrGO014636 for ; Fri, 29 Sep 2006 14:33:53 -0400 (EDT) Received: from carter-zimmerman.mit.edu (STRATTON-FOUR-THIRTY-TWO.MIT.EDU [18.187.6.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 1CF3611C2A8 for ; Fri, 29 Sep 2006 14:33:49 -0400 (EDT) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id BB73CE0128; Fri, 29 Sep 2006 14:33:49 -0400 (EDT) From: Sam Hartman To: saag@MIT.EDU, ipsec@ietf.org Date: Fri, 29 Sep 2006 14:33:49 -0400 Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: tsvwg-chairs@tools.ietf.org Subject: [saag] tsvwg, preemption and rsvp: exposing characteristics of confidential traffic X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Sep 2006 18:33:51 -0000 There are two RSVP drafts before the IESG or in last call that affect the security community. The first is draft-ietf-tsvwg-rsvp-ipsec and the second is draft-ietf-tsvwg-vpn-signal-preemption. These drafts set up a model under which each precedence class of data from a preemption standpoint goes over its own SA and uses its own aggregate RSVP reservation. What that means is you expose on the unprotected side of the interface what fraction of your traffic is at each precedence level. First question: Is this new or something we have signed onto in the past? Obviously, it is sometimes desirable to set things up this way. However if this is new, are we happy with this being a requirement? Are there situations where the distribution of traffic precedences is sufficiently sensitive that we'd rather make ugly tradeoffs than expose it? I'd appreciate your input on these questions and any comments you have on the two drafts. Thanks, Sam Hartman Security Area Director From sommerfeld@sun.com Fri Sep 29 14:48:27 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k8TImJCO002965 for ; Fri, 29 Sep 2006 14:48:19 -0400 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k8TIl6nx028302 for ; Fri, 29 Sep 2006 14:47:07 -0400 (EDT) Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by mit.edu (Spam Firewall) with ESMTP id 71BAA16E163; Fri, 29 Sep 2006 14:47:06 -0400 (EDT) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k8TIl09c002994; Fri, 29 Sep 2006 11:47:00 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k8TIkxIO025171; Fri, 29 Sep 2006 14:46:59 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.7+Sun/8.13.7) with ESMTP id k8TIkxwA019744; Fri, 29 Sep 2006 14:46:59 -0400 (EDT) From: Bill Sommerfeld To: Sam Hartman In-Reply-To: References: Content-Type: text/plain Date: Fri, 29 Sep 2006 14:46:59 -0400 Message-Id: <1159555619.16677.89.camel@thunk> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.01 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, ipsec@ietf.org, tsvwg-chairs@tools.ietf.org Subject: Re: [saag] tsvwg, preemption and rsvp: exposing characteristics of confidential traffic X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Sep 2006 18:48:27 -0000 On Fri, 2006-09-29 at 14:33 -0400, Sam Hartman wrote: > These drafts set up a model under which each precedence class of data > from a preemption standpoint goes over its own SA and uses its own > aggregate RSVP reservation. What that means is you expose on the > unprotected side of the interface what fraction of your traffic is at > each precedence level. > > First question: Is this new or something we have signed onto in the > past? it's something we've signed on to in the past in the context of diffserv; the architecture is such that the actual preemption/priority/etc mechanism is almost completely opaque to IPsec. See rfc4301, halfway into section 4.1 (starting near the bottom of page 13): If different classes of traffic (distinguished by Differentiated Services Code Point (DSCP) bits [NiBlBaBL98], [Gro02]) are sent on the same SA, and if the receiver is employing the optional anti-replay feature available in both AH and ESP, this could result in inappropriate discarding of lower priority packets due to the windowing mechanism used by this feature. Therefore, a sender SHOULD put traffic of different classes, but with the same selector values, on different SAs to support Quality of Service (QoS) appropriately. To permit this, the IPsec implementation MUST permit establishment and maintenance of multiple SAs between a given sender and receiver, with the same selectors. Distribution of traffic among these parallel SAs to support QoS is locally determined by the sender and is not negotiated by IKE. The receiver MUST process the packets from the different SAs without prejudice. These requirements apply to both transport and tunnel mode SAs. In the case of tunnel mode SAs, the DSCP values in question appear in the inner IP header. In transport mode, the DSCP value might change en route, but this should not cause problems with respect to IPsec processing since the value is not employed for SA selection and MUST NOT be checked as part of SA/packet validation. However, if significant re-ordering of packets occurs in an SA, e.g., as a result of changes to DSCP values en route, this may trigger packet discarding by a receiver due to application of the anti-replay mechanism. seems obvious to extend this to rsvp or any other scheme which involves intentional packet reordering by the network. From hartmans@MIT.EDU Fri Sep 29 15:09:37 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k8TJ9b4P006647 for ; Fri, 29 Sep 2006 15:09:37 -0400 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k8TJ9hZd004461 for ; Fri, 29 Sep 2006 15:09:43 -0400 (EDT) Received: from carter-zimmerman.mit.edu (STRATTON-FOUR-THIRTY-TWO.MIT.EDU [18.187.6.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id CD3D41CC6E7 for ; Fri, 29 Sep 2006 15:09:42 -0400 (EDT) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id B3C78E0128; Fri, 29 Sep 2006 15:09:33 -0400 (EDT) From: Sam Hartman To: Bill Sommerfeld References: <1159555619.16677.89.camel@thunk> Date: Fri, 29 Sep 2006 15:09:33 -0400 In-Reply-To: <1159555619.16677.89.camel@thunk> (Bill Sommerfeld's message of "Fri, 29 Sep 2006 14:46:59 -0400") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, ipsec@ietf.org, tsvwg-chairs@tools.ietf.org Subject: Re: [saag] tsvwg, preemption and rsvp: exposing characteristics of confidential traffic X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Sep 2006 19:09:37 -0000 >>>>> "Bill" == Bill Sommerfeld writes: Bill> On Fri, 2006-09-29 at 14:33 -0400, Sam Hartman wrote: >> These drafts set up a model under which each precedence class >> of data from a preemption standpoint goes over its own SA and >> uses its own aggregate RSVP reservation. What that means is >> you expose on the unprotected side of the interface what >> fraction of your traffic is at each precedence level. >> >> First question: Is this new or something we have signed onto in >> the past? Bill> it's something we've signed on to in the past in the context Bill> of diffserv; the architecture is such that the actual Bill> preemption/priority/etc mechanism is almost completely Bill> opaque to IPsec. I was aware of the text you cite below, but: Bill> See rfc4301, halfway into section 4.1 (starting near the Bill> bottom of page 13): Bill> If different classes of traffic (distinguished by Bill> Differentiated Services Code Point (DSCP) bits [NiBlBaBL98], Bill> [Gro02]) are sent on the same SA, and if the receiver is Bill> employing the optional anti-replay feature available in both Bill> AH and ESP, this could result in inappropriate discarding of Bill> lower priority packets due to the windowing mechanism used Bill> by this feature. Therefore, a sender SHOULD put traffic of Bill> different classes, but with the same selector values, on Bill> different SAs to support Quality of Service (QoS) Bill> appropriately. To permit this, the IPsec implementation Bill> MUST permit establishment and maintenance of multiple SAs Bill> between a given sender and receiver, with the same Bill> selectors. Distribution of traffic among these parallel SAs Bill> to support QoS is locally determined by the sender and is Bill> not negotiated by IKE. The receiver MUST process the Bill> packets from the different SAs without prejudice. These Bill> requirements apply to both transport and tunnel mode SAs. Bill> In the case of tunnel mode SAs, the DSCP values in question Bill> appear in the inner IP header. In transport mode, the DSCP Bill> value might change en route, but this should not cause Bill> problems with respect to IPsec processing since the value is Bill> not employed for SA selection and MUST NOT be checked as Bill> part of SA/packet validation. However, if significant Bill> re-ordering of packets occurs in an SA, e.g., as a result of Bill> changes to DSCP values en route, this may trigger packet Bill> discarding by a receiver due to application of the Bill> anti-replay mechanism. That says sender SHOULD and the implementation MUST support, which means we've signed onto it as an option, not as a requirement. --Sam From Black_David@emc.com Fri Sep 29 18:20:30 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k8TMKSrt016913 for ; Fri, 29 Sep 2006 18:20:28 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k8TMKYBB027518 for ; Fri, 29 Sep 2006 18:20:34 -0400 (EDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id BE6851266A3; Fri, 29 Sep 2006 18:20:33 -0400 (EDT) Received: from mailhub.lss.emc.com (uraeus.lss.emc.com [10.254.144.14]) by mexforward.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k8TMKOVO006746; Fri, 29 Sep 2006 18:20:24 -0400 (EDT) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k8TMKJMk012889; Fri, 29 Sep 2006 18:20:20 -0400 (EDT) From: Black_David@emc.com Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 29 Sep 2006 18:01:23 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] tsvwg, preemption and rsvp: exposing characteristics of confidentialtraffic thread-index: Acbj9mol+vmyK8cHTnSbIyQ6vL4/PAAE7wFQ To: , , X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.9.29.145442 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, NO_REAL_NAME 0, __C230066_P5 0, __CP_NOT_1 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CTYPE_CHARSET_QUOTED 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 1.27 X-Spam-Level: * (1.27) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id k8TMKSrt016913 Cc: tsvwg-chairs@tools.ietf.org, flefauch@cisco.com, fred@cisco.com Subject: Re: [saag] tsvwg, preemption and rsvp: exposing characteristics of confidentialtraffic X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Sep 2006 22:20:30 -0000 Sam, The terminology in this space is confusing, and used in different ways in different documents, so let's stick to this clarification from Section 1 of the VPN Signaled Preemption draft: For the purposes of the present discussion, "priority" is a set of algorithms applied to datagrams, where "precedence" is a policy attribute of sessions. In other words, "priority" is about traffic handling (e.g., Diffserv) whereas "precedence" is about admission control. Despite this, the VPN Signaled Preemption draft then proceeds to use "Priority" (NB: first letter capitalized) for things that are actually "precedence". For example, in Section 1.3: Preemption of a reservation is specified in the context, in [RFC3181] which in essence specifies that a reservation installed in the network using an Preemption Priority and retained using a separate Defending Priority may be removed by the network via an RESV Error signal that removes the entire reservation. That's an unfortunate source of confusion. I would strongly encourage the authors to clean this up, particularly their unfortunate use of '"priority"' as a precedence level in Sections 2.3.3 and 2.3.4 (example quoted below in this message). In order to avoid further confusion, I will use the phrase "Diffserv priority" to refer to priority for datagram traffic handling. Nonetheless, on your concern: > These drafts set up a model under which each precedence class of data > from a preemption standpoint goes over its own SA and uses its own > aggregate RSVP reservation. What that means is you expose on the > unprotected side of the interface what fraction of your traffic is at > each precedence level. Actually, only the vpn-signaled-preemption draft appears to do this. The rsvp-ipsec draft allows multiple reservations between the same endpoints for the same DSCP, which would allow such traffic to use different tunnels but if it requires traffic for different reservations to use different tunnels, I was not able to find a statement of that requirement. OTOH, the vpn-signaled-preemption draft is quite clear that different precedence levels for the same DSCP result in different IPsec tunnels. Section 2.3.3 says: Due to the mechanics of preemption, however, this would not expand the existing "routine" reservations in the interface and inner domains, as doing this causes loss of information - how much of the reservation is now "routine" and how much is "priority"? Rather, this new reservation will open up a separate set of tunnels or security associations for traffic of its application class at its precedence between that aggregator and deaggregator. Here, "priority" is being used in its "Priority" sense as a level of precedence. The concern I have here is that the second sentence quoted above does not immediately follow from the first - there's a missing logical step in asserting that if the aggregate traffic for a DSCP (single Diffserv priority level) exceeds the reserved and/or available capacity then the policing of that traffic to the appropriate limit MUST respect precedence (i.e., delay/drop/shape "routine" traffic before "priority" traffic). That requirement should be asserted and defended in the vpn-signaled-preemption draft, because it is what leads to your concern. Meeting that requirement in general requires segregation of traffic at each precedence level within a single Diffserv priority, and because the reservation identity is not marked on the datagrams, separate IPsec tunnels are needed to do this, thus making precedence distinctions within a Diffserv priority visible to traffic analysis between the VPN routers. At least, that's what I think is going on (the confusing use of the 'priority' word doesn't help). I've added Fred Baker and Francois LeFaucheur to the cc: line so that they can correct anything I've gotten wrong. If my above explanation is correct, I can answer your first question: > First question: Is this new or something we have signed onto > in the past? I'm the author of RFC 2983, the initial source of the concepts in the RFC 4301 text that Bill Sommerfeld quoted, and I was involved in making sure that RFC 4301 covered that issue. IMHO, from a Diffserv and IPsec standpoint, I believe this is new and (as stated above), I think the vpn-signaled-preemption draft should state and defend this precedence-aware-traffic-conditioning requirement. That discussion could then be expanded to cover your second question: > Obviously, it is sometimes desirable to set things up this way. > However if this is new, are we happy with this being a requirement? > Are there situations where the distribution of traffic precedences is > sufficiently sensitive that we'd rather make ugly tradeoffs than > expose it? I share your concern about this being a requirement. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: saag-bounces@MIT.EDU [mailto:saag-bounces@MIT.EDU] On > Behalf Of Sam Hartman > Sent: Friday, September 29, 2006 2:34 PM > To: saag@MIT.EDU; ipsec@ietf.org > Cc: tsvwg-chairs@tools.ietf.org > Subject: [saag] tsvwg,preemption and rsvp: exposing > characteristics of confidentialtraffic > > > > > > There are two RSVP drafts before the IESG or in last call that affect > the security community. > > > The first is draft-ietf-tsvwg-rsvp-ipsec and the second is > draft-ietf-tsvwg-vpn-signal-preemption. > > > These drafts set up a model under which each precedence class of data > from a preemption standpoint goes over its own SA and uses its own > aggregate RSVP reservation. What that means is you expose on the > unprotected side of the interface what fraction of your traffic is at > each precedence level. > > First question: Is this new or something we have signed onto in the > past? > > Obviously, it is sometimes desirable to set things up this way. > However if this is new, are we happy with this being a requirement? > Are there situations where the distribution of traffic precedences is > sufficiently sensitive that we'd rather make ugly tradeoffs than > expose it? > > > I'd appreciate your input on these questions and any comments you have > on the two drafts. > > Thanks, > > Sam Hartman > Security Area Director > > > _______________________________________________ > saag mailing list > saag@mit.edu > http://mailman.mit.edu/mailman/listinfo/saag > From Black_David@emc.com Fri Sep 29 19:22:59 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k8TNMxp4028058 for ; Fri, 29 Sep 2006 19:22:59 -0400 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k8TNN62h011359 for ; Fri, 29 Sep 2006 19:23:06 -0400 (EDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id BDFE217E9F9; Fri, 29 Sep 2006 19:23:05 -0400 (EDT) Received: from mailhub.lss.emc.com (uraeus.lss.emc.com [10.254.144.14]) by mexforward.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k8TNN0Zb004840; Fri, 29 Sep 2006 19:23:00 -0400 (EDT) Received: from corpussmtp4.corp.emc.com (corpussmtp4.corp.emc.com [10.254.64.54]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k8TNMw0R013891; Fri, 29 Sep 2006 19:22:58 -0400 (EDT) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.13]) by corpussmtp4.corp.emc.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 29 Sep 2006 19:22:58 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 29 Sep 2006 19:22:57 -0400 Message-ID: In-Reply-To: <36E4499D-2CA2-4FAD-B929-26D0482B6220@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] tsvwg, preemption and rsvp: exposing characteristics of confidentialtraffic Thread-Index: AcbkG0Op86EV886IRqGV01JA7DUjjAAASV7Q To: X-OriginalArrivalTime: 29 Sep 2006 23:22:58.0283 (UTC) FILETIME=[330623B0:01C6E41E] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.9.29.155442 X-PerlMx-Spam: Gauge=, SPAM=2%, Reason='EMC_FROM_0+ -2, NO_REAL_NAME 0, __CT 0, __CTE 0, __CTYPE_CHARSET_QUOTED 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 1.15 X-Spam-Level: * (1.15) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id k8TNMxp4028058 Cc: saag@mit.edu, ipsec@ietf.org, tsvwg-chairs@tools.ietf.org, hartmans-ietf@mit.edu, flefauch@cisco.com Subject: Re: [saag] tsvwg, preemption and rsvp: exposing characteristics of confidentialtraffic X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Sep 2006 23:23:00 -0000 Fred, This looks like a good approach. Please check the rest of the draft for more "residual verbiage about tunnels", as there's also potentially problematic text in at least Sections 2.1 and 2.3.1 In 2.1, there are a number of places where use of singular "reservation" instead of plural "reservations" may imply that there is one aggregate reservation for the tunnel. Also, please consider how the approach in this draft ought to be applied to a PHB that consists of multiple DSCPs (e.g., an AF class, cf. RFC 2597). I believe AF is not a good fit to the sort of traffic that motivated this draft, so explaining that may suffice. Thanks, --David > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > Sent: Friday, September 29, 2006 6:59 PM > To: Black, David > Cc: hartmans-ietf@MIT.EDU; saag@MIT.EDU; ipsec@ietf.org; > tsvwg-chairs@tools.ietf.org; flefauch@cisco.com > Subject: Re: [saag] tsvwg,preemption and rsvp: exposing > characteristics of confidentialtraffic > > hmm. It sounds like there is some residual verbiage about tunnels in > the vpn-signaled-preemption draft. > > Bottom line, both drafts call for a common DSCP. Both require > multiple reservations by vport in the RSVP signaling, with the vport > indicating anything that the network administrator wants it to > indicate, and the vpn-signaling draft specifically saying that the > network administrator in question is requesting that it signify call > precedence. Call precedence is, in reality, not signaled by the vport > number, but by the priorities signaled in the RFC3181-clone priority > (precedence) fields of the rsvp draft, but the values used for the > vports have to be agreed upon throughout the network in order to name > the resulting reservations so they can be "discussed" among the > equipment. > > I am willing to clean up the use of "priority" and "precedence" as > you suggest and clean up this paragraph, along with Jari's > "discuss" (as in, "remove a section the principal client of the draft > asked to have written into it"). I think it's fair to ask for any > remaining IESG comment before doing so... > > On Sep 29, 2006, at 3:01 PM, Black_David@emc.com wrote: > > > Actually, only the vpn-signaled-preemption draft appears to do this. > > > > The rsvp-ipsec draft allows multiple reservations between the same > > endpoints for the same DSCP, which would allow such traffic to use > > different tunnels but if it requires traffic for different > > reservations to use different tunnels, I was not able to find > > a statement of that requirement. > > > > OTOH, the vpn-signaled-preemption draft is quite clear that different > > precedence levels for the same DSCP result in different IPsec tunnels. > > Section 2.3.3 says: > > > > Due to > > the mechanics of preemption, however, this would not expand the > > existing "routine" reservations in the interface and inner domains, > > as doing this causes loss of information - how much of the > > reservation is now "routine" and how much is "priority"? Rather, > > this new reservation will open up a separate set of tunnels or > > security associations for traffic of its application class at its > > precedence between that aggregator and deaggregator. > From Black_David@emc.com Mon Oct 2 09:42:11 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k92Dg9Aj004114 for ; Mon, 2 Oct 2006 09:42:09 -0400 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k92DgAEf001848 for ; Mon, 2 Oct 2006 09:42:11 -0400 (EDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 6EEC51DF17B; Mon, 2 Oct 2006 09:42:10 -0400 (EDT) Received: from mailhub.lss.emc.com (uraeus.lss.emc.com [10.254.144.14]) by mexforward.lss.emc.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k92DfrVM013569; Mon, 2 Oct 2006 09:41:53 -0400 (EDT) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k92DeqAG013834; Mon, 2 Oct 2006 09:41:51 -0400 (EDT) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.13]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 2 Oct 2006 09:41:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 2 Oct 2006 09:41:25 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] tsvwg, preemption and rsvp: exposing characteristics of confidentialtraffic Thread-Index: AcbmCozgS1x9wBpHT+iMb8LHSyJ9fgAHPd1w To: X-OriginalArrivalTime: 02 Oct 2006 13:41:26.0349 (UTC) FILETIME=[750CC7D0:01C6E628] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.10.2.61442 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTE 0, __CTYPE_CHARSET_QUOTED 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 1.15 X-Spam-Level: * (1.15) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id k92Dg9Aj004114 Cc: ipsec@ietf.org, tsvwg-chairs@tools.ietf.org, fred@cisco.com, saag@mit.edu, hartmans-ietf@mit.edu, black_david@emc.com Subject: Re: [saag] tsvwg, preemption and rsvp: exposing characteristics of confidentialtraffic X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2006 13:42:11 -0000 Francois, The concern about how to use a PHB consisting of multiple DSCPs (e.g., AF) also applies to the rsvp-ipsec draft. Using PHBIDs (cf. RFC 3140) may help address this, and this concern may also affect RFC 3175. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: Francois Le Faucheur [mailto:flefauch@cisco.com] > Sent: Monday, October 02, 2006 6:03 AM > To: Black, David > Cc: Francois Le Faucheur; hartmans-ietf@MIT.EDU; > saag@MIT.EDU; ipsec@ietf.org; tsvwg-chairs@tools.ietf.org; > fred@cisco.com > Subject: Re: [saag] tsvwg,preemption and rsvp: exposing > characteristics of confidentialtraffic > > Hello, > > Just expanding on Dave's observation: > > >> These drafts set up a model under which each precedence class of data > >> from a preemption standpoint goes over its own SA and uses its own > >> aggregate RSVP reservation. What that means is you expose on the > >> unprotected side of the interface what fraction of your traffic is at > >> each precedence level. > > > > Actually, only the vpn-signaled-preemption draft appears to do this. > > > > The rsvp-ipsec draft allows multiple reservations between the same > > endpoints for the same DSCP, which would allow such traffic to use > > different tunnels but if it requires traffic for different > > reservations to use different tunnels, I was not able to find > > a statement of that requirement. > > > > Right. > The rsvp-ipsec draft effectively decorelates the aggregate > reservations from the security associations (this was done as a > result of the first round of Security Experts review we got). So, for > example,: > * it allows to set up multiple aggregate reservations using a single SA > * it allows to setup one aggregate reservation per SA > * it does not force/mandate either of these modes. > > The logic is to provide a generic mechanism which may be used in > different ways, in particular in the way(s) discussed in vpn-signaled-preemption. > rsvp-ipsec refers to vpn-signaled-preemption's Security > Considerations for when used as per vpn-signaled-preemption. > > Cheers > > Francois From magnus.westerlund@ericsson.com Mon Oct 2 09:46:21 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k92DkLZZ005186 for ; Mon, 2 Oct 2006 09:46:21 -0400 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k92DkQGg008798 for ; Mon, 2 Oct 2006 09:46:26 -0400 (EDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by mit.edu (Spam Firewall) with ESMTP id 65D4E13E103 for ; Mon, 2 Oct 2006 09:46:25 -0400 (EDT) Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7A4A84F0203 for ; Mon, 2 Oct 2006 15:42:23 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.173]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Oct 2006 14:54:40 +0200 Received: from [147.214.30.247] ([147.214.30.247]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Oct 2006 12:46:16 +0200 Message-ID: <4520EDF8.90806@ericsson.com> Date: Mon, 02 Oct 2006 12:46:16 +0200 From: Magnus Westerlund User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: SAAG Content-Type: multipart/mixed; boundary="------------020305050604060100050104" X-OriginalArrivalTime: 02 Oct 2006 10:46:16.0555 (UTC) FILETIME=[FCB97BB0:01C6E60F] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.72 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] [Fwd: [Tsvwg] Last Call: 'Generic Aggregate RSVP Reservations' to Proposed Standard (draft-ietf-tsvwg-rsvp-ipsec)] X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Oct 2006 13:46:21 -0000 This is a multi-part message in MIME format. --------------020305050604060100050104 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit In relation to the Question Sam raised, here is the IETF last call. Cheers Magnus Westerlund TSV AD --------------020305050604060100050104 Content-Type: message/rfc822; name*0="[Tsvwg] Last Call: 'Generic Aggregate RSVP Reservations' to Prop"; name*1="osed Standard (draft-ietf-tsvwg-rsvp-ipsec)" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="[Tsvwg] Last Call: 'Generic Aggregate RSVP Reservations' to "; filename*1="Proposed Standard (draft-ietf-tsvwg-rsvp-ipsec)" Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw103.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Sep 2006 16:38:31 +0200 Received: from mailgw1.ericsson.se ([193.180.251.59]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Sep 2006 16:38:30 +0200 Received: from megatron.ietf.org (optimus.ietf.org [156.154.16.145]) by mailgw1.ericsson.se (Symantec Mail Security) with ESMTP id EB3DA7BF; Fri, 29 Sep 2006 16:38:29 +0200 (CEST) Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTJU5-0007ot-V3; Fri, 29 Sep 2006 10:37:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GTJU3-0007mp-It; Fri, 29 Sep 2006 10:36:59 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GTJU3-00065J-H4; Fri, 29 Sep 2006 10:36:59 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GTJU0-0002fr-U3; Fri, 29 Sep 2006 10:36:59 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id D73B72AC9B; Fri, 29 Sep 2006 14:36:26 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GTJTW-0005Kq-Kl; Fri, 29 Sep 2006 10:36:26 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Fri, 29 Sep 2006 10:36:26 -0400 X-Spam-Score: -5.8 (-----) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: tsvwg@ietf.org Subject: [Tsvwg] Last Call: 'Generic Aggregate RSVP Reservations' to Proposed Standard (draft-ietf-tsvwg-rsvp-ipsec) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: tsvwg-bounces@ietf.org X-Brightmail-Tracker: AAAAAA== Return-Path: tsvwg-bounces@ietf.org X-OriginalArrivalTime: 29 Sep 2006 14:38:30.0411 (UTC) FILETIME=[EEB5EDB0:01C6E3D4] The IESG has received a request from the Transport Area Working Group WG to consider the following document: - 'Generic Aggregate RSVP Reservations ' as a Proposed Standard 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 2006-10-13. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-ipsec-03.txt --------------020305050604060100050104-- From fenton@cisco.com Mon Oct 2 20:01:44 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k9301i8Q004231 for ; Mon, 2 Oct 2006 20:01:44 -0400 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k9301kWV007326 for ; Mon, 2 Oct 2006 20:01:46 -0400 (EDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mit.edu (Spam Firewall) with ESMTP id 5AEF41E4A18 for ; Mon, 2 Oct 2006 20:01:45 -0400 (EDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 02 Oct 2006 17:01:44 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9301iu6030450 for ; Mon, 2 Oct 2006 17:01:44 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k9301iYp022124 for ; Mon, 2 Oct 2006 17:01:44 -0700 (PDT) Received: from [171.71.97.128] (dhcp-171-71-97-128.cisco.com [171.71.97.128]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k92Nogrt000803 for ; Mon, 2 Oct 2006 16:50:42 -0700 Message-ID: <4521A868.40006@cisco.com> Date: Mon, 02 Oct 2006 17:01:44 -0700 From: Jim Fenton User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: saag@mit.edu References: <44F74633.3030904@cisco.com> In-Reply-To: <44F74633.3030904@cisco.com> X-Enigmail-Version: 0.93.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-2.cisco.com; header.From=fenton@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=1054; t=1159833704; x=1160697704; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fenton@cisco.com; z=From:Jim=20Fenton=20 |Subject:Re=3A=20[saag]=20Threat=20analyses=20-=20guidance=20for=20future=20autho rs; X=v=3Dcisco.com=3B=20h=3Dm8N4hPEM8g1M0R3TuvLFsrCMCuU=3D; b=0y9g5b86db+MbL92K7BxO7vzfMd+d/h+5hWuHp71Tbw5tiJlukz7mKPgX37alcaLud+ZxwK/ 5bHqorapNX7vM/X6jeNmF2zpcwWE22BKDwMboxS7ypzg8fDZSaT1fwiL; X-Spam-Score: 0.12 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: Re: [saag] Threat analyses - guidance for future authors X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Oct 2006 00:01:44 -0000 I neglected to mention to this list that a mailing list for the below-described effort has been set up. The mailing list is ietf-threat-analysis@imc.org; please go to the list's web page at http://www.imc.org/ietf-threat-analysis/ if you're interested in subscribing. -Jim Jim Fenton wrote: > At the time a few of us started the DKIM Threat Analysis, we looked > around to try to figure out what a threat analysis is supposed to say. > The guidance that was available in the form of IETF-published threat > analyses was inconsistent, so not surprisingly our first shot at it was > not really in the right direction. > > If others are interested in collaborating, I'd be willing to lead/edit > the creation of an internet-draft describing the suggested content and > format of security threat analyses, for the benefit of future authors. > I'm not saying that the DKIM threat analysis is necessarily the model > here; in fact, it may be a bit of a special case. > > Are others interested in working on this? > > -Jim > > From aglo@citi.umich.edu Tue Oct 3 11:33:11 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k93FXBN7012050 for ; Tue, 3 Oct 2006 11:33:11 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k93FXDVx017861 for ; Tue, 3 Oct 2006 11:33:13 -0400 (EDT) Received: from citi.umich.edu (citi.umich.edu [141.211.133.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id C60721BB94F for ; Tue, 3 Oct 2006 11:33:10 -0400 (EDT) Received: from [141.211.133.26] (yoga.citi.umich.edu [141.211.133.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "aglo", Issuer "CITI Production KCA" (verified OK)) by citi.umich.edu (Postfix) with ESMTP id E28F71BDE1; Tue, 3 Oct 2006 11:33:09 -0400 (EDT) Message-ID: <452282B5.7000708@citi.umich.edu> Date: Tue, 03 Oct 2006 11:33:09 -0400 From: Olga Kornievskaia User-Agent: Thunderbird 1.5.0.7 (X11/20060913) MIME-Version: 1.0 To: saag@mit.edu, kitten@ietf.org, nfsv4@ietf.org, tls@lists.ietf.org, ietf-pkix@imc.org, spkm@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] [67th IETF] SPKM3 BOF announcement X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Oct 2006 15:33:11 -0000 We would like to announce the following BOF for the 67th IETF meeting. BOF name: NFSv4 and Low Infrastructure Public Key Based GSS Security Mechanisms Area: Security Area Chair: Jeffrey Hutzelman If this topic is of interest to you please email your questions and concerns to the mail list (spkm@ietf.org). Problem Statement: The NFSv4 protocol has a need for low infrastructure PKI based GSS security mechanism(s) that provide for the creation of a secure channel using mutual authentication where 1) both user and server authenticate with public key certificates 2) server authenticates with public key certificates, and the user authenticates with a username and password. Current State: RFC3530 "Network File System (NFS) version 4 Protocol" mandates the use of RFC2847 "LIPKEY - A Low Infrastructure Public Key Mechanism Using SPKM". While RFC2847 fulfills the requirements of the problem statement, there are areas where RFC2847 is outdated and/or underspecified. Futhermore, RFC2847 both replaces and refers to portions of RFC2025 "The Simple Public-Key GSS-API Mechanism (SPKM)" and is confusing to implementers. None the less, there are two implementations (Hummingbird and Linux) based upon RFC2847. draft-adamson-rfc2847-bis-01.txt, an update of RFC2847, is intended to address RFC2847 shortcomings and provide a complete specification that doesn't need [RFC2025] and that replaces [RFC2847]. Agenda: 1) Need for a low infrastructure PK based GSS security mechanism for NFSV4 - what is low infrastructure - existing markets - current implementations 2) draft-adamson-rfc2847-bis-01.txt - issues brought up by IESG review - naming - algorithms - which diffie-hellman - clarify protocol security claims - whole document review - backwards compatibility with RFC2847 based implementations 3) moving forward - finish draft-adamson-rfc2847-bis-01.txt - get draft into shape to submit to for IESG comments. - find reviewers - explore alternative GSS mechanisms From housley@vigilsec.com Tue Oct 3 15:32:05 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k93JW5Et001360 for ; Tue, 3 Oct 2006 15:32:05 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k93JW6lL014709 for ; Tue, 3 Oct 2006 15:32:07 -0400 (EDT) Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by mit.edu (Spam Firewall) with SMTP id 6A6001CB7D7 for ; Tue, 3 Oct 2006 15:31:52 -0400 (EDT) Received: (qmail 29514 invoked by uid 0); 3 Oct 2006 19:30:46 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.126.161.75) by woodstock.binhost.com with SMTP; 3 Oct 2006 19:30:46 -0000 Message-Id: <7.0.0.16.2.20061003152023.071cad78@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Tue, 03 Oct 2006 15:30:48 -0400 To: hokeyp@opendiameter.org, saag@mit.edu From: Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.01 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] Nominations for HOKEY WG Chair X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Oct 2006 19:32:06 -0000 Thank you for the lively charter text on the HOKEYP mail list discussion. At this point, I am assuming that the result will be a WG. We could not have gotten as far as we are without your help, and your continued involvement is critical to a successful WG. The O&M Area has been very successful in selecting WG Chairs through a nominations process. We are trying in this yet-to-be-formed WG. I hope we are as successful as the O&M Area. The qualifications for chair of the HOKEY WG are: * Familiarity with IETF process * Solid understanding of AAA and EAP * Experience building consensus * Good at finding common ground in the face of disagreement * Demonstrated ability to manage technical contributors Please send nominations for HOKEY WG Chair to me. I plan to select two co-chairs. Thanks, Russ From pekkas@netcore.fi Wed Oct 11 04:37:59 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k9B8bxrN022537 for ; Wed, 11 Oct 2006 04:37:59 -0400 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k9B8btm5022003 for ; Wed, 11 Oct 2006 04:37:58 -0400 (EDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by mit.edu (Spam Firewall) with ESMTP id CABE17CFB for ; Wed, 11 Oct 2006 04:37:51 -0400 (EDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id k9B8blbP023252 for ; Wed, 11 Oct 2006 11:37:47 +0300 Date: Wed, 11 Oct 2006 11:37:47 +0300 (EEST) From: Pekka Savola To: saag@mit.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Status: Clean X-Spam-Status: No, score=-0.0 required=5.0 tests=NO_RELAYS autolearn=failed version=3.1.4 X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-25) on otso.netcore.fi X-Spam-Score: 0.34 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] IPsec protection for IPv6-in-IPv4 tunnels X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Oct 2006 08:37:59 -0000 FYI, There was some discussion on this doc on SAAG list in July and in September, in particular, about authors' suggestion to remove Tunnel mode support. In response to the comments a specific operating mode of tunnel mode is described in an appendix. The reasons why we prefer transport mode instead (similar to RFC 3884) were discussed on the list and are expanded in the document. The authors would welcome folks to take a look at this version to make sure that the new IPsec details were written out correctly. I'd like to ask to send feedback by Oct 18 (in a week) so that we may consider whether the draft needs to revised prior to the IETF.. The tools WG page (including diffs etc.) is: http://tools.ietf.org/wg/v6ops/draft-ietf-v6ops-ipsec-tunnels/ ---------- Forwarded message ---------- Date: Tue, 10 Oct 2006 15:50:02 -0400 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org Subject: I-D ACTION:draft-ietf-v6ops-ipsec-tunnels-03.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 : Using IPsec to Secure IPv6-in-IPv4 Tunnels Author(s) : P. Savola, et al. Filename : draft-ietf-v6ops-ipsec-tunnels-03.txt Pages : 22 Date : 2006-10-10 This document gives guidance on securing manually configured IPv6-in- IPv4 tunnels using IPsec. No additional protocol extensions are described beyond those available with the IPsec framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipsec-tunnels-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-ipsec-tunnels-03.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-ipsec-tunnels-03.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 housley@vigilsec.com Tue Oct 24 16:08:34 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k9OK8YY0024195 for ; Tue, 24 Oct 2006 16:08:34 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k9OK8MRI009653 for ; Tue, 24 Oct 2006 16:08:23 -0400 (EDT) Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by mit.edu (Spam Firewall) with SMTP id 87EBD724A82 for ; Tue, 24 Oct 2006 16:08:22 -0400 (EDT) Received: (qmail 5854 invoked by uid 0); 24 Oct 2006 20:08:15 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.126.161.75) by woodstock.binhost.com with SMTP; 24 Oct 2006 20:08:15 -0000 Message-Id: <7.0.0.16.2.20061024160558.041167f0@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Tue, 24 Oct 2006 16:08:19 -0400 To: saag@mit.edu From: Russ Housley In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.01 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: NOMCOM06 Subject: Re: [saag] Making non-re-up decisions public X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2006 20:08:34 -0000 I am pleased to make a public statement in this topic, and the SAAG list seems like the right place to do it for a Security Area Director. I am willing to serve another term as Security Area Director. Russ At 02:49 PM 10/20/2006, Andrew Lange wrote: >Hello All, > >We've heard from a number of sources that it would be useful if >members of the IESG, IAB and IAOC who do NOT wish to re-up make their >intentions public. The rationale behind this request is that if an >incumbent has been doing a good job, members of the community may not >nominate someone else, or stand for the position themselves, if they >believe the incumbent wishes to continue. > >The decision is obviously up to each IESG/IAB/IAOC member >themselves. But, I'd like to encourage any who have made the >decision NOT to reup to make their intentions public. > >Thank you! > >Andrew From smb@cs.columbia.edu Tue Oct 24 17:40:24 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k9OLeNU5014928 for ; Tue, 24 Oct 2006 17:40:23 -0400 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k9OLeDsk003575 for ; Tue, 24 Oct 2006 17:40:13 -0400 (EDT) Received: from machshav.com (machshav.com [147.28.0.16]) by mit.edu (Spam Firewall) with ESMTP id 586DAA56DD for ; Tue, 24 Oct 2006 17:40:00 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 4F09CFB2A8; Tue, 24 Oct 2006 21:40:00 +0000 (UTC) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id A7538FB29B; Tue, 24 Oct 2006 21:39:58 +0000 (UTC) Received: by berkshire.machshav.com (Postfix, from userid 54047) id 5837D3C070A; Tue, 24 Oct 2006 17:39:57 -0400 (EDT) Date: Tue, 24 Oct 2006 17:39:57 -0400 From: "Steven M. Bellovin" To: Russ Housley Message-Id: <20061024173957.1f984200.smb@cs.columbia.edu> In-Reply-To: <7.0.0.16.2.20061024160558.041167f0@vigilsec.com> References: <7.0.0.16.2.20061024160558.041167f0@vigilsec.com> Organization: Columbia University X-Mailer: Sylpheed version 2.2.7 (GTK+ 2.8.20; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.13 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, NOMCOM06 Subject: Re: [saag] Making non-re-up decisions public X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2006 21:40:24 -0000 On Tue, 24 Oct 2006 16:08:19 -0400, Russ Housley wrote: > I am pleased to make a public statement in this topic, and the SAAG > list seems like the right place to do it for a Security Area Director. > > I am willing to serve another term as Security Area Director. > Good! --Steven M. Bellovin, http://www.cs.columbia.edu/~smb From wes@hardakers.net Wed Oct 25 09:58:08 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k9PDw7fW003790 for ; Wed, 25 Oct 2006 09:58:08 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k9PDvniw020867 for ; Wed, 25 Oct 2006 09:57:49 -0400 (EDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by mit.edu (Spam Firewall) with ESMTP id 8487E752E1C for ; Wed, 25 Oct 2006 09:57:44 -0400 (EDT) Received: by wes.hardakers.net (Postfix, from userid 274) id 6225C11D87C; Wed, 25 Oct 2006 06:57:41 -0700 (PDT) From: Wes Hardaker To: Russ Housley Organization: Sparta References: <7.0.0.16.2.20061024160558.041167f0@vigilsec.com> Date: Wed, 25 Oct 2006 06:57:40 -0700 In-Reply-To: <7.0.0.16.2.20061024160558.041167f0@vigilsec.com> (Russ Housley's message of "Tue\, 24 Oct 2006 16\:08\:19 -0400") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.19 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, NOMCOM06 Subject: Re: [saag] Making non-re-up decisions public X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2006 13:58:08 -0000 >>>>> "RH" == Russ Housley writes: RH> I am pleased to make a public statement in this topic, and the SAAG RH> list seems like the right place to do it for a Security Area Director. RH> I am willing to serve another term as Security Area Director. Russ, I'm still trying to decide how I'm going to lobby the NOMCOM members this time around. So that I can make a decision, can you please restate your position on cookies? -- "In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find." -- Terry Pratchett From housley@vigilsec.com Wed Oct 25 11:00:45 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k9PF0jjS017453 for ; Wed, 25 Oct 2006 11:00:45 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k9PF0ThM011104 for ; Wed, 25 Oct 2006 11:00:29 -0400 (EDT) Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by mit.edu (Spam Firewall) with SMTP id D1048756462 for ; Wed, 25 Oct 2006 11:00:28 -0400 (EDT) Received: (qmail 8194 invoked by uid 0); 25 Oct 2006 15:00:25 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.126.161.75) by woodstock.binhost.com with SMTP; 25 Oct 2006 15:00:25 -0000 Message-Id: <7.0.0.16.2.20061025104118.07763008@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Wed, 25 Oct 2006 10:43:03 -0400 To: Wes Hardaker From: Russ Housley In-Reply-To: References: <7.0.0.16.2.20061024160558.041167f0@vigilsec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.01 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] Making non-re-up decisions public X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2006 15:00:45 -0000 Thanks. I really needed a laugh... I bought one of the "I want my damn cookies" T-shirts for viewing during the IAB Plenary in Montreal. Russ At 09:57 AM 10/25/2006, Wes Hardaker wrote: > >>>>> "RH" == Russ Housley writes: > >RH> I am pleased to make a public statement in this topic, and the SAAG >RH> list seems like the right place to do it for a Security Area Director. > >RH> I am willing to serve another term as Security Area Director. > >Russ, > >I'm still trying to decide how I'm going to lobby the NOMCOM members >this time around. So that I can make a decision, can you please >restate your position on cookies? >-- >"In the bathtub of history the truth is harder to hold than the soap, > and much more difficult to find." -- Terry Pratchett From fred@cisco.com Fri Sep 29 18:59:23 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k8TMxNlj023589 for ; Fri, 29 Sep 2006 18:59:23 -0400 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k8TMxNH9012301 for ; Fri, 29 Sep 2006 18:59:24 -0400 (EDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mit.edu (Spam Firewall) with ESMTP id EB5BC166C1E; Fri, 29 Sep 2006 18:59:21 -0400 (EDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 29 Sep 2006 15:59:21 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8TMxLM2018679; Fri, 29 Sep 2006 15:59:21 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k8TMxKQV028299; Fri, 29 Sep 2006 15:59:20 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Sep 2006 15:59:20 -0700 Received: from [10.32.244.222] ([10.32.244.222]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Sep 2006 15:59:20 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <36E4499D-2CA2-4FAD-B929-26D0482B6220@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker To: Black_David@emc.com X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 29 Sep 2006 22:59:20.0347 (UTC) FILETIME=[E5DE46B0:01C6E41A] DKIM-Signature: a=rsa-sha1; q=dns; l=2250; t=1159570761; x=1160434761; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Re=3A=20[saag]=20tsvwg, preemption=20and=20rsvp=3A=20exposing=20character istics=20of=20confidentialtraffic; X=v=3Dcisco.com=3B=20h=3DhcjCNbUX7AG3uehObri/rdcPUn0=3D; b=FSW9vvUOWMUfkE9ZThSxrm0cBLqJ5D1fxwM146XIG9eLHLJ+95xER81f8w1Tol1RnI9hNw3t HUXCw3qee/ndlZ2eonZZ5z+3yHnJYCThvOih+xRz0g6dIGzxPQ6J6UXJ; Authentication-Results: sj-dkim-4.cisco.com; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.01 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 X-Mailman-Approved-At: Wed, 08 Nov 2006 09:20:46 -0500 Cc: saag@mit.edu, ipsec@ietf.org, tsvwg-chairs@tools.ietf.org, hartmans-ietf@mit.edu, flefauch@cisco.com Subject: Re: [saag] tsvwg, preemption and rsvp: exposing characteristics of confidentialtraffic X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Fri, 29 Sep 2006 22:59:23 -0000 X-Original-Date: Fri, 29 Sep 2006 15:59:18 -0700 X-List-Received-Date: Fri, 29 Sep 2006 22:59:23 -0000 hmm. It sounds like there is some residual verbiage about tunnels in the vpn-signaled-preemption draft. Bottom line, both drafts call for a common DSCP. Both require multiple reservations by vport in the RSVP signaling, with the vport indicating anything that the network administrator wants it to indicate, and the vpn-signaling draft specifically saying that the network administrator in question is requesting that it signify call precedence. Call precedence is, in reality, not signaled by the vport number, but by the priorities signaled in the RFC3181-clone priority (precedence) fields of the rsvp draft, but the values used for the vports have to be agreed upon throughout the network in order to name the resulting reservations so they can be "discussed" among the equipment. I am willing to clean up the use of "priority" and "precedence" as you suggest and clean up this paragraph, along with Jari's "discuss" (as in, "remove a section the principal client of the draft asked to have written into it"). I think it's fair to ask for any remaining IESG comment before doing so... On Sep 29, 2006, at 3:01 PM, Black_David@emc.com wrote: > Actually, only the vpn-signaled-preemption draft appears to do this. > > The rsvp-ipsec draft allows multiple reservations between the same > endpoints for the same DSCP, which would allow such traffic to use > different tunnels but if it requires traffic for different > reservations to use different tunnels, I was not able to find > a statement of that requirement. > > OTOH, the vpn-signaled-preemption draft is quite clear that different > precedence levels for the same DSCP result in different IPsec tunnels. > Section 2.3.3 says: > > Due to > the mechanics of preemption, however, this would not expand the > existing "routine" reservations in the interface and inner domains, > as doing this causes loss of information - how much of the > reservation is now "routine" and how much is "priority"? Rather, > this new reservation will open up a separate set of tunnels or > security associations for traffic of its application class at its > precedence between that aggregator and deaggregator. From fred@cisco.com Fri Sep 29 19:32:53 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k8TNWrfS029737 for ; Fri, 29 Sep 2006 19:32:53 -0400 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id k8TNUamm011221 for ; Fri, 29 Sep 2006 19:30:36 -0400 (EDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mit.edu (Spam Firewall) with ESMTP id F02B31C85DE; Fri, 29 Sep 2006 19:30:35 -0400 (EDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 29 Sep 2006 16:30:35 -0700 X-IronPort-AV: i="4.09,238,1157353200"; d="scan'208"; a="1855963666:sNHT52780752" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8TNUZ66001080; Fri, 29 Sep 2006 16:30:35 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k8TNUZQV013371; Fri, 29 Sep 2006 16:30:35 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Sep 2006 16:30:34 -0700 Received: from [10.32.244.222] ([10.32.244.222]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Sep 2006 16:30:34 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <55720FD7-B61D-48B6-AEA6-A4DD3260FFC7@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker To: Black_David@emc.com X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 29 Sep 2006 23:30:34.0359 (UTC) FILETIME=[42DDD070:01C6E41F] DKIM-Signature: a=rsa-sha1; q=dns; l=952; t=1159572635; x=1160436635; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Re=3A=20[saag]=20tsvwg, preemption=20and=20rsvp=3A=20exposing=20character istics=20of=20confidentialtraffic; X=v=3Dcisco.com=3B=20h=3DhcjCNbUX7AG3uehObri/rdcPUn0=3D; b=g4tVXvfuYZdRsdGXvhb34rWMdcqkH/kQPGCIon2hjfcaZdIA5Hboy++wvvR0y9P6pYbgERbI jcpLjapRErIrlXGWW8L94sVNQb7GPI9lkCIdFhzradTTe+RqK8s9yd/l; Authentication-Results: sj-dkim-2.cisco.com; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.01 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 X-Mailman-Approved-At: Wed, 08 Nov 2006 09:20:47 -0500 Cc: saag@mit.edu, ipsec@ietf.org, tsvwg-chairs@tools.ietf.org, hartmans-ietf@mit.edu, flefauch@cisco.com Subject: Re: [saag] tsvwg, preemption and rsvp: exposing characteristics of confidentialtraffic X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Fri, 29 Sep 2006 23:32:53 -0000 X-Original-Date: Fri, 29 Sep 2006 16:30:32 -0700 X-List-Received-Date: Fri, 29 Sep 2006 23:32:53 -0000 On Sep 29, 2006, at 4:22 PM, Black_David@emc.com wrote: > Also, please consider how the approach in this draft ought to be > applied to a PHB that consists of multiple DSCPs (e.g., an AF > class, cf. RFC 2597). I believe AF is not a good fit to the > sort of traffic that motivated this draft, so explaining that > may suffice. well, ... This draft is for real time traffic, which is to say "traffic that calls for reservations". So yes, AF is not for real time traffic. I need to have a discussion with Verizon. But certain random customers do indeed have a need for preferential AF traffic in VPN-like networks similar to these. I suspect it behaves a lot like AF as it goes through a tunnel (well documented already) - with the exception that DSCP modifications that happened in the black network will not be propagated into the red networks, so any actual useful information is lost. Sigh. Mumble. Sigh. From flefauch@cisco.com Mon Oct 2 06:04:22 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id k92A4K6v015668 for ; Mon, 2 Oct 2006 06:04:20 -0400 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k92A4QWF026107 for ; Mon, 2 Oct 2006 06:04:27 -0400 (EDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by mit.edu (Spam Firewall) with ESMTP id 00F771DE0D5; Mon, 2 Oct 2006 06:04:24 -0400 (EDT) Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 02 Oct 2006 06:04:24 -0400 X-IronPort-AV: i="4.09,242,1157342400"; d="scan'208"; a="105341006:sNHT53936632" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k92A4Nm7031757; Mon, 2 Oct 2006 06:04:24 -0400 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k92A4Mg2010235; Mon, 2 Oct 2006 12:04:23 +0200 (MEST) Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Oct 2006 12:04:22 +0200 Received: from [144.254.53.135] ([144.254.53.135]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Oct 2006 03:04:21 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Francois Le Faucheur To: Black_David@emc.com X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 02 Oct 2006 10:04:22.0029 (UTC) FILETIME=[21F343D0:01C6E60A] DKIM-Signature: a=rsa-sha1; q=dns; l=1456; t=1159783464; x=1160647464; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:Francois=20Le=20Faucheur=20 |Subject:Re=3A=20[saag]=20tsvwg, preemption=20and=20rsvp=3A=20exposing=20character istics=20of=20confidentialtraffic |To:Black_David@emc.com; X=v=3Dcisco.com=3B=20h=3D4GoZqgtikWfIydAomu/JQUtzMLo=3D; b=CFzL/0mumyiC0dxrN49aOlv41dkJCUm6HzSdWOxgF4oiujtxKvKJCDI1dtvY4B3tS87uZTgx Jfb81RxadcApYRYS2a7G6SRMe1JQ0oKxpwyo/Ge35B28RnSiqVkywEYF; Authentication-Results: rtp-dkim-2.cisco.com; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.01 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 X-Mailman-Approved-At: Wed, 08 Nov 2006 09:20:47 -0500 Cc: ipsec@ietf.org, Francois Le Faucheur , fred@cisco.com, saag@mit.edu, hartmans-ietf@mit.edu, tsvwg-chairs@tools.ietf.org Subject: Re: [saag] tsvwg, preemption and rsvp: exposing characteristics of confidentialtraffic X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Mon, 02 Oct 2006 10:04:23 -0000 X-Original-Date: Mon, 2 Oct 2006 12:03:27 +0200 X-List-Received-Date: Mon, 02 Oct 2006 10:04:23 -0000 Hello, Just expanding on Dave's observation: >> These drafts set up a model under which each precedence class of data >> from a preemption standpoint goes over its own SA and uses its own >> aggregate RSVP reservation. What that means is you expose on the >> unprotected side of the interface what fraction of your traffic is at >> each precedence level. > > Actually, only the vpn-signaled-preemption draft appears to do this. > > The rsvp-ipsec draft allows multiple reservations between the same > endpoints for the same DSCP, which would allow such traffic to use > different tunnels but if it requires traffic for different > reservations to use different tunnels, I was not able to find > a statement of that requirement. > Right. The rsvp-ipsec draft effectively decorelates the aggregate reservations from the security associations (this was done as a result of the first round of Security Experts review we got). So, for example,: * it allows to set up multiple aggregate reservations using a single SA * it allows to setup one aggregate reservation per SA * it does not force/mandate either of these modes. The logic is to provide a generic mechanism which may be used in different ways, in particular in the way(s) discussed in vpn-signaled- preemption. rsvp-ipsec refers to vpn-signaled-preemption's Security Considerations for when used as per vpn-signaled-preemption. Cheers Francois From stephen.farrell@cs.tcd.ie Wed Nov 8 17:14:55 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id kA8MEtoF023820 for ; Wed, 8 Nov 2006 17:14:55 -0500 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id kA8MEntP006450 for ; Wed, 8 Nov 2006 17:14:49 -0500 (EST) Received: from srv1.ietf67.org (srv1.ietf67.org [130.129.2.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 12D6F2EF996; Wed, 8 Nov 2006 17:14:48 -0500 (EST) Received: from [127.0.0.1] (dhcp68-75.ietf67.org [130.129.68.75]) by srv1.ietf67.org (8.13.8/8.13.6) with ESMTP id kA8MEf10041659; Wed, 8 Nov 2006 22:14:47 GMT (envelope-from stephen.farrell@cs.tcd.ie) Message-ID: <45525700.10804@cs.tcd.ie> Date: Wed, 08 Nov 2006 22:15:28 +0000 From: Stephen Farrell User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: saag@mit.edu, ietf-dkim , Russ Housley , Sam Hartman Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] DKIM wg summary for SAAG X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2006 22:14:55 -0000 Here's the summary of the DKIM WG meeting for the SAAG at IETF-67. About 75 people attended. The base document finished IETF last call on Nov 7. The few comments received are being processed by the editors. We went over the open issues with the "sender signing policy requirements" document. A major meta-issue there, which we discussed for a while, is what to do with the document, ultimately: should it become an informational RFC, or should it just live as a draft document, guiding the development of the signing policy specification(s), and then expire? After a surprising amount of discussion on that point, we got a "hum" from the room marginally in favour of making it an informational RFC. Next, three participants presented their proposals for specific details of a signing policy specification. We limited discussion during the presentations, and had an open-mike period afterward. Phillip Hallam-Baker's presentation offered a mix-and-match set of three independent aspects, and it was well received. It seems likely that at least some parts of his proposal will become part of the final specification. Tony Hansen reviewed the status of the DKIM Overview document, and we got another "hum" from the room about preference to put the document out soon, to aid implementations of the DKIM base, with a possible second version later, covering subsequent topics... or to publish the overview document only after the working group completes (or largely completes) the rest of its work. The consensus was again not overwhelming, and was marginally in favour of publishing a first version now. Paul Hoffman presented a brief overview of a reputation protocol, Vouch By Reference, that's being experimented with by the Domain Assurance Council, an organization he runs. Finally, we revised the SSP milestone, deciding to set a new date of July '07 for a final SSP spec, and to add a new milestone for February for the working group's acceptance of an SSP spec as a working group document. From sandy@tislabs.com Thu Nov 9 11:38:28 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id kA9GcBSC016979 for ; Thu, 9 Nov 2006 11:38:28 -0500 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id kA9GbA5B005369 for ; Thu, 9 Nov 2006 11:37:10 -0500 (EST) Received: from nutshell.tislabs.com (sentry.gw.tislabs.com [192.94.214.100]) by mit.edu (Spam Firewall) with ESMTP id 4523C391B0 for ; Thu, 9 Nov 2006 11:37:01 -0500 (EST) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id kA9GZH54005364; Thu, 9 Nov 2006 11:35:17 -0500 (EST) Received: from pecan.tislabs.com(10.66.1.30) by nutshell.tislabs.com via csmap (V6.0) id srcAAA8_aOnk; Thu, 9 Nov 06 11:33:34 -0500 Received: by pecan.tislabs.com (Postfix, from userid 2005) id EC05A3F425; Thu, 9 Nov 2006 11:07:17 -0500 (EST) To: saag@mit.edu In-Reply-To: <7.0.0.16.2.20061109085908.014b9048@apnic.net> Message-Id: <20061109160717.EC05A3F425@pecan.tislabs.com> Date: Thu, 9 Nov 2006 11:07:17 -0500 (EST) From: sandy@tislabs.com (Sandy Murphy) X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: gih@apnic.net Subject: Re: [saag] [Sidr] SIDR Working Group meeting summary X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2006 16:38:29 -0000 Some context for the saag folk: The sidr wg is addressing an architecture for security for inter-domain routing (BGP). The resource certificate draft in sidr is defining a profile of the RFC3779 extensions, which will represent "right of use" of a prefix. The intent of the architecture is to follow the current Internet resource allocation process, where addresses are allocated from IANA to Regional Internet Registries to ISPs and from thence to their customers and their customers, etc. The next step, just begun in this meeting, is create a definition of the authority to originate a route to a prefix, based on these resource certificates' statement of who the valid prefix holder is. The route origination attestations (ROAs) mentioned in the minutes are signed objects that will represent that authority, granted by the prefix holder to an AS and signed by the prefix holder. In the meeting, Geoff Huston presented the resource certificate draft, which is nearing last call. There was a discussion about ROAs, with Geoff talking about content, Brian Weis talking about content and format possbilities, and Sandy Murphy raising some questions about communication of ROAs and the authorization model. The most contentious question was whether including a prefix in a ROA should represent authority to originate a route to exactly that prefix or to that and any more specific prefix. Russ Housley suggested CMS as an alternative format (TLV, ASN.1 and XML were the choices presented). The consensus of the group was to keep the authorization model that the prefix holder grants the authority to originate a route, and not to adopt the RIPE/RPSS model that both prefix holder and AS holder must authorize the route origination. --Sandy From kent@bbn.com Thu Nov 9 12:22:33 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id kA9HMXMQ001239 for ; Thu, 9 Nov 2006 12:22:33 -0500 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id kA9HMLV7002503 for ; Thu, 9 Nov 2006 12:22:22 -0500 (EST) Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by mit.edu (Spam Firewall) with ESMTP id 831A75A08A for ; Thu, 9 Nov 2006 12:22:20 -0500 (EST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[12.105.247.171]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1GiDbX-0002iz-5O for saag@mit.edu; Thu, 09 Nov 2006 12:22:19 -0500 Mime-Version: 1.0 Message-Id: Date: Thu, 9 Nov 2006 12:22:16 -0500 To: saag@mit.edu From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] PKIX report X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2006 17:22:34 -0000 PKIX Report for SAAG - The changes that resulted in the 05 version of 3280bis were briefed and we appear ready for WG last call on this document - Changes to SCVP based on feedback from Sam were briefed. At Sam's direction we will conduct a WG straw poll to verify that the group is comfortable with a spec that does not mandate that either the DPV or DPD function is required for compliance, i.e., a compliant server may implement either or both. - The three CMS drafts, which are undergoing AD review, require some additional changes based on the review. Jim will make these changes and we will execute a WG last call in parallel with AD re-review. - The design team constituted to evaluate options for how to represent info re ECC algorithm use restrictions with a cert recommended creation of a new cert extension, instead of using parameters in the Subject Public Key Info field. If we proceed adopt this recommendation, we may expand the scope of the proposed extension to accommodate analogous RSA algorithm modes, obsoleting RFC 4055. A discussion of the design team report will be conducted on the list and, if appropriate, a new work item will be created to design the extension. - The meeting concluded with a brief presentation on the idea of creating an extension for a CRL to carry one or more certs that could be used to verify the CRL, in cases where the CRL issuer has a different cert than the issuer of the certs on the CRL. A straw poll will be conducted on the list to decide if there is Wg support to pursue development of such an extension. From housley@vigilsec.com Thu Nov 9 12:58:29 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id kA9HwTEv010161 for ; Thu, 9 Nov 2006 12:58:29 -0500 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id kA9HwClQ006144 for ; Thu, 9 Nov 2006 12:58:12 -0500 (EST) Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by mit.edu (Spam Firewall) with SMTP id A42D1266B2B for ; Thu, 9 Nov 2006 12:58:11 -0500 (EST) Received: (qmail 15573 invoked by uid 0); 9 Nov 2006 17:58:06 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (130.129.68.101) by woodstock.binhost.com with SMTP; 9 Nov 2006 17:58:06 -0000 Message-Id: <7.0.0.16.2.20061109124851.041792f0@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Thu, 09 Nov 2006 12:49:18 -0500 To: Stephen Kent , saag@mit.edu From: Russ Housley In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.13 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: Re: [saag] PKIX report X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2006 17:58:29 -0000 s/CMS/CMC/ At 12:22 PM 11/9/2006, Stephen Kent wrote: >PKIX Report for SAAG > > - The changes that resulted in the 05 version of 3280bis were >briefed and we appear ready for WG last call on this document > > - Changes to SCVP based on feedback from Sam were briefed. At >Sam's direction we will conduct a WG straw poll to verify that the >group is comfortable with a spec that does not mandate that either >the DPV or DPD function is required for compliance, i.e., a compliant >server may implement either or both. > > - The three CMS drafts, which are undergoing AD review, >require some additional changes based on the review. Jim will make >these changes and we will execute a WG last call in parallel with AD >re-review. > > - The design team constituted to evaluate options for how >to represent info re ECC algorithm use restrictions with a cert >recommended creation of a new cert extension, instead of using >parameters in the Subject Public Key Info field. If we proceed adopt >this recommendation, we may expand the scope of the proposed >extension to accommodate analogous RSA algorithm modes, obsoleting >RFC 4055. A discussion of the design team report will be conducted on >the list and, if appropriate, a new work item will be created to >design the extension. > > - The meeting concluded with a brief presentation on the idea >of creating an extension for a CRL to carry one or more certs that >could be used to verify the CRL, in cases where the CRL issuer has a >different cert than the issuer of the certs on the CRL. A straw poll >will be conducted on the list to decide if there is Wg support to >pursue development of such an extension. >_______________________________________________ >saag mailing list >saag@mit.edu >http://mailman.mit.edu/mailman/listinfo/saag From jsalowey@cisco.com Thu Nov 9 13:11:45 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id kA9IBjSt013359 for ; Thu, 9 Nov 2006 13:11:45 -0500 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id kA9IBdjb007601 for ; Thu, 9 Nov 2006 13:11:39 -0500 (EST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mit.edu (Spam Firewall) with ESMTP id 138F8F0E5E; Thu, 9 Nov 2006 13:11:37 -0500 (EST) Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 09 Nov 2006 10:02:29 -0800 X-IronPort-AV: i="4.09,406,1157353200"; d="scan'208"; a="1863471863:sNHT1218119048" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id kA9I2Too016832; Thu, 9 Nov 2006 10:02:29 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id kA9I27Oh000864; Thu, 9 Nov 2006 10:02:29 -0800 (PST) Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Nov 2006 10:02:21 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Thu, 9 Nov 2006 10:02:20 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: EMU Summary Thread-Index: AccEKTL3cNbl+AwxTTeNY2WoSCiEYA== From: "Joseph Salowey (jsalowey)" To: , , "Sam Hartman" , "Russ Housley" X-OriginalArrivalTime: 09 Nov 2006 18:02:21.0606 (UTC) FILETIME=[3401EC60:01C70429] DKIM-Signature: a=rsa-sha1; q=dns; l=1119; t=1163095349; x=1163959349; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:EMU=20Summary |Sender:; X=v=3Dcisco.com=3B=20h=3DIlEGhB7IIR30pnlTGmVy50fRnMY=3D; b=hOGutkcJ7+NCAHEpQchbRriNl/WNWoT0z0xmtRk1SgE8/rRwRzGqcyiPlQIU8pQXzl/zj8LF ttSjgPYXPPR2+tWqNKUFRPHtcoeG1FM33yl4E4+Spqk+zDPCsN0C8ytq; Authentication-Results: sj-dkim-7; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.60 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id kA9IBjSt013359 Subject: [saag] EMU Summary X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2006 18:11:45 -0000 EMU working group Summary EMU met on Monday afternoon. Our first agenda item was RFC2716bis (EAP-TLS) where much of the discussion of open items centered around certificate handling. This document is almost ready for WG Last Call, which should be started later this month. Our second item was GPSK (generalized pre-shared key) where we had some discussion of key derivation and NIST requirements for key derivation. This document is also close to WG group last call which should occur before the next IETF. For the third agenda item we discussed approaches for a password based method that works with existing password databases. This discussion centered around the choice of reusing existing methods or trying to develop something new. There was a general feeling that we should avoid doing something new. We will be forming a design team shortly after this IETF meeting to work on this method type. Finally we had lengthy discussion on enhanced EAP-TLS and how negotiation should be performed. There were some good ideas uncovered in this discussion which will be discussed on the list. From jaltman@columbia.edu Thu Nov 9 13:59:36 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id kA9Ixa6V026131 for ; Thu, 9 Nov 2006 13:59:36 -0500 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id kA9IxIbW012675 for ; Thu, 9 Nov 2006 13:59:18 -0500 (EST) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 423B56C770 for ; Thu, 9 Nov 2006 13:59:11 -0500 (EST) Received: from [130.129.67.91] (dhcp67-91.ietf67.org [130.129.67.91]) (user=jaltman mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id kA9IxAa0003983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 9 Nov 2006 13:59:11 -0500 (EST) Resent-From: Jeffrey Altman Resent-To: saag@mit.edu Resent-Date: Thu, 9 Nov 2006 11:02:48 -0800 Resent-Message-Id: <45537B58.1010507@columbia.edu> Resent-User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.8) Gecko/20061025 Thunderbird/1.5.0.8 Message-ID: <45536F12.9030600@secure-endpoints.com> Date: Thu, 09 Nov 2006 10:10:26 -0800 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Kitten , saag@mit.edu, Sam Hartman , housley@vigilsec.com X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080302010900070003090704" X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.42 X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.12 X-Spam-Flag: NO Subject: [saag] IETF67 Summary of Kitten WG Meeting X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2006 18:59:36 -0000 This is a cryptographically signed message in MIME format. --------------ms080302010900070003090704 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The Kitten working group met at IETF67 on Tuesday afternoon session II. The presentation materials are available at: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=67#wg-kitten The Audio Stream is available at http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf67/ietf67ch2-tue-noon.mp3 The Jabber Logs are available at: http://www3.ietf.org/meetings/ietf-logs/kitten/2006-11-07.html =================================================================================== Document Status --------------- Desired Enhancements to GSSAPI Version 3 Naming - draft-ietf-kitten-gss-naming-04.txt - IESG approved; Waiting for RFC publication GSS-API Domain-Based Service Names - draft-ietf-kitten-gssapi-domain-based-names-04.txt - IETF Last Call complete GSS-API Domain-Based Service Names Mapping for the Kerberos V GSS Mechanism - draft-ietf-kitten-krb5-gssapi-domain-based-names-02.txt - IETF Last Call complete GSS-APIv2 Extension for Storing Delegated Credentials - draft-williams-gssapi-store-deleg-creds - Ready for Working Group Last Call Extended Generic Security Service Mechanism Inquiry APIs - draft-ietf-kitten-extended-mech-inquiry-02.txt - In Working Group Last Call - Please review Stackable Generic Security Service Pseudo-Mechanisms - draft-ietf-kitten-gssapi-stackable-pseudo-mechs-02.txt - In Working Group Last Call - Please review Generic Security Service API Version 2 : Java Bindings Update - draft-ietf-kitten-rfc2853bis-01.txt - In Working Group Last Call - Please review ========================================================================= Proposed Charter Revision ------------------------- Charter and Milestone Revisions being reviewed by the IESG. Charter removes work item for defining channels for use in channel bindings. Charter adds permission to address internationalization issues. ========================================================================= Technical Discussion -------------------- * The WG reviewed the outstanding AD comments on "GSS-API Domain-Based Service Names". The working group will confirm consensus of decisions on the mailing list. * WGLC: An Update to the Java GSS-API specification - Reviewers Needed Shan Emery and will Leif Johansson will review document. Need to Java language experts reviewers. 2 weeks to the review to complete * WGLC: Stackable mechs / Extended mech inquiry APIs. 3 people sending comments in the last few days More reviewers needed Jeffery Hutzelman and Ken R will review document * Internationalization Consensus GSS-API v2u1 specifies "ISO Latin-1" in existing gss_display_name and gss_display_status functions. WG consensus is that new functions providing "Unicode" and "Locale" specific output will be specified in future extensions. * Presentation: Leif Johansson on HTTP GSSAPI Negotiate replacement http://www.ietf.org/internet-drafts/draft-johansson-http-gss-00.txt http://www.ietf.org/internet-drafts/draft-johansson-http-tls-cb-00.txt Please review. * Presentation: Larry Zhu on Kerberos for Web Services - needs new name - permits client/kdc traffic through a GSS-API proxy - must be extended to handle change password protocol * Presentation: Larry Zhu on PKU2U - peer to peer kerberos. no need for a KDC - transmits Kerberos PDUs inside GSS-API tokens * Implementation Experience A concern was raised regarding the lack of running code for the GSS-API extensions in WGLC. Jeffrey Altman Kitten Chair --------------ms080302010900070003090704 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEBW00lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloX DTA3MDUyNzIyMDMzMlowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQC19SD7DncCP/+wfQlLzAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0o fGCucDfcQbSIrkhHD9z4TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U 8uN3kLyqXAFIGWKO8DJVGTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0 ma0H7PiFJ2kLfOf///07E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCD A9bNErMiOXA3dudaNNzXlN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQQFAAOBgQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4Vbo pA7BAR4ihAPibv7j7ZaxmyMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03v L3EVETiGFqTB2sLp5MLc6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAxcwggKAoAMCAQICEBW0 0lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloXDTA3MDUyNzIyMDMzMlow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC19SD7DncCP/+wfQlL zAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0ofGCucDfcQbSIrkhHD9z4 TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U8uN3kLyqXAFIGWKO8DJV GTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0ma0H7PiFJ2kLfOf///07 E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCDA9bNErMiOXA3dudaNNzX lN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOB gQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4VbopA7BAR4ihAPibv7j7Zax myMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03vL3EVETiGFqTB2sLp5MLc 6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ FbTSUrChYle3zBuZOXUzSTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNjExMDkxODEwMjZaMCMGCSqGSIb3DQEJBDEWBBTf+GOc lxhUJyErl1WcnjdXQJy0pjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEBW00lKwoWJXt8wbmTl1M0kwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBW00lKwoWJXt8wbmTl1M0kwDQYJ KoZIhvcNAQEBBQAEggEAHSSGanCliiP3x3zjLJmTTEibyt+QOCMSiAxuPB5m0g0cBp4Qivnu IzM4ZACwjYUciA6huCPzUPQ1uzPE+FU4QS0HI79coOAmtV06CsYYhcXjYlUf4x18qeMnIrw5 +MPAXKRAEe43Kz97k0nKPbAyfPYZL02j34Xx6xHmTmkESecmadrv7LJYIVCxRYoMTeVIYFWY A0qxlh8N+RlLsEuoPWo0hbBtilBRCPLstykiWBpUxaoMQEHXUn/TDS3Ulz6W03CTsoKXb3X6 +4SWL0dbjKRwrDV7n2ZcH2/yw8SbCgC+C9CNuvsi7ZfL79kR6ZqggGxK9ocvOOH6QfY7c+V9 XQAAAAAAAA== --------------ms080302010900070003090704-- From jhutz@cmu.edu Thu Nov 9 14:25:33 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id kA9JPXGM002056 for ; Thu, 9 Nov 2006 14:25:33 -0500 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id kA9JPCQH005234 for ; Thu, 9 Nov 2006 14:25:12 -0500 (EST) Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by mit.edu (Spam Firewall) with SMTP id B6E02F1B31; Thu, 9 Nov 2006 14:25:11 -0500 (EST) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa15556; 9 Nov 2006 14:24 EST Date: Thu, 9 Nov 2006 14:24:23 -0500 (EST) From: Jeffrey Hutzelman X-X-Sender: To: , Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: hartmans-ietf@mit.edu, housley@vigilsec.com Subject: [saag] SPKM BOF summary from IETF 67 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2006 19:25:33 -0000 What follows is a short summary of the SPKM BOF that was held this Monday. Presentations are on the IETF web site: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=67#wg-spkm Full minutes will be uploaded to that site and posted to the spkm@ietf.org mailing list in the near future. -- Jeff SPKM BOF - IETF 67 meeting summary We held a BOF on the topic of building a lightweight public-key-based GSS-API mechanism, motivated in large part by a need for such a mechanism for NFSv4. We began with a problem statement presentation, which was followed by presentations on proposals for four approaches to solutions: * Updating SPKM3 * PKU2U -- user-to-user auth based on PKINIT and GSS-krb5 * GSS-TLS -- a mechanism built on TLS and/or DTLS * SSiLKey -- use HTTPS to obtain a token used in GSS context establishment Polls indicated there was sufficient interest in this work and enough people willing to work on it; however, it was not clear whether formation of a working group was actually necessary to proceed. The sense of the room seemed to be that leaving the choice of solution up to the proposed WG would be counter-productive, and that any WG formed should be constrained to a particular solution. This led to a discussion about the relative merits of the solutions proposed. The conclusion was that selection of a particlar proposal was not possible in the short time remaining in the BOF session. As a next step, Sam will form an AD-sponsored design team to evaluate the proposals and select one. This group will include one of the authors of of each of the four proposals, and possibly a small number of others. A poll of the room indicated that the output of such a design team would likely be acceptable to the group. From shanna@juniper.net Thu Nov 9 14:33:44 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id kA9JXimY004560 for ; Thu, 9 Nov 2006 14:33:44 -0500 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id kA9JXQUO020734 for ; Thu, 9 Nov 2006 14:33:26 -0500 (EST) Received: from kremlin.juniper.net (kremlin.juniper.net [207.17.137.120]) by mit.edu (Spam Firewall) with ESMTP id A7D4B7657E for ; Thu, 9 Nov 2006 14:33:16 -0500 (EST) Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 09 Nov 2006 11:30:24 -0800 X-IronPort-AV: i="4.09,406,1157353200"; d="scan'208"; a="607230413:sNHT29845280" X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 9 Nov 2006 14:33:12 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF67 NEA WG Meeting summary Thread-index: AccELVhWTnx+V+0kT4GwhokPC5/jugACHuqQ From: "Stephen Hanna" To: X-Spam-Score: 0.60 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id kA9JXimY004560 Cc: "Susan Thomson \(sethomso\)" Subject: [saag] IETF67 NEA WG Meeting summary X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2006 19:33:44 -0000 NEA WG Meeting Summary Tuesday Nov 7 15.20-17.20 1. Discuss formation of NEA WG Requirements I-D The first milestone of the WG is formation of the requirements I-D. To this end, the contents that need to be covered in the Requirements I-D were reviewed along with the proposed reference model. Several use cases were introduced with the goal of driving protocol requirements. The WG also reviewed an individual submission on NEA requirements that had been submitted prior to chartering of the WG. Some material in this document may be used as a start for the WG document with appropriate changes to reflect the approved charter. 2. Next Steps: WG chairs to send call for requirements I-D "design team" volunteers to mailing list (done) Volunteers to send names to WG chairs by Nov 16 WG chairs to select design team by Nov 22 Design team to start con calls week of Nov 27 Post first draft of requirements I-D From tlyu@MIT.EDU Thu Nov 9 15:43:45 2006 Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id kA9Khjwn025531 for ; Thu, 9 Nov 2006 15:43:45 -0500 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id kA9KhLP0003183; Thu, 9 Nov 2006 15:43:21 -0500 (EST) Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id kA9KhJ2h004219 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 9 Nov 2006 15:43:20 -0500 (EST) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9) id kA9KhJqN013437; Thu, 9 Nov 2006 15:43:19 -0500 (EST) To: saag@MIT.EDU From: Tom Yu Date: Thu, 09 Nov 2006 15:43:19 -0500 Message-ID: Lines: 58 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.42 X-Spam-Score: -5.598 X-Spam-Flag: NO Cc: housley@vigilsec.com, hartmans-ietf@mit.edu, ietf-sasl@imc.org Subject: [saag] IETF67 SASL WG summary X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2006 20:43:45 -0000 SASL WG Tuesday, November 7, 2006, at 1740-1840 SUMMARY ======= Thanks to Chris Newman and Lisa Dusseault for scribing. Document Status: CRAM-MD5 - needs new rev GS2 - some open issues GSSAPI - RFC Editor queue PLAIN - RFC 4616 rfc2831bis (DIGEST-MD5) - some open issues Only minor open issues in DIGEST-MD5; we will coordinate with HTTP people to investigate possible HTTP compatibility issues. CRAM-MD5 needs new revision with Kurt's proposed applicability text and other minor changes. Extended discussion ensues about GS2 and channel bindings. Simon Josefsson has some concerns about implementability of TLS channel bindings due to lack of adequate specification. Explicitly reference Jeff Altman's TLS channel bindings draft? Consensus that this is a bad idea; leave GS2 alone for now (referencing draft-williams-on-channel-binding). Some discussion occurs about advancing specifications to Draft Standard. ACTION ITEMS ============ * Chris Newman and Jeff Altman will do reviews of DIGEST-MD5 by end of Nov. HTTP people will be contacted too. * Lyndon will incorporate new CRAM-MD5 text by end of Nov. * Alexey will verify that GS2 last call issues are addressed in current doc rev. * Alexey, Jeff Altman, and Kurt will independently compute the krb5 GS2 mechanism name for verification. * Kurt will form a design team to determine what's needed for the interop reports. * Milestones: Nov 2006 WGLC for CRAM-MD5 Nov 2006 WGLC for GS2 Nov 2006 WGLC for DIGEST-MD5 Dec 2006 CRAM-MD5 to IESG Dec 2006 GS2 to IESG Dec 2006 DIGEST-MD5 to IESG Jun 2007 Implementation report plan Jul 2007 Revise charter or conclude From gih@apnic.net Wed Nov 8 17:04:36 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id kA8M4a1K020486 for ; Wed, 8 Nov 2006 17:04:36 -0500 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id kA8M4Uf7010057 for ; Wed, 8 Nov 2006 17:04:30 -0500 (EST) Received: from kahuna.telstra.net (kahuna.telstra.net [203.50.0.6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 0275DF717A for ; Wed, 8 Nov 2006 17:04:28 -0500 (EST) Received: from gihm3.apnic.net (kahuna.telstra.net [IPv6:2001:360::4]) by kahuna.telstra.net (8.12.11/8.12.11) with ESMTP id kA8M42xO041972; Thu, 9 Nov 2006 09:04:07 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <7.0.0.16.2.20061109085908.014b9048@apnic.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Thu, 09 Nov 2006 09:04:00 +1100 To: sidr@ietf.org From: Geoff Huston Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.01 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 X-Mailman-Approved-At: Thu, 09 Nov 2006 16:03:19 -0500 Cc: saag@mit.edu Subject: [saag] SIDR Working Group meeting summary X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2006 22:04:36 -0000 SIDR Working Group Summary The SIDR working group met at IETF 67, 0900-1130 on Wednesday. The WG agenda items covered the progress with the charter milestones, the resource certificate profile and the initial thoughts and considerations regarding routing origination attestations and their content and format. In considering the WG status as against the milestones, it is the case that the WG's efforts on an architecture for inter-domain routing security are falling behind. In the WG meeting a group of authors volunteered to work on this topic in the coming months, so that there is now some confidence that while this milestone is going to be late (as the milestone was August 2006!), a path of progress has been identified. Work on the secure origination charter item is also now underway. We received an informal report from Russ White, the RSPEC WG co-chair that the IDR Security Requirements documents was close to completion and that the RPSEC WG are unable to resolve one way or another the issues relating to distinct approaches with respect to path validation that have been considered in RPSEC for some months. The implication is that the issues that surfaced in RPSEC may be replayed in SIDR. At his stage we will await the RPSEC outcomes to understand the situation a little better. Presentations (and minutes, when prepared) can be views in the SIDR section of https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=67 In short - productive WG meeting, people interested in working on the next steps, progress is being made, and the charter milestones are, at this stage, not too badly behind the original estimates! thanks, Geoff and Sandy co-chairs, SIDR WG Geoff and Sandy From jaltman@secure-endpoints.com Thu Nov 9 13:07:12 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id kA9I7CWU012135 for ; Thu, 9 Nov 2006 13:07:12 -0500 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id kA9I72X0028922 for ; Thu, 9 Nov 2006 13:07:02 -0500 (EST) Received: from ms-smtp-02.rdc-nyc.rr.com (ms-smtp-02.rdc-nyc.rr.com [24.29.109.6]) by mit.edu (Spam Firewall) with ESMTP id 5985F557C8; Thu, 9 Nov 2006 13:06:59 -0500 (EST) Received: from www.secure-endpoints.com (cpe-68-175-91-105.nyc.res.rr.com [68.175.91.105]) by ms-smtp-02.rdc-nyc.rr.com (8.13.6/8.13.6) with ESMTP id kA9I6wdG007948; Thu, 9 Nov 2006 13:06:58 -0500 (EST) Received: from [130.129.67.91] by secure-endpoints.com (Cipher TLSv1:RC4-MD5:128) (MDaemon PRO v9.5.3) with ESMTP id md50000034397.msg; Thu, 09 Nov 2006 13:10:35 -0500 Message-ID: <45536F12.9030600@secure-endpoints.com> Date: Thu, 09 Nov 2006 10:10:26 -0800 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Kitten , saag@mit.edu, Sam Hartman , housley@vigilsec.com X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080302010900070003090704" X-Authenticated-Sender: jaltman@secure-endpoints.com X-Spam-Processed: www.secure-endpoints.com, Thu, 09 Nov 2006 13:10:35 -0500 (not processed: message from valid local sender) X-MDRemoteIP: 130.129.67.91 X-Return-Path: jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-Spam-Score: 0.12 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 X-Mailman-Approved-At: Thu, 09 Nov 2006 16:03:19 -0500 Subject: [saag] IETF67 Summary of Kitten WG Meeting X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Reply-To: jaltman@secure-endpoints.com List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2006 18:07:12 -0000 This is a cryptographically signed message in MIME format. --------------ms080302010900070003090704 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The Kitten working group met at IETF67 on Tuesday afternoon session II. The presentation materials are available at: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=67#wg-kitten The Audio Stream is available at http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf67/ietf67ch2-tue-noon.mp3 The Jabber Logs are available at: http://www3.ietf.org/meetings/ietf-logs/kitten/2006-11-07.html =================================================================================== Document Status --------------- Desired Enhancements to GSSAPI Version 3 Naming - draft-ietf-kitten-gss-naming-04.txt - IESG approved; Waiting for RFC publication GSS-API Domain-Based Service Names - draft-ietf-kitten-gssapi-domain-based-names-04.txt - IETF Last Call complete GSS-API Domain-Based Service Names Mapping for the Kerberos V GSS Mechanism - draft-ietf-kitten-krb5-gssapi-domain-based-names-02.txt - IETF Last Call complete GSS-APIv2 Extension for Storing Delegated Credentials - draft-williams-gssapi-store-deleg-creds - Ready for Working Group Last Call Extended Generic Security Service Mechanism Inquiry APIs - draft-ietf-kitten-extended-mech-inquiry-02.txt - In Working Group Last Call - Please review Stackable Generic Security Service Pseudo-Mechanisms - draft-ietf-kitten-gssapi-stackable-pseudo-mechs-02.txt - In Working Group Last Call - Please review Generic Security Service API Version 2 : Java Bindings Update - draft-ietf-kitten-rfc2853bis-01.txt - In Working Group Last Call - Please review ========================================================================= Proposed Charter Revision ------------------------- Charter and Milestone Revisions being reviewed by the IESG. Charter removes work item for defining channels for use in channel bindings. Charter adds permission to address internationalization issues. ========================================================================= Technical Discussion -------------------- * The WG reviewed the outstanding AD comments on "GSS-API Domain-Based Service Names". The working group will confirm consensus of decisions on the mailing list. * WGLC: An Update to the Java GSS-API specification - Reviewers Needed Shan Emery and will Leif Johansson will review document. Need to Java language experts reviewers. 2 weeks to the review to complete * WGLC: Stackable mechs / Extended mech inquiry APIs. 3 people sending comments in the last few days More reviewers needed Jeffery Hutzelman and Ken R will review document * Internationalization Consensus GSS-API v2u1 specifies "ISO Latin-1" in existing gss_display_name and gss_display_status functions. WG consensus is that new functions providing "Unicode" and "Locale" specific output will be specified in future extensions. * Presentation: Leif Johansson on HTTP GSSAPI Negotiate replacement http://www.ietf.org/internet-drafts/draft-johansson-http-gss-00.txt http://www.ietf.org/internet-drafts/draft-johansson-http-tls-cb-00.txt Please review. * Presentation: Larry Zhu on Kerberos for Web Services - needs new name - permits client/kdc traffic through a GSS-API proxy - must be extended to handle change password protocol * Presentation: Larry Zhu on PKU2U - peer to peer kerberos. no need for a KDC - transmits Kerberos PDUs inside GSS-API tokens * Implementation Experience A concern was raised regarding the lack of running code for the GSS-API extensions in WGLC. Jeffrey Altman Kitten Chair --------------ms080302010900070003090704 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJeTCC AxcwggKAoAMCAQICEBW00lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloX DTA3MDUyNzIyMDMzMlowczEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVy aWMxHDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQC19SD7DncCP/+wfQlLzAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0o fGCucDfcQbSIrkhHD9z4TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U 8uN3kLyqXAFIGWKO8DJVGTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0 ma0H7PiFJ2kLfOf///07E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCD A9bNErMiOXA3dudaNNzXlN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcG A1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADAN BgkqhkiG9w0BAQQFAAOBgQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4Vbo pA7BAR4ihAPibv7j7ZaxmyMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03v L3EVETiGFqTB2sLp5MLc6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAxcwggKAoAMCAQICEBW0 0lKwoWJXt8wbmTl1M0kwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDUyNzIyMDMzMloXDTA3MDUyNzIyMDMzMlow czEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMxHDAaBgNVBAMTE0pl ZmZyZXkgRXJpYyBBbHRtYW4xKzApBgkqhkiG9w0BCQEWHGphbHRtYW5Ac2VjdXJlLWVuZHBv aW50cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC19SD7DncCP/+wfQlL zAAcxf1nJ/7UQgh4o/nxzvuY55XwHdLQjqWuFUnM5vecfyZKwq0ofGCucDfcQbSIrkhHD9z4 TZ8vDaYWVY9Foz8Rp8G0PNdbRFoFtfJbaeVBX5hG3aQXIc/T1b9U8uN3kLyqXAFIGWKO8DJV GTKKtOiPVOp1U+9CwujyYmUSKF+suutKABhhK1ZGHsTnFczLZ2g0ma0H7PiFJ2kLfOf///07 E1fbr4IRb+cd87kpWLcjtEZ0rbBr9HlOy9dkeEii/qFoo1ahfKCDA9bNErMiOXA3dudaNNzX lN/70slq5fboBXbepamJGrsnXYcCsS9+LtCTAgMBAAGjOTA3MCcGA1UdEQQgMB6BHGphbHRt YW5Ac2VjdXJlLWVuZHBvaW50cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOB gQDBzWhkrW+ol3iyT1rV8ZBQB0+z/6dFH3djQfNf7jDXNoXx4VbopA7BAR4ihAPibv7j7Zax myMxWiDACRGS934uvUS0K6L6q14hTWMostJgFsAEDArrmbrES03vL3EVETiGFqTB2sLp5MLc 6+z+72pLXRuDPL3lO2GOQuBbILswRzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg VG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwg RnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV +065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfAr hVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxh YmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/ TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amc OY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggNkMIID YAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ FbTSUrChYle3zBuZOXUzSTAJBgUrDgMCGgUAoIIBwzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNjExMDkxODEwMjZaMCMGCSqGSIb3DQEJBDEWBBTf+GOc lxhUJyErl1WcnjdXQJy0pjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBhQYJKwYB BAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg Q0ECEBW00lKwoWJXt8wbmTl1M0kwgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJa QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBW00lKwoWJXt8wbmTl1M0kwDQYJ KoZIhvcNAQEBBQAEggEAHSSGanCliiP3x3zjLJmTTEibyt+QOCMSiAxuPB5m0g0cBp4Qivnu IzM4ZACwjYUciA6huCPzUPQ1uzPE+FU4QS0HI79coOAmtV06CsYYhcXjYlUf4x18qeMnIrw5 +MPAXKRAEe43Kz97k0nKPbAyfPYZL02j34Xx6xHmTmkESecmadrv7LJYIVCxRYoMTeVIYFWY A0qxlh8N+RlLsEuoPWo0hbBtilBRCPLstykiWBpUxaoMQEHXUn/TDS3Ulz6W03CTsoKXb3X6 +4SWL0dbjKRwrDV7n2ZcH2/yw8SbCgC+C9CNuvsi7ZfL79kR6ZqggGxK9ocvOOH6QfY7c+V9 XQAAAAAAAA== --------------ms080302010900070003090704-- From jhutz@cmu.edu Thu Nov 9 16:09:13 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id kA9L9DSt001060 for ; Thu, 9 Nov 2006 16:09:13 -0500 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id kA9L7EdP024304 for ; Thu, 9 Nov 2006 16:07:15 -0500 (EST) Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by mit.edu (Spam Firewall) with SMTP id 3634AB2068; Thu, 9 Nov 2006 16:07:00 -0500 (EST) Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa17430; 9 Nov 2006 16:06 EST Date: Thu, 9 Nov 2006 16:06:14 -0500 (EST) From: Jeffrey Hutzelman X-X-Sender: To: , Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: hartmans-ietf@mit.edu, housley@vigilsec.com Subject: [saag] KRB-WG session summary for IETF67 X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2006 21:09:13 -0000 Kerberos Working Group - IETF 67 meeting summary ACTION ITEMS: * jhutz: send tcp-expansion to IESG * jhutz: start WGLC on set/change password * jhutz: start WGLC on naming, anonymous * jhutz, hartmans: refine charter proposal DECISIONS (to be validated): - KDC needs to signal to clients whether to use unicode or legacy encoding for string2key in cases where preauth is used. Need to discuss on the list how to do this. SESSION SUMMARY: + There was a summary of ongoing work, related work outside the WG, and proposed new work items. + Tom Yu gave a presentation on the goals for kerberos-extensions, then led a discussion about open issues in that document. + Jeff Hutzelman presented a proposal for an updated charter. There was very little discussion. Sam said he wants us to agree on a charter before submitting our next agenda request (i.e. for IETF68). From lha@it.su.se Thu Nov 9 16:10:47 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id kA9LAj09001632 for ; Thu, 9 Nov 2006 16:10:45 -0500 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id kA9LAQ97000408 for ; Thu, 9 Nov 2006 16:10:29 -0500 (EST) Received: from smtp3.su.se (smtp3.su.se [130.237.93.228]) by mit.edu (Spam Firewall) with ESMTP id 7DFD5E8361 for ; Thu, 9 Nov 2006 16:10:26 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id F1EF53BFC4; Thu, 9 Nov 2006 22:10:24 +0100 (CET) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 05073-01-53; Thu, 9 Nov 2006 22:10:24 +0100 (CET) Received: from [130.129.65.147] (dhcp65-147.ietf67.org [130.129.65.147]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id 7F6F13BE82; Thu, 9 Nov 2006 22:10:23 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <54E66E12-347F-42EF-B79F-1285C50F654D@it.su.se> Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Love_H=F6rnquist_=C5strand?= Date: Thu, 9 Nov 2006 13:10:21 -0800 To: "Discussions of anonymous Internet security." X-Mailer: Apple Mail (2.752.3) X-Spam-Status: No, hits=-1.618 tagged_above=-99 required=7 tests=[AWL=0.047, BAYES_00=-1.665] X-Spam-Level: ** (2.01) X-Spam-Score: 2.01 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: Security Area General Directorate Group Subject: [saag] BTNS summary X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2006 21:10:48 -0000 BTNS meet shortly on Monday at IETF67. We had a short update on the problem and statement, it will be WG-LC after the IETF general meeting. The core document describing BTNS is still waiting for the edit since the last IETF. The API document appeared in the first version of the document, the document seem to have the right direction, but needs improvment before its accepted as a working-group document. The editors would like to have contact with application protocol implementors so they can discuss the API. Love From Quittek@netlab.nec.de Thu Nov 9 21:05:39 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id kAA25d04016380 for ; Thu, 9 Nov 2006 21:05:39 -0500 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id kAA25LBr019326 for ; Thu, 9 Nov 2006 21:05:22 -0500 (EST) Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by mit.edu (Spam Firewall) with ESMTP id DCBE72C0815; Thu, 9 Nov 2006 21:05:17 -0500 (EST) Received: from localhost (atlas1.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 6808E20031EF; Fri, 10 Nov 2006 03:05:41 +0100 (CET) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ntV2mwVRMnPn; Fri, 10 Nov 2006 03:05:41 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 5193B20031E5; Fri, 10 Nov 2006 03:05:41 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 10 Nov 2006 03:05:10 +0100 Message-ID: <113091BD57179D4491C19DA7E10CD69610ADBA@mx1.office> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ISMS IETF67 session summary Thread-Index: AccEbKaLCfVPBK2PSDecYmhEXKPwjQ== From: "Juergen Quittek" To: , , , , , X-Spam-Score: 0.60 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id kAA25d04016380 Subject: [saag] ISMS IETF67 session summary X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2006 02:05:39 -0000 ISMS IETF67 session summary ISMS met on Thursday after the SAAG meeting. As agreed at the last meeting, one of the two existing WG documents was split into two. The resulting three documents describe a transport subsystem for SNMP, a transport security model for SNMP, and a SSH security model for SNMP. The new document structure is more modular and simplifies the potential future specification of other security models, for example, a TLS security model in addition to the SSH model that the ISMS WG develops. The new document structure was approved by the WG and by the responsible AD Sam Hartman. For the transport subsystem for SNMP and the transport security model for SNMP all open issues have been resolved and the next versions of these documents will enter WGLC. The SSH security model for SNMP will probably need two more revisions to be ready for WGLC. The biggest open issue is the authentication for notifications. The charter contains two more documents that do not yet exist. One describes the usage of RADIUS for the SSH security model. We have an individual draft, but kept it on hold until the SSH security model had become sufficiently stable. This has been achieved with the current version of the SSH security model. Now, work on the RADIUS document can go on and the initial WG draft is planned for December. The last document on the charter is an applicability statement for ISMS. With the new modular structure, the WG considers it preferable to have rather applicability statements per module instead of a generic one for ISMS. It was agreed to drop this document and instead add a specific applicability statement to the SSH security module. This change was approved by the responsible AD. From CWallace@cygnacom.com Thu Nov 9 20:56:05 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id kAA1u5hf013869 for ; Thu, 9 Nov 2006 20:56:05 -0500 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id kAA1u2Ig024463 for ; Thu, 9 Nov 2006 20:56:02 -0500 (EST) Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by mit.edu (Spam Firewall) with SMTP id 453293651E for ; Thu, 9 Nov 2006 20:56:01 -0500 (EST) Received: (qmail 19324 invoked from network); 10 Nov 2006 01:44:45 -0000 Received: from CWallace@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4; 10 Nov 2006 01:44:45 -0000 Received: from unknown (HELO scygmxs1.cygnacom.com) (10.60.50.7) by scygmxsecs1.cygnacom.com with SMTP; 10 Nov 2006 01:44:45 -0000 Received: by scygmxs1.cygnacom.com with Internet Mail Service (5.5.2657.72) id ; Thu, 9 Nov 2006 20:56:01 -0500 Message-ID: <886F5D4C78AFB14D87261206BFB9612E1BCCC552@scygmxs1.cygnacom.com> From: Carl Wallace To: saag@mit.edu Date: Thu, 9 Nov 2006 20:56:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7046B.5ECC50BC" X-Spam-Score: 0.01 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 X-Mailman-Approved-At: Sat, 11 Nov 2006 00:07:45 -0500 Cc: ietf-ltans@imc.org Subject: [saag] LTANS summary X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2006 01:56:05 -0000 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C7046B.5ECC50BC Content-Type: text/plain LTANS held a short meeting to review the status of the active working group documents. The Evidence Record Syntax (ERS) draft has completed working group last call. A new version will be posted to address a few comments that were received. This new version will be cross-posted to the S/MIME working group to garner additional review. The Long-Term Archive Protocol (LTAP) document will be the focus as work on ERS winds down. Two drafts related to preserving verification data separate from archived data will progress after ERS is submitted to the IESG. A CRL extension in the appendix of one draft will possibly be dropped pending a survey of existing client behavior when using a CRL generated after the time of interest of a verification operation. Two new drafts were reviewed. One describes the overall architecture of services using the ERS and LTAP specs. The other defines processing rules for using RFC3161 timestamps within an Evidence Record. A straw poll will be conducted on the mailing list to determine if these documents are accepted as working group work items. ------_=_NextPart_001_01C7046B.5ECC50BC Content-Type: text/html Content-Transfer-Encoding: quoted-printable LTANS summary

LTANS held a short meeting to review the status of = the active working group documents.  The Evidence Record Syntax = (ERS) draft has completed working group last call.  A new version = will be posted to address a few comments that were received.  This = new version will be cross-posted to the S/MIME working group to garner = additional review.  The Long-Term Archive Protocol (LTAP) document = will be the focus as work on ERS winds down.  Two drafts related = to preserving verification data separate from archived data will = progress after ERS is submitted to the IESG.  A CRL extension in = the appendix of one draft will possibly be dropped pending a survey of = existing client behavior when using a CRL generated after the time of = interest of a verification operation.  Two new drafts were = reviewed.  One describes the overall architecture of services = using the ERS and LTAP specs.  The other defines processing rules = for using RFC3161 timestamps within an Evidence Record.  A straw = poll will be conducted on the mailing list to determine if these = documents are accepted as working group work items.

------_=_NextPart_001_01C7046B.5ECC50BC-- From housley@vigilsec.com Sat Nov 11 12:58:16 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id kABHwGuT021166 for ; Sat, 11 Nov 2006 12:58:16 -0500 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id kABHw3RZ019126 for ; Sat, 11 Nov 2006 12:58:03 -0500 (EST) Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by mit.edu (Spam Firewall) with SMTP id 2B41524C56 for ; Sat, 11 Nov 2006 12:58:01 -0500 (EST) Received: (qmail 8657 invoked by uid 0); 11 Nov 2006 17:57:55 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.246.224.121) by woodstock.binhost.com with SMTP; 11 Nov 2006 17:57:55 -0000 Message-Id: <7.0.0.16.2.20061110165208.041e9268@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Fri, 10 Nov 2006 16:53:42 -0500 To: saag@mit.edu From: Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.01 X-Spam-Level: * (1.01) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] Draft SAAG Minutes X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Nov 2006 17:58:16 -0000 Many thanks to DJ and Don for their notes. Errors are mine. Please tell me about them. Russ = = = = = = = = = = = = Security Area Advisory Group (SAAG) IETF 67, San Diego, California, USA Minutes compiled by David Johnston, Donald Eastlake, and Russ Housley Agenda WG Session Reports BOF Session Reports Invited Presentations - Embedding Security Knowledge in RFCs -- By Venkat Pothamsetty - Real Attacks and Threat Models -- By Steve Bellovin - How Not To Protect PC's From Power Analysis -- By Russ Housley on behalf of Adi Shamir Open Microphone ------------------------------------------------------------------------ WG and BOF Session Reports As usual, the SAAG session began with Working Group and BOF Reports. Each Working Group or BOF that had a meeting at IETF 67 gave a very brief summary of the session. Please see the minutes for each of these sessions for more details. The highlights are not repeated here. Reports were provited by these Working Groups (in the order that they met during the week): - EMU (Joe Salowey) - MSEC (Ran Canetii and Lakshminath Dondeti) - BTNS (Love Hornquist-Astrand) - DKIM (Stephen Farrell and Barry Leiba) - KRB-WG (Jeffrey Hutzelman) - KITTEN (Jeffrey Altman) - NEA (Steven Hanna and Susan Thomson) - HOKEY (Charles Clancy and Glen Zorn) - SASL (Tom Yu and Kurt Zeilenga) - PKIX (Steve Kent and Stefan Santesson) - S/MIME (Blake Ramsdell and Sean Turner) - ISMS (Juergen Schoenwaelder and Juergen Quittek) - LTANS (Tobias Gondrom and Carl Wallace) - TLS (Pasi Eronen and Eric Rescorla) Reports were provited by these BOFs (again, in the order that they met during the week): - SPKM (Jeff Hutzelman) - KEYPROV (Phillip Hallam-Baker and Susan Cannon) ------------------------------------------------------------------------ Embedding Security Knowledge in RFCs Venkat Pothamsetty http://www3.ietf.org/proceedings/06nov/slides/saag-1.ppt Implementations should come out robust even if their implementers blindly follow the RFC protocol specifications. We have not seen vulnerability types and attack types change much over the last 5+ years. Limits scope of the knowledge. Education on writing secure code important and, we should not leave this to be the weakest link. Security considerations in RFCs inconsistent. Looked at why do implementers make the same mistakes? Implementers followed the RFCs. Security considerations sections are not exhaustive. Educating implementers not scalable. Fixing RFCs is scalable, there are a lot more implementers than specification writers. Lists Meyers seven sins of specifiers. Q: I have been involved in text based protocols. Some have full ABNF formal specifications. But this seems to have been no help on buffer overflows and other implementation flaws. Some fields are inherently infinite except for implementation constraints. Security Considerations in RFCs are better than they have been in the past. So we are doing much of what you suggest, but it has been of little help. A: Some things like packet rate are not in Security Considerations so far. Q: First, the implication of what you say is that protocols written in ASN.1 should have no problems. But we do continue to see problems because the parsing problem is hard. Second, people are making mistakes in translating even perfect specifications into code. Should we write implementations in some new language that is closer to the specification language. A: I am not proposing a formal language. That was just one example. The current situation is like building a building without having a building code. I'm suggestion there should be a building code. Q: I didn't think you were talking about a formal language. As a result, I have no idea what you are talking about. You used RADIUS as an example in your presentation, and the RADIUS specification cannot be understood in one reading. After reading the specification 2 or 3 or 5 times, one will discover that it does fully specify packet content, length, and so on. It is possible to do correct implementations from the specification. So what is the problem again? A: Well, current specifications don't provide all that I am suggesting. Even a low packet rate can kill some IPsec implementations. Why not have the IPsec specification give a packet rate? Q: It's a good idea to have better specifications, but formal languages don't cut it. How much would it delay documents due to arguments over details required for a full formal language specification? I recommend against putting in packet rates. Correct rate limits depend too much on specific context. But it sure would be good to have better implementations. A: I wrote a separate Security Considerations document for a specification done outside IETF. Implementers seem to like it. Q: I don't think it makes any difference what language in which the specification is written. The issue is that you have to make mid-parse decisions in almost every protocol. If an RFC could be all ABNF, you could do a perfect implementation. In the real world, you always have to partially parse, and then make decisions before parsing further. Q: Changing the implementation language to be more like the specification language works to improve implementation reliability. Q: I support the use of formal specifications, but you have to do the right specification. There were bugs in the Berkeley FTP daemon because of subtle bugs in the original specification. Buffer overflow errors are not found early because specifications usually say things like "shall handle messages up to 4K bytes," but the specifications do not say "fail gracefully for anything over 4K." Q: ISCA laboratories has lots of real experience in testing products. (... Some examples of very bad implementations were given. ...) There are only so many steps we can take to improve things. More specifications should include state machines. They need more focus on proper handling of unexpected messages and unexpected conditions. ------------------------------------------------------------------------ Real Attacks and Threat Models Steve Bellovin http://www3.ietf.org/proceedings/06nov/slides/saag-3.pdf Those crazy scenarios the security guys come up with are real! They are out there in the wild. We need to take into account the elevated threat model today. The Computer Science Departmeent at Columbia University was informed that our FTP server was launching attacks. We disconnected it, and the reports continued! Someone was spoofing the IP and MAC address of the server. It was traced to a firewall in a different building on campus, which was communicating to a machine in Sweden every four minutes. We then disconnected that machine. When we brought up the FTP server, the attack started up again. Something local was monitoring, perhaps looking for gratuitous ARP. We found deliberately broken SYNs, which were probably being used for communication with another compromised local machine. We had gotten a couple of complaints about the FTP server, but when we tested our FTP server internally, it worked fine. Only outsiders, going through a higher level switch, got failures. Further, the local testing temporarily fixed the problem due to bridge learning. Investigation showed that machines had been compromised for months and had used hundreds of different legitimate MAC addresses. The attack was noticed in October, but logs show that it was already underway in May. We know that there are other compromised machines in the department, but we do not knnow which ones. When we turned it off, we had a few days of intermittent DOS attacks from spoofed MAC addresses inside our LAN, perhaps in retaliation. Conclusion: there are some very sophisticated bad guys out there. While talking about this to someone at the IETF, they told me they had experienced something very similar. So have been at least two cases of this in the wild. It only takes one sophisticated bad guy to enable many script-kiddies. Q: Were you using SEND (Secure Network Discovery)? A: SEND would have prevented the MAC spoofing. We were not using it. One needs SEND support on the switch, not just the host. C: People should come to the plenary tonight. Steve is talking about the tip of an ice berg. We will talk about the ice that is below the water line tonight. C: Switches can limit the number of MAC addresses on a port. Next time someone complains about your FTP server, I'll be happy to test from off campus. Q: Most people don't publicize anything about attacks. Thanks for giving us some more details. I was hoping that INCH would help. We need to spot patterns of attacks. A: The compromised box had a Linux 2.4 kernel. C: We hear about attacks but mostly about DDoS multi-box attacks. This was a single box attack. A while ago we heard reports of attacks on DNS servers. Initial reports blamed botnets. In fact, it turned out to be 10 UNIX servers that had been compromised and used DNSSEC as to amplify the traffic. C: Some working groups in IETF say that these crazy threats don't apply to their protocol. Well, they really do. ------------------------------------------------------------------------ How Not To Protect PC's From Power Analysis Yossi Oren and Adi Shamir (presented by Russ Housley) http://www3.ietf.org/proceedings/06nov/slides/saag-4.ppt The most dangerous part of a PC is the USB port! Many companies disable these ports to prevent data downloading. However, it is also an excellent way to do power analysis. We tried doing a simple power analysis over a few minutes without opening the cover of the computer. Few found lots of high frequency variation. We also found that you couldn't disable the port with OS or BIOS or USB security programs. Shorting pins finally stopped the power. But even with no power, high frequency signals were still there. Conclusion: Power analysis does not require power! Q: I've done implementations designed to fix the number of clock cycles for crypto operations. A: Constant time does not mean constant power. Q: Well, it is pretty close. (... This was disputed by many people in the room. It seems easier to do for symmetric operations thna asymmetric ones. ...) ------------------------------------------------------------------------ Open Microphone C: I'd like to commend all of the speakers for getting their slides to Russ and Sam in time for them to be posted before the session. The has not been the case at other recent SAAG meetings. C: I notice that two presentations had the same theme. You have to remember the layers below you, like spoofing MAC addresses and power analysis. Both are widely know and commonly forgotten. Need to open analysis to all layers of the protocol stack. Q: As an addition to the first presentation, to aid protocol testing we should provide not only a flow test general document, but also a torture test document. While you can't test everything, that sort of thing has found a lot of problems. Implementers understand test cases. C: I'd like to second the recommendation for documenting torture tests. A: SIP and S/MIME have documents that include test data for things that are supposed to work as well as things that are supposed to fail. C: Maybe the protocol specification people shouldn't do the tests. Hard enough to find people to do the protocol work. There are things like Google Summer of Programming which show that programming resources are available. Maybe grad students would be available to write attack tools and tests. C: Protocol designers have best idea of where weak points are. Implementors need to know too. Protocol designers should include warnings in their documents. C: There are companies that sell test suites. From fergdawg@netzero.net Mon Nov 13 13:36:06 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id kADIa6BP016495 for ; Mon, 13 Nov 2006 13:36:06 -0500 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id kADIZljQ009069 for ; Mon, 13 Nov 2006 13:35:47 -0500 (EST) Received: from outbound-mail.lax.untd.com (outbound-mail.lax.untd.com [64.136.28.164]) by mit.edu (Spam Firewall) with SMTP id 60CDE5C9E8 for ; Mon, 13 Nov 2006 13:34:58 -0500 (EST) Received: from webmail04.lax.untd.com (webmail04.lax.untd.com [10.131.27.144]) by smtpout07.lax.untd.com with SMTP id AABCXTQWYAXVSKRA for (sender ); Mon, 13 Nov 2006 10:33:58 -0800 (PDT) X-UNTD-OriginStamp: AcganUYbgVGZ0C6nm/9IPatablCmMCeKlJ+4LgamHW01vM+X+Z7+ow== Received: (from fergdawg@netzero.net) by webmail04.lax.untd.com (jqueuemail) id L63YKSQH; Mon, 13 Nov 2006 10:33:15 PST Received: from [168.61.0.42] by webmail04.lax.untd.com with HTTP: Mon, 13 Nov 2006 18:32:51 GMT X-Originating-IP: [168.61.0.42] Mime-Version: 1.0 From: "Fergie" Date: Mon, 13 Nov 2006 18:32:51 GMT To: saag@mit.edu X-Mailer: Webmail Version 4.0 Content-Disposition: inline Content-Type: text/plain Message-Id: <20061113.103315.28.1437125@webmail04.lax.untd.com> X-ContentStamp: 16:8:2501324113 X-MAIL-INFO: 41e7fe6fe702fe0a02470a2f0edea38eae039e6a5b8f4f4f1ece27cefb57d78e83fe0f8e3f0a576e07f79f5e078f3e4e3baa5e3a5e979adb97facada9a73fa0277bb07caba3ea773779f87f3ba9b13ababc7dbaa1af7dbafdfdbfa93cefe1bcee7b3fee72ffe0a2f47df6aea4a230b0bf3c7f36b6e5b1f8b8b7aa717ee3b571e6eebd7a3fe37fee72f031b6ffe02e3f71adff7ab971aab4a1ade4a3a233b874e633333bacfba9b132e935a5aaa6b3f2ac7aabeab7edaab07aa1a6e4a2a73f78b471be77f671b67670e472f43039ac3c39ef393c3ceea434f8e6e0bd7ebeb1b83a3b3e7 X-UNTD-Peer-Info: 10.131.27.144|webmail04.lax.untd.com|webmail04.lax.untd.com|fergdawg@netzero.net X-Spam-Score: 0.13 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id kADIa6BP016495 Subject: [saag] RFC2827-bis comments solicitation X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2006 18:36:06 -0000 First, sorry for any duplicates, but we wanted to reach all interested parties. After several discussions with many different folks last week at IETF 67 in San Diego, as well as various people over the course of the past few months, Dan Senie and I have decided to undertake an effort to "update" RFC2827/BCP38 [1]. I know that I'm not the only person who has heard various discussions in the past couple of years that concluded that (paraphrased), "BCP38 needs to be updated." Now is your chance to speak up. :-) We would very much like to solicit comments & suggestions from the community-at-large on areas where you feel BCP38 is lacking, or in areas where you feel it does not properly address with regards to prohibiting source-spoofed traffic from any given administrative network boundary, given that some technical aspects of the Internet may have changed since it's publication. While we acknowledge that a uniform application of a source address verification architecture/ingress filtering scheme will not mitigate _all_ "unwanted traffic" [2] in the Internet, it will most certainly address the issue of hosts which attempt to source-spoof traffic into the Internet. I have not set up a mailing list for this yet, but if there is enough discussion/input, I will make an effort to do so (or perhaps the SAVA mailing list [3] might be a good place for discussion). In the interim, you can contact me or Dan directly: Paul Ferguson: fergdawg(at)netzero.net Dan Senie: dts(at)senie.com Thanks, fergie & dan p.s. Also, for anyone who might be interesting in related work, there is an effort to bring some additional work into the IETF called SAVA, or Source Address Validation Architecture [4]. [1] http://www.rfc-editor.org/rfc/rfc2827.txt [2] http://www.iab.org/about/workshops/unwantedtraffic/index.html [3] http://www.nrc.tsinghua.edu.cn/mailman/listinfo/sava [4] http://www.nrc.tsinghua.edu.cn/pipermail/sava/2006-September/000004.html -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/ From fergdawg@netzero.net Fri Nov 17 13:48:25 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id kAHImPYU011469 for ; Fri, 17 Nov 2006 13:48:25 -0500 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id kAHImIVP013041 for ; Fri, 17 Nov 2006 13:48:18 -0500 (EST) Received: from outbound-mail.lax.untd.com (outbound-mail.lax.untd.com [64.136.28.164]) by mit.edu (Spam Firewall) with SMTP id C44F9C0DAC for ; Fri, 17 Nov 2006 13:48:16 -0500 (EST) Received: from webmail53.lax.untd.com (webmail53.lax.untd.com [10.131.27.193]) by smtpout01.lax.untd.com with SMTP id AABCX6A89A4AS63J for (sender ); Fri, 17 Nov 2006 10:47:59 -0800 (PST) X-UNTD-OriginStamp: AcganUYbgVGZ0C6nm/9IPatablCmMCeKG3YAXJ4nr/4zf/ZMHA3T6A== Received: (from fergdawg@netzero.net) by webmail53.lax.untd.com (jqueuemail) id L7EAXZL6; Fri, 17 Nov 2006 10:47:06 PST Received: from [168.61.0.42] by webmail53.lax.untd.com with HTTP: Fri, 17 Nov 2006 18:47:04 GMT X-Originating-IP: [168.61.0.42] Mime-Version: 1.0 From: "Fergie" Date: Fri, 17 Nov 2006 18:47:04 GMT To: saag@mit.edu X-Mailer: Webmail Version 4.0 Content-Disposition: inline Content-Type: text/plain Message-Id: <20061117.104706.717.1003483@webmail53.lax.untd.com> X-ContentStamp: 31:15:1664305257 X-MAIL-INFO: 55434b8343874be3873be35a3317676f233f47ceeeef7a7a7f8f028f13bf1f6faa4b2f6f1ae3bf03fa734ac3faef7e77f75bc3c7c3f31eeaf35f1e8b1e275f873a9afaa35e7ebe273a4a97eb5ed38a6a6a1bea5b4f73eab76bea5f578f4ba78f433e4b435a4be35a3b6bceb39e9b0a0aeb1bebd703eebbe7e74ebefe2bf7bf7f030e1f674bda4b435a3fa7834b87af734f6b736af34f6a9e4f179ec79bf797770bdede5edf5ed38a2a57abab5bd71acb1b5bca6a638b6afa5b4f039ecb2773e73ba743fbbaa7baba333b5a073f1e6e6e47eb576e8fb3077a6f030a1f0e0ea7aa673e43 X-UNTD-Peer-Info: 10.131.27.193|webmail53.lax.untd.com|webmail53.lax.untd.com|fergdawg@netzero.net X-Spam-Score: 0.13 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id kAHImPYU011469 Subject: [saag] ietf-bcp38bis mailing list [Was: RFC2827-bis comments solicitation] X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2006 18:48:25 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 As a follow-up to my previous message re: "RFC2827-bis comments solicitation", we now have a dedicated mailing list for discussion of bringing BCP38 up-to-date: [snip] ietf-bcp38bis mailing list The ietf-bcp38bis mailing list is for discussing an update to BCP 38, "Network Ingress Filtering". To subscribe to the mailing list, send a message to: ietf-bcp38bis-request@vpnc.org ...with the single word 'subscribe' in the body of the message. [snip] The web site for this mailing list is sponsored by the VPN Consortium. If you have any suggestions for additions or corrections to this web page, please send them to paul.hoffman(at)vpnc.org. Many thanks to Paul Hoffman for hosting the list. - - ferg > >First, sorry for any duplicates, but we wanted to reach all >interested parties. > >After several discussions with many different folks last week >at IETF 67 in San Diego, as well as various people over the >course of the past few months, Dan Senie and I have decided to >undertake an effort to "update" RFC2827/BCP38 [1]. > >I know that I'm not the only person who has heard various >discussions in the past couple of years that concluded that >(paraphrased), "BCP38 needs to be updated." > >Now is your chance to speak up. :-) > >We would very much like to solicit comments & suggestions from the >community-at-large on areas where you feel BCP38 is lacking, or in >areas where you feel it does not properly address with regards to >prohibiting source-spoofed traffic from any given administrative >network boundary, given that some technical aspects of the Internet >may have changed since it's publication. > >While we acknowledge that a uniform application of a source address >verification architecture/ingress filtering scheme will not mitigate >_all_ "unwanted traffic" [2] in the Internet, it will most certainly >address the issue of hosts which attempt to source-spoof traffic into >the Internet. > >I have not set up a mailing list for this yet, but if there is >enough discussion/input, I will make an effort to do so (or perhaps >the SAVA mailing list [3] might be a good place for discussion). In >the interim, you can contact me or Dan directly: > > Paul Ferguson: fergdawg(at)netzero.net > Dan Senie: dts(at)senie.com > > >Thanks, > >fergie & dan > >p.s. Also, for anyone who might be interesting in related work, >there is an effort to bring some additional work into the IETF >called SAVA, or Source Address Validation Architecture [4]. > > >[1] http://www.rfc-editor.org/rfc/rfc2827.txt >[2] http://www.iab.org/about/workshops/unwantedtraffic/index.html >[3] http://www.nrc.tsinghua.edu.cn/mailman/listinfo/sava >[4] >http://www.nrc.tsinghua.edu.cn/pipermail/sava/2006-September/000004.html -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.1 (Build 1557) wj8DBQFFXgK9q1pz9mNUZTMRArqOAKDzeVk2VCfD/Ru0OtrgtNLyJ90MqACePChS 2dqaaWAbXonj185jAtwnZ8Q= =jieX -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/ From ekr@networkresonance.com Fri Nov 17 20:22:45 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id kAI1MjT8023850 for ; Fri, 17 Nov 2006 20:22:45 -0500 Received: from mit.mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id kAI1MdXw015430 for ; Fri, 17 Nov 2006 20:22:39 -0500 (EST) Received: from laser.networkresonance.com (laser.networkresonance.com [198.144.196.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.mit.edu (Spam Firewall) with ESMTP id DE46A316D07 for ; Fri, 17 Nov 2006 20:22:38 -0500 (EST) Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id 142355C01E; Fri, 17 Nov 2006 17:25:32 -0800 (PST) To: saag@mit.edu, tls@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.2; XEmacs 21.4 (patch 19) Date: Fri, 17 Nov 2006 17:22:27 -0800 From: Eric Rescorla Message-Id: <20061118012532.142355C01E@laser.networkresonance.com> X-Spam-Score: 0.01 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] IETF67 TLS Summary X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Nov 2006 01:22:45 -0000 TLS met on Friday morning. The major discussion item was TLS 1.2, which is moving along. The only contentious issue is the PRF. The general theory seemed to be to have a default PRF (based on SHA-256) and then require future cipher suites to define their own PRF with a preference for something based on the TLS PRF. We also discussed the IV for counter mode and GCM but no consensus was reached and the issue will be taken to the list. Pasi Eronen presented on a bunch of bugs in the way that TLS stacks handle legal but unusual record layer constructs. These don't appear to be security issues but rather interop issues. It was suggested that TLS 1.2 forbid some unusual behaviors (e.g., empty fragments in the handshake). Text will be proposed on the list. Russ Housley gave a presentation on adding signatures to TLS for evidentiary purposes. This was somewhat contentious but the WG seemed generally in favor. This would require a charter change and discussion on the list. Tim Polk gave a presentation on some issues NIST had with TLS. Mostly these are minor issues or clarifications. Resolutions to be proposed on the list. Stefan Stantesson gave a presentation on an approach he's been working on for integrating GSS-API with TLS. This was quite contentious and no consensus seemed on hand. However, no actual draft is available so the next stage is for Stefan to circulate one. -Ekr From hartmans@MIT.EDU Tue Nov 21 14:10:46 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id kALJAkP1008354 for ; Tue, 21 Nov 2006 14:10:46 -0500 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id kALJAh9n017583 for ; Tue, 21 Nov 2006 14:10:44 -0500 (EST) Received: from carter-zimmerman.mit.edu (carter-zimmerman.dyn.MIT.EDU [18.188.3.148]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 11B4F64BBB for ; Tue, 21 Nov 2006 14:10:40 -0500 (EST) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 2592BE02A3; Tue, 21 Nov 2006 14:10:32 -0500 (EST) From: Sam Hartman To: anonsec@postel.org, saag@MIT.EDU Date: Tue, 21 Nov 2006 14:10:32 -0500 Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] Seeking Second co-chair for BTNS working Group X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Nov 2006 19:10:47 -0000 Hi, folks. Love HörnqvistÅstrand and I are searching for a second chair for the Better than Nothing Security group. Love is doing a fine job, but has asked for some help. Also, it is generally best if working groups have two chairs. I'd like to ask people to volunteer to be considered as BTNS co-chair. Please send a note expressing your interest and discussing qualifications to Russ and I by December 7, 2006. I will be discussing details of applicants with Love and Russ. Chairs should have the following qualifications: * Familiarity and experience with the IETF process either as an author or chair. * Interest in the BTNS working group's work areas. * Familiarity with IPsec. * Willingness to dedicate at least 3 hours a week to the working group. Thanks, --Sam From pekkas@netcore.fi Thu Nov 30 02:14:47 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id kAU7EiQw008773 for ; Thu, 30 Nov 2006 02:14:47 -0500 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id kAU7EcSo024471 for ; Thu, 30 Nov 2006 02:14:38 -0500 (EST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by mit.edu (Spam Firewall) with ESMTP id 11578C33F8 for ; Thu, 30 Nov 2006 02:14:36 -0500 (EST) Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id kAU7EYOq027158 for ; Thu, 30 Nov 2006 09:14:35 +0200 Date: Thu, 30 Nov 2006 09:14:34 +0200 (EET) From: Pekka Savola To: saag@mit.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Status: Clean X-Spam-Status: No, score=-0.0 required=5.0 tests=NO_RELAYS autolearn=failed version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on otso.netcore.fi X-Spam-Score: 0.12 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] CIPSO implementations X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2006 07:14:47 -0000 Hi, Some time ago, someone implemented CIPSO [1] from 1992 on Linux, and it's in the mainline kernel now. A bit google seems to indicate that TrustedBSD has had some interest in it as well, and it seems to be implemented in (Trusted) Solaris as well. I wonder why this never became an RFC? As there seems to be renewed interes in labeled networking, I wonder if there is anything the IETF should do about this? [1] http://www.watersprings.org/pub/id/draft-ietf-cipso-ipsecurity-01.txt For IPv6: http://www.watersprings.org/pub/id/draft-belgaied-ipv6-lsopt-00.txt -- 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 kent@bbn.com Thu Nov 30 02:56:42 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id kAU7uefd019303 for ; Thu, 30 Nov 2006 02:56:40 -0500 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id kAU7uXaY021569 for ; Thu, 30 Nov 2006 02:56:33 -0500 (EST) Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by mit.edu (Spam Firewall) with ESMTP id 1DBAA33A8AA for ; Thu, 30 Nov 2006 02:56:32 -0500 (EST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[196.192.2.69]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1GpgmS-0007r4-5y; Thu, 30 Nov 2006 02:56:29 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 30 Nov 2006 02:52:09 -0500 To: Pekka Savola From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.12 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] CIPSO implementations X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2006 07:56:42 -0000 At 9:14 AM +0200 11/30/06, Pekka Savola wrote: >Hi, > >Some time ago, someone implemented CIPSO [1] from 1992 on Linux, and >it's in the mainline kernel now. A bit google seems to indicate that >TrustedBSD has had some interest in it as well, and it seems to be >implemented in (Trusted) Solaris as well. > >I wonder why this never became an RFC? As there seems to be renewed >interes in labeled networking, I wonder if there is anything the IETF >should do about this? > >[1] >http://www.watersprings.org/pub/id/draft-ietf-cipso-ipsecurity-01.txt > >For IPv6: >http://www.watersprings.org/pub/id/draft-belgaied-ipv6-lsopt-00.txt > Despite the appearance of the word "commercial" its name, this extension was designed to support the needs of the U.S. DoD and Intelligence Community, as defined in what was called the Compartmented Mode Workstation (CMW) project. The word "commercial" refers to the fact that it was commercial organizations (Sun, Dec, HP, IBM, ...) that implemented the CMW features and drafted the extension in support of their products. Unfortunately, there is no basis to assume that the extension is well-suited to labelled networking, as you indicate, given the design history of the extension. As for why this never became an RFC, I'll note that the CMW project went away, along with the trusted workstation business of several of the companies noted above. Steve From scampbell@assureddecisions.com Thu Nov 30 14:35:29 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id kAUJZTX4030410 for ; Thu, 30 Nov 2006 14:35:29 -0500 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id kAUJZR18020658 for ; Thu, 30 Nov 2006 14:35:28 -0500 (EST) Received: from mout.perfora.net (mout.perfora.net [217.160.230.41]) by mit.edu (Spam Firewall) with ESMTP id 4188632D5BA for ; Thu, 30 Nov 2006 14:35:27 -0500 (EST) Received: from [172.23.126.14] (helo=ntxsmtpus.exchange.xchg) by mrelay.perfora.net (node=mrelayus0) with ESMTP (Nemesis), id 0MKoyl-1Gprgj2tBh-00045O; Thu, 30 Nov 2006 14:35:20 -0500 Received: from ntxbeus05.exchange.xchg ([172.23.126.6]) by ntxsmtpus.exchange.xchg with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Nov 2006 14:35:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 30 Nov 2006 14:35:16 -0500 Message-ID: <3B2E3342C52B074CA926404692A7C35A0181A226@ntxbeus05.exchange.xchg> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] CIPSO implementations Thread-Index: AccUt2lb8OdS2PWwQdS+gHlIY2QjNA== From: "Shawn Campbell" To: "Stephen Kent" , "Pekka Savola" X-OriginalArrivalTime: 30 Nov 2006 19:35:17.0266 (UTC) FILETIME=[AA08DF20:01C714B6] X-Spam-Score: 0.72 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id kAUJZTX4030410 Cc: saag@mit.edu Subject: Re: [saag] CIPSO implementations X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2006 19:35:30 -0000 Most of the CMW work has been/was absorbed into other lines. For example, Addamax became Argus became Trusted Computing Solutions (their secure Linux version), SecureWare (Trusted SCO UNIX) became Security First/HP became HP Trusted OS, Sun's Trusted Solaris has been absorbed into Solaris 10 Trusted Extensions, other next steps like Trusted Mach (TIS) became Flask (I think associated in some degree with TrustedBSD) became SELinux. No idea what became of Ultrix - unless like VMS it became part of eventual Windows security capabilities. All the genealogy may not be entirely accurate, but probably close enough. There was an RFC 1108 IPSO (not exactly CIPSO but very close) that was referenced in RFC 2401, but I don't think that has been carried forward into IPv6. Shawn -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com] Sent: Thursday, November 30, 2006 2:52 AM To: Pekka Savola Cc: saag@mit.edu Subject: Re: [saag] CIPSO implementations At 9:14 AM +0200 11/30/06, Pekka Savola wrote: >Hi, > >Some time ago, someone implemented CIPSO [1] from 1992 on Linux, and >it's in the mainline kernel now. A bit google seems to indicate that >TrustedBSD has had some interest in it as well, and it seems to be >implemented in (Trusted) Solaris as well. > >I wonder why this never became an RFC? As there seems to be renewed >interes in labeled networking, I wonder if there is anything the IETF >should do about this? > >[1] >http://www.watersprings.org/pub/id/draft-ietf-cipso-ipsecurity-01.txt > >For IPv6: >http://www.watersprings.org/pub/id/draft-belgaied-ipv6-lsopt-00.txt > Despite the appearance of the word "commercial" its name, this extension was designed to support the needs of the U.S. DoD and Intelligence Community, as defined in what was called the Compartmented Mode Workstation (CMW) project. The word "commercial" refers to the fact that it was commercial organizations (Sun, Dec, HP, IBM, ...) that implemented the CMW features and drafted the extension in support of their products. Unfortunately, there is no basis to assume that the extension is well-suited to labelled networking, as you indicate, given the design history of the extension. As for why this never became an RFC, I'll note that the CMW project went away, along with the trusted workstation business of several of the companies noted above. Steve From smb@cs.columbia.edu Thu Nov 30 16:32:35 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id kAULWYWF028328 for ; Thu, 30 Nov 2006 16:32:34 -0500 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id kAULVsHD016187 for ; Thu, 30 Nov 2006 16:31:54 -0500 (EST) Received: from machshav.com (machshav.com [147.28.0.16]) by mit.edu (Spam Firewall) with ESMTP id 56AD2FBA06 for ; Thu, 30 Nov 2006 16:31:53 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 5A894FB56D; Thu, 30 Nov 2006 21:31:49 +0000 (UTC) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id AA40EFB563; Thu, 30 Nov 2006 21:31:48 +0000 (UTC) Received: by berkshire.machshav.com (Postfix, from userid 54047) id 1EAB53C03F8; Thu, 30 Nov 2006 16:31:48 -0500 (EST) Date: Thu, 30 Nov 2006 16:31:48 -0500 From: "Steven M. Bellovin" To: "Shawn Campbell" In-Reply-To: <3B2E3342C52B074CA926404692A7C35A0181A226@ntxbeus05.exchange.xchg> References: <3B2E3342C52B074CA926404692A7C35A0181A226@ntxbeus05.exchange.xchg> Organization: Columbia University X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20061130213148.1EAB53C03F8@berkshire.machshav.com> X-Spam-Score: 0.13 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Pekka Savola Subject: Re: [saag] CIPSO implementations X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2006 21:32:35 -0000 On Thu, 30 Nov 2006 14:35:16 -0500 "Shawn Campbell" wrote: > Most of the CMW work has been/was absorbed into other lines. For > example, Addamax became Argus became Trusted Computing Solutions > (their secure Linux version), SecureWare (Trusted SCO UNIX) became > Security First/HP became HP Trusted OS, Sun's Trusted Solaris has > been absorbed into Solaris 10 Trusted Extensions, other next steps > like Trusted Mach (TIS) became Flask (I think associated in some > degree with TrustedBSD) became SELinux. No idea what became of > Ultrix - unless like VMS it became part of eventual Windows security > capabilities. All the genealogy may not be entirely accurate, but > probably close enough. > I think this summarizes the problem -- there's a scarcity of hosts. That is, if I can't trust a host to label a packet properly or to do the right thing with a received label, what's the point of honoring labels in the network? --Steve Bellovin, http://www.cs.columbia.edu/~smb From scampbell@assureddecisions.com Thu Nov 30 21:11:00 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id kB12B0X8003998 for ; Thu, 30 Nov 2006 21:11:00 -0500 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id kB12Arq0016118 for ; Thu, 30 Nov 2006 21:10:54 -0500 (EST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.191]) by mit.edu (Spam Firewall) with ESMTP id E0CFC14AFD4 for ; Thu, 30 Nov 2006 21:10:52 -0500 (EST) Received: from [212.227.126.200] (helo=mrvnet.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1GpxqM-0002n6-00; Fri, 01 Dec 2006 03:09:38 +0100 Received: from [172.23.1.26] (helo=xchgsmtp.exchange.xchg) by mrvnet.kundenserver.de with smtp (Exim 3.35 #1) id 1GpxqL-00075K-00; Fri, 01 Dec 2006 03:09:37 +0100 Received: from NTXBEUS01.exchange.xchg ([172.23.129.4]) by xchgsmtp.exchange.xchg with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Dec 2006 03:09:37 +0100 Received: from ntxbeus05.exchange.xchg ([172.23.126.6]) by NTXBEUS01.exchange.xchg with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Nov 2006 21:09:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 30 Nov 2006 21:09:36 -0500 Message-ID: <3B2E3342C52B074CA926404692A7C35A0181A287@ntxbeus05.exchange.xchg> In-Reply-To: <20061130213148.1EAB53C03F8@berkshire.machshav.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] CIPSO implementations Thread-Index: AccUxvMUp48xNO1PRsGcZZAH5rMnBQAJsoDQ From: "Shawn Campbell" To: "Steven M. Bellovin" X-OriginalArrivalTime: 01 Dec 2006 02:09:36.0466 (UTC) FILETIME=[C0044B20:01C714ED] X-Provags-ID: kundenserver.de abuse@kundenserver.de ident:@172.23.1.26 X-Spam-Score: 0.72 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id kB12B0X8003998 Cc: saag@mit.edu, Pekka Savola Subject: Re: [saag] CIPSO implementations X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2006 02:11:00 -0000 >From a database view, Oracle has an interesting take on that with their OLS. Can that record label be trusted when the underlying enforcement of the OS is not bound to the label? I believe IPSO/CIPSO were also part of the time when the protocol stack was often on a NIC. There were some efforts to try and bind the network label from the NIC's protocol stack with an OS label. I don't know if there were any successes in that arena. -----Original Message----- From: Steven M. Bellovin [mailto:smb@cs.columbia.edu] Sent: Thursday, November 30, 2006 4:32 PM To: Shawn Campbell Cc: Stephen Kent; Pekka Savola; saag@mit.edu Subject: Re: [saag] CIPSO implementations On Thu, 30 Nov 2006 14:35:16 -0500 "Shawn Campbell" wrote: > Most of the CMW work has been/was absorbed into other lines. For > example, Addamax became Argus became Trusted Computing Solutions > (their secure Linux version), SecureWare (Trusted SCO UNIX) became > Security First/HP became HP Trusted OS, Sun's Trusted Solaris has > been absorbed into Solaris 10 Trusted Extensions, other next steps > like Trusted Mach (TIS) became Flask (I think associated in some > degree with TrustedBSD) became SELinux. No idea what became of > Ultrix - unless like VMS it became part of eventual Windows security > capabilities. All the genealogy may not be entirely accurate, but > probably close enough. > I think this summarizes the problem -- there's a scarcity of hosts. That is, if I can't trust a host to label a packet properly or to do the right thing with a received label, what's the point of honoring labels in the network? --Steve Bellovin, http://www.cs.columbia.edu/~smb From kent@bbn.com Fri Dec 1 00:41:57 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id kB15fvRb030024 for ; Fri, 1 Dec 2006 00:41:57 -0500 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id kB15fnKQ013629 for ; Fri, 1 Dec 2006 00:41:49 -0500 (EST) Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by mit.edu (Spam Firewall) with ESMTP id 1F42113C57E for ; Fri, 1 Dec 2006 00:41:48 -0500 (EST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[196.192.2.69]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Gq19f-00040X-4x; Fri, 01 Dec 2006 00:41:47 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <3B2E3342C52B074CA926404692A7C35A0181A287@ntxbeus05.exchange.xchg> References: <3B2E3342C52B074CA926404692A7C35A0181A287@ntxbeus05.exchange.xchg> Date: Fri, 1 Dec 2006 00:07:40 -0500 To: "Shawn Campbell" From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Pekka Savola Subject: Re: [saag] CIPSO implementations X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2006 05:41:57 -0000 At 9:09 PM -0500 11/30/06, Shawn Campbell wrote: > >From a database view, Oracle has an interesting take on that with their >OLS. Can that record label be trusted when the underlying enforcement >of the OS is not bound to the label? > >I believe IPSO/CIPSO were also part of the time when the protocol stack >was often on a NIC. There were some efforts to try and bind the network >label from the NIC's protocol stack with an OS label. I don't know if >there were any successes in that arena. That iwas not the motivation for IPSO, and not really for CISPO either. I am the author of 1108, and the rationale for IPSO was a crypto device called BLACKER. It needed the extension to work in multi-level security environments. Of course there were few if any approved MLS hosts, to this was largely not useful. CIPSO, as I noted, was developed for the CMW work, and the assumption there was that the hosts were trusted and needed a way to exchange security label data not just for security levels, but also for compartments. If a network crypto device was used, e.g., BLACKER or a follow on device, the notion that this device would be programmed to examine the labels and enforce access controls at the network layer, to provide a layer access control model, e.g., a network crypto device would be configured to restrict inbound and outbound labels to fall within the range for which the host behind it was accredited. Steve From scampbell@assureddecisions.com Fri Dec 1 08:23:12 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id kB1DNCBr019293 for ; Fri, 1 Dec 2006 08:23:12 -0500 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id kB1DN2W9020317 for ; Fri, 1 Dec 2006 08:23:03 -0500 (EST) Received: from mout.perfora.net (mout.perfora.net [217.160.230.40]) by mit.edu (Spam Firewall) with ESMTP id 56A2E333C4D for ; Fri, 1 Dec 2006 08:22:59 -0500 (EST) Received: from [172.23.126.14] (helo=ntxsmtpus.exchange.xchg) by mrelay.perfora.net (node=mrelayus1) with ESMTP (Nemesis), id 0MKp2t-1Gq8Lu3Qhq-0003tx; Fri, 01 Dec 2006 08:22:58 -0500 Received: from ntxbeus05.exchange.xchg ([172.23.126.6]) by ntxsmtpus.exchange.xchg with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Dec 2006 08:22:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 1 Dec 2006 08:22:52 -0500 Message-ID: <3B2E3342C52B074CA926404692A7C35A0181A2F4@ntxbeus05.exchange.xchg> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] CIPSO implementations Thread-Index: AccVC3m6bwhuR2iiR3ebEKb63bJ8WQAPeq1g From: "Shawn Campbell" To: "Stephen Kent" X-OriginalArrivalTime: 01 Dec 2006 13:22:53.0065 (UTC) FILETIME=[CE441F90:01C7154B] X-Spam-Score: 0.72 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id kB1DNCBr019293 Cc: saag@mit.edu, Pekka Savola Subject: Re: [saag] CIPSO implementations X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2006 13:23:14 -0000 I understand. I was referencing some work in the early 90s to attempt to bind the Verdix/Cryptek LAN NIC with AT&T (B1/B2?) Trusted Sys V and other CMW implementations. This was some experimentation to try and get any type of system (network/host) labeling. I think the Motorola NES was also part of the efforts. I believe the efforts were sort of a chocolate (TCSEC/NSA/TNI)/peanut butter (DoDIIS/DIA/CMW) exercise. Sorry Pekka, I took us off the original question. A very similar thread occurred a few years ago concerning IPSec labeling that may provide some additional insight (http://www.vpnc.org/ietf-ipsec/01.ipsec/msg00320.html). Steve K., Steve B., and others, provided a lot of insight on labeling issues in that thread. I don't know of any labeling work (outside of information labeling) that isn't associated with IPSec (and associated RFCs). Shawn -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com] Sent: Friday, December 01, 2006 12:08 AM To: Shawn Campbell Cc: Steven M. Bellovin; saag@mit.edu; Pekka Savola Subject: Re: [saag] CIPSO implementations At 9:09 PM -0500 11/30/06, Shawn Campbell wrote: > >From a database view, Oracle has an interesting take on that with their >OLS. Can that record label be trusted when the underlying enforcement >of the OS is not bound to the label? > >I believe IPSO/CIPSO were also part of the time when the protocol stack >was often on a NIC. There were some efforts to try and bind the network >label from the NIC's protocol stack with an OS label. I don't know if >there were any successes in that arena. That iwas not the motivation for IPSO, and not really for CISPO either. I am the author of 1108, and the rationale for IPSO was a crypto device called BLACKER. It needed the extension to work in multi-level security environments. Of course there were few if any approved MLS hosts, to this was largely not useful. CIPSO, as I noted, was developed for the CMW work, and the assumption there was that the hosts were trusted and needed a way to exchange security label data not just for security levels, but also for compartments. If a network crypto device was used, e.g., BLACKER or a follow on device, the notion that this device would be programmed to examine the labels and enforce access controls at the network layer, to provide a layer access control model, e.g., a network crypto device would be configured to restrict inbound and outbound labels to fall within the range for which the host behind it was accredited. Steve From paul.moore@hp.com Fri Dec 1 15:30:41 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id kB1KUfxe009566 for ; Fri, 1 Dec 2006 15:30:41 -0500 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id kB1KUHtK016754 for ; Fri, 1 Dec 2006 15:30:17 -0500 (EST) Received: from ccerelrim04.cce.hp.com (smtp.cce.hp.com [161.114.21.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id E275A15950E for ; Fri, 1 Dec 2006 15:30:16 -0500 (EST) Received: from ccerelrim04.cce.hp.com (localhost.localdomain [127.0.0.1]) by receive-from-antispam-filter (Postfix) with SMTP id EFF0D4015; Fri, 1 Dec 2006 14:30:15 -0600 (CST) Received: from mailstation.cce.hp.com (mailstation.cce.hp.com [161.114.20.124]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by ccerelrim04.cce.hp.com (Postfix) with ESMTP id BD2D44020; Fri, 1 Dec 2006 14:30:15 -0600 (CST) Received: from stuffed.lan (c-24-62-171-110.hsd1.nh.comcast.net [24.62.171.110]) by mailstation.cce.hp.com (Postfix) with ESMTP id 7B845D27D; Fri, 1 Dec 2006 14:30:12 -0600 (CST) From: Paul Moore To: saag@mit.edu Date: Fri, 1 Dec 2006 15:30:07 -0500 User-Agent: KMail/1.9.5 Organization: Hewlett Packard MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200612011530.07987.paul.moore@hp.com> X-PMX-Version: 5.2.1.279297, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.12.1.121434 X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: Pekka Savola Subject: [saag] Why the IETF should care about labeled networking (was: CIPSO implementations) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2006 20:30:41 -0000 Hello, Sorry for starting a new thread, but I just joined this list and as a result I don't have the original posts to reply to. Pekka sent me a pointer to the CIPSO thread from the past two days, and I thought I might be able to add something of value to the conversation. As others have pointed out there have been multiple attempts at labeled networking over the years including RIPSO, CIPSO, TSIX/MAXSIX/SAMP, and labeled IPsec; some of these attempts have resulted in outdated standards, some have stagnated as expired drafts, and some have simply disappeared. However, despite the apparent lack of usable labeled networking standards there remains a group of users who do care very much about labeled networking. The problem is that these users tend to be rather quiet and in the grand view of the networked world I will admit they represent only a small percentage. As a result, the current state of labeled networking is far from ideal. A series of de-facto standards have evolved based around expired drafts (CIPSO) and lost standards from defunct SIGs (TSIG). As you can imagine this makes the barrier for entry very high and even then proving interoperability can be troublesome. I personally thing this is a problem the IETF can help solve; while the number of players are small, having a forum where we can publish standards or even just informational specifications would go a long ways towards making labeled networking more palatable. There is still a need for labeled networking, you just have to dig a little to see it. [In the interest of full disclosure, I was the one responsible for the CIPSO implementation for Linux which was just released this week as part of the Linux 2.6.19 kernel.] -- paul moore linux security @ hp From sommerfeld@sun.com Fri Dec 1 18:00:23 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id kB1N0NXH013658 for ; Fri, 1 Dec 2006 18:00:23 -0500 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id kB1N0CeS004164 for ; Fri, 1 Dec 2006 18:00:12 -0500 (EST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by mit.edu (Spam Firewall) with ESMTP id 57CCA11F249 for ; Fri, 1 Dec 2006 18:00:11 -0500 (EST) Received: from eastmail4bur.east.Sun.COM ([129.148.13.1]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kB1N088Z010828; Fri, 1 Dec 2006 16:00:08 -0700 (MST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail4bur.east.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id kB1N07JM004224; Fri, 1 Dec 2006 18:00:07 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id kB1N06KZ020215; Fri, 1 Dec 2006 18:00:07 -0500 (EST) From: Bill Sommerfeld To: Paul Moore In-Reply-To: <200612011530.07987.paul.moore@hp.com> References: <200612011530.07987.paul.moore@hp.com> Content-Type: text/plain Date: Fri, 01 Dec 2006 18:00:06 -0500 Message-Id: <1165014006.18458.85.camel@thunk> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.01 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Pekka Savola Subject: Re: [saag] Why the IETF should care about labeled networking (was: CIPSO implementations) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2006 23:00:23 -0000 On Fri, 2006-12-01 at 15:30 -0500, Paul Moore wrote: > The problem is that these users tend to be rather quiet Indeed. > ... the current state of labeled networking is far from ideal. A > series of de-facto standards have evolved based around expired drafts (CIPSO) > and lost standards from defunct SIGs (TSIG). As you can imagine this makes > the barrier for entry very high and even then proving interoperability can be > troublesome. I personally think this is a problem the IETF can help solve; > while the number of players are small, having a forum where we can publish > standards or even just informational specifications would go a long ways > towards making labeled networking more palatable. One of the main points of unpalatability for me is the trust many labelling schemes place in the packet forwarding infrastructure. That rules out IPSO, CIPSO, etc., leaving some flavor of labelled IPsec. Conveniently, part of my day job involves work on Solaris's IPsec stack. I've recently started investigating labelled IPsec -- so count me as someone who has recently started to care about labelled networking. - Bill From nw141292@binky.Central.Sun.COM Fri Dec 1 18:35:47 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id kB1NZlPa022118 for ; Fri, 1 Dec 2006 18:35:47 -0500 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id kB1NZexj010321 for ; Fri, 1 Dec 2006 18:35:41 -0500 (EST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by mit.edu (Spam Firewall) with ESMTP id 5E3D82F6798 for ; Fri, 1 Dec 2006 18:35:40 -0500 (EST) Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kB1NZdsG027727 for ; Fri, 1 Dec 2006 16:35:39 -0700 (MST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id kB1NZcYx011363 for ; Fri, 1 Dec 2006 16:35:38 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id kB1NZZpE028094; Fri, 1 Dec 2006 17:35:37 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id kB1NZYwt028093; Fri, 1 Dec 2006 17:35:34 -0600 (CST) Date: Fri, 1 Dec 2006 17:35:34 -0600 From: Nicolas Williams To: Bill Sommerfeld Message-ID: <20061201233534.GE5938@binky.Central.Sun.COM> References: <200612011530.07987.paul.moore@hp.com> <1165014006.18458.85.camel@thunk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1165014006.18458.85.camel@thunk> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Paul Moore , Pekka Savola Subject: Re: [saag] Why the IETF should care about labeled networking (was: CIPSO implementations) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2006 23:35:47 -0000 On Fri, Dec 01, 2006 at 06:00:06PM -0500, Bill Sommerfeld wrote: > One of the main points of unpalatability for me is the trust many > labelling schemes place in the packet forwarding infrastructure. > > That rules out IPSO, CIPSO, etc., leaving some flavor of labelled IPsec. > > Conveniently, part of my day job involves work on Solaris's IPsec stack. > I've recently started investigating labelled IPsec -- so count me as > someone who has recently started to care about labelled networking. I think labelled IPsec is the way to go. Even better, the labelling should happen in the KE protocol, or even just in the PAD, so no IP, ESP or AH extensions should be needed. The only possible benefit of having labels below ESP/AH (i.e., in IP) is to prevent traffic analysis by eavesdroppers when you have trusted paths, but if you don't have trusted paths then labels below ESP/AH enhance traffice analysis, so visible packet labels seem like a double-edged sword to me. Nico -- From paul.moore@hp.com Fri Dec 1 18:37:45 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id kB1NbjNA022653 for ; Fri, 1 Dec 2006 18:37:45 -0500 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id kB1NbfdZ013240 for ; Fri, 1 Dec 2006 18:37:42 -0500 (EST) Received: from mailhub.hp.com (mailhub.hp.com [192.151.27.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 9962B113C4B for ; Fri, 1 Dec 2006 18:37:41 -0500 (EST) Received: from stuffed.lan (c-24-62-171-110.hsd1.nh.comcast.net [24.62.171.110]) by mailhub.hp.com (Postfix) with ESMTP id B49A02711C; Fri, 1 Dec 2006 18:37:33 -0500 (EST) From: Paul Moore Organization: Hewlett Packard To: Bill Sommerfeld Date: Fri, 1 Dec 2006 18:37:28 -0500 User-Agent: KMail/1.9.5 References: <200612011530.07987.paul.moore@hp.com> <1165014006.18458.85.camel@thunk> In-Reply-To: <1165014006.18458.85.camel@thunk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200612011837.29421.paul.moore@hp.com> X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Pekka Savola Subject: Re: [saag] =?iso-8859-6?q?Why_the_IETF_should_care_about_labeled_netw?= =?iso-8859-6?q?orking_=28_was=3A=09CIPSO_implementations=29?= X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2006 23:37:45 -0000 On Friday 01 December 2006 6:00 pm, Bill Sommerfeld wrote: > On Fri, 2006-12-01 at 15:30 -0500, Paul Moore wrote: > > ... the current state of labeled networking is far from ideal. A > > series of de-facto standards have evolved based around expired drafts > > (CIPSO) and lost standards from defunct SIGs (TSIG). As you can imagine > > this makes the barrier for entry very high and even then proving > > interoperability can be troublesome. I personally think this is a > > problem the IETF can help solve; while the number of players are small, > > having a forum where we can publish standards or even just informational > > specifications would go a long ways towards making labeled networking > > more palatable. > > One of the main points of unpalatability for me is the trust many > labelling schemes place in the packet forwarding infrastructure. > > That rules out IPSO, CIPSO, etc., leaving some flavor of labelled IPsec. The thing to remember is that some of the people/users who care about labeled networking have a high level of assurance in their physical network; not everyone needs or wants the packet level integrity and/or confidentiality that IPsec provides. The good news is that most of the labeled networking protocols work well with IPsec, i.e. immutable IP options. There are some other issues related to labeled IPsec but I suspect that discussion would be better left for another thread. > Conveniently, part of my day job involves work on Solaris's IPsec stack. > I've recently started investigating labelled IPsec -- so count me as > someone who has recently started to care about labelled networking. I'm trying to put a face to a name - would you happen to be the same fellow who had the unfortunate task of cleaning spilled Coke out of his laptop at a IPsec bakeoff in Finland a few years ago? -- paul moore linux security @ hp From paul.moore@hp.com Fri Dec 1 18:41:43 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id kB1NfhaG023549 for ; Fri, 1 Dec 2006 18:41:43 -0500 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id kB1Nfd4K018647 for ; Fri, 1 Dec 2006 18:41:40 -0500 (EST) Received: from mailhub.hp.com (mailhub.hp.com [192.151.27.10]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 56D7E33EA7E for ; Fri, 1 Dec 2006 18:41:39 -0500 (EST) Received: from stuffed.lan (c-24-62-171-110.hsd1.nh.comcast.net [24.62.171.110]) by mailhub.hp.com (Postfix) with ESMTP id 676C82710F; Fri, 1 Dec 2006 18:41:35 -0500 (EST) From: Paul Moore Organization: Hewlett Packard To: Nicolas Williams Date: Fri, 1 Dec 2006 18:41:31 -0500 User-Agent: KMail/1.9.5 References: <200612011530.07987.paul.moore@hp.com> <1165014006.18458.85.camel@thunk> <20061201233534.GE5938@binky.Central.Sun.COM> In-Reply-To: <20061201233534.GE5938@binky.Central.Sun.COM> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200612011841.31416.paul.moore@hp.com> X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Bill Sommerfeld , Pekka Savola Subject: Re: [saag] =?iso-8859-1?q?Why_the_IETF_should_care_about_labeled=09ne?= =?iso-8859-1?q?tworking_=28was=3A_CIPSO_implementations=29?= X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Dec 2006 23:41:43 -0000 On Friday 01 December 2006 6:35 pm, Nicolas Williams wrote: > The only possible benefit of having labels below ESP/AH (i.e., in IP) is > to prevent traffic analysis by eavesdroppers when you have trusted > paths, but if you don't have trusted paths then labels below ESP/AH > enhance traffice analysis, so visible packet labels seem like a > double-edged sword to me. Keep in mind that some users want/require visible packet labels so that intermediate hops can easily determine the security attributes of a packet. -- paul moore linux security @ hp From smb@cs.columbia.edu Fri Dec 1 19:02:33 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id kB202XRU028244 for ; Fri, 1 Dec 2006 19:02:33 -0500 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id kB202Uxb013840 for ; Fri, 1 Dec 2006 19:02:30 -0500 (EST) Received: from machshav.com (machshav.com [147.28.0.16]) by mit.edu (Spam Firewall) with ESMTP id 9B5EDDB6E9 for ; Fri, 1 Dec 2006 19:02:29 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id B93FCFB4CE; Sat, 2 Dec 2006 00:02:28 +0000 (UTC) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id DF2F9FB4C4; Sat, 2 Dec 2006 00:02:27 +0000 (UTC) Received: by berkshire.machshav.com (Postfix, from userid 54047) id 4F1BC3C0554; Fri, 1 Dec 2006 19:02:22 -0500 (EST) Date: Fri, 1 Dec 2006 19:02:22 -0500 From: "Steven M. Bellovin" To: Paul Moore In-Reply-To: <200612011530.07987.paul.moore@hp.com> References: <200612011530.07987.paul.moore@hp.com> Organization: Columbia University X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20061202000222.4F1BC3C0554@berkshire.machshav.com> X-Spam-Score: 0.01 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Pekka Savola Subject: Re: [saag] Why the IETF should care about labeled networking (was: CIPSO implementations) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Dec 2006 00:02:33 -0000 As I posted yesterday, the problem is with the hosts: hosts that reliably and securely do something with labels are not very common. As Steve Kent noted, the CMW project -- and the workstations aimed at it -- have also disappeared. What are the endpoints you propose to connect to your labeled network? From Black_David@emc.com Fri Dec 1 19:21:26 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id kB20LQ60032090 for ; Fri, 1 Dec 2006 19:21:26 -0500 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id kB20LFU3024852 for ; Fri, 1 Dec 2006 19:21:15 -0500 (EST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id F3E11142740 for ; Fri, 1 Dec 2006 19:21:14 -0500 (EST) Received: from mailhub.lss.emc.com (nirah.lss.emc.com [10.254.144.13]) by mexforward.lss.emc.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id kB20LDjd006991; Fri, 1 Dec 2006 19:21:13 -0500 (EST) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kB20LAHA029490; Fri, 1 Dec 2006 19:21:10 -0500 (EST) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.12]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Dec 2006 19:21:10 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 1 Dec 2006 19:21:09 -0500 Message-ID: In-Reply-To: <200612011837.29421.paul.moore@hp.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag]Why the IETF should care about labeled networking ( was: CIPSO implementations) Thread-Index: AccVognTL0vr1D6MTwWWlgnyEShRLQABPx5g To: X-OriginalArrivalTime: 02 Dec 2006 00:21:10.0088 (UTC) FILETIME=[C4538C80:01C715A7] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2006.12.1.155432 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTE 0, __CTYPE_CHARSET_QUOTED 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 1.15 X-Spam-Level: * (1.15) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id kB20LQ60032090 Cc: saag@mit.edu Subject: Re: [saag] Why the IETF should care about labeled networking ( was: CIPSO implementations) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Dec 2006 00:21:26 -0000 Paul, > > One of the main points of unpalatability for me is the trust many > > labelling schemes place in the packet forwarding infrastructure. > > > > That rules out IPSO, CIPSO, etc., leaving some flavor of labelled IPsec. > > The thing to remember is that some of the people/users who care about labeled > networking have a high level of assurance in their physical network; not > everyone needs or wants the packet level integrity and/or confidentiality > that IPsec provides. That's nice, but it's not true of the public (big-I) Internet that the IETF develops protocol standards for. IETF protocol standards are used in many non-public networks, but they are designed to be used on the public Internet ... because sooner or later, somebody will do that. The "people/users" who want standards that are only usable on tightly controlled private networks that have a "high level of assurance in the physical network" should look elsewhere, IMHO. FYI, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- From paul.moore@hp.com Fri Dec 1 19:24:51 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id kB20OpKV000535 for ; Fri, 1 Dec 2006 19:24:51 -0500 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id kB20Olg2029373 for ; Fri, 1 Dec 2006 19:24:47 -0500 (EST) Received: from ccerelrim01.cce.hp.com (ccerelrim01.cce.hp.com [161.114.21.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 1F203CE6A2 for ; Fri, 1 Dec 2006 19:24:46 -0500 (EST) Received: from ccerelrim01.cce.hp.com (localhost [127.0.0.1]) by receive-from-antispam-filter (Postfix) with SMTP id 35547223D19; Fri, 1 Dec 2006 18:33:28 -0600 (CST) Received: from mailstation.cce.hp.com (mailstation.cce.hp.com [161.114.20.124]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by ccerelrim01.cce.hp.com (Postfix) with ESMTP id B5B3E223BBB; Fri, 1 Dec 2006 18:33:25 -0600 (CST) Received: from stuffed.lan (c-24-62-171-110.hsd1.nh.comcast.net [24.62.171.110]) by mailstation.cce.hp.com (Postfix) with ESMTP id AE0AFC8F4; Fri, 1 Dec 2006 18:24:04 -0600 (CST) From: Paul Moore Organization: Hewlett Packard To: "Steven M. Bellovin" Date: Fri, 1 Dec 2006 19:24:01 -0500 User-Agent: KMail/1.9.5 References: <200612011530.07987.paul.moore@hp.com> <20061202000222.4F1BC3C0554@berkshire.machshav.com> In-Reply-To: <20061202000222.4F1BC3C0554@berkshire.machshav.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200612011924.01935.paul.moore@hp.com> X-PMX-Version: 5.2.1.279297, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.12.1.160933 X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Pekka Savola Subject: Re: [saag] Why the IETF should care about labeled networking (was: CIPSO implementations) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Dec 2006 00:24:51 -0000 On Friday 01 December 2006 7:02 pm, Steven M. Bellovin wrote: > As I posted yesterday, the problem is with the hosts: hosts that > reliably and securely do something with labels are not very common. As > Steve Kent noted, the CMW project -- and the workstations aimed at it > -- have also disappeared. What are the endpoints you propose to > connect to your labeled network? Shawn Campbell did a pretty good job in that thread describing what happened to all the CMW hosts and I would summarize it by saying that the CMW workstations have not disappeared they have simply "reorganized". I can think of three OSs of the top of my head which are either already validated against a Common Criteria PP which requires labeled import/export of data (networking included) or are under evaluation now: AIX, Trusted Solaris, and Linux (RedHat). -- paul moore linux security @ hp From paul.moore@hp.com Fri Dec 1 19:36:33 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id kB20aXFx002809 for ; Fri, 1 Dec 2006 19:36:33 -0500 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id kB20aPxe013978 for ; Fri, 1 Dec 2006 19:36:25 -0500 (EST) Received: from ccerelrim04.cce.hp.com (ccerelrim04.cce.hp.com [161.114.21.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 49221121303 for ; Fri, 1 Dec 2006 19:36:25 -0500 (EST) Received: from ccerelrim04.cce.hp.com (localhost.localdomain [127.0.0.1]) by receive-from-antispam-filter (Postfix) with SMTP id 4D5754013; Fri, 1 Dec 2006 18:36:24 -0600 (CST) Received: from mailstation.cce.hp.com (mailstation.cce.hp.com [161.114.20.124]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by ccerelrim04.cce.hp.com (Postfix) with ESMTP id 21FB14016; Fri, 1 Dec 2006 18:36:24 -0600 (CST) Received: from stuffed.lan (c-24-62-171-110.hsd1.nh.comcast.net [24.62.171.110]) by mailstation.cce.hp.com (Postfix) with ESMTP id C6273CDEB; Fri, 1 Dec 2006 18:36:20 -0600 (CST) From: Paul Moore Organization: Hewlett Packard To: Black_David@emc.com Date: Fri, 1 Dec 2006 19:36:11 -0500 User-Agent: KMail/1.9.5 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200612011936.11212.paul.moore@hp.com> X-PMX-Version: 5.2.1.279297, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.12.1.162433 X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] =?iso-8859-1?q?Why_the_IETF_should_care_about_labeled_netw?= =?iso-8859-1?q?orking_=28_was=3A=09CIPSO_implementations=29?= X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Dec 2006 00:36:33 -0000 On Friday 01 December 2006 7:21 pm, Black_David@emc.com wrote: > Paul, > > > > One of the main points of unpalatability for me is the trust many > > > labelling schemes place in the packet forwarding infrastructure. > > > > > > That rules out IPSO, CIPSO, etc., leaving some flavor of labelled > IPsec. > > > The thing to remember is that some of the people/users who care about > labeled > > networking have a high level of assurance in their physical network; > not > > > everyone needs or wants the packet level integrity and/or > confidentiality > > that IPsec provides. > > That's nice, but it's not true of the public (big-I) Internet that the > IETF develops protocol standards for. IETF protocol standards are > used in many non-public networks, but they are designed to be used on > the public Internet ... because sooner or later, somebody will do that. I think having a labeling protocol which works in conjunction with existing security protocols is far more flexible, and appealing, than a labeling protocol which requires a one size fits all approach to security. I don't mean to disparage IPsec, I think it is a very good thing; I just think it is not the best choice for the basis of a packet labeling protocol. -- paul moore linux security @ hp From Black_David@emc.com Fri Dec 1 20:27:06 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id kB21R6iZ012307 for ; Fri, 1 Dec 2006 20:27:06 -0500 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id kB21R3V9002356 for ; Fri, 1 Dec 2006 20:27:03 -0500 (EST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 5EF993094F9 for ; Fri, 1 Dec 2006 20:27:02 -0500 (EST) Received: from mailhub.lss.emc.com (sesha.lss.emc.com [10.254.144.12]) by mexforward.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kB21Qx0L024935; Fri, 1 Dec 2006 20:26:59 -0500 (EST) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kB21QvrV026787; Fri, 1 Dec 2006 20:26:58 -0500 (EST) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.12]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Dec 2006 20:26:57 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 1 Dec 2006 20:26:57 -0500 Message-ID: In-Reply-To: <200612011936.11212.paul.moore@hp.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag]Why the IETF should care about labeled networking ( was: CIPSO implementations) Thread-Index: AccVqegmEqaEPDfSSjyy8qXHQ2dnJwABlUOw To: X-OriginalArrivalTime: 02 Dec 2006 01:26:57.0754 (UTC) FILETIME=[F55193A0:01C715B0] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2006.12.1.171432 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTE 0, __CTYPE_CHARSET_QUOTED 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 1.15 X-Spam-Level: * (1.15) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id kB21R6iZ012307 Cc: saag@mit.edu Subject: Re: [saag] Why the IETF should care about labeled networking ( was: CIPSO implementations) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Dec 2006 01:27:06 -0000 > > > > One of the main points of unpalatability for me is the trust many > > > > labelling schemes place in the packet forwarding infrastructure. > > > > > > > > That rules out IPSO, CIPSO, etc., leaving some flavor of labelled IPsec. > > > > > The thing to remember is that some of the people/users who care about labeled > > > networking have a high level of assurance in their physical network; not > > > everyone needs or wants the packet level integrity and/or confidentiality > > > that IPsec provides. > > > > That's nice, but it's not true of the public (big-I) Internet that the > > IETF develops protocol standards for. IETF protocol standards are > > used in many non-public networks, but they are designed to be used on > > the public Internet ... because sooner or later, somebody will do that. > > I think having a labeling protocol which works in conjunction with existing > security protocols is far more flexible, and appealing, than a labeling > protocol which requires a one size fits all approach to security. > > I don't mean to disparage IPsec, I think it is a very good thing; I just think > it is not the best choice for the basis of a packet labeling protocol. I'm not sure IPsec is the only answer, but (IMHO) a design assumption of "a high level of assurance in [the] physical network" will likely produce a successor to RFC 3514 (an RFC about traffic labeling), and like RFC 3514, its successor will only be publishable on April 1st. My 0.02, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- From kent@bbn.com Sat Dec 2 08:13:52 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id kB2DDo7b023536 for ; Sat, 2 Dec 2006 08:13:50 -0500 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id kB2DDh0x015105 for ; Sat, 2 Dec 2006 08:13:43 -0500 (EST) Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by mit.edu (Spam Firewall) with ESMTP id 5E507107D50 for ; Sat, 2 Dec 2006 08:13:43 -0500 (EST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.182.149]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1GqUgX-0002QG-3v; Sat, 02 Dec 2006 08:13:42 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <200612011841.31416.paul.moore@hp.com> References: <200612011530.07987.paul.moore@hp.com> <1165014006.18458.85.camel@thunk> <20061201233534.GE5938@binky.Central.Sun.COM> <200612011841.31416.paul.moore@hp.com> Date: Sat, 2 Dec 2006 08:13:10 -0500 To: Paul Moore From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.65 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Bill Sommerfeld , Pekka Savola , Nicolas Williams Subject: Re: [saag] Why the IETF should care about labeled ne tworking (was: CIPSO implementations) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Dec 2006 13:13:53 -0000 At 6:41 PM -0500 12/1/06, Paul Moore wrote: >On Friday 01 December 2006 6:35 pm, Nicolas Williams wrote: >> The only possible benefit of having labels below ESP/AH (i.e., in IP) is >> to prevent traffic analysis by eavesdroppers when you have trusted >> paths, but if you don't have trusted paths then labels below ESP/AH >> enhance traffice analysis, so visible packet labels seem like a >> double-edged sword to me. > >Keep in mind that some users want/require visible packet labels so that >intermediate hops can easily determine the security attributes of a packet. > or, from another perspective, wiretappers can avoid wasting time on the dull stuff :-). While the folks who want to use IPSO/CIPSO labels do believe their network are secure, relying on them to do the right thing is a violation of the principle of least privilege, and thus not to be encouraged. Steve From paul.moore@hp.com Sat Dec 2 12:14:40 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id kB2HEbgd025746 for ; Sat, 2 Dec 2006 12:14:37 -0500 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id kB2HEVpb019797 for ; Sat, 2 Dec 2006 12:14:31 -0500 (EST) Received: from ccerelrim02.cce.hp.com (ccerelrim02.cce.hp.com [161.114.21.23]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id A9384E00A6 for ; Sat, 2 Dec 2006 12:14:30 -0500 (EST) Received: from ccerelrim02.cce.hp.com (localhost [127.0.0.1]) by receive-from-antispam-filter (Postfix) with SMTP id 52B26331A8; Sat, 2 Dec 2006 11:23:14 -0600 (CST) Received: from mailstation.cce.hp.com (mailstation.cce.hp.com [161.114.20.124]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by ccerelrim02.cce.hp.com (Postfix) with ESMTP id 15021331DC; Sat, 2 Dec 2006 11:23:13 -0600 (CST) Received: from stuffed.lan (c-24-62-171-110.hsd1.nh.comcast.net [24.62.171.110]) by mailstation.cce.hp.com (Postfix) with ESMTP id 2F596C574; Sat, 2 Dec 2006 11:14:26 -0600 (CST) From: Paul Moore Organization: Hewlett Packard To: Stephen Kent Date: Sat, 2 Dec 2006 12:14:22 -0500 User-Agent: KMail/1.9.5 References: <200612011530.07987.paul.moore@hp.com> <200612011841.31416.paul.moore@hp.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200612021214.22657.paul.moore@hp.com> X-PMX-Version: 5.2.1.279297, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.12.2.85933 X-Spam-Score: 0.65 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Bill Sommerfeld , Pekka Savola , Nicolas Williams Subject: Re: [saag] =?iso-8859-1?q?Why_the_IETF_should_care_about_labeled=09ne?= =?iso-8859-1?q?_=09tworking_=28was=3A_CIPSO_implementations=29?= X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Dec 2006 17:14:40 -0000 On Saturday 02 December 2006 8:13 am, Stephen Kent wrote: > At 6:41 PM -0500 12/1/06, Paul Moore wrote: > >On Friday 01 December 2006 6:35 pm, Nicolas Williams wrote: > >> The only possible benefit of having labels below ESP/AH (i.e., in IP) > >> is to prevent traffic analysis by eavesdroppers when you have trusted > >> paths, but if you don't have trusted paths then labels below ESP/AH > >> enhance traffice analysis, so visible packet labels seem like a > >> double-edged sword to me. > > > >Keep in mind that some users want/require visible packet labels so that > >intermediate hops can easily determine the security attributes of a > > packet. > > or, from another perspective, wiretappers can avoid wasting time on > the dull stuff :-). ;) > While the folks who want to use IPSO/CIPSO labels do believe their > network are secure, relying on them to do the right thing is a > violation of the principle of least privilege, and thus not to be > encouraged. I think no matter what we do, the industry is always going to have a problem in that we rely on administrators to "do the right thing" in terms of building and configuring systems. Unfortunately, the "right thing" often varies from organization to organization, and as a result a violation of one organization's security policy may not be an violation in another. IPSO, CIPSO, and other labeling protocols work well IPsec for users who don't trust the network and the work well without IPsec when users feel they can trust the network. Flexibility is typically hard to come by when you start dealing with security issues; I'd hate to see this flexibility lost. -- paul moore linux security @ hp From nw141292@binky.Central.Sun.COM Sun Dec 3 23:03:04 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id kB4432ef015981 for ; Sun, 3 Dec 2006 23:03:02 -0500 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id kB442tWt027764 for ; Sun, 3 Dec 2006 23:02:56 -0500 (EST) Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by mit.edu (Spam Firewall) with ESMTP id EBCA631A5CC for ; Sun, 3 Dec 2006 23:02:53 -0500 (EST) Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by nwkea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kB43xKmj006605 for ; Sun, 3 Dec 2006 19:59:20 -0800 (PST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id kB43xJtb006080 for ; Sun, 3 Dec 2006 20:59:20 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id kB43xGJ9029015; Sun, 3 Dec 2006 21:59:16 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id kB43xEkA029014; Sun, 3 Dec 2006 21:59:14 -0600 (CST) Date: Sun, 3 Dec 2006 21:59:14 -0600 From: Nicolas Williams To: Stephen Kent Message-ID: <20061204035914.GG5938@binky.Central.Sun.COM> References: <200612011530.07987.paul.moore@hp.com> <1165014006.18458.85.camel@thunk> <20061201233534.GE5938@binky.Central.Sun.COM> <200612011841.31416.paul.moore@hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.651 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Bill Sommerfeld , Paul Moore , Pekka Savola Subject: Re: [saag] Why the IETF should care about labeled ne tworking (was: CIPSO implementations) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Dec 2006 04:03:04 -0000 On Sat, Dec 02, 2006 at 08:13:10AM -0500, Stephen Kent wrote: > At 6:41 PM -0500 12/1/06, Paul Moore wrote: > >On Friday 01 December 2006 6:35 pm, Nicolas Williams wrote: > >> The only possible benefit of having labels below ESP/AH (i.e., in IP) is > >> to prevent traffic analysis by eavesdroppers when you have trusted > >> paths, but if you don't have trusted paths then labels below ESP/AH > >> enhance traffice analysis, so visible packet labels seem like a > >> double-edged sword to me. > > > >Keep in mind that some users want/require visible packet labels so that > >intermediate hops can easily determine the security attributes of a packet. > > > > or, from another perspective, wiretappers can avoid wasting time on > the dull stuff :-). > > While the folks who want to use IPSO/CIPSO labels do believe their > network are secure, relying on them to do the right thing is a > violation of the principle of least privilege, and thus not to be > encouraged. For me the issue is this idea that middleboxes should make routing decisions based on packet labels. If my network is trusted then what's the point? And if portions of it aren't trusted, then one should use IPsec as necessary (either for VPNs or end-to-end) and the addresses of the various end-points should suffice for making safe routing decisions. And if the whole network is untrusted, then one should be using end-to-end IPsec and to hell with the middleboxes. IOW, packet labelling might be useful to end nodes in a trusted network situation, but that's it. We can and should simplify packet labelling by not giving middleboxes any role in the matter. Nico -- From kent@bbn.com Mon Dec 4 21:26:34 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id kB52QWSD001932 for ; Mon, 4 Dec 2006 21:26:32 -0500 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id kB52QQOS018467 for ; Mon, 4 Dec 2006 21:26:26 -0500 (EST) Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by mit.edu (Spam Firewall) with ESMTP id 903C4340756 for ; Mon, 4 Dec 2006 21:26:25 -0500 (EST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.77.15.173]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1GrQ0k-000707-4C; Mon, 04 Dec 2006 21:26:22 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <200612021214.22657.paul.moore@hp.com> References: <200612011530.07987.paul.moore@hp.com> <200612011841.31416.paul.moore@hp.com> <200612021214.22657.paul.moore@hp.com> Date: Mon, 4 Dec 2006 13:45:48 -0500 To: Paul Moore From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 1.40 X-Spam-Level: * (1.40) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Bill Sommerfeld , Pekka Savola , Nicolas Williams Subject: Re: [saag] Why the IETF should care about labeled ne tworking (was: CIPSO implementations) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Dec 2006 02:26:34 -0000 At 12:14 PM -0500 12/2/06, Paul Moore wrote: >... > >I think no matter what we do, the industry is always going to have a problem >in that we rely on administrators to "do the right thing" in terms of >building and configuring systems. yes, and use of labels to ensure secure routing of traffic increases the number of admins who have to "do the right thing" to ensure secure communication. That's the primary reason for not encouraging such use, in lieu of solutions like IPsec. >Unfortunately, the "right thing" often >varies from organization to organization, and as a result a violation of one >organization's security policy may not be an violation in another. Or a violation of one organization's policy may trigger a violation of that of another organization due to an incorrect configuration of label checking or label translation (a likely next step if one relies on labels to control packet flows and connects labeled nets to one another) along the path. Steve From Jarrett.Lu@sun.com Tue Dec 5 20:16:21 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id kB61GLvl029764 for ; Tue, 5 Dec 2006 20:16:21 -0500 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id kB61GCZx013025 for ; Tue, 5 Dec 2006 20:16:12 -0500 (EST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by mit.edu (Spam Firewall) with ESMTP id EDD2C100088 for ; Tue, 5 Dec 2006 20:16:11 -0500 (EST) Received: from jurassic.eng.sun.com ([129.146.224.31]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kB61GAkd020081 for ; Tue, 5 Dec 2006 18:16:11 -0700 (MST) Received: from [129.150.24.127] (vpn-129-150-24-127.SFBay.Sun.COM [129.150.24.127]) by jurassic.eng.sun.com (8.13.8+Sun/8.13.8) with ESMTP id kB61GAcu203842; Tue, 5 Dec 2006 17:16:10 -0800 (PST) Message-ID: <457619D3.80500@sun.com> Date: Tue, 05 Dec 2006 17:16:03 -0800 From: Jarrett Lu User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: saag@mit.edu Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] Why the IETF should care about labeled ne tworking (was: CIPSO implementations) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2006 01:16:21 -0000 On /Sun Dec 3 22:59:14 EST 2006, /*Nicolas Williams Wrote:* > > For me the issue is this idea that middleboxes should make routing > decisions based on packet labels. If my network is trusted then what's > the point? And if portions of it aren't trusted, then one should use > IPsec as necessary (either for VPNs or end-to-end) and the addresses of > the various end-points should suffice for making safe routing decisions. > And if the whole network is untrusted, then one should be using > end-to-end IPsec and to hell with the middleboxes. > > IOW, packet labelling might be useful to end nodes in a trusted network > situation, but that's it. We can and should simplify packet labelling > by not giving middleboxes any role in the matter. In a trusted environment, administrators can assign different level of trust to the middle boxes so that certain traffic can take the path of a higher level of trust. Not letting middle box make labeled routing decisions takes this feature away. Despite its narrow scope, I believe it's still good to have a labeled networking standard so that products from different vendors in this space can interoperate. I think it's important for the documents to be *very clear* about the "trusted network" assumptions and elaborate on the limitations of this technology. Labeled networking standards work can definitely benefit from help from IETF. There is tremendous expertise in security area in this body, and labeled networking can work with other IETF produced protocols (e.g. IPsec). It doesn't appear there is wide interests within IETF at the moment. But getting expert review on individual submissions would go a long way in. getting the language right and help mitigating the risk of misusing this technology in environments it is ill-suited. I apologize for I lumping comments to other posting of this thread in this reply. Jarrett From pbaker@verisign.com Fri Dec 8 15:25:46 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id kB8KPiMa028591 for ; Fri, 8 Dec 2006 15:25:44 -0500 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id kB8KPbnR011579 for ; Fri, 8 Dec 2006 15:25:37 -0500 (EST) Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 70DAB31972A for ; Fri, 8 Dec 2006 15:25:36 -0500 (EST) Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by robin.verisign.com (8.13.6/8.13.4) with ESMTP id kB8KPK6T002109; Fri, 8 Dec 2006 12:25:20 -0800 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Dec 2006 12:25:19 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 8 Dec 2006 12:24:04 -0800 Message-ID: <198A730C2044DE4A96749D13E167AD3701059571@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Why the IETF should care about labeled ne tworking (was:CIPSO implementations) Thread-Index: AccXWqsHLC4xBQr3QhCN0QPYWCvTnwDqh2fQ From: "Hallam-Baker, Phillip" To: "Nicolas Williams" , "Stephen Kent" X-OriginalArrivalTime: 08 Dec 2006 20:25:19.0546 (UTC) FILETIME=[FAD671A0:01C71B06] X-Spam-Score: 0.72 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id kB8KPiMa028591 Cc: saag@mit.edu, Bill Sommerfeld , Paul Moore , Pekka Savola Subject: Re: [saag] Why the IETF should care about labeled ne tworking (was:CIPSO implementations) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2006 20:25:47 -0000 I would suggest that the place to look at this would be in an IRTF group rather than as a protocol feature at this particular point. > Behalf Of Nicolas Williams > For me the issue is this idea that middleboxes should make > routing decisions based on packet labels. If my network is > trusted then what's the point? There are many people in Europe talking about Deperimeterization. The problem is that even trusted networks can have compromised machines inside them. Deployment of granular security in depth today is very expensive, administration is much more costly than in a network with a conventional Firewall-DMZ configuration. It can be done bit it is expensive. There are two issues here. One is should the IETF be looking at this problem? The answer is certainly. And no these problems are not all solved in IPSEC, IPv6 or anything else. People are using those products but they are achieving the effect through custom architectures built on top. Each enterprise has to discover this themselves. The result is large deployment and administration costs. The second question is should the IETF simply adopt an existing label based solution? Perhaps but probably not. I think we need to admit the fact that the problems with IPSEC are rather more substantial than the complexity of a few particular pieces. The fact is that there are many security problems where the answer is not end-to-end security and in most cases the answer is probably not even more cryptography. I think this needs some thought and I think that that thought needs to be unconstrained by preconceived notions that this problem has come along to deploy something we made earlier (UK readers: sticky backed plastic reference intentional). I think that there is actually an opportunity to drive IPv6, IPSEC, DNSSEC deployment here but it requires rather more subtlety and finesse. And if portions of it aren't > trusted, then one should use IPsec as necessary (either for > VPNs or end-to-end) and the addresses of the various > end-points should suffice for making safe routing decisions. > And if the whole network is untrusted, then one should be > using end-to-end IPsec and to hell with the middleboxes. > > IOW, packet labelling might be useful to end nodes in a > trusted network situation, but that's it. We can and should > simplify packet labelling by not giving middleboxes any role > in the matter. > > Nico > -- > _______________________________________________ > saag mailing list > saag@mit.edu > http://mailman.mit.edu/mailman/listinfo/saag > > From paul.hoffman@vpnc.org Fri Dec 8 17:01:16 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id kB8M1GcJ013101 for ; Fri, 8 Dec 2006 17:01:16 -0500 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id kB8M196G014545 for ; Fri, 8 Dec 2006 17:01:10 -0500 (EST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 619B015AD0E for ; Fri, 8 Dec 2006 17:01:08 -0500 (EST) Received: from [10.20.30.100] (ool-4350bad7.dyn.optonline.net [67.80.186.215]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id kB8M16om035772 for ; Fri, 8 Dec 2006 15:01:07 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <200612021214.22657.paul.moore@hp.com> References: <200612011530.07987.paul.moore@hp.com> <200612011841.31416.paul.moore@hp.com> <200612021214.22657.paul.moore@hp.com> Date: Fri, 8 Dec 2006 17:00:58 -0500 To: saag@mit.edu From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: Re: [saag] Why the IETF should care about labeled networking (was: CIPSO implementations) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2006 22:01:16 -0000 At 12:14 PM -0500 12/2/06, Paul Moore wrote: >I think no matter what we do, the industry is always going to have a problem >in that we rely on administrators to "do the right thing" in terms of >building and configuring systems. Yes, but we can give them tools that make doing the wrong thing more difficult. For example, if the two endpoints of an IPsec VPN have configured things differently, there is a reasonable chance that no traffic will flow until the two policies match. The IETF traditionally doesn't create protocols that are meant to work only on a fully-trusted network; in fact, we often make snide remarks such protocols as we turn down the work. The big-picture problem can be worked on in the IETF, but not with any expectation that this should work on a fully-trusted network. There will be enough rat-holes in the discussion without that assumption. --Paul Hoffman, Director --VPN Consortium From paul.moore@hp.com Fri Dec 8 17:35:43 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id kB8MZhHe018481 for ; Fri, 8 Dec 2006 17:35:43 -0500 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id kB8MZaXk001783 for ; Fri, 8 Dec 2006 17:35:36 -0500 (EST) Received: from atlrel8.hp.com (atlrel8.hp.com [156.153.255.206]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 4DF15315B89 for ; Fri, 8 Dec 2006 17:35:36 -0500 (EST) Received: from smtp2.fc.hp.com (smtp2.fc.hp.com [15.11.136.114]) by atlrel8.hp.com (Postfix) with ESMTP id 352BD35345 for ; Fri, 8 Dec 2006 17:35:43 -0500 (EST) Received: from [16.116.113.207] (flek.zko.hp.com [16.116.113.207]) by smtp2.fc.hp.com (Postfix) with ESMTP id 909281570D4 for ; Fri, 8 Dec 2006 22:35:34 +0000 (UTC) Message-ID: <4579E8B5.3080606@hp.com> Date: Fri, 08 Dec 2006 17:35:33 -0500 From: Paul Moore Organization: Hewlett Packard User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: saag@mit.edu References: <200612011530.07987.paul.moore@hp.com> <200612011841.31416.paul.moore@hp.com> <200612021214.22657.paul.moore@hp.com> In-Reply-To: X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: Re: [saag] Why the IETF should care about labeled networking (was: CIPSO implementations) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2006 22:35:43 -0000 Paul Hoffman wrote: > The IETF traditionally doesn't create protocols that are meant to > work only on a fully-trusted network; in fact, we often make snide > remarks such protocols as we turn down the work. > > The big-picture problem can be worked on in the IETF, but not with > any expectation that this should work on a fully-trusted network. > There will be enough rat-holes in the discussion without that > assumption. I originally got involved in this discussion because I thought there was a definite need for standardization in regards to labeled networking. In the course of the discussion it has become clear (to me anyway) that the labeled networking goals of the IETF are somewhat different from the goals of the majority of the people who use labeled networking today. That said, I think there is still some value in developing a labeled networking standard that the IETF could agree upon. Perhaps once a RFC standard is in place it might be possible to find a way to make it useful for those who use labeled networking today. However, to continue to do nothing will leave people with no other option than expired drafts and impossible to find standards from long dead SIGs; I don't think anybody wants that. I don't know the best way forward from here, someone mentioned the IRTF, but I'm happy to work within whatever process people feel is best. -- paul moore linux security @ hp From sommerfeld@sun.com Fri Dec 8 18:09:27 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id kB8N9RkH024288 for ; Fri, 8 Dec 2006 18:09:27 -0500 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id kB8N9MS5017242 for ; Fri, 8 Dec 2006 18:09:22 -0500 (EST) Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by mit.edu (Spam Firewall) with ESMTP id DB127C6C2B for ; Fri, 8 Dec 2006 18:09:21 -0500 (EST) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kB8N9Jhj022593; Fri, 8 Dec 2006 15:09:19 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id kB8N9JB2021350; Fri, 8 Dec 2006 18:09:19 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id kB8N9HfX002623; Fri, 8 Dec 2006 18:09:18 -0500 (EST) From: Bill Sommerfeld To: Paul Moore In-Reply-To: <4579E8B5.3080606@hp.com> References: <200612011530.07987.paul.moore@hp.com> <200612011841.31416.paul.moore@hp.com> <200612021214.22657.paul.moore@hp.com> <4579E8B5.3080606@hp.com> Content-Type: text/plain Date: Fri, 08 Dec 2006 18:09:16 -0500 Message-Id: <1165619356.28763.54.camel@thunk> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.01 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] Why the IETF should care about labeled networking (was: CIPSO implementations) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2006 23:09:27 -0000 On Fri, 2006-12-08 at 17:35 -0500, Paul Moore wrote: > > The big-picture problem can be worked on in the IETF, but not with > > any expectation that this should work on a fully-trusted network. > > There will be enough rat-holes in the discussion without that > > assumption. > > I originally got involved in this discussion because I thought there was a > definite need for standardization in regards to labeled networking. In the > course of the discussion it has become clear (to me anyway) that the labeled > networking goals of the IETF are somewhat different from the goals of the > majority of the people who use labeled networking today. on the other hand, it's clear to me that labelled systems are of minimal value without a form of labelled networking which works on real-world networks, which are, for the most part, not trusted. So I'm reluctant to spend any energy on labelled networking which benefits only the deployments with trusted wires. > That said, I think there is still some value in developing a labeled networking > standard that the IETF could agree upon. Perhaps once a RFC standard is in > place it might be possible to find a way to make it useful for those who use > labeled networking today. However, to continue to do nothing will leave people > with no other option than expired drafts and impossible to find standards from > long dead SIGs; I don't think anybody wants that. It appears to me that a significant amount of the work involved in getting labelled networking going has nothing to do with the bits-on-the-wire used to transport labelled data between systems, but rather comes in representing and distributing policy around the network as systems are deployed and administered. - Bill From kent@bbn.com Fri Dec 8 18:14:13 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id kB8NEDZV024893 for ; Fri, 8 Dec 2006 18:14:13 -0500 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id kB8NEAW2022689 for ; Fri, 8 Dec 2006 18:14:10 -0500 (EST) Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by mit.edu (Spam Firewall) with ESMTP id 2DB95E63BF for ; Fri, 8 Dec 2006 18:14:10 -0500 (EST) Received: from dhcp89-089-106.bbn.com ([128.89.89.106]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Gsouv-0001zV-5C; Fri, 08 Dec 2006 18:14:09 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <4579E8B5.3080606@hp.com> References: <200612011530.07987.paul.moore@hp.com> <200612011841.31416.paul.moore@hp.com> <200612021214.22657.paul.moore@hp.com> <4579E8B5.3080606@hp.com> Date: Fri, 8 Dec 2006 18:02:28 -0500 To: Paul Moore From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] Why the IETF should care about labeled networking (was: CIPSO implementations) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2006 23:14:13 -0000 Paul, The IRTF does not create docs that become standards tracks RFCs. Steve From nw141292@binky.Central.Sun.COM Sat Dec 9 00:00:15 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id kB950CEP009816 for ; Sat, 9 Dec 2006 00:00:12 -0500 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id kB9507Q5016557 for ; Sat, 9 Dec 2006 00:00:07 -0500 (EST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by mit.edu (Spam Firewall) with ESMTP id 64AAB34D8B9 for ; Sat, 9 Dec 2006 00:00:06 -0500 (EST) Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kB9505nK004942 for ; Fri, 8 Dec 2006 22:00:05 -0700 (MST) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id kB95044Q012811 for ; Fri, 8 Dec 2006 22:00:05 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id kB9501ms029825; Fri, 8 Dec 2006 23:00:01 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id kB94xxCV029824; Fri, 8 Dec 2006 22:59:59 -0600 (CST) Date: Fri, 8 Dec 2006 22:59:59 -0600 From: Nicolas Williams To: "Hallam-Baker, Phillip" Message-ID: <20061209045959.GY26175@binky.Central.Sun.COM> References: <198A730C2044DE4A96749D13E167AD3701059571@MOU1WNEXMB04.vcorp.ad.vrsn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <198A730C2044DE4A96749D13E167AD3701059571@MOU1WNEXMB04.vcorp.ad.vrsn.com> User-Agent: Mutt/1.5.7i X-Spam-Score: 0 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Bill Sommerfeld , Paul Moore , Pekka Savola Subject: Re: [saag] Why the IETF should care about labeled ne tworking (was:CIPSO implementations) X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Dec 2006 05:00:15 -0000 On Fri, Dec 08, 2006 at 12:24:04PM -0800, Hallam-Baker, Phillip wrote: > I would suggest that the place to look at this would be in an IRTF > group rather than as a protocol feature at this particular point. Why? I don't think SA labelling should require an IRTF group, and I believe packet labelling to be useful only when you believe that the network is trustworthy and you don't want to spend cycles on IPsec crypto (e.g., HPC), and we don't need an IRTF group for that either. As to what the IETF should work on: I believe there is room for an individual submission I-D targetting the Standards Track and for specifying IKEv1/2 extensions for SA labelling. If such a work could get bogged on on labelling rather than protocol issues, then perhaps a WG could be formed, but I think it wouldn't come to that. I can't judge the level of interest on _packet_ labelling, but I know I'm not very interested in it. HPC sites tend not to mind authentication as much as they mind bulk crypto, so IPsec w/ SA labelling + ESP w/ null ciphers/MACs may do just fine as a replacement for packet labelling). > > Behalf Of Nicolas Williams > > > For me the issue is this idea that middleboxes should make > > routing decisions based on packet labels. If my network is > > trusted then what's the point? > > There are many people in Europe talking about Deperimeterization. The > problem is that even trusted networks can have compromised machines > inside them. If you don't trust the middleboxes then use IPsec. > Deployment of granular security in depth today is very expensive, > administration is much more costly than in a network with a > conventional Firewall-DMZ configuration. It can be done bit it is > expensive. I think this is as true once you bring labelling into the picture, so this isn't about IPsec being difficult. > There are two issues here. One is should the IETF be looking at this > problem? The answer is certainly. And no these problems are not all > solved in IPSEC, IPv6 or anything else. People are using those > products but they are achieving the effect through custom > architectures built on top. Each enterprise has to discover this > themselves. The result is large deployment and administration costs. > > The second question is should the IETF simply adopt an existing label > based solution? Perhaps but probably not. I think we need to admit the > fact that the problems with IPSEC are rather more substantial than the > complexity of a few particular pieces. The fact is that there are many > security problems where the answer is not end-to-end security and in > most cases the answer is probably not even more cryptography. There already are efforts underway at the IETF to make IPsec easier to use. And yes, there are applications where end-to-end security isn't the answer, but end-to-end security may still play a role, and anyways, I'm not sure that I see the connection to packet labelling, unless you mean to push labelling up the protocol stack (which is needed, but some amount of labelling in the protocol stack below the application would be needed too [again, SA labelling should do]). > I think this needs some thought and I think that that thought needs to > be unconstrained by preconceived notions that this problem has come > along to deploy something we made earlier (UK readers: sticky backed > plastic reference intentional). Oh, there is room for an IRTF RG, but I think it's clear that for something like SA labelling there is plenty of past research and deployment experience to proceed without one. Nico -- From housley@vigilsec.com Mon Dec 18 09:24:55 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id kBIEOrPj031576 for ; Mon, 18 Dec 2006 09:24:53 -0500 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id kBIEOlbr018842 for ; Mon, 18 Dec 2006 09:24:47 -0500 (EST) Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by mit.edu (Spam Firewall) with SMTP id E7C2C16EFB8 for ; Mon, 18 Dec 2006 09:24:46 -0500 (EST) Received: (qmail 2155 invoked by uid 0); 18 Dec 2006 14:24:43 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.246.224.157) by woodstock.binhost.com with SMTP; 18 Dec 2006 14:24:43 -0000 Message-Id: <7.0.0.16.2.20061218092112.07e11cf0@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Mon, 18 Dec 2006 09:24:42 -0500 To: ietf@ietf.org, saag@mit.edu From: Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 3.635 X-Spam-Level: *** (3.635) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: gwz@cisco.com, clancy@ltsnet.net Subject: [saag] HOKEY interim meeting on January 23rd X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2006 14:24:57 -0000 The HOKEY WG will hold a one-day interim meeting. The CAPWAP WG will hold an interim meeting at the same location on the two days following the HOKEY WG interim meeting. Here are the details: HOKEY WG Interim Meeting Tuesday, January 23, 2007 9:00 AM - 5:00 PM (PDT) 3750 Cisco Way (Building 15) San Jose, CA Thanks, Russ From housley@vigilsec.com Fri Dec 22 14:38:46 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id kBMJckFa000422 for ; Fri, 22 Dec 2006 14:38:46 -0500 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id kBMJcdvq013593 for ; Fri, 22 Dec 2006 14:38:39 -0500 (EST) Received: from woodstock.binhost.com (woodstock.binhost.com [66.150.120.2]) by mit.edu (Spam Firewall) with SMTP id EA55F177FAB for ; Fri, 22 Dec 2006 14:38:38 -0500 (EST) Received: (qmail 1964 invoked by uid 0); 22 Dec 2006 19:38:32 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.246.224.157) by woodstock.binhost.com with SMTP; 22 Dec 2006 19:38:32 -0000 Message-Id: <7.0.0.16.2.20061222143539.077ab998@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Fri, 22 Dec 2006 14:38:36 -0500 To: saag@mit.edu From: Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.13 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] KeyProv WG Chair Nominations X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Dec 2006 19:38:46 -0000 I am sending this to SAAG to make sure that all potential candidates for KeyProv WG are aware of the call for nominations. Russ >Date: Fri, 22 Dec 2006 13:40:36 -0500 >To: ietf-keyprov@safehaus.org >From: Russ Housley >Subject: [Ietf-keyprov] KeyProv WG Chair Nominations > >The charter text that was developed on this list is on the agenda >for discussion at the next IESG Telechat, which will take place on >January 11th. Based on the overwhelming consensus to do this work >that was demonstrated at the BOF, I do not expect lengthy discussion. > >The next step will be IETF-wide discussion of the proposed charter >text. That discussion will last two weeks. At the end of the >discussion period, the charter will again appear on the IESG >Telechat agenda, this time for WG Creation approval. We need to >have candidates for the WG Chair positions before we reach this point. > >The O&M Area has been very successful in selecting WG Chairs through >a nominations process. We are trying in this yet-to-be-formed >WG. I hope we are as successful as the O&M Area. > >The qualifications for chair of the KeyProv WG are: >* Familiarity with IETF process >* Solid understanding of key management >* Experience building consensus >* Good at finding common ground in the face of disagreement >* Demonstrated ability to manage technical contributors > >Please send nominations for KeyProv WG Chair to me by January >8th. I plan to select two co-chairs. > >Thanks, > Russ > >_______________________________________________ >Ietf-keyprov mailing list >Ietf-keyprov@safehaus.org >http://www.safehaus.org/mailman/listinfo/ietf-keyprov From flefauch@cisco.com Tue Dec 26 06:05:39 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id kBQB5dOY027565 for ; Tue, 26 Dec 2006 06:05:39 -0500 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id kBQB5VHV018848 for ; Tue, 26 Dec 2006 06:05:31 -0500 (EST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by mit.edu (Spam Firewall) with ESMTP id 06B261903AD; Tue, 26 Dec 2006 06:05:30 -0500 (EST) Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 26 Dec 2006 12:05:31 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kBQB5T50017842; Tue, 26 Dec 2006 12:05:29 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kBQB5CA4027228; Tue, 26 Dec 2006 12:05:24 +0100 (MET) Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Dec 2006 12:05:22 +0100 Received: from [144.254.53.108] ([144.254.53.108]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Dec 2006 12:05:21 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Francois Le Faucheur IMAP Date: Tue, 26 Dec 2006 12:03:41 +0100 To: Black_David@emc.com X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 26 Dec 2006 11:05:21.0762 (UTC) FILETIME=[BC6EF420:01C728DD] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3170; t=1167131129; x=1167995129; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20Re=3A=20[saag]=20tsvwg, preemption=20and=20rsvp=3A=20exposing= 20characteristics=20of=20confidentialtraffic |Sender:=20; bh=rC0F/wjWccnFMbm5XIzULUoTml/K5A8Gc/B77QKkvS0=; b=tGDRqG4x0FsmazHFWllWwCkh/fRqHFH9F8QB7bXW0W5ye4WFCiSSGrH09NnLuVzMrgbydtw+ uxoVNeeye6n4wGsnbWKjcsaUEvhz9iwJL29BfKSiF42+p5GXdQTt4JUl; Authentication-Results: ams-dkim-1; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.01 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: ipsec@ietf.org, Francois Le Faucheur IMAP , Bose Pratik , Fred Baker , saag@mit.edu, Sam Hartman , tsvwg-chairs@tools.ietf.org Subject: Re: [saag] tsvwg, preemption and rsvp: exposing characteristics of confidentialtraffic X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Dec 2006 11:05:39 -0000 Hello David, Now that we've converged on the list on the text for the Security Considerations section, I'd like to issue the updated version of the Generic Aggregate RSVP Reservation I-D (i.e. the confusingly named rsvp-ipsec draft). My understanding is that Fred/Pratik will do some edits in vpn- signaled-preemption as discussed by email to address your initial concern. Is there anything remaining from your concern below that you feel still needs resolution in rsvp-ipsec? If yes, any specific suggestions? Thank you and happy holiday season. Francois On 2 Oct 2006, at 15:41, Black_David@emc.com wrote: > Francois, > > The concern about how to use a PHB consisting of multiple DSCPs (e.g., > AF) > also applies to the rsvp-ipsec draft. Using PHBIDs (cf. RFC 3140) may > help address this, and this concern may also affect RFC 3175. > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > black_david@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > >> -----Original Message----- >> From: Francois Le Faucheur [mailto:flefauch@cisco.com] >> Sent: Monday, October 02, 2006 6:03 AM >> To: Black, David >> Cc: Francois Le Faucheur; hartmans-ietf@MIT.EDU; >> saag@MIT.EDU; ipsec@ietf.org; tsvwg-chairs@tools.ietf.org; >> fred@cisco.com >> Subject: Re: [saag] tsvwg,preemption and rsvp: exposing >> characteristics of confidentialtraffic >> >> Hello, >> >> Just expanding on Dave's observation: >> >>>> These drafts set up a model under which each precedence class of > data >>>> from a preemption standpoint goes over its own SA and uses its own >>>> aggregate RSVP reservation. What that means is you expose on the >>>> unprotected side of the interface what fraction of your traffic is > at >>>> each precedence level. >>> >>> Actually, only the vpn-signaled-preemption draft appears to do this. >>> >>> The rsvp-ipsec draft allows multiple reservations between the same >>> endpoints for the same DSCP, which would allow such traffic to use >>> different tunnels but if it requires traffic for different >>> reservations to use different tunnels, I was not able to find >>> a statement of that requirement. >>> >> >> Right. >> The rsvp-ipsec draft effectively decorelates the aggregate >> reservations from the security associations (this was done as a >> result of the first round of Security Experts review we got). So, for > >> example,: >> * it allows to set up multiple aggregate reservations using a > single SA >> * it allows to setup one aggregate reservation per SA >> * it does not force/mandate either of these modes. >> >> The logic is to provide a generic mechanism which may be used in >> different ways, in particular in the way(s) discussed in > vpn-signaled-preemption. >> rsvp-ipsec refers to vpn-signaled-preemption's Security >> Considerations for when used as per vpn-signaled-preemption. >> >> Cheers >> >> Francois From Black_David@emc.com Thu Dec 28 16:45:50 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id kBSLjoIp008159 for ; Thu, 28 Dec 2006 16:45:50 -0500 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id kBSLjg7d027990 for ; Thu, 28 Dec 2006 16:45:43 -0500 (EST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 98B0918B2FE; Thu, 28 Dec 2006 16:45:41 -0500 (EST) Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.11]) by mexforward.lss.emc.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id kBSLjTfM028539; Thu, 28 Dec 2006 16:45:29 -0500 (EST) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kBSLixtb014842; Thu, 28 Dec 2006 16:45:23 -0500 (EST) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.13]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Dec 2006 16:44:41 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Thu, 28 Dec 2006 16:44:41 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] tsvwg, preemption and rsvp: exposing characteristics of confidentialtraffic Thread-Index: Acco3chiYIfLD4mhSsarJQEXegRAuwB6XpNw To: X-OriginalArrivalTime: 28 Dec 2006 21:44:41.0816 (UTC) FILETIME=[61A22D80:01C72AC9] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2006.12.28.132433 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, NO_REAL_NAME 0, __C230066_P5 0, __CP_NOT_1 0, __CT 0, __CTE 0, __CTYPE_CHARSET_QUOTED 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 1.15 X-Spam-Level: * (1.15) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id kBSLjoIp008159 Cc: ipsec@ietf.org, tsvwg-chairs@tools.ietf.org, fred@cisco.com, saag@mit.edu, hartmans-ietf@mit.edu, pratik.bose@lmco.com, black_david@emc.com Subject: Re: [saag] tsvwg, preemption and rsvp: exposing characteristics of confidentialtraffic X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Dec 2006 21:45:50 -0000 Francois, My general concern for the draft is: > > The concern about how to use a PHB consisting of multiple DSCPs (e.g., AF) > > also applies to the rsvp-ipsec draft. Using PHBIDs (cf. RFC 3140) may > > help address this, and this concern may also affect RFC 3175. For example, this sentence from the Introduction (Section 1) applies to EF, but not AF for carrying the reserved traffic: One example is where E2E reservations using different preemption priorities (as per [RSVP-PREEMP]) need to be aggregated through a Diffserv cloud using the same DSCP. The underlying situation is that the raw notion of DSCP is being used instead of a PHB, and for better or worse, this is already the case in RFC 3175. The practical upshot is that RFC 3175 effectively forbids use of AF PHBs for carrying reserved traffic - one has to explicitly specify the DSCP (which could also be used as part of an AF PHB if one was being careful). Going back and changing RFC 3175 at this point is definitely *not* a good idea, so I would suggest just making this observation (RFC 3175 requires use of a single DSCP for traffic aggregated into a single reservation) in the rsvp-ipsec draft and observing that this forbids meaningful use of AF drop precedence for traffic covered by an RSVP reservation. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com] > Sent: Tuesday, December 26, 2006 6:04 AM > To: Black, David > Cc: Francois Le Faucheur IMAP; Sam Hartman; saag@MIT.EDU; > ipsec@ietf.org; tsvwg-chairs@tools.ietf.org; Fred Baker; Bose Pratik > Subject: Re: [saag] tsvwg,preemption and rsvp: exposing > characteristics of confidentialtraffic > > Hello David, > > Now that we've converged on the list on the text for the Security > Considerations section, I'd like to issue the updated version of the > Generic Aggregate RSVP Reservation I-D (i.e. the confusingly named > rsvp-ipsec draft). > > My understanding is that Fred/Pratik will do some edits in vpn- > signaled-preemption as discussed by email to address your initial concern. > Is there anything remaining from your concern below that you feel > still needs resolution in rsvp-ipsec? > If yes, any specific suggestions? > > Thank you and happy holiday season. > > Francois > > On 2 Oct 2006, at 15:41, Black_David@emc.com wrote: > > > Francois, > > > > The concern about how to use a PHB consisting of multiple DSCPs (e.g., AF) > > also applies to the rsvp-ipsec draft. Using PHBIDs (cf. RFC 3140) may > > help address this, and this concern may also affect RFC 3175. > > > > Thanks, > > --David > > ---------------------------------------------------- > > David L. Black, Senior Technologist > > EMC Corporation, 176 South St., Hopkinton, MA 01748 > > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > > black_david@emc.com Mobile: +1 (978) 394-7754 > > ---------------------------------------------------- > > > >> -----Original Message----- > >> From: Francois Le Faucheur [mailto:flefauch@cisco.com] > >> Sent: Monday, October 02, 2006 6:03 AM > >> To: Black, David > >> Cc: Francois Le Faucheur; hartmans-ietf@MIT.EDU; > >> saag@MIT.EDU; ipsec@ietf.org; tsvwg-chairs@tools.ietf.org; > >> fred@cisco.com > >> Subject: Re: [saag] tsvwg,preemption and rsvp: exposing > >> characteristics of confidentialtraffic > >> > >> Hello, > >> > >> Just expanding on Dave's observation: > >> > >>>> These drafts set up a model under which each precedence class of data > >>>> from a preemption standpoint goes over its own SA and uses its own > >>>> aggregate RSVP reservation. What that means is you expose on the > >>>> unprotected side of the interface what fraction of your traffic is at > >>>> each precedence level. > >>> > >>> Actually, only the vpn-signaled-preemption draft appears to do this. > >>> > >>> The rsvp-ipsec draft allows multiple reservations between the same > >>> endpoints for the same DSCP, which would allow such traffic to use > >>> different tunnels but if it requires traffic for different > >>> reservations to use different tunnels, I was not able to find > >>> a statement of that requirement. > >>> > >> > >> Right. > >> The rsvp-ipsec draft effectively decorelates the aggregate > >> reservations from the security associations (this was done as a > >> result of the first round of Security Experts review we got). So, for example,: > >> * it allows to set up multiple aggregate reservations using a single SA > >> * it allows to setup one aggregate reservation per SA > >> * it does not force/mandate either of these modes. > >> > >> The logic is to provide a generic mechanism which may be used in > >> different ways, in particular in the way(s) discussed in vpn-signaled-preemption. > >> rsvp-ipsec refers to vpn-signaled-preemption's Security > >> Considerations for when used as per vpn-signaled-preemption. > >> > >> Cheers > >> > >> Francois > > From flefauch@cisco.com Fri Dec 29 05:03:44 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id kBTA3hMA028886 for ; Fri, 29 Dec 2006 05:03:43 -0500 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id kBTA3a3o021658 for ; Fri, 29 Dec 2006 05:03:36 -0500 (EST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by mit.edu (Spam Firewall) with ESMTP id 7C9A61A5B2F; Fri, 29 Dec 2006 05:03:34 -0500 (EST) Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 29 Dec 2006 11:03:35 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kBTA3X36002175; Fri, 29 Dec 2006 11:03:33 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kBTA3BAA013505; Fri, 29 Dec 2006 11:03:22 +0100 (MET) Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Dec 2006 11:02:50 +0100 Received: from [144.254.53.108] ([144.254.53.108]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Dec 2006 11:02:49 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: multipart/alternative; boundary=Apple-Mail-4-100707851 Message-Id: From: Francois Le Faucheur IMAP Date: Fri, 29 Dec 2006 11:01:08 +0100 To: Black_David@emc.com X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 29 Dec 2006 10:02:50.0018 (UTC) FILETIME=[7F758020:01C72B30] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=35316; t=1167386613; x=1168250613; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20Re=3A=20[saag]=20tsvwg, preemption=20and=20rsvp=3A=20exposing= 20characteristics=20of=20confidentialtraffic |Sender:=20; bh=v7z/5XbMpdWChRg/Qie+mXyljUbiiJXi4KGPkSzwQ0w=; b=X8bF0uKO9i6UWa4ex+mFiMq75ugLvUWDvzCBesoZXmILjMaf7c0teCbFXGuGC1bxDUtF8jHQ Ka0oo9eVX0J10CwrvWh06M/8WqksmkO5l4Btb730DLB3wGoerT907uGl; Authentication-Results: ams-dkim-1; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.27 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: ipsec@ietf.org, Francois Le Faucheur IMAP , pratik.bose@lmco.com, fred@cisco.com, saag@mit.edu, hartmans-ietf@mit.edu, tsvwg-chairs@tools.ietf.org Subject: Re: [saag] tsvwg, preemption and rsvp: exposing characteristics of confidentialtraffic X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Dec 2006 10:03:44 -0000 --Apple-Mail-4-100707851 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hello David, Now I understand your concern. Please see below: On 28 Dec 2006, at 22:44, Black_David@emc.com wrote: > Francois, > > My general concern for the draft is: > >>> The concern about how to use a PHB consisting of multiple DSCPs > (e.g., AF) >>> also applies to the rsvp-ipsec draft. Using PHBIDs (cf. RFC 3140) > may >>> help address this, and this concern may also affect RFC 3175. > > For example, this sentence from the Introduction (Section 1) applies > to EF, but not AF for carrying the reserved traffic: > > One example is where E2E reservations using > different preemption priorities (as per [RSVP-PREEMP]) need to be > aggregated through a Diffserv cloud using the same DSCP. > > The underlying situation is that the raw notion of DSCP is being used > instead of a PHB, and for better or worse, this is already the case > in RFC 3175. The practical upshot is that RFC 3175 effectively > forbids > use of AF PHBs for carrying reserved traffic - Actually, RFC 3175 explicitly (attempts to) allow(s) the use of AF PHBs for carrying reserved traffic. In particular, it says: " In the case where a session uses a pair of PHBs (e.g., AF11 and AF12), the DSCP used should represent the numerically smallest PHB (e.g., AF11). This follows the same naming convention described in [BRIM]. ... [BRIM] Brim, S., Carpenter, B. and F. LeFaucheur, "Per Hop Behavior Identification Codes", RFC 2836, May 2000. " Do you agree that RFC 3175 allows use of AF? > one has to explicitly > specify the DSCP (which could also be used as part of an AF PHB if > one was being careful). Going back and changing RFC 3175 at this > point is definitely *not* a good idea, so I would suggest just making > this observation (RFC 3175 requires use of a single DSCP for traffic > aggregated into a single reservation) in the rsvp-ipsec draft and > observing that this forbids meaningful use of AF drop precedence > for traffic covered by an RSVP reservation. With respect to rsvp-ipsec, a simple approach is to edit the description text of the "DSCP" field in the GENERIC-AGGREGATE SESSION object along the lines of what is in RFC 3175 (ie if session uses single PHB, then field contains the DSCP of PHB. If session uses group of PHBs like AF1x, then field contains the numerically smallest DSCP value as per [PHB-ID]). This would make it explicit that rsvp- ipsec also allows use of PHB groups, and would ensure consistent use of DSCP field between RFC 3175 and rsvp-ipsec. The other approach would be to change the format of the GENERIC- AGGREGATE SESSION object and include a full 16-bit PHB-ID instead of DSCP field. I can see that this could help in situations where (i) the Aggregate reservation crosses Diffserv domain boundaries and (ii) different DSCP values are used for a given PHB/PHB-group. But I am not sure that this would be a common situation. On the flip side, it would make things less consistent between RFC 3175 and rsvp-ipsec (for example, in cases where the operator has elected to use a DSCP for the PHB which is different from the recommended DSCP value, then RFC 3175 would encode the used-DSCP while rsvp-ipsec would encode the recommended-DSCP as per PHB-ID). Thoughts? BTW: One related question on PHB-ID. PHB-ID says " Note that the recommended DSCP value MUST be used, even if the network in question has chosen a different mapping." So what happens if someone wants to deploy two instances of EF? how do you encode those in a PHB-ID? Cheers Francois > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > black_david@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > >> -----Original Message----- >> From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com] >> Sent: Tuesday, December 26, 2006 6:04 AM >> To: Black, David >> Cc: Francois Le Faucheur IMAP; Sam Hartman; saag@MIT.EDU; >> ipsec@ietf.org; tsvwg-chairs@tools.ietf.org; Fred Baker; Bose Pratik >> Subject: Re: [saag] tsvwg,preemption and rsvp: exposing >> characteristics of confidentialtraffic >> >> Hello David, >> >> Now that we've converged on the list on the text for the Security >> Considerations section, I'd like to issue the updated version of the >> Generic Aggregate RSVP Reservation I-D (i.e. the confusingly named >> rsvp-ipsec draft). >> >> My understanding is that Fred/Pratik will do some edits in vpn- >> signaled-preemption as discussed by email to address your initial > concern. >> Is there anything remaining from your concern below that you feel >> still needs resolution in rsvp-ipsec? >> If yes, any specific suggestions? >> >> Thank you and happy holiday season. >> >> Francois >> >> On 2 Oct 2006, at 15:41, Black_David@emc.com wrote: >> >>> Francois, >>> >>> The concern about how to use a PHB consisting of multiple DSCPs > (e.g., AF) >>> also applies to the rsvp-ipsec draft. Using PHBIDs (cf. RFC 3140) > may >>> help address this, and this concern may also affect RFC 3175. >>> >>> Thanks, >>> --David >>> ---------------------------------------------------- >>> David L. Black, Senior Technologist >>> EMC Corporation, 176 South St., Hopkinton, MA 01748 >>> +1 (508) 293-7953 FAX: +1 (508) 293-7786 >>> black_david@emc.com Mobile: +1 (978) 394-7754 >>> ---------------------------------------------------- >>> >>>> -----Original Message----- >>>> From: Francois Le Faucheur [mailto:flefauch@cisco.com] >>>> Sent: Monday, October 02, 2006 6:03 AM >>>> To: Black, David >>>> Cc: Francois Le Faucheur; hartmans-ietf@MIT.EDU; >>>> saag@MIT.EDU; ipsec@ietf.org; tsvwg-chairs@tools.ietf.org; >>>> fred@cisco.com >>>> Subject: Re: [saag] tsvwg,preemption and rsvp: exposing >>>> characteristics of confidentialtraffic >>>> >>>> Hello, >>>> >>>> Just expanding on Dave's observation: >>>> >>>>>> These drafts set up a model under which each precedence class of > data >>>>>> from a preemption standpoint goes over its own SA and uses its > own >>>>>> aggregate RSVP reservation. What that means is you expose on the >>>>>> unprotected side of the interface what fraction of your traffic > is at >>>>>> each precedence level. >>>>> >>>>> Actually, only the vpn-signaled-preemption draft appears to do > this. >>>>> >>>>> The rsvp-ipsec draft allows multiple reservations between the same >>>>> endpoints for the same DSCP, which would allow such traffic to use >>>>> different tunnels but if it requires traffic for different >>>>> reservations to use different tunnels, I was not able to find >>>>> a statement of that requirement. >>>>> >>>> >>>> Right. >>>> The rsvp-ipsec draft effectively decorelates the aggregate >>>> reservations from the security associations (this was done as a >>>> result of the first round of Security Experts review we got). So, > for example,: >>>> * it allows to set up multiple aggregate reservations using a > single SA >>>> * it allows to setup one aggregate reservation per SA >>>> * it does not force/mandate either of these modes. >>>> >>>> The logic is to provide a generic mechanism which may be used in >>>> different ways, in particular in the way(s) discussed in > vpn-signaled-preemption. >>>> rsvp-ipsec refers to vpn-signaled-preemption's Security >>>> Considerations for when used as per vpn-signaled-preemption. >>>> >>>> Cheers >>>> >>>> Francois >> >> --Apple-Mail-4-100707851 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
Hello David,

Now I understand your = concern. Please see below:

On 28 Dec 2006, at 22:44, = Black_David@emc.com = wrote:

Francois,

My = general concern for the draft is:

The concern about how to use a = PHB consisting of multiple DSCPs
(e.g., AF)
also applies to the rsvp-ipsec = draft.=A0 Using PHBIDs (cf. = RFC 3140)
may
=
help address this, and this concern may also affect = RFC 3175.

For example, this sentence from = the Introduction (Section 1) applies
to EF, but = not AF for carrying the reserved traffic:

=A0=A0 One example is where E2E = reservations using=A0
=A0=A0 = different preemption priorities (as per [RSVP-PREEMP]) need to = be=A0
=A0=A0 = aggregated through a Diffserv cloud using the same = DSCP.

The underlying situation is that the raw notion of = DSCP is being used
instead of a PHB, and for = better or worse, this is already the case
in RFC = 3175.=A0 The practical = upshot is that RFC 3175 effectively forbids
use of = AF PHBs for carrying reserved traffic -

Actually, RFC 3175 = explicitly=A0(attempts to) allow(s) the use of AF PHBs for carrying = reserved traffic.
In particular, it = says:
"
=A0 =A0In the case where a session uses a = pair of PHBs (e.g., AF11
=A0=A0 and AF12), the DSCP used = should represent the numerically smallest
=A0=A0 PHB (e.g., = AF11).=A0 This follows the same naming convention described
=A0=A0= in [BRIM].
...

=A0 =A0[BRIM]=A0 =A0 =A0=A0 = Brim, S., Carpenter, B. and F. LeFaucheur, "Per Hop
=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 Behavior Identification Codes", RFC 2836, May = 2000.
"

Do you agree that RFC 3175 = allows use of AF?


one has to explicitly
specify = the DSCP (which could also be used as part of an AF PHB if
one was being careful).=A0 Going back and changing RFC = 3175 at this
point is definitely *not* a good = idea, so I would suggest just making
this = observation (RFC 3175 requires use of a single DSCP for = traffic
aggregated into a single = reservation) in the rsvp-ipsec draft and
for traffic covered by an RSVP = reservation.

With respect to rsvp-ipsec, = a simple approach is to edit the description text of the "DSCP" field in = the GENERIC-AGGREGATE SESSION object along the = lines of what is in RFC 3175 (ie if session uses single PHB, then field = contains the DSCP of PHB. If session uses group of PHBs like AF1x, then = field contains the numerically smallest DSCP value as per [PHB-ID]). = This would make it explicit that rsvp-ipsec also allows use of PHB = groups, and would ensure consistent use of DSCP field between RFC 3175 = and rsvp-ipsec.

The other approach would be = to change the format of the=A0GENERIC-AGGREGATE = SESSION=A0object and include a full 16-bit PHB-ID = instead of DSCP field. I can see that this could help in situations = where (i) the Aggregate reservation crosses Diffserv domain boundaries = and (ii) different DSCP values are used for a given PHB/PHB-group. But I = am not sure that this would be a common situation. On the flip side, it = would make things less consistent between RFC 3175 and rsvp-ipsec (for = example, in cases where the operator has elected to use a DSCP for the = PHB which is different from the recommended DSCP value, then RFC = 3175=A0would encode the used-DSCP while rsvp-ipsec would encode the = recommended-DSCP as per PHB-ID).

Thoughts?

BTW:=A0One related question = on PHB-ID. PHB-ID says "=A0Note that the recommended DSCP value MUST be = used, even if=A0the network in question has chosen a different mapping." = So what happens if someone wants to deploy two instances of EF? how do = you encode those in a PHB-ID?

Cheers

Francois



--David
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA=A0 01748
+1 (508) 293-7953 =A0 =A0 =A0 =A0 =A0 =A0 FAX: +1 = (508) 293-7786
black_david@emc.com=A0 =A0 =A0 =A0 Mobile: +1 (978) = 394-7754

-----Original = Message-----
From: Francois Le Faucheur IMAP = [mailto:flefauch@cisco.com]=A0
Sent: = Tuesday, December 26, 2006 6:04 AM
To: Black, = David
Cc: Francois Le Faucheur IMAP; = Sam Hartman; saag@MIT.EDU;=A0


Is there anything remaining from = your concern below that you feel =A0
still = needs resolution in rsvp-ipsec?
If yes, any = specific suggestions?
Thank you and happy holiday = season.

Francois


=
Francois,

The = concern about how to use a PHB consisting of multiple DSCPs
=
(e.g., AF)
=
also applies to the rsvp-ipsec draft.=A0 Using PHBIDs (cf. RFC = 3140)
may
=
help address this, and this concern may also affect = RFC 3175.

Thanks,
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA=A0 01748
+1 (508) 293-7953 =A0 =A0 =A0 =A0 =A0 =A0 FAX: +1 = (508) 293-7786
black_david@emc.com=A0 =A0 =A0 =A0 Mobile: +1 (978) = 394-7754

-----Original = Message-----
From: Francois Le Faucheur [mailto:flefauch@cisco.com]
Sent: Monday, October 02, 2006 6:03 AM
To: Black, David
Cc: Francois = Le Faucheur; hartmans-ietf@MIT.EDU;
saag@MIT.EDU; ipsec@ietf.org; tsvwg-chairs@tools.ietf.org;
Subject: Re: [saag] tsvwg,preemption and rsvp: = exposing
characteristics of = confidentialtraffic
Hello,

Just = expanding on Dave's observation:

These drafts set up a model = under which each precedence class of
=
data
from a = preemption standpoint goes over its own SA and uses its
=
own
aggregate = RSVP reservation.=A0 What = that means is you expose on the
unprotected = side of the interface what fraction of your traffic
=
is at
each = precedence level.

Actually, only the = vpn-signaled-preemption draft appears to do
=
this.

The = rsvp-ipsec draft allows multiple reservations between the same
endpoints for the same DSCP, which would allow such = traffic to use
different tunnels but if it = requires traffic for different
reservations = to use different tunnels, I was not able to find
a statement of that requirement.


The rsvp-ipsec draft effectively = decorelates the aggregate
reservations = from the security associations (this was done as a
result of the first round of Security Experts review = we got). So,
for example,:
* it allows to set up multiple = aggregate reservations using a
=
single = SA
* it allows to setup one = aggregate reservation per SA
* it does = not force/mandate either of these modes.

The logic is = to provide a generic mechanism which may be used in
different ways, in particular in the way(s) = discussed in
vpn-signaled-preemption.
rsvp-ipsec refers to vpn-signaled-preemption's = Security
Considerations for when used as = per vpn-signaled-preemption.

Cheers




= --Apple-Mail-4-100707851-- From hartmans@MIT.EDU Fri Dec 29 12:11:34 2006 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id kBTHBYW2013111 for ; Fri, 29 Dec 2006 12:11:34 -0500 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id kBTHBRn1026840 for ; Fri, 29 Dec 2006 12:11:27 -0500 (EST) Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id C3A7D1B1ECB for ; Fri, 29 Dec 2006 12:11:25 -0500 (EST) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 06778E00B4; Fri, 29 Dec 2006 12:11:17 -0500 (EST) From: Sam Hartman To: saag@MIT.EDU Date: Fri, 29 Dec 2006 12:11:17 -0500 Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.82 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] [Richard Brackney] New ITU-T Identity Management Focus Group X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Dec 2006 17:11:34 -0000 --=-=-= I'm not entirely sure how they have scoped the problem. If people involved in the security area here are going to be involved in this effort they should speak up. --=-=-= Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from localhost ([unix socket]) by mail.suchdamage.org (Cyrus v2.2.13-Debian-2.2.13-10) with LMTPA; Fri, 29 Dec 2006 09:32:02 -0500 X-Sieve: CMU Sieve 2.2 Received: from south-station-annex.mit.edu (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by mail.suchdamage.org (Postfix) with ESMTP id E86F52041A for ; Fri, 29 Dec 2006 09:31:51 -0500 (EST) Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by south-station-annex.mit.edu (8.13.6/8.9.2) with ESMTP id kBTEVWJx028442 for ; Fri, 29 Dec 2006 09:31:32 -0500 (EST) Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id kBTEVPXK000036 for ; Fri, 29 Dec 2006 09:31:25 -0500 (EST) Received: from vms040pub.verizon.net (vms040pub.verizon.net [206.46.252.40]) by mit.edu (Spam Firewall) with ESMTP id 3637D16BAAB for ; Fri, 29 Dec 2006 09:31:23 -0500 (EST) Received: from NEWGATEWAY ([71.166.36.96]) by vms040.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0JB100DTWHNCNP17@vms040.mailsrvcs.net> for hartmans-ietf@mit.edu; Fri, 29 Dec 2006 08:31:13 -0600 (CST) Date: Fri, 29 Dec 2006 09:30:46 -0500 From: "Richard Brackney" Subject: New ITU-T Identity Management Focus Group Message-id: <000501c72b55$f201fea0$0201a8c0@NEWGATEWAY> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.13 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 X-DSPAM-Result: Innocent X-DSPAM-Processed: Fri Dec 29 09:32:02 2006 X-DSPAM-Confidence: 0.8512 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 459526e216571175920332 X-DSPAM-Factors: 27, To*, 0.00487, To*, 0.00487, Chair, 0.00587, Chair, 0.00587, To*nokia.com>, 0.00713, Received*2006))+with, 0.00928, X-MIMEOLE*V6.00.2900.3028, 0.01000, ">+

Hello and Happy New Year

 

Because you are the Chair of a Standards Body/Consortium that would have an interest in Identity Management (IdM), I want to inform you of a recent ITU-T, Study Group (SG) 13 event.

 

At the December 2006 meeting, ITU-T SG 17 approved the creation of a Focus Group (FG) on Identity Management (IdM). Detailed information about the FG along with the Circular that establishes it can be found at http://www.itu.int/ITU-T/studygroups/com17/fgidm/index.html .

 

A FG is the mechanism ITU-T uses to open participation to all interested parties when the ITU-T attempts to solve a problem that covers a broad range of disciplines and technologies. The objectives of the IdM FG are interoperability, interworking, common data models, discovery, privacy and governance in relationship to various IdM solutions for a global telecommunications environment.

 

In my role as Co-Chair of the FG and on behalf of the FG Chair, Abbie Barbir (NOTEL - Canada), we invite your organization to join the Focus Group. We are particularly interested in leveraging your organization’s expertise in a way that makes sense in a global telecommunications environment that is dependent on users and device identities.

 

The ITU-T is an ideal venue to promote identity management solutions at an international level. The first face to face meeting of this FG will be in Geneva during Feb 13-16, 2007. The structure and most of the Chairs of the Working Groups will be appointed during this meeting. To help focus the first meeting of the FG, we ask you to publicize the FG within your organization and encourage members of your organization to participate and submit technical contributions.

 

If your organization is interested in joining the FG, please contact me (rcbrack@verizon.net) and Abbie Barbir (abbieb@nortel.com ) with the name(s) and email(s) of the person(s) within your organization who would like to participate in the FG.

 

Thanks

 

Dick Brackney

Co-Chair ITU-T IdM FG

 

 

--===-=-=-- --=-=-=-- From Black_David@emc.com Fri Dec 29 13:01:15 2006 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id kBTI1Dt1025165 for ; Fri, 29 Dec 2006 13:01:13 -0500 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id kBTI19Zb017782 for ; Fri, 29 Dec 2006 13:01:09 -0500 (EST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 7F7841B7FFA; Fri, 29 Dec 2006 13:01:07 -0500 (EST) Received: from mailhub.lss.emc.com (nirah.lss.emc.com [10.254.144.13]) by mexforward.lss.emc.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id kBTH0qEJ000907; Fri, 29 Dec 2006 12:00:52 -0500 (EST) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id kBTI0bRT000830; Fri, 29 Dec 2006 13:00:47 -0500 (EST) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.13]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Dec 2006 13:00:37 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C72B73.3E20A375" Date: Fri, 29 Dec 2006 13:00:36 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] tsvwg, preemption and rsvp: exposing characteristics of confidentialtraffic Thread-Index: AccrMKbBkLLh+B1aT8+C3EXLAs9IegAQKxIg To: X-OriginalArrivalTime: 29 Dec 2006 18:00:37.0425 (UTC) FILETIME=[3E90AA10:01C72B73] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2006.12.29.93433 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2, HTML_50_70 0.1, HTML_NO_HTTP 0.1, NO_REAL_NAME 0, __C230066_P5 0, __CP_NOT_1 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_HTML 0, __MIME_VERSION 0, __RATWARE_SIGNATURE_3_N1 0, __SANE_MSGID 0, __TAG_EXISTS_HTML 0' X-Spam-Score: 1.41 X-Spam-Level: * (1.41) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: ipsec@ietf.org, tsvwg-chairs@tools.ietf.org, fred@cisco.com, saag@mit.edu, hartmans-ietf@mit.edu, pratik.bose@lmco.com, black_david@emc.com Subject: Re: [saag] tsvwg, preemption and rsvp: exposing characteristics of confidentialtraffic X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Dec 2006 18:01:15 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C72B73.3E20A375 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Francois, =20 > Do you agree that RFC 3175 allows use of AF? =20 Yes - the fact that it deliberately did not put in a full PHB-ID is unfortunate, as having to infer from context whether a DSCP is a singleton vs. representative of a group from context is not the best approach. It looks like I missed this AF support in quickly scanning RFC 3175. =20 > With respect to rsvp-ipsec, a simple approach is to edit the description text of the "DSCP" field in the > GENERIC-AGGREGATE SESSION object along the lines of what is in RFC 3175 (ie if session uses > single PHB, then field contains the DSCP of PHB. If session uses group of PHBs like AF1x, then field > contains the numerically smallest DSCP value as per [PHB-ID]). This would make it explicit that > rsvp-ipsec also allows use of PHB groups, and would ensure consistent use of DSCP field between > RFC 3175 and rsvp-ipsec. =20 That's probably the right thing to do at this juncture, because ... =20 > The other approach would be to change the format of the GENERIC-AGGREGATE SESSION object > and include a full 16-bit PHB-ID instead of DSCP field. I can see that this could help in situations where > (i) the Aggregate reservation crosses Diffserv domain boundaries and (ii) different DSCP values are used > for a given PHB/PHB-group. But I am not sure that this would be a common situation. On the flip side, > it would make things less consistent between RFC 3175 and rsvp-ipsec (for example, in cases where the > operator has elected to use a DSCP for the PHB which is different from the recommended DSCP value, > then RFC 3175 would encode the used-DSCP while rsvp-ipsec would encode the recommended-DSCP > as per PHB-ID). =20 ... probably entails going back and changing RFC 3175 to use a PHB-ID, something that it's probably entirely too late to do, and I agree that a divergence between RFC 3175 and rsvp-ipsec is undesirable. =20 > BTW: One related question on PHB-ID. PHB-ID says " Note that the recommended DSCP value MUST > be used, even if the network in question has chosen a different mapping." So what happens if someone wants > to deploy two instances of EF? how do you encode those in a PHB-ID? =20 The second EF instance would be a case 2 PHB-ID - experimental or local use. The current PHB-ID reference is RFC 3140. =20 One of the things I think we're discovering (e.g., w/Fred's admitted-voice PHB) is that EF instances aren't completely combinable in practice - in theory they're completely combinable, and hence one never needs more than one, *if* the rules are followed perfectly. That "if" doesn't appear to completely hold in practice. =20 Thanks, --David =20 ________________________________ From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com]=20 Sent: Friday, December 29, 2006 5:01 AM To: Black, David Cc: Francois Le Faucheur IMAP; hartmans-ietf@MIT.EDU; saag@MIT.EDU; ipsec@ietf.org; tsvwg-chairs@tools.ietf.org; fred@cisco.com; pratik.bose@lmco.com Subject: Re: [saag] tsvwg,preemption and rsvp: exposing characteristics of confidentialtraffic =09 =09 Hello David, Now I understand your concern. Please see below: On 28 Dec 2006, at 22:44, Black_David@emc.com wrote: Francois, My general concern for the draft is: The concern about how to use a PHB consisting of multiple DSCPs (e.g., AF) also applies to the rsvp-ipsec draft. Using PHBIDs (cf. RFC 3140) may help address this, and this concern may also affect RFC 3175. For example, this sentence from the Introduction (Section 1) applies to EF, but not AF for carrying the reserved traffic: One example is where E2E reservations using=20 different preemption priorities (as per [RSVP-PREEMP]) need to be=20 aggregated through a Diffserv cloud using the same DSCP. The underlying situation is that the raw notion of DSCP is being used instead of a PHB, and for better or worse, this is already the case in RFC 3175. The practical upshot is that RFC 3175 effectively forbids use of AF PHBs for carrying reserved traffic -=20 =09 Actually, RFC 3175 explicitly (attempts to) allow(s) the use of AF PHBs for carrying reserved traffic. In particular, it says: " In the case where a session uses a pair of PHBs (e.g., AF11 and AF12), the DSCP used should represent the numerically smallest PHB (e.g., AF11). This follows the same naming convention described in [BRIM]. ... [BRIM] Brim, S., Carpenter, B. and F. LeFaucheur, "Per Hop Behavior Identification Codes", RFC 2836, May 2000. " Do you agree that RFC 3175 allows use of AF? one has to explicitly specify the DSCP (which could also be used as part of an AF PHB if one was being careful). Going back and changing RFC 3175 at this point is definitely *not* a good idea, so I would suggest just making this observation (RFC 3175 requires use of a single DSCP for traffic aggregated into a single reservation) in the rsvp-ipsec draft and observing that this forbids meaningful use of AF drop precedence for traffic covered by an RSVP reservation. =09 =09 With respect to rsvp-ipsec, a simple approach is to edit the description text of the "DSCP" field in the GENERIC-AGGREGATE SESSION object along the lines of what is in RFC 3175 (ie if session uses single PHB, then field contains the DSCP of PHB. If session uses group of PHBs like AF1x, then field contains the numerically smallest DSCP value as per [PHB-ID]). This would make it explicit that rsvp-ipsec also allows use of PHB groups, and would ensure consistent use of DSCP field between RFC 3175 and rsvp-ipsec. The other approach would be to change the format of the GENERIC-AGGREGATE SESSION object and include a full 16-bit PHB-ID instead of DSCP field. I can see that this could help in situations where (i) the Aggregate reservation crosses Diffserv domain boundaries and (ii) different DSCP values are used for a given PHB/PHB-group. But I am not sure that this would be a common situation. On the flip side, it would make things less consistent between RFC 3175 and rsvp-ipsec (for example, in cases where the operator has elected to use a DSCP for the PHB which is different from the recommended DSCP value, then RFC 3175 would encode the used-DSCP while rsvp-ipsec would encode the recommended-DSCP as per PHB-ID). Thoughts? BTW: One related question on PHB-ID. PHB-ID says " Note that the recommended DSCP value MUST be used, even if the network in question has chosen a different mapping." So what happens if someone wants to deploy two instances of EF? how do you encode those in a PHB-ID? Cheers Francois Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- ------_=_NextPart_001_01C72B73.3E20A375 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Francois,
 
> Do you = agree that=20 RFC 3175 allows use of AF?
 
Yes - the fact that it deliberately did not put in a full = PHB-ID is=20 unfortunate,
as having to infer from context whether a DSCP is a singleton = vs.=20 representative
of a group from context is not the best = approach.  It looks=20 like I missed
this AF support in quickly scanning RFC 3175.
 
> With = respect to=20 rsvp-ipsec, a simple approach is to edit the description text of the = "DSCP"=20 field in the
> = GENERIC-AGGREGATE SESSION = object=20 along the lines of what is in RFC 3175 (ie if session uses
> single = PHB, then=20 field contains the DSCP of PHB. If session uses group of PHBs like AF1x, = then=20 field
> = contains the=20 numerically smallest DSCP value as per [PHB-ID]). This would make it = explicit=20 that
> = rsvp-ipsec also=20 allows use of PHB groups, and would ensure consistent use of DSCP field=20 between
> RFC = 3175 and=20 rsvp-ipsec.
 
That's probably the right thing to do at this juncture, because = ...
 
> The = other approach=20 would be to change the format of the GENERIC-AGGREGATE=20 SESSION object
> and = include a full=20 16-bit PHB-ID instead of DSCP field. I can see that this could help in=20 situations where
> (i) = the Aggregate=20 reservation crosses Diffserv domain boundaries and (ii) different DSCP = values=20 are used
> for a = given=20 PHB/PHB-group. But I am not sure that this would be a common situation. = On the=20 flip side,
> it = would make things=20 less consistent between RFC 3175 and rsvp-ipsec (for example, in cases = where=20 the
> = operator has elected=20 to use a DSCP for the PHB which is different from the recommended DSCP=20 value,
> then = RFC=20 3175 would encode the used-DSCP while rsvp-ipsec would encode the=20 recommended-DSCP
> as per = PHB-ID).
 
... probably entails going back and changing RFC 3175 to use a = PHB-ID,=20 something
that it's probably entirely too late to do, and I agree that a = divergence=20 between
RFC 3175 and rsvp-ipsec is undesirable.
 
> = BTW: One=20 related question on PHB-ID. PHB-ID says " Note that the recommended = DSCP=20 value MUST
> be = used,=20 even if the network in = question has=20 chosen a different mapping." So what happens if someone = wants
> to = deploy two=20 instances of EF? how do you encode those in a PHB-ID?
 
The second EF instance would be a case 2 PHB-ID - experimental = or local=20 use.
The current PHB-ID reference is RFC 3140.
 
One of the things I think we're discovering (e.g., w/Fred's=20 admitted-voice PHB)
is that EF instances aren't completely combinable in practice - = in theory=20 they're
completely combinable, and hence one never needs more than one, = *if* the=20 rules
are followed perfectly.  That "if" doesn't appear to = completely hold=20 in practice.
 
Thanks,
--David
 

From: Francois Le Faucheur IMAP=20 [mailto:flefauch@cisco.com]
Sent: Friday, December 29, 2006 = 5:01=20 AM
To: Black, David
Cc: Francois Le Faucheur IMAP; = hartmans-ietf@MIT.EDU; saag@MIT.EDU; ipsec@ietf.org;=20 tsvwg-chairs@tools.ietf.org; fred@cisco.com;=20 pratik.bose@lmco.com
Subject: Re: [saag] tsvwg,preemption = and rsvp:=20 exposing characteristics of confidentialtraffic

Hello David,

Now I understand your concern. Please see below:

On 28 Dec 2006, at 22:44, Black_David@emc.com = wrote:
Francois,

My general concern for the draft = is:

The concern about how to use a PHB = consisting=20 of multiple DSCPs
(e.g., AF)
also applies to the rsvp-ipsec = draft.  Using PHBIDs (cf. = RFC=20 3140)
may
help address this, and this concern = may also=20 affect RFC 3175.

For example, this sentence from the = Introduction=20 (Section 1) applies
to EF, but not AF for carrying the = reserved=20 traffic:

  =20 One example is where E2E reservations using 
  =20 different preemption priorities (as per [RSVP-PREEMP]) need = to=20 be 
  =20 aggregated through a Diffserv cloud using the same = DSCP.

The underlying situation is that the raw = notion of=20 DSCP is being used
instead of a PHB, and for better or = worse, this is=20 already the case
in RFC 3175.  The practical upshot is = that RFC=20 3175 effectively forbids
use of AF PHBs for carrying reserved = traffic -=20

Actually, RFC 3175 explicitly (attempts to) allow(s) the use = of AF=20 PHBs for carrying reserved traffic.
In particular, it says:
"
   In the case where a session uses a pair of PHBs = (e.g.,=20 AF11
   and AF12), the DSCP used should represent the = numerically=20 smallest
   PHB (e.g., AF11).  This follows the same naming = convention described
   in [BRIM].
...

   [BRIM]       Brim, S., = Carpenter, B. and=20 F. LeFaucheur, "Per Hop
                Behavior=20 Identification Codes", RFC 2836, May 2000.
"

Do you agree that RFC 3175 allows use of AF?


one has to explicitly
specify the DSCP (which could also be = used as part=20 of an AF PHB if
one was being careful).  Going back and changing = RFC 3175=20 at this
point is definitely *not* a good idea, so = I would=20 suggest just making
this observation (RFC 3175 requires use = of a single=20 DSCP for traffic
aggregated into a single reservation) in = the=20 rsvp-ipsec draft and
observing that this forbids meaningful = use of AF=20 drop precedence
for traffic covered by an RSVP=20 reservation.
With respect to rsvp-ipsec, a simple approach is to edit the = description=20 text of the "DSCP" field in the GENERIC-AGGREGATE = SESSION object=20 along the lines of what is in RFC 3175 (ie if session uses single PHB, = then=20 field contains the DSCP of PHB. If session uses group of PHBs like = AF1x, then=20 field contains the numerically smallest DSCP value as per [PHB-ID]). = This=20 would make it explicit that rsvp-ipsec also allows use of PHB groups, = and=20 would ensure consistent use of DSCP field between RFC 3175 and=20 rsvp-ipsec.

The other approach would be to change the format of = the GENERIC-AGGREGATE=20 SESSION object and include a full 16-bit = PHB-ID=20 instead of DSCP field. I can see that this could help in situations = where (i)=20 the Aggregate reservation crosses Diffserv domain boundaries and (ii)=20 different DSCP values are used for a given PHB/PHB-group. But I am not = sure=20 that this would be a common situation. On the flip side, it would make = things=20 less consistent between RFC 3175 and rsvp-ipsec (for example, in cases = where=20 the operator has elected to use a DSCP for the PHB which is different = from the=20 recommended DSCP value, then RFC 3175 would encode the used-DSCP = while=20 rsvp-ipsec would encode the recommended-DSCP as per PHB-ID).

Thoughts?

BTW: One related question on PHB-ID. PHB-ID says " Note = that=20 the recommended DSCP value MUST be used, even if the network in = question=20 has chosen a different mapping." So what happens if someone wants to = deploy=20 two instances of EF? how do you encode those in a PHB-ID?

Cheers

Francois



Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., = Hopkinton, MA  01748
+1 (508) 293-7953           =  =20 FAX: +1 (508) 293-7786
black_david@emc.com        = Mobile: +1=20 (978) 394-7754
----------------------------------------------------
------_=_NextPart_001_01C72B73.3E20A375--