From turners@ieca.com Mon Feb 4 07:03:04 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB3521F86AC for ; Mon, 4 Feb 2013 07:03:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.078 X-Spam-Level: X-Spam-Status: No, score=-101.078 tagged_above=-999 required=5 tests=[AWL=-0.672, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334, 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 Tf7TpuuswDja for ; Mon, 4 Feb 2013 07:03:04 -0800 (PST) Received: from gateway02.websitewelcome.com (gateway02.websitewelcome.com [69.93.106.20]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC5F21F869C for ; Mon, 4 Feb 2013 07:02:52 -0800 (PST) Received: by gateway02.websitewelcome.com (Postfix, from userid 5007) id A86E33E137F8B; Mon, 4 Feb 2013 09:02:48 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway02.websitewelcome.com (Postfix) with ESMTP id DA21C3E137AC2 for ; Mon, 4 Feb 2013 09:02:47 -0600 (CST) Received: from [108.45.16.214] (port=65207 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1U2NZK-0006f9-JP for http-auth@ietf.org; Mon, 04 Feb 2013 09:02:50 -0600 Message-ID: <510FCD99.3000300@ieca.com> Date: Mon, 04 Feb 2013 10:02:49 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "http-auth@ietf.org" References: <50F2F075.8090809@cs.tcd.ie> <51068A27.1050601@ieca.com> <51069692.20706@cs.tcd.ie> In-Reply-To: <51069692.20706@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [108.45.16.214]:65207 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: Re: [http-auth] charter rev -03 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 15:03:04 -0000 On 1/28/13 10:17 AM, Stephen Farrell wrote: > > > On 01/28/2013 02:24 PM, Sean Turner wrote: >> Right so the plan here is to put this on the BOF list with the hope that >> a WG will get formed before IETF 86. Obviously this plan is predicated >> on more expressions of support for the proposed charter. > > As a draft author, I think forming a wg with this charter > would be good. (As an IESG member, I'll be recusing myself > from IESG balloting on this.) Just to be clear, it's time to speak up if you support the idea of forming a WG because silence means we shelve the idea. spt From nico@cryptonector.com Mon Feb 4 07:06:35 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 466D321F86AC for ; Mon, 4 Feb 2013 07:06:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.48 X-Spam-Level: X-Spam-Status: No, score=-3.48 tagged_above=-999 required=5 tests=[AWL=-1.503, 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 dYFgh65xh0Zp for ; Mon, 4 Feb 2013 07:06:34 -0800 (PST) Received: from homiemail-a64.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id AA68621F869C for ; Mon, 4 Feb 2013 07:06:34 -0800 (PST) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id 6BCB1438079 for ; Mon, 4 Feb 2013 07:06:34 -0800 (PST) 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=+A/GEDD2nbiwrNh2C2eE GRSQZ78=; b=PHguhSbY2Xr1433vp7AvjXbx4JcsuM5y0+Xrl9DeKQqyVgWv2X6e 7UQEezJWlgXhmeIwKHfFq3kVm7hbB1w0N8qXJurRn3ssdvRpiL0urm/SaORxVr4c Q3JSSn82+RGeptlhOooooE4uGBSOX13RyMdf+phdU8EPWMxoANeY9rQ= Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPSA id 1F7FE43806C for ; Mon, 4 Feb 2013 07:06:33 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id 12so3198369wgh.3 for ; Mon, 04 Feb 2013 07:06:32 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.84.165 with SMTP id a5mr11151399wiz.6.1359990392532; Mon, 04 Feb 2013 07:06:32 -0800 (PST) Received: by 10.217.39.133 with HTTP; Mon, 4 Feb 2013 07:06:31 -0800 (PST) In-Reply-To: <510FCD99.3000300@ieca.com> References: <50F2F075.8090809@cs.tcd.ie> <51068A27.1050601@ieca.com> <51069692.20706@cs.tcd.ie> <510FCD99.3000300@ieca.com> Date: Mon, 4 Feb 2013 09:06:31 -0600 Message-ID: From: Nico Williams To: Sean Turner Content-Type: text/plain; charset=UTF-8 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] charter rev -03 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 15:06:35 -0000 I support forming this WG. From yaronf.ietf@gmail.com Mon Feb 4 07:10:18 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5262121F869C for ; Mon, 4 Feb 2013 07:10:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OwQ+jwsOt--x for ; Mon, 4 Feb 2013 07:10:14 -0800 (PST) Received: from mail-ee0-f43.google.com (mail-ee0-f43.google.com [74.125.83.43]) by ietfa.amsl.com (Postfix) with ESMTP id 1087421F88B1 for ; Mon, 4 Feb 2013 07:10:13 -0800 (PST) Received: by mail-ee0-f43.google.com with SMTP id c50so3376956eek.2 for ; Mon, 04 Feb 2013 07:10:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Nw4TYHPKv8waEN2utY3Yo3ntNeFFM2C921ihjAP2A1A=; b=VaHAqgugDu11bZdnVsnwbGAoZK3Y/CerxI/PJY4uB3Zz0njmonTTdiKTierOKoqaRw W9vp5xHJuYAZovvntYNlQLQG698yW0vqzB6cKnx5l+W7cjTdqJeiS42OM3yltQdA5r+w KOHMfXf6tUDCt2+tAHj/dkl08NEwbuVKcEGM99KdhpaWwVApxh+FFW5FTesU/cIYTGWv liKHxgXBWeOWpoXAoMOCUyKDqjOFxTd9I/TNWcftuGe3lwz5qpQvPLaSQ37zSIdrER9L mGKztnsKvtC3o3o0VWbAOuOFY6wKEOa8cv0y9Wov4qhEVw+9b/Uz3NlVT8xxXeMaJ0XO AOIQ== X-Received: by 10.14.193.131 with SMTP id k3mr73328278een.45.1359990613244; Mon, 04 Feb 2013 07:10:13 -0800 (PST) Received: from [10.0.0.13] (85-250-110-45.bb.netvision.net.il. [85.250.110.45]) by mx.google.com with ESMTPS id q42sm18438840eem.14.2013.02.04.07.10.10 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Feb 2013 07:10:11 -0800 (PST) Message-ID: <510FCF51.1050500@gmail.com> Date: Mon, 04 Feb 2013 17:10:09 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Nico Williams References: <50F2F075.8090809@cs.tcd.ie> <51068A27.1050601@ieca.com> <51069692.20706@cs.tcd.ie> <510FCD99.3000300@ieca.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "http-auth@ietf.org" Subject: Re: [http-auth] charter rev -03 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 15:10:18 -0000 +1. Yaron On 02/04/2013 05:06 PM, Nico Williams wrote: > I support forming this WG. > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > From tho@koanlogic.com Mon Feb 4 07:56:53 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7B3021F88B1 for ; Mon, 4 Feb 2013 07:56:53 -0800 (PST) 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 6EBncItpcB9i for ; Mon, 4 Feb 2013 07:56:53 -0800 (PST) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) by ietfa.amsl.com (Postfix) with ESMTP id 2ADF421F882F for ; Mon, 4 Feb 2013 07:56:52 -0800 (PST) Received: by mail-lb0-f175.google.com with SMTP id n3so6640628lbo.6 for ; Mon, 04 Feb 2013 07:56:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=bZ6tpcMmIK3vfjs6uPGHSBi79RhV6iPRAF8IQND7acs=; b=Bfet8wuZ1EZPnTiZIi1pfibpKf+WHVej4sSXmkmFbuqU9yuGW6wmS0a4WgHzJIIx6I y1L3Cne6HJpSE96RVn2pepQ8Tdm1/DX9Hn2l+rUGqAfu7kliHNFnNAZz9E+S9a1yHUDf BaGxeJww66tdf82vKy/dzRgHKY2MqtIxUeLC/JRnVq2csN/mcvySb/6FUphnt+ijQtnr ZVJfakXmwiR97CYsqVU5HeVYFZTr9H2iy9CIWZUHiDq/dzeWNQaxf0SGO9GIfPCoIBr1 5PEztslRsY/Ri3vskEjMETP9td/PcUGUmZP4Dllq6axWquMWGTu381cFmeyIkXqt4qGB Q+wg== MIME-Version: 1.0 X-Received: by 10.152.110.228 with SMTP id id4mr19782016lab.34.1359993412039; Mon, 04 Feb 2013 07:56:52 -0800 (PST) Received: by 10.114.82.2 with HTTP; Mon, 4 Feb 2013 07:56:51 -0800 (PST) X-Originating-IP: [81.134.152.4] In-Reply-To: <510FCD99.3000300@ieca.com> References: <50F2F075.8090809@cs.tcd.ie> <51068A27.1050601@ieca.com> <51069692.20706@cs.tcd.ie> <510FCD99.3000300@ieca.com> Date: Mon, 4 Feb 2013 15:56:51 +0000 Message-ID: From: Thomas Fossati To: Sean Turner Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkTDBrHCEII0Qevomdfs5vV2KmBSOZlGOlWv48ZXy/1BAYJBdNKQFTQ9wlf98XV9UjHRzpq Cc: "http-auth@ietf.org" Subject: Re: [http-auth] charter rev -03 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 15:56:54 -0000 On Mon, Feb 4, 2013 at 3:02 PM, Sean Turner wrote: > Just to be clear, it's time to speak up if you support the idea of forming a > WG because silence means we shelve the idea. (Strongly) in favour of the creation of this WG. From mike@mtcc.com Mon Feb 4 08:40:09 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D40CD21F892B for ; Mon, 4 Feb 2013 08:40:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zl-OPez0TWYa for ; Mon, 4 Feb 2013 08:40:09 -0800 (PST) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id 30C1521F8928 for ; Mon, 4 Feb 2013 08:40:09 -0800 (PST) Received: from piolinux.mtcc.com (63-171-70-46.dsl.volcano.net [63.171.70.46] (may be forged)) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r14Gdp1T027691 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Feb 2013 08:40:04 -0800 Message-ID: <510FE453.7090708@mtcc.com> Date: Mon, 04 Feb 2013 08:39:47 -0800 From: Michael Thomas User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Nico Williams References: <50F2F075.8090809@cs.tcd.ie> <51068A27.1050601@ieca.com> <51069692.20706@cs.tcd.ie> <510FCD99.3000300@ieca.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=218; t=1359996005; x=1360860005; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[http-auth]=20charter=20rev=20-03 |Sender:=20 |To:=20Nico=20Williams=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=I3OB/XIkf1MdadmGWiKbwo3uitFzqJSbwSZTEG5rZ9Y=; b=Cx0Ui62gxOd8DhyPAy3fKB1Yj1plmQvbzee1HqesEK461KxIEaenh9qbm9 J79NlLq9bX75l+wVd1nz07wp0oNoqOjobM8ieNEg0e9GK6tCUz0ATIh7+N5i U52zhHwHA0IaXcf/kXULsyjLDgzoLKBlpmlEhzuEm+yytm4jbVkvA=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: "http-auth@ietf.org" Subject: Re: [http-auth] charter rev -03 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 16:40:09 -0000 Nico Williams wrote: > I support forming this WG. > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth +1 Mike From ilari.liusvaara@elisanet.fi Mon Feb 4 12:26:57 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E70721F8B19 for ; Mon, 4 Feb 2013 12:26:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofbDB0yIfTu4 for ; Mon, 4 Feb 2013 12:26:56 -0800 (PST) Received: from emh07.mail.saunalahti.fi (emh07.mail.saunalahti.fi [62.142.5.117]) by ietfa.amsl.com (Postfix) with ESMTP id 7E55621F8B0A for ; Mon, 4 Feb 2013 12:26:56 -0800 (PST) Received: from saunalahti-vams (vs3-12.mail.saunalahti.fi [62.142.5.96]) by emh07.mail.saunalahti.fi (Postfix) with SMTP id 945B13FE4; Mon, 4 Feb 2013 22:26:54 +0200 (EET) Received: from emh01.mail.saunalahti.fi ([62.142.5.107]) by vs3-12.mail.saunalahti.fi ([62.142.5.96]) with SMTP (gateway) id A02CE37555B; Mon, 04 Feb 2013 22:26:54 +0200 Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id 5CA1A90068; Mon, 4 Feb 2013 22:26:54 +0200 (EET) Date: Mon, 4 Feb 2013 22:26:54 +0200 From: Ilari Liusvaara To: Sean Turner Message-ID: <20130204202653.GA23295@LK-Perkele-VII> References: <50F2F075.8090809@cs.tcd.ie> <51068A27.1050601@ieca.com> <51069692.20706@cs.tcd.ie> <510FCD99.3000300@ieca.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <510FCD99.3000300@ieca.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Ilari Liusvaara X-Antivirus: VAMS Cc: "http-auth@ietf.org" Subject: Re: [http-auth] charter rev -03 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 20:26:57 -0000 On Mon, Feb 04, 2013 at 10:02:49AM -0500, Sean Turner wrote: > > Just to be clear, it's time to speak up if you support the idea of > forming a WG because silence means we shelve the idea. +1 for forming a WG. I think HTTP-level authentication has been negelected for too long already. -Ilari From lef.mutualauth@gmail.com Tue Feb 5 05:06:27 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE1D21F8878 for ; Tue, 5 Feb 2013 05:06:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 seCPhD8TXblO for ; Tue, 5 Feb 2013 05:06:26 -0800 (PST) Received: from mail-wi0-x229.google.com (wi-in-x0229.1e100.net [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 65ECE21F880B for ; Tue, 5 Feb 2013 05:06:26 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id l13so3807761wie.4 for ; Tue, 05 Feb 2013 05:06:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=e9fnhwF/SN5llZYT4YeAR6m23re7ql2PxTP4AKDuMWg=; b=wGTOX8IdsrN8QR4D6BfaMu6BcQPitFrbpEAxUBe9Rcmx191feTTkA30hOWRf9Unji+ s8Sb3E0Mv8Ga2lhWXhHsa/wSt/R3wDbf/7OxW8mm6GGwInHR0tidevQ0Op+EUJU+wEri 8TfdM5hqTCUKP2SrO2m3xojwNzCtJvhU89/y/p0v75lPUe2p7qkm5BHxONkVaPitNZOn qYzOXT3eMSpYut2WrgzLk2lObCn98QOTINV3CgrwNbBOmKF98SeNQv/H58JRIPpR5m0y Aya290V/E1jfji2Fl03sgnsIci506+LHsev1Nn+QgG6+Cf2G/zPs50nj2RXOB8t7Ccmv zM8Q== X-Received: by 10.180.109.82 with SMTP id hq18mr17230960wib.0.1360069585520; Tue, 05 Feb 2013 05:06:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.176.161 with HTTP; Tue, 5 Feb 2013 05:06:05 -0800 (PST) In-Reply-To: <510FCD99.3000300@ieca.com> References: <50F2F075.8090809@cs.tcd.ie> <51068A27.1050601@ieca.com> <51069692.20706@cs.tcd.ie> <510FCD99.3000300@ieca.com> From: "HAYASHI, Tatsuya" Date: Tue, 5 Feb 2013 22:06:05 +0900 Message-ID: To: Sean Turner , "http-auth@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [http-auth] charter rev -03 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 13:06:27 -0000 +1 for forming a WG. On Tue, Feb 5, 2013 at 12:02 AM, Sean Turner wrote: > On 1/28/13 10:17 AM, Stephen Farrell wrote: >> >> >> >> On 01/28/2013 02:24 PM, Sean Turner wrote: >>> >>> Right so the plan here is to put this on the BOF list with the hope that >>> a WG will get formed before IETF 86. Obviously this plan is predicated >>> on more expressions of support for the proposed charter. >> >> >> As a draft author, I think forming a wg with this charter >> would be good. (As an IESG member, I'll be recusing myself >> from IESG balloting on this.) > > > Just to be clear, it's time to speak up if you support the idea of forming a > WG because silence means we shelve the idea. > > spt > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth -- HAYASHI, Tatsuya Lepidum Co. Ltd. From y.oiwa@aist.go.jp Tue Feb 5 05:28:15 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD59521F8648 for ; Tue, 5 Feb 2013 05:28:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 Chk6EAmL8234 for ; Tue, 5 Feb 2013 05:28:14 -0800 (PST) Received: from na3sys010aog110.obsmtp.com (na3sys010aog110.obsmtp.com [74.125.245.88]) by ietfa.amsl.com (Postfix) with ESMTP id 9436A21F8645 for ; Tue, 5 Feb 2013 05:28:14 -0800 (PST) Received: from mail-qa0-f69.google.com ([209.85.216.69]) (using TLSv1) by na3sys010aob110.postini.com ([74.125.244.12]) with SMTP ID DSNKUREI7bwFRHRTfewk3AgoDyiiNBS3k3Tj@postini.com; Tue, 05 Feb 2013 05:28:14 PST Received: by mail-qa0-f69.google.com with SMTP id hy16so374859qab.4 for ; Tue, 05 Feb 2013 05:28:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=rnaIoqIFZGXdLNvLa/kM96PvmWIaL6n/uQwjIYkzcTg=; b=JD82cXycXqqFoQVuOHFTbxb2j5LRyXteio8qWBuWUfFZXrOL8fOp5m9sAEpg7J5XNG M+3ITfaptuONsQpFeTs6dxEYN15rpj9iH0SstKSXAQMQ69oiBXabVdgxcZq6V1ftDy97 4qPTpuQ6dnFDxcXciXDRWXuu/Nd8sfI8M4OAE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=rnaIoqIFZGXdLNvLa/kM96PvmWIaL6n/uQwjIYkzcTg=; b=Wchbogch4Q4uE5d/ZrezBJoQQxMuqTJ7uaR5oyO/LvIAd4IY6bJWEo5Grz1nGUseV5 e104aBAkmprQ4BqLfPdlWYXx88lEiomdkjiKDGxu9ZxxS2CRlG8gRfsdI2uCnlK/lB1e 4ZKDu6TGb7nD1eYp52D35yUSWCLdFm5xfpfRTLTN+omwolAQL0GlzzmFrONoyJzNJN9Q ZF4ioEQbcLtJ2vt7qBXbC43tdiJAbqti/qUL2Q38+egEmwDM/R2ExH6w87lPHhaHgoNA XasvLnlDWKl0BNG2Xrofu3kXcbUCTOqPESgN8Hz6eqflYU/PlyNKEpoJUyVazv0YCpae MYdQ== X-Received: by 10.220.157.18 with SMTP id z18mr27376126vcw.72.1360070892852; Tue, 05 Feb 2013 05:28:12 -0800 (PST) X-Received: by 10.220.157.18 with SMTP id z18mr27376119vcw.72.1360070892762; Tue, 05 Feb 2013 05:28:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.151.176 with HTTP; Tue, 5 Feb 2013 05:27:52 -0800 (PST) In-Reply-To: <510FCD99.3000300@ieca.com> References: <50F2F075.8090809@cs.tcd.ie> <51068A27.1050601@ieca.com> <51069692.20706@cs.tcd.ie> <510FCD99.3000300@ieca.com> From: Yutaka OIWA Date: Tue, 5 Feb 2013 22:27:52 +0900 Message-ID: To: Sean Turner Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQktAj3lvbpo1zaDi1gqDYoU429H5NjEbsLKgF1Z/STb/hojN+wS2kfa3VPwQwgS1PQOWJYPoKkbjWyryXoc7AYNGU3ojKPwT4qD0zCn9tGlThCwprl7RLHQHsq2+3mJ2GWmXAUqo2deDV3BOOQDjk6vvxPF9Q== Cc: "http-auth@ietf.org" Subject: Re: [http-auth] charter rev -03 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 13:28:15 -0000 Dear Sean, 2013/2/5 Sean Turner : > Just to be clear, it's time to speak up if you support the idea of forming a > WG because silence means we shelve the idea. +1, supportive to form a WG. # just as a re-clarification of my mail on Jan 24th... -- Yutaka OIWA, Ph.D. Leader, Software Reliability Research Group Research Institute for Secure Systems (RISEC) 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 hhalpin@w3.org Tue Feb 5 06:40:30 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6FC521F8959 for ; Tue, 5 Feb 2013 06:40:30 -0800 (PST) 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 8kI0kQOrvIXK for ; Tue, 5 Feb 2013 06:40:30 -0800 (PST) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 26FD221F84B9 for ; Tue, 5 Feb 2013 06:40:30 -0800 (PST) Received: from [212.99.51.198] (helo=[10.0.3.67]) by jay.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1U2jhF-00030h-2l; Tue, 05 Feb 2013 09:40:29 -0500 Message-ID: <511119D6.1050000@w3.org> Date: Tue, 05 Feb 2013 15:40:22 +0100 From: Harry Halpin User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Sean Turner References: <50F2F075.8090809@cs.tcd.ie> <51068A27.1050601@ieca.com> <51069692.20706@cs.tcd.ie> <510FCD99.3000300@ieca.com> In-Reply-To: <510FCD99.3000300@ieca.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "http-auth@ietf.org" Subject: Re: [http-auth] charter rev -03 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 14:40:30 -0000 +1, and happy to serve to co-ordinate with W3C and browser folks in this area. We're having an "all hands-on deck" W3C Working Group session in late April that I can run the idea by them. Overall, I think there's a very strong desire for a HTTPAuth with a SRP protocol in a few coding projects, including one I'm involved with with the LEAP hat on [1]. So I know there's at least one large-scale, multi-thousand person user-base that wants this. cheers, harry [1] https://leap.se/en On 02/04/2013 04:02 PM, Sean Turner wrote: > On 1/28/13 10:17 AM, Stephen Farrell wrote: >> >> >> On 01/28/2013 02:24 PM, Sean Turner wrote: >>> Right so the plan here is to put this on the BOF list with the hope >>> that >>> a WG will get formed before IETF 86. Obviously this plan is predicated >>> on more expressions of support for the proposed charter. >> >> As a draft author, I think forming a wg with this charter >> would be good. (As an IESG member, I'll be recusing myself >> from IESG balloting on this.) > > Just to be clear, it's time to speak up if you support the idea of > forming a WG because silence means we shelve the idea. > > spt > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth From ynir@checkpoint.com Tue Feb 5 06:42:51 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA1721F857D for ; Tue, 5 Feb 2013 06:42:51 -0800 (PST) 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=[AWL=0.000, 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 2hFAfTeFbeai for ; Tue, 5 Feb 2013 06:42:50 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF2621F8573 for ; Tue, 5 Feb 2013 06:42:49 -0800 (PST) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r15Egkua020685; Tue, 5 Feb 2013 16:42:46 +0200 X-CheckPoint: {511116BC-0-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.18]) by DAG-EX10.ad.checkpoint.com ([169.254.3.103]) with mapi id 14.02.0328.009; Tue, 5 Feb 2013 16:42:47 +0200 From: Yoav Nir To: Sean Turner Thread-Topic: [http-auth] charter rev -03 Thread-Index: AQHN8bSDW3Yh6djmAUq+/ZIEf/Dma5hewXmAgAAOzQCACvwugIABjMcA Date: Tue, 5 Feb 2013 14:42:46 +0000 Message-ID: <4613980CFC78314ABFD7F85CC30277211199C31F@IL-EX10.ad.checkpoint.com> References: <50F2F075.8090809@cs.tcd.ie> <51068A27.1050601@ieca.com> <51069692.20706@cs.tcd.ie> <510FCD99.3000300@ieca.com> In-Reply-To: <510FCD99.3000300@ieca.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [91.90.139.159] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: <80EBABE71D8B554C930FB6DCC0433AE2@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] charter rev -03 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 14:42:51 -0000 On Feb 4, 2013, at 5:02 PM, Sean Turner wrote: > On 1/28/13 10:17 AM, Stephen Farrell wrote: >>=20 >>=20 >> On 01/28/2013 02:24 PM, Sean Turner wrote: >>> Right so the plan here is to put this on the BOF list with the hope tha= t >>> a WG will get formed before IETF 86. Obviously this plan is predicated >>> on more expressions of support for the proposed charter. >>=20 >> As a draft author, I think forming a wg with this charter >> would be good. (As an IESG member, I'll be recusing myself >> from IESG balloting on this.) >=20 > Just to be clear, it's time to speak up if you support the idea of formin= g a WG because silence means we shelve the idea. It seems like we have enough people, including enough people willing to wor= k on things.=20 I am still not convinced that any of these proposals will ever see any impl= ementation. We may very well be creating a series of vanity RFCs. That said, while running code is a goal, the important consideration for fo= rming a working group is the availability of people and time to do the work= . This is available here, so I support forming the working group. Yoav From hhalpin@w3.org Tue Feb 5 06:52:18 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF73221F85B2 for ; Tue, 5 Feb 2013 06:52:17 -0800 (PST) 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 Wd3256YMIUvq for ; Tue, 5 Feb 2013 06:52:17 -0800 (PST) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id E160021F84CE for ; Tue, 5 Feb 2013 06:52:16 -0800 (PST) Received: from [212.99.51.198] (helo=[10.0.3.67]) by jay.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1U2jsd-0005Bx-4I; Tue, 05 Feb 2013 09:52:15 -0500 Message-ID: <51111C99.5070906@w3.org> Date: Tue, 05 Feb 2013 15:52:09 +0100 From: Harry Halpin User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Yoav Nir References: <50F2F075.8090809@cs.tcd.ie> <51068A27.1050601@ieca.com> <51069692.20706@cs.tcd.ie> <510FCD99.3000300@ieca.com> <4613980CFC78314ABFD7F85CC30277211199C31F@IL-EX10.ad.checkpoint.com> In-Reply-To: <4613980CFC78314ABFD7F85CC30277211199C31F@IL-EX10.ad.checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "http-auth@ietf.org" Subject: [http-auth] Anyone on mailing list working for browser vendor [was Re: charter rev -03] X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 14:52:18 -0000 On 02/05/2013 03:42 PM, Yoav Nir wrote: > On Feb 4, 2013, at 5:02 PM, Sean Turner wrote: > >> On 1/28/13 10:17 AM, Stephen Farrell wrote: >>> >>> On 01/28/2013 02:24 PM, Sean Turner wrote: >>>> Right so the plan here is to put this on the BOF list with the hope that >>>> a WG will get formed before IETF 86. Obviously this plan is predicated >>>> on more expressions of support for the proposed charter. >>> As a draft author, I think forming a wg with this charter >>> would be good. (As an IESG member, I'll be recusing myself >>> from IESG balloting on this.) >> Just to be clear, it's time to speak up if you support the idea of forming a WG because silence means we shelve the idea. > > It seems like we have enough people, including enough people willing to work on things. > > I am still not convinced that any of these proposals will ever see any implementation. We may very well be creating a series of vanity RFCs. Is anyone on this mailing list working on a browser? If not, we should do the outreach. > > That said, while running code is a goal, the important consideration for forming a working group is the availability of people and time to do the work. This is available here, so I support forming the working group. > > Yoav > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth From hallam@gmail.com Tue Feb 5 07:25:03 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D59821F88F7 for ; Tue, 5 Feb 2013 07:25:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.098 X-Spam-Level: X-Spam-Status: No, score=-6.098 tagged_above=-999 required=5 tests=[AWL=-2.500, 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 HQImmeiV+x0o for ; Tue, 5 Feb 2013 07:25:00 -0800 (PST) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) by ietfa.amsl.com (Postfix) with ESMTP id 45BC121F8552 for ; Tue, 5 Feb 2013 07:25:00 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id 15so217056wgd.28 for ; Tue, 05 Feb 2013 07:24:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Z4m023DA8StaVKmGHltV/pVehW6sGvPl3pxSl4zz0s8=; b=ZOa1FxfVMEAL+AbsKgfjdxAAO0sRFEaBDxxLTnIF8NYKCfy9Y0oRSbF0DlmZqkDM13 cFJTI7ZQtlQ1n/4cEQmUyV6iiG8TAA5vPGk+ELneoqWoquuHWuZ2MZgcvqaESCqKjqnU NLbID30ml6CVjZ+B9glFCZJQB/2pYelba7vm5NqAHPrLzldTr6JrZAiCoGc3VBcVzGbi YG/bY/Is/cHN/h31qyLVFOS/7WwFlveIJAOmewVGfpc969aXbz5aWPdQb+OEvgQlsalf ESGq6o74vatyN0VQTFvIgXZyWnRunzylgY9xPYG4/Fck3lPgfuzBayC9c+Ud6Tb14StI HAMw== MIME-Version: 1.0 X-Received: by 10.180.79.37 with SMTP id g5mr17852679wix.8.1360077896860; Tue, 05 Feb 2013 07:24:56 -0800 (PST) Received: by 10.194.85.196 with HTTP; Tue, 5 Feb 2013 07:24:56 -0800 (PST) In-Reply-To: <51111C99.5070906@w3.org> References: <50F2F075.8090809@cs.tcd.ie> <51068A27.1050601@ieca.com> <51069692.20706@cs.tcd.ie> <510FCD99.3000300@ieca.com> <4613980CFC78314ABFD7F85CC30277211199C31F@IL-EX10.ad.checkpoint.com> <51111C99.5070906@w3.org> Date: Tue, 5 Feb 2013 10:24:56 -0500 Message-ID: From: Phillip Hallam-Baker To: Harry Halpin Content-Type: multipart/alternative; boundary=f46d044306b0e8c54f04d4fbcfc8 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Anyone on mailing list working for browser vendor [was Re: charter rev -03] X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 15:25:03 -0000 --f46d044306b0e8c54f04d4fbcfc8 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 5, 2013 at 9:52 AM, Harry Halpin wrote: > On 02/05/2013 03:42 PM, Yoav Nir wrote: > >> On Feb 4, 2013, at 5:02 PM, Sean Turner wrote: >> >> On 1/28/13 10:17 AM, Stephen Farrell wrote: >>> >>>> >>>> On 01/28/2013 02:24 PM, Sean Turner wrote: >>>> >>>>> Right so the plan here is to put this on the BOF list with the hope >>>>> that >>>>> a WG will get formed before IETF 86. Obviously this plan is predicated >>>>> on more expressions of support for the proposed charter. >>>>> >>>> As a draft author, I think forming a wg with this charter >>>> would be good. (As an IESG member, I'll be recusing myself >>>> from IESG balloting on this.) >>>> >>> Just to be clear, it's time to speak up if you support the idea of >>> forming a WG because silence means we shelve the idea. >>> >> >> It seems like we have enough people, including enough people willing to >> work on things. >> >> I am still not convinced that any of these proposals will ever see any >> implementation. We may very well be creating a series of vanity RFCs. >> > > Is anyone on this mailing list working on a browser? > > If not, we should do the outreach. > I think Web browsing is pretty much water under the bridge at this point. It is possible to change the Web browsing scheme but any scheme that does so has to find a killer app outside Web browsing first. Web services are a different matter. There are hundreds being defined each week. Pretty much every single one needs an authentication layer and HTML forms won't work for that. What might be feasible is to get SAML and OAuth and OpenID to agree on using the HTTP auth scheme for authentication to the identity provider in place of the cookie based schemes that are currently in place. It is also possible that a 'hard cookie' that is a direct replacement for a traditional HTTP authentication cookie but is not passed as a bearer token and so is resistant to various MITM schemes would find favor. I would not expect the browser providers to drive this effort though. My experience there is that is pretty much the 'bring me a rock' school of management where they will give little input as to what sort of rock they want up front but tell you that its the wrong rock afterwards. -- Website: http://hallambaker.com/ --f46d044306b0e8c54f04d4fbcfc8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Feb 5, 2013 at 9:52 AM, Harry Ha= lpin <hhalpin@w3.org> wrote:
On 02/05/2013 03:42 PM, Yoav Nir wrote:
On Feb 4, 2013, at 5:02 PM, Sean Turner <turners@ieca.com> wrote:

On 1/28/13 10:17 AM, Stephen Farrell wrote:

On 01/28/2013 02:24 PM, Sean Turner wrote:
Right so the plan here is to put this on the BOF list with the hope that a WG will get formed before IETF 86. =A0Obviously this plan is predicated on more expressions of support for the proposed charter.
As a draft author, I think forming a wg with this charter
would be good. (As an IESG member, I'll be recusing myself
from IESG balloting on this.)
Just to be clear, it's time to speak up if you support the idea of form= ing a WG because silence means we shelve the idea.

It seems like we have enough people, including enough people willing to wor= k on things.

I am still not convinced that any of these proposals will ever see any impl= ementation. We may very well be creating a series of vanity RFCs.

=A0Is anyone on this mailing list working on a browser?

=A0If not, we should do the outreach.

I= think Web browsing is pretty much water under the bridge at this point. It= is possible to change the Web browsing scheme but any scheme that does so = has to find a killer app outside Web browsing first.

Web services are a different matter. There are hundreds= being defined each week. Pretty much every single one needs an authenticat= ion layer and HTML forms won't work for that.=A0


What might be feasible is to get SAML and OAuth and Ope= nID to agree on using the HTTP auth scheme for authentication to the identi= ty provider in place of the cookie based schemes that are currently in plac= e.

It is also possible that a 'hard cookie' that i= s a direct replacement for a traditional HTTP authentication cookie but is = not passed as a bearer token and so is resistant to various MITM schemes wo= uld find favor.

I would not expect the browser providers to drive this = effort though. My experience there is that is pretty much the 'bring me= a rock' school of management where they will give little input as to w= hat sort of rock they want up front but tell you that its the wrong rock af= terwards.=A0
=A0

--
Website: http://hallambaker.com/
--f46d044306b0e8c54f04d4fbcfc8-- From paul.hoffman@vpnc.org Tue Feb 5 07:50:25 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C39E21F88DD for ; Tue, 5 Feb 2013 07:50:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 qYs90Jmwk3Kj for ; Tue, 5 Feb 2013 07:50:24 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id AC7A321F88B4 for ; Tue, 5 Feb 2013 07:50:24 -0800 (PST) Received: from [10.20.30.90] (50-1-98-243.dsl.dynamic.sonic.net [50.1.98.243]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r15FoNlf036922 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 5 Feb 2013 08:50:24 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: <4613980CFC78314ABFD7F85CC30277211199C31F@IL-EX10.ad.checkpoint.com> Date: Tue, 5 Feb 2013 07:50:24 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50F2F075.8090809@cs.tcd.ie> <51068A27.1050601@ieca.com> <51069692.20706@cs.tcd.ie> <510FCD99.3000300@ieca.com> <4613980CFC78314ABFD7F85CC30277211199C31F@IL-EX10.ad.checkpoint.com> To: "http-auth@ietf.org" X-Mailer: Apple Mail (2.1499) Subject: Re: [http-auth] charter rev -03 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 15:50:25 -0000 On Feb 5, 2013, at 6:42 AM, Yoav Nir wrote: > It seems like we have enough people, including enough people willing = to work on things.=20 >=20 > I am still not convinced that any of these proposals will ever see any = implementation. We may very well be creating a series of vanity RFCs. >=20 > That said, while running code is a goal, the important consideration = for forming a working group is the availability of people and time to do = the work. This is available here, so I support forming the working = group. +1, +1, +.5 --Paul Hoffman= From julian.reschke@gmx.de Tue Feb 5 07:54:13 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99D4C21F85CB for ; Tue, 5 Feb 2013 07:54:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.119 X-Spam-Level: X-Spam-Status: No, score=-105.119 tagged_above=-999 required=5 tests=[AWL=-2.520, 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 IyGvWsWKxREG for ; Tue, 5 Feb 2013 07:54:13 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id DDD8921F85BC for ; Tue, 5 Feb 2013 07:54:07 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.27]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MLUQ0-1U3IoJ378E-000cs0 for ; Tue, 05 Feb 2013 16:54:05 +0100 Received: (qmail invoked by alias); 05 Feb 2013 15:54:05 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.102]) [217.91.35.233] by mail.gmx.net (mp027) with SMTP; 05 Feb 2013 16:54:05 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/5wAhOYO/5IKvZoyVlT8xAft7B2Ihf4C4cmHDeBE RdnZ45LSYe7t+Q Message-ID: <51112B1C.7040201@gmx.de> Date: Tue, 05 Feb 2013 16:54:04 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <50F2F075.8090809@cs.tcd.ie> <51068A27.1050601@ieca.com> <51069692.20706@cs.tcd.ie> <510FCD99.3000300@ieca.com> <4613980CFC78314ABFD7F85CC30277211199C31F@IL-EX10.ad.checkpoint.com> <51111C99.5070906@w3.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Anyone on mailing list working for browser vendor [was Re: charter rev -03] X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 15:54:13 -0000 On 2013-02-05 16:24, Phillip Hallam-Baker wrote: > > > On Tue, Feb 5, 2013 at 9:52 AM, Harry Halpin > wrote: > > On 02/05/2013 03:42 PM, Yoav Nir wrote: > > On Feb 4, 2013, at 5:02 PM, Sean Turner > wrote: > > On 1/28/13 10:17 AM, Stephen Farrell wrote: > > > On 01/28/2013 02:24 PM, Sean Turner wrote: > > Right so the plan here is to put this on the BOF > list with the hope that > a WG will get formed before IETF 86. Obviously this > plan is predicated > on more expressions of support for the proposed charter. > > As a draft author, I think forming a wg with this charter > would be good. (As an IESG member, I'll be recusing myself > from IESG balloting on this.) > > Just to be clear, it's time to speak up if you support the > idea of forming a WG because silence means we shelve the idea. > > > It seems like we have enough people, including enough people > willing to work on things. > > I am still not convinced that any of these proposals will ever > see any implementation. We may very well be creating a series of > vanity RFCs. > > > Is anyone on this mailing list working on a browser? > > If not, we should do the outreach. > > > I think Web browsing is pretty much water under the bridge at this > point. It is possible to change the Web browsing scheme but any scheme > that does so has to find a killer app outside Web browsing first. > ... Hmm. The charter contains: > In addition, the WG will aim to get rough consensus on two drafts that > will obsolete the basic and digest schemes defined in RFC 2617 taking > into account errata on that specification. > > For the digest scheme, "more modern" algorithm agility and > internationalisation support will be developed as a standards-track > RFC. The starting point for this will be > draft-ahrens-httpbis-digest-auth-update, but the WG is not precluded > from e.g. adding a Diffie-Hellman exchange to this method. > > For the basic scheme, no technical changes are envisaged other than to > handle i18n of usernames and passwords, the goal will simply be to > improve the documentation of the scheme to allow obsoleting RFC 2617 > which has some significant flaws when looked back at 13 years later. It should be our goal to get at least these implemented in browsers. Best regards, Julian From paul.hoffman@vpnc.org Tue Feb 5 08:04:09 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0527D21F88DD for ; Tue, 5 Feb 2013 08:04:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 PXBWTRUCjLBD for ; Tue, 5 Feb 2013 08:04:08 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 92E0921F8552 for ; Tue, 5 Feb 2013 08:04:08 -0800 (PST) Received: from [10.20.30.90] (50-1-98-243.dsl.dynamic.sonic.net [50.1.98.243]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r15G46B4037483 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 5 Feb 2013 09:04:08 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: <51112B1C.7040201@gmx.de> Date: Tue, 5 Feb 2013 08:04:07 -0800 Content-Transfer-Encoding: 7bit Message-Id: <5B3BB4F1-F929-45FC-BA9B-71FC985A05AD@vpnc.org> References: <50F2F075.8090809@cs.tcd.ie> <51068A27.1050601@ieca.com> <51069692.20706@cs.tcd.ie> <510FCD99.3000300@ieca.com> <4613980CFC78314ABFD7F85CC30277211199C31F@IL-EX10.ad.checkpoint.com> <51111C99.5070906@w3.org> <51112B1C.7040201@gmx.de> To: "http-auth@ietf.org" X-Mailer: Apple Mail (2.1499) Subject: Re: [http-auth] Anyone on mailing list working for browser vendor [was Re: charter rev -03] X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 16:04:09 -0000 On Feb 5, 2013, at 7:54 AM, Julian Reschke wrote: > It should be our goal to get at least these implemented in browsers. +1. It is inappropriate to suggest otherwise. --Paul Hoffman From hallam@gmail.com Tue Feb 5 08:25:09 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A528E21F894E for ; Tue, 5 Feb 2013 08:25:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.786 X-Spam-Level: X-Spam-Status: No, score=-5.786 tagged_above=-999 required=5 tests=[AWL=-2.188, 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 qtqmUQeeJnXr for ; Tue, 5 Feb 2013 08:25:04 -0800 (PST) Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) by ietfa.amsl.com (Postfix) with ESMTP id F300021F8923 for ; Tue, 5 Feb 2013 08:24:51 -0800 (PST) Received: by mail-wg0-f51.google.com with SMTP id 8so271799wgl.18 for ; Tue, 05 Feb 2013 08:24:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=8J+DON0ZkKVbXvlCzwEvE4oHTgMNL1bnCGV7087lufc=; b=vf+aYhHzJNBEsiwLeByon8BqF0q36uccLoA1KW/339b4n2iZsjMMUCPRVkXXTm4vtf UShmhjMupRoRORM/QHvha5VAMEupdS8Xh5gWvIZq8cQG0qjb/MjzvSQ9r51pLHAc5uBc ltxGpr3JYhaCf4aXbr0SVDInQqwCNsu9DTfTZLK2/0REUWHYkrvz5r4xLNIWU9RHhpGV 309oYa9OmVpoTjWL7HUcB/JQC1HaSiq6/gyHD+Hx99UDhMqUls76W1QraRbYSb8Go8Tc BBu1eNxIh9SBQa1KJAHU0JXXlRBxrnPuCh0SMH98NFoQgNMO/GQhmiHz4zRDqWNJiVqP Vzag== MIME-Version: 1.0 X-Received: by 10.194.123.105 with SMTP id lz9mr43868808wjb.43.1360081488806; Tue, 05 Feb 2013 08:24:48 -0800 (PST) Received: by 10.194.85.196 with HTTP; Tue, 5 Feb 2013 08:24:48 -0800 (PST) In-Reply-To: <5B3BB4F1-F929-45FC-BA9B-71FC985A05AD@vpnc.org> References: <50F2F075.8090809@cs.tcd.ie> <51068A27.1050601@ieca.com> <51069692.20706@cs.tcd.ie> <510FCD99.3000300@ieca.com> <4613980CFC78314ABFD7F85CC30277211199C31F@IL-EX10.ad.checkpoint.com> <51111C99.5070906@w3.org> <51112B1C.7040201@gmx.de> <5B3BB4F1-F929-45FC-BA9B-71FC985A05AD@vpnc.org> Date: Tue, 5 Feb 2013 11:24:48 -0500 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: multipart/alternative; boundary=089e011776990181e204d4fca658 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Anyone on mailing list working for browser vendor [was Re: charter rev -03] X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 16:25:10 -0000 --089e011776990181e204d4fca658 Content-Type: text/plain; charset=ISO-8859-1 Who ever appointed you to say what is appropriate or not? Nobody, that is who. Now I would let it slide only you spend a lot of your time making snippy comments accusing others of this behavior. Moreover, you are misrepresenting what I said which was not 'we should not try' but 'don't expect to see the browser people participate' and in particular 'don't gate on the browser people providing input'. Which is another thing you spend rather too much time policing. On Tue, Feb 5, 2013 at 11:04 AM, Paul Hoffman wrote: > On Feb 5, 2013, at 7:54 AM, Julian Reschke wrote: > > > It should be our goal to get at least these implemented in browsers. > > +1. It is inappropriate to suggest otherwise. > > --Paul Hoffman > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > -- Website: http://hallambaker.com/ --089e011776990181e204d4fca658 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Who ever appointed you to say what is appropriate or not?

Nobody, that is who.

Now I would let it slide on= ly you spend a lot of your time making snippy comments accusing others of t= his behavior.=A0


Moreover, you are misrepresenting what I= said which was not 'we should not try' but 'don't expect t= o see the browser people participate' and in particular 'don't = gate on the browser people providing input'.

Which is another thing you spend rather too much time p= olicing.


On Tue, Fe= b 5, 2013 at 11:04 AM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
On Feb 5, 2013, at 7:54 AM= , Julian Reschke <julian.reschk= e@gmx.de> wrote:

> It should be our goal to get at least these implemented in browsers.
+1. It is inappropriate to suggest otherwise.

--Paul Hoffman
_____________________= __________________________
http-auth mailing list
http-auth@ietf.org
https://www.ietf.org/mailman/listinfo/http-auth



--
= Website: http://hallambaker.com/
--089e011776990181e204d4fca658-- From nico@cryptonector.com Tue Feb 5 08:30:35 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCF3121F87CE for ; Tue, 5 Feb 2013 08:30:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.674 X-Spam-Level: X-Spam-Status: No, score=-3.674 tagged_above=-999 required=5 tests=[AWL=-1.698, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 CPkZtpZLF7Vd for ; Tue, 5 Feb 2013 08:30:35 -0800 (PST) Received: from homiemail-a64.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id AF89821F8558 for ; Tue, 5 Feb 2013 08:30:33 -0800 (PST) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id 61D59438081 for ; Tue, 5 Feb 2013 08:30:33 -0800 (PST) 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=AIZlsOlj9PjtbUwS5OuE y6QneiM=; b=f/St7zMGyJkgdYkRp9Xv/4infH3iEa1CzoikDMFkkSKUk3dYk46C U3ZLY2qUQZw9Plxgq1MEc/YsTAT12t3kfKwwvPRxMyR0Qy68EAZaU/kwnx5SobNO oV7SZxT05Asz44B5JfX/Fe6//AjJA0hE9gjMuEnCP3y/31JaMg7w8h0= Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPSA id EFB78438072 for ; Tue, 5 Feb 2013 08:30:32 -0800 (PST) Received: by mail-wg0-f53.google.com with SMTP id fn15so281808wgb.8 for ; Tue, 05 Feb 2013 08:30:31 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.84.165 with SMTP id a5mr18523995wiz.6.1360081831603; Tue, 05 Feb 2013 08:30:31 -0800 (PST) Received: by 10.217.39.133 with HTTP; Tue, 5 Feb 2013 08:30:31 -0800 (PST) Received: by 10.217.39.133 with HTTP; Tue, 5 Feb 2013 08:30:31 -0800 (PST) In-Reply-To: <5B3BB4F1-F929-45FC-BA9B-71FC985A05AD@vpnc.org> References: <50F2F075.8090809@cs.tcd.ie> <51068A27.1050601@ieca.com> <51069692.20706@cs.tcd.ie> <510FCD99.3000300@ieca.com> <4613980CFC78314ABFD7F85CC30277211199C31F@IL-EX10.ad.checkpoint.com> <51111C99.5070906@w3.org> <51112B1C.7040201@gmx.de> <5B3BB4F1-F929-45FC-BA9B-71FC985A05AD@vpnc.org> Date: Tue, 5 Feb 2013 10:30:31 -0600 Message-ID: From: Nico Williams To: Paul Hoffman Content-Type: multipart/alternative; boundary=f46d0418270e702ea104d4fcba8b Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Anyone on mailing list working for browser vendor [was Re: charter rev -03] X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 16:30:35 -0000 --f46d0418270e702ea104d4fcba8b Content-Type: text/plain; charset=UTF-8 On Feb 5, 2013 11:04 AM, "Paul Hoffman" wrote: > > On Feb 5, 2013, at 7:54 AM, Julian Reschke wrote: > > > It should be our goal to get at least these implemented in browsers. > > +1. It is inappropriate to suggest otherwise. +1. And non-browser clients. And (of course) servers. IMO we must also pursue a generic session continuation protocol as proposed many times recently in various fora, preferably in the WEBSEC WG. Nico -- --f46d0418270e702ea104d4fcba8b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Feb 5, 2013 11:04 AM, "Paul Hoffman" <paul.hoffman@vpnc.org> wrote:
>
> On Feb 5, 2013, at 7:54 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
>
> > It should be our goal to get at least these implemented in browse= rs.
>
> +1. It is inappropriate to suggest otherwise.

+1.=C2=A0 And non-browser clients.=C2=A0 And (of course) servers.

IMO we must also pursue a generic session continuation protocol as propo= sed many times recently in various fora, preferably in the WEBSEC WG.

Nico
--

--f46d0418270e702ea104d4fcba8b-- From nico@cryptonector.com Tue Feb 5 08:30:50 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 824EF21F8919 for ; Tue, 5 Feb 2013 08:30:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.297 X-Spam-Level: X-Spam-Status: No, score=-4.297 tagged_above=-999 required=5 tests=[AWL=-2.321, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 slSpR4yMYAat for ; Tue, 5 Feb 2013 08:30:49 -0800 (PST) Received: from homiemail-a98.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 28FC221F8558 for ; Tue, 5 Feb 2013 08:30:49 -0800 (PST) Received: from homiemail-a98.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a98.g.dreamhost.com (Postfix) with ESMTP id D901C2C206E for ; Tue, 5 Feb 2013 08:30:48 -0800 (PST) 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=hdkaZvSImq9R8p6bbn3T 2MxbDFY=; b=pgaPI6zQOYk1VenXYlXzhdfCswXZvIftSQp4ilPTF0Lou6usvdsA aZ/TZQxWz5wwhl4shg8Brwz0wLjxI0A/JGXb0+DnzB8SA6XohiLZMw8dOIyzx6ko V/yn+ci6EgSHk0wo6wDwO3w6rBIRz07lJFtcWBMbPw+k34a3ZFIG47I= Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a98.g.dreamhost.com (Postfix) with ESMTPSA id 82E642C2079 for ; Tue, 5 Feb 2013 08:30:48 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id hi18so448696wib.3 for ; Tue, 05 Feb 2013 08:30:47 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.82.9 with SMTP id e9mr18685057wiy.1.1360081847126; Tue, 05 Feb 2013 08:30:47 -0800 (PST) Received: by 10.217.39.133 with HTTP; Tue, 5 Feb 2013 08:30:47 -0800 (PST) Received: by 10.217.39.133 with HTTP; Tue, 5 Feb 2013 08:30:47 -0800 (PST) In-Reply-To: References: <50F2F075.8090809@cs.tcd.ie> <51068A27.1050601@ieca.com> <51069692.20706@cs.tcd.ie> <510FCD99.3000300@ieca.com> <4613980CFC78314ABFD7F85CC30277211199C31F@IL-EX10.ad.checkpoint.com> <51111C99.5070906@w3.org> <51112B1C.7040201@gmx.de> <5B3BB4F1-F929-45FC-BA9B-71FC985A05AD@vpnc.org> Date: Tue, 5 Feb 2013 10:30:47 -0600 Message-ID: From: Nico Williams To: Paul Hoffman Content-Type: multipart/alternative; boundary=f46d044304765d098904d4fcbb48 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Anyone on mailing list working for browser vendor [was Re: charter rev -03] X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 16:30:51 -0000 --f46d044304765d098904d4fcbb48 Content-Type: text/plain; charset=UTF-8 On Feb 5, 2013 11:04 AM, "Paul Hoffman" wrote: > > On Feb 5, 2013, at 7:54 AM, Julian Reschke wrote: > > > It should be our goal to get at least these implemented in browsers. > > +1. It is inappropriate to suggest otherwise. +1. And non-browser clients. And (of course) servers. IMO we must also pursue a generic session continuation protocol as proposed many times recently in various fora, preferably in the WEBSEC WG. Nico -- --f46d044304765d098904d4fcbb48 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Feb 5, 2013 11:04 AM, "Paul Hoffman" <paul.hoffman@vpnc.org> wrote:
>
> On Feb 5, 2013, at 7:54 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
>
> > It should be our goal to get at least these implemented in browse= rs.
>
> +1. It is inappropriate to suggest otherwise.

+1.=C2=A0 And non-browser clients.=C2=A0 And (of course) servers.

IMO we must also pursue a generic session continuation protocol as propo= sed many times recently in various fora, preferably in the WEBSEC WG.

Nico
--

--f46d044304765d098904d4fcbb48-- From hallam@gmail.com Tue Feb 5 08:42:31 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14E6121F845E for ; Tue, 5 Feb 2013 08:42:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 7w-ytoanKoN9 for ; Tue, 5 Feb 2013 08:42:30 -0800 (PST) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 847F821F8518 for ; Tue, 5 Feb 2013 08:42:28 -0800 (PST) Received: by mail-we0-f177.google.com with SMTP id d7so311408wer.22 for ; Tue, 05 Feb 2013 08:42:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=xTaB2NLMHS82xQfeqdgxiFX1JxoSCRMZkRrtLn3xVuI=; b=snous4qyMdMQ7/zm7zmn93TNpZxRRQUaIjKwUaTBuWYUPSTwCKNY3IVBysAYsWnwtL pkWWY7rNTWajqaTC1JDnED2Dy0JTKkzdKGYpDBGs/hsawf/KWeffZNLr5X0f8j76M+vO FNiOo06GzBr9PSLifIJf2y3ccExiwuGzvIB6GwgllJOgRSB1aANHifrE1V0LqM11ag2J pTp8xXmzQUW6TQ1FlVgao/Ze8i9q7cq2537FS8BxRrsmEqLIEDf90mb5Livgl/lmSG8s TschIyUxT6StrfxUnWvnvNxuj10bVqjbATRHovb9KeIV5Vzl8bLHzQD9W3T0o+LIquOw WN6Q== MIME-Version: 1.0 X-Received: by 10.180.94.234 with SMTP id df10mr18601604wib.17.1360082547637; Tue, 05 Feb 2013 08:42:27 -0800 (PST) Received: by 10.194.85.196 with HTTP; Tue, 5 Feb 2013 08:42:27 -0800 (PST) In-Reply-To: <50F2F075.8090809@cs.tcd.ie> References: <50F2F075.8090809@cs.tcd.ie> Date: Tue, 5 Feb 2013 11:42:27 -0500 Message-ID: From: Phillip Hallam-Baker To: Stephen Farrell Content-Type: multipart/alternative; boundary=f46d0444ea9f1dfcb604d4fce507 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] charter rev -03 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 16:42:31 -0000 --f46d0444ea9f1dfcb604d4fce507 Content-Type: text/plain; charset=ISO-8859-1 I think that it needs to be clear that we are currently in a charter discussion and that this is still an proposal. It is thus entirely appropriate to suggest that the focus of this work should be enabling Web Service interactions which represents a 'green field' site for development rather than trying to propose a mechanism to replace the legacy Web browser base. While I would like to do the second, I don't want anyone to judge the success of the group by the likelihood they would deliver in that particular area. On Sun, Jan 13, 2013 at 12:35 PM, Stephen Farrell wrote: > > Hi all and happy new year, > > Sorry to have done nothing since mid-Nov on this, but I've > finally gotten around to going back over the list traffic > and modified the text to make the attached -03 version of > the charter. > > I think this one is good enough to hand over to Sean to see > what he wants to do about it, that is, I don't see it getting > way way better due to mail on this list, so I reckon we're > done for now, and its over to Sean to see what he thinks. > > Cheers, > S. > > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > > -- Website: http://hallambaker.com/ --f46d0444ea9f1dfcb604d4fce507 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think that it needs to be clear that we are currently in a charter discus= sion and that this is still an proposal.

It is thus enti= rely appropriate to suggest that the focus of this work should be enabling = Web Service interactions which represents a 'green field' site for = development rather than trying to propose a mechanism to replace the legacy= Web browser base.

While I would like to do the second, I don't want a= nyone to judge the success of the group by the likelihood they would delive= r in that particular area.


On Sun, Jan 13, 2013 at 12:35 PM, Stephen Farrell <stephen.farrell= @cs.tcd.ie> wrote:

Hi all and happy new year,

Sorry to have done nothing since mid-Nov on this, but I've
finally gotten around to going back over the list traffic
and modified the text to make the attached -03 version of
the charter.

I think this one is good enough to hand over to Sean to see
what he wants to do about it, that is, I don't see it getting
way way better due to mail on this list, so I reckon we're
done for now, and its over to Sean to see what he thinks.

Cheers,
S.


_______________________________________________
http-auth mailing list
http-auth@ietf.org
https://www.ietf.org/mailman/listinfo/http-auth




--
Website:= http://hallambaker.com/
--f46d0444ea9f1dfcb604d4fce507-- From stephen.farrell@cs.tcd.ie Tue Feb 5 08:53:57 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8635E21F8694 for ; Tue, 5 Feb 2013 08:53:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 9qdxEi63K8zc for ; Tue, 5 Feb 2013 08:53:56 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id C5E2E21F867B for ; Tue, 5 Feb 2013 08:53:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1AE0FBE49; Tue, 5 Feb 2013 16:53:28 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qn0VHlFuuIHX; Tue, 5 Feb 2013 16:53:25 +0000 (GMT) Received: from [IPv6:2001:770:10:203:888c:6d5d:3340:b249] (unknown [IPv6:2001:770:10:203:888c:6d5d:3340:b249]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DF8BFBE35; Tue, 5 Feb 2013 16:53:25 +0000 (GMT) Message-ID: <51113907.3010503@cs.tcd.ie> Date: Tue, 05 Feb 2013 16:53:27 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <50F2F075.8090809@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "http-auth@ietf.org" Subject: Re: [http-auth] charter rev -03 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 16:53:57 -0000 Hi Phill, Actually I think we're all really agreeing about what's doable and what's not, even you and Paul:-) Nobody here (afaik) thinks we're gonna get browsers to immediately adopt any lovely new fangled experimental stuff that's proposed. If non-browsers do adopt then that's great and we'll see where it goes. For the two things Julian mentioned we would like browsers to adopt them if we do a good job, hence it seems reasonable to try progress those on the standards track. If there are charter text changes that you want to suggest then please do so, but I think the -03 version captures the above already. And of course, if Sean decides to take this further then there'll be more opportunities to comment and propose changes as the charter is reviewed. Cheers, S. On 02/05/2013 04:42 PM, Phillip Hallam-Baker wrote: > I think that it needs to be clear that we are currently in a charter > discussion and that this is still an proposal. > > It is thus entirely appropriate to suggest that the focus of this work > should be enabling Web Service interactions which represents a 'green > field' site for development rather than trying to propose a mechanism to > replace the legacy Web browser base. > > While I would like to do the second, I don't want anyone to judge the > success of the group by the likelihood they would deliver in that > particular area. > > > On Sun, Jan 13, 2013 at 12:35 PM, Stephen Farrell > wrote: > >> >> Hi all and happy new year, >> >> Sorry to have done nothing since mid-Nov on this, but I've >> finally gotten around to going back over the list traffic >> and modified the text to make the attached -03 version of >> the charter. >> >> I think this one is good enough to hand over to Sean to see >> what he wants to do about it, that is, I don't see it getting >> way way better due to mail on this list, so I reckon we're >> done for now, and its over to Sean to see what he thinks. >> >> Cheers, >> S. >> >> >> _______________________________________________ >> http-auth mailing list >> http-auth@ietf.org >> https://www.ietf.org/mailman/listinfo/http-auth >> >> > > From hotz@jpl.nasa.gov Tue Feb 5 09:45:21 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17A5221F8688 for ; Tue, 5 Feb 2013 09:45:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.489 X-Spam-Level: X-Spam-Status: No, score=-5.489 tagged_above=-999 required=5 tests=[AWL=1.110, 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 9ji1VJLndWpU for ; Tue, 5 Feb 2013 09:45:20 -0800 (PST) Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.106]) by ietfa.amsl.com (Postfix) with ESMTP id A3A8821F8630 for ; Tue, 5 Feb 2013 09:45:20 -0800 (PST) Received: from laphotz.jpl.nasa.gov (laphotz.jpl.nasa.gov [128.149.133.44]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r15HjIHE015091 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Tue, 5 Feb 2013 09:45:19 -0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: "Henry B. Hotz" In-Reply-To: Date: Tue, 5 Feb 2013 09:45:17 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50F2F075.8090809@cs.tcd.ie> <51068A27.1050601@ieca.com> <51069692.20706@cs.tcd.ie> <510FCD99.3000300@ieca.com> <4613980CFC78314ABFD7F85CC30277211199C31F@IL-EX10.ad.checkpoint.com> <51111C99.5070906@w3.org> <51112B1C.7040201@gmx.de> <5B3BB4F1-F929-45FC-BA9B-71FC985A05AD@vpnc.org> To: Nico Williams X-Mailer: Apple Mail (2.1499) X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: "http-auth@ietf.org" , Paul Hoffman Subject: Re: [http-auth] Anyone on mailing list working for browser vendor [was Re: charter rev -03] X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 17:45:21 -0000 +1 However I have not heard any answer addressing the original question, = which would seem to be a prerequisite. ------------------------------------------------------ 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 On Feb 5, 2013, at 8:30 AM, Nico Williams wrote: >=20 > On Feb 5, 2013 11:04 AM, "Paul Hoffman" wrote: > > > > On Feb 5, 2013, at 7:54 AM, Julian Reschke = wrote: > > > > > It should be our goal to get at least these implemented in = browsers. > > > > +1. It is inappropriate to suggest otherwise. >=20 > +1. And non-browser clients. And (of course) servers. >=20 > IMO we must also pursue a generic session continuation protocol as = proposed many times recently in various fora, preferably in the WEBSEC = WG. >=20 > Nico > --=20 > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth From cmhjones@gmail.com Tue Feb 5 10:41:01 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC06221F85AF for ; Tue, 5 Feb 2013 10:41:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.402 X-Spam-Level: * X-Spam-Status: No, score=1.402 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_SUMOF=5, 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 63MqBjFmOycH for ; Tue, 5 Feb 2013 10:41:01 -0800 (PST) Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0F821F85E7 for ; Tue, 5 Feb 2013 10:41:01 -0800 (PST) Received: by mail-ob0-f181.google.com with SMTP id ni5so508655obc.40 for ; Tue, 05 Feb 2013 10:40:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=V04t1LPZCdzH+yrl3eww4FIMSkHROWC0oY8oLAuHx1s=; b=bKfw+0Y1ECiw7JSwmSodq+Ii4QwM6bVbnoYj4fFm3tIBJI3zV1MgQaPoteYiqFRVNI ehLR6RiSp6uX66vRAwd4YfVuty5BHYL/gtFWZACBFB34TNAwgyW5wkMaOXzPGkmnUc3S TCi0Pl/Rhu1UgdI/mjNa0bgRl54nNF+bJQT4N0OcQ5KYs81Enj4qRlGyHPLQ2tijHSNH sGjNAV4vHdZFY2AZqSDb0aP1F7pMuFdnZP3g4+5jcxc9lJnKdskg35H6y3TlvH7+5KIX Efjh9SXsw4xzTaUiuM/EfjM9ibftryEgQym1CZTgkqmI7mKqstVahXK6grgY9xfL1bzE QLQA== MIME-Version: 1.0 X-Received: by 10.60.172.80 with SMTP id ba16mr18349666oec.116.1360089655935; Tue, 05 Feb 2013 10:40:55 -0800 (PST) Received: by 10.60.162.103 with HTTP; Tue, 5 Feb 2013 10:40:55 -0800 (PST) In-Reply-To: <51111C99.5070906@w3.org> References: <50F2F075.8090809@cs.tcd.ie> <51068A27.1050601@ieca.com> <51069692.20706@cs.tcd.ie> <510FCD99.3000300@ieca.com> <4613980CFC78314ABFD7F85CC30277211199C31F@IL-EX10.ad.checkpoint.com> <51111C99.5070906@w3.org> Date: Tue, 5 Feb 2013 18:40:55 +0000 Message-ID: From: Cameron Jones To: Harry Halpin Content-Type: multipart/alternative; boundary=bcaec5523bb6ce015504d4fe8c0c Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Anyone on mailing list working for browser vendor [was Re: charter rev -03] X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 18:41:02 -0000 --bcaec5523bb6ce015504d4fe8c0c Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 5, 2013 at 2:52 PM, Harry Halpin wrote: > On 02/05/2013 03:42 PM, Yoav Nir wrote: > >> On Feb 4, 2013, at 5:02 PM, Sean Turner wrote: >> >> On 1/28/13 10:17 AM, Stephen Farrell wrote: >>> >>>> >>>> On 01/28/2013 02:24 PM, Sean Turner wrote: >>>> >>>>> Right so the plan here is to put this on the BOF list with the hope >>>>> that >>>>> a WG will get formed before IETF 86. Obviously this plan is predicated >>>>> on more expressions of support for the proposed charter. >>>>> >>>> As a draft author, I think forming a wg with this charter >>>> would be good. (As an IESG member, I'll be recusing myself >>>> from IESG balloting on this.) >>>> >>> Just to be clear, it's time to speak up if you support the idea of >>> forming a WG because silence means we shelve the idea. >>> >> >> It seems like we have enough people, including enough people willing to >> work on things. >> >> I am still not convinced that any of these proposals will ever see any >> implementation. We may very well be creating a series of vanity RFCs. >> > > Is anyone on this mailing list working on a browser? > > If not, we should do the outreach. > > This was briefly skimmed over in the HTML WG F2F in Lyon, November 2012 where Henri from Mozilla indicated that they would potentially be interested in implementing new HTTP Auth schemes. That was pretty much the sum of it. He also indicated that they're quite keen on their BrowserID mechanism. Without wanting to speak for him any more, i'd think they might be happy for the outreach. I think largely what is in demand, based on other input to the HTML group, is a SRP-style protocol to protect against server password leaks. The negotiation process should be enough for a new protocol to be trickle adopted, however there is a slight problem for existing organizations - when would they delete their old databases and thus realize the benefits of the protocol? The other aspects of zero-knowledge password proofs would probably outweigh this enough for adoption tho, especially if there is strong consumer demand driven by more frequent breaches, but perhaps the horse bolted long ago for organizations interested in complete zero-knowlege with persistent backwards compatibility - ie6 grips hold of what life it had with a vengeance. Thanks, Cameron Jones --bcaec5523bb6ce015504d4fe8c0c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Feb 5, 2013 at 2:52 PM, Harry Halpin <hhal= pin@w3.org> wrote:
On 02/05/2013 03:42 PM, Yoav Nir wrote:
On Feb 4, 2013, at 5:02 PM, Sean Turner <turners@ieca.com> wrote:

On 1/28/13 10:17 AM, Stephen Farrell wrote:

On 01/28/2013 02:24 PM, Sean Turner wrote:
Right so the plan here is to put this on the BOF list with the hope that a WG will get formed before IETF 86. =A0Obviously this plan is predicated on more expressions of support for the proposed charter.
As a draft author, I think forming a wg with this charter
would be good. (As an IESG member, I'll be recusing myself
from IESG balloting on this.)
Just to be clear, it's time to speak up if you support the idea of form= ing a WG because silence means we shelve the idea.

It seems like we have enough people, including enough people willing to wor= k on things.

I am still not convinced that any of these proposals will ever see any impl= ementation. We may very well be creating a series of vanity RFCs.

=A0Is anyone on this mailing list working on a browser?

=A0If not, we should do the outreach.


This was briefly skimmed over in the HTML WG F2F = in Lyon, November 2012 where Henri from Mozilla indicated that they would p= otentially be interested in implementing new HTTP Auth schemes. That was pr= etty much the sum of it. He also indicated that they're quite keen on t= heir BrowserID mechanism. Without wanting to speak for him any more, i'= d think they might be happy for the outreach.

I think largely what is in demand, based on other input to the HTML gro= up, is a SRP-style protocol to protect against server password leaks. The n= egotiation process should be enough for a new protocol to be trickle adopte= d, however there is a slight problem for existing organizations - when woul= d they delete their old databases and thus realize the benefits of the prot= ocol? The other aspects of zero-knowledge password proofs would probably ou= tweigh this enough for adoption tho, especially if there is strong consumer= demand driven by more frequent breaches, but perhaps the horse bolted long= ago for organizations interested in complete zero-knowlege with persistent= backwards compatibility - ie6 grips hold of what life it had with a vengea= nce.

Thanks,
Cameron Jones
--bcaec5523bb6ce015504d4fe8c0c-- From cmhjones@gmail.com Tue Feb 5 10:51:04 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03CEF21F8549 for ; Tue, 5 Feb 2013 10:51:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.098 X-Spam-Level: X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5 tests=[AWL=2.500, 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 Sa9Ern-gnfe3 for ; Tue, 5 Feb 2013 10:51:03 -0800 (PST) Received: from mail-ob0-f170.google.com (mail-ob0-f170.google.com [209.85.214.170]) by ietfa.amsl.com (Postfix) with ESMTP id 65DED21F853D for ; Tue, 5 Feb 2013 10:51:03 -0800 (PST) Received: by mail-ob0-f170.google.com with SMTP id wc20so538787obb.1 for ; Tue, 05 Feb 2013 10:51:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ziuACFeGBfyF8yO9ZS5qFYfb/XUsuhEN1WrVxv+IRME=; b=D+jlZ0e1iQMTYRQHjmLS+LnME/zDBdMGDS7C/ntqn9vL7iH0vIF+rTGDWmY2lLm4Az Asl7limWtvOS2uWpNHD52pZxhRc6Bho/7xxq599RccsJ+SjYNhdmRIcWMcEVaW/a4RnY z4hJ/lzIdBLBsv2DN9G/oZHl9d55idicuTUZDG5WZQEupxSxFs8sF3wcKGENz4yW1KCv P6WT8Yzl8spuGcUYhwU1iJXF235QE4NSv+MV11kVJQMl3CLqJkPV78KEbX6wNmPzZA7l H5SAikOGcc8ugQppIztQ+nxmMafA21Xy50xv2OSXU6knX/ejDVtBEl9/YDpoTYwWdfkc bDDQ== MIME-Version: 1.0 X-Received: by 10.60.25.138 with SMTP id c10mr20475386oeg.12.1360090262908; Tue, 05 Feb 2013 10:51:02 -0800 (PST) Received: by 10.60.162.103 with HTTP; Tue, 5 Feb 2013 10:51:02 -0800 (PST) In-Reply-To: <510FCD99.3000300@ieca.com> References: <50F2F075.8090809@cs.tcd.ie> <51068A27.1050601@ieca.com> <51069692.20706@cs.tcd.ie> <510FCD99.3000300@ieca.com> Date: Tue, 5 Feb 2013 18:51:02 +0000 Message-ID: From: Cameron Jones To: Sean Turner Content-Type: multipart/alternative; boundary=e89a8ff1c2fcfbaefb04d4feb0c6 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] charter rev -03 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 18:51:04 -0000 --e89a8ff1c2fcfbaefb04d4feb0c6 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Feb 4, 2013 at 3:02 PM, Sean Turner wrote: > On 1/28/13 10:17 AM, Stephen Farrell wrote: > >> >> >> On 01/28/2013 02:24 PM, Sean Turner wrote: >> >>> Right so the plan here is to put this on the BOF list with the hope that >>> a WG will get formed before IETF 86. Obviously this plan is predicated >>> on more expressions of support for the proposed charter. >>> >> >> As a draft author, I think forming a wg with this charter >> would be good. (As an IESG member, I'll be recusing myself >> from IESG balloting on this.) >> > > Just to be clear, it's time to speak up if you support the idea of forming > a WG because silence means we shelve the idea. > > spt > +1 Thanks, Cameron Jones --e89a8ff1c2fcfbaefb04d4feb0c6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Feb 4, 2013 at 3:02 PM, Sean Turner <tur= ners@ieca.com> wrote:
On 1/28/13 10:17 AM, Stephen Farrell wrote:


On 01/28/2013 02:24 PM, Sean Turner wrote:
Right so the plan here is to put this on the BOF list with the hope that a WG will get formed before IETF 86. =A0Obviously this plan is predicated on more expressions of support for the proposed charter.

As a draft author, I think forming a wg with this charter
would be good. (As an IESG member, I'll be recusing myself
from IESG balloting on this.)

Just to be clear, it's time to speak up if you support the idea of form= ing a WG because silence means we shelve the idea.

spt

+1

Thanks,
Cameron Jones
<= /div> --e89a8ff1c2fcfbaefb04d4feb0c6-- From fenton@bluepopcorn.net Tue Feb 5 10:51:33 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62D6421F853D for ; Tue, 5 Feb 2013 10:51:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2zyqwOryFYo for ; Tue, 5 Feb 2013 10:51:32 -0800 (PST) Received: from kernel.bluepopcorn.net (ipv6.bluepopcorn.net [IPv6:2001:470:1f05:bfe:21a:70ff:fe11:c889]) by ietfa.amsl.com (Postfix) with ESMTP id AB4B421F8552 for ; Tue, 5 Feb 2013 10:51:32 -0800 (PST) Received: from splunge.local ([96.8.44.21]) (authenticated bits=0) by kernel.bluepopcorn.net (8.14.5/8.14.4) with ESMTP id r15IpUZe017247 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 5 Feb 2013 10:51:32 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=buttered; t=1360090292; bh=hfbwWAnY0EKIWjybXT7ySK5mnyeSTQk94fzZi+Oq4ro=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Mvpl8QMpUx0GXCBE5rTtMZU46D/J+e07GR83m/zy8VNN7DFuT3ecJWYw4ziwIOxxB vPlQmvONPZe5tqbs5nRnVg9cJc30IPArSXVgOQCHjDHXOrH2VIOW/Ql3TJZsz/h Message-ID: <511154B3.9070706@bluepopcorn.net> Date: Tue, 05 Feb 2013 10:51:31 -0800 From: Jim Fenton User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: http-auth@ietf.org References: <50F2F075.8090809@cs.tcd.ie> <51068A27.1050601@ieca.com> <51069692.20706@cs.tcd.ie> <510FCD99.3000300@ieca.com> In-Reply-To: <510FCD99.3000300@ieca.com> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [http-auth] charter rev -03 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 18:51:33 -0000 On 2/4/13 7:02 AM, Sean Turner wrote: > > Just to be clear, it's time to speak up if you support the idea of > forming a WG because silence means we shelve the idea. Unfortunately, given the scope limitations of this charter (in particular, the exclusion of mechanisms that aren't tied directly to HTTP), I can't support formation of a WG. Which is not to say that I oppose it, but rather that I can't justify the time to participate in it. One thing I don't see in the charter is a rationale for why HTTP authentication should be preferred over the pervasive "web" authentication currently being done. If there are better HTTP authentication schemes (and I agree, the current selection of schemes is very limited), will HTTP authentication be widely deployed? -Jim From hallam@gmail.com Tue Feb 5 11:28:19 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C43221F8746 for ; Tue, 5 Feb 2013 11:28:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 y3eiqzw1NoO3 for ; Tue, 5 Feb 2013 11:28:18 -0800 (PST) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 1A51521F8697 for ; Tue, 5 Feb 2013 11:28:17 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id 12so4379414wgh.1 for ; Tue, 05 Feb 2013 11:28:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=qldrd2I77a8NB/2fIIuY5mSnbyGO8LQnUJvIUCc2swY=; b=dMKlTJ4SB8/Qwse4FDT3V0ZC2fdeYETbMgScE1ME20sawzl/FMEM4byjg9UkJsNc6m fVq4Uftss7vjWH0qrPBi/XOZBwhAoYlo8g/Jk8UMzkun3xlCudUO/9hNQ6SYh8u+Z25f pDN+3UftfU1PTotDRjiGd22mUEj4OhAL9uFeHBPp0N8zM64yXCILiPqSneY+lDEwO5p7 Uzaevr6hZamVEaEyvbw8xw0/7qGEX7lahzxyw4r6WIZYioHkKI+469xVuV/4tG4DOGR9 DHoLzpshH14ari+BI1Fo/VqQI7Ix9TSG6xFyEzLBAW0uzL/Y5+DpD/0mtpuSkvr2Na/l rEtA== MIME-Version: 1.0 X-Received: by 10.194.58.175 with SMTP id s15mr44805912wjq.31.1360092496995; Tue, 05 Feb 2013 11:28:16 -0800 (PST) Received: by 10.194.85.196 with HTTP; Tue, 5 Feb 2013 11:28:16 -0800 (PST) In-Reply-To: <51113907.3010503@cs.tcd.ie> References: <50F2F075.8090809@cs.tcd.ie> <51113907.3010503@cs.tcd.ie> Date: Tue, 5 Feb 2013 14:28:16 -0500 Message-ID: From: Phillip Hallam-Baker To: Stephen Farrell Content-Type: multipart/alternative; boundary=047d7ba9792425263c04d4ff362e Cc: "http-auth@ietf.org" Subject: Re: [http-auth] charter rev -03 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 19:28:19 -0000 --047d7ba9792425263c04d4ff362e Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 5, 2013 at 11:53 AM, Stephen Farrell wrote: > > Hi Phill, > > Actually I think we're all really agreeing about what's > doable and what's not, even you and Paul:-) > That is my understanding to. What I objected to was Paul's assertion that raising that set of concerns was inappropriate. > Nobody here (afaik) thinks we're gonna get browsers to > immediately adopt any lovely new fangled experimental stuff > that's proposed. If non-browsers do adopt then that's > great and we'll see where it goes. > I don't think we will get the browsers to lend their weight to make the proposal a success. But I think they are quite likely to get involved if they get the idea that a proposal might be a success without their participation and eventually require them to implement a standard that is not ideally suited to browser needs. I don't think we can or should try to replace Web authentication schemes (OpenID, SAML, OAuth). But we can and should provide capabilities that would allow those schemes to be simpler and work better. As currently written the charter looks to me like it is proposing to start a group that will try to work on its own in a vacuum rather than something that could be built on by other groups. If there are charter text changes that you want to > suggest then please do so, but I think the -03 version > captures the above already. > I would like the charter to better define the part of the authentication process it is going to support. Simply saying 'authentication' does not tell me which problems are in scope and which are not. Digest Authentication actually has three parts: 1) Credential issue - user and service agree a symmetric key. This is performed out of band. 2) Credential negotiation - user attempts to connect to the service, is told authentication is required 3) Session continuation - authenticated messages are exchanged. In my view as an author, the spec is defective in the following ways: A) There is no provision for using public key cryptography which was encumbered at the time the design was first proposed. B) There is no provision for binding to TLS or other channel authentication C) The negotiation mechanism and message authentication mechanism are conflated in a confused way. This makes using the mechanism to authenticate server responses unattractive. D) Every existing implementation is vulnerable to a downgrade attack. Z) The cryptographic algorithm used (PHB-MAC-MD5) is rather unfashionable And of course, if Sean decides to take this further then > there'll be more opportunities to comment and propose > changes as the charter is reviewed. > -- Website: http://hallambaker.com/ --047d7ba9792425263c04d4ff362e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Feb 5, 2013 at 11:53 AM, Stephen= Farrell <stephen.farrell@cs.tcd.ie> wrote:

Hi Phill,

Actually I think we're all really agreeing about what's
doable and what's not, even you and Paul:-)

That is my understanding to.

What I objec= ted to was Paul's assertion that raising that set of concerns was inapp= ropriate.=A0



=A0
Nobody here (afaik) thinks we're gonna get browsers to
immediately adopt any lovely new fangled experimental stuff
that's proposed. If non-browsers do adopt then that's
great and we'll see where it goes.

= I don't think we will get the browsers to lend their weight to make the= proposal a success. But I think they are quite likely to get involved if t= hey get the idea that a proposal might be a success without their participa= tion and eventually require them to implement a standard that is not ideall= y suited to browser needs.

I don't think we can or should try to replace Web a= uthentication schemes (OpenID, SAML, OAuth). But we can and should provide = capabilities that would allow those schemes to be simpler and work better. = As currently written the charter looks to me like it is proposing to start = a group that will try to work on its own in a vacuum rather than something = that could be built on by other groups.=A0


If there are charter text changes that you want to
suggest then please do so, but I think the -03 version
captures the above already.

I would lik= e the charter to better define the part of the authentication process it is= going to support. Simply saying 'authentication' does not tell me = which problems are in scope and which are not.

Digest Authentication actually has three parts:

1) Credential issue - user and service agree a symmetric = key. This is performed out of band.

2) Credential = negotiation - user attempts to connect to the service, is told authenticati= on is required

3) Session continuation - authenticated messages are ex= changed.

=A0
In my view as an author, th= e spec is defective in the following ways:

A) Ther= e is no provision for using public key cryptography which was encumbered at= the time the design was first proposed.

B) There is no provision for binding to TLS or other ch= annel authentication

C) The negotiation mechanism = and message authentication mechanism are conflated in a confused way. This = makes using the mechanism to authenticate server responses unattractive.

D) Every existing implementation is vulnerable to a dow= ngrade attack.

