From stephen.farrell@cs.tcd.ie Thu Jun 2 02:29:34 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACE84E0704 for ; Thu, 2 Jun 2011 02:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qfZcStJNoexC for ; Thu, 2 Jun 2011 02:29:34 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 23570E06C3 for ; Thu, 2 Jun 2011 02:29:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 1BF28171C39 for ; Thu, 2 Jun 2011 10:29:31 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1307006970; bh=hsZKLYKZgqST6nWASmeDIKTz EfcNhq8PFj9o6D9ZP7Q=; b=Jl2N567C9HzmR8B3Ioxs07RK6pe5XM2ih4nnjfYJ MLf2Dj9mIBNxrlAQNP347JySCnRHP+/098UucApAccdPNSdbOMGo9/+WGTTjbJAs sVSoG+cZvQ9C/peb98zg3wKBUI/EyIA1/Ee0rSJQ3nYYLb/PB/D/KketZjW1a7xx q1H93IlhQLTzHOCvWyJ+aU1V7qfsqX2v19GTg2znF9M0VtBwJLerZ5v41tzruSgp wYz3JfzODi0+h0XiDHTuomBXtIBZpXakG66LhvMMcXyTSrxjkVdwkjvoRH6bGr36 Lx7naIECaqMQlQqpZSFR4PoQHQvI74A+DTCofWcJcS+jBQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id n1XuSwQjuTuQ for ; Thu, 2 Jun 2011 10:29:30 +0100 (IST) Received: from [134.226.36.137] (stephen-samy.dsg.cs.tcd.ie [134.226.36.137]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 02A1A171C03 for ; Thu, 2 Jun 2011 10:29:29 +0100 (IST) Message-ID: <4DE757F9.6000102@cs.tcd.ie> Date: Thu, 02 Jun 2011 10:29:29 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: "saag@ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [saag] reminder: WG session and BoF requests X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 09:29:34 -0000 Folks, Monday is the deadline for requesting WG sessions at IETF 81: https://datatracker.ietf.org/cgi-bin/wg/wg_session_requester.cgi And Monday the 13th is the deadline for BoF requests: http://www.ietf.org/iesg/bof-procedures.html Cheers, S. From Jeff.Hodges@KingsMountain.com Fri Jun 3 09:23:40 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A39BE0772 for ; Fri, 3 Jun 2011 09:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.009 X-Spam-Level: X-Spam-Status: No, score=-101.009 tagged_above=-999 required=5 tests=[AWL=-1.304, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_66=0.6, RCVD_IN_BL_SPAMCOP_NET=1.96, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gRhVZs+NRmxC for ; Fri, 3 Jun 2011 09:23:39 -0700 (PDT) Received: from oproxy2-pub.bluehost.com (oproxy2-pub.bluehost.com [67.222.39.55]) by ietfa.amsl.com (Postfix) with SMTP id 873BEE073D for ; Fri, 3 Jun 2011 09:23:39 -0700 (PDT) Received: (qmail 9951 invoked by uid 0); 3 Jun 2011 16:23:38 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy2.bluehost.com with SMTP; 3 Jun 2011 16:23:38 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=4UEUV3ETniDqZqfrqJhw3wSp4Z/WVemhKtNCapKOYN+SLoddjyy8BNJFCQcKjkI6EMsvTjk/M3zDM/8JFXMTq/kkhZ7KN+zQXx3y8QsU0Mubz5TH50jtHRc/vwzx0t74; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.136.46]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QSX9u-0002O3-MM for saag@ietf.org; Fri, 03 Jun 2011 10:23:38 -0600 Message-ID: <4DE90A8A.2000309@KingsMountain.com> Date: Fri, 03 Jun 2011 09:23:38 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: IETF Security Area Advisory Group Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: Re: [saag] status on call for JavaScript (JS) Crypto Support (was: Paper for W3C Identity in the Browser Workshop) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 16:23:40 -0000 Hi, The paper that Sean, Stephen, & PeterSA wrote that was discussed here at = the=20 end of april, is published here.. The Need for a Web Security API slides:=20 It turns out that at that workshop=20 the need for such crypto= =20 support was mentioned either directly or or tacitly implied by several of= the=20 other presenters/authors/participants. So when the workshop was summed up= , it=20 was among the proposals with the most interest on the part of those prese= nt. See.. The W3C Identity in the Browser workshop: Final Report Rough Notes In fact, there's been work going on from time-to-time wrt JavaScript (JS= )=20 "native" crypto APIs, and David Dahl (Mozilla) has been working on that o= f=20 late, and has a prototype. He recently posted the below message to several lists, but the main discu= ssion=20 appears to be occurring on the public-webapps@w3.org list. Here's the roo= t of=20 the thread.. Request for feedback: DOMCrypt API proposal http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0795.html Also, fyi/fwiw, there's been recent discussion on this topic on the WhatW= G=20 (i.e. HTML) list.. [whatwg] window.cipher HTML crypto API draft spec http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-May/031741.ht= ml (there's also on-and-off crypto api discussions on that list predating th= e=20 above, e.g. in Feb-2011) HTH, =3DJeffH --- Subject: Request for feedback: DOMCrypt API proposal From: David Dahl Date: Wed, 1 Jun 2011 15:54:47 -0700 (PDT) To: public-webapps@w3.org (text/plain) Hello public-webapps members, (I wanted to post this proposed draft spec for the DOMCrypt API (=20 https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest ) to thi= s list=20 - if there is a more fitting mailing list, please let me know) I recently posted this draft spec for a crypto API for browsers to the wh= atwg=20 (see: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-May/031741= =2Ehtml)=20 and wanted to get feedback from W3C as well. Privacy and user control on the web is of utter importance. Tracking,=20 unauthorized user data aggregation and personal information breaches are = becoming so commonplace you see a new headline almost daily. (It seems). We need crypto APIs in browsers to allow developers to create more secure= =20 communications tools and web applications that don=92t have to implicitly= trust=20 the server, among other use cases. The DOMCrypt API is a good start, and more feedback and discussion will r= eally=20 help round out how all of this should work =96 as well as how it can work= in any=20 browser that will support such an API. This API will provide each web browser window with a =91cipher=92 propert= y[1] that=20 facilitates: asymmetric encryption key pair generation public key encryption public key decryption symmetric encryption signature generation signature verification hashing easy public key discovery via meta tags or an =91addressbookentry=92= tag [1] There is a bit of discussion around adding this API to window.navigat= or or=20 consolidation within window.crypto I have created a Firefox extension that implements most of the above, and= am=20 working on an experimental patch that integrates this API into Firefox. The project originated in an extension I wrote, the home page is here:=20 http://domcrypt.org The source code for the extension is here: https://github.com/daviddahl/d= omcrypt The Mozilla bugs are here: https://bugzilla.mozilla.org/show_bug.cgi?id=3D649154 https://bugzilla.mozilla.org/show_bug.cgi?id=3D657432 Firefox "feature wiki page": https://wiki.mozilla.org/Privacy/Features/DO= MCryptAPI You can test the API by installing the extension hosted at domcrypt.org, = and=20 going to http://domcrypt.org A recent blog post updating all of this is posted here:=20 http://monocleglobe..wordpress.com/2011/06/01/domcrypt-update-2011-06-01/= The API: window.cipher =3D { // Public Key API pk: { set algorithm(algorithm){ }, get algorithm(){ }, // Generate a keypair and then execute the callback function generateKeypair: function ( function callback( aPublicKey ) { } ) { }= , // encrypt a plainText encrypt: function ( plainText, function callback (cipherMessageObject)= ) {=20 } ) { }, // decrypt a cipherMessage decrypt: function ( cipherMessageObject, function callback ( plainText= ) { }=20 ) { }, // sign a message sign: function ( plainText, function callback ( signature ) { } ) { }= , // verify a signature verify: function ( signature, plainText, function callback ( boolean )= { } )=20 { }, // get the JSON cipherAddressbook get addressbook() {}, // make changes to the addressbook saveAddressbook: function (JSONObject, function callback ( addresssboo= k ) {=20 }) { } }, // Symmetric Crypto API sym: { get algorithm(), set algorithm(algorithm), // create a new symmetric key generateKey: function (function callback ( key ){ }) { }, // encrypt some data encrypt: function (plainText, key, function callback( cipherText ){ })= { }, // decrypt some data decrypt: function (cipherText, key, function callback( plainText ) { }= ) { }, }, // hashing hash: { SHA256: function (function callback (hash){}) { } } } Your feedback and criticism will be invaluable. Best regards, David Dahl Firefox Engineer, Mozilla Corp. --- end From stephen.farrell@cs.tcd.ie Sat Jun 4 09:54:04 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93F86E06B9; Sat, 4 Jun 2011 09:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6gU-EdC3jVT; Sat, 4 Jun 2011 09:54:04 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id E01BAE06B2; Sat, 4 Jun 2011 09:54:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 20B58171D91; Sat, 4 Jun 2011 17:54:00 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1307206438; bh=ZNv1PzZdQgCkhfWeprDHLp+p HqWZY5nSGvhTAoUJvSs=; b=a7/DTDvZUEAVjktgVI++zu/ee6AImye5r7VDKJnY Cy7p6yMMqBbOSSdN8nGdELcTZkIGWRU+cesUJzko6BRFDjX1MiCLHDgPPUTORHCP lGCbyYi4N9IwEGWB5eUt2gjfP4xGGDU7FcmTkyz877ET0Tv1zs7IBY4kuN+SMre0 QJJasZSEr19y8B7cG2hsTd1w1yND4f/+3KdaCX2DcQ1DmMsAE/HDUz5Wz5+/ioIQ r6PQaZQB5nHuLQwmrOxw4889ZVAoHCAyOBIbgXWarHfxypmYrzXQVtQuiOJN3wFo cCltyseGiNyYZ3Ya3ICwZxSx//J91NFCt9vAAPa07doF6Q== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 71PooJeNHN6f; Sat, 4 Jun 2011 17:53:58 +0100 (IST) Received: from [10.87.48.9] (unknown [86.45.54.169]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id D391F171C03; Sat, 4 Jun 2011 17:53:55 +0100 (IST) Message-ID: <4DEA6323.4070302@cs.tcd.ie> Date: Sat, 04 Jun 2011 17:53:55 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: "saag@ietf.org" , ipv6@ietf.org, v6ops@ietf.org X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [saag] ITU-T SG17 IPv6 security work items liaison X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jun 2011 16:54:04 -0000 Hi all, We received a liaison [1] from ITU-T saying they're planning to start a couple of work items on the security of IPv6. As far as we know, they envisage developing a "technical guideline on deploying IPv6" and "Security Management Guideline for implementation of IPv6 environment in telecommunications organizations." Bear in mind that they're just starting so they know about as much as we would just before a BoF or something like that. I think we'd like to respond to them that that's great, and we'll be interested in their results, but can they *please* come back to us before saying something should be changed so's we can talk about it. If you've comments or ideas on that, please respond to this in the next week. At that point, we'll get some help translating this into liaison-speak (thanks Eliot:-) and send the result to these lists for a quick check before shipping it off to the ITU-T folks. Cheers, S. [1] https://datatracker.ietf.org/liaison/1047/ From tena@huawei.com Sat Jun 4 23:25:16 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0354111E808C; Sat, 4 Jun 2011 23:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTTktb-9HJnn; Sat, 4 Jun 2011 23:25:15 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5DB11E8072; Sat, 4 Jun 2011 23:25:15 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LMB002S70I0M9@usaga02-in.huawei.com>; Sun, 05 Jun 2011 01:25:13 -0500 (CDT) Received: from TingZousc1 ([10.212.246.21]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LMB00KSJ0HW7G@usaga02-in.huawei.com>; Sun, 05 Jun 2011 01:25:12 -0500 (CDT) Date: Sat, 04 Jun 2011 23:25:03 -0700 From: Tina Tsou In-reply-to: To: 'Fred Baker' , 'Stephen Farrell' Message-id: <020601cc2349$530f5400$f92dfc00$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcwjR4ZQpJGdiSiJTVadap3krXe/CwAAbBaw References: <4DEA6323.4070302@cs.tcd.ie> Cc: ipv6@ietf.org, v6ops@ietf.org, saag@ietf.org Subject: Re: [saag] [v6ops] ITU-T SG17 IPv6 security work items liaison X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2011 06:25:16 -0000 Hi, RFC 4775 is the process to follow. We keep our promises with one another - no matter what! Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Fred Baker Sent: Saturday, June 04, 2011 11:10 PM To: Stephen Farrell Cc: Turner, Sean P.; v6ops@ietf.org; ipv6@ietf.org; saag@ietf.org; Eliot Lear Subject: Re: [v6ops] ITU-T SG17 IPv6 security work items liaison On Jun 4, 2011, at 9:53 AM, Stephen Farrell wrote: > I think we'd like to respond to them that that's great, > and we'll be interested in their results, but can they > *please* come back to us before saying something should > be changed so's we can talk about it. That seems like a reasonable proposal. There a, of course, several proposed sets of security guidelines for IPv6 floating in the breeze. If you want my druthers, I would like to see a comprehensive security *architecture*. Steve Kent wrote to me last month, on another topic, saying > I do have a few comments about the discuss of secruity, in general. I see that you used the CIA model for describing security requirements/services. Although this is a commonly used model, I find it inferior to the model that was developed by ISO in the mid 80's (ISO 7498-2). It might be worthwhile to look at the ISO model he suggests as a possible starting point. To my mind, anything resembling a security architecture will identify threats at the physical, link, network (LAN and IP), transport, and applications layers, and make recommendations for addressing them - and not start from the premise of a global federated identity, which doesn't exist. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From y.oiwa@aist.go.jp Sun Jun 5 10:06:53 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 473D011E809D; Sun, 5 Jun 2011 10:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.769 X-Spam-Level: * X-Spam-Status: No, score=1.769 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4S9r6TdnbR1n; Sun, 5 Jun 2011 10:06:52 -0700 (PDT) Received: from mx1.aist.go.jp (mx1.aist.go.jp [150.29.246.133]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE6511E809B; Sun, 5 Jun 2011 10:06:44 -0700 (PDT) Received: from rqsmtp2.aist.go.jp (rqsmtp2.aist.go.jp [150.29.254.123]) by mx1.aist.go.jp with ESMTP id p55H6eDW026639; Mon, 6 Jun 2011 02:06:40 +0900 (JST) env-from (y.oiwa@aist.go.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=aist.go.jp; s=aist; t=1307293601; bh=Mml2AqTlUsDw4XeO2CDdd6yNNvq9cbqtV8GWNgHH23w=; h=From:Date:Message-ID; b=RkFy9itZre+AH5Xliw5+JgP4yMYLpYEvG/kNtr2qwhwAnY1JV4HY2QWpWZS0BtKDm mGAyoyG5MCexQi8y/Tg+hiaJhYVIKYICoCrBgSCLPpQWq9tGvSENNLv6j/9t5HFzpU kNGf6r1maVzEiD+QgXYvXAJI3Ot24mJosGdOGgXA= Received: from smtp4.aist.go.jp by rqsmtp2.aist.go.jp with ESMTP id p55H6e0e002272; Mon, 6 Jun 2011 02:06:40 +0900 (JST) env-from (y.oiwa@aist.go.jp) Received: by smtp4.aist.go.jp with ESMTP id p55H6c42025520; Mon, 6 Jun 2011 02:06:38 +0900 (JST) env-from (y.oiwa@aist.go.jp) To: http-auth@ietf.org From: Yutaka OIWA Date: Mon, 06 Jun 2011 02:06:38 +0900 Message-ID: <878vtgfbs1.fsf@bluewind.rcis.aist.go.jp> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Harry Halpin , public-identity@w3.org, websec@ietf.org, saag@ietf.org Subject: [saag] re-call for IETF http-auth BoF X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: http-auth@ietf.org, y.oiwa@aist.go.jp List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2011 17:06:53 -0000 Dear all at http-auth mailing list, (Cc: Peter, Sean, Harry, and related mailing lists subscribers) following the discussions in the Prague http-auth Bar-BoF in March, and the W3C Identity in Browser workshop in the last month, now I would like to re-call the formation of BoF for http-auth in IETF. The workshop was really hot and enjoying, and there were so many useful inputs to both Web community and IETF, I believe. Some materials presented and discussed there are available at . # Harry, are the *output* materials of the workshop already available to public? Currently I'm preparing a start-up version of problem statement document and proposed BoF agenda. However, very unfortunately, the last week I had a severe fever heat and could not work well (I'm really sorry about that). I'm going to submit them to the list within two days, and if possible comments to the last version of the agenda proposal, available at , are welcome. I'm currently working based on that. Thanks, Yutaka -- Yutaka OIWA, Ph.D. Research Scientist Research Center for Information Security (RCIS) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] From lear@cisco.com Mon Jun 6 03:06:38 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D2A911E80F0; Mon, 6 Jun 2011 03:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQUBFjuXwGao; Mon, 6 Jun 2011 03:06:37 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 54F0711E808C; Mon, 6 Jun 2011 03:06:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=7439; q=dns/txt; s=iport; t=1307354797; x=1308564397; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=1uYQGLju7XRr6KKlj3vz0+0SQKDvRvj2ZAbOgZXNl/s=; b=GahtMpq8ogb0webfuD430Y2xoxLU/tlN5idcn4rBommQvea4m5s4Fnkw 70GfGyb3RIcYM1SRs/SJgqzLv7tb38a+9s+OMuga/O0qaNYdYgXFCh21H HDTmwv17WklLiSdrGN3StGg53spGmknl9efnmHMKDLUPKnirG9zy91x3X w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EALul7E1Io8UQ/2dsb2JhbABThEqhcHetV40JkBmFF4EKBJB5jzw X-IronPort-AV: E=Sophos;i="4.65,325,1304294400"; d="scan'208,217";a="92408112" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-1.cisco.com with ESMTP; 06 Jun 2011 10:06:05 +0000 Received: from dhcp-10-55-89-175.cisco.com (dhcp-10-55-89-175.cisco.com [10.55.89.175]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p56A62MF020755; Mon, 6 Jun 2011 10:06:02 GMT Message-ID: <4DECA68A.6080305@cisco.com> Date: Mon, 06 Jun 2011 12:06:02 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Arturo Servin References: <4DEA6323.4070302@cs.tcd.ie> <20110605031045.GK88250@verdi> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: multipart/alternative; boundary="------------070307020309060605080903" Cc: IPv6 Operations , ipv6@ietf.org, saag@ietf.org, John Leslie Subject: Re: [saag] ITU-T SG17 IPv6 security work items liaison X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 10:06:38 -0000 This is a multi-part message in MIME format. --------------070307020309060605080903 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Arturo, On 6/5/11 10:30 PM, Arturo Servin wrote: > I do not see why the ITU has to start from zero. There are several (or some at least) very good RFC and I+D documents related to IPv6 security. I think we should recommend them to ITU, it is good that they let us know, it would be better if they use our work as a foundation. There are several specific areas of interest that you can view at https://datatracker.ietf.org/documents/LIAISON/file1228.pdf. The chairman and vice-chairman of the ITU's security area, SG17, are informing us that two of their working groups which the ITU-T calls Questions will be taking on new work relating to IPv6. Let's review the two work items: The first thing to note is that X.ipv6-secguide is targeted to be a deployment guide. We need more of these for IPv6 and we should welcome the ITU-T's involvement. The second document, X.mgv6 is meant to be "management guidelines for implementation of IPv6". We provide a fair amount of this sort of guidance in our collective works. Also, the difference between implementation guidance and normative statements can be very narrow. Therefore, this is the area most likely to have overlap. The best way to address that overlap is to communicate effectively through the liaison process, and perhaps to also participate directly in the meetings, when possible. Here the chairman and vice-chairman of SG17 have recognized that the IETF is an important player in the work to be done. While no response has been requested, it would be wise for us to provide the relevant related work so, as you say, the ITU-T doesn't attempt to start from scratch. I hasten to point out that they are by no means starting from scratch, but we should still provide them relevant guidance. So what is relevant guidance? That can take several different forms: 1. Direct participation in the Study Group meetings. Study Group meetings are open to Member States and Sector Members. ISOC is a Sector Member. The IETF on its own is not. 2. Concise and relevant liaison statements. As this work is just beginning, we can point to not only the published RFCs that are relevant, and they include not only RFC 4294 and draft-ietf-6man-node-req-bis (and we can reference this as a work in progress, and in fact invite comment), but also relevant portions of other RFCs, particular their relevant Security Considerations sections. 3. Informal consultations with ITU-T participants. Believe it or not, this is often the most effective way to contribute. At the same time we should invite SG17 to provide us any feedback on our works, especially when they discover any of the following: * A security problem; * An obstacle to deployment; or * An interoperability problem. While this solicitation should not be limited to the ITU-T, that organization has a reach into the developing world that quite frankly we do not, and they may spot issues that relate to certain environments. Hope this helps, Eliot --------------070307020309060605080903 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Arturo,

On 6/5/11 10:30 PM, Arturo Servin wrote: 
	I do not see why the ITU has to start from zero. There are several (or some at least) very good RFC and I+D documents related to IPv6 security. I think we should recommend them to ITU, it is good that they let us know, it would be better if  they use our work as a foundation.


There are several specific areas of interest that you can view at https://datatracker.ietf.org/documents/LIAISON/file1228.pdf.  The chairman and vice-chairman of the ITU's security area, SG17, are informing us that two of their working groups which the ITU-T calls Questions will be taking on new work relating to IPv6.

Let's review the two work items:

The first thing to note is that X.ipv6-secguide is targeted to be a deployment guide.  We need more of these for IPv6 and we should welcome the ITU-T's involvement.

The second document, X.mgv6 is meant to be "management guidelines for implementation of IPv6".   We provide a fair amount of this sort of guidance in our collective works.  Also, the difference between implementation guidance and normative statements can be very narrow.  Therefore, this is the area most likely to have overlap.  The best way to address that overlap is to communicate effectively through the liaison process, and perhaps to also participate directly in the meetings, when possible.

Here the chairman and vice-chairman of SG17 have recognized that the IETF is an important player in the work to be done.  While no response has been requested, it would be wise for us to provide the relevant related work so, as you say, the ITU-T doesn't attempt to start from scratch.  I hasten to point out that they are by no means starting from scratch, but we should still provide them relevant guidance.  So what is relevant guidance?  That can take several different forms:

  1. Direct participation in the Study Group meetings.  Study Group meetings are open to Member States and Sector Members.  ISOC is a Sector Member.  The IETF on its own is not.
  2. Concise and relevant liaison statements.  As this work is just beginning, we can point to not only the published RFCs that are relevant, and they include not only RFC 4294 and draft-ietf-6man-node-req-bis (and we can reference this as a work in progress, and in fact invite comment), but also relevant portions of other RFCs, particular their relevant Security Considerations sections.
  3. Informal consultations with ITU-T participants.  Believe it or not, this is often the most effective way to contribute.
At the same time we should invite SG17 to provide us any feedback on our works, especially when they discover any of the following:
  • A security problem;
  • An obstacle to deployment; or
  • An interoperability problem.
While this solicitation should not be limited to the ITU-T, that organization has a reach into the developing world that quite frankly we do not, and they may spot issues that relate to certain environments.

Hope this helps,

Eliot
--------------070307020309060605080903-- From stephen.farrell@cs.tcd.ie Mon Jun 6 04:41:41 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56DA211E80F8; Mon, 6 Jun 2011 04:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KcGkv6PgkxUu; Mon, 6 Jun 2011 04:41:40 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 2D04211E80D6; Mon, 6 Jun 2011 04:41:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 5A76C171C18; Mon, 6 Jun 2011 12:41:39 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1307360497; bh=HGQZCafMYnnf4+ cQeY11uzwY5tWANiICFL/8uDkNxpc=; b=uuju7tFoXlq6V7j4TQGbUxhLmSXQ/P EzPwhIvHKGeDqINtSypNv6oimK3d1264ZRpmnMZgK6mu/toqCVoYeo5o4jBlxIeG DZ4Mmul6h47NwGgIwUUQw2PKwvJO91Qt1H+K0hpviG1crqV5iWiP1qNFALBqagHQ s8EZmA5IVcYa6pTsmj6VO9h4LoGxTLG0m7avfJ3+inkTDfUoGWZa1iWijSLBqwse WjLWBORn/Q59GfcpiXn6TtsKkX1CmzGfnN2JmS5gZxKVa1X4FxUvbjcO3H63Jcaw LbosmpcuFhP2F+AMMwgM2UhGpFoU6zxkl1ToBOjXBNgrrldZfhl5O+QA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id o8oaWcScZvBj; Mon, 6 Jun 2011 12:41:37 +0100 (IST) Received: from [10.87.48.9] (unknown [86.42.182.86]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 2C0D8171C17; Mon, 6 Jun 2011 12:41:35 +0100 (IST) Message-ID: <4DECBCEE.6070108@cs.tcd.ie> Date: Mon, 06 Jun 2011 12:41:34 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Arturo Servin References: <4DEA6323.4070302@cs.tcd.ie> <20110605031045.GK88250@verdi> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , ipv6@ietf.org, saag@ietf.org, John Leslie Subject: Re: [saag] ITU-T SG17 IPv6 security work items liaison X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 11:41:41 -0000 On 05/06/11 21:30, Arturo Servin wrote: > > I do not see why the ITU has to start from zero. What Eliot said. > There are several (or some at least) very good RFC and I+D documents related to IPv6 security. Sure. Feel free to send RFC numbers and we'll include some in the draft response that we'll circulate in a while. (So no need to spam everyone with those, just sending your suggestions to Eliot, Sean and I will be enough.) Thanks, S. > I think we should recommend them to ITU, it is good that they let us know, it would be better if they use our work as a foundation. > > just my 20 cents > -as > > > On 5 Jun 2011, at 00:10, John Leslie wrote: > >> Stephen Farrell wrote: >>> >>> We received a liaison [1] from ITU-T saying they're >>> planning to start a couple of work items on the >>> security of IPv6. As far as we know, they envisage >>> developing a "technical guideline on deploying IPv6" >>> and "Security Management Guideline for implementation >>> of IPv6 environment in telecommunications >>> organizations." Bear in mind that they're just starting >>> so they know about as much as we would just before a >>> BoF or something like that. >>> >>> I think we'd like to respond to them that that's great, >>> and we'll be interested in their results, but can they >>> *please* come back to us before saying something should >>> be changed so's we can talk about it. >> >> I don't think that's quite right. We should welcome their studying >> security issues; but I think we need to _strongly_ encourage them to >> start from draft-ietf-6man-node-req-bis when it becomes an RFC -- since >> it has _significant_ changes from RFC 4294 (and an ITU-T study based >> on RFC4294 will be of rather limited value). >> >> Furthermore, ITU-T should NOT propose "changes" to IPv6 protocol >> or the Node Requirements. The language there should talk of documenting >> security "concerns" or "issues" or whatever term seems neutral enough; >> and list as the next step exchanging ideas of what "changes" might help. >> >> Clearly, ITU-T is entirely justified in publishing recommendations >> of what level of security-related-trust to place in IPv6 packet >> forwarding: but any protocol _changes_ are outside their bailiwick. >> >> (As an aside, IETF should resist most proposals for change until >> IPv6 sees widespread deployment -- deploying to a moving target is >> just TOO risky.) >> >> -- >> John Leslie >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > From bkihara.l@gmail.com Tue Jun 7 03:09:26 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C682411E80C4; Tue, 7 Jun 2011 03:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvnhDgiyA-kw; Tue, 7 Jun 2011 03:09:26 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2879711E80BF; Tue, 7 Jun 2011 03:09:26 -0700 (PDT) Received: by pwi5 with SMTP id 5so2893093pwi.31 for ; Tue, 07 Jun 2011 03:09:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=r1sHsORBGJUl1zuAXFf0vNvc3svdFmbZ3pj+423sxUQ=; b=m5g80NQo+cZGXo7GQ3niMzh/3TUIf3a3BFBabP1EoOUnD0p9TLwchA14NXRGdRVKly oKEbGvrW4Di298cnsMsYKuXOj8zWtM+iTBb/2qBCUu2If+kMSVmYiU8myvOgDxjv4IDo Rqm2dobVVJzo6BivHkfo2bBjMWMUQ1lRrTx0g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=V786vpDuw6ktQcsrXSmiLUmtoWyZySIEWy99/XQmuJDVrcSzkBzV73ZGJMSebu/aqA N8D9ZCJwkyEmGdaA9cGCplOFLLoZfQERL/DT6Ex+S7gxr5QZjK89CZtL5gKvW+Bi2/6k CH1fNirDyvX/mnyHUUAqFBuMUDM96UxjpA20Q= MIME-Version: 1.0 Received: by 10.142.248.35 with SMTP id v35mr38393wfh.245.1307441365610; Tue, 07 Jun 2011 03:09:25 -0700 (PDT) Received: by 10.142.164.3 with HTTP; Tue, 7 Jun 2011 03:09:25 -0700 (PDT) In-Reply-To: References: Date: Tue, 7 Jun 2011 19:09:25 +0900 Message-ID: From: "KIHARA, Boku" To: saag@ietf.org, websec@ietf.org, oauth@ietf.org, public-identity@w3.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [saag] Fwd: [http-auth] REST-GSS I-D posted X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 10:09:26 -0000 FYI ---------- Forwarded message ---------- From: Nico Williams Date: 2011/6/7 Subject: [http-auth] REST-GSS I-D posted To: http-auth@ietf.org http://www.ietf.org/id/draft-williams-rest-gss-00.txt This is to go with the slides and paper presented almost two weeks ago at the W3C workshop on identity in the browser: http://www.w3.org/2011/identity-ws/agenda.html I would like to add some co-authors. =A0Anyone interested? Cheers, Nico -- _______________________________________________ http-auth mailing list http-auth@ietf.org https://www.ietf.org/mailman/listinfo/http-auth From fernando.gont.netbook.win@gmail.com Tue Jun 7 06:32:00 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61E1011E8101; Tue, 7 Jun 2011 06:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.607 X-Spam-Level: X-Spam-Status: No, score=-2.607 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YbodLpky5zOb; Tue, 7 Jun 2011 06:31:59 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 556CA11E808E; Tue, 7 Jun 2011 06:31:59 -0700 (PDT) Received: by gxk19 with SMTP id 19so2638489gxk.31 for ; Tue, 07 Jun 2011 06:31:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=Gs/07prDImCcX7YegUVdeujV3T0/S0uzggVg7GZJej0=; b=NUF+z20w5mwP4OXwXwKEBZf9WFcgCGFnpzKkkFGNodHPEQzbtieJkN4DuR7Ic4ZU6R btg6xBbwkEAN50xEySR4YpTNUJwAxmtTcTbDYyUEd+Hlm6orz1XL7UOZnuqQOC9Nrfyy I3LkbuK0/C3Rf4OuQko4dtsSATv2N5xgqtfwI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=c71AKdoXA6PEXOwiqk4ueAoH3jPSqvbdAppM70USwO9/HW2UcAoqC05P8ELegsHw2P 6Oe2SWgeJJSvpuJgra1Duidj6/KI97UqInoTptUhB4vSCqT+NIDNYLYBo/0ZMZnu9Alm eb7Uyy+putwYdU1pePgKDSvUIZtzPmllzM0GE= Received: by 10.101.2.25 with SMTP id e25mr4862704ani.28.1307453518777; Tue, 07 Jun 2011 06:31:58 -0700 (PDT) Received: from [192.168.1.102] ([190.190.97.123]) by mx.google.com with ESMTPS id w19sm4069026anf.38.2011.06.07.06.31.52 (version=SSLv3 cipher=OTHER); Tue, 07 Jun 2011 06:31:57 -0700 (PDT) Sender: Fernando Gont Message-ID: <4DED7DB2.6080802@gont.com.ar> Date: Mon, 06 Jun 2011 22:24:02 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: John Leslie References: <4DEA6323.4070302@cs.tcd.ie> <20110605031045.GK88250@verdi> In-Reply-To: <20110605031045.GK88250@verdi> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, ipv6@ietf.org, "saag@ietf.org" Subject: Re: [saag] ITU-T SG17 IPv6 security work items liaison X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 13:32:00 -0000 On 06/05/2011 12:10 AM, John Leslie wrote: >> I think we'd like to respond to them that that's great, >> and we'll be interested in their results, but can they >> *please* come back to us before saying something should >> be changed so's we can talk about it. > > I don't think that's quite right. We should welcome their studying > security issues; but I think we need to _strongly_ encourage them to > start from draft-ietf-6man-node-req-bis when it becomes an RFC -- since > it has _significant_ changes from RFC 4294 (and an ITU-T study based > on RFC4294 will be of rather limited value). While I have not read the latest version of the aforementioned I-D, I don't think it address (nor should it) the security implications of IPv6. As a simply example, while there has been some work on the security implications of transition/co-existence technologies, I don't think there have been e.g. best practices published on e.g. how to filter them (in those environments in which the use of technologies such as Teredo is undesirable). Additionally, I don't think there has been much work on which tools could be used (and how) to perform network monitoring (e.g., use NDPMon to monitor ND-based attacks). > Clearly, ITU-T is entirely justified in publishing recommendations > of what level of security-related-trust to place in IPv6 packet > forwarding: but any protocol _changes_ are outside their bailiwick. Agreed. However (and with no clue about what ITU-T is planning to work on) I guess there's room for recommendations on what stuff to filter, specific features that should be enabled/disabled, etc. > (As an aside, IETF should resist most proposals for change until > IPv6 sees widespread deployment -- deploying to a moving target is > just TOO risky.) While I do see some value in this point (and I'm aware there are many that share this point of view), I think this argument does not necessarily apply to security. If a flaw is identified, and there's a concrete proposal to mitigate it, I don't think it would be a good idea to resist to *this* type of change/update. Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From turners@ieca.com Tue Jun 7 07:47:38 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D39311E814A for ; Tue, 7 Jun 2011 07:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.226 X-Spam-Level: X-Spam-Status: No, score=-102.226 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wrgd0tEFdXz for ; Tue, 7 Jun 2011 07:47:37 -0700 (PDT) Received: from nm4.access.bullet.mail.sp2.yahoo.com (nm4.access.bullet.mail.sp2.yahoo.com [98.139.44.131]) by ietfa.amsl.com (Postfix) with SMTP id B8F5911E810C for ; Tue, 7 Jun 2011 07:47:37 -0700 (PDT) Received: from [98.139.44.106] by nm4.access.bullet.mail.sp2.yahoo.com with NNFMP; 07 Jun 2011 14:47:37 -0000 Received: from [98.139.44.79] by tm11.access.bullet.mail.sp2.yahoo.com with NNFMP; 07 Jun 2011 14:47:37 -0000 Received: from [127.0.0.1] by omp1016.access.mail.sp2.yahoo.com with NNFMP; 07 Jun 2011 14:47:37 -0000 X-Yahoo-Newman-Id: 641444.64933.bm@omp1016.access.mail.sp2.yahoo.com Received: (qmail 12167 invoked from network); 7 Jun 2011 14:47:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1307458057; bh=DPWQq89x7mI0yT66kFRHsjwnOxRV2TyI1Afn1RjzoOE=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=5P7xIDlu6i5L51W2Xx5KLQh2aP+STOT/dJMhCJ5fx/lQVeUouImLjvvZNnN1bKffffaGoEYQYMtu9brng5FjoITeBvzbo/1fAsSg8kogmU6bzgc0VKHEgtzGXHEhyPtLd4/0EY5hqw846CbJR6VBE++lBD8eZw+SqMXKBlR0GJI= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: GJmL0jgVM1nVQsWfhGlpEkP.S3ucb5CXdc9mNR3O8g2jDWt ApfD5eHAbNc6.imMJhlDXzB8BJZw7dQbxAtJ_WlC.OnjD8Yr.3v0tyJRTGH. LzcfUKOs4sIhJ1jwm6OsZwBsqDuve0DEQYBC7kmdvCLxGrQ.jUo6IhMFPdUP _HmbwVZ6qEWGPnRwCzs85u1bVN.oALFfzpmcjP9s7MBL.apH6W2ZYBdovDX7 .sNfM.VkrIWABjM78tPBOIsGpeWPB4hyO0wYETthHVc9O805YssGpz1VbwHD VdMJ1F2viymv2oUzSAEja_C1gEt17EjtvDIamlaFZAsmCppcWTEIzU8wPeTO SmknIRdKw.LmxBmVrajIp1bvHQ4FRM6bjZWsomxSn X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ Received: from thunderfish.local (turners@96.231.121.181 with plain) by smtp113.biz.mail.sp1.yahoo.com with SMTP; 07 Jun 2011 07:47:36 -0700 PDT Message-ID: <4DEE3A07.9010208@ieca.com> Date: Tue, 07 Jun 2011 10:47:35 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: "saag@ietf.org" References: <4D9B2C20.6020604@cs.tcd.ie> In-Reply-To: <4D9B2C20.6020604@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [saag] Pick a saag presentation for Quebec... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 14:47:38 -0000 We've not had any takers on this offer. We're still willing to entertain topics. Don't be shy ;) spt On 4/5/11 10:50 AM, Stephen Farrell wrote: > > And while we're filling the saag folder. I'm sure we've all > noted the general warmth with which many saag presentations > have been greeted over the years:-) > > Next time, as an experiment, we'd like you to pick one of > them. > > So, please send suggestions to the list, for topic and > optionally presenter, ideally with the presenter's > agreement, for a 20-30 minute slot and we'll see what > folks here want to hear/talk about and whether we can > arrange that. > > I guess suggestions before say June 5th should give us > enough time to get stuff sorted. We'll figure some way > to let you all help pick one after that. > > If this works ok, we'll keep it up. If not, then we > won't. If we need to tweak things to make it work then > we'll do that. > > Please keep the subject line intact for suggestions and > discussions about picking a presentation. If discussion > wanders off into the meat of a topic, then start a new > thread. > > Thanks, > Stephen. > > PS: Don't worry - the ADs will still pick some topics, so > you won't lose the opportunity to ask how we could > possibly be so dumb:-) > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From tlr@w3.org Tue Jun 7 07:53:40 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC4E111E8132 for ; Tue, 7 Jun 2011 07:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MB6ethSO+SP6 for ; Tue, 7 Jun 2011 07:53:40 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 276D011E8119 for ; Tue, 7 Jun 2011 07:53:40 -0700 (PDT) Received: from [88.207.143.141] (helo=[192.168.2.114]) by jay.w3.org with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1QTxes-0005SJ-Qw; Tue, 07 Jun 2011 10:53:31 -0400 From: Thomas Roessler Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Jun 2011 16:53:27 +0200 Message-Id: <82E4BE68-98DC-4CE4-886E-007CEB55E14E@w3.org> To: saag@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: Frederick Hirsch Subject: [saag] Request for Review of XML Signature 2.0 and Canonicalization 2.0 specifications X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 14:53:41 -0000 The W3C XML Security Working Group has issued Last Call Working Drafts = of XML Signature 2.0 and Canonical XML 2.0. These specifications are = intended to address XML-related performance and attack surface issues. Working Drafts here: http://www.w3.org/TR/xmldsig-core2/ http://www.w3.org/TR/xml-c14n2/ While the formal Last Call period has ended on 31 May, the WG is = prepared to accept reviews until 5 July. Regards, -- Thomas Roessler, W3C (@roessler) From yutaka@g.oiwa.jp Sat May 21 22:25:07 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 424EBE0662; Sat, 21 May 2011 22:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4HOrYcoMCNgB; Sat, 21 May 2011 22:25:06 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 43584E0618; Sat, 21 May 2011 22:25:05 -0700 (PDT) Received: by pzk5 with SMTP id 5so3055734pzk.31 for ; Sat, 21 May 2011 22:25:05 -0700 (PDT) Received: by 10.68.16.3 with SMTP id b3mr1636170pbd.483.1306041905277; Sat, 21 May 2011 22:25:05 -0700 (PDT) Received: from [119.107.196.233] (wf01-119-107-196-233.uqwimax.jp [119.107.196.233]) by mx.google.com with ESMTPS id q2sm3521273pbk.49.2011.05.21.22.25.01 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 21 May 2011 22:25:04 -0700 (PDT) Sender: Yutaka OIWA Message-ID: <4DD89E2E.9040709@aist.go.jp> From: Yutaka OIWA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "http-auth@ietf.org" Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 07 Jun 2011 09:05:31 -0700 Cc: "saag@ietf.org" Subject: [saag] Identity in Browser, and HTTP-auth preparation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Sun, 22 May 2011 18:10:17 -0000 X-Original-Date: Sun, 22 May 2011 14:25:02 +0900 X-List-Received-Date: Sun, 22 May 2011 18:10:17 -0000 Dear all, I'd like to restart preparing for the HTTP-auth BoF in IETF. Sorry for our slow progress. I'm now heading to San Francisco from Tokyo for the W3C identity in browser workshop, where our and others' related topics about Web identity will be presented. I'd like to have some more discussion for our strategy there. We're preparing our problem statement straw-man document, and I'd like to release it soon after IIB, possibly reflecting some of discussed topics in the workshop. I'll also attend OAuth interim meeting tomorrow, so please contact me if it is more preferable. Yutaka -- Yutaka OIWA, Ph.D. Research Scientist Research Center for Information Security (RCIS) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] From john@jlc.net Sat Jun 4 20:10:53 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC5D11E8088; Sat, 4 Jun 2011 20:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wHeI-wCxaHm; Sat, 4 Jun 2011 20:10:52 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2F211E8077; Sat, 4 Jun 2011 20:10:46 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id ED3AA33C21; Sat, 4 Jun 2011 23:10:45 -0400 (EDT) Date: Sat, 4 Jun 2011 23:10:45 -0400 From: John Leslie To: Stephen Farrell Message-ID: <20110605031045.GK88250@verdi> References: <4DEA6323.4070302@cs.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DEA6323.4070302@cs.tcd.ie> User-Agent: Mutt/1.4.1i X-Mailman-Approved-At: Tue, 07 Jun 2011 09:05:31 -0700 Cc: v6ops@ietf.org, ipv6@ietf.org, "saag@ietf.org" Subject: Re: [saag] ITU-T SG17 IPv6 security work items liaison X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2011 03:10:53 -0000 Stephen Farrell wrote: > > We received a liaison [1] from ITU-T saying they're > planning to start a couple of work items on the > security of IPv6. As far as we know, they envisage > developing a "technical guideline on deploying IPv6" > and "Security Management Guideline for implementation > of IPv6 environment in telecommunications > organizations." Bear in mind that they're just starting > so they know about as much as we would just before a > BoF or something like that. > > I think we'd like to respond to them that that's great, > and we'll be interested in their results, but can they > *please* come back to us before saying something should > be changed so's we can talk about it. I don't think that's quite right. We should welcome their studying security issues; but I think we need to _strongly_ encourage them to start from draft-ietf-6man-node-req-bis when it becomes an RFC -- since it has _significant_ changes from RFC 4294 (and an ITU-T study based on RFC4294 will be of rather limited value). Furthermore, ITU-T should NOT propose "changes" to IPv6 protocol or the Node Requirements. The language there should talk of documenting security "concerns" or "issues" or whatever term seems neutral enough; and list as the next step exchanging ideas of what "changes" might help. Clearly, ITU-T is entirely justified in publishing recommendations of what level of security-related-trust to place in IPv6 packet forwarding: but any protocol _changes_ are outside their bailiwick. (As an aside, IETF should resist most proposals for change until IPv6 sees widespread deployment -- deploying to a moving target is just TOO risky.) -- John Leslie From fred@cisco.com Sat Jun 4 23:10:28 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3B6E21F849E; Sat, 4 Jun 2011 23:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8H3oCAwa3c5W; Sat, 4 Jun 2011 23:10:28 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC5921F849C; Sat, 4 Jun 2011 23:10:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1273; q=dns/txt; s=iport; t=1307254228; x=1308463828; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=E+G5E4waGRozGgDTvx/8cuWzmvINw4JL+cVxXGBxqHY=; b=jkOfpEIAA67lx14v9243aKouM1YKn+9NoHflHuVfQjdB1p68WOFS1f1G GCk6sRNvIM888qaQBInQBiTRY7HfytSMOcbckfZUmNijScA+VIhTFwxra CLxgaPhrNF+nc0v4ckNFRakyJo8MoNOmhyvkyhPsCYrkfWiswIA7l2HSu Q=; X-IronPort-AV: E=Sophos;i="4.65,321,1304294400"; d="scan'208";a="459906997" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-1.cisco.com with ESMTP; 05 Jun 2011 06:10:26 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p556ALrJ003107; Sun, 5 Jun 2011 06:10:26 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Sat, 04 Jun 2011 23:10:26 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Sat, 04 Jun 2011 23:10:26 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <4DEA6323.4070302@cs.tcd.ie> Date: Sat, 4 Jun 2011 23:10:11 -0700 Message-Id: References: <4DEA6323.4070302@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 07 Jun 2011 09:05:31 -0700 Cc: v6ops@ietf.org, ipv6@ietf.org, "saag@ietf.org" Subject: Re: [saag] [v6ops] ITU-T SG17 IPv6 security work items liaison X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2011 06:10:28 -0000 On Jun 4, 2011, at 9:53 AM, Stephen Farrell wrote: > I think we'd like to respond to them that that's great, > and we'll be interested in their results, but can they > *please* come back to us before saying something should > be changed so's we can talk about it. That seems like a reasonable proposal.=20 There a, of course, several proposed sets of security guidelines for = IPv6 floating in the breeze. If you want my druthers, I would like to = see a comprehensive security *architecture*. Steve Kent wrote to me last = month, on another topic, saying > I do have a few comments about the discuss of secruity, in general. I = see that you used the CIA model for describing security = requirements/services. Although this is a commonly used model, I find it = inferior to the model that was developed by ISO in the mid 80's (ISO = 7498-2). It might be worthwhile to look at the ISO model he suggests as a = possible starting point.=20 To my mind, anything resembling a security architecture will identify = threats at the physical, link, network (LAN and IP), transport, and = applications layers, and make recommendations for addressing them - and = not start from the premise of a global federated identity, which doesn't = exist.= From fred@cisco.com Sat Jun 4 23:33:41 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8955711E808C; Sat, 4 Jun 2011 23:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyAWNNSOAZEj; Sat, 4 Jun 2011 23:33:40 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6CA11E8072; Sat, 4 Jun 2011 23:33:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1585; q=dns/txt; s=iport; t=1307255620; x=1308465220; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=gBI06pG8hja0PoRnlP78Ei2x232f8DDCsM2JN7aXahQ=; b=gLEckFLJxIGOLx3ipwVvBPhVAXX1gxndLw/JV0iOTfMewyopSg0VG7ng ZXFXXeUpnVBqJ6cDwxOy/j0Tf33lnPk1T0878KfjIgUVLTQvPjHy/WEMV i104iuQAFo26xVAL8BMxPoJ/QLjlfYJMx+14SoyuUqnJYEq5iF4RIv8ON g=; X-IronPort-AV: E=Sophos;i="4.65,321,1304294400"; d="scan'208";a="330349821" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-3.cisco.com with ESMTP; 05 Jun 2011 06:33:40 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p556XYgD019240; Sun, 5 Jun 2011 06:33:39 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Sat, 04 Jun 2011 23:33:40 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Sat, 04 Jun 2011 23:33:40 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Sat, 4 Jun 2011 23:33:24 -0700 Message-Id: <1B36FABA-D389-4804-A45B-8F49BD7D8ECB@cisco.com> References: <4DEA6323.4070302@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 07 Jun 2011 09:05:31 -0700 Cc: 6man Mailing List , IPv6 Operations Working Group , saag@ietf.org Subject: Re: [saag] [v6ops] ITU-T SG17 IPv6 security work items liaison X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2011 06:33:41 -0000 BTW, in case it wasn't clear, I think the IETF should do that = architecture. On Jun 4, 2011, at 11:10 PM, Fred Baker wrote: >=20 > On Jun 4, 2011, at 9:53 AM, Stephen Farrell wrote: >=20 >> I think we'd like to respond to them that that's great, >> and we'll be interested in their results, but can they >> *please* come back to us before saying something should >> be changed so's we can talk about it. >=20 > That seems like a reasonable proposal.=20 >=20 > There a, of course, several proposed sets of security guidelines for = IPv6 floating in the breeze. If you want my druthers, I would like to = see a comprehensive security *architecture*. Steve Kent wrote to me last = month, on another topic, saying >=20 >> I do have a few comments about the discuss of secruity, in general. I = see that you used the CIA model for describing security = requirements/services. Although this is a commonly used model, I find it = inferior to the model that was developed by ISO in the mid 80's (ISO = 7498-2). >=20 > It might be worthwhile to look at the ISO model he suggests as a = possible starting point.=20 >=20 > To my mind, anything resembling a security architecture will identify = threats at the physical, link, network (LAN and IP), transport, and = applications layers, and make recommendations for addressing them - and = not start from the premise of a global federated identity, which doesn't = exist. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From arturo.servin@gmail.com Sun Jun 5 13:31:04 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A34221F84BC; Sun, 5 Jun 2011 13:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gmi-9yfQfRU; Sun, 5 Jun 2011 13:31:03 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id DCBC521F84BB; Sun, 5 Jun 2011 13:30:59 -0700 (PDT) Received: by wyb29 with SMTP id 29so2873179wyb.31 for ; Sun, 05 Jun 2011 13:30:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=JhPE23+t/7g7fRBD7ic0InIjd0Ip/qZ8bHxVe6CqBUA=; b=mo+YtVdGIqwjxyPWBBTOSSxIfWbPu6A86dNtxTqyKECRu+MtSJBIMYoXVRH8EmIOBW vvhZ755aO489tA/rKl4RrQl2yD6s9yhOxOSVRxY+DEpwlCiMpypoiloTy9mgu+cD8ihJ 4jlAwMezf+ernZj4WBiXhl4tODfmIokZmE7Ks= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=Qg/zxP9mxtVjNY0tzA192wyWjN5C9iy1rXZKdnlbVX/w6fyjjiv85uOS8wwuS3S+vn j1NNbnVSsti8E/DpczqSWfVbeEIFYe5wIwD6Hn8Xj/hI68eG/cYRYAqPHQpAdREirBE9 cc6MoxNgrtUMkZopx++H2PSIXP6dgfftHlKAE= Received: by 10.227.57.148 with SMTP id c20mr4231397wbh.54.1307305858776; Sun, 05 Jun 2011 13:30:58 -0700 (PDT) Received: from [10.225.103.220] ([83.111.212.208]) by mx.google.com with ESMTPS id o38sm2424267wba.3.2011.06.05.13.30.56 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 05 Jun 2011 13:30:58 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Arturo Servin In-Reply-To: <20110605031045.GK88250@verdi> Date: Sun, 5 Jun 2011 17:30:54 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DEA6323.4070302@cs.tcd.ie> <20110605031045.GK88250@verdi> To: IPv6 Operations , ipv6@ietf.org X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Tue, 07 Jun 2011 09:05:31 -0700 Cc: John Leslie , saag@ietf.org Subject: Re: [saag] ITU-T SG17 IPv6 security work items liaison X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2011 20:31:04 -0000 I do not see why the ITU has to start from zero. There are = several (or some at least) very good RFC and I+D documents related to = IPv6 security. I think we should recommend them to ITU, it is good that = they let us know, it would be better if they use our work as a = foundation. just my 20 cents -as On 5 Jun 2011, at 00:10, John Leslie wrote: > Stephen Farrell wrote: >>=20 >> We received a liaison [1] from ITU-T saying they're >> planning to start a couple of work items on the >> security of IPv6. As far as we know, they envisage >> developing a "technical guideline on deploying IPv6" >> and "Security Management Guideline for implementation >> of IPv6 environment in telecommunications >> organizations." Bear in mind that they're just starting >> so they know about as much as we would just before a >> BoF or something like that. >>=20 >> I think we'd like to respond to them that that's great, >> and we'll be interested in their results, but can they >> *please* come back to us before saying something should >> be changed so's we can talk about it. >=20 > I don't think that's quite right. We should welcome their studying > security issues; but I think we need to _strongly_ encourage them to > start from draft-ietf-6man-node-req-bis when it becomes an RFC -- = since > it has _significant_ changes from RFC 4294 (and an ITU-T study based > on RFC4294 will be of rather limited value). >=20 > Furthermore, ITU-T should NOT propose "changes" to IPv6 protocol > or the Node Requirements. The language there should talk of = documenting > security "concerns" or "issues" or whatever term seems neutral enough; > and list as the next step exchanging ideas of what "changes" might = help. >=20 > Clearly, ITU-T is entirely justified in publishing recommendations > of what level of security-related-trust to place in IPv6 packet > forwarding: but any protocol _changes_ are outside their bailiwick. >=20 > (As an aside, IETF should resist most proposals for change until > IPv6 sees widespread deployment -- deploying to a moving target is > just TOO risky.) >=20 > -- > John Leslie > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From hhalpin@w3.org Sun Jun 5 14:32:55 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F00AE21F8502; Sun, 5 Jun 2011 14:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4aDtcp3IEv-J; Sun, 5 Jun 2011 14:32:54 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 6296121F8500; Sun, 5 Jun 2011 14:32:53 -0700 (PDT) Received: from www-data by jay.w3.org with local (Exim 4.69) (envelope-from ) id 1QTKw8-0004Ua-Eq; Sun, 05 Jun 2011 17:32:44 -0400 Received: from 87.149.171.109 (SquirrelMail authenticated user hhalpin) by webmail-mit.w3.org with HTTP; Sun, 5 Jun 2011 22:32:44 +0100 (BST) Message-ID: <6cdda6a1c5901b19823e4e2cf54b7e90.squirrel@webmail-mit.w3.org> In-Reply-To: <878vtgfbs1.fsf@bluewind.rcis.aist.go.jp> References: <878vtgfbs1.fsf@bluewind.rcis.aist.go.jp> Date: Sun, 5 Jun 2011 22:32:44 +0100 (BST) From: "Harry Halpin" To: http-auth@ietf.org, y.oiwa@aist.go.jp User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mailman-Approved-At: Tue, 07 Jun 2011 09:05:31 -0700 Cc: Harry Halpin , public-identity@w3.org, websec@ietf.org, saag@ietf.org Subject: Re: [saag] re-call for IETF http-auth BoF X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2011 21:32:55 -0000 > Dear all at http-auth mailing list, > (Cc: Peter, Sean, Harry, and related mailing lists subscribers) > > following the discussions in the Prague http-auth Bar-BoF in March, > and the W3C Identity in Browser workshop in the last month, now I > would like to re-call the formation of BoF for http-auth in IETF. The > workshop was really hot and enjoying, and there were so many useful > inputs to both Web community and IETF, I believe. Some materials > presented and discussed there are available at > . > > # Harry, are the *output* materials ofn the workshop already available to > public? > The workshop already links to all papers and slides on the website. There will be a final report released in about 2 weeks. The public-identity@w3.org will be list I use to get input to the draft final report, to join email "subscribe" in subject line to public-identity-request@w3.org. From my memory there was interest in MutualAuth, primarily from the financial industry and banks, who really did seem to want it. The browser vendors were of course skeptical of anything in chrome, but other discussions such as Dirk Balfanz's do to auth in the OS layer could provide an alternative. [1] http://www.w3.org/2011/identity-ws/ > Currently I'm preparing a start-up version of problem statement document > and > proposed BoF agenda. However, very unfortunately, the last week I had a > severe fever heat and could not work well (I'm really sorry about that). > I'm going to submit them to the list within two days, and if possible > comments to the last version of the agenda proposal, available at > , > are welcome. I'm currently working based on that. > > Thanks, > > Yutaka > > -- > Yutaka OIWA, Ph.D. Research > Scientist > Research Center for Information Security > (RCIS) > National Institute of Advanced Industrial Science and Technology > (AIST) > Mail addresses: , > > OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 > 46B5] > > From Marcus.Williams@ed.gov Mon Jun 6 05:58:59 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D517E11E8133; Mon, 6 Jun 2011 05:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HhOUReTY2FiE; Mon, 6 Jun 2011 05:58:58 -0700 (PDT) Received: from exprod8og109.obsmtp.com (exprod8og109.obsmtp.com [64.18.3.98]) by ietfa.amsl.com (Postfix) with ESMTP id C5F7211E813A; Mon, 6 Jun 2011 05:58:50 -0700 (PDT) Received: from eduptcexmr01.ed.gov ([160.109.63.134]) (using TLSv1) by exprod8ob109.postini.com ([64.18.7.12]) with SMTP ID DSNKTezPCDt5UDjv8KpyC7/7hKf9QEZqoPtb@postini.com; Mon, 06 Jun 2011 05:58:58 PDT Received: from eduptcexhb02.ed.gov (eduptcexhb02.ed.gov [165.224.52.34]) by eduptcexmr01.ed.gov (8.13.8/8.13.8) with ESMTP id p56CwkdX002512 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Mon, 6 Jun 2011 07:58:46 -0500 Received: from EDUPTCEXMB02.ed.gov ([165.224.52.20]) by eduptcexhb02.ed.gov ([165.224.52.34]) with mapi; Mon, 6 Jun 2011 07:58:46 -0500 From: "Williams, Marcus (Contractor)" To: Stephen Farrell , Arturo Servin Date: Mon, 6 Jun 2011 07:58:43 -0500 Thread-Topic: [v6ops] ITU-T SG17 IPv6 security work items liaison Thread-Index: AcwkPt1LDZw3bbl2TWqChG/iXIKbYgACZ7YA Message-ID: References: <4DEA6323.4070302@cs.tcd.ie> <20110605031045.GK88250@verdi> <4DECBCEE.6070108@cs.tcd.ie> In-Reply-To: <4DECBCEE.6070108@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 07 Jun 2011 09:05:31 -0700 Cc: IPv6 Operations , "ipv6@ietf.org" , "saag@ietf.org" , John Leslie Subject: Re: [saag] [v6ops] ITU-T SG17 IPv6 security work items liaison X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 12:58:59 -0000 > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Stephen Farrell > Sent: Monday, June 06, 2011 7:42 AM > Sure. Feel free to send RFC numbers and we'll include > some in the draft response that we'll circulate in a > while. (So no need to spam everyone with those, just > sending your suggestions to Eliot, Sean and I will be > enough.) There are a number of RFCs including 4291 already referenced in this NIST S= pecial Publication 800-119, Guidelines for the Secure Deployment of IPv6: http://csrc.nist.gov/publications/PubsDrafts.html#800-119 Marcus Williams, CISSP From kwatsen@juniper.net Wed Jun 8 16:44:26 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A6AE21F8518 for ; Wed, 8 Jun 2011 16:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ae2AsjZE-Olr for ; Wed, 8 Jun 2011 16:44:25 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id C074621F8515 for ; Wed, 8 Jun 2011 16:44:23 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKTfAJVyuVuRmo/lWt6RjQUgGyLfP9dh11@postini.com; Wed, 08 Jun 2011 16:44:25 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Wed, 8 Jun 2011 16:43:55 -0700 From: Kent Watsen To: "saag@ietf.org" , "ietf-ssh@NetBSD.org" Date: Wed, 8 Jun 2011 16:43:52 -0700 Thread-Topic: draft-kwatsen-reverse-ssh-01 submission for review Thread-Index: AcwmNexl1MkTfarBS+uDUm42L3SQIQ== Message-ID: <84600D05C20FF943918238042D7670FD3E81EA1164@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [saag] draft-kwatsen-reverse-ssh-01 submission for review X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 23:44:26 -0000 I've updated the Reverse SSH draft per suggestions: - now uses IANA-assigned SSH port 22 - now defines proper client and server roles (Reverse SSH client, Rever= se SSH server) - now uses in-band negotiation to automatically authenticate the SSH Se= rver's host key=20 Key aspects used to achieve this update include: - contextual awareness to set SSH client/server roles - definition of a new family of public host key algorithms (hmac-*) My own thoughts: - I like how now the host key and MAC algorithm are negotiated for hmac= -* use - I'm glad to find a solution minimizing the impact to existing SSH imp= lementations Link: - http://tools.ietf.org/html/draft-kwatsen-reverse-ssh-01 Thanks, Kent From jhutz@cmu.edu Wed Jun 8 19:51:57 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88E7021F858B for ; Wed, 8 Jun 2011 19:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0EerYV0+i6L for ; Wed, 8 Jun 2011 19:51:56 -0700 (PDT) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by ietfa.amsl.com (Postfix) with ESMTP id DDF3A21F858A for ; Wed, 8 Jun 2011 19:51:55 -0700 (PDT) Received: from [128.2.184.182] (JHUTZ-DYN5.PC.CS.CMU.EDU [128.2.184.182]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id p592ppf9023824 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Jun 2011 22:51:51 -0400 (EDT) From: Jeffrey Hutzelman To: Kent Watsen In-Reply-To: <965_1307576669_p58NiSYT016404_84600D05C20FF943918238042D7670FD3E81EA1164@EMBX01-HQ.jnpr.net> References: <965_1307576669_p58NiSYT016404_84600D05C20FF943918238042D7670FD3E81EA1164@EMBX01-HQ.jnpr.net> Content-Type: text/plain; charset="UTF-8" Date: Wed, 08 Jun 2011 22:51:51 -0400 Message-ID: <1307587911.7092.331.camel@destiny> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 Cc: "ietf-ssh@NetBSD.org" , "saag@ietf.org" Subject: Re: [saag] draft-kwatsen-reverse-ssh-01 submission for review X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 02:51:57 -0000 On Wed, 2011-06-08 at 16:43 -0700, Kent Watsen wrote: > I've updated the Reverse SSH draft per suggestions: > > - now uses IANA-assigned SSH port 22 > - now defines proper client and server roles (Reverse SSH client, Reverse SSH server) So, let's make sure I have this right. A device "calling home" is going to connect to some server on port 22, and expect the server to immediately pick up the role of being an SSH client? How is the server to distinguish between such a device and a normal ssh client being used by an admin who wants to log in to the server? Or by some other protocol that runs over ssh? I'm pretty sure I recall the discussion on this point involving some sort of negotiation, rather than a requirement that both sides know a priori which protocol variant they're going to speak. In fact, I seem to recall der Mouse suggesting use of a pre-kex extension packet to indicate this. > - definition of a new family of public host key algorithms (hmac-*) This is not the way to achieve what you're trying to do. Nor is specifying use of only particular host key algorithms, which rather badly breaks modularity. Further, what you've done doesn't actually buy anything. If the HMAC is precomputed before the device that will act as SSH server is deployed, then there is no operational advantage over X.509 certificates. On the other hand, if the HMAC is computed at the time of the connection, then both the client and server must know the key _and_ there must be a different key for each client/server pair (so one device cannot impersonate another). In which case, you may as well preshare per-device RSA keys instead of per-device HMAC keys. Except in cases like X.509 (where a host key is associated with a long-term signature by some trusted third party), SSH proves server identity and authenticates host keys as part of key exchange. If none of the already-defined KEX methods are suitable for your needs, then it might be possible to define a new one along the lines of what you've described. However, I seriously doubt its utility, for the reasons described above. It sounds to me like you really _don't_ want the device to be the SSH server at all; you only think you do. I suspect you really want the device to be the SSH _client_, except that once the connection is up, you want the server to open some sort of session to the client to execute commands, transfer files, run netconf or SNMP, or whatever. Interestingly, this role reversal -- allowing the SSH server to open sessions and run commands on the SSH client, requires no change to the SSH protocol at all. It simply requires that the client sit around waiting for a channel-open request from the server and accept it when it comes around. This is exactly the sort of situation in which it is appropriate to behave contrary to the SHOULD in RFC4254 section 6.1. FWIW, I'm fairly concerned about the hmac-* algorithms described in this document, which don't seem to provide any guarantee of freshness. I'm concerned that there is no description in this document as to how the SSH client is expected to authenticate itself to the device. This is fairly important, particularly since in the described deployment scenario, the device is likely about to give nearly unlimited power to the SSH client. Finally, I'm very concerned about the statements in the first paragraph of section 7, which assert that the proposed role reversal does not introduce any new security concerns. On the contrary, the proposed protocol is very nearly akin to calling someone up and saying "Give me your password", later followed by "by the way, I might be your bank". We've discussed "reverse SSH" ideas before*, and they haven't gained any traction. Part of the problem is that server and client authentication is not symmetric in the SSH protocol, and there is a basic assumption that a client knows a priori what server it intends to talk to, while the server does not know what client will be talking to it. Attempting to falsify this assumption and still have things work typically results in warping the protocol rather badly. I'm not saying a reverse SSH is not possible, and with a few more iterations this document might well become one. However, as mentioned above, I think it's probably not the right approach to solving the stated problem. -- Jeff From lear@cisco.com Wed Jun 8 22:33:07 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B14A21F84A0 for ; Wed, 8 Jun 2011 22:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZsvRqQSQX8X0 for ; Wed, 8 Jun 2011 22:33:06 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 307F821F849F for ; Wed, 8 Jun 2011 22:33:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=655; q=dns/txt; s=iport; t=1307597586; x=1308807186; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=P8X1sSVPHoI72pB0w8uskkKeewkCCdH8KYvo7YTPuxU=; b=Br+xBs8sDpjhKNxBvi/afZ7NpfX6xkBJFW0EaU5sD/XFOQG7w5sIhuLe IocS9UudQnDmPjc1uSDLCu8rnwzoPRUi4ZwNBD8QlFfkBox0OrmzVU2Qh GnjPFMFckAdifmHhNZ1i+m60TC9fCQPpXsfwY+lm1U0W5xKQKi3LGaMab 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALtZ8E2Q/khR/2dsb2JhbABSEIQ5oXB3qUSNH5EAgSuDboEKBJEqjx03 X-IronPort-AV: E=Sophos;i="4.65,340,1304294400"; d="scan'208";a="93034795" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 09 Jun 2011 05:33:05 +0000 Received: from dhcp-10-55-91-13.cisco.com (dhcp-10-55-91-13.cisco.com [10.55.91.13]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p595X47W004021; Thu, 9 Jun 2011 05:33:05 GMT Message-ID: <4DF05B10.3080703@cisco.com> Date: Thu, 09 Jun 2011 07:33:04 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Jeffrey Hutzelman References: <965_1307576669_p58NiSYT016404_84600D05C20FF943918238042D7670FD3E81EA1164@EMBX01-HQ.jnpr.net> <1307587911.7092.331.camel@destiny> In-Reply-To: <1307587911.7092.331.camel@destiny> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "ietf-ssh@NetBSD.org" , "saag@ietf.org" Subject: Re: [saag] draft-kwatsen-reverse-ssh-01 submission for review X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 05:33:07 -0000 Jeff, On 6/9/11 4:51 AM, Jeffrey Hutzelman wrote: > Interestingly, this role reversal -- allowing the SSH server to open > sessions and run commands on the SSH client, requires no change to the > SSH protocol at all. It simply requires that the client sit around > waiting for a channel-open request from the server and accept it when it > comes around. This is exactly the sort of situation in which it is > appropriate to behave contrary to the SHOULD in RFC4254 section 6.1. This is where my head has been on this issue. Why isn't this simply a matter of going contrary to the SHOULD (which I always thought was too strong)? Eliot From y.oiwa@aist.go.jp Thu Jun 9 07:32:05 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A61D611E80D2; Thu, 9 Jun 2011 07:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.22 X-Spam-Level: X-Spam-Status: No, score=0.22 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRSF5auJShTb; Thu, 9 Jun 2011 07:32:04 -0700 (PDT) Received: from mx1.aist.go.jp (mx1.aist.go.jp [150.29.246.133]) by ietfa.amsl.com (Postfix) with ESMTP id 206E811E808B; Thu, 9 Jun 2011 07:32:03 -0700 (PDT) Received: from rqsmtp2.aist.go.jp (rqsmtp2.aist.go.jp [150.29.254.123]) by mx1.aist.go.jp with ESMTP id p59EVvaL008115; Thu, 9 Jun 2011 23:31:57 +0900 (JST) env-from (y.oiwa@aist.go.jp) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=aist.go.jp; s=aist; t=1307629919; bh=u16ceoPm/IlX33yKZnBYTIYs6XdPEtqsSWqcKkgqocY=; h=From:Date:Message-ID; b=G8lemk+AekwTsTmib4Z0v6RV932tIWdhJP63QHC5g5sQuh0WIqDkEUhOvlb2Gdje7 GxpOQGbYKNilYKCfsuI71uw2JYdGeXlOYKx3UbuAuXF6TikjeKsgaO82WkgqAhjiSB r3qIuizE9QmRkk3rc20ah6LRduubS9bgc7uU20C8= Received: from smtp2.aist.go.jp by rqsmtp2.aist.go.jp with ESMTP id p59EVvWt023363; Thu, 9 Jun 2011 23:31:57 +0900 (JST) env-from (y.oiwa@aist.go.jp) Received: by smtp2.aist.go.jp with ESMTP id p59EVtXV012071; Thu, 9 Jun 2011 23:31:55 +0900 (JST) env-from (y.oiwa@aist.go.jp) To: http-auth@ietf.org References: <878vtgfbs1.fsf@bluewind.rcis.aist.go.jp> From: Yutaka OIWA Date: Thu, 09 Jun 2011 23:31:55 +0900 In-Reply-To: <878vtgfbs1.fsf@bluewind.rcis.aist.go.jp> (Yutaka OIWA's message of "Mon\, 06 Jun 2011 02\:06\:38 +0900") Message-ID: <87hb7zdqjo.fsf@bluewind.rcis.aist.go.jp> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Harry Halpin , public-identity@w3.org, websec@ietf.org, saag@ietf.org Subject: Re: [saag] re-call for IETF http-auth BoF X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: http-auth@ietf.org, y.oiwa@aist.go.jp List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 14:32:05 -0000 Dear all, Regarding http-auth, I finally updated the proposed BoF agenda. The text is appended to this mail. A "draft" of the problem statement document, referred to by the agenda, is currently available at . We're currently preparing an Internet-Draft formatted version. Comments for both documents are really welcome and appreciated. Cheers, --------- Description: The current authentication methods used in the Web system are prone to various serious vulnerabilities, including password eavesdropping, password stealing, session hijack, and phishing. Currently, the HTTP core protocol only provides basic plaintext password authentication and MD5-based hashed password authentication, both of which are insecure against eavesdropping and password dictionary attack. There are some other authentication protocols which integrate with existing authentication frameworks such as GSS and SASL, but these were not widely accepted outside the area where the frameworks are already used. TLS, which is the underlying transport of HTTPS, provides client certificate-based authentication but that has some but not massive use cases, mainly due to deployment and usability problems. Also, both current HTTP authentications and TLS client authentication lack several control features, which makes modern Web applications hard to deploy. For example, both authentication mechanisms do not have ability to dissolve authentication association (log-out) from the server side, nor ability to directly accept a guest (unauthenticated) user in the same URL as those for authenticated users. These lack of features make people tends to use HTML forms for authentication, which are by nature insecure against eavesdropping and Phishing attacks. Furthermore, although TLS has a almost-mandatory server authentication feature, it in the real world did not completely prevent impersonation attacks. To mitigate this, we should consider introduction of techniques which let users know by themselves whether the accessed server matches with their intentions, without relying on central authority or careful attentions of users. These problems should be solved as soon as possible to mitigate the impact of Web authentication-related frauds to the Internet users. However, to solve this problem, the resulting technologies should be carefully designed so that these will be well deployable to the real-world applications. Without this, we will end up with inventing one more useless technology, which is obviously unfortunate. Recently we have several new proposals for securing Web/HTTP authentications. In addition, we also have several proposed technologies in surrounding areas, such as delegated authorization (e.g. OAuth) or delegated authentication (OpenID). Combining those technologies with such secure authentication, with careful consideration about security binding, should contribute to the whole Web security improvements. Additionally, the work of the HTTPBIS working group is about to finish, and it will require some maintenance works for the HTTP existing authentication mechanism, at least the registrations to IANA. The purpose of the proposed BoF is to pursue creation of IETF working groups on various HTTP authentication issues. The possible topics of the future working group may include some of the following topics: * Introduction of much more secure authentication mechanisms as extensions to the HTTP, considering use with Web and non-Web accesses. These technologies should protect users from being stolen their authentication by malicious eavesdropper or phishers, or being impersonated by man-in-the-middle attacks, or forged authentication result by malicious servers. * Introduction of technologies which will enable more sophisticated use of HTTP authentication from recent Web applications. * Introduction of better secure authentication mechanisms which can be used with non-Web HTTP accesses with existing authentication frameworks. ("non-Web" here includes HTTP accesses made from scripting code running inside Web browsers.) * Introduction of proper channel-binding technologies to HTTP authentication layer, which can be combined with higher-layer authentication/authorization mechanisms. * Research on the secure and more easily usable ways of (possibly mutual) Web/HTML authentications using several kinds of authentication credentials, and required protocol-side support for them. * Maintenance of existing HTTP authentication extensions (other than Basic and Digest), either checking its httpbis-conformance or making it historic. * Proposing addition of the above authentication schemes to the IANA registry as proposed by httpbis new HTTP 1.1 specification. The working group should be careful about the impact of the introduced security mechanisms to privacy issues, as strong authentication sometimes conflicts with people's privacy concerns. Both BoF and possible future working group expect well coordination with W3C's effort on the related topics. It shall also be in coordination with related IETF working groups, including websec, abfab and oauth. BoF proposed agenda: * Discussions on HTTP authentication problem statement * Discussions for working group activity scope * Discussions for working group schedules (including handling of "research items") Logistical informations: BoF Chairs: TBD BOF Proponents: Harry Halpin, Yutaka OIWA, ... (TBD) People expected: 50 Length of session: 90min Conflicts to avoid: Working Groups in the APP and SEC areas WebEX: no Responsible AD: Peter Saint-Andre (tentative) Goal: to pursue creation of IETF working groups Drafts: http://tools.ietf.org/html/draft-oiwa-http-mutualauth-08; more to be added Mailing List: HTTP http-auth mailing list Mailing List Archive: http://www.ietf.org/mail-archive/web/http-auth/ -------- -- Yutaka OIWA, Ph.D. Research Scientist Research Center for Information Security (RCIS) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] From llynch@civil-tongue.net Wed Jun 8 11:20:39 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45AF811E80F0 for ; Wed, 8 Jun 2011 11:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-V1pVU2WJ7Z for ; Wed, 8 Jun 2011 11:20:37 -0700 (PDT) Received: from hiroshima.bogus.com (hiroshima.bogus.com [IPv6:2001:418:1::80]) by ietfa.amsl.com (Postfix) with ESMTP id 6A43A11E8095 for ; Wed, 8 Jun 2011 11:20:18 -0700 (PDT) Received: from hiroshima.bogus.com (localhost [127.0.0.1]) by hiroshima.bogus.com (8.14.3/8.14.3) with ESMTP id p58IKGBW093995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 8 Jun 2011 11:20:16 -0700 (PDT) (envelope-from llynch@civil-tongue.net) Received: from localhost (llynch@localhost) by hiroshima.bogus.com (8.14.3/8.14.3/Submit) with ESMTP id p58IKG8X093992 for ; Wed, 8 Jun 2011 11:20:16 -0700 (PDT) (envelope-from llynch@civil-tongue.net) Date: Wed, 8 Jun 2011 11:20:16 -0700 (PDT) From: Lucy Lynch X-X-Sender: llynch@hiroshima.bogus.com To: saag@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY="===============5522917255311306011==" X-Mailman-Approved-At: Thu, 09 Jun 2011 08:02:15 -0700 Subject: [saag] [Kantara - Community] NSTIC - Notice of Inquiry Released (fwd) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 18:20:39 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --===============5522917255311306011== Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; format=flowed All - You may want to review this document (in particular the questions on page 13) as OpenID/Oauth will be front and center in many of these conversations. - Lucy ---------- Forwarded message ---------- Date: Wed, 8 Jun 2011 10:32:11 -0400 From: Joni Brennan To: community Subject: [Kantara - Community] NSTIC - Notice of Inquiry Released Hello Community, I'm in Washington DC this week to participate in the NSTIC governance workshops. Specifically I'm on a panel tomorrow, June 9th, discussing governance in real world use cases. If you're in Washington, DC at the workshops please say hello. There was a recent development today I thought might be of interest to many. Today's NSTIC Notice of Inquiry (NOI) may be of interest to many community members. NSTIC team is seeking comments by July 22, 2011. http://www.nist.gov/nstic/nstic-frn-noi.pdf Thoughts are welcome and please feel free to share the link on other lists etc. Best Regards, =Joni Joni Brennan IEEE-ISTO Kantara Initiative | Executive Director voice:+1 732-226-4223 email: joni @ ieee-isto.org gtalk: jonibrennan skype: upon request Join the conversation on the community@ list - http://kantarainitiative.org/mailman/listinfo/community --===============5522917255311306011== Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-ID: Content-Description: Content-Disposition: INLINE _______________________________________________ Community mailing list Community@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/community --===============5522917255311306011==-- From julian.reschke@gmx.de Thu Jun 9 07:41:06 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7839221F8481 for ; Thu, 9 Jun 2011 07:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.026 X-Spam-Level: X-Spam-Status: No, score=-104.026 tagged_above=-999 required=5 tests=[AWL=-1.427, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MsO5VfANPtf1 for ; Thu, 9 Jun 2011 07:41:05 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 4D5A121F847E for ; Thu, 9 Jun 2011 07:41:04 -0700 (PDT) Received: (qmail invoked by alias); 09 Jun 2011 14:41:02 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp064) with SMTP; 09 Jun 2011 16:41:02 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18FrCU+9d8F0BT4qZs6WrwkE2eNpxWblpTVujxLg3 zzOpbSyDTjUPOd Message-ID: <4DF0DB72.9090601@gmx.de> Date: Thu, 09 Jun 2011 16:40:50 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: http-auth@ietf.org, y.oiwa@aist.go.jp References: <878vtgfbs1.fsf@bluewind.rcis.aist.go.jp> <87hb7zdqjo.fsf@bluewind.rcis.aist.go.jp> In-Reply-To: <87hb7zdqjo.fsf@bluewind.rcis.aist.go.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Mailman-Approved-At: Thu, 09 Jun 2011 08:02:15 -0700 Cc: public-identity@w3.org, websec@ietf.org, saag@ietf.org Subject: Re: [saag] [http-auth] re-call for IETF http-auth BoF X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 14:41:06 -0000 On 2011-06-09 16:31, Yutaka OIWA wrote: > ... > password stealing, session hijack, and phishing. Currently, the HTTP > core protocol only provides basic plaintext password authentication > and MD5-based hashed password authentication, both of which are > ... That's kind of misleading; the core HTTP protocol doesn't define any concrete authentication schemes at all; it just offers a framework (header fields, status codes etc). > ... > Both BoF and possible future working group expect well coordination > with W3C's effort on the related topics. It shall also be in > coordination with related IETF working groups, including websec, abfab > and oauth. > ... I believe you need to add HTTPbis. Best regards, Julian From hallam@gmail.com Sat Jun 11 14:53:41 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8F341F0C40; Sat, 11 Jun 2011 14:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pW7mU7V+kSW; Sat, 11 Jun 2011 14:53:41 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id B6EB01F0C35; Sat, 11 Jun 2011 14:53:40 -0700 (PDT) Received: by yie30 with SMTP id 30so413350yie.31 for ; Sat, 11 Jun 2011 14:53:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=sTcMNjiVKkU/azl26PIFGJu8Ro8VurX61Rg3uGhteJ8=; b=glzyuoJhrjGEsOucx0emvU7qiTPG9yw0hyuAi1HCHOWU7T4QJFMM8+o/PEWLZEw5wD Ax1PlXoqCIJCdyUc8IZfk4vpSTR8e0qOR6/aMVvjs4tlQ9XvUNwIN21ExGq1GVY75FVz mDABJgPXvTQ5HC6777gAUV5w0fcvM83ykB1pA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=PWov+qw1DeoBnaQNwyBInUDhhSrt1n+t63p/HTNWd1oQlhhAN9rJ6Agz9gD8OHuUx4 Fq+VCMNAzXkwpyWuLVntsnvP4FDTamlM3QHtFL12HaF9/PRa1y51Qdw8u8329f5WCT10 Jwlu0ulwOj3qHxAavi1pq4kpGDqI7/ysl9V7o= MIME-Version: 1.0 Received: by 10.101.52.7 with SMTP id e7mr3462730ank.85.1307829218554; Sat, 11 Jun 2011 14:53:38 -0700 (PDT) Received: by 10.100.41.5 with HTTP; Sat, 11 Jun 2011 14:53:38 -0700 (PDT) In-Reply-To: <4DF0DB72.9090601@gmx.de> References: <878vtgfbs1.fsf@bluewind.rcis.aist.go.jp> <87hb7zdqjo.fsf@bluewind.rcis.aist.go.jp> <4DF0DB72.9090601@gmx.de> Date: Sat, 11 Jun 2011 17:53:38 -0400 Message-ID: From: Phillip Hallam-Baker To: Julian Reschke Content-Type: multipart/alternative; boundary=001636ed7313ffb37304a576b79c Cc: public-identity@w3.org, websec@ietf.org, http-auth@ietf.org, saag@ietf.org Subject: Re: [saag] [websec] [http-auth] re-call for IETF http-auth BoF X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2011 21:53:42 -0000 --001636ed7313ffb37304a576b79c Content-Type: text/plain; charset=ISO-8859-1 I have a different proposal. Lets take the high value authentication use cases out of the browser completely. Back in 1993 when Digest was designed, a Web browser could be written in about ten thousand lines of code. Today a modern browser has a code footprint that is larger than the memory plus pagefile of machine I used to work on at CERN. The modern browser is contaminated with plugins and active code. The worst disservice that Netscape did to the Web was when they added Javascript to Navigator unilaterally. Once a program conflates code and data it is never going to be possible to make it secure. The alternative would be to have a mini-browser whose sole purpose was to be used to confirm high value transactions. This could be on the same machine as the browser or a totally different machine such as a mobile phone. If we start small with an application whose sole purpose is security we have a good chance of getting some secure implementations. This type of approach is not going to be acceptable for every possible application or for every user. But the same is true of smart-cards, tokens and the like. So imagine that we had such a capability (I have a draft, I am just working on getting preliminary feedback), what would we want HTTP authentication to look like? At that point what I would want most from the browser is to be able to authenticate the browser and the machine it is running on in a manner that is secure and robust. Cookies try to do this but again the implementation was shoddy. Where I think this conversation tends to go off the rails is when people get the idea that the problem is the lack of an authentication protocol or an authentication framework API. We have both of them, we have cartloads of both of them. The other point where I think the conversation went into a dead end was five years ago when people started to sniff out the possibility of a something that turned out to be Facebook. All those people who were wittering on about 'Identity' were not trying to solve the problem of how users authenticate or manage attributes they were trying to solve the problem of how they could win the spot in the industry that Facebook now occupies. The missing like here in my view is the account identifier and the mechanism by which it is mapped to a service. The market has already decided that the federated account identifier for Internet login will look like an email address. So Alice is going to be something like alice@example.com. The problem with the current authentication infrastructure is that Alice now has hundreds of accounts under that account name being maintained all over the Web and example.com really has no control over how they are used. One side effect of that lack of control is the type of idiocy I encountered trying to report a bug in Visual Studio yesterday. First I had to register to create a Windows Live ID. Which was irritating since I already have registered several products with Microsoft. But never mind. So I register for that and then I am told that I have to register my Windows Live account again and verify my email a second time. Plus give all the same personal details again. Now the reason that Microsoft ended up in that situation is quite easy to see. They have a bunch of divisions run as silos and one does not exchange information with another. But they do have management degrees coming down from the top telling one division to use another's dog food. If my hallam@gmail.com accounts were all managed by gmail.com there would be no need for any callback mechanism whatsoever. Nor would there have been any need for the Windows Live account or the crazy register then register all over again. If we could accept the simple idea that use of an authentication account should work the exact same way as use of an email account, this type of problem can be eliminated. You don't expect to be able to use gmail.com for email unless gmail.com has a Web server. So why do people try to write protocols that are designed to allow people to use gmail.com for authentication when gmail.com is not involved in the running of the authentication service in question? --001636ed7313ffb37304a576b79c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I have a different proposal. Lets take the high value authentication use ca= ses out of the browser completely.

Back in 1993 when Digest was designed, a Web browser co= uld be written in about ten thousand lines of code. Today a modern browser = has a code footprint that is larger than the memory plus pagefile of machin= e I used to work on at CERN.

The modern browser is contaminated with plugins and act= ive code. The worst disservice that Netscape did to the Web was when they a= dded Javascript to Navigator unilaterally. Once a program conflates code an= d data it is never going to be possible to make it secure.


The alternative would be to have a mini-= browser whose sole purpose was to be used to confirm high value transaction= s. This could be on the same machine as the browser or a totally different = machine such as a mobile phone.

If we start small with an application whose sole purpos= e is security we have a good chance of getting some secure implementations.=

This type of approach is not going to be acceptab= le for every possible application or for every user. But the same is true o= f smart-cards, tokens and the like.=A0


So imagine that we had such a capability= (I have a draft, I am just working on getting preliminary feedback), what = would we want HTTP authentication to look like?

At that point what I would want most from the browser is to be able to auth= enticate the browser and the machine it is running on in a manner that is s= ecure and robust. Cookies try to do this but again the implementation was s= hoddy.

Where I think this conversation tends to go off the rai= ls is when people get the idea that the problem is the lack of an authentic= ation protocol or an authentication framework API. We have both of them, we= have cartloads of both of them.=A0

The other point where I think the conversation went int= o a dead end was five years ago when people started to sniff out the possib= ility of a something that turned out to be Facebook. All those people who w= ere wittering on about 'Identity' were not trying to solve the prob= lem of how users authenticate or manage attributes they were trying to solv= e the problem of how they could win the spot in the industry that Facebook = now occupies.


The missing like here in my view is the = account identifier and the mechanism by which it is mapped to a service.

The market has already decided that the federated ac= count identifier for Internet login will look like an email address. So Ali= ce is going to be something like alice= @example.com.


The problem with the current authenticat= ion infrastructure is that Alice now has hundreds of accounts under that ac= count name being maintained all over the Web and example.com really has no control over how they are used.=A0

One side effect of that lack of control is the type of = idiocy I encountered trying to report a bug in Visual Studio yesterday. Fir= st I had to register to create a Windows Live ID. Which was irritating sinc= e I already have registered several products with Microsoft. But never mind= . So I register for that and then I am told that I have to register my Wind= ows Live account again and verify my email a second time. Plus give all the= same personal details again.

Now the reason that Microsoft ended up in that situatio= n is quite easy to see. They have a bunch of divisions run as silos and one= does not exchange information with another. But they do have management de= grees coming down from the top telling one division to use another's do= g food.

If my hallam@gmail.= com accounts were all managed by gmail.com= there would be no need for any callback mechanism whatsoever. Nor woul= d there have been any need for the Windows Live account or the crazy regist= er then register all over again.


If we could accept the simple idea that = use of an authentication account should work the exact same way as use of a= n email account, this type of problem can be eliminated.

You don't expect to be able to use gmail.com for email unless gmail.com has a Web server. So why do people try to write protocols that are desig= ned to allow people to use gmail.com for a= uthentication when gmail.com is not involv= ed in the running of the authentication service in question?
--001636ed7313ffb37304a576b79c-- From alexey.melnikov@isode.com Sun Jun 12 09:18:50 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3B5911E80AE; Sun, 12 Jun 2011 09:18:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.19 X-Spam-Level: X-Spam-Status: No, score=-102.19 tagged_above=-999 required=5 tests=[AWL=0.409, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRvrgPpmGwZ3; Sun, 12 Jun 2011 09:18:50 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id DC04811E80AC; Sun, 12 Jun 2011 09:18:49 -0700 (PDT) Received: from [188.28.0.10] (188.28.0.10.threembb.co.uk [188.28.0.10]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 12 Jun 2011 17:18:48 +0100 Message-ID: <4DF4E6C3.8030206@isode.com> Date: Sun, 12 Jun 2011 17:18:11 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Julian Reschke References: <878vtgfbs1.fsf@bluewind.rcis.aist.go.jp> <87hb7zdqjo.fsf@bluewind.rcis.aist.go.jp> <4DF0DB72.9090601@gmx.de> In-Reply-To: <4DF0DB72.9090601@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: public-identity@w3.org, websec@ietf.org, http-auth@ietf.org, saag@ietf.org Subject: Re: [saag] [websec] [http-auth] re-call for IETF http-auth BoF X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2011 16:18:50 -0000 Julian Reschke wrote: > On 2011-06-09 16:31, Yutaka OIWA wrote: > >> ... >> password stealing, session hijack, and phishing. Currently, the HTTP >> core protocol only provides basic plaintext password authentication >> and MD5-based hashed password authentication, both of which are >> ... > > That's kind of misleading; the core HTTP protocol doesn't define any > concrete authentication schemes at all; it just offers a framework > (header fields, status codes etc). > > > ... > >> Both BoF and possible future working group expect well coordination >> with W3C's effort on the related topics. It shall also be in >> coordination with related IETF working groups, including websec, abfab >> and oauth. >> ... > > I believe you need to add HTTPbis. +1. I would also add Kitten. From kwatsen@juniper.net Mon Jun 13 15:01:32 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF35521F853D for ; Mon, 13 Jun 2011 15:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1-9YLJl-7ZA for ; Mon, 13 Jun 2011 15:01:31 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id D787A21F853A for ; Mon, 13 Jun 2011 15:01:28 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKTfaItqEx+71ahgZQsvJVOQJCm8pcRyJR@postini.com; Mon, 13 Jun 2011 15:01:31 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Mon, 13 Jun 2011 15:00:09 -0700 From: Kent Watsen To: Jeffrey Hutzelman Date: Mon, 13 Jun 2011 15:00:05 -0700 Thread-Topic: [saag] draft-kwatsen-reverse-ssh-01 submission for review Thread-Index: AcwmUDMylkY2FD/lRWGPlPpb3vcEuAApMekw Message-ID: <84600D05C20FF943918238042D7670FD3E82122E54@EMBX01-HQ.jnpr.net> References: <965_1307576669_p58NiSYT016404_84600D05C20FF943918238042D7670FD3E81EA1164@EMBX01-HQ.jnpr.net> <1307587911.7092.331.camel@destiny> In-Reply-To: <1307587911.7092.331.camel@destiny> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "ietf-ssh@NetBSD.org" , "saag@ietf.org" Subject: Re: [saag] draft-kwatsen-reverse-ssh-01 submission for review X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 22:01:32 -0000 DQpIaSBKZWZmLA0KDQpUaGFuayB5b3UgZm9yIHNlbmRpbmcgb3V0IHlvdXIgY29tbWVudHMhDQoN Cg0KPiBTbywgbGV0J3MgbWFrZSBzdXJlIEkgaGF2ZSB0aGlzIHJpZ2h0LiAgQSBkZXZpY2UgImNh bGxpbmcgaG9tZSIgaXMgZ29pbmcNCj4gdG8gY29ubmVjdCB0byBzb21lIHNlcnZlciBvbiBwb3J0 IDIyLCBhbmQgZXhwZWN0IHRoZSBzZXJ2ZXIgdG8NCj4gaW1tZWRpYXRlbHkgcGljayB1cCB0aGUg cm9sZSBvZiBiZWluZyBhbiBTU0ggY2xpZW50Pw0KDQpZZXMsIHRoaXMgaXMgdGhlIHByb3Bvc2Fs DQoNCg0KPiBIb3cgaXMgdGhlIHNlcnZlciB0byBkaXN0aW5ndWlzaCBiZXR3ZWVuIHN1Y2ggYSBk ZXZpY2UgYW5kIGEgbm9ybWFsIHNzaA0KPiBjbGllbnQgYmVpbmcgdXNlZCBieSBhbiBhZG1pbiB3 aG8gd2FudHMgdG8gbG9nIGluIHRvIHRoZSBzZXJ2ZXI/ICBPciBieQ0KPiBzb21lIG90aGVyIHBy b3RvY29sIHRoYXQgcnVucyBvdmVyIHNzaD8NCg0KSXQgY2FuJ3QsIHRoZSBzZXJ2ZXIgaGFzIHRv ICprbm93KiB0aGF0IGl0J3MgaGF2aW5nIHRoaXMgcHVycG9zZS4gIEFzIG1lbnRpb25lZCBiZWZv cmUsIHRoZSBkZXZpY2VzIGNhbid0IGNvbm5lY3QgdG8gYSBnZW5lcmljIFNTSCBzZXJ2ZXIsIHNp bmNlIGFwcGxpY2F0aW9uLWxldmVsIGJ1c2luZXNzIGxvZ2ljIG5lZWRzIHRvIGJlIGxpbmtlZC1p biB0byBvcGVuIGNoYW5uZWxzIHRvIHRoZSBkZXZpY2UgYW5kIHdoYXQgbm90LiAgVGhpcyBpcyB3 aHkgaXMgY2FuJ3QgYmUgYSBnZW5lcmljIFNTSCBzZXJ2ZXIuICBJdCdzIGFsc28gd2h5IGEgZGlz dGluY3QgSUFOQS1hc3NpZ25lZCBwb3J0IG1pZ2h0IGJlIGdvb2QsIHNvIGFzIHRvIGRpc2NvdXJh Z2Ugc3RhbmRhcmQgU1NIIGNsaWVudHMgZnJvbSB0cnlpbmcgdG8gY29ubmVjdCB0byBpdC4NCg0K DQoNCj4gSSdtIHByZXR0eSBzdXJlIEkgcmVjYWxsIHRoZSBkaXNjdXNzaW9uIG9uIHRoaXMgcG9p bnQgaW52b2x2aW5nIHNvbWUNCj4gc29ydCBvZiBuZWdvdGlhdGlvbiwgcmF0aGVyIHRoYW4gYSBy ZXF1aXJlbWVudCB0aGF0IGJvdGggc2lkZXMga25vdyBhDQo+IHByaW9yaSB3aGljaCBwcm90b2Nv bCB2YXJpYW50IHRoZXkncmUgZ29pbmcgdG8gc3BlYWsuICBJbiBmYWN0LCBJIHNlZW0NCj4gdG8g cmVjYWxsIGRlciBNb3VzZSBzdWdnZXN0aW5nIHVzZSBvZiBhIHByZS1rZXggZXh0ZW5zaW9uIHBh Y2tldCB0bw0KPiBpbmRpY2F0ZSB0aGlzLg0KDQpUcnVlLiAgTm90IHRoYXQgaXQncyBhIGdvb2Qg ZXhjdXNlLCBidXQgaXQgSSBjb3VsZG4ndCBmaW5kIGEgd2F5IHRvIGhhdmUgYSBwcmUta2V4IGV4 dGVuc2lvbiBwYWNrZXQgdGhhdCB3b3VsZG7igJl0IGFsc28gbmVjZXNzaXRhdGUgdmVyc2lvbmlu ZyB0aGUgU1NIIFRyYW5zcG9ydCBMYXllciBwcm90b2NvbCAoU1NIIDIuMSkuICBJIHdhc24ndCBz dXJlIGlmIHRoaXMgd2FzIGdvaW5nIHRvIGJlIE9LLiAgSSBuZWdsZWN0ZWQgdG8gbWVudGlvbiBh bnl0aGluZyBhYm91dCB0aGlzIHdoZW4gSSBzZW50IG91dCB0aGUgdXBkYXRlIC0gdGhhbmtzIGZv ciBjYXRjaGluZyBpdCEgIElmIGRlc2lyZWQsIEknbGwgY2VydGFpbmx5IHVwZGF0ZSB0aGUgZHJh ZnQgdG8gY29tcGxldGUgdGhpcyBpdGVtLi4uICBbUFM6IEkgbGlrZSBtb3JlIHlvdXIgaWRlYSB0 byBsZXQgdGhlIFNTSCBzZXJ2ZXIgb3BlbiBjaGFubmVscyBvbiB0aGUgU1NIIGNsaWVudCwgbW9y ZSBvbiB0aGF0IGJlbG93XQ0KDQoNCg0KPiBUaGlzIGlzIG5vdCB0aGUgd2F5IHRvIGFjaGlldmUg d2hhdCB5b3UncmUgdHJ5aW5nIHRvIGRvLiAgTm9yIGlzDQo+IHNwZWNpZnlpbmcgdXNlIG9mIG9u bHkgcGFydGljdWxhciBob3N0IGtleSBhbGdvcml0aG1zLCB3aGljaCByYXRoZXINCj4gYmFkbHkg YnJlYWtzIG1vZHVsYXJpdHkuICBGdXJ0aGVyLCB3aGF0IHlvdSd2ZSBkb25lIGRvZXNuJ3QgYWN0 dWFsbHkgYnV5DQo+IGFueXRoaW5nLiAgSWYgdGhlIEhNQUMgaXMgcHJlY29tcHV0ZWQgYmVmb3Jl IHRoZSBkZXZpY2UgdGhhdCB3aWxsIGFjdCBhcw0KPiBTU0ggc2VydmVyIGlzIGRlcGxveWVkLCB0 aGVuIHRoZXJlIGlzIG5vIG9wZXJhdGlvbmFsIGFkdmFudGFnZSBvdmVyDQo+IFguNTA5IGNlcnRp ZmljYXRlcy4gIE9uIHRoZSBvdGhlciBoYW5kLCBpZiB0aGUgSE1BQyBpcyBjb21wdXRlZCBhdCB0 aGUNCj4gdGltZSBvZiB0aGUgY29ubmVjdGlvbiwgdGhlbiBib3RoIHRoZSBjbGllbnQgYW5kIHNl cnZlciBtdXN0IGtub3cgdGhlDQo+IGtleSBfYW5kXyB0aGVyZSBtdXN0IGJlIGEgZGlmZmVyZW50 IGtleSBmb3IgZWFjaCBjbGllbnQvc2VydmVyIHBhaXIgKHNvDQo+IG9uZSBkZXZpY2UgY2Fubm90 IGltcGVyc29uYXRlIGFub3RoZXIpLiAgSW4gd2hpY2ggY2FzZSwgeW91IG1heSBhcyB3ZWxsDQo+ IHByZXNoYXJlIHBlci1kZXZpY2UgUlNBIGtleXMgaW5zdGVhZCBvZiBwZXItZGV2aWNlIEhNQUMg a2V5cy4NCj4NCj4gRXhjZXB0IGluIGNhc2VzIGxpa2UgWC41MDkgKHdoZXJlIGEgaG9zdCBrZXkg aXMgYXNzb2NpYXRlZCB3aXRoIGENCj4gbG9uZy10ZXJtIHNpZ25hdHVyZSBieSBzb21lIHRydXN0 ZWQgdGhpcmQgcGFydHkpLCBTU0ggcHJvdmVzIHNlcnZlcg0KPiBpZGVudGl0eSBhbmQgYXV0aGVu dGljYXRlcyBob3N0IGtleXMgYXMgcGFydCBvZiBrZXkgZXhjaGFuZ2UuICBJZiBub25lDQo+IG9m IHRoZSBhbHJlYWR5LWRlZmluZWQgS0VYIG1ldGhvZHMgYXJlIHN1aXRhYmxlIGZvciB5b3VyIG5l ZWRzLCB0aGVuIGl0DQo+IG1pZ2h0IGJlIHBvc3NpYmxlIHRvIGRlZmluZSBhIG5ldyBvbmUgYWxv bmcgdGhlIGxpbmVzIG9mIHdoYXQgeW91J3ZlDQo+IGRlc2NyaWJlZC4gIEhvd2V2ZXIsIEkgc2Vy aW91c2x5IGRvdWJ0IGl0cyB1dGlsaXR5LCBmb3IgdGhlIHJlYXNvbnMNCj4gZGVzY3JpYmVkIGFi b3ZlLg0KDQpJIGV4cGVjdGVkIHRoaXMgdG8gYmUgY2hhbGxlbmdlZCwgYXMgaXQncyBxdWl0ZSB1 bmlxdWUuICAgTGV0IG1lIHN0YXJ0IGJ5IHN0YXRpbmcgdGhhdCB3ZSAoSnVuaXBlcikgaGF2ZSBi ZWVuIHVzaW5nIGFuIEhNQUMgdG8gc2VjdXJlIHJldmVyc2Utc3NoIGNvbm5lY3Rpb25zIGZvciBh IGZldyB5ZWFycyBub3cuICBXZSB1c2UgdGhlIEhNQUMgaW4gYSBib290c3RyYXBwaW5nIG1lc3Nh Z2Ugc2ltaWxhciB0byB0aGF0IGRlc2NyaWJlZCBieSB0aGUgLTAwIHZlcnNpb24gb2YgdGhpcyBk cmFmdC4gIENyZWF0aW5nIHRoZSAiaG1hYy0qIiBmYW1pbHkgb2YgYWxnb3JpdGhtcyB3YXMgb25s eSB0byBwcmVzZXJ2ZSB0aGlzIGZ1bmN0aW9uYWxpdHkgaW4gdGhlIFNTSCBwcm90b2NvbCBpdHNl bGYuDQoNClRoZSB3YXkgaXQgd29ya3MgaXMgYXMgZm9sbG93cy4gIFRoZSBOTVMgY3JlYXRlcyBh biBlbnRyeSBpbiBpdHMgZGF0YWJhc2UgZm9yIHRoZSBkZXZpY2UgaXQgZXhwZWN0cyB3aWxsIGNv bm5lY3Qgc29tZXRpbWUgbGF0ZXIuICBUaGUgZW50cnkgaXMga2V5ZWQgYnkgYSAiZGV2aWNlLWlk IiBhbmQgYSB1bmlxdWUgSE1BQyB2YWx1ZSBpcyBzdG9yZWQgZm9yIGl0LiAgTGF0ZXIsIEp1bmlw ZXIgd2lsbCBkcm9wLXNoaXAgdGhlIGRldmljZSAod2l0aCBmYWN0b3J5LWRlZmF1bHQgaW1hZ2Up IGRpcmVjdGx5IHRvIGl0cyBkZXN0aW5hdGlvbiAoaS5lLiBhIHJldGFpbCBvdXRsZXQgc3RvcmUp LCB3aGVyZSBpdCBpcyBleHBlY3RlZCB0aGF0IHRoZSAqc3RvcmUgbWFuYWdlciogd2lsbCBiZSBh YmxlIHRvIGdldCBpdCB1cCBhbmQgcnVubmluZy4gIEJlaW5nIG5vdCB2ZXJ5IHRlY2huaWNhbCwg dGhlIHN0b3JlIG1hbmFnZXIgZm9sbG93cyBzaW1wbGUgaW5zdHJ1Y3Rpb25zIHNlbnQgZnJvbSBI USAocGx1ZyBwaG9uZSBjYWJsZSBoZXJlLCBwbHVnIHBvd2VyIGNhYmxlIGhlcmUsIHdhaXQgZm9y IGxpZ2h0IHRvIGJsaW5rLCBjYWxsIHRoaXMgbnVtYmVyLCBldGMuKS4gIFVsdGltYXRlbHksIHRo ZSBkZXZpY2UgbmVlZHMgdG8gZ2V0IGVub3VnaCBjb25maWcgdG8gaW5pdGlhbGl6ZSBpdHMgbmV0 d29yayBzdGFjayBhbmQgc2VjdXJlbHkgImNhbGwgaG9tZSIgdG8gaXRzIE5NUy4gIFRoZSBkZXZp Y2UgTUFZIGdldCB0aGlzIGluZm9ybWF0aW9uIGZyb20gYSBESENQIHNlcnZlciBhbmQvb3IgVVNC IHBlbi1kcml2ZSBwbHVnZ2VkIGludG8gaXQgYW5kL29yIHZpYSBpdHMgd2ViL2NsaSBpbnRlcmZh Y2VzLiAgRm9yIGFuIEhNQUMsIHdlJ2QgbmV2ZXIgcHV0IHRoZSBITUFDLWtleSBvbiBhIERIQ1Ag c2VydmVyIHRvIGJlIHJldHJpZXZlZCB2aWEgb3B0aW9uIDQzIChhcyB0aGF0IHdvdWxkIGJlIGlu c2VjdXJlKSwgd2UgZWl0aGVyIGV4cGVjdCB0aGUgSE1BQy1rZXkgdG8gYmUgcmVhZCBvZmYgYSBV U0IgZHJpdmUgb3IgbWFudWFsbHkga2V5ZWQgaW4gYnkgdGhlIHN0b3JlIG1hbmFnZXIuDQoNCkkn bSBub3Qgc3VyZSB3aGF0IHlvdSBtZWFuIGJ5IG1vZHVsYXJpdHksIGJ1dCByZWdhcmRpbmcgb3Bl cmF0aW9uYWwgYWR2YW50YWdlIG92ZXIgeC41MDkgY2VydGlmaWNhdGVzLCBjb25zaWRlciB0aGUg Zm9sbG93aW5nOiAxKSB0aGVyZSdzIG5vIG9wcG9ydHVuaXR5IGluIHRoZSBhYm92ZSBkZXNjcmlw dGlvbiBmb3IgdGhlIHN0b3JlIG1hbmFnZXIgdG8gZ2V0IGEgeC41MDkgY2VydGlmaWNhdGUgZm9y IHRoZSBkZXZpY2UncyBkeW5hbWljYWxseS1nZW5lcmF0ZWQgcHJpdmF0ZS1rZXksIDIpIHRoZSBI TUFDIGlzIG11Y2ggc2ltcGxlciB0byBrZXkgaW4gdGhhbiBhIFBFTSBmaWxlIChmb3Igd2hlbiBj bGkvd2ViIGludGVyZmFjZSBpcyB1c2VkIHRvIGRvIHRoYXQpDQoNCg0KDQoNCj4gSXQgc291bmRz IHRvIG1lIGxpa2UgeW91IHJlYWxseSBfZG9uJ3RfIHdhbnQgdGhlIGRldmljZSB0byBiZSB0aGUg U1NIDQo+IHNlcnZlciBhdCBhbGw7IHlvdSBvbmx5IHRoaW5rIHlvdSBkby4gIEkgc3VzcGVjdCB5 b3UgcmVhbGx5IHdhbnQgdGhlDQo+IGRldmljZSB0byBiZSB0aGUgU1NIIF9jbGllbnRfLCBleGNl cHQgdGhhdCBvbmNlIHRoZSBjb25uZWN0aW9uIGlzIHVwLA0KPiB5b3Ugd2FudCB0aGUgc2VydmVy IHRvIG9wZW4gc29tZSBzb3J0IG9mIHNlc3Npb24gdG8gdGhlIGNsaWVudCB0bw0KPiBleGVjdXRl IGNvbW1hbmRzLCB0cmFuc2ZlciBmaWxlcywgcnVuIG5ldGNvbmYgb3IgU05NUCwgb3Igd2hhdGV2 ZXIuDQo+DQo+IEludGVyZXN0aW5nbHksIHRoaXMgcm9sZSByZXZlcnNhbCAtLSBhbGxvd2luZyB0 aGUgU1NIIHNlcnZlciB0byBvcGVuDQo+IHNlc3Npb25zIGFuZCBydW4gY29tbWFuZHMgb24gdGhl IFNTSCBjbGllbnQsIHJlcXVpcmVzIG5vIGNoYW5nZSB0byB0aGUNCj4gU1NIIHByb3RvY29sIGF0 IGFsbC4gIEl0IHNpbXBseSByZXF1aXJlcyB0aGF0IHRoZSBjbGllbnQgc2l0IGFyb3VuZA0KPiB3 YWl0aW5nIGZvciBhIGNoYW5uZWwtb3BlbiByZXF1ZXN0IGZyb20gdGhlIHNlcnZlciBhbmQgYWNj ZXB0IGl0IHdoZW4gaXQNCj4gY29tZXMgYXJvdW5kLiAgVGhpcyBpcyBleGFjdGx5IHRoZSBzb3J0 IG9mIHNpdHVhdGlvbiBpbiB3aGljaCBpdCBpcw0KPiBhcHByb3ByaWF0ZSB0byBiZWhhdmUgY29u dHJhcnkgdG8gdGhlIFNIT1VMRCBpbiBSRkM0MjU0IHNlY3Rpb24gNi4xLg0KDQpUaGlzIGlzIGEg dmVyeSBpbnRlcmVzdGluZyBpZGVhOyBpdCB3b3VsZCBiZSAqbXVjaCogc2ltcGxlciB0byBhbGxv dyB0aGUgc2VydmVyIHRvIG9wZW4gY2hhbm5lbHMgb24gdGhlIGNsaWVudC4gIFByZXN1bWFibHkg dGhlIGNsaWVudCB3b3VsZCBoYXZlIHRvIGJlIGNvbmZpZ3VyZWQgdG8gaW5kaWNhdGUgd2hpY2gg c3Vic3lzdGVtcyBhcmUgYWxsb3dlZCAodHR5LCBzZnRwLCBuZXRjb25mKS4NCg0KT2YgY291cnNl LCBhcyBtZW50aW9uZWQgYWJvdmUsIHdlIHN0aWxsIGNvdWxkbid0IHVzZSBhIGdlbmVyaWMgU1NI IHNlcnZlci4gIEluc3RlYWQsIGl0IHdvdWxkIGhhdmUgdG8gYmUgYSBTU0ggc2VydmVyIGxpbmtl ZCB0byBzb21lIGFwcGxpY2F0aW9uIGNvZGUgdG8gZG8gdGhlIGRvbWFpbi1zcGVjaWZpYyBidXNp bmVzcyBsb2dpYy4gIEZvciB0aGlzIHJlYXNvbiwgaXQgd291bGQgYmUgZ29vZCB0byBydW4gaXQg b24gYW5vdGhlciBwb3J0LCBidXQgbm93IGl0J2QgYmUgaGFyZCB0byBqdXN0aWZ5IGZvciBhbiBJ QU5BLWFzc2lnbmVkIHBvcnQsIHNpbmNlIGl0IHJlYWxseSBpcyB0aGUgU1NIIHByb3RvY29sIGFu ZCB0aGVyZSBhbHJlYWR5IGlzIGEgcG9ydCBmb3IgdGhhdC4gIEluc3RlYWQsIGFwcGxpY2F0aW9u cyB3b3VsZCBsaWtlbHkgbmVlZCB0byB1c2UgdGhlIGR5bmFtaWMvcHJpdmF0ZSBwb3J0IHJhbmdl Lg0KDQpUaGlua2luZyB0aGlzIHRocm91Z2gsIHVzaW5nIHRoZSBzdG9yZS1tYW5hZ2VyIGV4YW1w bGUgZnJvbSBhYm92ZSwgbGV0J3Mgc2F5IHRoZSBkZXZpY2UgU1NIJ3MgdG8gdGhlIGFwcGxpY2F0 aW9uLiAgVGhlIGRldmljZSBhdXRoZW50aWNhdGVzIHRoZSBzZXJ2ZXIncyBTU0ggaG9zdCBrZXks IHdoaWNoIGNvdWxkIGVpdGhlciBiZSBhIHguNTA5IGNlcnQgb3IgYW4gSE1BQy0qIGtleS4gIFRo ZW4gdGhlIGRldmljZSBsb2dzIGludG8gdGhlIGFwcGxpY2F0aW9uICh1c2VyYXV0aCkgYWdhaW4g dXNpbmcgZWl0aGVyIHguNTA5IGNlcnRpZmljYXRlIG9yIEhNQUMtKiBrZXkuICBUaGVuIHRoZSBh cHBsaWNhdGlvbiAodGhlIFNTSCBzZXJ2ZXIpIG9wZW5zIGNoYW5uZWxzIG9uIHRoZSBkZXZpY2Ug KHRoZSBTU0ggY2xpZW50KS4gIA0KDQpBIGNvdXBsZSB0aG91Z2h0cyBhYm91dCBob3cgaWRlbnRp dGllcyBjYW4gYmUgZGV0ZXJtaW5lZDoNCg0KMS4gdGhlIGRldmljZSBjYW4gYmUgY29uZmlndXJl ZCB0byBrbm93IHdoaWNoIHVzZXIgaXQgc2hvdWxkIHJ1biB0aGUgU1NIIGNsaWVudCBhcy4gIFdl IG5lZWQgdG8gZW5zdXJlIGEgdXNlciBpcyBzcGVjaWZpZWQgc2luY2UgQ29tbW9uIENyaXRlcmlh IHJlcXVpcmVzIHRoZSBkZXZpY2UgdG8gaWRlbnRpZnkgYSAidXNlciIgZm9yIGVhY2ggYXVkaXRh YmxlIGV2ZW50LiAgTm90ZSB0aGF0IHdlIGNhbid0IGxldmVyYWdlIFJGQyA2MTI1IChTZXJ2aWNl IElkZW50aXR5KSwgc2luY2Ugc2VjdGlvbiAxLjcuMiBzcGVjaWZpY2FsbHkgbGVmdCBjbGllbnQg b3IgZW5kLXVzZXIgaWRlbnRpdGllcyBvdXQgb2Ygc2NvcGUuDQoNCjIuIHRoZSBhcHBsaWNhdGlv biBjYW4gdXNlIHRoZSB1c2VybmFtZSB0aGUgZGV2aWNlIHBhc3NlcyBhcyB0aGUgImRldmljZS1p ZCIgdmFsdWUuICAgVGhpcyBzZWVtcyBvYnZpb3VzLCBidXQgaXQncyBkaWZmZXJlbnQgdGhlbiBi ZWZvcmUgYW5kIGhlbmNlIHdvcnRoIHN0YXRpbmcgZXhwbGljaXRseS4gIEFsc28sIHNpbmNlIHRo ZSB1c2VybmFtZSB2YWx1ZSBpcyBwYXNzZWQgaW5zaWRlIHRoZSBTU0ggdHVubmVsLCBpdCB3b3Vs ZCBiZSBPSyB0byBwYXNzIGEgc2VyaWFsLW51bWJlciwgc29tZXRoaW5nIHRoZSBvdGhlciBzb2x1 dGlvbnMgY291bGRuJ3QgcmVjb21tZW5kIGZvciBzZWN1cml0eSByZWFzb25zLg0KDQpJdCB3b3Vs ZCBiZSBpbnRlcmVzdGluZyB0byByZXZpZXcgYSBmZXcgU1NIIFNlcnZlciBsaWJyYXJ5IGltcGxl bWVudGF0aW9ucyAoaS5lLiBsaWJzc2gpIHRvIHNlZSBpZiB0aGV5IHByb3ZpZGUgdGhlIGhvb2tz IGFuIGFwcGxpY2F0aW9uIHdvdWxkIG5lZWQgdG8gaW1wbGVtZW50IGl0cyBidXNpbmVzcyBsb2dp Yy4uLg0KDQoNCg0KPiBGV0lXLCBJJ20gZmFpcmx5IGNvbmNlcm5lZCBhYm91dCB0aGUgaG1hYy0q IGFsZ29yaXRobXMgZGVzY3JpYmVkIGluIHRoaXMNCj4gZG9jdW1lbnQsIHdoaWNoIGRvbid0IHNl ZW0gdG8gcHJvdmlkZSBhbnkgZ3VhcmFudGVlIG9mIGZyZXNobmVzcy4NCg0KSSBhZ3JlZSB0aGF0 IGl0J3Mgbm90IGluIHRoZSBkcmFmdC4gIEkgdGhpbmsgdGhhdCBhICJTZWN1cml0eSBDb25zaWRl cmF0aW9uIiB3b3VsZCBzdWZmaWNlIHRob3VnaC4gIE91ciBOTVMgZG9lcyByZXBsYWNlIHRoZSBI TUFDIG9uIGRldmljZXMsIHVzaW5nIGEgY3J5cHRvZ3JhcGhpYyBQUk5HLiAgVGhhdCBzYWlkLCBJ IGRvbid0IGJlbGlldmUgZW50cm9weSBpcyBsb3N0IG92ZXIgdGltZSwgc2luY2UgdGhlIG1lc3Nh Z2UgdGhhdCBpcyBzaWduZWQgY2hhbmdlcyBvbmx5IHdoZW4gdGhlIGhvc3Qta2V5IGNoYW5nZXMu Li4NCg0KDQo+IEknbSBjb25jZXJuZWQgdGhhdCB0aGVyZSBpcyBubyBkZXNjcmlwdGlvbiBpbiB0 aGlzIGRvY3VtZW50IGFzIHRvIGhvdw0KPiB0aGUgU1NIIGNsaWVudCBpcyBleHBlY3RlZCB0byBh dXRoZW50aWNhdGUgaXRzZWxmIHRvIHRoZSBkZXZpY2UuICBUaGlzDQo+IGlzIGZhaXJseSBpbXBv cnRhbnQsIHBhcnRpY3VsYXJseSBzaW5jZSBpbiB0aGUgZGVzY3JpYmVkIGRlcGxveW1lbnQNCj4g c2NlbmFyaW8sIHRoZSBkZXZpY2UgaXMgbGlrZWx5IGFib3V0IHRvIGdpdmUgbmVhcmx5IHVubGlt aXRlZCBwb3dlciB0bw0KPiB0aGUgU1NIIGNsaWVudC4NCg0KVHJ1ZSwgYW5kIGl0IGFsc28gbGVm dCBvdXQgaG93IHRoZSBkZXZpY2UncyBuZXR3b3JraW5nIHN0YWNrIHdvdWxkIGJlIGNvbmZpZ3Vy ZWQuICAgRldJVywgc2VjdGlvbiA2IHNheXM6DQoNCiAgIlRoaXMgUkZDIGRvZXMgbm90IGF0dGVt cHQgdG8gZGVmaW5lIGFueSBzdHJhdGVneSBmb3IgaG93IGFuIGluaXRpYWwNCiAgIGRlcGxveW1l bnQgbWlnaHQgb2J0YWluIGl0cyBib290c3RyYXBwaW5nICJjYWxsIGhvbWUiIGNvbmZpZ3VyYXRp b24NCiAgIChhZGRyZXNzIHRvIGNvbm5lY3QgdG8sIHNpZ25hdHVyZSBhbGdvcml0aG0gdG8gdXNl LCBhdXRoZW50aWNhdGlvbg0KICAgY3JlZGVudGlhbHMgdG8gdXNlLCBldGMuKS4gIFRoYXQgc2Fp ZCwgaW1wbGVtZW50YXRpb25zIG1heSBjb25zaWRlcg0KICAgdXNlIG9mIGEgREhDUCBzZXJ2ZXIg b3IgYSBVU0IgcGVuIGRyaXZlIGFzIHZpYWJsZSBvcHRpb25zIGZvciB0aGVzZQ0KICAga2luZHMg b2YgZGVwbG95bWVudHMuIg0KDQpXZSBwcmltYXJpbHkgdXNlIGEgVVNCIGRyaXZlLCBmb3IgdGhl IGRldmljZSB0byByZWFkIG9uIGl0cyBmaXJzdCBib290LiAgVGhlIFVTQiBkcml2ZSBjYW4gY29u dGFpbiBldmVyeXRoaW5nIHRoZSBkZXZpY2UgbmVlZHMgdG8gImNhbGwgaG9tZSIgZnJvbSBhIGZh Y3RvcnktZGVmYXVsdCBjb25maWd1cmF0aW9uLiAgSSBkaWRuJ3QgdGhpbmsgaXQgd2FzIGltcG9y dGFudCB0byB0aGUgcHJvdG9jb2wgY2hhbmdlIGJlaW5nIGRpc2N1c3NlZCwgdGhvdWdoIGl0J3Mg Y2xlYXJseSBpbXBvcnRhbnQgdG8gdGhlIG92ZXJhbGwgc29sdXRpb24uDQoNCg0KDQo+IEZpbmFs bHksIEknbSB2ZXJ5IGNvbmNlcm5lZCBhYm91dCB0aGUgc3RhdGVtZW50cyBpbiB0aGUgZmlyc3Qg cGFyYWdyYXBoDQo+IG9mIHNlY3Rpb24gNywgd2hpY2ggYXNzZXJ0IHRoYXQgdGhlIHByb3Bvc2Vk IHJvbGUgcmV2ZXJzYWwgZG9lcyBub3QNCj4gaW50cm9kdWNlIGFueSBuZXcgc2VjdXJpdHkgY29u Y2VybnMuICBPbiB0aGUgY29udHJhcnksIHRoZSBwcm9wb3NlZA0KPiBwcm90b2NvbCBpcyB2ZXJ5 IG5lYXJseSBha2luIHRvIGNhbGxpbmcgc29tZW9uZSB1cCBhbmQgc2F5aW5nICJHaXZlIG1lDQo+ IHlvdXIgcGFzc3dvcmQiLCBsYXRlciBmb2xsb3dlZCBieSAiYnkgdGhlIHdheSwgSSBtaWdodCBi ZSB5b3VyIGJhbmsiLg0KDQpUaGF0J3Mgbm90IHRydWUuICBTZWN0aW9uIDQgc3RhdGVzOg0KDQog ICJpbiBvcmRlciB0byBlbmFibGUgdGhlIFJldmVyc2UgU1NIIHNlcnZlciB0byBpZGVudGlmeSB0 aGUNCiAgIFJldmVyc2UgU1NIIGNsaWVudCBhbmQgYXV0b21hdGljYWxseSBhdXRoZW50aWNhdGUg aXRzIFNTSCBob3N0IGtleSwNCiAgIGVhY2ggcGVlciBTSE9VTEQgb25seSBhZHZlcnRpc2Ugc3Vw cG9ydCBmb3Igb25lIG9mIHRoZSBmb2xsb3dpbmcgaG9zdA0KICAga2V5IGFsZ29yaXRobXM6Ig0K DQphbmQgdGhlbiBnb2VzIG9uIHRvIGxpc3QganVzdCB0aGUgeC41MDkgYW5kIHRoZSBobWFjLSog YWxnb3JpdGhtcywgYm90aCBvZiB3aGljaCBlbXBoYXNpemUgYXNzb2NpYXRpbmcgYW4gaWRlbnRp dHkgd2l0aCB0aGUgcHVibGljIGtleS4gIFNvIGl0J3Mgbm90ICJJIG1pZ2h0IGJlIHlvdXIgYmFu ayIsIGl0J3MgInlvdSBrbm93IEknbSB5b3VyIGJhbmsgYmVjYXVzZSBteSBpZGVudGl0eSBpcyBz aWduZWQgYnkgc29tZXRoaW5nIHlvdSB0cnVzdCIgKGVpdGhlciBhIENBIG9yIGFuIEhNQUMta2V5 KS4NCg0KDQo+IFdlJ3ZlIGRpc2N1c3NlZCAicmV2ZXJzZSBTU0giIGlkZWFzIGJlZm9yZSosIGFu ZCB0aGV5IGhhdmVuJ3QgZ2FpbmVkIGFueQ0KPiB0cmFjdGlvbi4gIFBhcnQgb2YgdGhlIHByb2Js ZW0gaXMgdGhhdCBzZXJ2ZXIgYW5kIGNsaWVudCBhdXRoZW50aWNhdGlvbg0KPiBpcyBub3Qgc3lt bWV0cmljIGluIHRoZSBTU0ggcHJvdG9jb2wsIGFuZCB0aGVyZSBpcyBhIGJhc2ljIGFzc3VtcHRp b24NCj4gdGhhdCBhIGNsaWVudCBrbm93cyBhIHByaW9yaSB3aGF0IHNlcnZlciBpdCBpbnRlbmRz IHRvIHRhbGsgdG8sIHdoaWxlDQo+IHRoZSBzZXJ2ZXIgZG9lcyBub3Qga25vdyB3aGF0IGNsaWVu dCB3aWxsIGJlIHRhbGtpbmcgdG8gaXQuICBBdHRlbXB0aW5nDQo+IHRvIGZhbHNpZnkgdGhpcyBh c3N1bXB0aW9uIGFuZCBzdGlsbCBoYXZlIHRoaW5ncyB3b3JrIHR5cGljYWxseSByZXN1bHRzDQo+ IGluIHdhcnBpbmcgdGhlIHByb3RvY29sIHJhdGhlciBiYWRseS4NCg0KRXhhY3RseS4gIFRoaXMg aXMgd2h5IG15IG9yaWdpbmFsIGRyYWZ0IHN0cmVzc2VkIHRoYXQgdGhlIGRldmljZSB3b3VsZCAq YWx3YXlzKiBiZSB0aGUgU1NIIHNlcnZlciwgcmVnYXJkbGVzcyB3aGljaCBwZWVyIGluaXRpYXRl ZCB0aGUgdW5kZXJseWluZyBUQ1AgY29ubmVjdGlvbi4gIEkgd2Fzbid0IHRyeWluZyB0byAiZmFs c2lmeSB0aGlzIGFzc3VtcHRpb24iLCBidXQgbWVyZWx5IGVuYWJsZSB0byBkZXZpY2UgdG8gaW5p dGlhdGUgdGhlIHVuZGVybHlpbmcgVENQIGNvbm5lY3Rpb24sIGV2ZXJ5dGhpbmcgZWxzZSByZW1h aW5zIHN0YW5kYXJkIFNTSCBwcm90b2NvbCwgd2l0aCB0aGUgZGV2aWNlIGFzIHRoZSBTU0ggc2Vy dmVyLg0KDQoNCg0KPiBJJ20gbm90IHNheWluZyBhIHJldmVyc2UgU1NIIGlzIG5vdCBwb3NzaWJs ZSwgYW5kIHdpdGggYSBmZXcgbW9yZQ0KPiBpdGVyYXRpb25zIHRoaXMgZG9jdW1lbnQgbWlnaHQg d2VsbCBiZWNvbWUgb25lLiAgSG93ZXZlciwgYXMgbWVudGlvbmVkDQo+IGFib3ZlLCBJIHRoaW5r IGl0J3MgcHJvYmFibHkgbm90IHRoZSByaWdodCBhcHByb2FjaCB0byBzb2x2aW5nIHRoZQ0KPiBz dGF0ZWQgcHJvYmxlbS4NCg0KSSdtIG1vdGl2YXRlZCB0byBkbyB3aGF0ZXZlciBpdCB0YWtlcyB0 byBnZXQgYSBzb2x1dGlvbiBzdGFuZGFyZGl6ZWQuICBKdW5pcGVyIGRvZXNu4oCZdCB3YW50IHRv IGhhdmUgYSBwcm9wcmlldGFyeSBzb2x1dGlvbiBhbmQgb3RoZXIgTkVUQ09ORyBXRyBtZW1iZXJz IGhhdmUgYXNrZWQgZm9yIGl0IGFzIHdlbGwuICAgSSB0aGluayB0aGF0LCB3aXRoIHRoaXMgcm91 bmQgb2YgUSZBLCB0aGF0IHdlJ3ZlIGdvdHRlbiBkb3duIHRvIHRoZSBjb3JlIG9mIHRoZSBpc3N1 ZS4gIEhvcGVmdWxseSB3ZSdsbCBpdGVyYXRlIHRvIHNvbWV0aGluZyBzb29uIG5vdy4gDQoNCg0K VGhhbmtzIGFnYWluLA0KS2VudA0KDQoNCg0K From stephen.farrell@cs.tcd.ie Mon Jun 13 15:25:14 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 685E911E80BF for ; Mon, 13 Jun 2011 15:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.425 X-Spam-Level: X-Spam-Status: No, score=-106.425 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Srp-dKzGcuX for ; Mon, 13 Jun 2011 15:25:13 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 5812111E80BA for ; Mon, 13 Jun 2011 15:25:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 0B16F171C66; Mon, 13 Jun 2011 23:25:06 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1308003892; bh=pYWKRUwCWjaygtNR8E9YSXxE FTg0qZjRSOUT+qPRP8Q=; b=0gL64o+pvvm0pwGmpBsV67mNBjP1hw6X7unCMmi8 NU1E7Y9+s1nmmAdU3fSqEWgwxe3g/TRJ1ZtAsr+0GEs+bVRiuSj2CufDK6NE1Wdp Hvm4p4wnsYw3xqOiWcr2C1nYy48C86wySuDfSl4d3ZbqoI2in/nw4kjc6Xi4clWe uFY4wnAqang/YowEKl97P/bcahin3VkiEvUgR3TLghQbSrfTz6D8iqGYD8+9X+5L Ls2wrOOZGUrOIc+R+bium1ZDiCtcd7IKx39bd89UJWd2p01JNDdBEoljqFAOTEGu jnGPB2Clxnz0UxF8aM2+U3UV6kSk9trXC4/50wdU/GsbXg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id RGEwWgYmE4fw; Mon, 13 Jun 2011 23:24:52 +0100 (IST) Received: from [10.87.48.10] (unknown [86.42.18.245]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id F19BD171C2D; Mon, 13 Jun 2011 23:24:50 +0100 (IST) Message-ID: <4DF68E32.3040800@cs.tcd.ie> Date: Mon, 13 Jun 2011 23:24:50 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: "saag@ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: draft-oreirdan-mody-bot-remediation@tools.ietf.org Subject: [saag] AD sponsoring draft-oreirdan-mody-bot-remediation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 22:25:14 -0000 Hi all, I've been asked, and have agreed, to AD sponsor this document. [1] The authors and I would be interested in saag feedback on the current version before I start an IETF LC. (I'll be giving them my own feedback as well when I get a chance.) The abstract says: This document contains recommendations on how Internet Service Providers can manage the effects of computers used by their subscribers, which have been infected with malicious bots, via various remediation techniques. Internet users with infected computers are exposed to risks such as loss of personal data, as well as increased susceptibility to online fraud and/or phishing. Such computers can also become an inadvertent participant in or component of an online crime network, spam network, and/or phishing network, as well as be used as a part of a distributed denial of service attack. Mitigating the effects of and remediating the installations of malicious bots will make it more difficult for botnets to operate and could reduce the level of online crime on the Internet in general and/or on a particular Internet Service Provider's network. Most of the document seems quite straightforwardly useful but I'd be particularly interested in comment about sections 5.4 (walled garden notification), 5.7 (web browser notification) and 7 (failure or refusal to remediate) which may be somewhat more controversial. I'm most interested in comment as to the effectiveness, in terms of improved security, of the practices described. To comment, either reply to this, or just mail me and the authors, or just me if you're very shy:-) Thanks, S. [1] https://datatracker.ietf.org/doc/draft-oreirdan-mody-bot-remediation/ From msk@cloudmark.com Mon Jun 13 15:51:58 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7E021F8549 for ; Mon, 13 Jun 2011 15:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.474 X-Spam-Level: X-Spam-Status: No, score=-103.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEIG+p9zpiYj for ; Mon, 13 Jun 2011 15:51:57 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id AB16821F8548 for ; Mon, 13 Jun 2011 15:51:57 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 13 Jun 2011 15:51:57 -0700 From: "Murray S. Kucherawy" To: Stephen Farrell , "saag@ietf.org" Date: Mon, 13 Jun 2011 15:51:56 -0700 Thread-Topic: [saag] AD sponsoring draft-oreirdan-mody-bot-remediation Thread-Index: AcwqGM5Qua/Li+9uRA6fSc3UTYr3rgAA3Dgw Message-ID: References: <4DF68E32.3040800@cs.tcd.ie> In-Reply-To: <4DF68E32.3040800@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [saag] AD sponsoring draft-oreirdan-mody-bot-remediation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 22:51:58 -0000 > -----Original Message----- > From: saag-bounces@ietf.org [mailto:saag-bounces@ietf.org] On Behalf Of S= tephen Farrell > Sent: Monday, June 13, 2011 3:25 PM > To: saag@ietf.org > Cc: draft-oreirdan-mody-bot-remediation@tools.ietf.org > Subject: [saag] AD sponsoring draft-oreirdan-mody-bot-remediation >=20 > Most of the document seems quite straightforwardly useful but > I'd be particularly interested in comment about sections > 5.4 (walled garden notification), 5.7 (web browser notification) > and 7 (failure or refusal to remediate) which may be somewhat > more controversial. I'm most interested in comment as to the > effectiveness, in terms of improved security, of the practices > described. Have the authors provided such commentary about the effectiveness of the ad= vice found in those sections? Seems like they're in a particularly good po= sition to do so. Section 7 in particular seems particularly sparse in that regard. From stephen.farrell@cs.tcd.ie Mon Jun 13 16:09:32 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDEF8228011; Mon, 13 Jun 2011 16:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.183 X-Spam-Level: X-Spam-Status: No, score=-106.183 tagged_above=-999 required=5 tests=[AWL=-0.184, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQo6OWhbZy3L; Mon, 13 Jun 2011 16:09:32 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id A3152228010; Mon, 13 Jun 2011 16:09:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 10013171C57; Tue, 14 Jun 2011 00:09:28 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1308006564; bh=2M+MRdBDcYEi+w uymS+lhd6/LQM/EloQMaEtcwOBKK0=; b=XocrV9AIVVQ53tuk/v7lL8rFH88TDm PyDbEB4R/N2TPwGux3n8DMoLN7Pc4j2UECg5iceaSfE3qgISHMpFndoNka2zVwh7 ptRUU3kq/HUfLz14+UoU8Km5sPp6pNb9CAh2NV2PgY7Nmo2PfPDp8Ri533EpZe8F VwUSLd6pmiTULnHpKYykYDb+JFFWqnLDAAJpVRpirlr67R4+5Ndc7C2ggQxKU6QI BTtAhtTRaAu3fSrMttGii8ILx/9yL8IH+P9KldYJfJjC+2WWnYwwqAydL2mTUuWJ t1bN8I1zkyrnmdDuEJb/uoukxtLnEUu8cxAH/fnxP+lMUPo7RCe5Mzkg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id TV7xFrezEjkZ; Tue, 14 Jun 2011 00:09:24 +0100 (IST) Received: from [10.87.48.10] (unknown [86.42.18.245]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 3E613171C2D; Tue, 14 Jun 2011 00:09:24 +0100 (IST) Message-ID: <4DF69899.2050606@cs.tcd.ie> Date: Tue, 14 Jun 2011 00:09:13 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Stephen Farrell References: <4DEA6323.4070302@cs.tcd.ie> In-Reply-To: <4DEA6323.4070302@cs.tcd.ie> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org, ipv6@ietf.org, "saag@ietf.org" Subject: Re: [saag] ITU-T SG17 IPv6 security work items liaison X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 23:09:33 -0000 All, Thanks for the feedback on this liaison. Eliot (mostly) and I (a bit) have tried to capture all that in the text below. Please send any comments on that (with specific alternative text) in the next week and then we'll shoot it on to them. RFC 3514 does have some words about IPv6 - should I add that as a reference? :-) Thanks, Stephen. From: IETF Security Area To: Study Group 17, Questions 2 and 3 Title: Work on Security of IPv6 FOR ACTION The IETF thanks Study Group 17 for its liaison LS-206 "Liaison on IPv6 security issues". As the world transitions to IPv6, new opportunities and challenges and challenges arise. SG17's new focus on deployment and implementation considerations reflects this reality. We would like to bring to your attention the following work which we believe may prove a useful basis for both X.ipv6-secguide and X.mgv6: * RFC 4294 – "IPv6 Node Requirements" (N.B., this work is currently under revision) * draft-ietf-6man-node-req-bis (work in progress) – "IPv6 Node Requirements RFC 4294-bis" * RFC 4864 – "Local Network Protection for IPv6" * RFC 6092 – "Recommended Simple Security Capabilities in Customer Premise Equipment (CPE) for Providing Residential IPv6 Internet Service" * RFC 6105 – "IPv6 Router Advertisement Guard" * RFC 6106 – "IPv6 Router Advertisement Options for DNS Configuration", §7 in particular. As you are aware, every RFC contains a Security Considerations section. In developing either a implementation or deployment guide, contributors are strongly encouraged to review the RFCs and Internet-Drafts that support any underlying function. In addition, we bring to your attention the following IETF Working Groups that are working on security-related work of IPv6: Working Group Purpose Mailing list address Name 6man IPv6 Maintenance ipv6@ietf.org savi Source Address Validation savi@ietf.org Improvements dhc Dynamic Host Configuration dhcwg@ietf.org v6ops IPv6 Operations v6ops@ietf.org opsec Operational Security opsec@ietf.org Capabilities for an IP Network In addition to the above working groups, the Security Area of the IETF maintains a mailing list for general discussion, saag@ietf.org. We encourage and invite open and informal discussion in these or other relevant IETF fora on this very important topic. As with all IETF working groups, any and all interested parties can choose to directly contribute via the mailing lists above. As in other areas, the Security Area of the IETF invites SG17 to bring any new-found concerns about IETF protocols to our attention so that as and when we revise our documents we can make appropriate amendments to IETF protocols. In particular, as this planned work matures, we would welcome hearing about it in more detail, perhaps via an invited presentation at a saag meeting or via review of draft documents as may be appropriate. From housley@vigilsec.com Mon Jun 13 16:57:52 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D75419E800E; Mon, 13 Jun 2011 16:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.158 X-Spam-Level: X-Spam-Status: No, score=-102.158 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vfn96rGnbGjm; Mon, 13 Jun 2011 16:57:52 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 356ED9E8007; Mon, 13 Jun 2011 16:57:52 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 86079F241CB; Mon, 13 Jun 2011 19:58:16 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id 2zCri2Y+0vBM; Mon, 13 Jun 2011 19:57:50 -0400 (EDT) Received: from v234.vpn.iad.rg.net (v234.vpn.iad.rg.net [198.180.150.234]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 5A1EDF24166; Mon, 13 Jun 2011 19:58:15 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Russ Housley In-Reply-To: <4DF69899.2050606@cs.tcd.ie> Date: Mon, 13 Jun 2011 19:57:49 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DEA6323.4070302@cs.tcd.ie> <4DF69899.2050606@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org, ipv6@ietf.org, "saag@ietf.org" Subject: Re: [saag] ITU-T SG17 IPv6 security work items liaison X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 23:57:53 -0000 Stephen: Comments below. Russ > From: IETF Security Area > To: Study Group 17, Questions 2 and 3 > Title: Work on Security of IPv6 >=20 > FOR ACTION >=20 > The IETF thanks Study Group 17 for its liaison LS-206 "Liaison on IPv6 > security issues". As the world transitions to IPv6, new opportunities > and challenges and challenges arise. SG17's new focus on deployment = and s/and challenges and challenges/and challenges/ s/new// > implementation considerations reflects this reality. We would like = to > bring to your attention the following work which we believe may prove = a > useful basis for both X.ipv6-secguide and X.mgv6: >=20 > * RFC 4294 =96 "IPv6 Node Requirements" (N.B., this work is = currently > under revision) Why not just reference the bis document? > * draft-ietf-6man-node-req-bis (work in progress) =96 "IPv6 Node > Requirements RFC 4294-bis" > * RFC 4864 =96 "Local Network Protection for IPv6" > * RFC 6092 =96 "Recommended Simple Security Capabilities in = Customer > Premise Equipment (CPE) for Providing Residential IPv6 Internet > Service" > * RFC 6105 =96 "IPv6 Router Advertisement Guard" > * RFC 6106 =96 "IPv6 Router Advertisement Options for DNS > Configuration", =A77 in particular. >=20 > As you are aware, every RFC contains a Security Considerations = section. > In developing either a implementation or deployment guide, = contributors > are strongly encouraged to review the RFCs and Internet-Drafts that > support any underlying function. >=20 > In addition, we bring to your attention the following IETF Working > Groups that are working on security-related work of IPv6: >=20 > Working Group Purpose Mailing list address > Name >=20 > 6man IPv6 Maintenance ipv6@ietf.org > savi Source Address Validation savi@ietf.org > Improvements > dhc Dynamic Host Configuration dhcwg@ietf.org > v6ops IPv6 Operations v6ops@ietf.org > opsec Operational Security opsec@ietf.org > Capabilities for an IP > Network >=20 > In addition to the above working groups, the Security Area of the IETF > maintains a mailing list for general discussion, saag@ietf.org. We > encourage and invite open and informal discussion in these or other > relevant IETF fora on this very important topic. As with all IETF > working groups, any and all interested parties can choose to directly > contribute via the mailing lists above. >=20 > As in other areas, the Security Area of the IETF invites SG17 to bring > any new-found concerns about IETF protocols to our attention so that = as > and when we revise our documents we can make appropriate amendments to > IETF protocols. In particular, as this planned work matures, we would > welcome hearing about it in more detail, perhaps via an invited > presentation at a saag meeting or via review of draft documents as may > be appropriate. From stephen.farrell@cs.tcd.ie Mon Jun 13 17:01:28 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4ED321F8479; Mon, 13 Jun 2011 17:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.137 X-Spam-Level: X-Spam-Status: No, score=-106.137 tagged_above=-999 required=5 tests=[AWL=-0.138, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bF9AVgqOyG62; Mon, 13 Jun 2011 17:01:28 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id C8A9321F8478; Mon, 13 Jun 2011 17:01:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id EADA1171C57; Tue, 14 Jun 2011 01:01:23 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1308009683; bh=5brO03To29fhYd a07P2lJXC4KlbotzYy3H/AyOFPMvI=; b=qZt/PET7ZAxj8DkKgTGHIbGJ9tTFzM LKMYDCrZHssLdzupGCVfsRd7F6o0i9OrdgEZgCXBQa5YPb14k/Cv/CaaAoGh5N0l BPrSZx4k+LxZnLdYQ9jQ2a4J0uAHW6s/+6G9RelCis4qK5goaj5htY1CUTjnC5O3 zW9tG/n7Ki513g1FWAVLDpdSK5fXpJpoiF6Y7zE0kL6wyBZEe1VXRiiI9yZea2gB 7Guc0YOoX+BgSvxsQdYj1Wfcmbm0fppenhd4WHrLnIuwoOxHt5g7CTueKATRBLPF 48lEEW+Jr0FFL+tAVKthdOAcKJOgVKo5rMWGQNcn57Za3tHhiWPN24mg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id UIGQ1gVqZRlH; Tue, 14 Jun 2011 01:01:23 +0100 (IST) Received: from [10.87.48.10] (unknown [86.42.18.245]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 6417A171C2D; Tue, 14 Jun 2011 01:01:23 +0100 (IST) Message-ID: <4DF6A4D2.9060306@cs.tcd.ie> Date: Tue, 14 Jun 2011 01:01:22 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Russ Housley References: <4DEA6323.4070302@cs.tcd.ie> <4DF69899.2050606@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org, ipv6@ietf.org, "saag@ietf.org" Subject: Re: [saag] ITU-T SG17 IPv6 security work items liaison X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 00:01:28 -0000 Thanks Russ, will make those changes. S. On 14/06/11 00:57, Russ Housley wrote: > Stephen: > > Comments below. > > Russ > > >> From: IETF Security Area >> To: Study Group 17, Questions 2 and 3 >> Title: Work on Security of IPv6 >> >> FOR ACTION >> >> The IETF thanks Study Group 17 for its liaison LS-206 "Liaison on IPv6 >> security issues". As the world transitions to IPv6, new opportunities >> and challenges and challenges arise. SG17's new focus on deployment and > > s/and challenges and challenges/and challenges/ > s/new// > >> implementation considerations reflects this reality. We would like to >> bring to your attention the following work which we believe may prove a >> useful basis for both X.ipv6-secguide and X.mgv6: >> >> * RFC 4294 – "IPv6 Node Requirements" (N.B., this work is currently >> under revision) > > Why not just reference the bis document? > >> * draft-ietf-6man-node-req-bis (work in progress) – "IPv6 Node >> Requirements RFC 4294-bis" >> * RFC 4864 – "Local Network Protection for IPv6" >> * RFC 6092 – "Recommended Simple Security Capabilities in Customer >> Premise Equipment (CPE) for Providing Residential IPv6 Internet >> Service" >> * RFC 6105 – "IPv6 Router Advertisement Guard" >> * RFC 6106 – "IPv6 Router Advertisement Options for DNS >> Configuration", §7 in particular. >> >> As you are aware, every RFC contains a Security Considerations section. >> In developing either a implementation or deployment guide, contributors >> are strongly encouraged to review the RFCs and Internet-Drafts that >> support any underlying function. >> >> In addition, we bring to your attention the following IETF Working >> Groups that are working on security-related work of IPv6: >> >> Working Group Purpose Mailing list address >> Name >> >> 6man IPv6 Maintenance ipv6@ietf.org >> savi Source Address Validation savi@ietf.org >> Improvements >> dhc Dynamic Host Configuration dhcwg@ietf.org >> v6ops IPv6 Operations v6ops@ietf.org >> opsec Operational Security opsec@ietf.org >> Capabilities for an IP >> Network >> >> In addition to the above working groups, the Security Area of the IETF >> maintains a mailing list for general discussion, saag@ietf.org. We >> encourage and invite open and informal discussion in these or other >> relevant IETF fora on this very important topic. As with all IETF >> working groups, any and all interested parties can choose to directly >> contribute via the mailing lists above. >> >> As in other areas, the Security Area of the IETF invites SG17 to bring >> any new-found concerns about IETF protocols to our attention so that as >> and when we revise our documents we can make appropriate amendments to >> IETF protocols. In particular, as this planned work matures, we would >> welcome hearing about it in more detail, perhaps via an invited >> presentation at a saag meeting or via review of draft documents as may >> be appropriate. > > From pgut001@login01.cs.auckland.ac.nz Mon Jun 13 21:59:59 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9801F0C8C; Mon, 13 Jun 2011 21:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVokf5x1+QYJ; Mon, 13 Jun 2011 21:59:57 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 0F8401F0C82; Mon, 13 Jun 2011 21:59:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1308027597; x=1339563597; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20hallam@gmail.com,=20julian.reschke@gmx.de|Subject: =20Re:=20[saag]=20[websec]=20[http-auth]=20re-call=20for =20IETF=20http-auth=20BoF|Cc:=20http-auth@ietf.org,=20pub lic-identity@w3.org,=20saag@ietf.org,=0D=0A=20=20=20=20we bsec@ietf.org|In-Reply-To:=20|Message-Id:=20|Date:=20Tue,=2014=20Ju n=202011=2016:59:54=20+1200; bh=MuLKPw/XGt8/FxbjsT18BBlz9z5+VlWKDD31mvISxRs=; b=u8GyTUUZJnA+n4/Ubigmdb/xyqPe90Y+FrYU/aJN5u/o6DVEqGIHpvih zIKzySVlGGNfODw9OzvHpF9/bZ6BqGiQ8ELacqPQZQc+A5qdYyDa8B4W0 8J9sGPdoNSynDqAsmF2ubibn1qSVKQs1s5hLA9of67BBx49E4wPl+hzjx g=; X-IronPort-AV: E=Sophos;i="4.65,362,1304251200"; d="scan'208";a="67285743" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 14 Jun 2011 16:59:54 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QWLjG-0004Wb-Hf; Tue, 14 Jun 2011 16:59:54 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QWLjG-0007nd-EG; Tue, 14 Jun 2011 16:59:54 +1200 From: Peter Gutmann To: hallam@gmail.com, julian.reschke@gmx.de In-Reply-To: Message-Id: Date: Tue, 14 Jun 2011 16:59:54 +1200 Cc: public-identity@w3.org, http-auth@ietf.org, websec@ietf.org, saag@ietf.org Subject: Re: [saag] [websec] [http-auth] re-call for IETF http-auth BoF X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 04:59:59 -0000 Phillip Hallam-Baker writes: >what would we want HTTP authentication to look like? I have a suggestion for what it shouldn't look like: Any method that hands over the password (or a password-equivalent like a password in hashed form) as current browsers do should be banned outright, and anyone who implements hand-over-the-password should killed and eaten to prevent them from passing on the genes. The only permitted auth.form should be a dynamic, cryptographic mutual auth. that authenticates both the client and the server. There are endless designs for this sort of thing around so the precise form isn't too important, as long as it's not hand-over-the-password. Peter. From stephen.farrell@cs.tcd.ie Tue Jun 14 00:20:04 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D899611E8111; Tue, 14 Jun 2011 00:20:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.423 X-Spam-Level: X-Spam-Status: No, score=-105.423 tagged_above=-999 required=5 tests=[AWL=-0.820, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFC4dtBetRgx; Tue, 14 Jun 2011 00:20:03 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 39E2011E8070; Tue, 14 Jun 2011 00:20:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 5114715356B; Tue, 14 Jun 2011 08:19:56 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h=date :subject:from:x-mailer:message-id:content-type :content-transfer-encoding:mime-version:in-reply-to:references :received:received:x-virus-scanned; s=cs; t=1308035995; bh=2883g 9CmH7gUGjXVhpis5QtP7w9of6b9492MzLkdFx8=; b=GYUhs7mKtMTfTjB89UNZG IjQnCGr3w5fi3aNWPWmnMSIRIZMMbZpuLBvGaUxsC/p+XQGGWzlxD5wzBilYfUgW GTx9N/O1JQAVcrHOz6jOCMZa3xrECCkIpgj1UxMPkyhn98LS/myOwYMXj5Ot1FEr 5qltKMkd3hkLfxjsB59SaEY7huvTJa1CHd1KLR2zPu8QyTpYT1D2inmDIodxHZ8Z 99I/dM5xcOiMMOENkiW4OjHlmrN0PgRy3htmvq73O3nAU7kfM5sdieQDZOjZGr6v JYYb+qpfVSu9XoyryHhWt2xXXLgjKhCtMnGkQcVxS/uG8RcmbXbyVilKXwgNCNQA A== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id Pjz+6LKmtmjs; Tue, 14 Jun 2011 08:19:55 +0100 (IST) Received: from [10.87.48.6] (unknown [86.42.18.245]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id C321A15356A; Tue, 14 Jun 2011 08:19:54 +0100 (IST) References: <4DEA6323.4070302@cs.tcd.ie> <4DF69899.2050606@cs.tcd.ie> <22C01597-E89D-4200-8251-2F3979ABB0B6@gmail.com> In-Reply-To: <22C01597-E89D-4200-8251-2F3979ABB0B6@gmail.com> Mime-Version: 1.0 (iPhone Mail 8H7) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: X-Mailer: iPhone Mail (8H7) From: Stephen Farrell Date: Tue, 14 Jun 2011 08:19:52 +0100 To: Bob Hinden Cc: Bob Hinden , "v6ops@ietf.org" , "saag@ietf.org" , "ipv6@ietf.org" Subject: Re: [saag] [v6ops] ITU-T SG17 IPv6 security work items liaison X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 07:20:05 -0000 On 14 Jun 2011, at 05:51, Bob Hinden wrote: > Russ, >=20 > On Jun 14, 2011, at 2:57 AM, Russ Housley wrote: >=20 >> Stephen: >>=20 >> Comments below. >>=20 >> Russ >>=20 >>=20 >>> From: IETF Security Area >>> To: Study Group 17, Questions 2 and 3 >>> Title: Work on Security of IPv6 >>>=20 >>> FOR ACTION >>>=20 >>> The IETF thanks Study Group 17 for its liaison LS-206 "Liaison on IPv6 >>> security issues". As the world transitions to IPv6, new opportunities >>> and challenges and challenges arise. SG17's new focus on deployment and= >>=20 >> s/and challenges and challenges/and challenges/ >> s/new// >>=20 >>> implementation considerations reflects this reality. We would like to >>> bring to your attention the following work which we believe may prove a >>> useful basis for both X.ipv6-secguide and X.mgv6: >>>=20 >>> * RFC 4294 =E2=80=93 "IPv6 Node Requirements" (N.B., this work is curre= ntly >>> under revision) >>=20 >> Why not just reference the bis document? >=20 >>=20 >>> * draft-ietf-6man-node-req-bis (work in progress) =E2=80=93 "IPv6 Node >>> Requirements RFC 4294-bis" >=20 >=20 > The draft could also say that the working group has reached consensus and h= as submitted it to the IESG for publication on 25 May 2011. Will do, S >=20 > Bob >=20 >=20 >>> * RFC 4864 =E2=80=93 "Local Network Protection for IPv6" >>> * RFC 6092 =E2=80=93 "Recommended Simple Security Capabilities in Custo= mer >>> Premise Equipment (CPE) for Providing Residential IPv6 Internet >>> Service" >>> * RFC 6105 =E2=80=93 "IPv6 Router Advertisement Guard" >>> * RFC 6106 =E2=80=93 "IPv6 Router Advertisement Options for DNS >>> Configuration", =C2=A77 in particular. >>>=20 >>> As you are aware, every RFC contains a Security Considerations section. >>> In developing either a implementation or deployment guide, contributors >>> are strongly encouraged to review the RFCs and Internet-Drafts that >>> support any underlying function. >>>=20 >>> In addition, we bring to your attention the following IETF Working >>> Groups that are working on security-related work of IPv6: >>>=20 >>> Working Group Purpose Mailing list address >>> Name >>>=20 >>> 6man IPv6 Maintenance ipv6@ietf.org >>> savi Source Address Validation savi@ietf.org >>> Improvements >>> dhc Dynamic Host Configuration dhcwg@ietf.org >>> v6ops IPv6 Operations v6ops@ietf.org >>> opsec Operational Security opsec@ietf.org >>> Capabilities for an IP >>> Network >>>=20 >>> In addition to the above working groups, the Security Area of the IETF >>> maintains a mailing list for general discussion, saag@ietf.org. We >>> encourage and invite open and informal discussion in these or other >>> relevant IETF fora on this very important topic. As with all IETF >>> working groups, any and all interested parties can choose to directly >>> contribute via the mailing lists above. >>>=20 >>> As in other areas, the Security Area of the IETF invites SG17 to bring >>> any new-found concerns about IETF protocols to our attention so that as >>> and when we revise our documents we can make appropriate amendments to >>> IETF protocols. In particular, as this planned work matures, we would >>> welcome hearing about it in more detail, perhaps via an invited >>> presentation at a saag meeting or via review of draft documents as may >>> be appropriate. >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 From stephen.farrell@cs.tcd.ie Tue Jun 14 04:07:41 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 971D311E8097; Tue, 14 Jun 2011 04:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.045 X-Spam-Level: X-Spam-Status: No, score=-106.045 tagged_above=-999 required=5 tests=[AWL=0.554, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7lRRCT9lnv74; Tue, 14 Jun 2011 04:07:40 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id C9C7F11E8071; Tue, 14 Jun 2011 04:07:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id B1308171C03; Tue, 14 Jun 2011 12:07:18 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1308049638; bh=BR372cB96WaTSt J2eDtWqWz7b9GALC6jcCwc47ovgKg=; b=CIliRfxuv9AVgQ458vvKDKCI0SWR49 j1S6c21C/Z3gmv+Hg/SV4ToP93TDUARCbT3aj/TPilMLPES59RW6nJSHojfH0yqp DzTvfZ6aWY5gVHoLcYFfveHBOMPTv45y94UWlMINuh67BIb5go/UHFtWBQRCSmYB m+njLBm/Fp1IyS/1oGLL9MrDuMXYrk2idNFbP4S0m/6WWUi5qUjyA7Pj0EMjAfxG WKt9wkMxsno7B6UuQswtMkKUV9x8ol2Dw9ZDbCVoX8xqYs6hUjaDSK4nBvWaCvPU zh7vIcbki6nCFs4pznmo9AWk4RHM6ypHLJANq5jQm/IkQVZVYQRmwFdQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id bB+PEJkkE4sb; Tue, 14 Jun 2011 12:07:18 +0100 (IST) Received: from [134.226.36.137] (stephen-samy.dsg.cs.tcd.ie [134.226.36.137]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 63DD7171C01; Tue, 14 Jun 2011 12:07:17 +0100 (IST) Message-ID: <4DF740E5.4030309@cs.tcd.ie> Date: Tue, 14 Jun 2011 12:07:17 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Nick Hilliard References: <4DEA6323.4070302@cs.tcd.ie> <4DF69899.2050606@cs.tcd.ie> <4DF73138.6010009@inex.ie> In-Reply-To: <4DF73138.6010009@inex.ie> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: v6ops@ietf.org, ipv6@ietf.org, "saag@ietf.org" Subject: Re: [saag] [v6ops] ITU-T SG17 IPv6 security work items liaison X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 11:07:41 -0000 Thanks Nick, I'll add that unless someone tells me its a bad plan. Its a fairly fresh I-D, but I guess it looks pretty relevant all right. S. On 14/06/11 11:00, Nick Hilliard wrote: > On 14/06/2011 00:09, Stephen Farrell wrote: >> * RFC 6105 – "IPv6 Router Advertisement Guard" >> * RFC 6106 – "IPv6 Router Advertisement Options for DNS >> Configuration", §7 in particular. > > maybe mention draft-gont-v6ops-ra-guard-evasion? It's not a strategic > focused document, but gives specific advice on a specific issue which is > relevant to ipv6 lan deployments. > > Nick > From dhc2@dcrocker.net Tue Jun 14 07:52:24 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDAC211E8078 for ; Tue, 14 Jun 2011 07:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Huh9aemknp+E for ; Tue, 14 Jun 2011 07:52:24 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4070722801B for ; Tue, 14 Jun 2011 07:52:24 -0700 (PDT) Received: from [192.168.1.15] (adsl-67-127-56-68.dsl.pltn13.pacbell.net [67.127.56.68]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p5EEqD1v011563 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 14 Jun 2011 07:52:18 -0700 Message-ID: <4DF77596.20503@dcrocker.net> Date: Tue, 14 Jun 2011 07:52:06 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Stephen Farrell References: <4DF68E32.3040800@cs.tcd.ie> In-Reply-To: <4DF68E32.3040800@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 14 Jun 2011 07:52:19 -0700 (PDT) Cc: "saag@ietf.org" , draft-oreirdan-mody-bot-remediation@tools.ietf.org Subject: Re: [saag] AD sponsoring draft-oreirdan-mody-bot-remediation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 14:52:25 -0000 On 6/13/2011 3:24 PM, Stephen Farrell wrote: > To comment, either reply to this, or just mail me and the authors, > or just me if you're very shy:-) Folks, Since there's a considerable industry that's been working on anti-abuse and since the topic is not a major, on-going IETF activity, I thought it worth soliciting comments from APWG, since this sort of thing is their life. Here's a response that came back: > Subject: Re: [apwg] [saag] AD sponsoring draft-oreirdan-mody-bot-remediation > Date: Tue, 14 Jun 2011 08:53:48 -0400 > From: Maxim Weinstein > To: dcrocker@bbiw.net > CC: APWG > > > Dave, Neil, et. al., > > Back when this IETF draft came to my attention, I developed a set of comments, > which I shared with Mike O'Reirdan, and perhaps blogged about, at the time. > Those comments can be found at: > > https://docs.google.com/a/stopbadware.org/Doc?docid=0AXgXeriL62dYZGQ0cmY1Ym5fMTA0bTQ4bW00cg&hl=en > > > Regards, > Maxim -- Dave Crocker Brandenburg InternetWorking bbiw.net From bob.hinden@gmail.com Mon Jun 13 21:51:54 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39B9B11E8132; Mon, 13 Jun 2011 21:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_RECV_BEZEQINT_B=0.763, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pA8WQ1nMPHJp; Mon, 13 Jun 2011 21:51:53 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id D38A411E80BE; Mon, 13 Jun 2011 21:51:52 -0700 (PDT) Received: by wwk4 with SMTP id 4so3173310wwk.1 for ; Mon, 13 Jun 2011 21:51:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=6AThwAjNBVwPIKrUgpuFEpb/oXzGgDCcnmzweIpCl+Y=; b=NV3Qq92MVq0LJRz9+0UOFrFG20XgQ1OlawVA9896fKvBJ+SGYB1MPl6A9UZpQz+bhf GYbHxuoQe1pmqKTfhfA1Z4VTrXsKO8UKpgUWkhweRYrkNSEMJTUHIefMK5Abbvyh9S6u CziJVwgJMkI+N1l8fWDTRmbG/zWlu/5JzJQwc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=Kxho02N5kcfl28ZqEuMuPQJMjWGd5N7avksGSVy2VcIOyY0xTg7CFcujz7xHAVW67t j1Q5pqte8yl0jfy59w/po6+CXHVLLKatULLejgrzARwH9zXCDRQ0h/bAdHbw0bGiPkpo RWCteZJatH0jaxGP1FVvonGDmidwVujGB3TSc= Received: by 10.227.196.193 with SMTP id eh1mr5937739wbb.12.1308027098894; Mon, 13 Jun 2011 21:51:38 -0700 (PDT) Received: from [192.168.4.127] (bzq-218-39-93.cablep.bezeqint.net [81.218.39.93]) by mx.google.com with ESMTPS id fl19sm4717598wbb.49.2011.06.13.21.51.37 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 13 Jun 2011 21:51:38 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Bob Hinden In-Reply-To: Date: Tue, 14 Jun 2011 07:51:35 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <22C01597-E89D-4200-8251-2F3979ABB0B6@gmail.com> References: <4DEA6323.4070302@cs.tcd.ie> <4DF69899.2050606@cs.tcd.ie> To: Russ Housley X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Tue, 14 Jun 2011 08:01:52 -0700 Cc: ipv6@ietf.org, v6ops@ietf.org, Bob Hinden , "saag@ietf.org" Subject: Re: [saag] [v6ops] ITU-T SG17 IPv6 security work items liaison X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 04:51:54 -0000 Russ, On Jun 14, 2011, at 2:57 AM, Russ Housley wrote: > Stephen: >=20 > Comments below. >=20 > Russ >=20 >=20 >> From: IETF Security Area >> To: Study Group 17, Questions 2 and 3 >> Title: Work on Security of IPv6 >>=20 >> FOR ACTION >>=20 >> The IETF thanks Study Group 17 for its liaison LS-206 "Liaison on = IPv6 >> security issues". As the world transitions to IPv6, new = opportunities >> and challenges and challenges arise. SG17's new focus on deployment = and >=20 > s/and challenges and challenges/and challenges/ > s/new// >=20 >> implementation considerations reflects this reality. We would like = to >> bring to your attention the following work which we believe may prove = a >> useful basis for both X.ipv6-secguide and X.mgv6: >>=20 >> * RFC 4294 =96 "IPv6 Node Requirements" (N.B., this work is = currently >> under revision) >=20 > Why not just reference the bis document? >=20 >> * draft-ietf-6man-node-req-bis (work in progress) =96 "IPv6 Node >> Requirements RFC 4294-bis" The draft could also say that the working group has reached consensus = and has submitted it to the IESG for publication on 25 May 2011. Bob >> * RFC 4864 =96 "Local Network Protection for IPv6" >> * RFC 6092 =96 "Recommended Simple Security Capabilities in = Customer >> Premise Equipment (CPE) for Providing Residential IPv6 Internet >> Service" >> * RFC 6105 =96 "IPv6 Router Advertisement Guard" >> * RFC 6106 =96 "IPv6 Router Advertisement Options for DNS >> Configuration", =A77 in particular. >>=20 >> As you are aware, every RFC contains a Security Considerations = section. >> In developing either a implementation or deployment guide, = contributors >> are strongly encouraged to review the RFCs and Internet-Drafts that >> support any underlying function. >>=20 >> In addition, we bring to your attention the following IETF Working >> Groups that are working on security-related work of IPv6: >>=20 >> Working Group Purpose Mailing list address >> Name >>=20 >> 6man IPv6 Maintenance ipv6@ietf.org >> savi Source Address Validation savi@ietf.org >> Improvements >> dhc Dynamic Host Configuration dhcwg@ietf.org >> v6ops IPv6 Operations v6ops@ietf.org >> opsec Operational Security opsec@ietf.org >> Capabilities for an IP >> Network >>=20 >> In addition to the above working groups, the Security Area of the = IETF >> maintains a mailing list for general discussion, saag@ietf.org. We >> encourage and invite open and informal discussion in these or other >> relevant IETF fora on this very important topic. As with all IETF >> working groups, any and all interested parties can choose to directly >> contribute via the mailing lists above. >>=20 >> As in other areas, the Security Area of the IETF invites SG17 to = bring >> any new-found concerns about IETF protocols to our attention so that = as >> and when we revise our documents we can make appropriate amendments = to >> IETF protocols. In particular, as this planned work matures, we would >> welcome hearing about it in more detail, perhaps via an invited >> presentation at a saag meeting or via review of draft documents as = may >> be appropriate. >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nick@inex.ie Tue Jun 14 03:00:37 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5588121F85CC; Tue, 14 Jun 2011 03:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mFnPb+cqO35Y; Tue, 14 Jun 2011 03:00:36 -0700 (PDT) Received: from mail.acquirer.com (mail.acquirer.com [46.182.8.5]) by ietfa.amsl.com (Postfix) with ESMTP id C10AB21F85C7; Tue, 14 Jun 2011 03:00:35 -0700 (PDT) X-Envelope-To: saag@ietf.org Received: from cupcake.internal.acquirer.com (mail.acquirer.com [87.198.142.10] (may be forged)) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id p5EA0OHg041950 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 14 Jun 2011 11:00:25 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <4DF73138.6010009@inex.ie> Date: Tue, 14 Jun 2011 11:00:24 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110528 Thunderbird/5.0b1 MIME-Version: 1.0 To: Stephen Farrell References: <4DEA6323.4070302@cs.tcd.ie> <4DF69899.2050606@cs.tcd.ie> In-Reply-To: <4DF69899.2050606@cs.tcd.ie> X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Tue, 14 Jun 2011 08:01:52 -0700 Cc: v6ops@ietf.org, ipv6@ietf.org, "saag@ietf.org" Subject: Re: [saag] [v6ops] ITU-T SG17 IPv6 security work items liaison X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 10:00:37 -0000 On 14/06/2011 00:09, Stephen Farrell wrote: > * RFC 6105 – "IPv6 Router Advertisement Guard" > * RFC 6106 – "IPv6 Router Advertisement Options for DNS > Configuration", §7 in particular. maybe mention draft-gont-v6ops-ra-guard-evasion? It's not a strategic focused document, but gives specific advice on a specific issue which is relevant to ipv6 lan deployments. Nick From stephen.farrell@cs.tcd.ie Tue Jun 14 08:40:07 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0C6B11E8163 for ; Tue, 14 Jun 2011 08:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.131 X-Spam-Level: X-Spam-Status: No, score=-106.131 tagged_above=-999 required=5 tests=[AWL=0.468, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FeM5bgDzYEbv for ; Tue, 14 Jun 2011 08:40:07 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 3D46811E80B4 for ; Tue, 14 Jun 2011 08:40:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 650E9171C1D; Tue, 14 Jun 2011 16:40:01 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1308066001; bh=YEriAEHEXOWtm6 B2CWMksWyLJey1W/NcuCZTt0/FD7s=; b=vi5eip8F4QDNP3NJSnz9AncpkS0T5f ARYWZAJjeQW6uCLbkbQXzmSHTCPnoMeAK7nxtmSf2apABPf4XCq447sPXwXdgvm4 oyXYoVq9W4dLcGxQskn50nw1oc7EKAaZXTOzKQMpuB9x3RKjXagWcC4iA0bybcER tw5wE1DANnhRiwdRWoGYbofasQQmLFZ/QBo01apMafkA0N4PDv8D6QShWtpEcvXH +tp9xgoymCeBT8ok8Ojtw4C03ZP6VO+jE1p7LR5qxDxWwIG37ZRa+MEMon36HRds zz+HbBmYCqQK+Eg/Rl6Pa5Z2fyX2sun6FSye0qdZ6OnDzKxTx0JWRrYQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id lZO6QEEHwC0a; Tue, 14 Jun 2011 16:40:01 +0100 (IST) Received: from [134.226.36.137] (stephen-samy.dsg.cs.tcd.ie [134.226.36.137]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 8F551171C02; Tue, 14 Jun 2011 16:39:56 +0100 (IST) Message-ID: <4DF780CC.4050209@cs.tcd.ie> Date: Tue, 14 Jun 2011 16:39:56 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: dcrocker@bbiw.net References: <4DF68E32.3040800@cs.tcd.ie> <4DF77596.20503@dcrocker.net> In-Reply-To: <4DF77596.20503@dcrocker.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "saag@ietf.org" , draft-oreirdan-mody-bot-remediation@tools.ietf.org Subject: Re: [saag] AD sponsoring draft-oreirdan-mody-bot-remediation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 15:40:08 -0000 Thanks Dave, Those look like comments well worth considering to me. Authors? S. On 14/06/11 15:52, Dave CROCKER wrote: > > > On 6/13/2011 3:24 PM, Stephen Farrell wrote: >> To comment, either reply to this, or just mail me and the authors, >> or just me if you're very shy:-) > > > Folks, > > Since there's a considerable industry that's been working on anti-abuse > and since the topic is not a major, on-going IETF activity, I thought it > worth soliciting comments from APWG, since this sort of thing is their > life. > > Here's a response that came back: > > >> Subject: Re: [apwg] [saag] AD sponsoring >> draft-oreirdan-mody-bot-remediation >> Date: Tue, 14 Jun 2011 08:53:48 -0400 >> From: Maxim Weinstein >> To: dcrocker@bbiw.net >> CC: APWG >> >> >> Dave, Neil, et. al., >> >> Back when this IETF draft came to my attention, I developed a set of >> comments, >> which I shared with Mike O'Reirdan, and perhaps blogged about, at the >> time. >> Those comments can be found at: >> >> https://docs.google.com/a/stopbadware.org/Doc?docid=0AXgXeriL62dYZGQ0cmY1Ym5fMTA0bTQ4bW00cg&hl=en >> >> >> >> >> Regards, >> Maxim > > From nico@cryptonector.com Tue Jun 14 09:17:05 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE651F0C36; Tue, 14 Jun 2011 09:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.145 X-Spam-Level: X-Spam-Status: No, score=-2.145 tagged_above=-999 required=5 tests=[AWL=-1.968, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_14=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WLzm717IlfBL; Tue, 14 Jun 2011 09:17:04 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 09A811F0C34; Tue, 14 Jun 2011 09:17:04 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id 854A4202044; Tue, 14 Jun 2011 09:17:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=M6DhzyALUZaO3+DFAfH01txiCMUr08aVWvWhf43DgE6z DGGjVL9y0ZqpU0waS18LbaChz6h+Y//sgWriT3aGe5ENzY6DjAJ+DekdCC7M5S0Z bIdlHvcRQZD9OyQE5YLb130BidS59+qUsdU4fA0kR1y6AGJglWHijsmUDKKWdg8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=P8lX6P6P1u63ALqOYW3sNzZWs28=; b=NAkLObol6rO StYoelV3k8oM/zbd7rjLYQndqVYYR5mDt3TV6kN5LdQR7uUpG/LEhRf33SaHK6GQ lEkVM2uaGvfiD9lWAnTTHOxCFM4aaHn3l7VT4YVJQDadfOz9+fH7rkwrDD/Ns39J m/Zbp9ROOA/+6Wexc8OglTYrZ5QiCajg= Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id 07C9A202043; Tue, 14 Jun 2011 09:17:02 -0700 (PDT) Received: by pwi5 with SMTP id 5so2972364pwi.31 for ; Tue, 14 Jun 2011 09:17:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.14.103 with SMTP id o7mr3246236pbc.523.1308068222669; Tue, 14 Jun 2011 09:17:02 -0700 (PDT) Received: by 10.68.50.39 with HTTP; Tue, 14 Jun 2011 09:17:02 -0700 (PDT) In-Reply-To: References: Date: Tue, 14 Jun 2011 11:17:02 -0500 Message-ID: From: Nico Williams To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: julian.reschke@gmx.de, public-identity@w3.org, websec@ietf.org, http-auth@ietf.org, saag@ietf.org, hallam@gmail.com Subject: Re: [saag] [websec] [http-auth] re-call for IETF http-auth BoF X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 16:17:05 -0000 On Mon, Jun 13, 2011 at 11:59 PM, Peter Gutmann wrote: > Phillip Hallam-Baker writes: >>what would we want HTTP authentication to look like? > > I have a suggestion for what it shouldn't look like: Any method that hand= s > over the password (or a password-equivalent like a password in hashed for= m) as > current browsers do should be banned outright, and anyone who implements > hand-over-the-password should killed and eaten to prevent them from passi= ng on > the genes. +1. > The only permitted auth.form should be a dynamic, cryptographic mutual au= th. > that authenticates both the client and the server. =C2=A0There are endles= s designs > for this sort of thing around so the precise form isn't too important, as= long > as it's not hand-over-the-password. +1, particularly with regard to mutual authentication. It's important to understand that we need mutual authentication using something other than the TLS server cert PKI for authenticating the server. Some aspects of the designs are important. For example: - Is this to be done in TLS? HTTP? Or at the application-layer? IMO: TLS is too low a layer to do authentication in, and doing it in HTTP would require retrofitting too many HTTP stacks. Doing it at the application layer has a number of advantages. - Shall we have just one authentication mechanism? IMO: We can't pick a universal authentication mechanism that will work for everyone, but if it helps get momentum I'd be happy to specify something where we start with one mechanism but nothing prevents us from adding others later. Here's an example showing how to use SCRAM (a successor to DIGEST-MD5, thus not terribly interesting, but pretend for a second that this is a ZKPP) at the application layer and in a RESTful way: C->S: HTTP/1.1 POST /rest-gss-login Host: A.example Content-Type: application/rest-gss-login Content-Length: nnn SCRAM-SHA-1,,MIC n,,n=3Duser,r=3Dfyko+d2lbbFgONRv9qkxdawL S->C: HTTP/1.1 201 Location http://A.example/rest-gss-session-9d0af5f680d4ff46 Content-Type: application/rest-gss-login Content-Length: nnn C r=3Dfyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j, s=3DQSXCR+Q6sek8bf92,i=3D4096 C->S: HTTP/1.1 POST /rest-gss-session-9d0af5f680d4ff46 Host: A.example Content-Type: application/rest-gss-login Content-Length: nnn c=3Dbiws,r=3Dfyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j, p=3Dv0X8v3Bz2T0CJGbJQyF0X+HI4Ts=3D S->C: HTTP/1.1 200 Content-Type: application/rest-gss-login Content-Length: nnn A v=3DrmF9pqV8S7suAoZWja4dJRkFsKQ=3D Does that work for you? Nico -- From stephen.farrell@cs.tcd.ie Tue Jun 14 09:36:52 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99A0011E807F; Tue, 14 Jun 2011 09:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.001 X-Spam-Level: X-Spam-Status: No, score=-103.001 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_44=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9r4JtXOoA-DW; Tue, 14 Jun 2011 09:36:45 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 09E7E9E802E; Tue, 14 Jun 2011 09:36:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 6CE0B171C03; Tue, 14 Jun 2011 17:36:23 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h=date :subject:from:x-mailer:message-id:content-type :content-transfer-encoding:mime-version:in-reply-to:references :received:received:x-virus-scanned; s=cs; t=1308069382; bh=kqIm4 jHDs81NEcSSm4exH0reLW/jZ4nKCmvRSO3SNic=; b=Pw88SLOl1pzIHAWmCqRdJ AwQpCYzBatNawyjEo3KQaeO0cnEU2awaeyjQ0Mo6QZtM6z3aku0jx+auVkdnh6vh hVsNwNrMu5hogIRQTEfqk9br182gkrraCrFSqcTMFrH0sdSOme8lPewQvoARxVNV 8ifVOn6UcZ9WXwnjdwOwm+XTGLoBUwXAs/LWRqhVtpqK0oXPqY8vqW+WtOyztZqh BBOeOesHEQ18oVtiOynZGHQLQiphYHmO0t6tqpoQErYwuPItdbYm2X+pWaFeSwOP 0Vbg4xNUJ8wzIkYyJ1ly1hXPBCbh7SsT4BE30qC61JIMcUkIAjt2pJG2U5W6VPu0 g== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id Rxrh5psMVZHL; Tue, 14 Jun 2011 17:36:22 +0100 (IST) Received: from [10.52.30.188] (mobileinternet4.o2.ie [62.40.32.14]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 39620171C02; Tue, 14 Jun 2011 17:36:20 +0100 (IST) References: In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8H7) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8H7) From: Stephen Farrell Date: Tue, 14 Jun 2011 17:36:14 +0100 To: Nico Williams Cc: "public-identity@w3.org" , "http-auth@ietf.org" , "websec@ietf.org" , "saag@ietf.org" Subject: Re: [saag] [websec] [http-auth] re-call for IETF http-auth BoF X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 16:36:52 -0000 This is about http auth (and I'm glad to see the discussion) but can we keep= it to just that list?=20 Ta. S On 14 Jun 2011, at 17:17, Nico Williams wrote: > On Mon, Jun 13, 2011 at 11:59 PM, Peter Gutmann > wrote: >> Phillip Hallam-Baker writes: >>> what would we want HTTP authentication to look like? >>=20 >> I have a suggestion for what it shouldn't look like: Any method that hand= s >> over the password (or a password-equivalent like a password in hashed for= m) as >> current browsers do should be banned outright, and anyone who implements >> hand-over-the-password should killed and eaten to prevent them from passi= ng on >> the genes. >=20 > +1. >=20 >> The only permitted auth.form should be a dynamic, cryptographic mutual au= th. >> that authenticates both the client and the server. There are endless des= igns >> for this sort of thing around so the precise form isn't too important, as= long >> as it's not hand-over-the-password. >=20 > +1, particularly with regard to mutual authentication. It's important > to understand that we need mutual authentication using something other > than the TLS server cert PKI for authenticating the server. >=20 > Some aspects of the designs are important. >=20 > For example: >=20 > - Is this to be done in TLS? HTTP? Or at the application-layer? >=20 > IMO: TLS is too low a layer to do authentication in, and doing it in > HTTP would require retrofitting too many HTTP stacks. Doing it at the > application layer has a number of advantages. >=20 > - Shall we have just one authentication mechanism? >=20 > IMO: We can't pick a universal authentication mechanism that will work > for everyone, but if it helps get momentum I'd be happy to specify > something where we start with one mechanism but nothing prevents us > from adding others later. >=20 > Here's an example showing how to use SCRAM (a successor to DIGEST-MD5, > thus not terribly interesting, but pretend for a second that this is a > ZKPP) at the application layer and in a RESTful way: >=20 > C->S: HTTP/1.1 POST /rest-gss-login > Host: A.example > Content-Type: application/rest-gss-login > Content-Length: nnn >=20 > SCRAM-SHA-1,,MIC > n,,n=3Duser,r=3Dfyko+d2lbbFgONRv9qkxdawL >=20 > S->C: HTTP/1.1 201 > Location http://A.example/rest-gss-session-9d0af5f680d4ff46 > Content-Type: application/rest-gss-login > Content-Length: nnn >=20 > C > r=3Dfyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j, > s=3DQSXCR+Q6sek8bf92,i=3D4096 >=20 > C->S: HTTP/1.1 POST /rest-gss-session-9d0af5f680d4ff46 > Host: A.example > Content-Type: application/rest-gss-login > Content-Length: nnn >=20 > c=3Dbiws,r=3Dfyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j, > p=3Dv0X8v3Bz2T0CJGbJQyF0X+HI4Ts=3D >=20 > S->C: HTTP/1.1 200 > Content-Type: application/rest-gss-login > Content-Length: nnn >=20 > A > v=3DrmF9pqV8S7suAoZWja4dJRkFsKQ=3D >=20 >=20 > Does that work for you? >=20 > Nico > -- > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From rstruik.ext@gmail.com Tue Jun 14 16:13:56 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBFCB11E80A8 for ; Tue, 14 Jun 2011 16:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cufQxrxPepKJ for ; Tue, 14 Jun 2011 16:13:56 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1977211E807D for ; Tue, 14 Jun 2011 16:13:56 -0700 (PDT) Received: by qwc23 with SMTP id 23so3929740qwc.31 for ; Tue, 14 Jun 2011 16:13:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=fALoHvC9vq0ylGQommop+GkXuGsx4fZnObZNNBpjaAU=; b=jTHKLOPDr3mm+gNblEM7QL1d6tzmO40/ThUP7oB3nlLCs3smyX15994jcW38St10G8 1KpRVrn21GeZzQ2AIqlyQkuXtXRaXmpgqerHqm8eXX6Y4rkCk2PRdpLtpdKWnq4wYaLE uE6HhCa9F9rr+F04xBxrsueVUXFos7xKqdgHk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=QEieVGFfjhZk2YsoiM718mXMF6b9mPPoGvXmAsIrQoL/D0GSbNPifUdXhOOOBoQvsy fh6AaqjQ5bCctfbQoeSY8FrhnHJnjNg1NrMnnQuUUvb6peIS7teuJWQAGB4bNu2B+07g H+aEQ996OVCFERod11FXoR5yq3mhx887qiPkI= Received: by 10.224.189.9 with SMTP id dc9mr5674075qab.11.1308093232053; Tue, 14 Jun 2011 16:13:52 -0700 (PDT) Received: from [192.168.1.101] (CPE0013100e2c51-CM00186851d6f6.cpe.net.cable.rogers.com [99.231.117.243]) by mx.google.com with ESMTPS id u15sm5774424qcq.24.2011.06.14.16.13.50 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 14 Jun 2011 16:13:51 -0700 (PDT) Message-ID: <4DF7EB17.8090300@gmail.com> Date: Tue, 14 Jun 2011 19:13:27 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Sean Turner References: <4D9B2C20.6020604@cs.tcd.ie> <4DEE3A07.9010208@ieca.com> In-Reply-To: <4DEE3A07.9010208@ieca.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "saag@ietf.org" Subject: Re: [saag] Pick a saag presentation for Quebec... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 23:13:56 -0000 Dear Sean, Stephen: It may have merit to have more face-to-face time on each of the following: 1) efficient and secure crypto for small devices (think: Internet of Things). 2) security policies and key management architectures for small devices (right now, this overarching topic does not really have a "home", since cross-domain). 3) configuration/reconfiguration issues {obviously, can be thought off as part of [2] above}. I had a presentation at IETF-78 on ECC efficiency improvements, which could be thought of as promoting [1] above (or, more generally, "thwarting traditional arguments that public key crypto would be too expensive", for small and luxuriously unconstrained environments alike). The topic is much broader, though. I would be happy to produce and present material in either of these realms [1] and [2] during IETF-81, Quebec, QC, July 26-30, 2011. Intention is to keep this quite independent of existing protocols, but sketch on how this may fit in with what is already there and what is worth developing. My hope would be that there would be a clear path forward after that meeting (think: tree of basic documents, derived protocols to push things into, etc.). Best regards, Rene On 07/06/2011 10:47 AM, Sean Turner wrote: > We've not had any takers on this offer. We're still willing to > entertain topics. Don't be shy ;) > > spt > > On 4/5/11 10:50 AM, Stephen Farrell wrote: >> >> And while we're filling the saag folder. I'm sure we've all >> noted the general warmth with which many saag presentations >> have been greeted over the years:-) >> >> Next time, as an experiment, we'd like you to pick one of >> them. >> >> So, please send suggestions to the list, for topic and >> optionally presenter, ideally with the presenter's >> agreement, for a 20-30 minute slot and we'll see what >> folks here want to hear/talk about and whether we can >> arrange that. >> >> I guess suggestions before say June 5th should give us >> enough time to get stuff sorted. We'll figure some way >> to let you all help pick one after that. >> >> If this works ok, we'll keep it up. If not, then we >> won't. If we need to tweak things to make it work then >> we'll do that. >> >> Please keep the subject line intact for suggestions and >> discussions about picking a presentation. If discussion >> wanders off into the meat of a topic, then start a new >> thread. >> >> Thanks, >> Stephen. >> >> PS: Don't worry - the ADs will still pick some topics, so >> you won't lose the opportunity to ask how we could >> possibly be so dumb:-) >> >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >> > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag -- email: rstruik.ext@gmail.com Skype: rstruik cell: +1 (647) 867-5658 USA Google voice: +1 (415) 690-7363 From touch@isi.edu Tue Jun 14 17:17:48 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CCF81F0C5C; Tue, 14 Jun 2011 17:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.38 X-Spam-Level: X-Spam-Status: No, score=-101.38 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drapnSrBNONL; Tue, 14 Jun 2011 17:17:48 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id F167E1F0C5B; Tue, 14 Jun 2011 17:17:47 -0700 (PDT) Received: from [192.168.121.117] ([221.148.74.64]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id p5F0HIuB019915 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 14 Jun 2011 17:17:22 -0700 (PDT) Message-ID: <4DF7FA0D.6040201@isi.edu> Date: Tue, 14 Jun 2011 17:17:17 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Stephen Farrell References: <4DEA6323.4070302@cs.tcd.ie> <4DF69899.2050606@cs.tcd.ie> <4DF73138.6010009@inex.ie> <4DF740E5.4030309@cs.tcd.ie> In-Reply-To: <4DF740E5.4030309@cs.tcd.ie> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: v6ops@ietf.org, Nick Hilliard , ipv6@ietf.org, "saag@ietf.org" Subject: Re: [saag] [v6ops] ITU-T SG17 IPv6 security work items liaison X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 00:17:48 -0000 Hi, all, It'd be useful to wait until these docs (this v6ops one and the 6man one it refers) are adopted by the relevant WGs before noting them in recommendations to external parties, IMO. Some of the recommendations in these documents are akin to "if I didn't expect it, it's an attack", which I feel makes our protocols too brittle unless we are in a situation of known security compromise via other indicators. The latter doc (6man) also silently discards legitimate packets (complicating debugging), and ends up deprecating the entire extension header feature of IPv6 for all IPv6 signaling protocols - which seems like a bad idea overall. I'd prefer to see the relevant WGs endorse these as useful ways forward before adding them to this list. Joe On 6/14/2011 4:07 AM, Stephen Farrell wrote: > > Thanks Nick, > > I'll add that unless someone tells me its a bad plan. > Its a fairly fresh I-D, but I guess it looks pretty > relevant all right. > > S. > > On 14/06/11 11:00, Nick Hilliard wrote: >> On 14/06/2011 00:09, Stephen Farrell wrote: >>> * RFC 6105 – "IPv6 Router Advertisement Guard" >>> * RFC 6106 – "IPv6 Router Advertisement Options for DNS >>> Configuration", §7 in particular. >> >> maybe mention draft-gont-v6ops-ra-guard-evasion? It's not a strategic >> focused document, but gives specific advice on a specific issue which is >> relevant to ipv6 lan deployments. >> >> Nick >> > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From stephen.farrell@cs.tcd.ie Tue Jun 14 17:32:34 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F8B71F0C5C; Tue, 14 Jun 2011 17:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.125 X-Spam-Level: X-Spam-Status: No, score=-106.125 tagged_above=-999 required=5 tests=[AWL=-0.126, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7HrSUHMbfnGN; Tue, 14 Jun 2011 17:32:33 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8021F0C52; Tue, 14 Jun 2011 17:32:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 57F1615356D; Wed, 15 Jun 2011 01:32:25 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-type:in-reply-to:references:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1308097944; bh=hm1ypKE3WAatZ8Py/YHfyYJh V7QSXt//EGcxhiHf36M=; b=pQbq8nUS8l9leztQT5v1eIfT+jMfMxr3ki6J5zeN ppamvXPtwDbwtONnidLBHABaC9ukuOQDlkLoZMqGvpLk3tn2um1kBe3ziYk3zI4n jXz0xlsx38N/Ppw7Qq9Xmfo9IamFeC900s9GMWa3hM+VAOh6fIJaotnu2tB60sPc xW0o/lv9iiTBx7jN09yfrSaCwiKQP7S/3bHiGbrYYcYD2aqrO1X6MeO/KznI9QyP wOiz0ym5rQzT4rlJ0hXxXoPtuGx7lQbfK73TAELgSRU989MUHG9DEofGcj5zIrp3 p+Hm3JkpcfkTDtMCD79tNUR77CW5gIAxoYAbhCWTCiPr+Q== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id st0l0XVxzUVQ; Wed, 15 Jun 2011 01:32:24 +0100 (IST) Received: from [10.87.48.10] (unknown [86.46.27.52]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id D98F415356C; Wed, 15 Jun 2011 01:32:22 +0100 (IST) Message-ID: <4DF7FD96.9010700@cs.tcd.ie> Date: Wed, 15 Jun 2011 01:32:22 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Joe Touch References: <4DEA6323.4070302@cs.tcd.ie> <4DF69899.2050606@cs.tcd.ie> <4DF73138.6010009@inex.ie> <4DF740E5.4030309@cs.tcd.ie> <4DF7FA0D.6040201@isi.edu> In-Reply-To: <4DF7FA0D.6040201@isi.edu> X-Enigmail-Version: 1.1.1 Content-Type: multipart/mixed; boundary="------------020404050002030007000507" Cc: v6ops@ietf.org, Nick Hilliard , ipv6@ietf.org, "saag@ietf.org" Subject: Re: [saag] [v6ops] ITU-T SG17 IPv6 security work items liaison X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 00:32:34 -0000 This is a multi-part message in MIME format. --------------020404050002030007000507 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Joe, Fair point about the draft-gont document. I've taken it out for now. Which was the 6man I-D you meant? There are now two referenced thanks to recent comments and both are draft-ietf-6man so have presumably been adopted by the WG. My current version is attached following today's edits in case that helps. I've still not included rfc 3514 but the more iterations this takes, the more I'm getting more tempted:-) Thanks, S. On 15/06/11 01:17, Joe Touch wrote: > Hi, all, > > It'd be useful to wait until these docs (this v6ops one and the 6man one > it refers) are adopted by the relevant WGs before noting them in > recommendations to external parties, IMO. > > Some of the recommendations in these documents are akin to "if I didn't > expect it, it's an attack", which I feel makes our protocols too brittle > unless we are in a situation of known security compromise via other > indicators. The latter doc (6man) also silently discards legitimate > packets (complicating debugging), and ends up deprecating the entire > extension header feature of IPv6 for all IPv6 signaling protocols - > which seems like a bad idea overall. > > I'd prefer to see the relevant WGs endorse these as useful ways forward > before adding them to this list. > > Joe > > On 6/14/2011 4:07 AM, Stephen Farrell wrote: >> >> Thanks Nick, >> >> I'll add that unless someone tells me its a bad plan. >> Its a fairly fresh I-D, but I guess it looks pretty >> relevant all right. >> >> S. >> >> On 14/06/11 11:00, Nick Hilliard wrote: >>> On 14/06/2011 00:09, Stephen Farrell wrote: >>>> * RFC 6105 – "IPv6 Router Advertisement Guard" >>>> * RFC 6106 – "IPv6 Router Advertisement Options for DNS >>>> Configuration", §7 in particular. >>> >>> maybe mention draft-gont-v6ops-ra-guard-evasion? It's not a strategic >>> focused document, but gives specific advice on a specific issue which is >>> relevant to ipv6 lan deployments. >>> >>> Nick >>> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag > --------------020404050002030007000507 Content-Type: text/plain; name="ituipv6lia.txt" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="ituipv6lia.txt" From: IETF Security Area To: Study Group 17, Questions 2 and 3 Title: Work on Security of IPv6 FOR ACTION The IETF thanks Study Group 17 for its liaison LS-206 "Liaison on IPv6 security issues". As the world transitions to IPv6, new opportunities and challenges arise. SG17's focus on deployment and implementation considerations reflects this reality. We would like to bring to your attention the following work which we believe may prove a useful basis for both X.ipv6-secguide and X.mgv6: * RFC 4294 – "IPv6 Node Requirements" (N.B., this work is currently under revision as draft-ietf-6man-node-req-bis, submitted to the IESG for approval on 2011-05-25) * draft-ietf-6man-node-req-bis (work in progress) – "IPv6 Node Requirements RFC 4294-bis" * RFC 4864 – "Local Network Protection for IPv6" * RFC 4942 - "IPv6 Transition/Coexistence Security Considerations" * RFC 6092 – "Recommended Simple Security Capabilities in Customer Premise Equipment (CPE) for Providing Residential IPv6 Internet Service" * RFC 6105 – "IPv6 Router Advertisement Guard" * RFC 6106 – "IPv6 Router Advertisement Options for DNS Configuration", §7 in particular. As you are aware, every RFC contains a Security Considerations section. In developing either an implementation or deployment guide, contributors are strongly encouraged to review the RFCs and Internet-Drafts that support any underlying function. In addition, we bring to your attention the following IETF Working Groups that are working on IPv6 security-related work: Working Group Purpose Mailing list address Name 6man IPv6 Maintenance ipv6@ietf.org savi Source Address Validation savi@ietf.org Improvements dhc Dynamic Host Configuration dhcwg@ietf.org v6ops IPv6 Operations v6ops@ietf.org opsec Operational Security opsec@ietf.org Capabilities for an IP Network In addition to the above working groups, the Security Area of the IETF maintains a mailing list for general discussion, saag@ietf.org. We encourage and invite open and informal discussion in these or other relevant IETF fora on this very important topic. As with all IETF working groups, any and all interested parties can choose to directly contribute via the mailing lists above. As in other areas, the Security Area of the IETF invites SG17 to bring any new-found concerns about IETF protocols to our attention so that as and when we revise our documents we can make appropriate amendments to IETF protocols. In particular, as this planned work matures, we would welcome hearing about it in more detail, perhaps via an invited presentation at a saag meeting or via review of draft documents as may be appropriate. --------------020404050002030007000507-- From touch@isi.edu Tue Jun 14 17:36:08 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32EA221F84F1; Tue, 14 Jun 2011 17:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.994 X-Spam-Level: X-Spam-Status: No, score=-101.994 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mUStbJKOsrRO; Tue, 14 Jun 2011 17:36:07 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id A46F521F84EA; Tue, 14 Jun 2011 17:36:07 -0700 (PDT) Received: from [192.168.121.117] ([221.148.74.90]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id p5F0Zn26026673 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 14 Jun 2011 17:35:54 -0700 (PDT) Message-ID: <4DF7FE65.9070303@isi.edu> Date: Tue, 14 Jun 2011 17:35:49 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Stephen Farrell References: <4DEA6323.4070302@cs.tcd.ie> <4DF69899.2050606@cs.tcd.ie> <4DF73138.6010009@inex.ie> <4DF740E5.4030309@cs.tcd.ie> <4DF7FA0D.6040201@isi.edu> <4DF7FD96.9010700@cs.tcd.ie> In-Reply-To: <4DF7FD96.9010700@cs.tcd.ie> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: v6ops@ietf.org, Nick Hilliard , ipv6@ietf.org, "saag@ietf.org" Subject: Re: [saag] [v6ops] ITU-T SG17 IPv6 security work items liaison X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 00:36:08 -0000 On 6/14/2011 5:32 PM, Stephen Farrell wrote: > > Hi Joe, > > Fair point about the draft-gont document. I've taken it out > for now. > > Which was the 6man I-D you meant? The one ref'd inside the draft-gont-v6ops doc - it's draft-gont-6man... There aren't issues with the draft-ietf-6man docs. Joe > There are now two referenced > thanks to recent comments and both are draft-ietf-6man so have > presumably been adopted by the WG. > > My current version is attached following today's edits in case > that helps. > > I've still not included rfc 3514 but the more iterations this > takes, the more I'm getting more tempted:-) > > Thanks, > S. > > On 15/06/11 01:17, Joe Touch wrote: >> Hi, all, >> >> It'd be useful to wait until these docs (this v6ops one and the 6man one >> it refers) are adopted by the relevant WGs before noting them in >> recommendations to external parties, IMO. >> >> Some of the recommendations in these documents are akin to "if I didn't >> expect it, it's an attack", which I feel makes our protocols too brittle >> unless we are in a situation of known security compromise via other >> indicators. The latter doc (6man) also silently discards legitimate >> packets (complicating debugging), and ends up deprecating the entire >> extension header feature of IPv6 for all IPv6 signaling protocols - >> which seems like a bad idea overall. >> >> I'd prefer to see the relevant WGs endorse these as useful ways forward >> before adding them to this list. >> >> Joe >> >> On 6/14/2011 4:07 AM, Stephen Farrell wrote: >>> >>> Thanks Nick, >>> >>> I'll add that unless someone tells me its a bad plan. >>> Its a fairly fresh I-D, but I guess it looks pretty >>> relevant all right. >>> >>> S. >>> >>> On 14/06/11 11:00, Nick Hilliard wrote: >>>> On 14/06/2011 00:09, Stephen Farrell wrote: >>>>> * RFC 6105 – "IPv6 Router Advertisement Guard" >>>>> * RFC 6106 – "IPv6 Router Advertisement Options for DNS >>>>> Configuration", §7 in particular. >>>> >>>> maybe mention draft-gont-v6ops-ra-guard-evasion? It's not a strategic >>>> focused document, but gives specific advice on a specific issue which is >>>> relevant to ipv6 lan deployments. >>>> >>>> Nick >>>> >>> _______________________________________________ >>> saag mailing list >>> saag@ietf.org >>> https://www.ietf.org/mailman/listinfo/saag >> From stephen.farrell@cs.tcd.ie Tue Jun 14 18:02:11 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5821F0C65; Tue, 14 Jun 2011 18:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.903 X-Spam-Level: X-Spam-Status: No, score=-105.903 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5EtotTQsjj7q; Tue, 14 Jun 2011 18:02:10 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 91D1B1F0C61; Tue, 14 Jun 2011 18:02:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 875E015356D; Wed, 15 Jun 2011 02:02:03 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1308099723; bh=Mj2C9ZnZ69N5v0 UR7zepE5rS2tIrBtpD/aIBFkclXrI=; b=1P9h3C9rJYdTOHdmCCtUtc43CJlsrc +wtzP4tEkZbqA+rQfYpu1s5VYtcK/AXOvyHC8wkSYiCrDtM1MrDiHlB9TNJSjkok 9L+CN8TiBIVjvtP5fz6jEQy8DCHm5oe2KvHOe3cwXDWFrOv6lDQLq/CVCrZW57ZY LD/GQoJS16qQ4FPna4she1X1SIUtUBNdFiBtGyRqpywKazPpWDNXHAkwiUdzp5bO O7aLIDfel+UdfAvtYVtZOuMf6kr2Aq8ztfkol2jF/F/blHPVLoksZ4STQmJCGIHA 4jcMTaTilXO86ksmo3rR1EzNr7ftZCzS8+JmBmCz+/Zk6AU7L/UUBLDA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id rJIjJSlGLEuV; Wed, 15 Jun 2011 02:02:03 +0100 (IST) Received: from [10.87.48.10] (unknown [86.46.27.52]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 5361B15356B; Wed, 15 Jun 2011 02:02:00 +0100 (IST) Message-ID: <4DF8047D.9000209@cs.tcd.ie> Date: Wed, 15 Jun 2011 02:01:49 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Fred Baker References: <4DEA6323.4070302@cs.tcd.ie> <4DF69899.2050606@cs.tcd.ie> <4DF77E98.8030300@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" , "ipv6@ietf.org" , Suresh Krishnan , "saag@ietf.org" Subject: Re: [saag] ITU-T SG17 IPv6 security work items liaison X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 01:02:11 -0000 All, On 15/06/11 01:42, Fred Baker wrote: > > On Jun 14, 2011, at 8:30 AM, Suresh Krishnan wrote: > >> RFC5157 IPv6 Implications for Network Scanning > > Personally, I think that RFC has been overtaken by events. Network scans have been reported in the wild. Ok, that's not currently included and given its not clear (to me at least) I'm gonna leave it out. I think we've accumulated enough references at this point - its never going to be a complete list and even if it attempted to be such, it'd probably be so long as to be useless. So I'm no longer taking additional reference recommendations unless a whole bunch of people say the same thing and otherwise I'm gonna stick with the current list as sent in a reply to Joe Touch a few minutes ago. If there're text edits that are *needed* then I'll take those for a couple of days more but I reckon we've iterated enough here. Thanks for all the help with this, I think we're done now basically. Cheers, S. From bkihara.l@gmail.com Wed Jun 15 02:44:38 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6437F11E810E; Wed, 15 Jun 2011 02:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.744 X-Spam-Level: X-Spam-Status: No, score=-2.744 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id akVtq69ceNwG; Wed, 15 Jun 2011 02:44:37 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id C988711E8083; Wed, 15 Jun 2011 02:44:37 -0700 (PDT) Received: by pzk5 with SMTP id 5so123735pzk.31 for ; Wed, 15 Jun 2011 02:44:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Z6RqmxXDDYraRdQTDVasR9YrGFA5q0a4p694l5ZaNAo=; b=H7FdSdYBHUTUvljKTe7f23zaDsYNF3Oo5a8HTHnZpK04xY4wR3AI5BdIoM8g5qxBhV aIAjJ5KJ6NMdnvsdUehfh6WB/nZOiDEN/jIiVdfXOi4Nk5zjDw2R210mfOCxPLMBK11G 81Hbnqe/rAaD63Q8CNHQwjlLatQZC7w7NkqUM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=vIgUFkqoK38ynXz9ZFo9A3gtU2j6GXC9cu4wE4baRQUPdK6u0/gr8lrIKnIThqsTmg AZ8vkCBQIDgmeGdWFuQ/kIYGT5T7wIiUuNCyS5hsGQo1x2HcncTJyn9D0s+4PKBjUYj8 AVW4e14RdVPXuxjbNFwa46QMDIksaxjK6QmHU= MIME-Version: 1.0 Received: by 10.142.43.4 with SMTP id q4mr46697wfq.403.1308131077129; Wed, 15 Jun 2011 02:44:37 -0700 (PDT) Received: by 10.142.50.6 with HTTP; Wed, 15 Jun 2011 02:44:37 -0700 (PDT) In-Reply-To: References: Date: Wed, 15 Jun 2011 18:44:37 +0900 Message-ID: From: "KIHARA, Boku" To: Peter Gutmann , http-auth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: public-identity@w3.org, websec@ietf.org, saag@ietf.org Subject: Re: [saag] [websec] [http-auth] re-call for IETF http-auth BoF X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 09:44:38 -0000 2011/6/14 Peter Gutmann : > Phillip Hallam-Baker writes: > >>what would we want HTTP authentication to look like? > > I have a suggestion for what it shouldn't look like: Any method that hand= s > over the password (or a password-equivalent like a password in hashed for= m) as > current browsers do should be banned outright, and anyone who implements > hand-over-the-password should killed and eaten to prevent them from passi= ng on > the genes. +1. To make the goal clear, let's list what kind of authentication methods should be avoided. One item is methods that hand over passwords, mentioned by Peter. Let me add methods whose UI can be imitated and the result can be forged by malicious sites. Like a padlock icon that insists the session is secured by TLS inside content area, Is a _secure_ authentication method inside content area truly reliable? * a method that hands over a password (or a password-equivalent) * a method whose UI can be imitated by malicious sites. Of course there might be more items, please append. # Peter, sorry for missing Ccs. -- KIHARA, Boku 2011/6/14 Peter Gutmann : > Phillip Hallam-Baker writes: > >>what would we want HTTP authentication to look like? > > I have a suggestion for what it shouldn't look like: Any method that hand= s > over the password (or a password-equivalent like a password in hashed for= m) as > current browsers do should be banned outright, and anyone who implements > hand-over-the-password should killed and eaten to prevent them from passi= ng on > the genes. > > The only permitted auth.form should be a dynamic, cryptographic mutual au= th. > that authenticates both the client and the server. =A0There are endless d= esigns > for this sort of thing around so the precise form isn't too important, as= long > as it's not hand-over-the-password. > > Peter. > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From bkihara.l@gmail.com Wed Jun 15 06:42:08 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1DA311E8149; Wed, 15 Jun 2011 06:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJ4rgJIDej6Q; Wed, 15 Jun 2011 06:42:08 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA2E11E8126; Wed, 15 Jun 2011 06:42:08 -0700 (PDT) Received: by pvh18 with SMTP id 18so328974pvh.31 for ; Wed, 15 Jun 2011 06:42:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=EcJ17BR2lt3kRBLXsf2Q1auz6i3BQSHDKkxW5H1XMDI=; b=jKIexr+LBGmM7+AE6WF901awmITrRutLH/oeeKcoIqEiERN7etShI3SEemdv/nzKUk uW1WoogBOZN811CuumN2ltLznpkZ+iJBshpSWEiq61Q8GzjloGNm2cbPYk5CaameJdEn yMnTcDan9YO2jlDo82+Vs9v87rTsY7T2OUcnQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=DEcpfC8RnCItC4zwi8LUnSmhKkXyn9J5tPMfHkWaRO2Frw/Sau9UsvK3POfMjhjtZF i2wxR2PoT9N/NAqffA4rJE7NLMtTYn9nk8ChGhrgbFrnvZ0tGnoxQ/9Q69TGDFHWxsWo RnTo2QyzzlMgF1BfWT7FgrxVdM4qB4wuEubao= MIME-Version: 1.0 Received: by 10.142.226.15 with SMTP id y15mr100697wfg.232.1308145326248; Wed, 15 Jun 2011 06:42:06 -0700 (PDT) Received: by 10.142.50.6 with HTTP; Wed, 15 Jun 2011 06:42:06 -0700 (PDT) In-Reply-To: References: Date: Wed, 15 Jun 2011 22:42:06 +0900 Message-ID: From: "KIHARA, Boku" To: http-auth@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: public-identity-request@w3.org, websec@ietf.org, saag@ietf.org Subject: [saag] Fwd: [websec] [http-auth] re-call for IETF http-auth BoF X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 13:42:08 -0000 Missing Ccs? Forwarding: ---------- Forwarded message ---------- From: David S. Misell MBCS CISSP <07710380044@o2.co.uk> Date: 2011/6/15 Subject: RE: [saag] [websec] [http-auth] re-call for IETF http-auth BoF To: "KIHARA, Boku" One time passwords should still be OK for poor auth methods, There is a series of SecurID based RFCs Kind Regards dave -original message- Subject: Re: [saag] [websec] [http-auth] re-call for IETF http-auth BoF From: "KIHARA, Boku" Date: 15/06/2011 10:45 am 2011/6/14 Peter Gutmann : > Phillip Hallam-Baker writes: > >>what would we want HTTP authentication to look like? > > I have a suggestion for what it shouldn't look like: Any method that hand= s > over the password (or a password-equivalent like a password in hashed for= m) as > current browsers do should be banned outright, and anyone who implements > hand-over-the-password should killed and eaten to prevent them from passi= ng on > the genes. +1. To make the goal clear, let's list what kind of authentication methods should be avoided. One item is methods that hand over passwords, mentioned by Peter. Let me add methods whose UI can be imitated and the result can be forged by malicious sites. Like a padlock icon that insists the session is secured by TLS inside content area, Is a _secure_ authentication method inside content area truly reliable? * a method that hands over a password (or a password-equivalent) * a method whose UI can be imitated by malicious sites. Of course there might be more items, please append. # Peter, sorry for missing Ccs. -- KIHARA, Boku 2011/6/14 Peter Gutmann : > Phillip Hallam-Baker writes: > >>what would we want HTTP authentication to look like? > > I have a suggestion for what it shouldn't look like: Any method that hand= s > over the password (or a password-equivalent like a password in hashed for= m) as > current browsers do should be banned outright, and anyone who implements > hand-over-the-password should killed and eaten to prevent them from passi= ng on > the genes. > > The only permitted auth.form should be a dynamic, cryptographic mutual au= th. > that authenticates both the client and the server. =A0There are endless d= esigns > for this sort of thing around so the precise form isn't too important, as= long > as it's not hand-over-the-password. > > Peter. > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From tlr@w3.org Wed Jun 15 06:44:26 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDA511E8145; Wed, 15 Jun 2011 06:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1qGXV3OW28X; Wed, 15 Jun 2011 06:44:26 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 0B1E911E8126; Wed, 15 Jun 2011 06:44:25 -0700 (PDT) Received: from [88.207.143.141] (helo=[192.168.2.114]) by jay.w3.org with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1QWqOO-0002p8-OV; Wed, 15 Jun 2011 09:44:25 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Thomas Roessler In-Reply-To: Date: Wed, 15 Jun 2011 15:44:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "KIHARA, Boku" X-Mailer: Apple Mail (2.1084) Cc: public-identity@w3.org, http-auth@ietf.org, websec@ietf.org, saag@ietf.org Subject: Re: [saag] [websec] Fwd: [http-auth] re-call for IETF http-auth BoF X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 13:44:26 -0000 Make that public-identity@w3.org, not public-identity-request@w3.org. ;) -- Thomas Roessler, W3C (@roessler) On 2011-06-15, at 15:42 , KIHARA, Boku wrote: > Missing Ccs? Forwarding: >=20 > ---------- Forwarded message ---------- > From: David S. Misell MBCS CISSP <07710380044@o2.co.uk> > Date: 2011/6/15 > Subject: RE: [saag] [websec] [http-auth] re-call for IETF http-auth = BoF > To: "KIHARA, Boku" >=20 >=20 > One time passwords should still be OK for poor auth methods, There is > a series of SecurID based RFCs > Kind Regards > dave >=20 > -original message- > Subject: Re: [saag] [websec] [http-auth] re-call for IETF http-auth = BoF > From: "KIHARA, Boku" > Date: 15/06/2011 10:45 am >=20 > 2011/6/14 Peter Gutmann : >> Phillip Hallam-Baker writes: >>=20 >>> what would we want HTTP authentication to look like? >>=20 >> I have a suggestion for what it shouldn't look like: Any method that = hands >> over the password (or a password-equivalent like a password in hashed = form) as >> current browsers do should be banned outright, and anyone who = implements >> hand-over-the-password should killed and eaten to prevent them from = passing on >> the genes. >=20 > +1. >=20 > To make the goal clear, let's list what kind of authentication methods > should be avoided. One item is methods that hand over passwords, > mentioned by Peter. Let me add methods whose UI can be imitated and > the result can be forged by malicious sites. Like a padlock icon that > insists the session is secured by TLS inside content area, Is a = _secure_ > authentication method inside content area truly reliable? >=20 > * a method that hands over a password (or a password-equivalent) > * a method whose UI can be imitated by malicious sites. >=20 > Of course there might be more items, please append. >=20 > # Peter, sorry for missing Ccs. >=20 > -- > KIHARA, Boku >=20 > 2011/6/14 Peter Gutmann : >> Phillip Hallam-Baker writes: >>=20 >>> what would we want HTTP authentication to look like? >>=20 >> I have a suggestion for what it shouldn't look like: Any method that = hands >> over the password (or a password-equivalent like a password in hashed = form) as >> current browsers do should be banned outright, and anyone who = implements >> hand-over-the-password should killed and eaten to prevent them from = passing on >> the genes. >>=20 >> The only permitted auth.form should be a dynamic, cryptographic = mutual auth. >> that authenticates both the client and the server. There are endless = designs >> for this sort of thing around so the precise form isn't too = important, as long >> as it's not hand-over-the-password. >>=20 >> Peter. >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >>=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec >=20 From nico@cryptonector.com Wed Jun 15 07:17:28 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA70411E8122; Wed, 15 Jun 2011 07:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.014 X-Spam-Level: X-Spam-Status: No, score=-3.014 tagged_above=-999 required=5 tests=[AWL=-1.037, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4JRsB65gO8y; Wed, 15 Jun 2011 07:17:28 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA4611E8126; Wed, 15 Jun 2011 07:17:28 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id D88C72F407A; Wed, 15 Jun 2011 07:17:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=wSwspyTudS/X49eHq4yl+ 9Gk+P/41ChapW+tjx6gLG4BjjfLi53xxzeaRN6v9mnNMs+wPm0pzj+0MAQi23P42 ZLPTiyUmqit33V2T9Ut9yVDh6f95xgneam85zEHT/ZDgs7SkCt+cqm1eyEF2dUvR 2mTzYBJ1tyLJH31dfE1B5g= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=eUh8lQHLzyvX+JNOWocc CIg63dA=; b=f3qdqyDTSWEulQTzB/GCrO4OfCvtC5GUEsS5FAb/3VHkH64TSqO9 CZ0VuLqrLgxXc8RERWdSntUv6y03RDdOFXeNBBho8m8i+pbIlYcVrw9NshaFUlnW kYs0Gq3Pq8SqnB3uWQWPt0sft8oTsSaBtHNkDq70vPiGu4NZq8FCeKg= Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPSA id AC33E2F4076; Wed, 15 Jun 2011 07:17:27 -0700 (PDT) Received: by pvh18 with SMTP id 18so365616pvh.31 for ; Wed, 15 Jun 2011 07:17:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.41.65 with SMTP id d1mr326960pbl.255.1308147447157; Wed, 15 Jun 2011 07:17:27 -0700 (PDT) Received: by 10.68.50.39 with HTTP; Wed, 15 Jun 2011 07:17:26 -0700 (PDT) In-Reply-To: References: Date: Wed, 15 Jun 2011 09:17:26 -0500 Message-ID: From: Nico Williams To: "KIHARA, Boku" Content-Type: text/plain; charset=UTF-8 Cc: public-identity@w3.org, http-auth@ietf.org, websec@ietf.org, saag@ietf.org Subject: Re: [saag] [http-auth] [websec] re-call for IETF http-auth BoF X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 14:17:29 -0000 On Wed, Jun 15, 2011 at 4:44 AM, KIHARA, Boku wrote: > To make the goal clear, let's list what kind of authentication methods > should be avoided. One item is methods that hand over passwords, > mentioned by Peter. Let me add methods whose UI can be imitated and > the result can be forged by malicious sites. Like a padlock icon that > insists the session is secured by TLS inside content area, Is a _secure_ > authentication method inside content area truly reliable? > > * a method that hands over a password (or a password-equivalent) > * a method whose UI can be imitated by malicious sites. The protocol and UI are not that closely related. I can't think of any method that satisfies the first requirement that couldn't have a secure UI. Nico -- From yutaka-oiwa-aist-temp@g.oiwa.jp Wed Jun 15 07:32:34 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8234C11E8122; Wed, 15 Jun 2011 07:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.885 X-Spam-Level: X-Spam-Status: No, score=-2.885 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4V5d0z9ErsH; Wed, 15 Jun 2011 07:32:34 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id CC30111E80A9; Wed, 15 Jun 2011 07:32:33 -0700 (PDT) Received: by yxt33 with SMTP id 33so441341yxt.31 for ; Wed, 15 Jun 2011 07:32:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.13.17 with SMTP id 17mr870058ybm.394.1308148353251; Wed, 15 Jun 2011 07:32:33 -0700 (PDT) Sender: yutaka@g.oiwa.jp X-Google-Sender-Delegation: yutaka@g.oiwa.jp Received: by 10.151.103.4 with HTTP; Wed, 15 Jun 2011 07:32:32 -0700 (PDT) In-Reply-To: References: Date: Wed, 15 Jun 2011 23:32:32 +0900 X-Google-Sender-Auth: qJq8zE8oN7vb9v05HcDSM661CcM Message-ID: From: Yutaka OIWA To: Nico Williams Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: http-auth@ietf.org, websec@ietf.org, public-identity@w3.org, saag@ietf.org Subject: Re: [saag] [http-auth] [websec] re-call for IETF http-auth BoF X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 14:32:34 -0000 2011/6/15 Nico Williams : >> * a method that hands over a password (or a password-equivalent) >> * a method whose UI can be imitated by malicious sites. > The protocol and UI are not that closely related. =A0I can't think of > any method that satisfies the first requirement that couldn't have a > secure UI. How about a simple form-field extension which encrypts some password with timed challenges? OK, but your point suggests the following rephrasing: * a UI which can be imitated by malicious sites. Although they are not closely related, but we cannot completely ignore the UI issues . I think that protocol designs should, in some extent, consider how such UI is to be provided (especially when and how they are kicked in). How about it? From suresh.krishnan@ericsson.com Tue Jun 14 08:34:24 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD2F311E813E; Tue, 14 Jun 2011 08:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.21 X-Spam-Level: X-Spam-Status: No, score=-106.21 tagged_above=-999 required=5 tests=[AWL=-0.211, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id egDgaaoeXu04; Tue, 14 Jun 2011 08:34:23 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 82CAB11E80B0; Tue, 14 Jun 2011 08:34:21 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p5EFYDKn017018 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Jun 2011 10:34:14 -0500 Received: from [142.133.10.107] (147.117.20.214) by eusaamw0711.eamcs.ericsson.se (147.117.20.179) with Microsoft SMTP Server id 8.3.137.0; Tue, 14 Jun 2011 11:34:13 -0400 Message-ID: <4DF77E98.8030300@ericsson.com> Date: Tue, 14 Jun 2011 11:30:32 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Stephen Farrell References: <4DEA6323.4070302@cs.tcd.ie> <4DF69899.2050606@cs.tcd.ie> In-Reply-To: <4DF69899.2050606@cs.tcd.ie> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Wed, 15 Jun 2011 08:04:13 -0700 Cc: "v6ops@ietf.org" , "ipv6@ietf.org" , "saag@ietf.org" Subject: Re: [saag] ITU-T SG17 IPv6 security work items liaison X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 15:34:25 -0000 Hi Stephen, Please consider adding the following RFCs to the list. RFC3756 IPv6 Neighbor Discovery (ND) Trust Models and Threats RFC4890 Recommendations for Filtering ICMPv6 Messages in Firewalls RFC4942 IPv6 Transition/Co-existence Security Considerations RFC5157 IPv6 Implications for Network Scanning Thanks Suresh On 11-06-13 07:09 PM, Stephen Farrell wrote: > All, > > Thanks for the feedback on this liaison. Eliot (mostly) > and I (a bit) have tried to capture all that in the > text below. Please send any comments on that (with > specific alternative text) in the next week and then > we'll shoot it on to them. > > RFC 3514 does have some words about IPv6 - should I > add that as a reference? :-) > > Thanks, > Stephen. > > From: IETF Security Area > To: Study Group 17, Questions 2 and 3 > Title: Work on Security of IPv6 > > FOR ACTION > > The IETF thanks Study Group 17 for its liaison LS-206 "Liaison on IPv6 > security issues". As the world transitions to IPv6, new opportunities > and challenges and challenges arise. SG17's new focus on deployment and > implementation considerations reflects this reality. We would like to > bring to your attention the following work which we believe may prove a > useful basis for both X.ipv6-secguide and X.mgv6: > > * RFC 4294 – "IPv6 Node Requirements" (N.B., this work is currently > under revision) > * draft-ietf-6man-node-req-bis (work in progress) – "IPv6 Node > Requirements RFC 4294-bis" > * RFC 4864 – "Local Network Protection for IPv6" > * RFC 6092 – "Recommended Simple Security Capabilities in Customer > Premise Equipment (CPE) for Providing Residential IPv6 Internet > Service" > * RFC 6105 – "IPv6 Router Advertisement Guard" > * RFC 6106 – "IPv6 Router Advertisement Options for DNS > Configuration", §7 in particular. > > As you are aware, every RFC contains a Security Considerations section. > In developing either a implementation or deployment guide, contributors > are strongly encouraged to review the RFCs and Internet-Drafts that > support any underlying function. > > In addition, we bring to your attention the following IETF Working > Groups that are working on security-related work of IPv6: > > Working Group Purpose Mailing list address > Name > > 6man IPv6 Maintenance ipv6@ietf.org > savi Source Address Validation savi@ietf.org > Improvements > dhc Dynamic Host Configuration dhcwg@ietf.org > v6ops IPv6 Operations v6ops@ietf.org > opsec Operational Security opsec@ietf.org > Capabilities for an IP > Network > > In addition to the above working groups, the Security Area of the IETF > maintains a mailing list for general discussion, saag@ietf.org. We > encourage and invite open and informal discussion in these or other > relevant IETF fora on this very important topic. As with all IETF > working groups, any and all interested parties can choose to directly > contribute via the mailing lists above. > > As in other areas, the Security Area of the IETF invites SG17 to bring > any new-found concerns about IETF protocols to our attention so that as > and when we revise our documents we can make appropriate amendments to > IETF protocols. In particular, as this planned work matures, we would > welcome hearing about it in more detail, perhaps via an invited > presentation at a saag meeting or via review of draft documents as may > be appropriate. > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From jason_livingood@cable.comcast.com Tue Jun 14 09:43:36 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25D2711E80F3 for ; Tue, 14 Jun 2011 09:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.656 X-Spam-Level: X-Spam-Status: No, score=-101.656 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s+zxUr2c7vKG for ; Tue, 14 Jun 2011 09:43:35 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 7C99711E807F for ; Tue, 14 Jun 2011 09:43:35 -0700 (PDT) Received: from ([24.40.55.42]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.40562655; Tue, 14 Jun 2011 10:46:38 -0600 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%12]) with mapi id 14.01.0289.001; Tue, 14 Jun 2011 12:43:13 -0400 From: "Livingood, Jason" To: Stephen Farrell , Dave Crocker Thread-Topic: [saag] AD sponsoring draft-oreirdan-mody-bot-remediation Thread-Index: AQHMKhjQog7N15huE0uBsxl66AZ975S9NB4AgAANXQD//86pAA== Date: Tue, 14 Jun 2011 16:43:12 +0000 Message-ID: In-Reply-To: <4DF780CC.4050209@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 x-originating-ip: [24.40.55.72] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 15 Jun 2011 08:04:13 -0700 Cc: "Mody, Nirmal" , "saag@ietf.org" Subject: Re: [saag] AD sponsoring draft-oreirdan-mody-bot-remediation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 16:43:36 -0000 I think we may have done so before, but we'll look at them again and respond. Jason On 6/14/11 11:39 AM, "Stephen Farrell" wrote: > >Thanks Dave, > >Those look like comments well worth considering to me. >Authors? > >S. > > >On 14/06/11 15:52, Dave CROCKER wrote: >>=20 >>=20 >> On 6/13/2011 3:24 PM, Stephen Farrell wrote: >>> To comment, either reply to this, or just mail me and the authors, >>> or just me if you're very shy:-) >>=20 >>=20 >> Folks, >>=20 >> Since there's a considerable industry that's been working on anti-abuse >> and since the topic is not a major, on-going IETF activity, I thought it >> worth soliciting comments from APWG, since this sort of thing is their >> life. >>=20 >> Here's a response that came back: >>=20 >>=20 >>> Subject: Re: [apwg] [saag] AD sponsoring >>> draft-oreirdan-mody-bot-remediation >>> Date: Tue, 14 Jun 2011 08:53:48 -0400 >>> From: Maxim Weinstein >>> To: dcrocker@bbiw.net >>> CC: APWG >>> >>> >>> Dave, Neil, et. al., >>> >>> Back when this IETF draft came to my attention, I developed a set of >>> comments, >>> which I shared with Mike O'Reirdan, and perhaps blogged about, at the >>> time. >>> Those comments can be found at: >>> >>>=20 >>>https://docs.google.com/a/stopbadware.org/Doc?docid=3D0AXgXeriL62dYZGQ0c= mY >>>1Ym5fMTA0bTQ4bW00cg&hl=3Den >>> >>>=20 >>>>>Y1Ym5fMTA0bTQ4bW00cg&hl=3Den> >>> >>> >>> Regards, >>> Maxim >>=20 >>=20 From fred@cisco.com Tue Jun 14 17:42:37 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D54D821F8542; Tue, 14 Jun 2011 17:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.754 X-Spam-Level: X-Spam-Status: No, score=-110.754 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BjYh4GmzLyLD; Tue, 14 Jun 2011 17:42:36 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 6C97921F8541; Tue, 14 Jun 2011 17:42:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=219; q=dns/txt; s=iport; t=1308098556; x=1309308156; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=Z/RESjri8B8J6elnS7oB+jzBCx5V7NSIkXFMNCI4P8Q=; b=Gain37CwW6NXckQ3uB15n1eweBu2kDijkjBnqYfzLO/+RpAJdJyFfEic qH/yu/qyf6px5CRtxxJXUDoAFc5OrWahi0Jvfpm/FIO9VOP1QlWojStHY b+03EYfEbizNp6Ktv6dTKUpWaiOXRMT/YbiZu3UPGb7jIuNhk7JnEy0oo k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMj/902rRDoI/2dsb2JhbABSplF3iHOhLp44hiYEhxWKNIRZizU X-IronPort-AV: E=Sophos;i="4.65,368,1304294400"; d="scan'208";a="465551729" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-1.cisco.com with ESMTP; 15 Jun 2011 00:42:34 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5F0gTVE030497; Wed, 15 Jun 2011 00:42:34 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Tue, 14 Jun 2011 17:42:34 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Tue, 14 Jun 2011 17:42:34 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <4DF77E98.8030300@ericsson.com> Date: Tue, 14 Jun 2011 17:42:18 -0700 Message-Id: References: <4DEA6323.4070302@cs.tcd.ie> <4DF69899.2050606@cs.tcd.ie> <4DF77E98.8030300@ericsson.com> To: Suresh Krishnan X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 15 Jun 2011 08:04:13 -0700 Cc: "v6ops@ietf.org" , "ipv6@ietf.org" , "saag@ietf.org" Subject: Re: [saag] ITU-T SG17 IPv6 security work items liaison X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 00:42:38 -0000 On Jun 14, 2011, at 8:30 AM, Suresh Krishnan wrote: > RFC5157 IPv6 Implications for Network Scanning Personally, I think that RFC has been overtaken by events. Network scans = have been reported in the wild.= From tjc@ecs.soton.ac.uk Wed Jun 15 02:45:37 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B00F121F8489; Wed, 15 Jun 2011 02:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[AWL=2.499, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OTP3JbvN7e+s; Wed, 15 Jun 2011 02:45:36 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1BE21F84DE; Wed, 15 Jun 2011 02:45:34 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p5F9iNF5030547; Wed, 15 Jun 2011 10:44:23 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk p5F9iNF5030547 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1308131063; bh=ZmTv3KiCfclrWyN5WvZkuPEk1ts=; h=References:In-Reply-To:Mime-Version:Cc:From:Subject:Date:To; b=Lr9LLzGKMi7Pl+TSo9GKXoMS92/zjfH2RffRFdMqh1pw048cdM8SAyThjI2irA6wZ tAV1FKD9MAUUvLWX/KVzSKNkVb4gTTCVGA07jUznprfdoM2dUow0GRAJTJlzbCM8iM NY0Tl/8Zljq877cIv9w45M07I40dRkp/3eBL9Fps= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP id n5EAiN0521310575Og ret-id none; Wed, 15 Jun 2011 10:44:23 +0100 Received: from cerf.ecs.soton.ac.uk (cerf.ecs.soton.ac.uk [152.78.69.39]) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p5F9iE7U028888 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 15 Jun 2011 10:44:15 +0100 References: <4DEA6323.4070302@cs.tcd.ie> <4DF69899.2050606@cs.tcd.ie> <4DF77E98.8030300@ericsson.com> <86015668-D0FC-4D85-B078-74E6AB096D56@ecs.soton.ac.uk> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-17--888627372 Message-ID: From: Tim Chown Date: Wed, 15 Jun 2011 10:44:14 +0100 To: Fred Baker X-Mailer: Apple Mail (2.1084) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=n5EAiN052131057500; tid=n5EAiN0521310575Og; client=relay,ipv6; mail=; rcpt=; nrcpt=6:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: p5F9iNF5030547 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk X-Mailman-Approved-At: Wed, 15 Jun 2011 08:04:13 -0700 Cc: "v6ops@ietf.org" , "ipv6@ietf.org" , Suresh Krishnan , "saag@ietf.org" Subject: Re: [saag] [v6ops] ITU-T SG17 IPv6 security work items liaison X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 09:45:37 -0000 --Apple-Mail-17--888627372 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 15 Jun 2011, at 01:42, Fred Baker wrote: >=20 > On Jun 14, 2011, at 8:30 AM, Suresh Krishnan wrote: >=20 >> RFC5157 IPv6 Implications for Network Scanning >=20 > Personally, I think that RFC has been overtaken by events. Network = scans have been reported in the wild. I just re-read the abstract and conclusion to 5157, and I think = everything stated there still applies. The bit where we stated that we'd not seen traditional network scanning = at our own site (to ::1, ::2, etc) is the part that has = changed - we could now say there is some evidence of such activity. But = that doesn't invalidate the advice to - for example - not have your = DHCPv6 pools start with ::1, or the observation that attackers = will look at other ways to glean addresses, with some discussion of = those. The interesting newly discussed issue since 5157 was published is the = possible impact on ND caches of scanning dark space, should such sweeps = reach the target subnet/link. WRT the ITU-T doc, I agree it's probably not needed. Tim --Apple-Mail-17--888627372 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On = Jun 14, 2011, at 8:30 AM, Suresh Krishnan wrote:

RFC5157 IPv6 Implications for Network = Scanning

Personally, I think that RFC has been = overtaken by events. Network scans have been reported in the wild.

I = just re-read the abstract and conclusion to 5157, and I think everything = stated there still applies.

The bit where we = stated that we'd not seen traditional network scanning at our own site = (to <prefix>::1, <prefix>::2, etc) is the part that has = changed - we could now say there is some evidence of such activity. =  But that doesn't invalidate the advice to - for example - not have = your DHCPv6 pools start with <prefix>::1, or the observation that = attackers will look at other ways to glean addresses, with some = discussion of those.

The interesting newly = discussed issue since 5157 was published is the possible impact on ND = caches of scanning dark space, should such sweeps reach the target = subnet/link.

WRT the ITU-T doc, I agree it's = probably not = needed.

Tim

= --Apple-Mail-17--888627372-- From lear@cisco.com Wed Jun 15 08:10:49 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4811011E80DC; Wed, 15 Jun 2011 08:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08MdA-6Q18xq; Wed, 15 Jun 2011 08:10:48 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 07D2811E8117; Wed, 15 Jun 2011 08:10:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=646; q=dns/txt; s=iport; t=1308150648; x=1309360248; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=2c/Ay7D0sEraqeWcowjTYMYOVsjeqe/n+VpClTuipdo=; b=h0EGVtRlNS90wnM2wft3DcfmBVo0VHuV3j0ahp1mwEpuMhj8Cxcpzf9f Wh8ZMW10qbtGz8ww84xg2nzY6ftcQe1Y04ukzRiJXftPNMVjHgh/V0kW9 fVQbIkjbBQHSTHNYQ4smdTXM4V+okxAyUaeDo3T3RJ3STd15XrqzNqxms Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOPK+E2Q/khM/2dsb2JhbABSEIQ5ogh3qTuNK5EQgSuDcYEKBJFOjzs3 X-IronPort-AV: E=Sophos;i="4.65,370,1304294400"; d="scan'208";a="94113869" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 15 Jun 2011 15:10:42 +0000 Received: from dhcp-10-61-101-58.cisco.com (dhcp-10-61-101-58.cisco.com [10.61.101.58]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5FFAfst016460; Wed, 15 Jun 2011 15:10:42 GMT Message-ID: <4DF8CB71.3060806@cisco.com> Date: Wed, 15 Jun 2011 17:10:41 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Joe Touch References: <4DEA6323.4070302@cs.tcd.ie> <4DF69899.2050606@cs.tcd.ie> <4DF73138.6010009@inex.ie> <4DF740E5.4030309@cs.tcd.ie> <4DF7FA0D.6040201@isi.edu> In-Reply-To: <4DF7FA0D.6040201@isi.edu> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, Nick Hilliard , ipv6@ietf.org, "saag@ietf.org" Subject: Re: [saag] [v6ops] ITU-T SG17 IPv6 security work items liaison X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 15:10:49 -0000 Joe, A suggestion just on this one point: > I'd prefer to see the relevant WGs endorse these as useful ways > forward before adding them to this list. > It is good for the IETF to provide the ITU's membership an opportunity to comment either formally via the liaison process or informally as individuals before work is finalized, just as we would like that opportunity. So long as we are clear on the status of the work, and the work can reasonably be construed as relevant, it's okay to mention it. Now, how should one apply my advice (which is what this is) to your suggestion? Regards, Eliot From stephen.farrell@cs.tcd.ie Thu Jun 16 01:58:44 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06ADD11E811A for ; Thu, 16 Jun 2011 01:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LDBTT4iaVYFG for ; Thu, 16 Jun 2011 01:58:43 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE4B11E80F0 for ; Thu, 16 Jun 2011 01:58:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id D4DDC171C20; Thu, 16 Jun 2011 09:58:37 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1308214717; bh=53amja//YmF4U4 5oyVAtR0PvZzjX+rcKno2kyir1GMg=; b=ViC7vmIhYta1C6lOV1Pc1Zza7KKJAR Ha9MdjZ71QkTwGwoeLlSCEQOW0skzFQBd57/RkiSqg0DigDS4dv3kh+HUyumeeKd XsJFe7ata0H/CHPVI5hCaz756Eh48PX/lvK82m2hgnlPkEPCNlFbpTw5TlOglmfF WNy/HqWC0owVIsopT+/vaSSYG2J2npFRKeOPZY98eAi6mW7CCClkvfurrhjcyQTU JSMb/rEFvjGgmai5uZsWtDp7coWiusxb8MpfTP1NCsEUHwjRfRfVwV8D/Lenysv9 SXBb3paxs8jzSwJowX8dZk1fF0DUkUj0zM1hdeUGKyDuVpa6jW4x1MXQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id DeV1KACK1Gs3; Thu, 16 Jun 2011 09:58:37 +0100 (IST) Received: from [134.226.36.137] (stephen-samy.dsg.cs.tcd.ie [134.226.36.137]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 1B29C171BFE; Thu, 16 Jun 2011 09:58:32 +0100 (IST) Message-ID: <4DF9C5B8.2000108@cs.tcd.ie> Date: Thu, 16 Jun 2011 09:58:32 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Fred Baker References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Ron Bonica , Jari Arkko , Ralph Droms , "v6ops-chairs@tools.ietf.org Chairs" , saag@ietf.org Subject: Re: [saag] Looking for guidance re draft-gont-v6ops-ra-guard-evasion X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 08:58:44 -0000 Hi Fred, On 16/06/11 01:11, Fred Baker wrote: > I have a request from the authors to present draft-gont-v6ops-ra-guard-evasion in v6ops. The document describes two ways that a motivated attacker could attack RA-Guard (RFC 6105). For the first, he postulates that an RA Guard implementation might look at the first "Next Header" field rather than parsing the full IPv6 header, and as a result an attacker could slide his rogue RA by using a Destination Options header. In the second, he observes that if he fragments the message, the switch will be unlikely to be able to parse it because it can't reassemble it. > > The observations are legitimately true; an implementation that takes shortcuts is likely to miss cases, and fragmentation has that effect. It also seems like the observations are (a) generic to IPv6 datagrams, not just RA messages, and (b) not something an operator can do much about. Hence, I question the value of the draft to the operational community. It seems like a better fit to the security area or to 6man, who might be in a position to do something about it. Yeah, I had a look at this when it was mentioned for that ITU-T liaison and I see what you mean. I guess an operator could look out for this, but can't do much more if their kit is vulnerable. I'd say if this isn't a v6ops thing then its more one for Ralph and Jari though - for example, if someone found a (non-crypto) problem with a SIP header I reckon we'd deal with that to somewhere in RAI and I think this is similar, so 6man looks to me more appropriate than the security area if it doesn't belong in v6ops. Maybe another way to look at it would be to ask what RFC it might UPDATE and then have it land wherever that came from? Cheers, S. > > Looking for advice... From turners@ieca.com Thu Jun 16 04:57:25 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1760A1F0C35 for ; Thu, 16 Jun 2011 04:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.822 X-Spam-Level: X-Spam-Status: No, score=-101.822 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cs2Fq+9odbwG for ; Thu, 16 Jun 2011 04:57:24 -0700 (PDT) Received: from nm6.bullet.mail.sp2.yahoo.com (nm6.bullet.mail.sp2.yahoo.com [98.139.91.76]) by ietfa.amsl.com (Postfix) with SMTP id B8DDA1F0C34 for ; Thu, 16 Jun 2011 04:57:24 -0700 (PDT) Received: from [98.139.91.69] by nm6.bullet.mail.sp2.yahoo.com with NNFMP; 16 Jun 2011 11:57:24 -0000 Received: from [98.139.91.52] by tm9.bullet.mail.sp2.yahoo.com with NNFMP; 16 Jun 2011 11:57:24 -0000 Received: from [127.0.0.1] by omp1052.mail.sp2.yahoo.com with NNFMP; 16 Jun 2011 11:57:24 -0000 X-Yahoo-Newman-Id: 680510.45901.bm@omp1052.mail.sp2.yahoo.com Received: (qmail 67383 invoked from network); 16 Jun 2011 11:57:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1308225444; bh=GKYWZXzklDi5IKPpuMToHgSbMHfrqCXuLWUwXKwnWnA=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=u/3nHzBe3ZQkleVEQUH8zoc/O1COqAX+vGyNn3ZENuhQnXxS6pv0Z+2sSRLSXgeTKXMfluhopEdmkfoPHIHavdxr0zHfvwluSSIEpGQlb8DanQi+hdsUiZTTl8wCF30GPApkkejbsoAe3/MQQYl/yv9ORvBawDj9ZsjkyCAWfLg= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: m_VbLjsVM1kz5TJbhVDQ.mkaAFmVjEqLfE2PbMe1tERECGg bt1FfIbgKo4tM6YeFQcBnad.4s2zal5olt99wfYAq8jbLYz7Ped3548mDPsC EjJjEKPkBF6mDM.rZEDk82ntb_GR3Y9cnaZxOMGRU7UvnC.TwkANOalwTcTP fiKOH0VGFLSovUeASVlhKkTBuVZc4FRYK0C83ztdODcP3qLjaAzPfZdpuv1l mSGkaa7n.hvUthxRWHTCC6E3hCcvNgWFt7g0EohleAYaQWPBFjRIIbOozloW HVLsAaGmf4PK_826flYsHxkiHPE_i6zljh.G0toMxiWQr1nIWZhX.7Sesvd6 mACsZKyEx.Pj5bsE4MMw3sueY3fKr2kghn8.At5O8k5o- X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ Received: from thunderfish.local (turners@96.231.129.74 with plain) by smtp112.biz.mail.sp1.yahoo.com with SMTP; 16 Jun 2011 04:57:24 -0700 PDT Message-ID: <4DF9EFA1.6090502@ieca.com> Date: Thu, 16 Jun 2011 07:57:21 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Fred Baker References: <4DF9C5B8.2000108@cs.tcd.ie> In-Reply-To: <4DF9C5B8.2000108@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ron Bonica , Jari Arkko , saag@ietf.org, "v6ops-chairs@tools.ietf.org Chairs" , Ralph Droms Subject: Re: [saag] Looking for guidance re draft-gont-v6ops-ra-guard-evasion X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 11:57:25 -0000 On 6/16/11 4:58 AM, Stephen Farrell wrote: > > Hi Fred, > > On 16/06/11 01:11, Fred Baker wrote: >> I have a request from the authors to present draft-gont-v6ops-ra-guard-evasion in v6ops. The document describes two ways that a motivated attacker could attack RA-Guard (RFC 6105). For the first, he postulates that an RA Guard implementation might look at the first "Next Header" field rather than parsing the full IPv6 header, and as a result an attacker could slide his rogue RA by using a Destination Options header. In the second, he observes that if he fragments the message, the switch will be unlikely to be able to parse it because it can't reassemble it. >> >> The observations are legitimately true; an implementation that takes shortcuts is likely to miss cases, and fragmentation has that effect. It also seems like the observations are (a) generic to IPv6 datagrams, not just RA messages, and (b) not something an operator can do much about. Hence, I question the value of the draft to the operational community. It seems like a better fit to the security area or to 6man, who might be in a position to do something about it. snip > Maybe another way to look at it would be to ask what > RFC it might UPDATE and then have it land wherever that > came from? This was where I was going. spt From ondrej.sury@nic.cz Thu Jun 16 07:56:38 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D9E39E800B for ; Thu, 16 Jun 2011 07:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U9dAe9uLk5f4 for ; Thu, 16 Jun 2011 07:56:37 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE299E800A for ; Thu, 16 Jun 2011 07:56:37 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617] (unknown [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617]) by mail.nic.cz (Postfix) with ESMTPSA id 4E0962A2C20 for ; Thu, 16 Jun 2011 16:56:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1308236196; bh=8AXn2Or9FIrAcBucyABRpdSbAes28KOt4hNn09WqH8g=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=de06e/7atD9imrYYs1lmB/sV+10CRf4JpwiP5ytrCIhpW8Z+7J5XjDgr1HEERsqkS QK8VQ0STfecQ8qsgosOkKIGFgh1ZcLUUS3EsHJOvKLq302fK5kIxs4IfQmemD8rKQo +lNl7mS1ZuohFGsFw2SdGw7A0PiCgUZCP8fWZ+q0= Message-ID: <4DFA19A4.70301@nic.cz> Date: Thu, 16 Jun 2011 16:56:36 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: "saag@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: [saag] Fwd: New Version Notification for draft-os-ietf-sshfp-ecdsa-sha2-00.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 14:56:38 -0000 Dear colleagues, since it was brought up in some discussion about SSHFP (and DNSSEC) as missing I took a liberty of updating DNS SSHFP Resource Records with ECDSA algorithm (as described in RFC 5656) and also updated the hash algorithms to include SHA-256. It's my first security area individual submission, so please be gentle :). The source XML is here: http://www.ietf.org/id/draft-os-ietf-sshfp-ecdsa-sha2-00.xml And you can find TXT here: http://www.ietf.org/id/draft-os-ietf-sshfp-ecdsa-sha2-00.txt Thanks for your time, Ondrej -------- Original Message -------- Subject: New Version Notification for draft-os-ietf-sshfp-ecdsa-sha2-00.txt Date: Thu, 16 Jun 2011 07:51:23 -0700 From: internet-drafts@ietf.org To: ondrej.sury@nic.cz CC: ondrej.sury@nic.cz A new version of I-D, draft-os-ietf-sshfp-ecdsa-sha2-00.txt has been successfully submitted by Ondrej Sury and posted to the IETF repository. Filename: draft-os-ietf-sshfp-ecdsa-sha2 Revision: 00 Title: Use of SHA-256 Algorithm with RSA, DSA and ECDSA in SSHFP Resource Records Creation date: 2011-06-16 WG ID: Individual Submission Number of pages: 9 Abstract: This document defines how to store Secure Shell (SSH) ECDSA public keys and SHA-256 fingerprints in SSHFP Resource Records. The IETF Secretariat -- OndÅ™ej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- LaboratoÅ™e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From ondrej.sury@nic.cz Thu Jun 16 08:48:45 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA12F21F8504 for ; Thu, 16 Jun 2011 08:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I24yMlj7qDT4 for ; Thu, 16 Jun 2011 08:48:45 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id C032621F84A8 for ; Thu, 16 Jun 2011 08:48:44 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617] (unknown [IPv6:2001:1488:ac14:1400:224:e8ff:fea9:f617]) by mail.nic.cz (Postfix) with ESMTPSA id DE3D72A2B76 for ; Thu, 16 Jun 2011 17:48:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1308239324; bh=RJmdireR0RMoKrlrxECy4Bef7J80llLLqIjVAIwnMic=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Jbo+uspvP8RImN31o9uCuZwu52HMUsl20gIuIelph29Mys0IAr3njQ7RQIrits79H GiOZlsZ1Fy928ZBxoNd2LNzcyvEqOlQuuJrxrwVrrTona8GajoCs8/9UnJ365HeYle y8s1tcMDcqMtFfj86Bhp+l7J1vrn6J8D55fbzzkE= Message-ID: <4DFA25DB.5080607@nic.cz> Date: Thu, 16 Jun 2011 17:48:43 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: saag@ietf.org References: <4DFA19A4.70301@nic.cz> In-Reply-To: <4DFA19A4.70301@nic.cz> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: Re: [saag] Fwd: New Version Notification for draft-os-ietf-sshfp-ecdsa-sha2-00.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 15:48:45 -0000 One more note... I also wrote an implementation as a patch over OpenSSH portable (Debian version, but applies to vanilla as well). So if you feel playful, here's the patch: https://git.nic.cz/redmine/projects/ietf/repository/revisions/master/entry/ssh-sshfp-ecdsa.patch The ssh-keygen -r works, I am not so sure about the verification routines. O. On 16.6.2011 16:56, OndÅ™ej Surý wrote: > Dear colleagues, > > since it was brought up in some discussion about SSHFP (and DNSSEC) as > missing I took a liberty of updating DNS SSHFP Resource Records with > ECDSA algorithm (as described in RFC 5656) and also updated the hash > algorithms to include SHA-256. > > It's my first security area individual submission, so please be gentle :). > > The source XML is here: > > http://www.ietf.org/id/draft-os-ietf-sshfp-ecdsa-sha2-00.xml > > And you can find TXT here: > > http://www.ietf.org/id/draft-os-ietf-sshfp-ecdsa-sha2-00.txt > > Thanks for your time, > Ondrej > > -------- Original Message -------- > Subject: New Version Notification for draft-os-ietf-sshfp-ecdsa-sha2-00.txt > Date: Thu, 16 Jun 2011 07:51:23 -0700 > From: internet-drafts@ietf.org > To: ondrej.sury@nic.cz > CC: ondrej.sury@nic.cz > > A new version of I-D, draft-os-ietf-sshfp-ecdsa-sha2-00.txt has been > successfully submitted by Ondrej Sury and posted to the IETF repository. > > Filename: draft-os-ietf-sshfp-ecdsa-sha2 > Revision: 00 > Title: Use of SHA-256 Algorithm with RSA, DSA and ECDSA in SSHFP > Resource Records > Creation date: 2011-06-16 > WG ID: Individual Submission > Number of pages: 9 > > Abstract: > This document defines how to store Secure Shell (SSH) ECDSA public > keys and SHA-256 fingerprints in SSHFP Resource Records. > > > > > > The IETF Secretariat > -- OndÅ™ej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- LaboratoÅ™e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From fernando.gont.netbook.win@gmail.com Thu Jun 16 09:34:51 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20F1D1F0C59 for ; Thu, 16 Jun 2011 09:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zcR8eFAsmKZY for ; Thu, 16 Jun 2011 09:34:50 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4921F0C56 for ; Thu, 16 Jun 2011 09:34:49 -0700 (PDT) Received: by wwa36 with SMTP id 36so1177180wwa.13 for ; Thu, 16 Jun 2011 09:34:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=uTSnBVmnnzm7ZoKCTTTV8ey5hog4lWPCK8PBJ2KivQI=; b=cwqRgPv/A9jEemGJyoNGz8td+0yvsILxgCWVyMbcxu0EXs/RQU/LjUYnxF2EPO1VS5 dqATtdk1svFgrAjJLvAGFuCAqO5sI4PLN8Ilq38RlXXFO3tiPcKCHs+KDajxUH4WroiA igJF8KpDwZrZWXbKs+GnnUW61QSPZ5+fWg+2k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=PC627iIWr+staNfOjagem1g8pYKu5bAKX/ylVxcbNv5fnKJyjNW9QT9STSm2pLW1gb rOSTHTnL682AESFdS8aTeCsO+NUCemNn270EHQyUqfx8fJuHIueTNqSsGoM1U9/oxo0c MkNh2FnxzYKO/Dx/Ba6iS3F1B2Fc3YQq3n/Yw= Received: by 10.227.54.195 with SMTP id r3mr1133206wbg.11.1308242088923; Thu, 16 Jun 2011 09:34:48 -0700 (PDT) Received: from [10.0.0.209] ([81.255.18.126]) by mx.google.com with ESMTPS id en1sm276300wbb.35.2011.06.16.09.34.46 (version=SSLv3 cipher=OTHER); Thu, 16 Jun 2011 09:34:47 -0700 (PDT) Sender: Fernando Gont Message-ID: <4DFA30A5.1080609@gont.com.ar> Date: Thu, 16 Jun 2011 13:34:45 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: Sean Turner References: <4DF9C5B8.2000108@cs.tcd.ie> <4DF9EFA1.6090502@ieca.com> In-Reply-To: <4DF9EFA1.6090502@ieca.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Ron Bonica , Jari Arkko , Ralph Droms , "v6ops-chairs@tools.ietf.org Chairs" , Fred Baker , saag@ietf.org Subject: Re: [saag] Looking for guidance re draft-gont-v6ops-ra-guard-evasion X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 16:34:51 -0000 On 06/16/2011 08:57 AM, Sean Turner wrote: >> Maybe another way to look at it would be to ask what >> RFC it might UPDATE and then have it land wherever that >> came from? My take is that this document should update the RA-Guard RFC (RFC6105), which was produced by v6ops, and thus draft-gont-v6ops-ra-guard-evasion should be pursued within v6ops. Additional, this is an operational problem, and thus we should be producing possible mitigations for it (see the proposed filtering in the aforementioned I-D). My other I-D related to this subject (draft-gont-6man-nd-extension-headers) is orthogonal to this: having 6man prohibit the use of extension headers in ND packets would eventually enable for simpler and cleaner mitigations... Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fernando.gont.netbook.win@gmail.com Thu Jun 16 10:19:35 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C44A311E8247 for ; Thu, 16 Jun 2011 10:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NkCn4d2v4XcE for ; Thu, 16 Jun 2011 10:19:34 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 71E9611E8246 for ; Thu, 16 Jun 2011 10:19:34 -0700 (PDT) Received: by wwa36 with SMTP id 36so1208804wwa.13 for ; Thu, 16 Jun 2011 10:19:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=pvOaA+0ntBL+Ehtn9mIphkutX7ScO2hjteiycVNssFo=; b=cDGsBqs3FBNuUC62MyV7xhtL1BX9sw0DLoyr/sr1rqa4mLIom5yNYZrws2gRSf590r uUXikyrP+chfoB2Bpa5MPQ5WnNwWGnLWWPNOjt2Av8SA4KfAaqwoTritL8lHrfSI1GKJ jpyQCMv1V0WkpJsIBQiY15zuGg75wIfM06o6E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=CnSVva6EM/N0NL77he9uBcBkLsOT/8b8MsDaIt/i8rbheKbOdXbWLsZPRqyEsknPNT EJPGIOhzpadvUcnfR57O/r2EGZ8JKAlUuKb4JHk//pWZvu7QwHmS4xBaexXl345d4QlH zB83A3t9VgY9O+ZjBd9UyTooFJ0dOSlawlr/4= Received: by 10.227.201.148 with SMTP id fa20mr1217273wbb.39.1308244773398; Thu, 16 Jun 2011 10:19:33 -0700 (PDT) Received: from [192.168.1.106] ([90.84.146.190]) by mx.google.com with ESMTPS id en1sm308290wbb.18.2011.06.16.10.19.31 (version=SSLv3 cipher=OTHER); Thu, 16 Jun 2011 10:19:32 -0700 (PDT) Sender: Fernando Gont Message-ID: <4DFA3B21.8010103@gont.com.ar> Date: Thu, 16 Jun 2011 14:19:29 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: Fred Baker References: <4DF9C5B8.2000108@cs.tcd.ie> <4DF9EFA1.6090502@ieca.com> <4DFA30A5.1080609@gont.com.ar> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Ron Bonica , Jari Arkko , Ralph Droms , "v6ops-chairs@tools.ietf.org Chairs" , saag@ietf.org Subject: Re: [saag] Looking for guidance re draft-gont-v6ops-ra-guard-evasion X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 17:19:35 -0000 On 06/16/2011 01:51 PM, Fred Baker wrote: > Where I'm scratching my head is implementation. Since ND is a special > case of ICMPv6, ICMPv6 is a payload of IPv6 (and therefore lacks > visibility into individual fragments after they have been > reassembled), and we're talking about an L2 device analyzing the > packet to decide whether or not to allow it, this comes down pretty > quickly to having the switch block any packet with extension headers. No, I'm not suggesting that. See the proposed filter in the I-D. Also, if extension headers are prohibited in ND messages, then a simple RA-Guard implementation is possible, without having to affect any other traffic that uses extension headers. > I'm pretty sure that's not what you're suggesting, but I suspect it's > the direction the suggestion goes. It is, for example, what became of > the IPv4 suggestion that we not allow the various "record route" > options... I'm not sure how my proposal relates to the "record route" options. Record route options are probably blocked because the potential/eventual legitimate uses for them do not outweigh their security implications. > The better solution, of course, is to have an end system that > receives RAs with extensions (assuming the ICMPv6 module can tell) > discard such messages. That still has the end system dealing with the > message, which is counter to one of the objectives of RA Guard; > consuming end system resources is part of the attack. Not sure what you mean. Are you suggesting that end-systems should deal with the problem of Rogue-RAs? -- Anyway, the argument was about whether whether v6ops was an acceptable choice for pursuing this I-D... Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From pgut001@login01.cs.auckland.ac.nz Fri Jun 17 01:39:02 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F08122800C; Fri, 17 Jun 2011 01:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.556 X-Spam-Level: X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPC7SWDwqd2K; Fri, 17 Jun 2011 01:39:01 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id C415722800B; Fri, 17 Jun 2011 01:38:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1308299941; x=1339835941; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20nico@cryptonector.com,=20pgut001@cs.auckland.ac.nz |Subject:=20Re:=20[saag]=20[websec]=20[http-auth]=20re-ca ll=20for=20IETF=20http-auth=20BoF|Cc:=20hallam@gmail.com, =20http-auth@ietf.org,=20julian.reschke@gmx.de,=0D=0A=20 =20=20=20public-identity@w3.org,=20saag@ietf.org,=20webse c@ietf.org|In-Reply-To:=20|Message-Id:=20|Date:=20Fri,=2017=20Jun=20201 1=2020:38:45=20+1200; bh=vzoGqdzEGFYr2A19mGZEcWkLf5wzBjThQhZ+tz4RHkg=; b=UNnW1KZIZeEntiO6/jo+DuF12GZlgxOaepJ2XQ09qNj3BsW8MGE297w9 MXC5RfZBy1WRcuaaUjae2X6FTaL5AuK2RI1Ez+8HGxbsYDu80ynmQ0czr rQ9wRDbkP1k2C7dOu3FePKmteAMDt1f1uIn0+eWEOXJIbNQmcoIoK4tal Y=; X-IronPort-AV: E=Sophos;i="4.65,380,1304251200"; d="scan'208";a="67846850" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 17 Jun 2011 20:38:46 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QXUZh-0007ac-J0; Fri, 17 Jun 2011 20:38:45 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QXUZh-0007S2-RN; Fri, 17 Jun 2011 20:38:45 +1200 From: Peter Gutmann To: nico@cryptonector.com, pgut001@cs.auckland.ac.nz In-Reply-To: Message-Id: Date: Fri, 17 Jun 2011 20:38:45 +1200 Cc: julian.reschke@gmx.de, public-identity@w3.org, websec@ietf.org, http-auth@ietf.org, saag@ietf.org, hallam@gmail.com Subject: Re: [saag] [websec] [http-auth] re-call for IETF http-auth BoF X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 08:39:02 -0000 Nico Williams writes: >Some aspects of the designs are important. Definitely. Before we launch into the inevitable bikeshedding, I think we should set out what it is we're documenting/specifying (since this is copied across several lists, it's a bit hard to see what the target/goal is). Is it a new crypto mutual-auth mechanism? A recommendation to use crypto mutual auth? Is it for browsers/HTTP, or general use? Is it a MUST for a protocol, or a BCP, or an informational RFC? If we're going to go into UI issues then it's probably going to be an informational RFC, which won't have much effect on browser behaviour, while if it's a crytpto mutual-auth protocol for HTTP that'll become a MUST (I hope so!) then we're not really going to be able to lay out requirements for UI design. >Shall we have just one authentication mechanism? *If* the idea is to specify a new auth mechanism and *if* it's for browsers and similar devices, I'd just say "Use EAP with X", it's been studied and spec'd to death, there's lots of implementations, it's pretty simple to do, etc. >at the application layer and in a RESTful way: I would really, *really* prefer to not invent another auth mechanism. There'd have to be a pretty strong argument to not use what we've already got. I happen to like EAP because it's simple, already spec'd out for lots of things (including cellphones via SIMs and other non-browser devices), and you can just say "use this", as long as "this" is profiled a bit to be something more specific than "any EAP mechanism you feel like". Peter. From nico@cryptonector.com Fri Jun 17 08:25:32 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5DAE11E8182; Fri, 17 Jun 2011 08:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.99 X-Spam-Level: X-Spam-Status: No, score=-2.99 tagged_above=-999 required=5 tests=[AWL=-1.013, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vq6Aw6zSZWpk; Fri, 17 Jun 2011 08:25:27 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id C3B0211E8171; Fri, 17 Jun 2011 08:25:26 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 82C8B6B0078; Fri, 17 Jun 2011 08:25:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=YaMqgcQ4NriwpkftVtnIwXO6s61pzwNGPOYn3cQcC8Ol ABPGPFKXxcm5rekh6Lf0BAr7JH1tRDypV1CZMInwwOn+/eKmDWrR30QcVY9kzfDH 7DIEoi/FnMjUR5w9bjAweR0rnZ2y9VniMwCUO/ma8iU1BfGCHSqESW+hz7fmyuU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=Tfe+v6f1TOC1aW5HqhH3L0mPT3g=; b=AWeT1Np9mEX Hxp+sK5Yu2GfmhRVnB3mJsHfP0daQ+rqkntACBogn64AfxynTCHakSI9oVWDWbc1 JJwNKjHgc+5c8zoyJ+VsjH+My6IQRYR863NPjbAWSIbHzZ5kcVI2wQHeWxuaVz25 uFl6Oj/a5xoaTab3W4LWCbEVXwje91x4= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id 555936B0070; Fri, 17 Jun 2011 08:25:26 -0700 (PDT) Received: by pzk5 with SMTP id 5so2110761pzk.31 for ; Fri, 17 Jun 2011 08:25:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.59.198 with SMTP id b6mr1157786pbr.6.1308324325731; Fri, 17 Jun 2011 08:25:25 -0700 (PDT) Received: by 10.68.54.197 with HTTP; Fri, 17 Jun 2011 08:25:25 -0700 (PDT) In-Reply-To: References: Date: Fri, 17 Jun 2011 10:25:25 -0500 Message-ID: From: Nico Williams To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: julian.reschke@gmx.de, public-identity@w3.org, websec@ietf.org, http-auth@ietf.org, saag@ietf.org, hallam@gmail.com Subject: Re: [saag] [websec] [http-auth] re-call for IETF http-auth BoF X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 15:25:32 -0000 On Fri, Jun 17, 2011 at 3:38 AM, Peter Gutmann wrote: > Nico Williams writes: >>Shall we have just one authentication mechanism? > > *If* the idea is to specify a new auth mechanism and *if* it's for browse= rs > and similar devices, I'd just say "Use EAP with X", it's been studied and > spec'd to death, there's lots of implementations, it's pretty simple to d= o, > etc. CHeck out what ABFAB WG is doing then! ;) (Hint: they're making a GSS-API security mechanism based on EAP. Now, if only there were a way to use that well in HTTP.) >>at the application layer and in a RESTful way: > > I would really, *really* prefer to not invent another auth mechanism. =C2= =A0There'd > have to be a pretty strong argument to not use what we've already got. = =C2=A0I > happen to like EAP because it's simple, already spec'd out for lots of th= ings > (including cellphones via SIMs and other non-browser devices), and you ca= n > just say "use this", as long as "this" is profiled a bit to be something = more > specific than "any EAP mechanism you feel like". Ah, but I'm not proposing that we invent any new mechanisms. Mind you, I'd not mind more mechanism choices, but I'm not proposing new ones. I'm proposing a way to use the set of mechanisms we have in HTTP without modifying HTTP nor TLS. Nico -- From Josh.Howlett@ja.net Fri Jun 17 09:12:09 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC08B11E813B; Fri, 17 Jun 2011 09:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYBYCYiKSfBC; Fri, 17 Jun 2011 09:12:08 -0700 (PDT) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by ietfa.amsl.com (Postfix) with ESMTP id 6C3F611E80DB; Fri, 17 Jun 2011 09:12:08 -0700 (PDT) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 7A16C1A9A808_DFB7CD5B; Fri, 17 Jun 2011 16:12:05 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by egw001.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 5FE831A9A800_DFB7CD5F; Fri, 17 Jun 2011 16:12:05 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0289.001; Fri, 17 Jun 2011 17:11:40 +0100 From: Josh Howlett To: Nico Williams , Peter Gutmann Thread-Topic: [saag] [websec] [http-auth] re-call for IETF http-auth BoF Thread-Index: AQHMJrOA2X+WbfAeoEeB/qjJgezzBJS4pd8AgAObwgCAAL0xAIAENvOAgABxn4CAAB3LgA== Date: Fri, 17 Jun 2011 16:11:40 +0000 Message-ID: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <848963300C67714B999CDBF7C3D42472@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "julian.reschke@gmx.de" , "public-identity@w3.org" , "websec@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , "hallam@gmail.com" Subject: Re: [saag] [websec] [http-auth] re-call for IETF http-auth BoF X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 16:12:09 -0000 On 17/06/2011 16:25, "Nico Williams" wrote: >On Fri, Jun 17, 2011 at 3:38 AM, Peter Gutmann > wrote: >> Nico Williams writes: >>>Shall we have just one authentication mechanism? >> >> *If* the idea is to specify a new auth mechanism and *if* it's for >>browsers >> and similar devices, I'd just say "Use EAP with X", it's been studied >>and >> spec'd to death, there's lots of implementations, it's pretty simple to >>do, >> etc. > >CHeck out what ABFAB WG is doing then! ;) Just by way of information for Peter's benefit, we have an ABFAB implementation -- and we've demonstrated ABFAB-based EAP authentication with Firefox and Apache by leveraging their existing support for the HTTP Negotiate scheme. I also agree with Peter's argument, although there are other benefits to EAP that he doesn't mention. It supports a diverse range of authentication methods, which means that deployers are not required to use a particular type of credential - they can use whatever type of credential best suits their needs. In addition, with EAP Pass-Through the web server does not need to understand the credential technology being presented by the user; the web server can be entirely agnostic with respect to the credential technology being used by EAP (modulo some basic security properties that enable GSS magic to happen). >>>at the application layer and in a RESTful way: >> >> I would really, *really* prefer to not invent another auth mechanism. >>There'd >> have to be a pretty strong argument to not use what we've already got. >>I >> happen to like EAP because it's simple, already spec'd out for lots of >>things >> (including cellphones via SIMs and other non-browser devices), and you >>can >> just say "use this", as long as "this" is profiled a bit to be >>something more >> specific than "any EAP mechanism you feel like". > >Ah, but I'm not proposing that we invent any new mechanisms. Mind >you, I'd not mind more mechanism choices, but I'm not proposing new >ones. I'm proposing a way to use the set of mechanisms we have in >HTTP without modifying HTTP nor TLS. Nico's proposal definitely adds significant value to EAP (ABFAB) based authentication, relative to transport-bound Negotiate. I would like to see GSS REST happen. Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From fred@cisco.com Wed Jun 15 17:11:56 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42E8E21F8591 for ; Wed, 15 Jun 2011 17:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.416 X-Spam-Level: X-Spam-Status: No, score=-110.416 tagged_above=-999 required=5 tests=[AWL=-0.417, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iOtwqmSr0bcZ for ; Wed, 15 Jun 2011 17:11:54 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 576CC21F858D for ; Wed, 15 Jun 2011 17:11:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1105; q=dns/txt; s=iport; t=1308183114; x=1309392714; h=from:subject:date:message-id:cc:to:mime-version: content-transfer-encoding; bh=0xYVYRY8AGP6vRUoKgYXXWuCZVAUt4zRSRnFmpaMgSY=; b=jOMNuI071EHq0ra4Ntt5puiio252iW27L0jGHcp6gnTv8R1/4bifttHN BxCXmP/jBgc2kDi2xLND/M2hJipCoXuXCUAQ6TenXAmpPEIeXOEAR7eyU s4f17wSNn9+UlFIARuctEqxNH5iOnSDwO74UMNciKcX5BC7x0e7QMGkgU E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKxJ+U2rRDoG/2dsb2JhbABSpl93qx2eIoYmBIcYijaEW4s1 X-IronPort-AV: E=Sophos;i="4.65,372,1304294400"; d="scan'208";a="377493325" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 16 Jun 2011 00:11:52 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5G0Bhi0027223; Thu, 16 Jun 2011 00:11:49 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Wed, 15 Jun 2011 17:11:49 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Wed, 15 Jun 2011 17:11:49 -0700 From: Fred Baker Date: Wed, 15 Jun 2011 17:11:33 -0700 Message-Id: To: Sean Turner , Stephen Farrell , Ralph Droms , Jari Arkko Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sun, 19 Jun 2011 12:41:04 -0700 Cc: "v6ops-chairs@tools.ietf.org Chairs" , saag@ietf.org, Ron Bonica Subject: [saag] Looking for guidance re draft-gont-v6ops-ra-guard-evasion X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 00:11:56 -0000 I have a request from the authors to present = draft-gont-v6ops-ra-guard-evasion in v6ops. The document describes two = ways that a motivated attacker could attack RA-Guard (RFC 6105). For the = first, he postulates that an RA Guard implementation might look at the = first "Next Header" field rather than parsing the full IPv6 header, and = as a result an attacker could slide his rogue RA by using a Destination = Options header. In the second, he observes that if he fragments the = message, the switch will be unlikely to be able to parse it because it = can't reassemble it. The observations are legitimately true; an implementation that takes = shortcuts is likely to miss cases, and fragmentation has that effect. It = also seems like the observations are (a) generic to IPv6 datagrams, not = just RA messages, and (b) not something an operator can do much about. = Hence, I question the value of the draft to the operational community. = It seems like a better fit to the security area or to 6man, who might be = in a position to do something about it. Looking for advice...= From fred@cisco.com Thu Jun 16 07:18:34 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36CA711E8206 for ; Thu, 16 Jun 2011 07:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.704 X-Spam-Level: X-Spam-Status: No, score=-110.704 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h5jIARSA0l+O for ; Thu, 16 Jun 2011 07:18:33 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 4E31411E8208 for ; Thu, 16 Jun 2011 07:18:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=215; q=dns/txt; s=iport; t=1308233913; x=1309443513; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=G7OLRtBfbT809bIwa1JURvylA0/J1tJ0GYDfhSrh2/0=; b=cLiMxct4B7nfkvtz0j9PZTTUXnoWOUw7+VOMXfcvDMOy00JqBq/i6wAZ uvfuOfbtMd23ixYlYugTe2E4pafczALbNfpoLfRmQsZfnkSXwCfIcAAZp +M9+r09behL+HquIrVx8zjLtlrQPU4zucQ7VdWjSRG5EBrOoy6OCq3xVi I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EALcP+k2rRDoJ/2dsb2JhbABSpmB3iHOiVp4khicEhx2KPIRcizo X-IronPort-AV: E=Sophos;i="4.65,375,1304294400"; d="scan'208";a="378003767" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-2.cisco.com with ESMTP; 16 Jun 2011 14:18:32 +0000 Received: from Freds-Computer.local (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5GEIR1h018150; Thu, 16 Jun 2011 14:18:32 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Thu, 16 Jun 2011 07:18:33 -0700 X-PGP-Universal: processed; by Freds-Computer.local on Thu, 16 Jun 2011 07:18:33 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <4DF9C5B8.2000108@cs.tcd.ie> Date: Thu, 16 Jun 2011 07:18:17 -0700 Message-Id: References: <4DF9C5B8.2000108@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 19 Jun 2011 12:41:04 -0700 Cc: Ron Bonica , Jari Arkko , Ralph Droms , "v6ops-chairs@tools.ietf.org Chairs" , saag@ietf.org Subject: Re: [saag] Looking for guidance re draft-gont-v6ops-ra-guard-evasion X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 14:18:34 -0000 On Jun 16, 2011, at 1:58 AM, Stephen Farrell wrote: > Maybe another way to look at it would be to ask what > RFC it might UPDATE and then have it land wherever that > came from? Thanks. That makes sense. From fred@cisco.com Thu Jun 16 09:53:44 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8395511E811B for ; Thu, 16 Jun 2011 09:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.402 X-Spam-Level: X-Spam-Status: No, score=-110.402 tagged_above=-999 required=5 tests=[AWL=-0.403, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id npWa2auJR5DR for ; Thu, 16 Jun 2011 09:53:43 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 963AA11E807B for ; Thu, 16 Jun 2011 09:53:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2179; q=dns/txt; s=iport; t=1308243223; x=1309452823; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=TlLPrnOtWELb9l9VcMErZDLK/hJiekw7kq6e+SIDBz0=; b=FyvU4VB8KvyG8Pj25GXUDrvhVe/DgL+G/Oh7Y+unEcWe78/CvekjZK0i M0qJZJ2VHecbQTx1+6+SyuyLFsZHLz7dftZNXyhAOegifatZCcP4rGmb3 bvC2+bnOwWP9qgop9cv/YXtKBOprAILVHNAvf9K5g2uM18hw3Kl3pt3uR 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EABM0+k2rRDoH/2dsb2JhbABSpmJ3q0eeH4YnBIcdijyEXIs6 X-IronPort-AV: E=Sophos;i="4.65,376,1304294400"; d="scan'208";a="714880384" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-6.cisco.com with ESMTP; 16 Jun 2011 16:52:14 +0000 Received: from Freds-Computer.local (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5GGq8mB009616; Thu, 16 Jun 2011 16:52:14 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Thu, 16 Jun 2011 09:52:14 -0700 X-PGP-Universal: processed; by Freds-Computer.local on Thu, 16 Jun 2011 09:52:14 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <4DFA30A5.1080609@gont.com.ar> Date: Thu, 16 Jun 2011 09:51:58 -0700 Message-Id: References: <4DF9C5B8.2000108@cs.tcd.ie> <4DF9EFA1.6090502@ieca.com> <4DFA30A5.1080609@gont.com.ar> To: Fernando Gont X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sun, 19 Jun 2011 12:41:05 -0700 Cc: Ron Bonica , Jari Arkko , Ralph Droms , "v6ops-chairs@tools.ietf.org Chairs" , saag@ietf.org Subject: Re: [saag] Looking for guidance re draft-gont-v6ops-ra-guard-evasion X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 16:53:44 -0000 On Jun 16, 2011, at 9:34 AM, Fernando Gont wrote: > On 06/16/2011 08:57 AM, Sean Turner wrote: >=20 >>> Maybe another way to look at it would be to ask what >>> RFC it might UPDATE and then have it land wherever that >>> came from? >=20 > My take is that this document should update the RA-Guard RFC = (RFC6105), > which was produced by v6ops, and thus = draft-gont-v6ops-ra-guard-evasion > should be pursued within v6ops. Additional, this is an operational > problem, and thus we should be producing possible mitigations for it > (see the proposed filtering in the aforementioned I-D). That may be the right answer. > My other I-D related to this subject > (draft-gont-6man-nd-extension-headers) is orthogonal to this: having > 6man prohibit the use of extension headers in ND packets would > eventually enable for simpler and cleaner mitigations... That also may be a right answer.=20 Where I'm scratching my head is implementation. Since ND is a special = case of ICMPv6, ICMPv6 is a payload of IPv6 (and therefore lacks = visibility into individual fragments after they have been reassembled), = and we're talking about an L2 device analyzing the packet to decide = whether or not to allow it, this comes down pretty quickly to having the = switch block any packet with extension headers. I'm pretty sure that's = not what you're suggesting, but I suspect it's the direction the = suggestion goes. It is, for example, what became of the IPv4 suggestion = that we not allow the various "record route" options... The better solution, of course, is to have an end system that receives = RAs with extensions (assuming the ICMPv6 module can tell) discard such = messages. That still has the end system dealing with the message, which = is counter to one of the objectives of RA Guard; consuming end system = resources is part of the attack. In the words of a wise person I once spoke with, all things are possible = to him who doesn't have to do it... > Thanks, > --=20 > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >=20 >=20 >=20 From joelja@bogus.com Sun Jun 19 14:24:08 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F321B11E8071 for ; Sun, 19 Jun 2011 14:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r9maRlTWGkqA for ; Sun, 19 Jun 2011 14:24:07 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 158D511E8111 for ; Sun, 19 Jun 2011 14:24:06 -0700 (PDT) Received: from [10.180.105.116] (252.sub-166-250-32.myvzw.com [166.250.32.252]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id p5JLMQpv060728 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 19 Jun 2011 21:22:28 GMT (envelope-from joelja@bogus.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joel Jaeggli In-Reply-To: Date: Sun, 19 Jun 2011 14:22:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2536797D-E41D-4E0D-9F3A-629F410BECE2@bogus.com> References: To: Fred Baker X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sun, 19 Jun 2011 21:22:31 +0000 (UTC) Cc: Ron Bonica , Jari Arkko , saag@ietf.org, "v6ops-chairs@tools.ietf.org Chairs" , Ralph Droms Subject: Re: [saag] Looking for guidance re draft-gont-v6ops-ra-guard-evasion X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2011 21:24:08 -0000 I think that's it's fine to socialize it. the analysis is consistent = with a general class of problems which have the potential to impact = protocols beyond RA such as dhcp6. from my vantage point turning = stateless l2 devices into general purpose protocol inspect engines in = the process of solving this is probably a mistake. joel On Jun 15, 2011, at 5:11 PM, Fred Baker wrote: > I have a request from the authors to present = draft-gont-v6ops-ra-guard-evasion in v6ops. The document describes two = ways that a motivated attacker could attack RA-Guard (RFC 6105). For the = first, he postulates that an RA Guard implementation might look at the = first "Next Header" field rather than parsing the full IPv6 header, and = as a result an attacker could slide his rogue RA by using a Destination = Options header. In the second, he observes that if he fragments the = message, the switch will be unlikely to be able to parse it because it = can't reassemble it. >=20 > The observations are legitimately true; an implementation that takes = shortcuts is likely to miss cases, and fragmentation has that effect. It = also seems like the observations are (a) generic to IPv6 datagrams, not = just RA messages, and (b) not something an operator can do much about. = Hence, I question the value of the draft to the operational community. = It seems like a better fit to the security area or to 6man, who might be = in a position to do something about it. >=20 > Looking for advice... > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag >=20 From stephen.farrell@cs.tcd.ie Mon Jun 20 08:55:12 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B219321F84FD for ; Mon, 20 Jun 2011 08:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.055 X-Spam-Level: X-Spam-Status: No, score=-106.055 tagged_above=-999 required=5 tests=[AWL=0.544, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pmiysWhEbpRI for ; Mon, 20 Jun 2011 08:55:11 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id A571721F84EC for ; Mon, 20 Jun 2011 08:55:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 4953E171C19 for ; Mon, 20 Jun 2011 16:55:06 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1308585306; bh=A3kD0xE3XXSbQwJcWKxNAGZf WIew3RUqtHV3P/CMCbs=; b=Rr7ATkXlSrMRH+jD+ynuh8QD2ifcItTFKRWZFX4J NzAZUJXFfqg1koBVfYW6RPDTHpqF22jpfum89HcwPsdIfUStWtaSLMwqiL9AGCHM HcKJRtYobvWJ+K8osUFCnUy8+/vx8Byvam0t4cgBXux6O44Z2tm7vWwzZQaXY8+A jbR9ML9mMsSCx8ikgoT8V+R1erAmV9pF2GPkYdm1yVOqG+S3kPQAknqe2GoBbao3 aQTCXxiQRdO+FISluPZFp/FKkxNJmHySAnfctluuQJtEjjDbkziR00IG9pIgRQ6k hsZ9ntXorT+LYg3D05Dgop+WGOjkMZDmyCJdXAZurK9RdA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 5QxEGMkQKa7W for ; Mon, 20 Jun 2011 16:55:06 +0100 (IST) Received: from [134.226.36.137] (stephen-samy.dsg.cs.tcd.ie [134.226.36.137]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id DE4E2171C18 for ; Mon, 20 Jun 2011 16:55:05 +0100 (IST) Message-ID: <4DFF6D59.6060200@cs.tcd.ie> Date: Mon, 20 Jun 2011 16:55:05 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: "saag@ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [saag] Spotting less-fine crypto early... X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2011 15:55:12 -0000 Hi all, FYI, there's a thread over on the cfrg list [1] that's resulted in what Sean and I think is a welcome suggestion for a few cfrg volunteers to run some tools that Dave McGrew has over -00 I-Ds to spot things like referencing MD5 without mention of RFC 6151. The idea is that some kind cfrg person will then mail the authors and say "hey, did you hear about..." The details are being worked on the cfrg list, if you're interested sign up there and get involved in the discussion or volunteer to help out. Cheers, S. [1] http://www.ietf.org/mail-archive/web/cfrg/current/msg02946.html From stephen.farrell@cs.tcd.ie Tue Jun 21 01:51:19 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEEF311E80EF for ; Tue, 21 Jun 2011 01:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.228 X-Spam-Level: X-Spam-Status: No, score=-106.228 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uufE0HS1CPVk for ; Tue, 21 Jun 2011 01:51:17 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 78BC811E80BC for ; Tue, 21 Jun 2011 01:51:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id AB90A171C1B; Tue, 21 Jun 2011 09:50:53 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1308646253; bh=DEP48izfkDIgq3 3a2hZBd7Z1eSIKrusH3Dx3uGaQQAs=; b=qZna60d1MiGdKmhOM4FGDDWb3hkmM3 a6j+/hMfnn49sV5gumPoGC9d8F+ifgtf+Zu212X+PRowMxY8tewVdkJ99WsRxeSf lCcod9R2VtTjP5vTksIdptjLgwhie4FRqQM2IABt8KEM2I+WReH64xf3tRnflfSP YMf6pb1Phd+Cz+AzKwJ4Ne3IkU9l+Ypt67Vy6pro/rB8FsFJPjgWgM8IH7yHgN9j iMqFJYH/SqxZNSJcpwZH3rtHbLQwJWMZ2GP2TB+ngerrJNmmVB3JfN5XpaQDneyD Et37xiUy7wnFb2TsZlNcEMECv0mqxYdTBJCctQAi8enFQStzTLhnr2uw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id XvcPTqRdhVBO; Tue, 21 Jun 2011 09:50:53 +0100 (IST) Received: from [134.226.36.137] (stephen-samy.dsg.cs.tcd.ie [134.226.36.137]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id A299B171C02; Tue, 21 Jun 2011 09:50:52 +0100 (IST) Message-ID: <4E005B6C.50402@cs.tcd.ie> Date: Tue, 21 Jun 2011 09:50:52 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: saag@ietf.org References: <4DFA19A4.70301@nic.cz> <4DFA25DB.5080607@nic.cz> In-Reply-To: <4DFA25DB.5080607@nic.cz> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [saag] Fwd: New Version Notification for draft-os-ietf-sshfp-ecdsa-sha2-00.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 08:51:19 -0000 Hi All, OndÅ™ej's asking us to AD sponsor this. Any opinions on that would be appreciated. For now, just a +/-1 is enough, if we take it on there'll be a chance to comment on the detail. Ta, S. On 16/06/11 16:48, OndÅ™ej Surý wrote: > One more note... I also wrote an implementation as a patch over OpenSSH > portable (Debian version, but applies to vanilla as well). > > So if you feel playful, here's the patch: > https://git.nic.cz/redmine/projects/ietf/repository/revisions/master/entry/ssh-sshfp-ecdsa.patch > > The ssh-keygen -r works, I am not so sure about the verification routines. > > O. > > On 16.6.2011 16:56, OndÅ™ej Surý wrote: >> Dear colleagues, >> >> since it was brought up in some discussion about SSHFP (and DNSSEC) as >> missing I took a liberty of updating DNS SSHFP Resource Records with >> ECDSA algorithm (as described in RFC 5656) and also updated the hash >> algorithms to include SHA-256. >> >> It's my first security area individual submission, so please be gentle :). >> >> The source XML is here: >> >> http://www.ietf.org/id/draft-os-ietf-sshfp-ecdsa-sha2-00.xml >> >> And you can find TXT here: >> >> http://www.ietf.org/id/draft-os-ietf-sshfp-ecdsa-sha2-00.txt >> >> Thanks for your time, >> Ondrej >> >> -------- Original Message -------- >> Subject: New Version Notification for draft-os-ietf-sshfp-ecdsa-sha2-00.txt >> Date: Thu, 16 Jun 2011 07:51:23 -0700 >> From: internet-drafts@ietf.org >> To: ondrej.sury@nic.cz >> CC: ondrej.sury@nic.cz >> >> A new version of I-D, draft-os-ietf-sshfp-ecdsa-sha2-00.txt has been >> successfully submitted by Ondrej Sury and posted to the IETF repository. >> >> Filename: draft-os-ietf-sshfp-ecdsa-sha2 >> Revision: 00 >> Title: Use of SHA-256 Algorithm with RSA, DSA and ECDSA in SSHFP >> Resource Records >> Creation date: 2011-06-16 >> WG ID: Individual Submission >> Number of pages: 9 >> >> Abstract: >> This document defines how to store Secure Shell (SSH) ECDSA public >> keys and SHA-256 fingerprints in SSHFP Resource Records. >> >> >> >> >> >> The IETF Secretariat >> > > From netsequent@gmail.com Tue Jun 21 12:40:07 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 293391F0C6C; Tue, 21 Jun 2011 12:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B24TK66cEcso; Tue, 21 Jun 2011 12:40:06 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 65D3B1F0C64; Tue, 21 Jun 2011 12:40:06 -0700 (PDT) Received: by qyk29 with SMTP id 29so76781qyk.10 for ; Tue, 21 Jun 2011 12:40:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=i9G+wh1jFDdiulTuF9oUa2J0BjCy7hzfXClQW5iL3yA=; b=ZcvBAqDS4ajnZL4S35G59O3Jvgyrg4MblHiugk8N6z1hx0E50/jpfxIZFpkAzDgeNm /6mph3/9kMv0zg1+2hTSnHV8YorJKpAXhrQvfs3qnyiZZfyl4Clw0B3WYT08mJwPk8cP v38Jds1NOfb8PE9Dc9di3nEytrajmSIbcBLdU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=TGzYgcpLM9MY3047KbislqM4VrK0ztpZIveNfgdfvF/oEMylIb/gmQZWradTm227+j 4RWoGsETFf7oftpAAv3w+EU07v+Xa31i0q2YlfPvdAH0UGgML5q4tkQixSd5VFhvhCWD PN53+ADcHKItVG3JQwbYSxlsUN5m+S87Ml5jY= Received: by 10.229.13.152 with SMTP id c24mr5502259qca.87.1308685205849; Tue, 21 Jun 2011 12:40:05 -0700 (PDT) Received: from [10.9.64.146] (mobile-198-228-192-137.mycingular.net [198.228.192.137]) by mx.google.com with ESMTPS id g11sm991331qcm.3.2011.06.21.12.40.01 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Jun 2011 12:40:04 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8J2) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Message-Id: <08A16114-A59F-4EA7-906B-E1273C6A0100@gmail.com> X-Mailer: iPhone Mail (8J2) From: Marc Williams Date: Tue, 21 Jun 2011 15:39:54 -0400 To: Thomas Roessler Cc: "http-auth@ietf.org" , "websec@ietf.org" , "public-identity@w3.org" , "saag@ietf.org" Subject: Re: [saag] [websec] Fwd: [http-auth] re-call for IETF http-auth BoF X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 19:40:07 -0000 >> * a method that hands over a password (or a password-equivalent) >> * a method whose UI can be imitated by malicious sites. >> >> Of course there might be more items, please append. A method which pemits zero length password authentication Marc Williams From warren@kumari.net Tue Jun 21 18:01:39 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A63411E8095 for ; Tue, 21 Jun 2011 18:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LEwL492uFmQ0 for ; Tue, 21 Jun 2011 18:01:38 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 0F40D11E8070 for ; Tue, 21 Jun 2011 18:01:37 -0700 (PDT) Received: from [10.196.208.180] (unknown [199.91.194.30]) by vimes.kumari.net (Postfix) with ESMTPSA id BB08E1B4017E; Tue, 21 Jun 2011 21:01:35 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: Warren Kumari In-Reply-To: <4E005B6C.50402@cs.tcd.ie> Date: Wed, 22 Jun 2011 10:01:31 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <5552533D-C792-4186-AD7D-F8C627BC819B@kumari.net> References: <4DFA19A4.70301@nic.cz> <4DFA25DB.5080607@nic.cz> <4E005B6C.50402@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1084) Cc: saag@ietf.org Subject: Re: [saag] Fwd: New Version Notification for draft-os-ietf-sshfp-ecdsa-sha2-00.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 01:01:39 -0000 On Jun 21, 2011, at 5:50 PM, Stephen Farrell wrote: >=20 > Hi All, >=20 > Ond=C5=99ej's asking us to AD sponsor this. +1 > Any opinions on that > would be appreciated. For now, just a +/-1 is enough, if we > take it on there'll be a chance to comment on the detail. >=20 > Ta, > S. >=20 > On 16/06/11 16:48, Ond=C5=99ej Sur=C3=BD wrote: >> One more note... I also wrote an implementation as a patch over = OpenSSH >> portable (Debian version, but applies to vanilla as well). >>=20 >> So if you feel playful, here's the patch: >> = https://git.nic.cz/redmine/projects/ietf/repository/revisions/master/entry= /ssh-sshfp-ecdsa.patch >>=20 >> The ssh-keygen -r works, I am not so sure about the verification = routines. >>=20 >> O. >>=20 >> On 16.6.2011 16:56, Ond=C5=99ej Sur=C3=BD wrote: >>> Dear colleagues, >>>=20 >>> since it was brought up in some discussion about SSHFP (and DNSSEC) = as >>> missing I took a liberty of updating DNS SSHFP Resource Records with >>> ECDSA algorithm (as described in RFC 5656) and also updated the hash >>> algorithms to include SHA-256. >>>=20 >>> It's my first security area individual submission, so please be = gentle :). >>>=20 >>> The source XML is here: >>>=20 >>> http://www.ietf.org/id/draft-os-ietf-sshfp-ecdsa-sha2-00.xml >>>=20 >>> And you can find TXT here: >>>=20 >>> http://www.ietf.org/id/draft-os-ietf-sshfp-ecdsa-sha2-00.txt >>>=20 >>> Thanks for your time, >>> Ondrej >>>=20 >>> -------- Original Message -------- >>> Subject: New Version Notification for = draft-os-ietf-sshfp-ecdsa-sha2-00.txt >>> Date: Thu, 16 Jun 2011 07:51:23 -0700 >>> From: internet-drafts@ietf.org >>> To: ondrej.sury@nic.cz >>> CC: ondrej.sury@nic.cz >>>=20 >>> A new version of I-D, draft-os-ietf-sshfp-ecdsa-sha2-00.txt has been >>> successfully submitted by Ondrej Sury and posted to the IETF = repository. >>>=20 >>> Filename: draft-os-ietf-sshfp-ecdsa-sha2 >>> Revision: 00 >>> Title: Use of SHA-256 Algorithm with RSA, DSA and = ECDSA in SSHFP >>> Resource Records >>> Creation date: 2011-06-16 >>> WG ID: Individual Submission >>> Number of pages: 9 >>>=20 >>> Abstract: >>> This document defines how to store Secure Shell (SSH) ECDSA public >>> keys and SHA-256 fingerprints in SSHFP Resource Records. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> The IETF Secretariat >>>=20 >>=20 >>=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From magnus.westerlund@ericsson.com Wed Jun 22 07:37:49 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D857721F8440 for ; Wed, 22 Jun 2011 07:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.557 X-Spam-Level: X-Spam-Status: No, score=-106.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AVTiJhUGToL2 for ; Wed, 22 Jun 2011 07:37:49 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id A3BD821F843A for ; Wed, 22 Jun 2011 07:37:48 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-32-4e01fe3aba81 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 6A.FA.20773.A3EF10E4; Wed, 22 Jun 2011 16:37:47 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Wed, 22 Jun 2011 16:37:46 +0200 Message-ID: <4E01FE39.6050403@ericsson.com> Date: Wed, 22 Jun 2011 16:37:45 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: saag@ietf.org X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [saag] Request to reviewers of AES-GCM and AES-CCM Authenticated Encryption in Secure RTP (SRTP) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: IETF AVTCore WG List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 14:37:50 -0000 Hi, We have an WG document in AVTCORE (the WG responsible for SRTP among other things after the AVT split) that specifies AES-GCM and AES-CCM based encryption and authentication for SRTP. As WG chair I would highly appreciate a few people from the security area could review the document and provide feedback. The document can be retrieved here: https://datatracker.ietf.org/doc/draft-ietf-avt-srtp-aes-gcm/ We would appreciate the reviews prior to the Quebec meeting. Please send your feedback to the avt@ietf.org mailing list Thanks Magnus Westerlund AVTCORE WG chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From kazubu.lepidum@gmail.com Wed Jun 22 08:23:50 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A135611E80B8; Wed, 22 Jun 2011 08:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=1.110, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zcrI2UG7W9s3; Wed, 22 Jun 2011 08:23:50 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id D8B5F11E810A; Wed, 22 Jun 2011 08:23:49 -0700 (PDT) Received: by pwj5 with SMTP id 5so716027pwj.31 for ; Wed, 22 Jun 2011 08:23:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=6arHhX7E9aXvQiKGZPTZVPKmgqq09jYj5lfsEi15doU=; b=xjzfItAn9U61uQetmqOquLeRsM/2+OSNeTgPyrcJ1092NSTkYcMzsJ5yxt+IoWCn7x AIxqS6C2Ty2TFL8PkqjUM+MSAB+Lg2Rjc5qwohnEt20zjr6Fg3Dvc+aM+6bD34KrIp58 b7qWJeeQ/1mTimpYVWNiE7c7jWF8tnS/TGeU0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=YvpjL25DvWbCbqEw8aZ1WuVJM9lRnzbdIDuBjmz53tWN5+9mxhU/in5dJ8ttSnwsGY u/Lh/DQc+3np1VbchJP7t9PwLJvwJNSSlj/W/WSlCTut7ZimWbafGDTjxEpTL/QDikT1 JUjCdYVF9Cez8Pg/723sDNCC/3T+5vNCmUE4I= Received: by 10.143.25.29 with SMTP id c29mr174189wfj.381.1308756223182; Wed, 22 Jun 2011 08:23:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.91.20 with HTTP; Wed, 22 Jun 2011 08:23:23 -0700 (PDT) In-Reply-To: <08A16114-A59F-4EA7-906B-E1273C6A0100@gmail.com> References: <08A16114-A59F-4EA7-906B-E1273C6A0100@gmail.com> From: "SHIMIZU, Kazuki" Date: Thu, 23 Jun 2011 00:23:23 +0900 Message-ID: To: Marc Williams Content-Type: text/plain; charset=ISO-8859-1 Cc: "public-identity@w3.org" , "http-auth@ietf.org" , "websec@ietf.org" , "saag@ietf.org" Subject: Re: [saag] [websec] Fwd: [http-auth] re-call for IETF http-auth BoF X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 15:23:50 -0000 I agree. In addition, I think we should avoid not only "zero length password" but also weak passwords (e.g. 12345, qwerty, etc...). This problem may be operation policy issue, however, might be considering. 2011/6/22 Marc Williams : >>> * a method that hands over a password (or a password-equivalent) >>> * a method whose UI can be imitated by malicious sites. >>> >>> Of course there might be more items, please append. > > > > > A method which pemits zero length password authentication > > > Marc Williams > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > -- SHIMIZU, Kazuki From gogwim@unijos.edu.ng Wed Jun 22 10:03:26 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2C3D21F856A; Wed, 22 Jun 2011 10:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLSjJfc76okH; Wed, 22 Jun 2011 10:03:26 -0700 (PDT) Received: from staffmail.unijos.edu.ng (staffmail.unijos.edu.ng [196.46.147.201]) by ietfa.amsl.com (Postfix) with ESMTP id 0F3D621F8501; Wed, 22 Jun 2011 10:03:23 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by staffmail.unijos.edu.ng (Postfix) with ESMTP id 90C07700B529A; Wed, 22 Jun 2011 18:03:16 +0100 (WAT) X-Virus-Scanned: amavisd-new at unijos.edu.ng Received: from staffmail.unijos.edu.ng ([127.0.0.1]) by localhost (staffmail.unijos.edu.ng [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPNS9Qu5lqs8; Wed, 22 Jun 2011 18:03:12 +0100 (WAT) Received: from imap.unijos.edu.ng (unknown [10.0.0.4]) by staffmail.unijos.edu.ng (Postfix) with ESMTP id 078F4700B5281; Wed, 22 Jun 2011 18:03:12 +0100 (WAT) Received: from mail.unijos.edu.ng (localhost.localdomain [127.0.0.1]) by imap.unijos.edu.ng (Postfix) with ESMTP id 4C7263E5EFB; Wed, 22 Jun 2011 18:21:39 +0100 (WAT) Received: from 196.220.229.163 (SquirrelMail authenticated user gogwim) by mail.unijos.edu.ng with HTTP; Wed, 22 Jun 2011 18:21:39 +0100 (WAT) Message-ID: <53857.196.220.229.163.1308763299.squirrel@mail.unijos.edu.ng> In-Reply-To: References: <08A16114-A59F-4EA7-906B-E1273C6A0100@gmail.com> Date: Wed, 22 Jun 2011 18:21:39 +0100 (WAT) From: "GOGWIM, JOEL GODWIN" To: "SHIMIZU, Kazuki" User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "public-identity@w3.org" , "http-auth@ietf.org" , "websec@ietf.org" , "saag@ietf.org" Subject: Re: [saag] [websec] Fwd: [http-auth] re-call for IETF http-auth BoF X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gogwim@unijos.edu.ng List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 17:03:26 -0000 Supported. Weak and predictable passwords should be avoided. On Wed, June 22, 2011 4:23 pm, SHIMIZU, Kazuki said: > I agree. > > In addition, I think we should avoid not only "zero length password" > but also weak passwords (e.g. 12345, qwerty, etc...). > > This problem may be operation policy issue, > however, might be considering. > > 2011/6/22 Marc Williams : >>>> * a method that hands over a password (or a password-equivalent) >>>> * a method whose UI can be imitated by malicious sites. >>>> >>>> Of course there might be more items, please append. >> >> >> >> >> A method which pemits zero length password authentication >> >> >> Marc Williams >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >> > > -- > SHIMIZU, Kazuki > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From nico@cryptonector.com Wed Jun 22 10:08:04 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A86C021F859F; Wed, 22 Jun 2011 10:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.853 X-Spam-Level: X-Spam-Status: No, score=-2.853 tagged_above=-999 required=5 tests=[AWL=-0.876, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIbBj6YnhuBZ; Wed, 22 Jun 2011 10:08:04 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 1C57C21F859D; Wed, 22 Jun 2011 10:08:04 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id 8501D508084; Wed, 22 Jun 2011 10:08:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=BNsICpi/P438f3WJVmKj4 fktDINNhD3ZaDlQ1c7zmXpL7IRSC00biPXlYBsYeexiMYAIdXK5jlPS7ScoMHOQ3 Z9XVDNzFot+U4GcIDdt9gB1h0L47ofyHPLxk5UWNvjACcyuCyhq4ZlzIePeMfzai pbr4s0sDiFAaXyg46hup7w= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=bUQC/PFbimCpJ1fVv4po rukJnJY=; b=hWDCtv6iiQfYIs3lyrcPEHsZU+RBtNrpAHFsdxIrke2CO/UEh21R H3IGHXDh5rI0KYkIygF7Iz+9dAcgt0ePoYXVBrk/M3pQ1LK0qByZyY4w7MD7HMpH KFpn2/wvCO6rw0dTrsF8AD4xiKPCYadDP21o9IYuRF27iOjxGJpReW8= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPSA id 453E1508081; Wed, 22 Jun 2011 10:08:03 -0700 (PDT) Received: by pzk5 with SMTP id 5so709686pzk.31 for ; Wed, 22 Jun 2011 10:08:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.18.162 with SMTP id x2mr556598pbd.274.1308762482861; Wed, 22 Jun 2011 10:08:02 -0700 (PDT) Received: by 10.68.41.167 with HTTP; Wed, 22 Jun 2011 10:08:02 -0700 (PDT) In-Reply-To: <53857.196.220.229.163.1308763299.squirrel@mail.unijos.edu.ng> References: <08A16114-A59F-4EA7-906B-E1273C6A0100@gmail.com> <53857.196.220.229.163.1308763299.squirrel@mail.unijos.edu.ng> Date: Wed, 22 Jun 2011 12:08:02 -0500 Message-ID: From: Nico Williams To: gogwim@unijos.edu.ng Content-Type: text/plain; charset=UTF-8 Cc: "http-auth@ietf.org" , "public-identity@w3.org" , "websec@ietf.org" , "saag@ietf.org" Subject: Re: [saag] [websec] Fwd: [http-auth] re-call for IETF http-auth BoF X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 17:08:04 -0000 On Wed, Jun 22, 2011 at 12:21 PM, GOGWIM, JOEL GODWIN wrote: > Supported. > Weak and predictable passwords should be avoided. If you have ZKPPs then weak passwords are OK. Also, all passwords that users must remember should be considered weak. Nico -- From hotz@jpl.nasa.gov Wed Jun 22 11:01:31 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2EC0228013; Wed, 22 Jun 2011 11:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNUTv1-Ough6; Wed, 22 Jun 2011 11:01:30 -0700 (PDT) Received: from mail.jpl.nasa.gov (sentrion2.jpl.nasa.gov [128.149.139.106]) by ietfa.amsl.com (Postfix) with ESMTP id D0AB7228011; Wed, 22 Jun 2011 11:01:30 -0700 (PDT) Received: from laphotz.jpl.nasa.gov (laphotz.jpl.nasa.gov [128.149.133.44]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.3) with ESMTP id p5MI1Fmj025813 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Wed, 22 Jun 2011 11:01:27 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Henry B. Hotz" In-Reply-To: <53857.196.220.229.163.1308763299.squirrel@mail.unijos.edu.ng> Date: Wed, 22 Jun 2011 11:01:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4E484152-2FF6-4374-B8D4-DCDA0D12ABBD@jpl.nasa.gov> References: <08A16114-A59F-4EA7-906B-E1273C6A0100@gmail.com> <53857.196.220.229.163.1308763299.squirrel@mail.unijos.edu.ng> To: "gogwim@unijos.edu.ng" X-Mailer: Apple Mail (2.1084) X-Source-IP: laphotz.jpl.nasa.gov [128.149.133.44] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: "http-auth@ietf.org" , "public-identity@w3.org" , "websec@ietf.org" , "saag@ietf.org" Subject: Re: [saag] [websec] Fwd: [http-auth] re-call for IETF http-auth BoF X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 18:01:31 -0000 I can agree in principle, but in practice the definition of "weak" is = too fuzzy. On Jun 22, 2011, at 10:21 AM, GOGWIM, JOEL GODWIN wrote: > Supported. > Weak and predictable passwords should be avoided. >=20 >=20 > On Wed, June 22, 2011 4:23 pm, SHIMIZU, Kazuki said: >> I agree. >>=20 >> In addition, I think we should avoid not only "zero length password" >> but also weak passwords (e.g. 12345, qwerty, etc...). >>=20 >> This problem may be operation policy issue, >> however, might be considering. >>=20 >> 2011/6/22 Marc Williams : >>>>> * a method that hands over a password (or a password-equivalent) >>>>> * a method whose UI can be imitated by malicious sites. >>>>>=20 >>>>> Of course there might be more items, please append. >>>=20 >>>=20 >>>=20 >>>=20 >>> A method which pemits zero length password authentication >>>=20 >>>=20 >>> Marc Williams >>>=20 >>> _______________________________________________ >>> saag mailing list >>> saag@ietf.org >>> https://www.ietf.org/mailman/listinfo/saag >>>=20 >>=20 >> -- >> SHIMIZU, Kazuki >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >>=20 >=20 >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From yutaka-oiwa-aist-temp@g.oiwa.jp Wed Jun 22 19:36:11 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2FC31F0C41; Wed, 22 Jun 2011 19:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YaSTON1ZmomP; Wed, 22 Jun 2011 19:36:11 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8A61F0C3D; Wed, 22 Jun 2011 19:36:10 -0700 (PDT) Received: by wwe5 with SMTP id 5so1003860wwe.13 for ; Wed, 22 Jun 2011 19:36:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.11.131 with SMTP id t3mr1375268wbt.113.1308796569317; Wed, 22 Jun 2011 19:36:09 -0700 (PDT) Sender: yutaka@g.oiwa.jp X-Google-Sender-Delegation: yutaka@g.oiwa.jp Received: by 10.227.128.75 with HTTP; Wed, 22 Jun 2011 19:36:09 -0700 (PDT) In-Reply-To: <53857.196.220.229.163.1308763299.squirrel@mail.unijos.edu.ng> References: <08A16114-A59F-4EA7-906B-E1273C6A0100@gmail.com> <53857.196.220.229.163.1308763299.squirrel@mail.unijos.edu.ng> Date: Thu, 23 Jun 2011 11:36:09 +0900 X-Google-Sender-Auth: NE7KstGKngNb65HXXwY67jWpyog Message-ID: From: Yutaka OIWA To: gogwim@unijos.edu.ng Content-Type: text/plain; charset=ISO-8859-1 Cc: "http-auth@ietf.org" , "public-identity@w3.org" , "websec@ietf.org" , "saag@ietf.org" Subject: Re: [saag] [websec] Fwd: [http-auth] re-call for IETF http-auth BoF X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 02:36:11 -0000 2011/6/23 GOGWIM, JOEL GODWIN : > Supported. > Weak and predictable passwords should be avoided. I ideally agree, but in reality I hesitate to agree with it with technical means and backgrounds. In short, here is a security trade-off. Of course, the statement "weak and predictable passwords should be avoided", as literally, can be read as our requirements to users and agreed with no questions. However, the original thread was prepended with "Any protocols that allow". For this purpose, the more the technology gets strong to protect "good (unpredictable)" passwords and passphrases against possible attacks, the more such a protocol cannot reveal "weakness" of passwords to servers too. To detect by the server side to detect predictable passwords using bulky (e.g. 100k or 1M+) list, currently we need either a plain-text password authentication protocol or a plain-text password registration procedure. On the contrary, if we forgive users' "mistake" to use such a weak passwords as user's own, we can introduce much stronger password protocols which do not reveal (at least immediately) the user's password both in registration and authentication time. When we face with this trade-off, I don't want to trash out the latter's possibility. In this background, "forbidding protocols which allow users to (covertly) use weak predictable passwords" means that "servers *always* know the user's plain-text password", which is obviously not happy. We don't want to completely sacrifice well-done user's security in trade with the careless user's security. Of course, even if we introduce such "secure" password registration protocol, I foresee that some people will continue to stick on plain-text password registration for various reasons. For example, if a law had required some servers (e.g. financial entities) to check and reject such predictable passwords, we would have no way to secure it. For such purposes servers will continue to receive raw passwords and computes password-hashes (or whatever equivalent) on the server-side. But I think that providing a possibility to securely registering passwords to servers are one of required things to do for us. But, again at last, I repeat to agree that "users" should avoid weak and predictable passwords with no questions. From yutaka-oiwa-aist-temp@g.oiwa.jp Wed Jun 22 19:52:42 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 856941F0C3F; Wed, 22 Jun 2011 19:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.904 X-Spam-Level: X-Spam-Status: No, score=-2.904 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NsDXd0-+oIPy; Wed, 22 Jun 2011 19:52:41 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 709521F0C38; Wed, 22 Jun 2011 19:52:41 -0700 (PDT) Received: by gya6 with SMTP id 6so837314gya.31 for ; Wed, 22 Jun 2011 19:52:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.66.20 with SMTP id o20mr1653832yba.344.1308797560807; Wed, 22 Jun 2011 19:52:40 -0700 (PDT) Sender: yutaka@g.oiwa.jp X-Google-Sender-Delegation: yutaka@g.oiwa.jp Received: by 10.151.153.19 with HTTP; Wed, 22 Jun 2011 19:52:40 -0700 (PDT) In-Reply-To: <4E484152-2FF6-4374-B8D4-DCDA0D12ABBD@jpl.nasa.gov> References: <08A16114-A59F-4EA7-906B-E1273C6A0100@gmail.com> <53857.196.220.229.163.1308763299.squirrel@mail.unijos.edu.ng> <4E484152-2FF6-4374-B8D4-DCDA0D12ABBD@jpl.nasa.gov> Date: Thu, 23 Jun 2011 11:52:40 +0900 X-Google-Sender-Auth: SzZgA12GrfnI-4N8P0vs65rNFfQ Message-ID: From: Yutaka OIWA To: "Henry B. Hotz" Content-Type: text/plain; charset=ISO-8859-1 Cc: "public-identity@w3.org" , "http-auth@ietf.org" , "websec@ietf.org" , "saag@ietf.org" Subject: Re: [saag] [http-auth] [websec] Fwd: re-call for IETF http-auth BoF X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 02:52:42 -0000 2011/6/23 Henry B. Hotz : > I can agree in principle, but in practice the definition of "weak" is too fuzzy. > > On Jun 22, 2011, at 10:21 AM, GOGWIM, JOEL GODWIN wrote: > >> Supported. >> Weak and predictable passwords should be avoided. 2011/6/23 Nico Williams : > Also, all passwords that users must remember should be considered weak. This is a terminology issue, and I present here *my* use of such terminologies in general. = strong secret and weak secret = "strong" secrets are the secret data which has an entropy comparable to other security parameters (e.g. encryption key length etc.) They typically include public-key-cryptography secret keys, DH-key-exchanged shared keys, randomly-generated nonce-like bearer tokens and others. "weak" secrets are the secret data which has not enough entropy compared to encryption etc. PINs, Passwords and passphrases are typical examples. They should not be used for encryptions without some security-amplifications (e.g. password-authenticated key exchanges.) In this meaning, all memorable passwords are weak. = strong passwords/passphrases and weak passwords = I use the term "weak passwords" almost equivalent to predictable passwords or brute-force searchable passwords. The required strength may depend on the context, e.g. whether the passwords search can be off-line, or whether a pre-computed dictionary of hashed passwords can be useful, etc. but many people will agree that "1" and "1234" are weak, and "cA6mqUPgBpe6pQf7" is strong as a password. I prefer using "predictable" and "unpredictable" for this meanings. From yaronf.ietf@gmail.com Thu Jun 23 13:53:23 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACAEB11E8190; Thu, 23 Jun 2011 13:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.506 X-Spam-Level: X-Spam-Status: No, score=-102.506 tagged_above=-999 required=5 tests=[AWL=-0.365, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTI2B5ofQ3Dd; Thu, 23 Jun 2011 13:53:23 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id A3A2911E817E; Thu, 23 Jun 2011 13:53:22 -0700 (PDT) Received: by wwe5 with SMTP id 5so1555200wwe.13 for ; Thu, 23 Jun 2011 13:53:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=OR7JnsEnLlf48JBmP/54Vv1iqGkXkisHfO+ebmokLVU=; b=kAgUeTtSHIp8nzaxsnJww082UaYrG71ruq9HT+FU2kUU88oFE52DSfgMSc/cMWO9Ak VTW1MQQEwS4haYAhpku1IZqqHdVwe51EuVbw46kYmP4YVhLjF7h9ZRebx2J0ehgtHPvh ucaKHvFtQ5XvysBe1n6ayxTcupPDrEVIOzy2U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=NfIi1x4vP41vwXY+zpaxGlpZVv5bcFj+YLWIHTRDc5bwzt7PJmK6elr9CpHIRIfuCX zQFNIMKbvl+pwyY5CJgSRvy89eCip6WdG2V2kOIgOhlShUTKWu50bUGt2CGCGWXtNpb8 nJdC3B/YxZdTNfzW1Oe6dgKQ6yij0Y6siPm+8= Received: by 10.227.127.135 with SMTP id g7mr2376880wbs.96.1308862401614; Thu, 23 Jun 2011 13:53:21 -0700 (PDT) Received: from [10.0.0.2] (bzq-79-183-236-253.red.bezeqint.net [79.183.236.253]) by mx.google.com with ESMTPS id d19sm1507099wbh.42.2011.06.23.13.53.18 (version=SSLv3 cipher=OTHER); Thu, 23 Jun 2011 13:53:21 -0700 (PDT) Message-ID: <4E03A7BD.3080301@gmail.com> Date: Thu, 23 Jun 2011 23:53:17 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Nico Williams References: <08A16114-A59F-4EA7-906B-E1273C6A0100@gmail.com> <53857.196.220.229.163.1308763299.squirrel@mail.unijos.edu.ng> In-Reply-To: Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "public-identity@w3.org" , "http-auth@ietf.org" , "websec@ietf.org" , "saag@ietf.org" Subject: Re: [saag] [websec] Fwd: [http-auth] re-call for IETF http-auth BoF X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 20:53:23 -0000 No, even if you have ZKPP you should avoid ridiculously weak passwords like "qwerty". The reason is, you are still vulnerable to active password guessing, and even if you rate-limit aggressively (e.g. one guess per hour), the attacker might get lucky too early.

So I would distinguish between the 2**20 space of user-memorable passwords, vs. the 2**7 space of too-horrible-to-contemplate passwords.

Thanks,
    Yaron

On 06/22/2011 08:08 PM, Nico Williams wrote: 
On Wed, Jun 22, 2011 at 12:21 PM, GOGWIM, JOEL GODWIN
<gogwim@unijos.edu.ng> wrote:

Supported.
Weak and predictable passwords should be avoided.

If you have ZKPPs then weak passwords are OK.

Also, all passwords that users must remember should be considered weak.

Nico
--
_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag
From marsh@extendedsubset.com Thu Jun 23 14:05:50 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6CD111E819D; Thu, 23 Jun 2011 14:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[AWL=-2.100, BAYES_00=-2.599, FM_IS_IT_OUR_ACCOUNT=4.2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3O9sRKyYjg8G; Thu, 23 Jun 2011 14:05:49 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id BF7C511E819B; Thu, 23 Jun 2011 14:05:49 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1QZr5x-000Fe9-6F; Thu, 23 Jun 2011 21:05:49 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id A93A56073; Thu, 23 Jun 2011 21:05:31 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18l9WmfuTCvaaqQMCGHl4jfTaoGBBgkS34= Message-ID: <4E03AA9B.4030709@extendedsubset.com> Date: Thu, 23 Jun 2011 16:05:31 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: Yutaka OIWA References: <08A16114-A59F-4EA7-906B-E1273C6A0100@gmail.com> <53857.196.220.229.163.1308763299.squirrel@mail.unijos.edu.ng> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 26 Jun 2011 08:32:34 -0700 Cc: "public-identity@w3.org" , "http-auth@ietf.org" , "websec@ietf.org" , "saag@ietf.org" Subject: Re: [saag] [websec] Fwd: [http-auth] re-call for IETF http-auth BoF X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2011 21:05:50 -0000 On 06/22/2011 09:36 PM, Yutaka OIWA wrote: > 2011/6/23 GOGWIM, JOEL GODWIN: >> Supported. >> Weak and predictable passwords should be avoided. > > I ideally agree, but in reality I hesitate to agree with it > with technical means and backgrounds. How is the IETF or w3 going to define "weak password" anyway? Even if there were a way, it's common to see users getting hacked these days because the use the same (possibly strong) password at multiple sites. It's best to pick a completely unique, strong password (12 or more characters) for each and every site. But unless you're some kind of savant, this requires writing these passwords down somewhere. But instead, users are taught not to write their passwords down (mostly by employers who don't want it to end up on a sticky note in an obvious place). So users either pick simple passwords and/or they use the same one at every site. > Of course, even if we introduce such "secure" password registration protocol, > I foresee that some people will continue to stick on plain-text password > registration for various reasons. For example, if a law had required > some servers (e.g. financial entities) to check and reject such predictable passwords, > we would have no way to secure it. That would be a bad law. I don't think a protocol design can or should defend against bad laws. At least in the US, financial institutions don't have such laws. They instead have a patchwork of audit requirements, industry standards, best practices, compliance, etc.. Which is probably better than passing laws about password complexity requirements, all things considered. > For such purposes servers will > continue to receive raw passwords and computes password-hashes > (or whatever equivalent) on the server-side. > But I think that providing a possibility to securely registering passwords > to servers are one of required things to do for us. This is far more important than working out ways to accommodate sites that want or need to transfer the password in clear text. Those sites are already able to do that just fine. Ideally the technology would somehow prevent a site from accepting (or doing anything useful with) the user's plaintext password within the page. This would allow the browser to remove any ambiguity for users which would be exploitable by phishing. The simplest message and the one that will "sink in" with the most users is: "You should never type this password into any web page or program except this unmistakable piece of browser chrome. Not to verify your account info, not to reset your password, not to receive tech support from someone you trust, and not even to see free pictures of kittens." It would be amazing if we could get there, but browser vendors and sites conspire against us to defeat it. - Marsh From tho@koanlogic.com Sat Jun 25 01:59:56 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3981621F853F; Sat, 25 Jun 2011 01:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.505 X-Spam-Level: * X-Spam-Status: No, score=1.505 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, SARE_RECV_IP_069060096=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LEo9iwBsfL0x; Sat, 25 Jun 2011 01:59:55 -0700 (PDT) Received: from gonzo.koanlogic.com (unknown [69.60.118.166]) by ietfa.amsl.com (Postfix) with ESMTP id 2D45921F853D; Sat, 25 Jun 2011 01:59:55 -0700 (PDT) Received: from host247-5-dynamic.32-79-r.retail.telecomitalia.it ([79.32.5.247]:56588 helo=[192.168.1.5]) by sp2844.serverpronto.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.50) id 1QaOiL-0005v9-55; Sat, 25 Jun 2011 04:59:47 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Thomas Fossati In-Reply-To: Date: Sat, 25 Jun 2011 10:59:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <63B45E28-8167-4820-B7BC-9D02E61D88FE@koanlogic.com> References: To: Nico Williams X-Mailer: Apple Mail (2.1084) X-SA-Exim-Connect-IP: 79.32.5.247 X-SA-Exim-Mail-From: tho@koanlogic.com X-Spam-DCC: : X-Spam-Pyzor: Reported 0 times. X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on sp2844.serverpronto.com) X-Mailman-Approved-At: Sun, 26 Jun 2011 08:32:34 -0700 Cc: public-identity@w3.org, http-auth@ietf.org, websec , saag@ietf.org Subject: Re: [saag] [websec] [http-auth] re-call for IETF http-auth BoF X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2011 08:59:56 -0000 On Jun 14, 2011, at 6:17 PM, Nico Williams wrote: > Some aspects of the designs are important. >=20 > For example: >=20 > - Is this to be done in TLS? HTTP? Or at the application-layer? >=20 > IMO: TLS is too low a layer to do authentication in, and doing it in > HTTP would require retrofitting too many HTTP stacks. Doing it at the > application layer has a number of advantages. I've tried to figure out how to get something similar to your REST GSS = -- which I like -- at the HTTP level and, yes, you need to hammer HTTP = clients a bit to teach them how to do the challange-response on a = specially crafted cookie, but then it seems you can switch from = stateless to stateful HTTP (and viceversa) quite robustly. Still there's the related bootstrap problem to solve, i.e. the = authentication phase and implied key agreement. =20 In this respect I've only been able to sketch a TLS-based mechanism, = with a) explicit HTTP redirection, or b) a-priori knowledge of the = authentication URI via .well-known or DNS-SD, which then uses RFC 5705 = to feed both parties with the needed crypto material. Anyway, I still have hazy thoughts about the whole matter, basically = from an architectural standpoint, i.e. about where (which layer) the = secure state management component must be placed. My unanswered (taboo?) question being: would the core HTTP protocol = benefit from introducing secure state handling capabilities ? Or should = HTTP remain stateless ?=