Z) The cryptographic algorithm used= (PHB-MAC-MD5) is rather unfashionable

And of course, if Sean decides to take this further then
there'll be more opportunities to comment and propose
changes as the charter is reviewed.

=A0=
--
Website: http://hall= ambaker.com/
--047d7ba9792425263c04d4ff362e-- From mnot@mnot.net Tue Feb 5 12:37:20 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4774021F8534 for ; Tue, 5 Feb 2013 12:37:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.639 X-Spam-Level: X-Spam-Status: No, score=-105.639 tagged_above=-999 required=5 tests=[AWL=-3.040, 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 g1AP9WBCHO4I for ; Tue, 5 Feb 2013 12:37:19 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 333C921F8480 for ; Tue, 5 Feb 2013 12:37:19 -0800 (PST) Received: from [192.168.1.80] (unknown [118.209.138.158]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E68C822E1F4; Tue, 5 Feb 2013 15:37:02 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Mark Nottingham In-Reply-To: <51112B1C.7040201@gmx.de> Date: Wed, 6 Feb 2013 07:36:58 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <34748E83-144D-43B3-9645-15E920B03A61@mnot.net> References: <50F2F075.8090809@cs.tcd.ie> <51068A27.1050601@ieca.com> <51069692.20706@cs.tcd.ie> <510FCD99.3000300@ieca.com> <4613980CFC78314ABFD7F85CC30277211199C31F@IL-EX10.ad.checkpoint.com> <51111C99.5070906@w3.org> <51112B1C.7040201@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1499) Cc: http-auth@ietf.org Subject: Re: [http-auth] Anyone on mailing list working for browser vendor [was Re: charter rev -03] X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 20:37:20 -0000 On 06/02/2013, at 2:54 AM, Julian Reschke wrote: > Hmm. The charter contains: >=20 >> In addition, the WG will aim to get rough consensus on two drafts = that >> will obsolete the basic and digest schemes defined in RFC 2617 taking >> into account errata on that specification. >>=20 >> For the digest scheme, "more modern" algorithm agility and >> internationalisation support will be developed as a standards-track >> RFC. The starting point for this will be >> draft-ahrens-httpbis-digest-auth-update, but the WG is not precluded >> from e.g. adding a Diffie-Hellman exchange to this method. >>=20 >> For the basic scheme, no technical changes are envisaged other than = to >> handle i18n of usernames and passwords, the goal will simply be to >> improve the documentation of the scheme to allow obsoleting RFC 2617 >> which has some significant flaws when looked back at 13 years later. >=20 > It should be our goal to get at least these implemented in browsers. +1. Having the conversation dominated by experimental schemes that the = browsers aren't interested in is also going to make this discussion = harder for them to participate in. OTOH, two major browsers are Open Source projects; has anyone committed = to keeping patches for them up-to-date, at least?=20 -- Mark Nottingham http://www.mnot.net/ From ynir@checkpoint.com Tue Feb 5 12:56:45 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2F1C21F8684 for ; Tue, 5 Feb 2013 12:56:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.549 X-Spam-Level: X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 27Nvbm17uay1 for ; Tue, 5 Feb 2013 12:56:42 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 3FCB421F8464 for ; Tue, 5 Feb 2013 12:56:37 -0800 (PST) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r15KuWEu001350; Tue, 5 Feb 2013 22:56:32 +0200 X-CheckPoint: {51116E51-3-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.18]) by DAG-EX10.ad.checkpoint.com ([169.254.3.103]) with mapi id 14.02.0328.009; Tue, 5 Feb 2013 22:56:32 +0200 From: Yoav Nir To: Mark Nottingham Thread-Topic: [http-auth] Anyone on mailing list working for browser vendor [was Re: charter rev -03] Thread-Index: AQHOA+CiecJVDN1LyUSlxmaoeVCRJZhrnT4A Date: Tue, 5 Feb 2013 20:56:31 +0000 Message-ID: <4613980CFC78314ABFD7F85CC30277211199CB1A@IL-EX10.ad.checkpoint.com> References: <50F2F075.8090809@cs.tcd.ie> <51068A27.1050601@ieca.com> <51069692.20706@cs.tcd.ie> <510FCD99.3000300@ieca.com> <4613980CFC78314ABFD7F85CC30277211199C31F@IL-EX10.ad.checkpoint.com> <51111C99.5070906@w3.org> <51112B1C.7040201@gmx.de> <34748E83-144D-43B3-9645-15E920B03A61@mnot.net> In-Reply-To: <34748E83-144D-43B3-9645-15E920B03A61@mnot.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.252] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: <8D57C8CB8B35704F8DA48A24E215A852@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Julian Reschke , "" Subject: Re: [http-auth] Anyone on mailing list working for browser vendor [was Re: charter rev -03] X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 20:56:46 -0000 On Feb 5, 2013, at 10:36 PM, Mark Nottingham wrote: >=20 > On 06/02/2013, at 2:54 AM, Julian Reschke wrote: >=20 >> Hmm. The charter contains: >>=20 >>> In addition, the WG will aim to get rough consensus on two drafts that >>> will obsolete the basic and digest schemes defined in RFC 2617 taking >>> into account errata on that specification. >>>=20 >>> For the digest scheme, "more modern" algorithm agility and >>> internationalisation support will be developed as a standards-track >>> RFC. The starting point for this will be >>> draft-ahrens-httpbis-digest-auth-update, but the WG is not precluded >>> from e.g. adding a Diffie-Hellman exchange to this method. >>>=20 >>> For the basic scheme, no technical changes are envisaged other than to >>> handle i18n of usernames and passwords, the goal will simply be to >>> improve the documentation of the scheme to allow obsoleting RFC 2617 >>> which has some significant flaws when looked back at 13 years later. >>=20 >> It should be our goal to get at least these implemented in browsers. >=20 > +1. >=20 > Having the conversation dominated by experimental schemes that the browse= rs aren't interested in is also going to make this discussion harder for th= em to participate in. >=20 > OTOH, two major browsers are Open Source projects; has anyone committed t= o keeping patches for them up-to-date, at least?=20 AFAIK, out of the proposals that we've heard in Atlanta, only one (mutualAu= th) has been implemented in a browser, and that was a patch over Firefox 3.= 5 (current version is 18) Yoav= From mnot@mnot.net Tue Feb 5 13:07:01 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1676221F8609 for ; Tue, 5 Feb 2013 13:07:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.541 X-Spam-Level: X-Spam-Status: No, score=-105.541 tagged_above=-999 required=5 tests=[AWL=-2.942, 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 6qDid5ujCQVU for ; Tue, 5 Feb 2013 13:07:00 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 53AF321F85BB for ; Tue, 5 Feb 2013 13:07:00 -0800 (PST) Received: from [192.168.1.80] (unknown [118.209.138.158]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id B81D422E1F4; Tue, 5 Feb 2013 16:06:58 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Mark Nottingham In-Reply-To: <4613980CFC78314ABFD7F85CC30277211199CB1A@IL-EX10.ad.checkpoint.com> Date: Wed, 6 Feb 2013 08:06:54 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50F2F075.8090809@cs.tcd.ie> <51068A27.1050601@ieca.com> <51069692.20706@cs.tcd.ie> <510FCD99.3000300@ieca.com> <4613980CFC78314ABFD7F85CC30277211199C31F@IL-EX10.ad.checkpoint.com> <51111C99.5070906@w3.org> <51112B1C.7040201@gmx.de> <34748E83-144D-43B3-9645-15E920B03A61@mnot.net> <4613980CFC78314ABFD7F85CC30277211199CB1A@IL-EX10.ad.checkpoint.com> To: Yoav Nir X-Mailer: Apple Mail (2.1499) Cc: Julian Reschke , "" Subject: Re: [http-auth] Anyone on mailing list working for browser vendor [was Re: charter rev -03] X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 21:07:01 -0000 On 06/02/2013, at 7:56 AM, Yoav Nir wrote: >>=20 >> +1. >>=20 >> Having the conversation dominated by experimental schemes that the = browsers aren't interested in is also going to make this discussion = harder for them to participate in. >>=20 >> OTOH, two major browsers are Open Source projects; has anyone = committed to keeping patches for them up-to-date, at least?=20 >=20 > AFAIK, out of the proposals that we've heard in Atlanta, only one = (mutualAuth) has been implemented in a browser, and that was a patch = over Firefox 3.5 (current version is 18) I meant the basic / digest revisions specifically. I.e., if we're going = to replace 2617's schemes, the replacements should have at least SOME = connection to implementation. -- Mark Nottingham http://www.mnot.net/ From julian.reschke@gmx.de Tue Feb 5 13:19:20 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 221E021F86C4 for ; Tue, 5 Feb 2013 13:19:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-4.000, 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 b4oEZvyniLwt for ; Tue, 5 Feb 2013 13:19:19 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id CE88F21F86B0 for ; Tue, 5 Feb 2013 13:19:18 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.1]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0Mb5SX-1UMqY21eJP-00KdNk for ; Tue, 05 Feb 2013 22:19:17 +0100 Received: (qmail invoked by alias); 05 Feb 2013 21:19:17 -0000 Received: from p54BB304F.dip.t-dialin.net (EHLO [192.168.1.102]) [84.187.48.79] by mail.gmx.net (mp001) with SMTP; 05 Feb 2013 22:19:17 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+AZJ54+PKAkNIgmv1rQ6WfCgdk5b0cbcSuBwqccw vb4303rn3lKM2x Message-ID: <51117753.3000206@gmx.de> Date: Tue, 05 Feb 2013 22:19:15 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Mark Nottingham References: <50F2F075.8090809@cs.tcd.ie> <51068A27.1050601@ieca.com> <51069692.20706@cs.tcd.ie> <510FCD99.3000300@ieca.com> <4613980CFC78314ABFD7F85CC30277211199C31F@IL-EX10.ad.checkpoint.com> <51111C99.5070906@w3.org> <51112B1C.7040201@gmx.de> <34748E83-144D-43B3-9645-15E920B03A61@mnot.net> <4613980CFC78314ABFD7F85CC30277211199CB1A@IL-EX10.ad.checkpoint.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "" Subject: Re: [http-auth] Anyone on mailing list working for browser vendor [was Re: charter rev -03] X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 21:19:20 -0000 On 2013-02-05 22:06, Mark Nottingham wrote: > > On 06/02/2013, at 7:56 AM, Yoav Nir wrote: >>> >>> +1. >>> >>> Having the conversation dominated by experimental schemes that the browsers aren't interested in is also going to make this discussion harder for them to participate in. >>> >>> OTOH, two major browsers are Open Source projects; has anyone committed to keeping patches for them up-to-date, at least? >> >> AFAIK, out of the proposals that we've heard in Atlanta, only one (mutualAuth) has been implemented in a browser, and that was a patch over Firefox 3.5 (current version is 18) > > > I meant the basic / digest revisions specifically. I.e., if we're going to replace 2617's schemes, the replacements should have at least SOME connection to implementation. I was planning to implement draft-reschke-basicauth-enc in Mozilla, but that requires writing a sane WWW-A header field parser first. See test cases at . Best regards, Julian From stephen.farrell@cs.tcd.ie Tue Feb 5 14:27:09 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAE1521F85EE for ; Tue, 5 Feb 2013 14:27:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 0I5GWTdDGdtf for ; Tue, 5 Feb 2013 14:27:09 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC4421F85D2 for ; Tue, 5 Feb 2013 14:27:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id ADD91BE38; Tue, 5 Feb 2013 22:26:47 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6taVGs8GAZs; Tue, 5 Feb 2013 22:26:46 +0000 (GMT) Received: from [10.87.48.11] (unknown [86.41.62.183]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C6FADBE35; Tue, 5 Feb 2013 22:26:46 +0000 (GMT) Message-ID: <51118726.6020506@cs.tcd.ie> Date: Tue, 05 Feb 2013 22:26:46 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Cameron Jones References: <50F2F075.8090809@cs.tcd.ie> <51068A27.1050601@ieca.com> <51069692.20706@cs.tcd.ie> <510FCD99.3000300@ieca.com> <4613980CFC78314ABFD7F85CC30277211199C31F@IL-EX10.ad.checkpoint.com> <51111C99.5070906@w3.org> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Anyone on mailing list working for browser vendor [was Re: charter rev -03] X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 22:27:10 -0000 Hi Cameron, On 02/05/2013 06:40 PM, Cameron Jones wrote: > I think largely what is in demand, based on other input to the HTML group, > is a SRP-style protocol to protect against server password leaks. I don't think that works quite as you stated above. Passwords leak from databases or keyboards and not via sniffing in afaik pretty much all cases and strong password protocols still have dictionary attackable password verifier databases. There may still be good reasons to use a strong password protocol like SRP or EKE or whatever of course and I've nothing against 'em, (some are really elegant), but we'd want to be clear about what problems they do and don't address. But that's getting ahead of ourselves probably. S. From kazubu.lepidum@gmail.com Wed Feb 6 04:28:47 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 540B721F87CC for ; Wed, 6 Feb 2013 04:28:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NpQBZnFexz0f for ; Wed, 6 Feb 2013 04:28:46 -0800 (PST) Received: from mail-vc0-f181.google.com (mail-vc0-f181.google.com [209.85.220.181]) by ietfa.amsl.com (Postfix) with ESMTP id B940821F86F2 for ; Wed, 6 Feb 2013 04:28:46 -0800 (PST) Received: by mail-vc0-f181.google.com with SMTP id d16so792965vcd.40 for ; Wed, 06 Feb 2013 04:28:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=F0vQ42JvnogJqJ0FJAJLM2GDfHFv/WVI+U1TUawQ6E4=; b=gvN4KXNrx9ZpOt4sW6ELeGvN4kgT4RBWNLDgNfUZN1vPkuVMNhizumHop9TjDHZGhO tOML4ipJix8PKxrluZ2wi6rSCoJ7MbThxw50H57JleBfamiaWzNMX1Py0CoFnGR1hB6s SiWmEF9n5NpdzndzNreXCZ65MAKwJVB0yiQoytY+HmBmk+9mB6tKuWjeeYWRTLVjjtTZ l10gL7sNHZkQWzeK/JBl2mu4XV51cg2t6VVLh4Y+VO6gUIKIgGf0er/hs9Hh7Jpua890 GccIX2tVSXG/BSB80TDRZ6Bt4R/ccH/sXLc6haY7P6iHaMM6DBsci4L0+IJ3s6nkL0Zv 2t8Q== X-Received: by 10.220.154.199 with SMTP id p7mr31892166vcw.48.1360153726260; Wed, 06 Feb 2013 04:28:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.178.200 with HTTP; Wed, 6 Feb 2013 04:28:26 -0800 (PST) In-Reply-To: <510FCD99.3000300@ieca.com> References: <50F2F075.8090809@cs.tcd.ie> <51068A27.1050601@ieca.com> <51069692.20706@cs.tcd.ie> <510FCD99.3000300@ieca.com> From: "SHIMIZU, Kazuki" Date: Wed, 6 Feb 2013 21:28:26 +0900 Message-ID: To: Sean Turner Content-Type: text/plain; charset=ISO-8859-1 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] charter rev -03 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 12:28:47 -0000 > Just to be clear, it's time to speak up if you support the idea of forming a > WG because silence means we shelve the idea. +1 2013/2/5 Sean Turner : > On 1/28/13 10:17 AM, Stephen Farrell wrote: >> >> >> >> On 01/28/2013 02:24 PM, Sean Turner wrote: >>> >>> Right so the plan here is to put this on the BOF list with the hope that >>> a WG will get formed before IETF 86. Obviously this plan is predicated >>> on more expressions of support for the proposed charter. >> >> >> As a draft author, I think forming a wg with this charter >> would be good. (As an IESG member, I'll be recusing myself >> from IESG balloting on this.) > > > Just to be clear, it's time to speak up if you support the idea of forming a > WG because silence means we shelve the idea. > > spt > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth -- -- SHIMIZU, Kazuki From cmhjones@gmail.com Wed Feb 6 05:18:22 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC3EE21F8715 for ; Wed, 6 Feb 2013 05:18:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.348 X-Spam-Level: X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[AWL=1.250, 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 C8-pdWKn4qkR for ; Wed, 6 Feb 2013 05:18:22 -0800 (PST) Received: from mail-oa0-f51.google.com (mail-oa0-f51.google.com [209.85.219.51]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3E421F86E6 for ; Wed, 6 Feb 2013 05:18:22 -0800 (PST) Received: by mail-oa0-f51.google.com with SMTP id h2so1443247oag.24 for ; Wed, 06 Feb 2013 05:18:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=QsJrhgdh35BggfxcvQqPEt7WNng56KrsxVscWuNTpow=; b=QwmA9GtIMd54vqd2AiGnM0v3/qTrgjnkdRaL7nIva5CQLbX2FpiOfbX22iIRND7mFs KyVSc2poddreONSZ7MpgXE2fFokMv2cDx8M1rie6GNcsBa1ywii5T2koHboz0X0H7+8V YogzNc/6h4lT6vfL2awLnfYXrCrGCOs8uxgXWw12gvpKfE1kpBc/5WgNIN84Z/m8LhRl rCq/uGiEFBGLZbghKiKP9TqSPzPvFOWKRSqIUlJuC+S8gpV9KliQLki/mMVlw7mJmwc/ n36I9QJLczCJ8HzTGHDLQcmVGo/SoGs9FZdQw3H7ZvMRkY1TdyjpOHnIJ7gjzS6XXbX8 +8Ew== MIME-Version: 1.0 X-Received: by 10.182.23.101 with SMTP id l5mr20952254obf.16.1360156701771; Wed, 06 Feb 2013 05:18:21 -0800 (PST) Received: by 10.60.162.103 with HTTP; Wed, 6 Feb 2013 05:18:21 -0800 (PST) In-Reply-To: <51118726.6020506@cs.tcd.ie> References: <50F2F075.8090809@cs.tcd.ie> <51068A27.1050601@ieca.com> <51069692.20706@cs.tcd.ie> <510FCD99.3000300@ieca.com> <4613980CFC78314ABFD7F85CC30277211199C31F@IL-EX10.ad.checkpoint.com> <51111C99.5070906@w3.org> <51118726.6020506@cs.tcd.ie> Date: Wed, 6 Feb 2013 13:18:21 +0000 Message-ID: From: Cameron Jones To: Stephen Farrell Content-Type: multipart/alternative; boundary=f46d043749e10c47ec04d50e2924 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Anyone on mailing list working for browser vendor [was Re: charter rev -03] X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 13:18:23 -0000 --f46d043749e10c47ec04d50e2924 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 5, 2013 at 10:26 PM, Stephen Farrell wrote: > > Hi Cameron, > > On 02/05/2013 06:40 PM, Cameron Jones wrote: > > I think largely what is in demand, based on other input to the HTML > group, > > is a SRP-style protocol to protect against server password leaks. > > I don't think that works quite as you stated above. > > Passwords leak from databases or keyboards and not via sniffing in > afaik pretty much all cases and strong password protocols still > have dictionary attackable password verifier databases. > > There may still be good reasons to use a strong password protocol > like SRP or EKE or whatever of course and I've nothing against > 'em, (some are really elegant), but we'd want to be clear about > what problems they do and don't address. > > But that's getting ahead of ourselves probably. > > S. > > Hey Stephen, Yes, I wasn't trying to overstate a demand for SRP or other zero-knowledge password protocols above all else, more that there was a vocal demand for such. The requests were triggered by the various unsalted password database leaks\hack & grabs last year. Personally i too find the mechanism elegant and potentially highly valuable for some scenarios, but the migration for existing password-knowledgable systems seems to be a significant hurdle in achieving that utopian ideal. Thanks, Cameron Jones --f46d043749e10c47ec04d50e2924 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Feb 5, 2013 at 10:26 PM, Stephen Farrell= <stephen.farrell@cs.tcd.ie> wrote:

Hi Cameron,

On 02/05/2013 06:40 PM, Cameron Jones wrote:
> I think largely what is in demand, based on other input to the HTML gr= oup,
> is a SRP-style protocol to protect against server password leaks.

I don't think that works quite as you stated above.

Passwords leak from databases or keyboards and not via sniffing in
afaik pretty much all cases and strong password protocols still
have dictionary attackable password verifier databases.

There may still be good reasons to use a strong password protocol
like SRP or EKE or whatever of course and I've nothing against
'em, (some are really elegant), but we'd want to be clear about
what problems they do and don't address.

But that's getting ahead of ourselves probably.

S.


Hey Stephen,

Yes, I wasn't = trying to overstate a demand for SRP or other zero-knowledge password proto= cols above all else, more that there was a vocal demand for such. The reque= sts were triggered by the various unsalted password database leaks\hack &am= p; grabs last year.

Personally i too find the mechanism elegant and potentially highly valu= able for some scenarios, but the migration for existing password-knowledgab= le systems seems to be a significant hurdle in achieving that utopian ideal= .

Thanks,
Cameron Jones
--f46d043749e10c47ec04d50e2924-- From davidahrens@avaya.com Wed Feb 6 07:38:15 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D88A121F8589 for ; Wed, 6 Feb 2013 07:38:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5rXXzChEKmwH for ; Wed, 6 Feb 2013 07:38:12 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 737AE21F853E for ; Wed, 6 Feb 2013 07:38:12 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAJoQA1GHCzI1/2dsb2JhbABFgmu7ZxZzgh4BAQEBAgEBAQEPKDQQBwQCAQgNBAQBAQEKFAkHJwsUCQgCBBMIGodnBgELoViccASQXmEDnBqKO4J3giQ X-IronPort-AV: E=Sophos;i="4.84,541,1355115600"; d="scan'208";a="387660471" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 06 Feb 2013 10:37:32 -0500 Received: from unknown (HELO AZ-US1EXHC02.global.avaya.com) ([135.11.85.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 06 Feb 2013 10:37:44 -0500 Received: from AZ-US1EXMB02.global.avaya.com ([fe80::c01d:740:c927:8888]) by AZ-US1EXHC02.global.avaya.com ([::1]) with mapi id 14.02.0328.009; Wed, 6 Feb 2013 10:38:11 -0500 From: "Ahrens, David (David)" To: "http-auth@ietf.org" Thread-Topic: [http-auth] charter rev -03 Thread-Index: AQHOBGWUyB6sG4KCokqJs4LXwW8pL5hs9x4A Date: Wed, 6 Feb 2013 15:38:31 +0000 Message-ID: <5C4BC9217963F14D817A8ED51DB74B8007AFCE@AZ-US1EXMB02.global.avaya.com> References: <50F2F075.8090809@cs.tcd.ie> <51068A27.1050601@ieca.com> <51069692.20706@cs.tcd.ie> <510FCD99.3000300@ieca.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.47] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [http-auth] charter rev -03 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 15:38:16 -0000 +1 -----Original Message----- From: http-auth-bounces@ietf.org [mailto:http-auth-bounces@ietf.org] On Beh= alf Of SHIMIZU, Kazuki Sent: Wednesday, February 06, 2013 4:28 AM To: Sean Turner Cc: http-auth@ietf.org Subject: Re: [http-auth] charter rev -03 > Just to be clear, it's time to speak up if you support the idea of=20 > forming a WG because silence means we shelve the idea. +1 2013/2/5 Sean Turner : > On 1/28/13 10:17 AM, Stephen Farrell wrote: >> >> >> >> On 01/28/2013 02:24 PM, Sean Turner wrote: >>> >>> Right so the plan here is to put this on the BOF list with the hope=20 >>> that a WG will get formed before IETF 86. Obviously this plan is=20 >>> predicated on more expressions of support for the proposed charter. >> >> >> As a draft author, I think forming a wg with this charter would be=20 >> good. (As an IESG member, I'll be recusing myself from IESG balloting=20 >> on this.) > > > Just to be clear, it's time to speak up if you support the idea of=20 > forming a WG because silence means we shelve the idea. > > spt > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth -- -- SHIMIZU, Kazuki _______________________________________________ http-auth mailing list http-auth@ietf.org https://www.ietf.org/mailman/listinfo/http-auth From cmhjones@gmail.com Wed Feb 6 08:42:58 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C485721F8A55 for ; Wed, 6 Feb 2013 08:42:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.765 X-Spam-Level: X-Spam-Status: No, score=-2.765 tagged_above=-999 required=5 tests=[AWL=0.833, 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 D3AoFlT0LfND for ; Wed, 6 Feb 2013 08:42:58 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 380A421F8A56 for ; Wed, 6 Feb 2013 08:42:57 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id h1so1725711oag.3 for ; Wed, 06 Feb 2013 08:42:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=IouJy2VdWmw9J34jZiB1jSxbg+kNn3Oxd6bj4xjZxIk=; b=nK7eA+sS2jK0InD+X1td2ozX8+WtyUHzFioT+NzKkdPtlHqdPFxBbwWqOkSKRjBFTl LHswTFPpobZdYTafIpnWPsFVEPJk7PzLF21vvlyNihtAAJitkM0Ibyehq4EqNkX4PIvo ifCprW+lbJfGhef3tgvveLNgNMudDV3uPDptHWjbvcigQ9C62G859sclQhT86+Q/kdGK RVTZnb/+OJjhf01/3/vyqXfgXDC+/tzH94E2Q60E4XYCFOZ1ZCAc/7hNLVnswZJEhro5 BjZcMW5bYP+6LjdlDJXyRQYhMFgEUo17Qmlhe9wot6w2HDYnvlksijxNZBYWGbjZ/a9Z 498Q== MIME-Version: 1.0 X-Received: by 10.182.38.69 with SMTP id e5mr21836113obk.79.1360168976762; Wed, 06 Feb 2013 08:42:56 -0800 (PST) Received: by 10.60.162.103 with HTTP; Wed, 6 Feb 2013 08:42:56 -0800 (PST) Date: Wed, 6 Feb 2013 16:42:56 +0000 Message-ID: From: Cameron Jones To: Stephen Farrell Content-Type: multipart/alternative; boundary=f46d04462f0eb1c62e04d5110472 Cc: "http-auth@ietf.org" Subject: [http-auth] Zero-Knowledge Password Proof Migration [was Re: Anyone on mailing list working for browser vendor] X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 16:42:58 -0000 --f46d04462f0eb1c62e04d5110472 Content-Type: text/plain; charset=ISO-8859-1 Branching to new topic. On Wed, Feb 6, 2013 at 1:18 PM, Cameron Jones wrote: > On Tue, Feb 5, 2013 at 10:26 PM, Stephen Farrell < > stephen.farrell@cs.tcd.ie> wrote: > >> >> Hi Cameron, >> >> On 02/05/2013 06:40 PM, Cameron Jones wrote: >> > I think largely what is in demand, based on other input to the HTML >> group, >> > is a SRP-style protocol to protect against server password leaks. >> >> I don't think that works quite as you stated above. >> >> Passwords leak from databases or keyboards and not via sniffing in >> afaik pretty much all cases and strong password protocols still >> have dictionary attackable password verifier databases. >> >> There may still be good reasons to use a strong password protocol >> like SRP or EKE or whatever of course and I've nothing against >> 'em, (some are really elegant), but we'd want to be clear about >> what problems they do and don't address. >> >> But that's getting ahead of ourselves probably. >> >> S. >> >> > Hey Stephen, > > Yes, I wasn't trying to overstate a demand for SRP or other zero-knowledge > password protocols above all else, more that there was a vocal demand for > such. The requests were triggered by the various unsalted password database > leaks\hack & grabs last year. > > Personally i too find the mechanism elegant and potentially highly > valuable for some scenarios, but the migration for existing > password-knowledgable systems seems to be a significant hurdle in achieving > that utopian ideal. > > > With a bit more thinking, and not being a cryptography expert, but would it be possible to employ SRP-style algorithm for the user on the server-side both for password migration and legacy scheme support? So, standard SRP would work as normal, but legacy schemes (such as BASIC), would have raw passwords SRP applied on the server-side for authorization and storage? The benefits to service providers of all this is that they would eliminate their risk from password harvesters since the only useful information they would store would be that which relates to their own service, instead of being a point-of-failure for any email\password combination. SRP, if achievable, would largely eliminate the need for people to have multiple passwords. Thanks, Cameron Jones --f46d04462f0eb1c62e04d5110472 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Branching to new topic.

On Wed, Feb 6, 20= 13 at 1:18 PM, Cameron Jones <cmhjones@gmail.com> wrote:
On Tue, = Feb 5, 2013 at 10:26 PM, Stephen Farrell <stephen.farrell@cs.tcd.i= e> wrote:

Hi Cameron,

On 02/05/2013 06:40 PM, Cameron Jones wrote:
> I think largely what is in demand, based on other input to the HTML gr= oup,
> is a SRP-style protocol to protect against server password leaks.

I don't think that works quite as you stated above.

Passwords leak from databases or keyboards and not via sniffing in
afaik pretty much all cases and strong password protocols still
have dictionary attackable password verifier databases.

There may still be good reasons to use a strong password protocol
like SRP or EKE or whatever of course and I've nothing against
'em, (some are really elegant), but we'd want to be clear about
what problems they do and don't address.

But that's getting ahead of ourselves probably.

S.


Hey Stephen,

Yes, I= wasn't trying to overstate a demand for SRP or other zero-knowledge pa= ssword protocols above all else, more that there was a vocal demand for suc= h. The requests were triggered by the various unsalted password database le= aks\hack & grabs last year.

Personally i too find the mechanism elegant and potentially highly valu= able for some scenarios, but the migration for existing password-knowledgab= le systems seems to be a significant hurdle in achieving that utopian ideal= .




With a bit more thinking, and not being a= cryptography expert, but would it be possible to employ SRP-style algorith= m for the user on the server-side both for password migration and legacy sc= heme support?

So, standard SRP would work as normal, but legacy schemes (such as BASI= C), would have raw passwords SRP applied on the server-side for authorizati= on and storage?

The benefits to service providers of all this is tha= t they would eliminate their risk from password harvesters since the only u= seful information they would store would be that which relates to their own= service, instead of being a point-of-failure for any email\password combin= ation. SRP, if achievable, would largely eliminate the need for people to h= ave multiple passwords.

Thanks,
Cameron Jones

--f46d04462f0eb1c62e04d5110472-- From stpeter@stpeter.im Wed Feb 6 08:46:23 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2692221F8A41 for ; Wed, 6 Feb 2013 08:46:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8CO3Waw1fmf for ; Wed, 6 Feb 2013 08:46:22 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2005021F8A33 for ; Wed, 6 Feb 2013 08:46:22 -0800 (PST) Received: from [10.129.24.123] (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0F48F40564 for ; Wed, 6 Feb 2013 09:53:03 -0700 (MST) Message-ID: <511288DE.80202@stpeter.im> Date: Wed, 06 Feb 2013 09:46:22 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "http-auth@ietf.org" X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [http-auth] administrivia: request for list admins X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 16:46:23 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The admins for this list are me and Alexey Melnikov, a legacy of the days when he and I were area directors. Volunteers for the role of list administator would be appreciated. I'll ping the Security ADs about it, too. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlESiN4ACgkQNL8k5A2w/vz9DgCdF2wQeymlJDtcV9xRfFz/+Riw 77QAoIblnKzyOgJ4zHxAO/20m0tAwxWK =NMV2 -----END PGP SIGNATURE----- From hallam@gmail.com Wed Feb 6 09:05:43 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE3621F85CC for ; Wed, 6 Feb 2013 09:05:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.637 X-Spam-Level: X-Spam-Status: No, score=-6.637 tagged_above=-999 required=5 tests=[AWL=-3.039, 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 HnQtxr8X3ADx for ; Wed, 6 Feb 2013 09:05:42 -0800 (PST) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) by ietfa.amsl.com (Postfix) with ESMTP id CD87F21F85E2 for ; Wed, 6 Feb 2013 09:05:40 -0800 (PST) Received: by mail-wi0-f177.google.com with SMTP id hm14so1832424wib.10 for ; Wed, 06 Feb 2013 09:05:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=JiC7KxdBa6kZsT00J9R9v4WzAJkJMkr2/8M1kjAbWY0=; b=njYFNmLja7B9cmbMV/Hb5P8BL9pQNCRtnerCkmoU/nat6Ck/3+wEGSQ4ugf50Wu+tF NYRh74iFgZKoG4n9buIHJgedim788B5oaAaRX6tcMMjl7PvKeO9bZuKxVSF6Hs99a/2l O0ihzI2/iaWs91A/8lotRn8x9C1CxbdYWg5q7jYsetu9P38IXGwO96oHOV7FWcPXsOCd BO5OGc5/VrTsJCMVaCBX4VnsEHHvOGlx8a1mXUsFQkXS0mJJ7okKH6eOVxmhLYrfW+Xe MUw/MaaTmWWBdgxYY+8I7g/O8RuupriCh2KSoVYuBqJiU8n0YujjhOSZ03m3srVMRzeU qX7g== MIME-Version: 1.0 X-Received: by 10.180.94.234 with SMTP id df10mr6311374wib.17.1360170337203; Wed, 06 Feb 2013 09:05:37 -0800 (PST) Received: by 10.194.153.104 with HTTP; Wed, 6 Feb 2013 09:05:37 -0800 (PST) In-Reply-To: References: Date: Wed, 6 Feb 2013 12:05:37 -0500 Message-ID: From: Phillip Hallam-Baker To: Cameron Jones Content-Type: multipart/alternative; boundary=f46d0444ea9fc874dd04d511554e Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Zero-Knowledge Password Proof Migration [was Re: Anyone on mailing list working for browser vendor] X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 17:05:43 -0000 --f46d0444ea9fc874dd04d511554e Content-Type: text/plain; charset=ISO-8859-1 On Wed, Feb 6, 2013 at 11:42 AM, Cameron Jones wrote: > Branching to new topic. > > On Wed, Feb 6, 2013 at 1:18 PM, Cameron Jones wrote: > >> On Tue, Feb 5, 2013 at 10:26 PM, Stephen Farrell < >> stephen.farrell@cs.tcd.ie> wrote: >> >>> >>> Hi Cameron, >>> >>> On 02/05/2013 06:40 PM, Cameron Jones wrote: >>> > I think largely what is in demand, based on other input to the HTML >>> group, >>> > is a SRP-style protocol to protect against server password leaks. >>> >>> I don't think that works quite as you stated above. >>> >>> Passwords leak from databases or keyboards and not via sniffing in >>> afaik pretty much all cases and strong password protocols still >>> have dictionary attackable password verifier databases. >>> >>> There may still be good reasons to use a strong password protocol >>> like SRP or EKE or whatever of course and I've nothing against >>> 'em, (some are really elegant), but we'd want to be clear about >>> what problems they do and don't address. >>> >>> But that's getting ahead of ourselves probably. >>> >>> S. >>> >>> >> Hey Stephen, >> >> Yes, I wasn't trying to overstate a demand for SRP or other >> zero-knowledge password protocols above all else, more that there was a >> vocal demand for such. The requests were triggered by the various unsalted >> password database leaks\hack & grabs last year. >> >> Personally i too find the mechanism elegant and potentially highly >> valuable for some scenarios, but the migration for existing >> password-knowledgable systems seems to be a significant hurdle in achieving >> that utopian ideal. >> >> >> > > With a bit more thinking, and not being a cryptography expert, but would > it be possible to employ SRP-style algorithm for the user on the > server-side both for password migration and legacy scheme support? > > So, standard SRP would work as normal, but legacy schemes (such as BASIC), > would have raw passwords SRP applied on the server-side for authorization > and storage? > > The benefits to service providers of all this is that they would eliminate > their risk from password harvesters since the only useful information they > would store would be that which relates to their own service, instead of > being a point-of-failure for any email\password combination. SRP, if > achievable, would largely eliminate the need for people to have multiple > passwords. > > Thanks, > Cameron Jones > The big problem to avoid is the downgrade attack. Digest was originally proposed to replace BASIC. It was a mistake that should never have made it into the spec in my view and it would not have made it into the spec had we actually had a conversation about it first. That didn't happen and so DIGEST only got implemented three years later as a checkbox requirement to get HTTP/1.1 approved. Every implementation presents the same UI dialog for BASIC and DIGESt. This means there is no additional security against a MITM attack as a malicious party can always ask for the password using BASIC and the client has no way to know that it should not sent the password enclair. We should definitely look at the better password exchange schemes like EKE which are not encumbered. That would be a much better approach in my view than trying to patch DIGEST which was designed when DH was still encumbered and is only designed to limit the consequences of stupidity as far as was possible on the equipment of the day rather than eliminate all possible forms of attack. But there is no point in doing that either unless the downgrade attack issue is also dealt with. -- Website: http://hallambaker.com/ --f46d0444ea9fc874dd04d511554e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Feb 6, 2013 at 11:42 AM, Cameron= Jones <cmhjones@gmail.com> wrote:
Branching to new topic.

On Wed, Feb 6, 20= 13 at 1:18 PM, Cameron Jones <cmhjones@gmail.com> wrote:
On Tue, Feb 5, 2013 at 10:26 PM, Steph= en Farrell <stephen.farrell@cs.tcd.ie> wrote:

Hi Cameron,

On 02/05/2013 06:40 PM, Cameron Jones wrote:
> I think largely what is in demand, based on other input to the HTML gr= oup,
> is a SRP-style protocol to protect against server password leaks.

I don't think that works quite as you stated above.

Passwords leak from databases or keyboards and not via sniffing in
afaik pretty much all cases and strong password protocols still
have dictionary attackable password verifier databases.

There may still be good reasons to use a strong password protocol
like SRP or EKE or whatever of course and I've nothing against
'em, (some are really elegant), but we'd want to be clear about
what problems they do and don't address.

But that's getting ahead of ourselves probably.

S.


Hey Stephen,

Yes, I= wasn't trying to overstate a demand for SRP or other zero-knowledge pa= ssword protocols above all else, more that there was a vocal demand for suc= h. The requests were triggered by the various unsalted password database le= aks\hack & grabs last year.

Personally i too find the mechanism elegant and potentially highly valu= able for some scenarios, but the migration for existing password-knowledgab= le systems seems to be a significant hurdle in achieving that utopian ideal= .




With a bit more thinking, and not being a= cryptography expert, but would it be possible to employ SRP-style algorith= m for the user on the server-side both for password migration and legacy sc= heme support?

So, standard SRP would work as normal, but legacy schemes (such as BASI= C), would have raw passwords SRP applied on the server-side for authorizati= on and storage?

The benefits to service providers of all this is tha= t they would eliminate their risk from password harvesters since the only u= seful information they would store would be that which relates to their own= service, instead of being a point-of-failure for any email\password combin= ation. SRP, if achievable, would largely eliminate the need for people to h= ave multiple passwords.

Thanks,
Cameron Jones

Th= e big problem to avoid is the downgrade attack.

Di= gest was originally proposed to replace BASIC. It was a mistake that should= never have made it into the spec in my view and it would not have made it = into the spec had we actually had a conversation about it first.=A0

That didn't happen and so DIGEST only got implement= ed three years later as a checkbox requirement to get HTTP/1.1 approved. Ev= ery implementation presents the same UI dialog for BASIC and DIGESt. This m= eans there is no additional security against a MITM attack as a malicious p= arty can always ask for the password using BASIC and the client has no way = to know that it should not sent the password enclair.


We should definitely look at the better = password exchange schemes like EKE which are not encumbered. That would be = a much better approach in my view than trying to patch DIGEST which was des= igned when DH was still encumbered and is only designed to limit the conseq= uences of stupidity as far as was possible on the equipment of the day rath= er than eliminate all possible forms of attack.

But there is no point in doing that either unless the d= owngrade attack issue is also dealt with.


--
Website: http://halla= mbaker.com/
--f46d0444ea9fc874dd04d511554e-- From davidahrens@avaya.com Wed Feb 6 09:15:25 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B884B21F897A for ; Wed, 6 Feb 2013 09:15:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, 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 n8FjO7EF4Ud4 for ; Wed, 6 Feb 2013 09:15:19 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id A787B21F8639 for ; Wed, 6 Feb 2013 09:15:17 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIGAJoQA1HGmAcF/2dsb2JhbABFgkgjqT+JDQGJGhZzgh4BAQEBAxIbGiQDCxACAQgNBAQBAQEKDgsEByERFAkIAgQBDQUIGodbAw8BoWOOIoRwDYlVjA13Cwt+gkZhA5Q2AYJyhHGFKYUSgneBZwgXHg X-IronPort-AV: E=Sophos;i="4.84,541,1355115600"; d="scan'208,217";a="387679583" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 06 Feb 2013 12:14:35 -0500 Received: from unknown (HELO AZ-US1EXHC01.global.avaya.com) ([135.11.85.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 06 Feb 2013 12:14:07 -0500 Received: from AZ-US1EXMB02.global.avaya.com ([fe80::c01d:740:c927:8888]) by AZ-US1EXHC01.global.avaya.com ([135.11.85.12]) with mapi id 14.02.0328.009; Wed, 6 Feb 2013 12:15:14 -0500 From: "Ahrens, David (David)" To: Phillip Hallam-Baker , Cameron Jones Thread-Topic: [http-auth] Zero-Knowledge Password Proof Migration [was Re: Anyone on mailing list working for browser vendor] Thread-Index: AQHOBImPRfXD9aau0ki9umlusTLMqZhtYxyA//+udLA= Date: Wed, 6 Feb 2013 17:15:34 +0000 Message-ID: <5C4BC9217963F14D817A8ED51DB74B8007B4C7@AZ-US1EXMB02.global.avaya.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.47] Content-Type: multipart/alternative; boundary="_000_5C4BC9217963F14D817A8ED51DB74B8007B4C7AZUS1EXMB02global_" MIME-Version: 1.0 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Zero-Knowledge Password Proof Migration [was Re: Anyone on mailing list working for browser vendor] X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 17:15:25 -0000 --_000_5C4BC9217963F14D817A8ED51DB74B8007B4C7AZUS1EXMB02global_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable SIP (RFC 3261) doesn't allow Basic and only support Digest authentication s= o there's still a requirement for Digest authentication. -David From: http-auth-bounces@ietf.org [mailto:http-auth-bounces@ietf.org] On Beh= alf Of Phillip Hallam-Baker Sent: Wednesday, February 06, 2013 9:06 AM To: Cameron Jones Cc: http-auth@ietf.org Subject: Re: [http-auth] Zero-Knowledge Password Proof Migration [was Re: A= nyone on mailing list working for browser vendor] On Wed, Feb 6, 2013 at 11:42 AM, Cameron Jones > wrote: Branching to new topic. On Wed, Feb 6, 2013 at 1:18 PM, Cameron Jones > wrote: On Tue, Feb 5, 2013 at 10:26 PM, Stephen Farrell > wrote: Hi Cameron, On 02/05/2013 06:40 PM, Cameron Jones wrote: > I think largely what is in demand, based on other input to the HTML group= , > is a SRP-style protocol to protect against server password leaks. I don't think that works quite as you stated above. Passwords leak from databases or keyboards and not via sniffing in afaik pretty much all cases and strong password protocols still have dictionary attackable password verifier databases. There may still be good reasons to use a strong password protocol like SRP or EKE or whatever of course and I've nothing against 'em, (some are really elegant), but we'd want to be clear about what problems they do and don't address. But that's getting ahead of ourselves probably. S. Hey Stephen, Yes, I wasn't trying to overstate a demand for SRP or other zero-knowledge = password protocols above all else, more that there was a vocal demand for s= uch. The requests were triggered by the various unsalted password database = leaks\hack & grabs last year. Personally i too find the mechanism elegant and potentially highly valuable= for some scenarios, but the migration for existing password-knowledgable s= ystems seems to be a significant hurdle in achieving that utopian ideal. With a bit more thinking, and not being a cryptography expert, but would it= be possible to employ SRP-style algorithm for the user on the server-side = both for password migration and legacy scheme support? So, standard SRP would work as normal, but legacy schemes (such as BASIC), = would have raw passwords SRP applied on the server-side for authorization a= nd storage? The benefits to service providers of all this is that they would eliminate = their risk from password harvesters since the only useful information they = would store would be that which relates to their own service, instead of be= ing a point-of-failure for any email\password combination. SRP, if achievab= le, would largely eliminate the need for people to have multiple passwords. Thanks, Cameron Jones The big problem to avoid is the downgrade attack. Digest was originally proposed to replace BASIC. It was a mistake that shou= ld never have made it into the spec in my view and it would not have made i= t into the spec had we actually had a conversation about it first. That didn't happen and so DIGEST only got implemented three years later as = a checkbox requirement to get HTTP/1.1 approved. Every implementation prese= nts the same UI dialog for BASIC and DIGESt. This means there is no additio= nal security against a MITM attack as a malicious party can always ask for = the password using BASIC and the client has no way to know that it should n= ot sent the password enclair. We should definitely look at the better password exchange schemes like EKE = which are not encumbered. That would be a much better approach in my view t= han trying to patch DIGEST which was designed when DH was still encumbered = and is only designed to limit the consequences of stupidity as far as was p= ossible on the equipment of the day rather than eliminate all possible form= s of attack. But there is no point in doing that either unless the downgrade attack issu= e is also dealt with. -- Website: http://hallambaker.com/ --_000_5C4BC9217963F14D817A8ED51DB74B8007B4C7AZUS1EXMB02global_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

SIP (RFC 3261) doesn̵= 7;t allow Basic and only support Digest authentication so there’s sti= ll a requirement for Digest authentication.

 <= /p>

-David<= /p>

 <= /p>

From: http-aut= h-bounces@ietf.org [mailto:http-auth-bounces@ietf.org] On Behalf Of Phillip Hallam-Baker
Sent: Wednesday, February 06, 2013 9:06 AM
To: Cameron Jones
Cc: http-auth@ietf.org
Subject: Re: [http-auth] Zero-Knowledge Password Proof Migration [wa= s Re: Anyone on mailing list working for browser vendor]<= /p>

 

 

On Wed, Feb 6, 2013 at 11:42 AM, Cameron Jones <<= a href=3D"mailto:cmhjones@gmail.com" target=3D"_blank">cmhjones@gmail.com> wrote:

Branching to new topic.

On Wed, Feb 6, 2013 at 1:18 PM, Cameron Jones <cmhjones@gmail.com> wrote:=

On Tue, Feb 5, 2013 at 10:26 PM, Stephen Farrell <= ;stephen.far= rell@cs.tcd.ie> wrote:


Hi Cameron,


On 02/05/2013 06:40 PM, Cameron Jones wrote:
> I think largely what is in demand, based on other input to the HTML gr= oup,
> is a SRP-style protocol to protect against server password leaks.=

I don't think that wo= rks quite as you stated above.

Passwords leak from databases or keyboards and not via sniffing in
afaik pretty much all cases and strong password protocols still
have dictionary attackable password verifier databases.

There may still be good reasons to use a strong password protocol
like SRP or EKE or whatever of course and I've nothing against
'em, (some are really elegant), but we'd want to be clear about
what problems they do and don't address.

But that's getting ahead of ourselves probably.

S.

 

Hey Stephen,

Yes, I wasn't trying to overstate a demand for SRP or other zero-knowledge = password protocols above all else, more that there was a vocal demand for s= uch. The requests were triggered by the various unsalted password database = leaks\hack & grabs last year.

Personally i too find the mechanism elegant and potentially highly valuable= for some scenarios, but the migration for existing password-knowledgable s= ystems seems to be a significant hurdle in achieving that utopian ideal.



With a bit more thinking, and not being a cryptography expert, but would it= be possible to employ SRP-style algorithm for the user on the server-side = both for password migration and legacy scheme support?

So, standard SRP would work as normal, but legacy schemes (such as BASIC), = would have raw passwords SRP applied on the server-side for authorization a= nd storage?

The benefits to service providers of all this is that they would eliminate = their risk from password harvesters since the only useful information they = would store would be that which relates to their own service, instead of be= ing a point-of-failure for any email\password combination. SRP, if achievable, would largely eliminate the need for peop= le to have multiple passwords.

Thanks,
Cameron Jones

 

The big problem to avoid is the downgrade attack.

 

Digest was originally proposed to replace BASIC. It = was a mistake that should never have made it into the spec in my view and i= t would not have made it into the spec had we actually had a conversation a= bout it first. 

 

That didn't happen and so DIGEST only got implemente= d three years later as a checkbox requirement to get HTTP/1.1 approved. Eve= ry implementation presents the same UI dialog for BASIC and DIGESt. This me= ans there is no additional security against a MITM attack as a malicious party can always ask for the password= using BASIC and the client has no way to know that it should not sent the = password enclair.

 

 

We should definitely look at the better password exc= hange schemes like EKE which are not encumbered. That would be a much bette= r approach in my view than trying to patch DIGEST which was designed when D= H was still encumbered and is only designed to limit the consequences of stupidity as far as was possible on = the equipment of the day rather than eliminate all possible forms of attack= .

 

But there is no point in doing that either unless th= e downgrade attack issue is also dealt with.


 

--
Website: http://hallambaker.com/

--_000_5C4BC9217963F14D817A8ED51DB74B8007B4C7AZUS1EXMB02global_-- From yaronf.ietf@gmail.com Wed Feb 6 09:35:30 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8983421F8542 for ; Wed, 6 Feb 2013 09:35:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w+dMpwmx0tnL for ; Wed, 6 Feb 2013 09:35:29 -0800 (PST) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ietfa.amsl.com (Postfix) with ESMTP id 4858C21F8505 for ; Wed, 6 Feb 2013 09:35:29 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id fg15so1273715wgb.1 for ; Wed, 06 Feb 2013 09:35:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=9sObmbSoLmUVNJu/MJsinAwBFxs0CfEyhKYCH4p65rI=; b=AUYxRxFUH5Jov9NYhaXbRm+aKiDpmYvfLsQy9KgHOfwUsLCYjwfNT88XVJALRfzJhH PHTKodToHCdmgWq7+M7wvRIZnZsOTp0o6NvB/hpHV7AisHur81pEp879haurIBDYDTf1 s9Dz+Dl6p5Vpo6K65VaJTdPOFcBXTH+xrpvDYGbNw+b5NtFAv58HbXBWFyKLo8SiDByW rkRejeDAIsp0BFE2eBbCdcSesoUyhIKXRDTt4IZAFR8Wr/HW9MXHJ4CUTxXen6pWn7a+ IwzdNZi3uuSn7Q2crpMbwWs7zsio8gvMbQ3je4o1O/Rc44RFB36XwEowsI9vrAu0Gnjv FR+Q== X-Received: by 10.180.82.9 with SMTP id e9mr6862870wiy.1.1360172123814; Wed, 06 Feb 2013 09:35:23 -0800 (PST) Received: from [10.0.0.13] (85-250-110-45.bb.netvision.net.il. [85.250.110.45]) by mx.google.com with ESMTPS id b10sm4259299wix.7.2013.02.06.09.35.21 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Feb 2013 09:35:23 -0800 (PST) Message-ID: <51129458.9010005@gmail.com> Date: Wed, 06 Feb 2013 19:35:20 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Phillip Hallam-Baker References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Zero-Knowledge Password Proof Migration [was Re: Anyone on mailing list working for browser vendor] X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 17:35:30 -0000 Hi Phillip, we do have one more weapon today: HSTS can be used/modified to eliminate *some* of this issue. The first time I authenticate to www.example.com I get back a HTTP header that specifies that I should never use Basic or Digest with this domain, only SRP (or EKE or whatever). And to answer Cameron's question: unfortunately SRP password databases are as vulnerable to password guessing attacks as other password databases. Not the cleartext ones (whose admins should be taken out and shot) but the salted databases. Thanks, Yaron On 02/06/2013 07:05 PM, Phillip Hallam-Baker wrote: > > > On Wed, Feb 6, 2013 at 11:42 AM, Cameron Jones > wrote: > > Branching to new topic. > > On Wed, Feb 6, 2013 at 1:18 PM, Cameron Jones > wrote: > > On Tue, Feb 5, 2013 at 10:26 PM, Stephen Farrell > > > wrote: > > > Hi Cameron, > > On 02/05/2013 06:40 PM, Cameron Jones wrote: > > I think largely what is in demand, based on other input > to the HTML group, > > is a SRP-style protocol to protect against server > password leaks. > > I don't think that works quite as you stated above. > > Passwords leak from databases or keyboards and not via > sniffing in > afaik pretty much all cases and strong password protocols still > have dictionary attackable password verifier databases. > > There may still be good reasons to use a strong password > protocol > like SRP or EKE or whatever of course and I've nothing against > 'em, (some are really elegant), but we'd want to be clear about > what problems they do and don't address. > > But that's getting ahead of ourselves probably. > > S. > > > Hey Stephen, > > Yes, I wasn't trying to overstate a demand for SRP or other > zero-knowledge password protocols above all else, more that > there was a vocal demand for such. The requests were triggered > by the various unsalted password database leaks\hack & grabs > last year. > > Personally i too find the mechanism elegant and potentially > highly valuable for some scenarios, but the migration for > existing password-knowledgable systems seems to be a significant > hurdle in achieving that utopian ideal. > > > > > With a bit more thinking, and not being a cryptography expert, but > would it be possible to employ SRP-style algorithm for the user on > the server-side both for password migration and legacy scheme support? > > So, standard SRP would work as normal, but legacy schemes (such as > BASIC), would have raw passwords SRP applied on the server-side for > authorization and storage? > > The benefits to service providers of all this is that they would > eliminate their risk from password harvesters since the only useful > information they would store would be that which relates to their > own service, instead of being a point-of-failure for any > email\password combination. SRP, if achievable, would largely > eliminate the need for people to have multiple passwords. > > Thanks, > Cameron Jones > > > The big problem to avoid is the downgrade attack. > > Digest was originally proposed to replace BASIC. It was a mistake that > should never have made it into the spec in my view and it would not have > made it into the spec had we actually had a conversation about it first. > > That didn't happen and so DIGEST only got implemented three years later > as a checkbox requirement to get HTTP/1.1 approved. Every implementation > presents the same UI dialog for BASIC and DIGESt. This means there is no > additional security against a MITM attack as a malicious party can > always ask for the password using BASIC and the client has no way to > know that it should not sent the password enclair. > > > We should definitely look at the better password exchange schemes like > EKE which are not encumbered. That would be a much better approach in my > view than trying to patch DIGEST which was designed when DH was still > encumbered and is only designed to limit the consequences of stupidity > as far as was possible on the equipment of the day rather than eliminate > all possible forms of attack. > > But there is no point in doing that either unless the downgrade attack > issue is also dealt with. > > > -- > Website: http://hallambaker.com/ > > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > From hallam@gmail.com Wed Feb 6 09:40:51 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77C3621F879E for ; Wed, 6 Feb 2013 09:40:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=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 wf-sH9UWM0ch for ; Wed, 6 Feb 2013 09:40:50 -0800 (PST) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 121C221F88B6 for ; Wed, 6 Feb 2013 09:40:49 -0800 (PST) Received: by mail-we0-f181.google.com with SMTP id t44so1327865wey.12 for ; Wed, 06 Feb 2013 09:40:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=aBpZYyxycDGkxpP9Nef2OGNUlkVY98JD5zcEeenC1kI=; b=Z/CO3uG5K1l5pFprHD0xdIIl99ebb98xECDBmSWi8yrPfWNHZYHRSTX2Tk8lugxmPg +kWl6UMVZWL26wsOFRXrse3zcnhaV5jB9DFVWAdE1AzUuFPsWqP12WwPb8paTZfWH2A2 J+fgcRO1G0X/DAB70c8SNcBa+hzpSWtZW3V9Df17+U9yF541H/z2YDqe2f/fYZlcoBwU IaxmW8KqiExYIRpfidqQMFqQ5GiOQBJfrNDB4XKdYabQYSfDMjXpBbLNwuDVB79Uf0dF YXy7Nyd9RYux36ZB3+PTcTFUCWk9FHStGRVrJCfg5eHPcV3YGelHJfTodhmAiE9N0JAT Pw+w== MIME-Version: 1.0 X-Received: by 10.180.88.40 with SMTP id bd8mr6158852wib.17.1360172442712; Wed, 06 Feb 2013 09:40:42 -0800 (PST) Received: by 10.194.153.104 with HTTP; Wed, 6 Feb 2013 09:40:42 -0800 (PST) In-Reply-To: <51129458.9010005@gmail.com> References: <51129458.9010005@gmail.com> Date: Wed, 6 Feb 2013 12:40:42 -0500 Message-ID: From: Phillip Hallam-Baker To: Yaron Sheffer Content-Type: multipart/alternative; boundary=f46d04428f1247fb3904d511d362 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Zero-Knowledge Password Proof Migration [was Re: Anyone on mailing list working for browser vendor] X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 17:40:51 -0000 --f46d04428f1247fb3904d511d362 Content-Type: text/plain; charset=ISO-8859-1 There is certainly a need for out of band policy signalling. What I would like to see is the ability to signal the policy in either the HTTP header (for secure after first contact) and through a DNSSEC protected DNS record (for secure on first contact). So I see two separate questions 1) What is the information to be signaled? 2) What mechanisms are to be used to publish the information? The first would be a combination of the HTTP AUTH group and WebSEC. The second would be a WebSec thing and a DNS thing. Since DNSEXT is closed that should probably be an Apps area discussion. On Wed, Feb 6, 2013 at 12:35 PM, Yaron Sheffer wrote: > Hi Phillip, > > we do have one more weapon today: HSTS can be used/modified to eliminate > *some* of this issue. The first time I authenticate to www.example.com I > get back a HTTP header that specifies that I should never use Basic or > Digest with this domain, only SRP (or EKE or whatever). > > And to answer Cameron's question: unfortunately SRP password databases are > as vulnerable to password guessing attacks as other password databases. Not > the cleartext ones (whose admins should be taken out and shot) but the > salted databases. > > Thanks, > Yaron > > > On 02/06/2013 07:05 PM, Phillip Hallam-Baker wrote: > >> >> >> On Wed, Feb 6, 2013 at 11:42 AM, Cameron Jones > > wrote: >> >> Branching to new topic. >> >> On Wed, Feb 6, 2013 at 1:18 PM, Cameron Jones > > wrote: >> >> On Tue, Feb 5, 2013 at 10:26 PM, Stephen Farrell >> >> >> >> >> wrote: >> >> >> Hi Cameron, >> >> On 02/05/2013 06:40 PM, Cameron Jones wrote: >> > I think largely what is in demand, based on other input >> to the HTML group, >> > is a SRP-style protocol to protect against server >> password leaks. >> >> I don't think that works quite as you stated above. >> >> Passwords leak from databases or keyboards and not via >> sniffing in >> afaik pretty much all cases and strong password protocols >> still >> have dictionary attackable password verifier databases. >> >> There may still be good reasons to use a strong password >> protocol >> like SRP or EKE or whatever of course and I've nothing against >> 'em, (some are really elegant), but we'd want to be clear >> about >> what problems they do and don't address. >> >> But that's getting ahead of ourselves probably. >> >> S. >> >> >> Hey Stephen, >> >> Yes, I wasn't trying to overstate a demand for SRP or other >> zero-knowledge password protocols above all else, more that >> there was a vocal demand for such. The requests were triggered >> by the various unsalted password database leaks\hack & grabs >> last year. >> >> Personally i too find the mechanism elegant and potentially >> highly valuable for some scenarios, but the migration for >> existing password-knowledgable systems seems to be a significant >> hurdle in achieving that utopian ideal. >> >> >> >> >> With a bit more thinking, and not being a cryptography expert, but >> would it be possible to employ SRP-style algorithm for the user on >> the server-side both for password migration and legacy scheme support? >> >> So, standard SRP would work as normal, but legacy schemes (such as >> BASIC), would have raw passwords SRP applied on the server-side for >> authorization and storage? >> >> The benefits to service providers of all this is that they would >> eliminate their risk from password harvesters since the only useful >> information they would store would be that which relates to their >> own service, instead of being a point-of-failure for any >> email\password combination. SRP, if achievable, would largely >> eliminate the need for people to have multiple passwords. >> >> Thanks, >> Cameron Jones >> >> >> The big problem to avoid is the downgrade attack. >> >> Digest was originally proposed to replace BASIC. It was a mistake that >> should never have made it into the spec in my view and it would not have >> made it into the spec had we actually had a conversation about it first. >> >> That didn't happen and so DIGEST only got implemented three years later >> as a checkbox requirement to get HTTP/1.1 approved. Every implementation >> presents the same UI dialog for BASIC and DIGESt. This means there is no >> additional security against a MITM attack as a malicious party can >> always ask for the password using BASIC and the client has no way to >> know that it should not sent the password enclair. >> >> >> We should definitely look at the better password exchange schemes like >> EKE which are not encumbered. That would be a much better approach in my >> view than trying to patch DIGEST which was designed when DH was still >> encumbered and is only designed to limit the consequences of stupidity >> as far as was possible on the equipment of the day rather than eliminate >> all possible forms of attack. >> >> But there is no point in doing that either unless the downgrade attack >> issue is also dealt with. >> >> >> -- >> Website: http://hallambaker.com/ >> >> >> ______________________________**_________________ >> http-auth mailing list >> http-auth@ietf.org >> https://www.ietf.org/mailman/**listinfo/http-auth >> >> -- Website: http://hallambaker.com/ --f46d04428f1247fb3904d511d362 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable There is certainly a need for out of band policy signalling.

=
What I would like to see is the ability to signal the policy in either= the HTTP header (for secure after first contact) and through a DNSSEC prot= ected DNS record (for secure on first contact).

So I see two separate questions

1) What is the information to be signaled?
2) What mechanisms a= re to be used to publish the information?

The firs= t would be a combination of the HTTP AUTH group and WebSEC. The second woul= d be a WebSec thing and a DNS thing. Since DNSEXT is closed that should pro= bably be an Apps area discussion.


On Wed, Feb 6, 2013 at 1= 2:35 PM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
Hi Phillip,

we do have one more weapon today: HSTS can be used/modified to eliminate *s= ome* of this issue. The first time I authenticate to www.example.com I get back a HTTP header= that specifies that I should never use Basic or Digest with this domain, o= nly SRP (or EKE or whatever).

And to answer Cameron's question: unfortunately SRP password databases = are as vulnerable to password guessing attacks as other password databases.= Not the cleartext ones (whose admins should be taken out and shot) but the= salted databases.

Thanks,
=A0 =A0 =A0 =A0 Yaron


On 02/06/2013 07:05 PM, Phillip Hallam-Baker wrote:


On Wed, Feb 6, 2013 at 11:42 AM, Cameron Jones <cmhjones@gmail.com
<mailto:cmhjones= @gmail.com>> wrote:

=A0 =A0 Branching to new topic.

=A0 =A0 On Wed, Feb 6, 2013 at 1:18 PM, Cameron Jones <cmhjones@gmail.com
=A0 =A0 <mailto:= cmhjones@gmail.com>> wrote:

=A0 =A0 =A0 =A0 On Tue, Feb 5, 2013 at 10:26 PM, Stephen Farrell
=A0 =A0 =A0 =A0 <stephen.farrell@cs.tcd.ie <mailto:stephen.farrell@cs.tcd.ie&g= t;>

=A0 =A0 =A0 =A0 wrote:


=A0 =A0 =A0 =A0 =A0 =A0 Hi Cameron,

=A0 =A0 =A0 =A0 =A0 =A0 On 02/05/2013 06:40 PM, Cameron Jones wrote:
=A0 =A0 =A0 =A0 =A0 =A0 =A0> I think largely what is in demand, based on= other input
=A0 =A0 =A0 =A0 =A0 =A0 to the HTML group,
=A0 =A0 =A0 =A0 =A0 =A0 =A0> is a SRP-style protocol to protect against = server
=A0 =A0 =A0 =A0 =A0 =A0 password leaks.

=A0 =A0 =A0 =A0 =A0 =A0 I don't think that works quite as you stated ab= ove.

=A0 =A0 =A0 =A0 =A0 =A0 Passwords leak from databases or keyboards and not = via
=A0 =A0 =A0 =A0 =A0 =A0 sniffing in
=A0 =A0 =A0 =A0 =A0 =A0 afaik pretty much all cases and strong password pro= tocols still
=A0 =A0 =A0 =A0 =A0 =A0 have dictionary attackable password verifier databa= ses.

=A0 =A0 =A0 =A0 =A0 =A0 There may still be good reasons to use a strong pas= sword
=A0 =A0 =A0 =A0 =A0 =A0 protocol
=A0 =A0 =A0 =A0 =A0 =A0 like SRP or EKE or whatever of course and I've = nothing against
=A0 =A0 =A0 =A0 =A0 =A0 'em, (some are really elegant), but we'd wa= nt to be clear about
=A0 =A0 =A0 =A0 =A0 =A0 what problems they do and don't address.

=A0 =A0 =A0 =A0 =A0 =A0 But that's getting ahead of ourselves probably.=

=A0 =A0 =A0 =A0 =A0 =A0 S.


=A0 =A0 =A0 =A0 Hey Stephen,

=A0 =A0 =A0 =A0 Yes, I wasn't trying to overstate a demand for SRP or o= ther
=A0 =A0 =A0 =A0 zero-knowledge password protocols above all else, more that=
=A0 =A0 =A0 =A0 there was a vocal demand for such. The requests were trigge= red
=A0 =A0 =A0 =A0 by the various unsalted password database leaks\hack & = grabs
=A0 =A0 =A0 =A0 last year.

=A0 =A0 =A0 =A0 Personally i too find the mechanism elegant and potentially=
=A0 =A0 =A0 =A0 highly valuable for some scenarios, but the migration for =A0 =A0 =A0 =A0 existing password-knowledgable systems seems to be a signif= icant
=A0 =A0 =A0 =A0 hurdle in achieving that utopian ideal.




=A0 =A0 With a bit more thinking, and not being a cryptography expert, but<= br> =A0 =A0 would it be possible to employ SRP-style algorithm for the user on<= br> =A0 =A0 the server-side both for password migration and legacy scheme suppo= rt?

=A0 =A0 So, standard SRP would work as normal, but legacy schemes (such as<= br> =A0 =A0 BASIC), would have raw passwords SRP applied on the server-side for=
=A0 =A0 authorization and storage?

=A0 =A0 The benefits to service providers of all this is that they would =A0 =A0 eliminate their risk from password harvesters since the only useful=
=A0 =A0 information they would store would be that which relates to their =A0 =A0 own service, instead of being a point-of-failure for any
=A0 =A0 email\password combination. SRP, if achievable, would largely
=A0 =A0 eliminate the need for people to have multiple passwords.

=A0 =A0 Thanks,
=A0 =A0 Cameron Jones


The big problem to avoid is the downgrade attack.

Digest was originally proposed to replace BASIC. It was a mistake that
should never have made it into the spec in my view and it would not have made it into the spec had we actually had a conversation about it first.
That didn't happen and so DIGEST only got implemented three years later=
as a checkbox requirement to get HTTP/1.1 approved. Every implementation presents the same UI dialog for BASIC and DIGESt. This means there is no additional security against a MITM attack as a malicious party can
always ask for the password using BASIC and the client has no way to
know that it should not sent the password enclair.


We should definitely look at the better password exchange schemes like
EKE which are not encumbered. That would be a much better approach in my view than trying to patch DIGEST which was designed when DH was still
encumbered and is only designed to limit the consequences of stupidity
as far as was possible on the equipment of the day rather than eliminate all possible forms of attack.

But there is no point in doing that either unless the downgrade attack
issue is also dealt with.


--
Website: http://halla= mbaker.com/


_______________________________________________
http-auth mailing list
http-auth@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/http-auth




--
Website: http://hallambaker.com/
--f46d04428f1247fb3904d511d362-- From nico@cryptonector.com Wed Feb 6 09:53:12 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E5C721F85FD for ; Wed, 6 Feb 2013 09:53:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.904 X-Spam-Level: X-Spam-Status: No, score=-3.904 tagged_above=-999 required=5 tests=[AWL=-2.528, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_46=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 YuN9bGP5KzD4 for ; Wed, 6 Feb 2013 09:53:12 -0800 (PST) Received: from homiemail-a70.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 6C2DD21F8545 for ; Wed, 6 Feb 2013 09:52:57 -0800 (PST) Received: from homiemail-a70.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTP id 227AF76806A for ; Wed, 6 Feb 2013 09:52:57 -0800 (PST) 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=X59B1l6MSmDM0om/INKy X2pvKgs=; b=AEilZ2k/+eyIFES+q6pK9LRnaD9rVFANu5mBzbX5suIuZxu3PER8 6+fAzUTBWpasyEUImJqd7yFC/em3WTOoIBjniN9eFf7xl4nT9G4eWLaLb6CpWr6a 7u8GtTWadw1Pf7UE5SSire84p7Erk7/fj8sFpSitunc0+0Iz8AOu3pU= Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTPSA id B861E768083 for ; Wed, 6 Feb 2013 09:52:56 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id hq4so5871340wib.12 for ; Wed, 06 Feb 2013 09:52:55 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.77.13 with SMTP id o13mr51465423wjw.58.1360173175374; Wed, 06 Feb 2013 09:52:55 -0800 (PST) Received: by 10.217.39.133 with HTTP; Wed, 6 Feb 2013 09:52:55 -0800 (PST) Received: by 10.217.39.133 with HTTP; Wed, 6 Feb 2013 09:52:55 -0800 (PST) In-Reply-To: References: <51129458.9010005@gmail.com> Date: Wed, 6 Feb 2013 11:52:55 -0600 Message-ID: From: Nico Williams To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=047d7bfcfc6af382fc04d511feb6 Cc: http-auth@ietf.org Subject: Re: [http-auth] Zero-Knowledge Password Proof Migration [was Re: Anyone on mailing list working for browser vendor] X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 17:53:12 -0000 --047d7bfcfc6af382fc04d511feb6 Content-Type: text/plain; charset=UTF-8 EKE leaks password information because DH public keys contain some structure (all DH and ECDH.groups feature this problem, with the amount of structure varying by group), usually a few bits with not fixed but probable values, which allows off-line attackers to eliminate 2^(that many bits) passwords from the password dictionary search space. Use PACE, J-PAKE, SRP -, any other unencumbered ZKPP protocol known to not suffer from this problem. Nico -- On Feb 6, 2013 12:05 PM, "Phillip Hallam-Baker" wrote: --047d7bfcfc6af382fc04d511feb6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

EKE leaks password information because DH public keys contain some struc= ture (all DH and ECDH.groups feature this problem, with the amount of struc= ture varying by group), usually a few bits with not fixed but probable valu= es, which allows off-line attackers to eliminate 2^(that many bits) passwor= ds from the password dictionary search space.

Use PACE, J-PAKE, SRP -, any other unencumbered ZKPP protocol known to n= ot suffer from this problem.

Nico
--

On Feb 6, 2013 12:05 PM, "Phillip Hallam-Baker" <hallam@gmail.com> wrote:

--047d7bfcfc6af382fc04d511feb6-- From nico@cryptonector.com Wed Feb 6 09:53:38 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 868D521F8700 for ; Wed, 6 Feb 2013 09:53:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.807 X-Spam-Level: X-Spam-Status: No, score=-3.807 tagged_above=-999 required=5 tests=[AWL=-2.431, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_46=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 qJJX1iw-TElH for ; Wed, 6 Feb 2013 09:53:38 -0800 (PST) Received: from homiemail-a70.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 5F66321F8545 for ; Wed, 6 Feb 2013 09:53:37 -0800 (PST) Received: from homiemail-a70.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTP id 2E073768077 for ; Wed, 6 Feb 2013 09:53:37 -0800 (PST) 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=wF/4QB5UTvZpCRC8mUYV lF6A5vA=; b=lWExYJKPAklx9EhwwCje8cIP3/kiIfyijZI5nJ8C4KAz1VLrH88S rAvGl8gYTP2EjDEEuRQ/yLrV61ytJJDSwbTowH74xDE6UyjRlRnSxmeR9zXp4r36 MfqjxxXeGmjzBDhfInyKbu37ZgcGnJkhIWApqXitvEiHyNmQ44vuGxU= Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTPSA id BCEAC768080 for ; Wed, 6 Feb 2013 09:53:36 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id hm14so5871775wib.15 for ; Wed, 06 Feb 2013 09:53:35 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.8.130 with SMTP id r2mr6703639wia.28.1360173215398; Wed, 06 Feb 2013 09:53:35 -0800 (PST) Received: by 10.217.39.133 with HTTP; Wed, 6 Feb 2013 09:53:35 -0800 (PST) Received: by 10.217.39.133 with HTTP; Wed, 6 Feb 2013 09:53:35 -0800 (PST) In-Reply-To: References: <51129458.9010005@gmail.com> Date: Wed, 6 Feb 2013 11:53:35 -0600 Message-ID: From: Nico Williams To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=f46d0444029a563d1204d512012b Cc: http-auth@ietf.org Subject: Re: [http-auth] Zero-Knowledge Password Proof Migration [was Re: Anyone on mailing list working for browser vendor] X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 17:53:38 -0000 --f46d0444029a563d1204d512012b Content-Type: text/plain; charset=UTF-8 EKE leaks password information because DH public keys contain some structure (all DH and ECDH.groups feature this problem, with the amount of structure varying by group), usually a few bits with not fixed but probable values, which allows off-line attackers to eliminate 2^(that many bits) passwords from the password dictionary search space. Use PACE, J-PAKE, SRP -, any other unencumbered ZKPP protocol known to not suffer from this problem. Nico -- On Feb 6, 2013 12:05 PM, "Phillip Hallam-Baker" wrote: --f46d0444029a563d1204d512012b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

EKE leaks password information because DH public keys contain some struc= ture (all DH and ECDH.groups feature this problem, with the amount of struc= ture varying by group), usually a few bits with not fixed but probable valu= es, which allows off-line attackers to eliminate 2^(that many bits) passwor= ds from the password dictionary search space.

Use PACE, J-PAKE, SRP -, any other unencumbered ZKPP protocol known to n= ot suffer from this problem.

Nico
--

On Feb 6, 2013 12:05 PM, "Phillip Hallam-Baker" <hallam@gmail.com> wrote:

--f46d0444029a563d1204d512012b-- From cmhjones@gmail.com Wed Feb 6 10:13:58 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55B2221F8A33 for ; Wed, 6 Feb 2013 10:13:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.973 X-Spam-Level: X-Spam-Status: No, score=-2.973 tagged_above=-999 required=5 tests=[AWL=0.625, 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 bAkWeQbukFM5 for ; Wed, 6 Feb 2013 10:13:57 -0800 (PST) Received: from mail-ob0-f180.google.com (mail-ob0-f180.google.com [209.85.214.180]) by ietfa.amsl.com (Postfix) with ESMTP id CC70921F8A2F for ; Wed, 6 Feb 2013 10:13:57 -0800 (PST) Received: by mail-ob0-f180.google.com with SMTP id ef5so1783848obb.11 for ; Wed, 06 Feb 2013 10:13:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=AwBpJS0FdtGPivTefQiQ3yrBhyyRQbSN0Mz+6/gdrTE=; b=F3WcotQ2W7JI0YeOn+3h0LUdlXINVod+rKDVxZpaKIO68lgy//l2tyl40NIb7D1Llc 32ooNAEVBxtQisP2zuw7rn9HDax025ww/yDRgvH3v7O2AiyspwCT6wnTh3M6En+t9Aup 9/pLU7hxED22Sl73GopdrFcx6Sj8eQrZv3q0L3IcAjHWTu7bwp/O9h0+UDjqXHvQkIlI Xxq2MOBCIyCyEoQTjoDrVDBaaTKeRtO5tYwglqb5eAzuBaCFe3viVFpl5W+0W3GtiH+q +pMZAvrx9iMKvHc27P1d/1hUHXFE8K82V8iJp6QqvkVzayQE7ZCghgjQFkFreQKCn8GR yTeg== MIME-Version: 1.0 X-Received: by 10.182.38.69 with SMTP id e5mr22085178obk.79.1360174437389; Wed, 06 Feb 2013 10:13:57 -0800 (PST) Received: by 10.60.162.103 with HTTP; Wed, 6 Feb 2013 10:13:57 -0800 (PST) In-Reply-To: <51129458.9010005@gmail.com> References: <51129458.9010005@gmail.com> Date: Wed, 6 Feb 2013 18:13:57 +0000 Message-ID: From: Cameron Jones To: Yaron Sheffer Content-Type: multipart/alternative; boundary=f46d04462f0e2c552304d5124ada Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Zero-Knowledge Password Proof Migration [was Re: Anyone on mailing list working for browser vendor] X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 18:13:58 -0000 --f46d04462f0e2c552304d5124ada Content-Type: text/plain; charset=ISO-8859-1 On Wed, Feb 6, 2013 at 5:35 PM, Yaron Sheffer wrote: > Hi Phillip, > > we do have one more weapon today: HSTS can be used/modified to eliminate > *some* of this issue. The first time I authenticate to www.example.com I > get back a HTTP header that specifies that I should never use Basic or > Digest with this domain, only SRP (or EKE or whatever). > > And to answer Cameron's question: unfortunately SRP password databases are > as vulnerable to password guessing attacks as other password databases. Not > the cleartext ones (whose admins should be taken out and shot) but the > salted databases. > > Thanks, > Yaron > > Ahh thanks, i see that now. It is no magic bullet. Thanks, Cameron Jones --f46d04462f0e2c552304d5124ada Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Feb 6, 2013 at 5:35 PM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
Hi Phillip,

we do have one more weapon today: HSTS can be used/modified to eliminate *s= ome* of this issue. The first time I authenticate to www.example.com I get back a HTTP header= that specifies that I should never use Basic or Digest with this domain, o= nly SRP (or EKE or whatever).

And to answer Cameron's question: unfortunately SRP password databases = are as vulnerable to password guessing attacks as other password databases.= Not the cleartext ones (whose admins should be taken out and shot) but the= salted databases.

Thanks,
=A0 =A0 =A0 =A0 Yaron


Ahh = thanks, i see that now. It is no magic bullet.

Thanks,
Cameron Jo= nes

--f46d04462f0e2c552304d5124ada-- From y.oiwa@aist.go.jp Wed Feb 6 18:20:01 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F9311F0D07 for ; Wed, 6 Feb 2013 18:20:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 7-d44VMCTCUz for ; Wed, 6 Feb 2013 18:20:00 -0800 (PST) Received: from na3sys010aog110.obsmtp.com (na3sys010aog110.obsmtp.com [74.125.245.88]) by ietfa.amsl.com (Postfix) with ESMTP id 955A81F0D04 for ; Wed, 6 Feb 2013 18:20:00 -0800 (PST) Received: from mail-vb0-f70.google.com ([209.85.212.70]) (using TLSv1) by na3sys010aob110.postini.com ([74.125.244.12]) with SMTP ID DSNKURMPUGI843BVBqy32oBBQ/BDk5CKiKNq@postini.com; Wed, 06 Feb 2013 18:20:00 PST Received: by mail-vb0-f70.google.com with SMTP id s24so2655609vbi.5 for ; Wed, 06 Feb 2013 18:19:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=vyQHWAn96TQPh5N27pqkG2NmqrsGsX+Exauk35754Qc=; b=hhkD+5Ga166Z9wUII3SmJ5TE9//BhDoGC8+YnVSwejub2M24e2qZ6b47a2gQ/Ao57y DSf83MpUakXQDffstQxp3bJYJA0d64FpzFH8kcTM8w5Zx/DUdzJp5mQUhgdZkygnLsDM IZP/GcH53jc/JK25grHRCEjyXznwNmz33/AD8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=vyQHWAn96TQPh5N27pqkG2NmqrsGsX+Exauk35754Qc=; b=MMlTBVcK6a08l0YRy0HUiZGhhiE1ga9HUyvAAnOIBdMehYu8YQIqyXxAUlRccPmlV4 T+mXf7u5a5Lvlv3NUk9u7EiSthyk2BxYUGjGToNyf3dipy5p8EFzvguwizGlKdGRGUYo xu4qUkWkNiValec3kL3lrtAeg8Z7y7FByYe5wFpJ0QM6GrFX/Gqv8hnDQlWWIqfn2ffE GtNMv1ct5V7t5mKz08qrOyXlZSsP3VpEdwoyUDsLeONsjP7ccSJdBXP3kLAzos/liXIe 4Ay58doK7nm0vBh/OfKc5dz3NjHKZf6x14lQ2vI1+Y+hwRmKyODroE7xMKrcC6791o4W PJIg== X-Received: by 10.220.115.133 with SMTP id i5mr35337070vcq.42.1360203599514; Wed, 06 Feb 2013 18:19:59 -0800 (PST) X-Received: by 10.220.115.133 with SMTP id i5mr35337064vcq.42.1360203599417; Wed, 06 Feb 2013 18:19:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.151.176 with HTTP; Wed, 6 Feb 2013 18:19:39 -0800 (PST) In-Reply-To: <4613980CFC78314ABFD7F85CC30277211199CB1A@IL-EX10.ad.checkpoint.com> References: <50F2F075.8090809@cs.tcd.ie> <51068A27.1050601@ieca.com> <51069692.20706@cs.tcd.ie> <510FCD99.3000300@ieca.com> <4613980CFC78314ABFD7F85CC30277211199C31F@IL-EX10.ad.checkpoint.com> <51111C99.5070906@w3.org> <51112B1C.7040201@gmx.de> <34748E83-144D-43B3-9645-15E920B03A61@mnot.net> <4613980CFC78314ABFD7F85CC30277211199CB1A@IL-EX10.ad.checkpoint.com> From: Yutaka OIWA Date: Thu, 7 Feb 2013 11:19:39 +0900 Message-ID: To: Yoav Nir Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQk0NVSTW6i1n9blOaCp40Ii7B2wcxjeD55gjVe6GmSF+fBeGIYqz7lud9QwDLeKz9vn3lKrl9ECWT7s0FX55lqWXFaxh6HxOTVRzhJ3Dxc2ptDrRI4FBJs/X0Bje/PcINLP14xyiniwGLeb8lrXcJfJnD9R9Q== Cc: Julian Reschke , Mark Nottingham , "" Subject: Re: [http-auth] Anyone on mailing list working for browser vendor [was Re: charter rev -03] X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 02:20:01 -0000 2013/2/6 Yoav Nir : >> On 06/02/2013, at 2:54 AM, Julian Reschke wrote: >> OTOH, two major browsers are Open Source projects; has anyone committed to keeping patches for them up-to-date, at least? > > AFAIK, out of the proposals that we've heard in Atlanta, only one (mutualAuth) has been implemented in a browser, and that was a patch over Firefox 3.5 (current version is 18) The FF implementation is available on . We're currently implementing the protocol also on Chromium source codes. -- Yutaka OIWA, Ph.D. Leader, Software Reliability Research Group Research Institute for Secure Systems (RISEC) 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 bkihara.l@gmail.com Thu Feb 7 02:00:11 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A175321F8554 for ; Thu, 7 Feb 2013 02:00:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 dBwC2WB+bJWu for ; Thu, 7 Feb 2013 02:00:11 -0800 (PST) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id CF4D021F854C for ; Thu, 7 Feb 2013 02:00:10 -0800 (PST) Received: by mail-la0-f50.google.com with SMTP id ec20so2418513lab.9 for ; Thu, 07 Feb 2013 02:00:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=MQmo8VdXhD6knIXpP1XCd5i/SU3jJr2ZjdUl5U7DcuU=; b=K9HMbk/f936WyLethA29YhlG+kgQVkkgVKeSDUrwSvtVUzsHoVva6bwV96scQpCTGT lGpGRH2zEfwqxXEQ2LrXs6LezYX1lrWMqn1p+h2RQnSvCDWMEj1bBl0wa5TOivicL50I jwpGr/b7tPbkoNkvbiuMZ7gS2sCnRA1tg0VwKSPElYYql2JtryNNKcHC/y75mXsjHEaN hmGj2cGmsac2f7yTAp0pwMzHnjLCJFQo0u8/XD1fJj5NdhNpa76OyTyf9u0E6Fc0+cVb S8BvXE/rAIYN5MQ6bIQwagzj/IQdt44vhJo78FUR/EbRQeLcvqP+tEsmFrO+7f1d8BAY aGgg== MIME-Version: 1.0 X-Received: by 10.152.131.168 with SMTP id on8mr677225lab.38.1360231209546; Thu, 07 Feb 2013 02:00:09 -0800 (PST) Received: by 10.112.33.148 with HTTP; Thu, 7 Feb 2013 02:00:09 -0800 (PST) In-Reply-To: <510FCD99.3000300@ieca.com> References: <50F2F075.8090809@cs.tcd.ie> <51068A27.1050601@ieca.com> <51069692.20706@cs.tcd.ie> <510FCD99.3000300@ieca.com> Date: Thu, 7 Feb 2013 19:00:09 +0900 Message-ID: From: "KIHARA, Boku" To: Sean Turner Content-Type: text/plain; charset=ISO-8859-1 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] charter rev -03 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 10:00:11 -0000 +1. 2013/2/5 Sean Turner : > On 1/28/13 10:17 AM, Stephen Farrell wrote: >> >> >> >> On 01/28/2013 02:24 PM, Sean Turner wrote: >>> >>> Right so the plan here is to put this on the BOF list with the hope that >>> a WG will get formed before IETF 86. Obviously this plan is predicated >>> on more expressions of support for the proposed charter. >> >> >> As a draft author, I think forming a wg with this charter >> would be good. (As an IESG member, I'll be recusing myself >> from IESG balloting on this.) > > > Just to be clear, it's time to speak up if you support the idea of forming a > WG because silence means we shelve the idea. > > spt > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth From y.oiwa@aist.go.jp Mon Feb 18 10:40:27 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7005F21F871D for ; Mon, 18 Feb 2013 10:40:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 zJFiLrUnhZfJ for ; Mon, 18 Feb 2013 10:40:26 -0800 (PST) Received: from na3sys010aog101.obsmtp.com (na3sys010aog101.obsmtp.com [74.125.245.70]) by ietfa.amsl.com (Postfix) with ESMTP id 7533D21F8563 for ; Mon, 18 Feb 2013 10:40:26 -0800 (PST) Received: from mail-gg0-f199.google.com ([209.85.161.199]) (using TLSv1) by na3sys010aob101.postini.com ([74.125.244.12]) with SMTP ID DSNKUSJ1monZXrFmIVq2pvzFEauh4BigapZS@postini.com; Mon, 18 Feb 2013 10:40:26 PST Received: by mail-gg0-f199.google.com with SMTP id v5so4372025ggn.10 for ; Mon, 18 Feb 2013 10:40:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=x-received:x-received:mime-version:from:date:message-id:subject:to :content-type; bh=p3/DL60I9KIKdfqg5iUgob6YuvKz9kUeySdJ/PrWYsE=; b=FGFPUraDWVRtr7UedJsbeOImZl4jxfdorVbFUeeKMt7jTibV3/pHH/8WPGPSWHFiz5 nfwnH7gfrDDpGYfWnG70CI+ki02o7nmccwY3qnVinY7FKO+5qYQWYIg9so/hTeBf788w msuuuBTICebaGrq9/F0798yJmGf6C6H0e6PqU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=p3/DL60I9KIKdfqg5iUgob6YuvKz9kUeySdJ/PrWYsE=; b=XV4dau9wY+7UAdkBxA+E3iG1Fp7l7SyHnJGCNlMVsXDUlJXYqcy0SMq3lmMh4y6qMg U+aNuihhAh0cytUbTu5UsBl6RpWK0wyvXvYQXf9Z19ScqGQU8HQSAttvcUG+IACXQhzp L8vBDsP6Y/g8exAAEb18O3sQojmyzllsftI9LiBWShuB4i7gdwGLRXsdpgFhIQHN4Jg2 RRmQChUJfXgyuZFN/k5GrWY/RjPd4aT5XzVNvJdYz1yX5LMxvZSH7vm6eAwUFmg11E64 IjORHCNhqZJaDmu4x54Xufnr1f15fNLTJGhhgA6B/IvInElTCD893a/s16l6gw5hn96/ T7zw== X-Received: by 10.220.149.198 with SMTP id u6mr16635142vcv.52.1361212825661; Mon, 18 Feb 2013 10:40:25 -0800 (PST) X-Received: by 10.220.149.198 with SMTP id u6mr16635129vcv.52.1361212825515; Mon, 18 Feb 2013 10:40:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.151.176 with HTTP; Mon, 18 Feb 2013 10:40:05 -0800 (PST) From: Yutaka OIWA Date: Tue, 19 Feb 2013 03:40:05 +0900 Message-ID: To: "" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQn2YAz/5G1bAkI5iIhgBhqikUOp8tbrovN2Dti8bsUIPX5VzStNStjuAFIDjrqE453xvZlHhVWmzaKgWR0gQhA61sPuDhyD0PRHQ2pfcQV4UHisGwx7b4QQ5fYZ0tO67hRpBpVL2eBBWTL/pzXHDqappDT57w== Subject: [http-auth] Some strawman for implementation/design template (Re: Anyone on mailing list working for browser vendor) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 18:40:27 -0000 Dear all, I strongly feel that working-code principle is thought important by many people here, and we're managing to keep (at least one of) our code up-to-date, at least in regards to the new specification draft, so that we can see how the new things will work. We're not always possible to be keep it day-by-day, by at least we intend to as much as possible. Another concern is how to convince people to implement many independent proposals into working code, which would require independent maintanance works (even if the people like several individual proposals). Designing and implementing an multi-message authentication is really cumbersome, and people will not want to do it for two times or more. As a possible workaround to this, I wrote up a small (?) strawman proposal for having a "common basis" for shared functionalities. As you may know, my Mutual proposal already has a working mechanism for efficient re-authentication, nonce managements, channel binding and others. I extracted all the things which are not specific to PAKE- (or ZKPP-) based authentications, and compiled into a single draft named "Common Template for HTTP Message-based Multi-hop Authentication" (draft-oiwa-httpauth-multihop-template-00). It is just a strawman and I'm not forcing people to use this template in any way, but if you like it, you can design your own multi-message authentication by just defining a few key-exchange functions only, quoting the draft for all the rest. You will almost automatically have fast re-authentication, channel binding and nonce management mechanisms on the wire. Also, from the implementors' perspective, one can share the working code for all protocols based on the template, greatly reducing the maintenance and debugging overhead. I am quite open for improving the proposals, including incompatible changes to the message format. If such a movement become successful, I would rewrite my own proposal to use the common vehicle as well. Please take a look and give us comments. The strawman proposal is available from: http://www.ietf.org/id/draft-oiwa-httpauth-multihop-template-00.txt 2013/2/7 Yutaka OIWA : > 2013/2/6 Yoav Nir : >>> On 06/02/2013, at 2:54 AM, Julian Reschke wrote: >>> OTOH, two major browsers are Open Source projects; has anyone committed to keeping patches for them up-to-date, at least? >> >> AFAIK, out of the proposals that we've heard in Atlanta, only one (mutualAuth) has been implemented in a browser, and that was a patch over Firefox 3.5 (current version is 18) > > The FF implementation is available on > . > We're currently implementing the protocol also on Chromium source codes. > > -- > Yutaka OIWA, Ph.D. Leader, Software Reliability Research Group > Research Institute for Secure Systems (RISEC) > 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] -- Yutaka OIWA, Ph.D. Leader, Software Reliability Research Group Research Institute for Secure Systems (RISEC) 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 turners@ieca.com Fri Feb 22 06:57:52 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7534621F86AB for ; Fri, 22 Feb 2013 06:57:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.834 X-Spam-Level: X-Spam-Status: No, score=-100.834 tagged_above=-999 required=5 tests=[AWL=-0.428, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334, 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 bDXWzb9NsVz3 for ; Fri, 22 Feb 2013 06:57:51 -0800 (PST) Received: from gateway02.websitewelcome.com (gateway02.websitewelcome.com [67.18.36.20]) by ietfa.amsl.com (Postfix) with ESMTP id A42AC21F8E64 for ; Fri, 22 Feb 2013 06:57:51 -0800 (PST) Received: by gateway02.websitewelcome.com (Postfix, from userid 5007) id D9EA26BB0EDE2; Fri, 22 Feb 2013 08:57:47 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway02.websitewelcome.com (Postfix) with ESMTP id CEE266BB0EDC2 for ; Fri, 22 Feb 2013 08:57:47 -0600 (CST) Received: from [108.45.16.214] (port=60132 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1U8u4N-0006Qd-6n for http-auth@ietf.org; Fri, 22 Feb 2013 08:57:51 -0600 Message-ID: <5127876E.2090402@ieca.com> Date: Fri, 22 Feb 2013 09:57:50 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: http-auth@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [108.45.16.214]:60132 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 21 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [http-auth] charter status X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 14:57:52 -0000 It should come as no surprise that the IESG had some comments on the charter but maybe it would come as a surprise that there were a couple of blocking comments. I've worked with the members who had blocks and they're okay with the following, which I think has the same intent as what was passed up: https://datatracker.ietf.org/doc/charter-ietf-httpauth/ You can use the history tab to see the changed between what was passed up and the final version up for consideration on next week's telechat. Note that this charter will still need to go out for external review, which means that after the one week external review there's still a chance of being a WG before the session. spt From turners@ieca.com Thu Feb 28 10:26:12 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAA6421F8853 for ; Thu, 28 Feb 2013 10:26:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.027 X-Spam-Level: X-Spam-Status: No, score=-102.027 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 DFZAp7x-o5DV for ; Thu, 28 Feb 2013 10:26:11 -0800 (PST) Received: from gateway05.websitewelcome.com (gateway05.websitewelcome.com [67.18.10.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3558E21F8845 for ; Thu, 28 Feb 2013 10:26:09 -0800 (PST) Received: by gateway05.websitewelcome.com (Postfix, from userid 5007) id CEA018D94F659; Thu, 28 Feb 2013 12:26:08 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway05.websitewelcome.com (Postfix) with ESMTP id B81B08D94F5C3 for ; Thu, 28 Feb 2013 12:26:08 -0600 (CST) Received: from [192.1.48.2] (port=33365 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UB8BE-0006bi-Ka for http-auth@ietf.org; Thu, 28 Feb 2013 12:26:08 -0600 Message-ID: <512FA140.2030403@ieca.com> Date: Thu, 28 Feb 2013 13:26:08 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: http-auth@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [192.1.48.2]:33365 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 5 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [http-auth] status X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 18:26:12 -0000 The charter: https://datatracker.ietf.org/doc/charter-ietf-httpauth/ will be out for external review early next week. Barring any push back, the plan will be to have the WG officially up and running Tuesday morning of IETF week. Working on WG chairs now :) spt