From dev.akhawe@gmail.com Wed Dec 1 11:17:20 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B3063A6C60 for ; Wed, 1 Dec 2010 11:17:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id se423puuUefS for ; Wed, 1 Dec 2010 11:17:19 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 66BE43A6C52 for ; Wed, 1 Dec 2010 11:17:18 -0800 (PST) Received: by wyf23 with SMTP id 23so6415531wyf.31 for ; Wed, 01 Dec 2010 11:18:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=r/nAXRzGV1DCV0uNrtpQqN/BavPXk0E5hFpAT+tnvJM=; b=ocZ9LVQZZ0Y67fC43eJA9SshnFTIOwdx7ifGeBFb3ADgxFe2NRu+FR5kwbkV7LKLdS XJ4wqa0X8ZaygwZvynt9kIv83WSvMTmt2uwX2o6+/enzR4HBAn5NkQ8SQ8Jk5/rSzo5T P3juijs82Vvgtls6EB4g/a1OTCXZyWBDY8dkI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=f8+iWOTfbZvxLVyM6rIvhHY1dbF6N+YyzaeMF4CcGNLl8qwzzSM4IWcR2KEn6LJgt1 d/UvFQKDsz7Ilat+6iAvscYdX+CI6baCUHrF6+s43FxIAB+WzYlxUCms04apudxOmUxG iT3GE14/CEBxgXvv4OAKcz+WcS6JGCVzNi7EQ= Received: by 10.216.90.132 with SMTP id e4mr8078524wef.73.1291231111225; Wed, 01 Dec 2010 11:18:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.86.11 with HTTP; Wed, 1 Dec 2010 11:18:10 -0800 (PST) In-Reply-To: <4CF5F0DA.5090602@it.aoyama.ac.jp> References: <4CF4609E.6090201@extendedsubset.com> <4CF479F0.5070505@extendedsubset.com> <4CF52786.7060907@extendedsubset.com> <5EE049BA3C6538409BBE6F1760F328ABEB18908979@DEN-MEXMS-001.corp.ebay.com> <4CF5684F.9050201@extendedsubset.com> <4CF5F0DA.5090602@it.aoyama.ac.jp> From: Devdatta Akhawe Date: Wed, 1 Dec 2010 11:18:10 -0800 Message-ID: To: =?ISO-8859-1?Q?Martin_J=2E_D=FCrst?= Content-Type: text/plain; charset=ISO-8859-1 Cc: "websec@ietf.org" Subject: Re: [websec] Some questions about HSTS X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2010 19:17:20 -0000 > > There is also a proposal to solve the "hotel problem" on the HTTP level: > http://tools.ietf.org/html/draft-nottingham-http-portal-01 I don't think that works for SSL. From the draft : " This memo does not address non-HTTP applications, such as IMAP, POP or even TLS-encapsulated HTTP" basically, no one can insert a 428 header if you are using SSL, and the hotel won't let you use SSL until you click on 'I agree', but with STS the browser will show a network error if the hotel tries to insert the 'I agree' page into the SSL session, making the user think the hotel Wireless isn't working. cheers devdatta From marsh@extendedsubset.com Wed Dec 1 12:21:35 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67A3F28C0E6 for ; Wed, 1 Dec 2010 12:21:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.447 X-Spam-Level: X-Spam-Status: No, score=-1.447 tagged_above=-999 required=5 tests=[AWL=-1.219, BAYES_00=-2.599, TRACKER_ID=2.003, URI_HEX=0.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpGNpYj4z+cM for ; Wed, 1 Dec 2010 12:21:34 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 647D23A6C8A for ; Wed, 1 Dec 2010 12:21:34 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1PNtCS-0007WJ-D5; Wed, 01 Dec 2010 20:22:48 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 050EE6018; Wed, 1 Dec 2010 20:22:44 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+TtV6xgqhT1uUWQZlEr1+jNKhb6PDvV50= Message-ID: <4CF6AE93.3050309@extendedsubset.com> Date: Wed, 01 Dec 2010 14:22:43 -0600 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10 MIME-Version: 1.0 To: Devdatta Akhawe References: <4CF4609E.6090201@extendedsubset.com> <4CF479F0.5070505@extendedsubset.com> <4CF52786.7060907@extendedsubset.com> <5EE049BA3C6538409BBE6F1760F328ABEB18908979@DEN-MEXMS-001.corp.ebay.com> <4CF5684F.9050201@extendedsubset.com> <4CF5F0DA.5090602@it.aoyama.ac.jp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "websec@ietf.org" Subject: Re: [websec] Some questions about HSTS X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2010 20:21:35 -0000 On 12/01/2010 01:18 PM, Devdatta Akhawe wrote: > > basically, no one can insert a 428 header if you are using SSL, and > the hotel won't let you use SSL until you click on 'I agree', but with > STS the browser will show a network error if the hotel tries to insert > the 'I agree' page into the SSL session, making the user think the > hotel Wireless isn't working. Although it's obviously inappropriate for a user to accept a hotel's certificate for the actual site they requested, at the time the user is looking at the 'scary page' would it be entirely wrong to provide a mechanism for the hotel to provide a tiny bit of info: vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv An intermediate network device is admitting to attempting to intercept your connection. No information about your original web request has been provided to this device other than the protocol and hostname (https://bank.example.com). The intercepting device provides the following information: Entity name: [Luddite Hotel, 123 Obnoxious St., Unwelcomeville, MD] Reason codes: TOS_AGREEMENT_REQUIRED, POSSIBLE_PAYMENT_REQUIRED More information: http://hotelwall-000036.internal.dns/ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Only minimal information is accepted over the untrusted connection. Perhaps just entity name, some codes from a predefined set, and perhaps a hostname (not a full link) for follow up. The error page is considered to have come from an unique and untrusted origin. If there are any links allowed, no 'Referer' header should be sent. If they were standardized, these fields could be communicated in the bogus cert the MitM box presents. Or a proper TLS extension could be made for it. Just an idea, perhaps there have been similar proposals in the past? - Marsh From asteingruebl@paypal-inc.com Wed Dec 1 12:29:34 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD11E28C0FA for ; Wed, 1 Dec 2010 12:29:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.219 X-Spam-Level: X-Spam-Status: No, score=-7.219 tagged_above=-999 required=5 tests=[AWL=1.530, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_HI=-8, URI_HEX=0.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYK-wYa6EKhc for ; Wed, 1 Dec 2010 12:29:33 -0800 (PST) Received: from den-mipot-002.corp.ebay.com (den-mipot-002.corp.ebay.com [216.113.175.153]) by core3.amsl.com (Postfix) with ESMTP id 4E1CD28B56A for ; Wed, 1 Dec 2010 12:29:33 -0800 (PST) DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:CC: Date:Subject:Thread-Topic:Thread-Index:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: x-ems-proccessed:x-ems-stamp:Content-Type: Content-Transfer-Encoding:MIME-Version:X-CFilter; b=fFdwOU3MFlmmtoageiaoWOCxOKABbD7dNHKy9CszVMDNATZzmShu65iX mOX5mzcwjaOAOub+4Hg6POTi3gjmWTgRPBDSkjjk6msaQDBpT1vLPE1SZ aJzYvOE72KX/cio; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=asteingruebl@paypal-inc.com; q=dns/txt; s=ppinc; t=1291235448; x=1322771448; h=from:to:cc:date:subject:message-id:references: in-reply-to:content-transfer-encoding:mime-version; z=From:=20"Steingruebl,=20Andy"=20|To:=20Marsh=20Ray=20,=20D evdatta=20Akhawe=0D=0A=09|CC:=20"we bsec@ietf.org"=20|Date:=20Wed,=201=20Dec =202010=2013:30:46=20-0700|Subject:=20RE:=20[websec]=20So me=20questions=20about=20HSTS|Message-ID:=20<5EE049BA3C65 38409BBE6F1760F328ABEB189E5F98@DEN-MEXMS-001.corp.ebay.co m>|References:=20=0D=0A=09=0D=0A=09=0D=0A=09<4CF4609E.6090201@extend edsubset.com>=0D=0A=09=0D=0A=09<4CF479F0.5070505@ext endedsubset.com>=0D=0A=09=0D=0A=09<4CF52786.7060907@ extendedsubset.com>=0D=0A=09<5EE049BA3C6538409BBE6F1760F3 28ABEB18908979@DEN-MEXMS-001.corp.ebay.com>=0D=0A=09<4CF5 684F.9050201@extendedsubset.com>=09<4CF5F0DA.5090602@it.a oyama.ac.jp>=0D=0A=09=0D=0A=20<4CF6AE93.3050309@exte ndedsubset.com>|In-Reply-To:=20<4CF6AE93.3050309@extended subset.com>|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=OhD21JoU6vtWCqqGZUs39Dp/+NFl6dIq2vWDW4gsED0=; b=sWiRFUr99c2zSPJoW5ZH68FicNcZ27K16Wp7DOFqsj29F1xFofADbxjJ Pc1dctRHOw0x0dBansx3pivlbU/DVDnrV8KTqw9pghou2VfxPdXjzMu06 5uYkSA4/Yx2Vdls; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.59,285,1288594800"; d="scan'208";a="233039" Received: from den-vtenf-001.corp.ebay.com (HELO DEN-MEXHT-002.corp.ebay.com) ([10.101.112.212]) by den-mipot-002.corp.ebay.com with ESMTP; 01 Dec 2010 12:30:47 -0800 Received: from DEN-MEXMS-001.corp.ebay.com ([10.241.16.225]) by DEN-MEXHT-002.corp.ebay.com ([10.241.17.53]) with mapi; Wed, 1 Dec 2010 13:30:46 -0700 From: "Steingruebl, Andy" To: Marsh Ray , Devdatta Akhawe Date: Wed, 1 Dec 2010 13:30:46 -0700 Thread-Topic: [websec] Some questions about HSTS Thread-Index: AcuRlZUiH2CQ2TpDQ+WcsgiNSBNDIwAANHCw Message-ID: <5EE049BA3C6538409BBE6F1760F328ABEB189E5F98@DEN-MEXMS-001.corp.ebay.com> References: <4CF4609E.6090201@extendedsubset.com> <4CF479F0.5070505@extendedsubset.com> <4CF52786.7060907@extendedsubset.com> <5EE049BA3C6538409BBE6F1760F328ABEB18908979@DEN-MEXMS-001.corp.ebay.com> <4CF5684F.9050201@extendedsubset.com> <4CF5F0DA.5090602@it.aoyama.ac.jp> <4CF6AE93.3050309@extendedsubset.com> In-Reply-To: <4CF6AE93.3050309@extendedsubset.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A== x-ems-stamp: 9ys6+gRDXsRnR698gMnWww== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Cc: "websec@ietf.org" Subject: Re: [websec] Some questions about HSTS X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2010 20:29:34 -0000 > -----Original Message----- > From: websec-bounces@ietf.org [mailto:websec-bounces@ietf.org] On > Behalf Of Marsh Ray > vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv >=20 > An intermediate network device is admitting to attempting to intercept yo= ur > connection. No information about your original web request has been > provided to this device other than the protocol and hostname > (https://bank.example.com). >=20 > The intercepting device provides the following information: >=20 > Entity name: [Luddite Hotel, 123 Obnoxious St., Unwelcomeville, MD] Reaso= n > codes: TOS_AGREEMENT_REQUIRED, POSSIBLE_PAYMENT_REQUIRED More > information: http://hotelwall-000036.internal.dns/ It seems to me that a well-defined, completely standard, and handled at a d= ifferent layer of the architecture approach is called for, unfortunately. = I'm sympathetic to the need/desire to do NAC (Network access control) of so= me sort, but I don't think arbitrary connection hijacking is the right way = to do it, and supporting it long terms is a security-UI nightmare. - Andy From dev.akhawe@gmail.com Wed Dec 1 12:52:41 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B13363A6359 for ; Wed, 1 Dec 2010 12:52:41 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12RVh3xQ+bZs for ; Wed, 1 Dec 2010 12:52:40 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 679E73A63CA for ; Wed, 1 Dec 2010 12:52:40 -0800 (PST) Received: by eyd10 with SMTP id 10so4019893eyd.31 for ; Wed, 01 Dec 2010 12:53:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=D7ZvCsVT39jL7XHrcoQBeqWfvUlPvHhexs2CvGFe1iI=; b=CJJBky3//1ZJ9Mpme9vAHXmxgijcsAEZPmS/JNK7aEuH9PSUOrNwQh7beobfMFoHpN xwi7aYWMhwLMA8vWK8ZF1468K7BK+/2rtRm0u1paVf/XmkQzPakmtZTzQ7+Gb7KUrGQ1 MfG/Mj9YSEagrAaW1lGMVF9cdJ37quY+z+sJM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=rqOs/zR2tIKgBDiVyYYZPZ1EjoPaxDWqwZzP7izedi8UvK0BZeZ/npXVbKATraXYeQ hXPAjflyykinnP6oC73yCzxoRz9j0ZnhuOakKphPFvCoxw8Y3FmbCaftzR5oA1nMoSeZ 6givSkiYkS8BUypTbUWnuQLjwAxNj/jena3is= Received: by 10.216.161.147 with SMTP id w19mr8218867wek.88.1291236833662; Wed, 01 Dec 2010 12:53:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.86.11 with HTTP; Wed, 1 Dec 2010 12:53:33 -0800 (PST) In-Reply-To: <5EE049BA3C6538409BBE6F1760F328ABEB189E5F98@DEN-MEXMS-001.corp.ebay.com> References: <4CF4609E.6090201@extendedsubset.com> <4CF479F0.5070505@extendedsubset.com> <4CF52786.7060907@extendedsubset.com> <5EE049BA3C6538409BBE6F1760F328ABEB18908979@DEN-MEXMS-001.corp.ebay.com> <4CF5684F.9050201@extendedsubset.com> <4CF5F0DA.5090602@it.aoyama.ac.jp> <4CF6AE93.3050309@extendedsubset.com> <5EE049BA3C6538409BBE6F1760F328ABEB189E5F98@DEN-MEXMS-001.corp.ebay.com> From: Devdatta Akhawe Date: Wed, 1 Dec 2010 12:53:33 -0800 Message-ID: To: "Steingruebl, Andy" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "websec@ietf.org" Subject: Re: [websec] Some questions about HSTS X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2010 20:52:41 -0000 > It seems to me that a well-defined, completely standard, and handled at a= different layer of the architecture approach is called for, unfortunately.= =A0I'm sympathetic to the need/desire to do NAC (Network access control) o= f some sort, but I don't think arbitrary connection hijacking is the right = way to do it, and supporting it long terms is a security-UI nightmare. > +1 I was just saying that the HTTP level solution in the RFC seems wrong - the issue they are trying to solve is 'network access' which is lower down than HTTP. Unfortunately, HTTP =3D=3D network many a times (for example in hotels, cafe etc). cheers devdatta > - Andy > From marsh@extendedsubset.com Wed Dec 1 13:07:32 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 277933A6452 for ; Wed, 1 Dec 2010 13:07:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-4A01pfRcoB for ; Wed, 1 Dec 2010 13:07:31 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 3F9753A6358 for ; Wed, 1 Dec 2010 13:07:31 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1PNtuv-000Oj3-Am; Wed, 01 Dec 2010 21:08:45 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id B94F76018; Wed, 1 Dec 2010 21:08:43 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+b0wc/e+FhQPG6v2x3pGW9xCLWwZ6t3eg= Message-ID: <4CF6B95A.8060400@extendedsubset.com> Date: Wed, 01 Dec 2010 15:08:42 -0600 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10 MIME-Version: 1.0 To: Devdatta Akhawe References: <4CF4609E.6090201@extendedsubset.com> <4CF479F0.5070505@extendedsubset.com> <4CF52786.7060907@extendedsubset.com> <5EE049BA3C6538409BBE6F1760F328ABEB18908979@DEN-MEXMS-001.corp.ebay.com> <4CF5684F.9050201@extendedsubset.com> <4CF5F0DA.5090602@it.aoyama.ac.jp> <4CF6AE93.3050309@extendedsubset.com> <5EE049BA3C6538409BBE6F1760F328ABEB189E5F98@DEN-MEXMS-001.corp.ebay.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "websec@ietf.org" Subject: Re: [websec] Some questions about HSTS X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Dec 2010 21:07:32 -0000 On 12/01/2010 02:53 PM, Devdatta Akhawe wrote: >> It seems to me that a well-defined, completely standard, and >> handled at a different layer of the architecture approach is called >> for, unfortunately. I'm sympathetic to the need/desire to do NAC >> (Network access control) of some sort, but I don't think arbitrary >> connection hijacking is the right way to do it, and supporting it >> long terms is a security-UI nightmare. > > +1 > > I was just saying that the HTTP level solution in the RFC seems > wrong - the issue they are trying to solve is 'network access' which > is lower down than HTTP. Unfortunately, HTTP == network many a times > (for example in hotels, cafe etc). (+1)^2 I agree with both of you. I don't like talking about a "good way" to do this because I think it's something that shouldn't need to be done (in general). I think it's already over-used and making a simple 'on' switch for this kind of feature is just going to cause people to turn it on unnecessarily even more often. But we cannot ignore the counter argument: It's already being done. All the darn time. Badly. In ways that are breaking our stuff. And putting at risk new stuff (like HSTS). - Marsh From paul.hoffman@vpnc.org Thu Dec 2 10:01:03 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBC2828C11A for ; Thu, 2 Dec 2010 10:01:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.056 X-Spam-Level: X-Spam-Status: No, score=-100.056 tagged_above=-999 required=5 tests=[AWL=-0.610, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQOJqhyuD5Bz for ; Thu, 2 Dec 2010 10:01:03 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 2ADF128C0EE for ; Thu, 2 Dec 2010 10:01:03 -0800 (PST) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id oB2I2H07099703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Dec 2010 11:02:18 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4CF5B5B7.50604@KingsMountain.com> References: <4CF5B5B7.50604@KingsMountain.com> Date: Thu, 2 Dec 2010 10:02:15 -0800 To: =JeffH , IETF WebSec WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [websec] Another way to look at announcing strict security X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2010 18:01:03 -0000 Based on some off-line comments, I have updated the draft: . The changes are clarifying the problemn statement in the abstract, fixing a bad goof in the description of CSO, a statement that it covers TLS over other transports and DTLS, and a couple of editorial nits. --Paul Hoffman, Director --VPN Consortium From tobias.gondrom@gondrom.org Thu Dec 9 10:27:56 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3CA43A6958 for ; Thu, 9 Dec 2010 10:27:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.459 X-Spam-Level: X-Spam-Status: No, score=-94.459 tagged_above=-999 required=5 tests=[AWL=-0.555, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJhjxL0Vcw1U for ; Thu, 9 Dec 2010 10:27:50 -0800 (PST) Received: from lvps83-169-7-107.dedicated.hosteurope.de (lvps83-169-7-107.dedicated.hosteurope.de [83.169.7.107]) by core3.amsl.com (Postfix) with ESMTP id 27F063A6980 for ; Thu, 9 Dec 2010 10:27:47 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=gN4J6FcDDIbkbBQv74Nyf8lI8afceS0fAdzhYueNBKDLCh7vdftJGnljeRrp37m8Bd2krK61JVoJE85Y9Zz513VTIJTA8D3onhlQUPgilm2xNeADza5Yy0V692pwwI+Z; h=Received:Received:Message-ID:Disposition-Notification-To:Date:From:User-Agent:MIME-Version:To:Subject:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; Received: (qmail 24384 invoked from network); 9 Dec 2010 19:28:21 +0100 Received: from 94-194-102-93.zone8.bethere.co.uk (HELO seraphim.heaven) (94.194.102.93) by lvps83-169-7-107.dedicated.hosteurope.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 9 Dec 2010 19:28:21 +0100 Message-ID: <4D01201E.8000007@gondrom.org> Date: Thu, 09 Dec 2010 18:29:50 +0000 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101026 SUSE/3.1.6 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: websec X-Enigmail-Version: 1.1.1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [websec] request for feedback on adoption of drafts to WG - until Dec-16 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2010 18:27:56 -0000 Hello dear fellow websec members,

during the hasmat BOF in July and the websec charter consensus three individual drafts were listed as to be worked on as first items in our working group. I did so far not formally ask for WG consensus on adopting these three documents until now; our area director suggested that it would be appropriate to do so before they are re-submitted as working group drafts.

So I would like to ask for your feedback on adopting the following three individual drafts as WG documents (as outlined in the charter):

- draft-abarth-origin:
http://tools.ietf.org/tools/rfcmarkup/rfcmarkup.cgi?draft=draft-abarth-origin
   
- hodges-strict-transport-sec:
  http://tools.ietf.org/tools/rfcmarkup/rfcmarkup.cgi?draft=draft-hodges-strict-transport-sec

- draft-abarth-mime-sniff:
http://tools.ietf.org/tools/rfcmarkup/rfcmarkup.cgi?draft=draft-abarth-mime-sniff

Please reply ("yes" (for adoption) or "no" (against adoption), both are important) - either for each draft individually or for all three drafts as a bundle - to the list by Thurs 16th December 2010 (24:00GMT).

Kind regards and thanks a lot,

Tobias
chair of websec


From ietf@adambarth.com Thu Dec 9 10:45:43 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B13D28C141 for ; Thu, 9 Dec 2010 10:45:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[AWL=-1.021, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RrHJ83VGn7w1 for ; Thu, 9 Dec 2010 10:45:39 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 78CD028C132 for ; Thu, 9 Dec 2010 10:45:39 -0800 (PST) Received: by vws7 with SMTP id 7so1857219vws.31 for ; Thu, 09 Dec 2010 10:47:09 -0800 (PST) Received: by 10.220.179.73 with SMTP id bp9mr2341730vcb.216.1291920426971; Thu, 09 Dec 2010 10:47:06 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id g27sm833958vby.14.2010.12.09.10.47.05 (version=SSLv3 cipher=RC4-MD5); Thu, 09 Dec 2010 10:47:05 -0800 (PST) Received: by iyi42 with SMTP id 42so73040iyi.31 for ; Thu, 09 Dec 2010 10:47:05 -0800 (PST) Received: by 10.231.156.1 with SMTP id u1mr610275ibw.52.1291920424907; Thu, 09 Dec 2010 10:47:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.36.197 with HTTP; Thu, 9 Dec 2010 10:46:34 -0800 (PST) In-Reply-To: <4D01201E.8000007@gondrom.org> References: <4D01201E.8000007@gondrom.org> From: Adam Barth Date: Thu, 9 Dec 2010 10:46:34 -0800 Message-ID: To: Tobias Gondrom Content-Type: text/plain; charset=ISO-8859-1 Cc: websec Subject: Re: [websec] request for feedback on adoption of drafts to WG - until Dec-16 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2010 18:45:43 -0000 Yes for all three (but I'm probably biased). Adam On Thu, Dec 9, 2010 at 10:29 AM, Tobias Gondrom wrote: > Hello dear fellow websec members, > > during the hasmat BOF in July and the websec charter consensus three > individual drafts were listed as to be worked on as first items in our > working group. I did so far not formally ask for WG consensus on adopting > these three documents until now; our area director suggested that it would > be appropriate to do so before they are re-submitted as working group > drafts. > > So I would like to ask for your feedback on adopting the following three > individual drafts as WG documents (as outlined in the charter): > > - draft-abarth-origin: > http://tools.ietf.org/tools/rfcmarkup/rfcmarkup.cgi?draft=draft-abarth-origin > > - hodges-strict-transport-sec: > > http://tools.ietf.org/tools/rfcmarkup/rfcmarkup.cgi?draft=draft-hodges-strict-transport-sec > > - draft-abarth-mime-sniff: > http://tools.ietf.org/tools/rfcmarkup/rfcmarkup.cgi?draft=draft-abarth-mime-sniff > > Please reply ("yes" (for adoption) or "no" (against adoption), both are > important) - either for each draft individually or for all three drafts as a > bundle - to the list by Thurs 16th December 2010 (24:00GMT). > > Kind regards and thanks a lot, > > Tobias > chair of websec > > > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > > From g.koppen@jondos.de Thu Dec 9 12:03:54 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA98828C0E4 for ; Thu, 9 Dec 2010 12:03:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, SARE_BAYES_5x8=0.8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GiqFx8CeRWmO for ; Thu, 9 Dec 2010 12:03:52 -0800 (PST) Received: from mail.jondos.de (mail.jondos.de [78.129.167.163]) by core3.amsl.com (Postfix) with ESMTP id 1EDFD3A6BBA for ; Thu, 9 Dec 2010 12:03:52 -0800 (PST) Received: from [85.226.81.209] (helo=[192.168.1.66]) by mail.jondos.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1PQmjv-0008AS-NW for websec@ietf.org; Thu, 09 Dec 2010 21:05:21 +0100 Message-ID: <4D013679.2040108@jondos.de> Date: Thu, 09 Dec 2010 21:05:13 +0100 From: Georg Koppen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10 MIME-Version: 1.0 To: websec@ietf.org References: <4D01201E.8000007@gondrom.org> In-Reply-To: <4D01201E.8000007@gondrom.org> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 85.226.81.209 X-SA-Exim-Mail-From: g.koppen@jondos.de X-SA-Exim-Version: 4.2.1 (built Wed, 25 Jun 2008 17:14:11 +0000) X-SA-Exim-Scanned: Yes (on mail.jondos.de) X-Mailman-Approved-At: Thu, 09 Dec 2010 12:49:48 -0800 Subject: Re: [websec] request for feedback on adoption of drafts to WG - until Dec-16 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2010 20:03:54 -0000 Yes for all three. Georg > Hello dear fellow websec members, > > during the hasmat BOF in July and the websec charter consensus three individual > drafts were listed as to be worked on as first items in our working group. I did > so far not formally ask for WG consensus on adopting these three documents until > now; our area director suggested that it would be appropriate to do so before > they are re-submitted as working group drafts. > > So I would like to ask for your feedback on adopting the following three > individual drafts as WG documents (as outlined in the charter): > > - draft-abarth-origin: > http://tools.ietf.org/tools/rfcmarkup/rfcmarkup.cgi?draft=draft-abarth-origin > > - hodges-strict-transport-sec: > http://tools.ietf.org/tools/rfcmarkup/rfcmarkup.cgi?draft=draft-hodges-strict-transport-sec > > - draft-abarth-mime-sniff: > http://tools.ietf.org/tools/rfcmarkup/rfcmarkup.cgi?draft=draft-abarth-mime-sniff > > Please reply ("yes" (for adoption) or "no" (against adoption), both are > important) - either for each draft individually or for all three drafts as a > bundle - to the list by Thurs 16th December 2010 (24:00GMT). > > Kind regards and thanks a lot, > > Tobias > chair of websec > > > > > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec -- eMail: g.koppen@jondos.de PGP/GPG: 0xD936B338 Jabber: groeg@jabber.org OTR-Abdruck: 35446001 20BCBE89 29A239E8 EA937FE2 7241A520 JonDos GmbH Firmensitz: Bruderwöhrdstraße 15b, 93055 Regensburg Registergericht: Amtsgericht Regensburg, HRB 10532 Umsatzsteuer-Identifikationsnummer: DE814839010 Geschäftsführer: Rolf Wendolsky, Thomas Dumler From paul.hoffman@vpnc.org Thu Dec 9 13:11:22 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B41F33A6BDD for ; Thu, 9 Dec 2010 13:11:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.457 X-Spam-Level: X-Spam-Status: No, score=-101.457 tagged_above=-999 required=5 tests=[AWL=0.589, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRme1z1DTPw1 for ; Thu, 9 Dec 2010 13:11:18 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id A8A713A6BDA for ; Thu, 9 Dec 2010 13:11:17 -0800 (PST) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id oB9LChWG048999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Dec 2010 14:12:45 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4D01201E.8000007@gondrom.org> References: <4D01201E.8000007@gondrom.org> Date: Thu, 9 Dec 2010 13:12:42 -0800 To: Tobias Gondrom , websec From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [websec] request for feedback on adoption of drafts to WG - until Dec-16 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Dec 2010 21:11:22 -0000 At 6:29 PM +0000 12/9/10, Tobias Gondrom wrote: >- draft-abarth-origin: Yes >- hodges-strict-transport-sec: Not yet. The semantics are too limited, so far. I proposed a wider set of semantics (one that matches those in draft-hodges-strict-transport-sec plus more real-world policies), and Jeff seemed to like it. Incorporating those semantics could make hodges-strict-transport-sec both more useful and more concise. >- draft-abarth-mime-sniff: Yes --Paul Hoffman, Director --VPN Consortium From annevk@opera.com Fri Dec 10 02:59:46 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 890F83A68C0 for ; Fri, 10 Dec 2010 02:59:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.216 X-Spam-Level: X-Spam-Status: No, score=-7.216 tagged_above=-999 required=5 tests=[AWL=-0.617, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxfS6fS1M0qR for ; Fri, 10 Dec 2010 02:59:45 -0800 (PST) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id 5960F3A6824 for ; Fri, 10 Dec 2010 02:59:44 -0800 (PST) Received: from anne-van-kesterens-macbook-pro.local (pat-tdc.opera.com [213.236.208.22]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id oBAB1DYd018044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 10 Dec 2010 11:01:13 GMT Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Tobias Gondrom" , "Adam Barth" References: <4D01201E.8000007@gondrom.org> Date: Fri, 10 Dec 2010 12:01:13 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Anne van Kesteren" Organization: Opera Software Message-ID: In-Reply-To: User-Agent: Opera Mail/11.00 (MacIntel) X-Scanned-By: MIMEDefang 2.64 on 213.236.208.81 Cc: websec Subject: Re: [websec] request for feedback on adoption of drafts to WG - until Dec-16 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2010 10:59:46 -0000 On Thu, 09 Dec 2010 19:46:34 +0100, Adam Barth wrote: > Yes for all three (but I'm probably biased). Seconded (somewhat less biased). -- Anne van Kesteren http://annevankesteren.nl/ From ynir@checkpoint.com Fri Dec 10 04:01:25 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6535428C0D7 for ; Fri, 10 Dec 2010 04:01:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.252 X-Spam-Level: X-Spam-Status: No, score=-9.252 tagged_above=-999 required=5 tests=[AWL=1.347, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jzaqWZqnzsVW for ; Fri, 10 Dec 2010 04:01:24 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 4F68A28C0D0 for ; Fri, 10 Dec 2010 04:01:24 -0800 (PST) X-CheckPoint: {4D0216EE-0-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id oBAC2sC6029516 for ; Fri, 10 Dec 2010 14:02:54 +0200 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 10 Dec 2010 14:02:53 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Fri, 10 Dec 2010 14:02:53 +0200 From: Yoav Nir To: websec Date: Fri, 10 Dec 2010 14:02:51 +0200 Thread-Topic: [websec] request for feedback on adoption of drafts to WG - until Dec-16 Thread-Index: AcuYYiv/QSv5nSGjTVq0+0IFAaM0Pw== Message-ID: <837C2251-B19B-498B-B8DC-75EE3776E93E@checkpoint.com> References: <4D01201E.8000007@gondrom.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [websec] request for feedback on adoption of drafts to WG - until Dec-16 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2010 12:01:25 -0000 Yes to all three. On Dec 10, 2010, at 1:01 PM, Anne van Kesteren wrote: > On Thu, 09 Dec 2010 19:46:34 +0100, Adam Barth wrote= : >> Yes for all three (but I'm probably biased). >=20 > Seconded (somewhat less biased). >=20 From tobias.gondrom@gondrom.org Fri Dec 10 13:19:21 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81BCA3A6CC2 for ; Fri, 10 Dec 2010 13:19:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.397 X-Spam-Level: X-Spam-Status: No, score=-94.397 tagged_above=-999 required=5 tests=[AWL=-0.493, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9TrujKW6GMpo for ; Fri, 10 Dec 2010 13:19:20 -0800 (PST) Received: from lvps83-169-7-107.dedicated.hosteurope.de (lvps83-169-7-107.dedicated.hosteurope.de [83.169.7.107]) by core3.amsl.com (Postfix) with ESMTP id 02ABF3A6BB1 for ; Fri, 10 Dec 2010 13:19:19 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=ioSrjmwwEjPWIs5Nylveh0HubhfGxM6c2jaypRaEQSOd7vIRuMA5wiqUBxMQ1MAkIsrMK5miY2c+jInw57Dbvhb85CG4zQVbH74C1W2AXhslHn6Lv6vTbZMgs8TOy8Rh; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; Received: (qmail 32680 invoked from network); 10 Dec 2010 22:20:05 +0100 Received: from 94-194-102-93.zone8.bethere.co.uk (HELO seraphim.heaven) (94.194.102.93) by lvps83-169-7-107.dedicated.hosteurope.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 10 Dec 2010 22:20:05 +0100 Message-ID: <4D0299DE.30703@gondrom.org> Date: Fri, 10 Dec 2010 21:21:34 +0000 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101026 SUSE/3.1.6 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: websec X-Enigmail-Version: 1.1.1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [websec] IETF-79 (Beijing) meeting minutes posted X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2010 21:19:21 -0000 FYI: Please find our meeting minutes posted here (and sorry for the delay, which is totally my fault):
http://www.ietf.org/proceedings/79/minutes/websec.txt
Please ping me regarding any corrections.

And a thousand thanks to Paul Hoffman for taking notes!

Tobias
chair of websec


Ps.: btw. all presentation slides and agenda are there of course as well, already since our meeting in Beijing (and unchanged since then): https://datatracker.ietf.org/meeting/79/materials.html#wg-websec
And the recorded audio stream can be found here: http://www.ietf.org/audio/ietf79/ietf79-ch7-tue-noon.mp3

From stpeter@stpeter.im Fri Dec 10 14:52:28 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E28328C160; Fri, 10 Dec 2010 14:52:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pooBEj5tHnYh; Fri, 10 Dec 2010 14:52:27 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 5CB8428C0F3; Fri, 10 Dec 2010 14:52:24 -0800 (PST) Received: from dhcp-64-101-72-173.cisco.com (dhcp-64-101-72-173.cisco.com [64.101.72.173]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 69D59400F6; Fri, 10 Dec 2010 16:05:59 -0700 (MST) Message-ID: <4D02AF81.6000907@stpeter.im> Date: Fri, 10 Dec 2010 15:53:53 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: http-auth@ietf.org X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010603010501000706070400" Cc: "kitten@ietf.org" , websec@ietf.org, saag@ietf.org, "apps-discuss@ietf.org" , "ietf-http-wg@w3.org Group" Subject: [websec] HTTP authentication: the next generation X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2010 22:52:28 -0000 This is a cryptographically signed message in MIME format. --------------ms010603010501000706070400 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Is it time to start thinking about next-generation authentication technologies for HTTP? We all know that BASIC and DIGEST are ancient and crufty and lacking many features and security properties we might want, but there hasn't been much discussion about more modern approaches. Here are a few things I've found: 1. Way back in 2001, Keith Burdis wrote an I-D about upgrading to SASL within HTTP: http://tools.ietf.org/id/draft-burdis-http-sasl-00.txt 2. In 2007, Robert Sayre put together a few slides on the topic: http://people.mozilla.com/~sayrer/2007/auth.html 3. Yutaka Oiwa and his colleagues have been working on a protocol for mutual auth: http://tools.ietf.org/html/draft-oiwa-http-mutualauth-08 Other than that, I'm not aware of much activity. What have I missed? Does it make sense to perhaps hold an exploratory BoF at the next IETF meeting (Prague, March 2011) to get people thinking about this topic? If you're interested, please discuss on the http-auth@ietf.org list: https://www.ietf.org/mailman/listinfo/http-auth Thanks! Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms010603010501000706070400 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTIx MDIyNTM1M1owIwYJKoZIhvcNAQkEMRYEFEc4/NVCfSwpT+QNDvCgpHSbEhzeMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQArS8iF6UaxjKPP8ZrqY92kvXQSzbAWneUkedNjKuuEe+NjbnMcEyOJKrEL JQ6vyvnJcH8alEuqqtib17GOLwhc9gZ91SrgglZw/tcmCGLop3wCZX1bLxWBgCGwKpV4YOHU UqFh+TiUA4zJ2xZgx97JdozaI93e/4r4fLHUOfQkmh9i6XiFK98MZJtprN7evEQSSz+J31Mg vH9Qk3lOdITQhaXYoPCiJY7UPJopWHIs8jsBsdAUDptcrR6QpEdgx4y8D6UY/xQUfS4ifFHR 6Vaqs4gELB0xUoaB0ICY9s8rRdLdWDM+hCxRETfM7Mh8RECSUmKr4LE80SvA+0ChR5vkAAAA AAAA --------------ms010603010501000706070400-- From mnot@mnot.net Fri Dec 10 15:04:36 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EDF328C171; Fri, 10 Dec 2010 15:04:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.583 X-Spam-Level: X-Spam-Status: No, score=-104.583 tagged_above=-999 required=5 tests=[AWL=-1.984, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9qujG0fX4XH; Fri, 10 Dec 2010 15:04:35 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by core3.amsl.com (Postfix) with ESMTP id 9199D28C170; Fri, 10 Dec 2010 15:04:34 -0800 (PST) Received: from chancetrain-lm.mnot.net (unknown [118.209.2.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id B455722E1EB; Fri, 10 Dec 2010 18:06:03 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <4D02AF81.6000907@stpeter.im> Date: Sat, 11 Dec 2010 10:06:00 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <52E9BD81-E64B-47DA-83FC-C820B15D8B18@mnot.net> References: <4D02AF81.6000907@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1082) Cc: "apps-discuss@ietf.org" , websec@ietf.org, "kitten@ietf.org" , http-auth@ietf.org, saag@ietf.org, "ietf-http-wg@w3.org Group" Subject: Re: [websec] [apps-discuss] HTTP authentication: the next generation X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2010 23:04:36 -0000 There was a very well-attended and wide-ranging bar BoF in Vancouver, = and lots of background discussion (/noise). My impression at that point was that the use cases that people wanted to = put into scope were so diverse, and the requirements so exacting, that = it was a non-starter.=20 That may still be the case, and I think that without a concrete target, = starting the discussion again will ultimately just waste a lot of = engineer hours*. Having said that -- since we now have OAuth shaving off some of those = use cases, it may be that a purely browsing-focused authentication = mechanism might be able to get traction, provided we can get browser = vendors on board (naturally). I'd expect them to instigate this, = however. Cheers, * Waste, of course, is subjective. A cynical person would think that the = opportunity cost of having a bunch of standards people working on = something non-productive could, in the end, be a useful diversion. = However, I'm not that person, because I'm not thinking it, I'm saying = it. But I digress. On 11/12/2010, at 9:53 AM, Peter Saint-Andre wrote: > Is it time to start thinking about next-generation authentication > technologies for HTTP? >=20 > We all know that BASIC and DIGEST are ancient and crufty and lacking > many features and security properties we might want, but there hasn't > been much discussion about more modern approaches. Here are a few = things > I've found: >=20 > 1. Way back in 2001, Keith Burdis wrote an I-D about upgrading to SASL > within HTTP: http://tools.ietf.org/id/draft-burdis-http-sasl-00.txt >=20 > 2. In 2007, Robert Sayre put together a few slides on the topic: > http://people.mozilla.com/~sayrer/2007/auth.html >=20 > 3. Yutaka Oiwa and his colleagues have been working on a protocol for > mutual auth: http://tools.ietf.org/html/draft-oiwa-http-mutualauth-08 >=20 > Other than that, I'm not aware of much activity. What have I missed? > Does it make sense to perhaps hold an exploratory BoF at the next IETF > meeting (Prague, March 2011) to get people thinking about this topic? >=20 > If you're interested, please discuss on the http-auth@ietf.org list: >=20 > https://www.ietf.org/mailman/listinfo/http-auth >=20 > Thanks! >=20 > Peter >=20 > --=20 > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ From paul.hoffman@vpnc.org Fri Dec 10 15:08:11 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E792D28C176; Fri, 10 Dec 2010 15:08:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.456 X-Spam-Level: X-Spam-Status: No, score=-101.456 tagged_above=-999 required=5 tests=[AWL=0.590, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vA2caBcrvZhs; Fri, 10 Dec 2010 15:08:10 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 2D28428C170; Fri, 10 Dec 2010 15:08:10 -0800 (PST) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id oBAN9eKg012365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Dec 2010 16:09:42 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4D02AF81.6000907@stpeter.im> References: <4D02AF81.6000907@stpeter.im> Date: Fri, 10 Dec 2010 15:09:39 -0800 To: Peter Saint-Andre , http-auth@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: "kitten@ietf.org" , websec@ietf.org, saag@ietf.org, "apps-discuss@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [websec] [saag] HTTP authentication: the next generation X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2010 23:08:11 -0000 At 3:53 PM -0700 12/10/10, Peter Saint-Andre wrote: >Other than that, I'm not aware of much activity. What have I missed? TLS client certificates. --Paul Hoffman, Director --VPN Consortium From marsh@extendedsubset.com Fri Dec 10 15:52:59 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C52628C16B; Fri, 10 Dec 2010 15:52:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3T0nlJOeG43h; Fri, 10 Dec 2010 15:52:58 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 6FEB928C13D; Fri, 10 Dec 2010 15:52:58 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1PRCnG-0007jy-Mx; Fri, 10 Dec 2010 23:54:30 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id BC33060C7; Fri, 10 Dec 2010 23:54:28 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/98GPaWAVDLHrWGRfLI2yC8jrjm0RWGOw= Message-ID: <4D02BDB3.7060801@extendedsubset.com> Date: Fri, 10 Dec 2010 17:54:27 -0600 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10 MIME-Version: 1.0 To: Peter Saint-Andre References: <4D02AF81.6000907@stpeter.im> In-Reply-To: <4D02AF81.6000907@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" , websec@ietf.org, "kitten@ietf.org" , http-auth@ietf.org, saag@ietf.org, "ietf-http-wg@w3.org Group" Subject: Re: [websec] HTTP authentication: the next generation X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2010 23:52:59 -0000 On 12/10/2010 04:53 PM, Peter Saint-Andre wrote: > Is it time to start thinking about next-generation authentication > technologies for HTTP? No? :-) IMHO, authentication just doesn't belong at the HTTP layer. HTTP is inherently bad at being stateful. Stateless interfaces can be fantastic, but it doesn't support the "login session" concept that most people have in mind when they talk about authentication. Unless you're properly using TLS, you have no reason to believe that the byte you just received is from the same party as the previous byte you received. So under those circumstances, what exactly are you authenticating, and to whom? I use a lot of web sites and none of them do authentication via HTTP. Every single one of them expects a username/password via HTTP(s) POST variables and returns a cookie of varying duration. But what could we possibly do for a stateless, unMACed protocol like HTTP, except integrate and bind it better with a lower layer providing real integrity? I think what the world needs are ways for web apps (literally, the Ruby code) to easily work with the strongly-authenticated identities which are supported at the TLS layer. TLS already supports "sessions" and "client authentication", but for whatever reasons they're not being utilized. We should make using those facilities as easy for web developers as doing cookie-based logins. Improving the "authentication" for a protocol lacking basic message integrity would just be giving a false sense of security. It's like improving the login authentication for telnet or FTP sessions. But I do think there are lots of improvements waiting to be made in the right directions. - Marsh From Jeff.Hodges@KingsMountain.com Fri Dec 10 17:20:49 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C944C28C11A for ; Fri, 10 Dec 2010 17:20:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.937 X-Spam-Level: X-Spam-Status: No, score=-101.937 tagged_above=-999 required=5 tests=[AWL=0.328, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UeHfQheMT4mU for ; Fri, 10 Dec 2010 17:20:47 -0800 (PST) Received: from oproxy3-pub.bluehost.com (oproxy3-pub.bluehost.com [69.89.21.8]) by core3.amsl.com (Postfix) with SMTP id A8FD728C102 for ; Fri, 10 Dec 2010 17:20:47 -0800 (PST) Received: (qmail 30709 invoked by uid 0); 11 Dec 2010 01:22:20 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy3.bluehost.com with SMTP; 11 Dec 2010 01:22:20 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=dx6Kq2u4fGqUUxnrxy1R0XuF16QKyvyjXShdBhVC7P9Usy0JaCNxcKeJvj8YdAf5VV69QsG0J1cErtoi7C9qdiU4ES8R5HLkYVSeB1GHN6gUlIUFAysTDxRaclkwuSz0; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.136.42]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1PREAF-0005Mc-Nw for websec@ietf.org; Fri, 10 Dec 2010 18:22:19 -0700 Message-ID: <4D02D24A.1060705@KingsMountain.com> Date: Fri, 10 Dec 2010 17:22:18 -0800 From: =JeffH User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: IETF WebSec WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: Re: [websec] request for feedback on adoption of drafts to WG - until Dec-16 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2010 01:20:49 -0000 Yes for all three (but I am biased). Paul's suggestion wrt incorporating the semantic notions from draft-hoffman-server-has-tls is noted and I'll see what is approp to incorp. But I don't think that should necessarily the gate WG adoption step (I'll look into it in any case). thanks, =JeffH From Jeff.Hodges@KingsMountain.com Fri Dec 10 17:23:01 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65A9B28C11A for ; Fri, 10 Dec 2010 17:23:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.973 X-Spam-Level: X-Spam-Status: No, score=-101.973 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qv9Vr+v3Sysh for ; Fri, 10 Dec 2010 17:23:00 -0800 (PST) Received: from oproxy3-pub.bluehost.com (oproxy3-pub.bluehost.com [69.89.21.8]) by core3.amsl.com (Postfix) with SMTP id 793AE28C102 for ; Fri, 10 Dec 2010 17:23:00 -0800 (PST) Received: (qmail 3647 invoked by uid 0); 11 Dec 2010 01:24:33 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy3.bluehost.com with SMTP; 11 Dec 2010 01:24:33 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=Y3FOpxg+Qur5tDbF4tDWtt8TgD1I8IAtKL0BgKo7R/wNoCV/Io/BmadFXrfbwncaVN9xltWNGGDt+s+C+iBS/lY5zMUqEH/YU1ha3PAbUKFZ4v2TBbfi4+ABHnHbCFBW; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.136.42]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1PRECP-0007O8-1W; Fri, 10 Dec 2010 18:24:33 -0700 Message-ID: <4D02D2D0.6030100@KingsMountain.com> Date: Fri, 10 Dec 2010 17:24:32 -0800 From: =JeffH User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Tobias Gondrom Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Cc: IETF WebSec WG Subject: Re: [websec] IETF-79 (Beijing) meeting minutes posted X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2010 01:23:01 -0000 > FYI: Please find our meeting minutes posted here (and sorry for the delay, > which is totally my fault): > http://www.ietf.org/proceedings/79/minutes/websec.txt Please ping me > regarding any corrections. > > And a thousand thanks to Paul Hoffman for taking notes! > > Tobias chair of websec > > > Ps.: btw. all presentation slides and agenda are there of course as well, > already since our meeting in Beijing (and unchanged since then): > https://datatracker.ietf.org/meeting/79/materials.html#wg-websec And the > recorded audio stream can be found here: > http://www.ietf.org/audio/ietf79/ietf79-ch7-tue-noon.mp3 Thanks for getting those posted! =JeffH From hotz@jpl.nasa.gov Fri Dec 10 18:58:26 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAA253A6C0C; Fri, 10 Dec 2010 18:58:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id slildIl8V3MP; Fri, 10 Dec 2010 18:58:25 -0800 (PST) Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.109]) by core3.amsl.com (Postfix) with ESMTP id E18AF3A68B6; Fri, 10 Dec 2010 18:58:25 -0800 (PST) Received: from laphotz.jpl.nasa.gov (laphotz.jpl.nasa.gov [128.149.133.44]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.3) with ESMTP id oBB2xo8u016846 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Fri, 10 Dec 2010 18:59:57 -0800 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: "Henry B. Hotz" In-Reply-To: <4D02AF81.6000907@stpeter.im> Date: Fri, 10 Dec 2010 18:59:49 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D02AF81.6000907@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1081) X-Source-IP: laphotz.jpl.nasa.gov [128.149.133.44] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized X-Mailman-Approved-At: Sat, 11 Dec 2010 03:29:31 -0800 Cc: "apps-discuss@ietf.org" , "websec@ietf.org" , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [websec] [saag] HTTP authentication: the next generation X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2010 02:58:26 -0000 On Dec 10, 2010, at 2:53 PM, Peter Saint-Andre wrote: > Is it time to start thinking about next-generation authentication > technologies for HTTP? > 1. Way back in 2001, Keith Burdis wrote an I-D about upgrading to SASL > within HTTP: http://tools.ietf.org/id/draft-burdis-http-sasl-00.txt I think http://tools.ietf.org/html/draft-williams-tls-app-sasl-opt-04 is = the most recent iteration on the concept. This is at the TLS layer, not = the http layer. As Paul Hoffman said, X.509 client cert's. In fact one could argue = that's the traditional solution and that software support is already = widely available. Some organizations make this more practical by = issuing the client certs with KX509. = http://tools.ietf.org/search/draft-hotz-kx509-01 (-; Comments are still = desired! ;-) http://tools.ietf.org/html/rfc4559 (Microsoft's HTTP-Negotiate) Note = that W7/2K8 add channel binding to that, but it's an incompatible = upgrade, so it may not get the use it should. There is also active work in the abfab wg which is related. Please try = to synergise, not compete with that work. SAML Web-sso ---- IMO there are already enough options which don't do channel binding with = the enclosing TLS session. I believe any solution you propose should = either do that, or should operate as part of TLS itself. ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From Nicolas.Williams@oracle.com Fri Dec 10 21:20:35 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ED453A6CD6; Fri, 10 Dec 2010 21:20:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.536 X-Spam-Level: X-Spam-Status: No, score=-6.536 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOl0oREfL3jB; Fri, 10 Dec 2010 21:20:34 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 342833A6CD4; Fri, 10 Dec 2010 21:20:34 -0800 (PST) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id oBB5M48l019515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 11 Dec 2010 05:22:05 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id oBB5M31Y020970; Sat, 11 Dec 2010 05:22:03 GMT Received: from abhmt012.oracle.com by acsmt353.oracle.com with ESMTP id 845443701292044884; Fri, 10 Dec 2010 21:21:24 -0800 Received: from oracle.com (/10.135.193.24) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 10 Dec 2010 21:21:23 -0800 Date: Fri, 10 Dec 2010 23:21:18 -0600 From: Nicolas Williams To: Peter Saint-Andre Message-ID: <20101211052117.GA29086@oracle.com> References: <4D02AF81.6000907@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D02AF81.6000907@stpeter.im> User-Agent: Mutt/1.5.20 (2010-03-02) X-Mailman-Approved-At: Sat, 11 Dec 2010 03:29:31 -0800 Cc: "apps-discuss@ietf.org" , websec@ietf.org, "kitten@ietf.org" , http-auth@ietf.org, saag@ietf.org, "ietf-http-wg@w3.org Group" Subject: Re: [websec] [kitten] HTTP authentication: the next generation X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2010 05:20:35 -0000 On Fri, Dec 10, 2010 at 03:53:53PM -0700, Peter Saint-Andre wrote: > Is it time to start thinking about next-generation authentication > technologies for HTTP? > > We all know that BASIC and DIGEST are ancient and crufty and lacking > many features and security properties we might want, but there hasn't > been much discussion about more modern approaches. Here are a few things > I've found: > > 1. Way back in 2001, Keith Burdis wrote an I-D about upgrading to SASL > within HTTP: http://tools.ietf.org/id/draft-burdis-http-sasl-00.txt I have this: draft-williams-tls-app-sasl-opt-04.txt which could easily be made usable from HTTP. > If you're interested, please discuss on the http-auth@ietf.org list: > > https://www.ietf.org/mailman/listinfo/http-auth One more list... :) Nico -- From mattamah@gmail.com Sat Dec 11 14:08:22 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 561B53A6D4A for ; Sat, 11 Dec 2010 14:08:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fWLV25KTpLAJ for ; Sat, 11 Dec 2010 14:08:21 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 0C2F13A6CC1 for ; Sat, 11 Dec 2010 14:08:17 -0800 (PST) Received: by vws7 with SMTP id 7so2925983vws.31 for ; Sat, 11 Dec 2010 14:09:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=A2GlWTApM5zccRo/woAjAUHSrFm39qp7q4JFfybkdEw=; b=U5s8rms+v/uR3SVjhnTWiDIVvtrT7Pu5DbR6AlDGkldL8o1c1SsDrTwp7L1l80fXRV 4laofdf7LIbAbeiI/PIITLFUchHXXlUXFtQioQkD/OR7IrbXl32oJunBxUT4TqqRI44a dyBjXd3DL085c0VjSgnZfQqQADksaqk77yRKI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=auI3ZU1sB12LQiaTZkAQ/0Ck5h9OHOp3zUBys8cmwFAk53q+UacN1Xj3knwpfIp506 XBQTXWNHH7EbYzA3p4VifjTjChi7tYxGFbEgJ5YQOkh7O8gihpW6FgVPO12qwBlfCjbO MPumIn7jp36bnX3rB6XKgMXBHCAw1BEZrxQvA= MIME-Version: 1.0 Received: by 10.220.201.140 with SMTP id fa12mr689480vcb.20.1292105391094; Sat, 11 Dec 2010 14:09:51 -0800 (PST) Received: by 10.220.117.74 with HTTP; Sat, 11 Dec 2010 14:09:51 -0800 (PST) Date: Sat, 11 Dec 2010 23:09:51 +0100 Message-ID: From: Maduka Attamah To: websec@ietf.org Content-Type: multipart/alternative; boundary=90e6ba4fc124d93dce049729bad1 Subject: Re: [websec] request for feedback on adoption of drafts to WG - until Dec-16 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2010 22:08:22 -0000 --90e6ba4fc124d93dce049729bad1 Content-Type: text/plain; charset=ISO-8859-1 > - draft-abarth-origin: > - hodges-strict-transport-sec: > - draft-abarth-mime-sniff: > A: Yes for all three - not biased ;-) -- Maduka http://ui.edu.ng/mattamah --90e6ba4fc124d93dce049729bad1 Content-Type: text/html; charset=ISO-8859-1
- draft-abarth-origin:
- hodges-strict-transport-sec:
- draft-abarth-mime-sniff:

A: Yes for all three

- not biased ;-)

--
Maduka
--90e6ba4fc124d93dce049729bad1-- From dev.akhawe@gmail.com Sat Dec 11 14:13:55 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A8AD3A6D4D for ; Sat, 11 Dec 2010 14:13:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.112 X-Spam-Level: X-Spam-Status: No, score=-3.112 tagged_above=-999 required=5 tests=[AWL=0.488, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlQhqccc4eYY for ; Sat, 11 Dec 2010 14:13:54 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 189D63A6D4A for ; Sat, 11 Dec 2010 14:13:53 -0800 (PST) Received: by wyf23 with SMTP id 23so4766753wyf.31 for ; Sat, 11 Dec 2010 14:15:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type; bh=o1RQiARHObrU1RQ32WMnnp0k3Lmh9bTPJXE1d/L5hu4=; b=CBKfjx5OOdawUee9AAovZVrc0tmtqnor7ADT8PUaAltr3ZOPH+riG8//AyBiQp5M6+ qXlUZCRBVSrz/IV2tfAju/ny98SYhiSJt+lAUgJdouNP79tv6ZpV4Oz6hpE3pUBKey0C /aO6/inRz1JrOJvgfAafdfocurafPMrLIYdH4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=AV7oz9POCwosns09jzocnOO670RycC8GNiNmiNiVRCC61CC6sVAz73mu/Ty83iVoa9 Txi4N0vBRJJ3x++QUfUc7AE+pUt2Urtf/35OYJ9QGKLwD5xFR4qoP+NRscxJWk2+pDR8 Aj7eD+h+EzcjCsjXoOjFQTM/zwC07LIB9qY9I= Received: by 10.216.208.230 with SMTP id q80mr1099114weo.103.1292105726973; Sat, 11 Dec 2010 14:15:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.86.11 with HTTP; Sat, 11 Dec 2010 14:15:06 -0800 (PST) In-Reply-To: References: From: Devdatta Akhawe Date: Sat, 11 Dec 2010 14:15:06 -0800 Message-ID: To: websec@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [websec] request for feedback on adoption of drafts to WG - until Dec-16 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2010 22:13:55 -0000 What does "Adopt" mean ? They will still be drafts, right? On 11 December 2010 14:09, Maduka Attamah wrote: > >> - draft-abarth-origin: >> >> - hodges-strict-transport-sec: >> >> - draft-abarth-mime-sniff: > > A: Yes for all three > - not biased ;-) > -- > Maduka > http://ui.edu.ng/mattamah > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > > From tobias.gondrom@gondrom.org Sat Dec 11 14:53:19 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C878C3A6D4D for ; Sat, 11 Dec 2010 14:53:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.077 X-Spam-Level: X-Spam-Status: No, score=-95.077 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQOlXltAvyg2 for ; Sat, 11 Dec 2010 14:53:19 -0800 (PST) Received: from lvps83-169-7-107.dedicated.hosteurope.de (lvps83-169-7-107.dedicated.hosteurope.de [83.169.7.107]) by core3.amsl.com (Postfix) with ESMTP id 74DD13A6CF1 for ; Sat, 11 Dec 2010 14:53:18 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=fcv5QdSAEFKBP9qlyES2+w+IRJNvL7+kr3ZHma4kdCQmBcb9SJyBfi/d1JWnVemcqrSPLy97Tg7xKLdT9NIWZiRZpSUsgeoaWqKDFhWgeIIF7TNni/1L68ftSHzTZnJ4; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; Received: (qmail 1957 invoked from network); 11 Dec 2010 23:54:51 +0100 Received: from 94-194-102-93.zone8.bethere.co.uk (HELO seraphim.heaven) (94.194.102.93) by lvps83-169-7-107.dedicated.hosteurope.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 11 Dec 2010 23:54:50 +0100 Message-ID: <4D040197.1020907@gondrom.org> Date: Sat, 11 Dec 2010 22:56:23 +0000 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101026 SUSE/3.1.6 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: websec@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [websec] request for feedback on adoption of drafts to WG - until Dec-16 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2010 22:53:19 -0000 Yes. They will still be drafts. (they are now individual drafts and after adoption will be wg drafts) Tobias On 12/11/2010 10:15 PM, Devdatta Akhawe wrote: > What does "Adopt" mean ? They will still be drafts, right? > > > On 11 December 2010 14:09, Maduka Attamah wrote: >>> - draft-abarth-origin: >>> >>> - hodges-strict-transport-sec: >>> >>> - draft-abarth-mime-sniff: >> A: Yes for all three >> - not biased ;-) >> -- >> Maduka >> http://ui.edu.ng/mattamah >> _______________________________________________ >> websec mailing list >> websec@ietf.org >> https://www.ietf.org/mailman/listinfo/websec >> >> > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From dev.akhawe@gmail.com Sat Dec 11 14:55:22 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42A963A6D4F for ; Sat, 11 Dec 2010 14:55:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.209 X-Spam-Level: X-Spam-Status: No, score=-3.209 tagged_above=-999 required=5 tests=[AWL=0.390, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fFfXcJthSfOo for ; Sat, 11 Dec 2010 14:55:21 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 2739C3A6CF1 for ; Sat, 11 Dec 2010 14:55:20 -0800 (PST) Received: by wwa36 with SMTP id 36so5059718wwa.13 for ; Sat, 11 Dec 2010 14:56:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=HXArbdoC2cwVqS74v5ZFNQR7uXexLDgpoLe1tbH/qRw=; b=dKRL5k567RPFx+n1J46fXVCGNvqnuFDFDvmJHJFGGrR6DwZ7kDUZoSwExN3xtRAAlr Zx4C69xmA4zZigUzRssCoz9JpHTUucRhpO0ZcJUjoB7Q7hOEPPx2WZzAVNSwTJeSw9aQ UUE66raWqF/0zIbhDDFDCWIdGFlAyvwvwtdMk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=MMcI8/uSZ+KPjbHkvGVjl7W2af1iq9DNK8dsVllwynFcsFTl53eqFNLcVXjByLvUZM llpqWl4Z/D/egod3TN2R7DcccMfSqym+dFtG57bS+EPm/s+4w3ibY4JQf2z1LqqXGoxM BOBzjpQj3nPb3219jSKa5zO4hCyTMWY2I3YiA= Received: by 10.216.35.74 with SMTP id t52mr2616578wea.103.1292108214334; Sat, 11 Dec 2010 14:56:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.86.11 with HTTP; Sat, 11 Dec 2010 14:56:34 -0800 (PST) In-Reply-To: <4D040197.1020907@gondrom.org> References: <4D040197.1020907@gondrom.org> From: Devdatta Akhawe Date: Sat, 11 Dec 2010 14:56:34 -0800 Message-ID: To: Tobias Gondrom Content-Type: text/plain; charset=ISO-8859-1 Cc: websec@ietf.org Subject: Re: [websec] request for feedback on adoption of drafts to WG - until Dec-16 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2010 22:55:22 -0000 yes on all three On 11 December 2010 14:56, Tobias Gondrom wrote: > Yes. They will still be drafts. > (they are now individual drafts and after adoption will be wg drafts) > Tobias > > > On 12/11/2010 10:15 PM, Devdatta Akhawe wrote: >> What does "Adopt" mean ? They will still be drafts, right? >> >> >> On 11 December 2010 14:09, Maduka Attamah wrote: >>>> - draft-abarth-origin: >>>> >>>> - hodges-strict-transport-sec: >>>> >>>> - draft-abarth-mime-sniff: >>> A: Yes for all three >>> - not biased ;-) >>> -- >>> Maduka >>> http://ui.edu.ng/mattamah >>> _______________________________________________ >>> websec mailing list >>> websec@ietf.org >>> https://www.ietf.org/mailman/listinfo/websec >>> >>> >> _______________________________________________ >> websec mailing list >> websec@ietf.org >> https://www.ietf.org/mailman/listinfo/websec > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > From derhoermi@gmx.net Sat Dec 11 14:59:02 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF5BE3A6CF1 for ; Sat, 11 Dec 2010 14:59:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.791 X-Spam-Level: X-Spam-Status: No, score=-3.791 tagged_above=-999 required=5 tests=[AWL=-1.192, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s95kus3CJuYO for ; Sat, 11 Dec 2010 14:59:02 -0800 (PST) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 71A293A6CC3 for ; Sat, 11 Dec 2010 14:59:00 -0800 (PST) Received: (qmail invoked by alias); 11 Dec 2010 23:00:34 -0000 Received: from dslb-094-222-156-080.pools.arcor-ip.net (EHLO xn--bjrn-6qa.xn--hhrmann-90a.de) [94.222.156.80] by mail.gmx.net (mp019) with SMTP; 12 Dec 2010 00:00:34 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX18HwpEmGTEHTsTrrprNfrQkaIRP37u7UIHRaom5+b 41sjtQ1ezOzZGk From: Bjoern Hoehrmann To: Devdatta Akhawe Date: Sun, 12 Dec 2010 00:00:26 +0100 Message-ID: References: In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: websec@ietf.org Subject: Re: [websec] request for feedback on adoption of drafts to WG - until Dec-16 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2010 22:59:03 -0000 * Devdatta Akhawe wrote: >What does "Adopt" mean ? They will still be drafts, right? The drafts would become work items of the working group, further work in an area covered by one of the drafts would likely be based on them, in one way or the other. This would be a good time to argue, for instance, that a draft falls out of the scope of the Working Group, does not meet and is unlikely to meet requirements layed out in the charter, that the technical approach in a draft is fundamentally unsound; or make counter- proposals for what other existing work should be adopted to cover what is covered by one or more of the drafts. More simply put, it's a matter of "Yes, it makes sense to base the group's work in this area on them". They would still be drafts of course. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From ynir@checkpoint.com Sat Dec 11 15:14:20 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6BDD3A6CF7; Sat, 11 Dec 2010 15:14:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.364 X-Spam-Level: X-Spam-Status: No, score=-9.364 tagged_above=-999 required=5 tests=[AWL=1.235, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2a-6pFCQ27YO; Sat, 11 Dec 2010 15:14:20 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 94A583A6D09; Sat, 11 Dec 2010 15:14:19 -0800 (PST) X-CheckPoint: {4D040629-0-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id oBBNFrmj001961; Sun, 12 Dec 2010 01:15:53 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sun, 12 Dec 2010 01:15:52 +0200 From: Yoav Nir To: websec , Peter Saint-Andre Date: Sun, 12 Dec 2010 01:15:51 +0200 Thread-Topic: [saag] HTTP authentication: the next generation Thread-Index: AcuZiVq4ANG3mfypQUiHj/vOrV2Hpw== Message-ID: <5C0D484C-682B-4B7B-B7EA-DFC78ADA3ED4@checkpoint.com> References: <4D02AF81.6000907@stpeter.im> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "http-auth@ietf.org" , "saag@ietf.org" , "apps-discuss@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [websec] [saag] HTTP authentication: the next generation X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2010 23:14:20 -0000 resending with less recipients... On Dec 12, 2010, at 1:10 AM, Yoav Nir wrote: >=20 > On Dec 11, 2010, at 1:09 AM, Paul Hoffman wrote: >=20 >> At 3:53 PM -0700 12/10/10, Peter Saint-Andre wrote: >>> Other than that, I'm not aware of much activity. What have I missed? >>=20 >> TLS client certificates. >=20 > TLS client certificates work, but as we've learned both with the web and = with IPsec clients, people would much rather not use them. A few IETFs ago = (Chicago?), a bunch of us tried to push the idea of TLS with EAP authentica= tion. >=20 > http://tools.ietf.org/html/draft-nir-tls-eap >=20 > At the time, the TLS working group (and an AD) told us that this would co= ntradict the applicability statement of EAP, so no, you cannot use EAP for = anything other than network access.=20 >=20 > Now we have the abfab working group, so I don't think this still holds. >=20 > Also, I agree with Marsh, that authentication is not enough, and you need= the rest of TLS anyway. >=20 > So yes, I think that it is time to resurrect HTTP authentication. >=20 > Yoav >=20 >=20 From ynir@checkpoint.com Sat Dec 11 15:08:58 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB2943A6CC6; Sat, 11 Dec 2010 15:08:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.31 X-Spam-Level: X-Spam-Status: No, score=-9.31 tagged_above=-999 required=5 tests=[AWL=1.289, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bNfpvjyZj955; Sat, 11 Dec 2010 15:08:57 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id E78FF3A6CC3; Sat, 11 Dec 2010 15:08:53 -0800 (PST) X-CheckPoint: {4D0404E3-0-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id oBBNAFio001572; Sun, 12 Dec 2010 01:10:15 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sun, 12 Dec 2010 01:10:15 +0200 From: Yoav Nir To: Paul Hoffman , websec , Peter Saint-Andre Date: Sun, 12 Dec 2010 01:10:11 +0200 Thread-Topic: [saag] HTTP authentication: the next generation Thread-Index: AcuZiJEeUrzxMlnURUmsuTqhB7a9Ww== Message-ID: References: <4D02AF81.6000907@stpeter.im> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Sat, 11 Dec 2010 15:30:17 -0800 Cc: "apps-discuss@ietf.org" , "pgut001@cs.auckland.ac.nz" , "kitten@ietf.org" , Yaron Sheffer , "http-auth@ietf.org" , "saag@ietf.org" , Hannes Tschofenig , "ietf-http-wg@w3.org Group" Subject: Re: [websec] [saag] HTTP authentication: the next generation X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Dec 2010 23:08:59 -0000 On Dec 11, 2010, at 1:09 AM, Paul Hoffman wrote: > At 3:53 PM -0700 12/10/10, Peter Saint-Andre wrote: >> Other than that, I'm not aware of much activity. What have I missed? >=20 > TLS client certificates. TLS client certificates work, but as we've learned both with the web and wi= th IPsec clients, people would much rather not use them. A few IETFs ago (C= hicago?), a bunch of us tried to push the idea of TLS with EAP authenticati= on. http://tools.ietf.org/html/draft-nir-tls-eap At the time, the TLS working group (and an AD) told us that this would cont= radict the applicability statement of EAP, so no, you cannot use EAP for an= ything other than network access.=20 Now we have the abfab working group, so I don't think this still holds. Also, I agree with Marsh, that authentication is not enough, and you need t= he rest of TLS anyway. So yes, I think that it is time to resurrect HTTP authentication. Yoav From ynir@checkpoint.com Sun Dec 12 00:40:02 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C62523A6D89; Sun, 12 Dec 2010 00:40:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.413 X-Spam-Level: X-Spam-Status: No, score=-9.413 tagged_above=-999 required=5 tests=[AWL=1.186, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iy4+jBAiaJoV; Sun, 12 Dec 2010 00:40:01 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 0CB0E3A6D03; Sun, 12 Dec 2010 00:40:00 -0800 (PST) X-CheckPoint: {4D048ABF-0-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id oBC8fOCj014846; Sun, 12 Dec 2010 10:41:24 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sun, 12 Dec 2010 10:41:24 +0200 From: Yoav Nir To: "'Josh Howlett'" , Yaron Sheffer , Luke Howard Date: Sun, 12 Dec 2010 10:41:23 +0200 Thread-Topic: [kitten] [saag] HTTP authentication: the next generation Thread-Index: AQHLmca26Q0IJHpixEGWpmc927Vy9JOcaR2AgAAQ5U6AAAIIsA== Message-ID: <006FEB08D9C6444AB014105C9AEB133F012E6FCD449F@il-ex01.ad.checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Sun, 12 Dec 2010 06:05:34 -0800 Cc: "apps-discuss@ietf.org" , "pgut001@cs.auckland.ac.nz" , websec , Paul Hoffman , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , Hannes Tschofenig , "ietf-http-wg@w3.org Group" Subject: Re: [websec] [kitten] [saag] HTTP authentication: the next generation X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Dec 2010 08:40:02 -0000 To quote from Abfab's charter: This working group will specify a federated identity mechanism for use by other Internet protocols not based on HTML/HTTP,=20 For just adding authentication to HTTP, I don't think it makes sense to add= federation. All kinds of services such as web mail, online gaming, and onl= ine shopping require authentication, but there's no federation involved.=20 -----Original Message----- From: Josh Howlett [mailto:Josh.Howlett@ja.net]=20 Sent: 12 December 2010 10:30 To: Yaron Sheffer; Luke Howard Cc: apps-discuss@ietf.org; pgut001@cs.auckland.ac.nz; Yoav Nir; websec; Pau= l Hoffman; kitten@ietf.org; http-auth@ietf.org; saag@ietf.org; Hannes Tscho= fenig; Josh Howlett; ietf-http-wg@w3.org Group Subject: Re: [kitten] [saag] HTTP authentication: the next generation AbFab is defining a GSS EAP mechanism that can encapsulate the EAP methods = you mention. This mechanism could be run over SASL-TLS using GS2. Josh. --- original message --- From: "Yaron Sheffer" Subject: Re: [kitten] [saag] HTTP authentication: the next generation Date: 12th December 2010 Time: 7:36:41 am Hi Luke, I am not a big fan of EAP myself (although I am a co-author on Yoav's TLS-E= AP), but no, for pragmatic reasons SASL is not the moral equivalent. There is a number of EAP methods that provide zero-knowledge password based= mutual authentication (i.e. password based auth that's *not* susceptible t= o dictionary attacks). These include (see http://www.iana.org/assignments/eap-numbers/eap-numbers.xml#eap-numbers-3): EAP-SRP-SHA1, EAP-pwd, EAP-EKE and EAP-SPEKE. As far as I can see (http://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xhtml), SASL does not provide any equivalent method. Thanks, Yaron On 12/12/2010 03:38 AM, Luke Howard wrote: > > On 12/12/2010, at 10:10 AM, Yoav Nir wrote: > >> >> On Dec 11, 2010, at 1:09 AM, Paul Hoffman wrote: >> >>> At 3:53 PM -0700 12/10/10, Peter Saint-Andre wrote: >>>> Other than that, I'm not aware of much activity. What have I missed? >>> >>> TLS client certificates. >> >> TLS client certificates work, but as we've learned both with the web and= with IPsec clients, people would much rather not use them. A few IETFs ago= (Chicago?), a bunch of us tried to push the idea of TLS with EAP authentic= ation. >> >> http://tools.ietf.org/html/draft-nir-tls-eap > > Does draft-williams-tls-app-sasl-opt-04.txt + abfab get you the moral equ= ivalent? > > -- Luke _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten JANET(UK) is a trading name of The JNT Association, a company limited by gu= arantee which is registered in England under No. 2881024 and whose Register= ed Office is at Lumen House, Library Avenue, Harwell Science and Innovation= Campus, Didcot, Oxfordshire. OX11 0SG Scanned by Check Point Total Security Gateway. From ynir@checkpoint.com Sun Dec 12 06:20:48 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD6F83A6DC3; Sun, 12 Dec 2010 06:20:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.459 X-Spam-Level: X-Spam-Status: No, score=-9.459 tagged_above=-999 required=5 tests=[AWL=1.140, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0nFTpAiwfcwo; Sun, 12 Dec 2010 06:20:47 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id EB9663A6DC0; Sun, 12 Dec 2010 06:20:46 -0800 (PST) X-CheckPoint: {4D04DA9D-0-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id oBCEMKn0026696; Sun, 12 Dec 2010 16:22:21 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sun, 12 Dec 2010 16:22:20 +0200 From: Yoav Nir To: Alexey Melnikov Date: Sun, 12 Dec 2010 16:22:23 +0200 Thread-Topic: [kitten] [saag] HTTP authentication: the next generation Thread-Index: AcuaB/xyAYCHWnJxTlaeEDShPLa+xg== Message-ID: References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> In-Reply-To: <4D04D7D6.4090105@isode.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [websec] [kitten] [saag] HTTP authentication: the next generation X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Dec 2010 14:20:49 -0000 EAP has one advantage. It is easy to integrate with existing RADIUS/DIAMETE= R infrastructure.=20 On Dec 12, 2010, at 4:10 PM, Alexey Melnikov wrote: > Yaron Sheffer wrote: >=20 >> Hi Luke, >>=20 >> I am not a big fan of EAP myself (although I am a co-author on Yoav's=20 >> TLS-EAP), but no, for pragmatic reasons SASL is not the moral equivalent= . >>=20 >> There is a number of EAP methods that provide zero-knowledge password=20 >> based mutual authentication (i.e. password based auth that's *not*=20 >> susceptible to dictionary attacks). These include (see=20 >> http://www.iana.org/assignments/eap-numbers/eap-numbers.xml#eap-numbers-= 3):=20 >> EAP-SRP-SHA1, EAP-pwd, EAP-EKE and EAP-SPEKE. >>=20 >> As far as I can see=20 >> (http://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xhtml),= =20 >> SASL does not provide any equivalent method. >=20 > There is an expired SASL SRP draft, which can be revived, if needed. >=20 >> Thanks, >> Yaron >>=20 >> On 12/12/2010 03:38 AM, Luke Howard wrote: >>=20 >>> On 12/12/2010, at 10:10 AM, Yoav Nir wrote: >>>=20 >>>> On Dec 11, 2010, at 1:09 AM, Paul Hoffman wrote: >>>>=20 >>>>> At 3:53 PM -0700 12/10/10, Peter Saint-Andre wrote: >>>>>=20 >>>>>> Other than that, I'm not aware of much activity. What have I missed? >>>>>=20 >>>>>=20 >>>>> TLS client certificates. >>>>=20 >>>>=20 >>>> TLS client certificates work, but as we've learned both with the web=20 >>>> and with IPsec clients, people would much rather not use them. A few=20 >>>> IETFs ago (Chicago?), a bunch of us tried to push the idea of TLS=20 >>>> with EAP authentication. >>>>=20 >>>> http://tools.ietf.org/html/draft-nir-tls-eap >>>=20 >>>=20 >>> Does draft-williams-tls-app-sasl-opt-04.txt + abfab get you the moral=20 >>> equivalent? >>>=20 >>> -- Luke >>=20 >=20 >=20 > Scanned by Check Point Total Security Gateway. From Jeff.Hodges@KingsMountain.com Sun Dec 12 07:57:00 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E057F3A6DDF for ; Sun, 12 Dec 2010 07:57:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.224 X-Spam-Level: X-Spam-Status: No, score=-102.224 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZ1soE1QBate for ; Sun, 12 Dec 2010 07:57:00 -0800 (PST) Received: from oproxy1-pub.bluehost.com (oproxy1-pub.bluehost.com [66.147.249.253]) by core3.amsl.com (Postfix) with SMTP id E26833A6DDE for ; Sun, 12 Dec 2010 07:56:59 -0800 (PST) Received: (qmail 4168 invoked by uid 0); 12 Dec 2010 15:58:35 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy1.bluehost.com.bluehost.com with SMTP; 12 Dec 2010 15:58:35 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=auyfpCsiauQextJzYZwzt1ZWrJ2evJK/+dCJ45UBDWROKTsnUAmPePY0EQjJns3ZI2lubtGm4HrtWrjoR0g7OuMIeKfX7ymiLhmLlu7aQqifwSy7nkVsygOUqUDJHGYP; Received: from c-24-4-122-173.hsd1.ca.comcast.net ([24.4.122.173] helo=[192.168.11.10]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1PRoJn-0003xM-Iq for websec@ietf.org; Sun, 12 Dec 2010 08:58:35 -0700 Message-ID: <4D04F129.1020104@KingsMountain.com> Date: Sun, 12 Dec 2010 07:58:33 -0800 From: =JeffH User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: IETF WebSec WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Subject: Re: [websec] individual drafts -> working group drafts (was: request for feedback on adoption of drafts...) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Dec 2010 15:57:01 -0000 > Yes. They will still be drafts. > (they are now individual drafts and after adoption will be wg drafts) see also.. Guidelines to Authors of Internet-Drafts http://www.ietf.org/ietf-ftp/1id-guidelines.txt IETF Working Group Guidelines and Procedures http://www.ietf.org/rfc/rfc2418.txt =JeffH From alexey.melnikov@isode.com Sun Dec 12 10:39:27 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9B343A6DF1; Sun, 12 Dec 2010 10:39:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.953 X-Spam-Level: X-Spam-Status: No, score=-102.953 tagged_above=-999 required=5 tests=[AWL=-0.354, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8fihkoYXOihe; Sun, 12 Dec 2010 10:39:27 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id AFFEB3A6DEE; Sun, 12 Dec 2010 10:39:26 -0800 (PST) Received: from [192.168.0.102] ((unknown) [109.73.6.25]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 12 Dec 2010 18:41:01 +0000 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4D051731.1020400@isode.com> Date: Sun, 12 Dec 2010 21:40:49 +0300 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Yoav Nir References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [websec] [kitten] [saag] HTTP authentication: the next generation X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Dec 2010 18:39:28 -0000 Yoav Nir wrote: >EAP has one advantage. It is easy to integrate with existing RADIUS/DIAMETER infrastructure. > True. And SASL has an advantage that it is easier to integrate with LDAP infrastructure. I think this just demonstrates that before an HTTP authentication mechanism can be evaluated, people need to agree on a common evaluation criteria for HTTP authentication. From ynir@checkpoint.com Sun Dec 12 14:05:01 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4ABE28C0D9; Sun, 12 Dec 2010 14:05:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.501 X-Spam-Level: X-Spam-Status: No, score=-9.501 tagged_above=-999 required=5 tests=[AWL=1.098, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4vmhh7ZUTmo; Sun, 12 Dec 2010 14:05:00 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 8DA9A28C0D6; Sun, 12 Dec 2010 14:04:59 -0800 (PST) X-CheckPoint: {4D05476B-0-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id oBCM6VZI007290; Mon, 13 Dec 2010 00:06:31 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 13 Dec 2010 00:06:31 +0200 From: Yoav Nir To: Eliot Lear Date: Mon, 13 Dec 2010 00:06:29 +0200 Thread-Topic: [apps-discuss] [kitten] [saag] HTTP authentication: the next generation Thread-Index: AcuaSNSrne/txJ/+ThWOBmTF9om+dQ== Message-ID: <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> In-Reply-To: <4D054041.7010203@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [websec] [apps-discuss] [kitten] [saag] HTTP authentication: the next generation X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Dec 2010 22:05:02 -0000 Because I'd rather not implement too many mechanisms in my browser or in my= web server. And if EAP integrates better with RADIUS, while SASL integrates better with= LDAP, it's still bad design to expose the server's backend to the client b= y the authentication protocol. Let's try and list the requirements for HTTP authentication: - It has to be integrated in the protocol, not the application - It has to be secure against phishing - if the attacker gets you to authen= ticate, they can't later use that authentication to connect to the real ser= ver - If the authentication succeeded, then (a) you typed your password correct= ly, and (b) this is really the server EAP has some methods that do this. SASL can probably be made to do this, bu= t with an extra layer. On Dec 12, 2010, at 11:36 PM, Eliot Lear wrote: > Why settle for one? >=20 > On 12/12/10 7:40 PM, Alexey Melnikov wrote: >> Yoav Nir wrote: >>=20 >>> EAP has one advantage. It is easy to integrate with existing >>> RADIUS/DIAMETER infrastructure. >>>=20 >> True. >> And SASL has an advantage that it is easier to integrate with LDAP >> infrastructure. >>=20 >> I think this just demonstrates that before an HTTP authentication >> mechanism can be evaluated, people need to agree on a common >> evaluation criteria for HTTP authentication. >>=20 >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >>=20 >=20 > Scanned by Check Point Total Security Gateway. From alexey.melnikov@isode.com Sun Dec 12 06:09:09 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9AFD3A6DC1; Sun, 12 Dec 2010 06:09:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.804 X-Spam-Level: X-Spam-Status: No, score=-102.804 tagged_above=-999 required=5 tests=[AWL=-0.205, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7RKNwzBRmOBT; Sun, 12 Dec 2010 06:09:08 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id ED60D3A6DBE; Sun, 12 Dec 2010 06:09:07 -0800 (PST) Received: from [192.168.0.102] ((unknown) [109.73.6.25]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 12 Dec 2010 14:10:42 +0000 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4D04D7D6.4090105@isode.com> Date: Sun, 12 Dec 2010 17:10:30 +0300 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Yaron Sheffer References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> In-Reply-To: <4D0479E3.4050508@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 12 Dec 2010 14:47:16 -0800 Cc: "apps-discuss@ietf.org" , "pgut001@cs.auckland.ac.nz" , websec , Paul Hoffman , "kitten@ietf.org" , "http-auth@ietf.org" , Luke Howard , "saag@ietf.org" , Hannes Tschofenig , "ietf-http-wg@w3.org Group" Subject: Re: [websec] [kitten] [saag] HTTP authentication: the next generation X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Dec 2010 14:09:10 -0000 Yaron Sheffer wrote: > Hi Luke, > > I am not a big fan of EAP myself (although I am a co-author on Yoav's > TLS-EAP), but no, for pragmatic reasons SASL is not the moral equivalent. > > There is a number of EAP methods that provide zero-knowledge password > based mutual authentication (i.e. password based auth that's *not* > susceptible to dictionary attacks). These include (see > http://www.iana.org/assignments/eap-numbers/eap-numbers.xml#eap-numbers-3): > EAP-SRP-SHA1, EAP-pwd, EAP-EKE and EAP-SPEKE. > > As far as I can see > (http://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xhtml), > SASL does not provide any equivalent method. There is an expired SASL SRP draft, which can be revived, if needed. > Thanks, > Yaron > > On 12/12/2010 03:38 AM, Luke Howard wrote: > >> On 12/12/2010, at 10:10 AM, Yoav Nir wrote: >> >>> On Dec 11, 2010, at 1:09 AM, Paul Hoffman wrote: >>> >>>> At 3:53 PM -0700 12/10/10, Peter Saint-Andre wrote: >>>> >>>>> Other than that, I'm not aware of much activity. What have I missed? >>>> >>>> >>>> TLS client certificates. >>> >>> >>> TLS client certificates work, but as we've learned both with the web >>> and with IPsec clients, people would much rather not use them. A few >>> IETFs ago (Chicago?), a bunch of us tried to push the idea of TLS >>> with EAP authentication. >>> >>> http://tools.ietf.org/html/draft-nir-tls-eap >> >> >> Does draft-williams-tls-app-sasl-opt-04.txt + abfab get you the moral >> equivalent? >> >> -- Luke > From lear@cisco.com Sun Dec 12 13:34:17 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00D433A6E08; Sun, 12 Dec 2010 13:34:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.055 X-Spam-Level: X-Spam-Status: No, score=-110.055 tagged_above=-999 required=5 tests=[AWL=0.544, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NebqHih4IIKe; Sun, 12 Dec 2010 13:34:16 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 3D5EE3A6D47; Sun, 12 Dec 2010 13:34:15 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmAEAIjPBE2Q/khLgWdsb2JhbACDXKAqFQEBFiIppWmKSY9SgSGDNXQEink X-IronPort-AV: E=Sophos;i="4.59,333,1288569600"; d="scan'208";a="15112279" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 12 Dec 2010 21:35:51 +0000 Received: from ams3-vpn-dhcp4641.cisco.com (ams3-vpn-dhcp4641.cisco.com [10.61.82.32]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id oBCLZoMB011735; Sun, 12 Dec 2010 21:35:50 GMT Message-ID: <4D054041.7010203@cisco.com> Date: Sun, 12 Dec 2010 22:36:01 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Alexey Melnikov References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> In-Reply-To: <4D051731.1020400@isode.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 12 Dec 2010 14:47:16 -0800 Cc: "apps-discuss@ietf.org" , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [websec] [apps-discuss] [kitten] [saag] HTTP authentication: the next generation X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Dec 2010 21:34:17 -0000 Why settle for one? On 12/12/10 7:40 PM, Alexey Melnikov wrote: > Yoav Nir wrote: > >> EAP has one advantage. It is easy to integrate with existing >> RADIUS/DIAMETER infrastructure. >> > True. > And SASL has an advantage that it is easier to integrate with LDAP > infrastructure. > > I think this just demonstrates that before an HTTP authentication > mechanism can be evaluated, people need to agree on a common > evaluation criteria for HTTP authentication. > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From fielding@gbiv.com Sun Dec 12 14:37:48 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA2483A6DFA; Sun, 12 Dec 2010 14:37:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.908 X-Spam-Level: X-Spam-Status: No, score=-102.908 tagged_above=-999 required=5 tests=[AWL=-0.309, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5F7DPk-i9+xg; Sun, 12 Dec 2010 14:37:48 -0800 (PST) Received: from homiemail-a73.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by core3.amsl.com (Postfix) with ESMTP id E3FE33A6CCA; Sun, 12 Dec 2010 14:37:47 -0800 (PST) Received: from homiemail-a73.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTP id 765EE1F0069; Sun, 12 Dec 2010 14:39:24 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gbiv.com; h=subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; q=dns; s=gbiv.com; b=FYJb5G/ckuimNYH2 EAMF3uuc/bmghPYH8ir/SmwsMldYFoE+q6MzaGFSbJI9RRh/KECrXuBVc6f27dDE yhWSaZliwtQsnTI1hlclvSpj7YkVT+8KdfyzMKny2yqtt3roZAfNF7h3tWfvOKEl SiiYD3rxArbXfIIhT3q52pL2QAA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=AY54s7iPVjMmfy217h64SJv5wQw=; b=cyn7LDvPTexWvZcI80dZLqHSlJG2 E1gBEKD8jFcSwDbV5YdfvdzZHIXMaoq+R3IN+Ssx1HqjKORiTU7yYahe0XDvqbAM /XzSPPuTPFS5TVncRhVYQ6NaMqT4zN462bWQbXkR52lqQjt4FoIDFAeLLne3QyTS +587nIlVypmcR3A= Received: from [192.168.1.66] (99-21-208-82.lightspeed.irvnca.sbcglobal.net [99.21.208.82]) (Authenticated sender: fielding@gbiv.com) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTPA id 01E541F0065; Sun, 12 Dec 2010 14:39:23 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Roy T. Fielding" In-Reply-To: <4D051731.1020400@isode.com> Date: Sun, 12 Dec 2010 14:39:23 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.1082) X-Mailman-Approved-At: Sun, 12 Dec 2010 14:47:16 -0800 Cc: "apps-discuss@ietf.org" , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [websec] [kitten] [saag] HTTP authentication: the next generation X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Dec 2010 22:37:49 -0000 On Dec 12, 2010, at 10:40 AM, Alexey Melnikov wrote: > Yoav Nir wrote: >=20 >> EAP has one advantage. It is easy to integrate with existing = RADIUS/DIAMETER infrastructure. >>=20 > True. > And SASL has an advantage that it is easier to integrate with LDAP = infrastructure. >=20 > I think this just demonstrates that before an HTTP authentication = mechanism can be evaluated, people need to agree on a common evaluation = criteria for HTTP authentication. Define them all and let's have a bake-off. It has been 16 years since HTTP auth was taken out of our hands so that the security experts could define something perfect. Zero progress so far. We should just define everything and let the security experts do what they do best -- find the holes and tell us what not to implement. ....Roy= From marsh@extendedsubset.com Sun Dec 12 16:47:37 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF99E3A6D90; Sun, 12 Dec 2010 16:47:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bWvmuEKtAYSh; Sun, 12 Dec 2010 16:47:35 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 653B93A6D16; Sun, 12 Dec 2010 16:47:35 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1PRwbI-00080u-0i; Mon, 13 Dec 2010 00:49:12 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 2788E60C6; Mon, 13 Dec 2010 00:49:09 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+LS98k8zKrRc2V9A6d+dLVfNCJcc+FPxg= Message-ID: <4D056D83.2020704@extendedsubset.com> Date: Sun, 12 Dec 2010 18:49:07 -0600 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Roy T. Fielding" References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> In-Reply-To: <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [websec] [kitten] [saag] HTTP authentication: the next generation X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 00:47:37 -0000 On 12/12/2010 04:39 PM, Roy T. Fielding wrote: > > Define them all and let's have a bake-off. It has been 16 years > since HTTP auth was taken out of our hands so that the security > experts could define something perfect. Zero progress so far. Perhaps it's a bad idea? > We > should just define everything and let the security experts do what > they do best -- find the holes and tell us what not to implement. I know some professional pen-testers who would love that! Check out these videos. This is what happens when you take a general-purpose authentication protocol and repurpose it for use across the internet for an insecure application protocol: http://extendedsubset.com/smb_relay_fully_patched.wmv http://extendedsubset.com/smb_reflection_arp_poisoning.wmv http://extendedsubset.com/?p=36 This case is NTLMv2, but the phenomenon is not limited to that. The problem is that most general-purpose authentication protocols do not require enough specificity about the context of the authentication: who and what are you authenticating, to whom, and how does each side know it's operating under the same beliefs as the other? This means that even if the client wants to be careful and authenticate only for the purpose of setting up a secure connection, the attacker can possibly forward that authentication to auth his own connection or transaction on some other service (on the same or even a different server). Most auth protocols don't let the client strongly verify the server's identity before the client has to authenticate with his own. This is probably at least in part because it requires some common infrastructure to do this. So Kerberos and x509 PKI systems can authenticate the server (and sometimes even the target service), but most others do not. Since HTTP lacks connection integrity, it's meaningless to speak of "an authenticated client". Perhaps the only thing that could be meaningfully authenticated is the request data itself. But auth protocols designed for setting up persistent connections typically don't have defined inputs for the message data/digest being signed, so it's often impractical to reuse them for that purpose. These issues have been mostly addressed at the protocol level for TLS client cert authentication. If it really just comes down to deployment and client usability issues, it's hard to imagine coming up with something at another layer which would have less risk than building on top of that. Deploying new uses of compatible, standard authentication protocols over insecure application protocols can be bad for the greater security ecosystem because it widens the field for cross-protocol attacks. - Marsh From ynir@checkpoint.com Mon Dec 13 00:47:43 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AD0D3A6D70; Mon, 13 Dec 2010 00:47:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.54 X-Spam-Level: X-Spam-Status: No, score=-9.54 tagged_above=-999 required=5 tests=[AWL=1.059, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4HPTUmFhZBCJ; Mon, 13 Dec 2010 00:47:41 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 1BCB73A6CED; Mon, 13 Dec 2010 00:47:40 -0800 (PST) X-CheckPoint: {4D05DE0D-D-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id oBD8n31r011021; Mon, 13 Dec 2010 10:49:14 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 13 Dec 2010 10:49:05 +0200 From: Yoav Nir To: Marsh Ray Date: Mon, 13 Dec 2010 10:49:08 +0200 Thread-Topic: [websec] [kitten] [saag] HTTP authentication: the next generation Thread-Index: AcuaopkknTdJEIPhRueT7ek5WBXGLQ== Message-ID: References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> <4D056D83.2020704@extendedsubset.com> In-Reply-To: <4D056D83.2020704@extendedsubset.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "http-auth@ietf.org" , websec , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [websec] [kitten] [saag] HTTP authentication: the next generation X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 08:47:43 -0000 On Dec 13, 2010, at 2:49 AM, Marsh Ray wrote: > On 12/12/2010 04:39 PM, Roy T. Fielding wrote: >>=20 >> Define them all and let's have a bake-off. It has been 16 years >> since HTTP auth was taken out of our hands so that the security >> experts could define something perfect. Zero progress so far. >=20 > Perhaps it's a bad idea? Disagree. Authentication is very much needed in the web. The current state = is that websites have you fill in a form, and store a session cookie. We al= l know how this fails. An attacker can make a login page that looks like go= ogle's or paypal's or bankleumi.co.il just as easily as the respective orga= nizations, and gain access to their credentials. This is good enough for Google, who need the cookies to track your searches= and emails so as to match them to ads. A little bit of someone searching t= he web with someone else's userid doesn't make much difference to them. But= if I have some important information in my gmail account, or money in bank= leumi, I would like to avoid sending my password in the clear to an attacke= r's site. And things like SRP can do this. If SRP succeeds with a remote s= erver, I know that it's the right server. Client certificates would work even better, but client certificates have th= eir own set of problems, which is why they're not widely used. I agree with you that layering whatever authentication on top of HTTP witho= ut at least message authentication is not a good idea, so TLS seems like th= e right choice - all those bank and email sites are already doing it. But w= e do need something more useable than certificates, and for now, this means= passwords. >=20 >> We >> should just define everything and let the security experts do what >> they do best -- find the holes and tell us what not to implement. >=20 > I know some professional pen-testers who would love that! >=20 > Check out these videos. This is what happens when you take a=20 > general-purpose authentication protocol and repurpose it for use across=20 > the internet for an insecure application protocol: >=20 > http://extendedsubset.com/smb_relay_fully_patched.wmv > http://extendedsubset.com/smb_reflection_arp_poisoning.wmv > http://extendedsubset.com/?p=3D36 >=20 > This case is NTLMv2, but the phenomenon is not limited to that. >=20 > The problem is that most general-purpose authentication protocols do not= =20 > require enough specificity about the context of the authentication: who=20 > and what are you authenticating, to whom, and how does each side know=20 > it's operating under the same beliefs as the other? >=20 > This means that even if the client wants to be careful and authenticate=20 > only for the purpose of setting up a secure connection, the attacker can= =20 > possibly forward that authentication to auth his own connection or=20 > transaction on some other service (on the same or even a different server= ). >=20 > Most auth protocols don't let the client strongly verify the server's=20 > identity before the client has to authenticate with his own. This is=20 > probably at least in part because it requires some common infrastructure= =20 > to do this. So Kerberos and x509 PKI systems can authenticate the server= =20 > (and sometimes even the target service), but most others do not. >=20 > Since HTTP lacks connection integrity, it's meaningless to speak of "an=20 > authenticated client". Perhaps the only thing that could be meaningfully= =20 > authenticated is the request data itself. But auth protocols designed=20 > for setting up persistent connections typically don't have defined=20 > inputs for the message data/digest being signed, so it's often=20 > impractical to reuse them for that purpose. >=20 > These issues have been mostly addressed at the protocol level for TLS=20 > client cert authentication. If it really just comes down to deployment=20 > and client usability issues, it's hard to imagine coming up with=20 > something at another layer which would have less risk than building on=20 > top of that. >=20 > Deploying new uses of compatible, standard authentication protocols over= =20 > insecure application protocols can be bad for the greater security=20 > ecosystem because it widens the field for cross-protocol attacks. >=20 > - Marsh > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec >=20 > Scanned by Check Point Total Security Gateway. From dsr@w3.org Mon Dec 13 02:16:17 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CA3E28C0DD; Mon, 13 Dec 2010 02:16:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1QhYXMl8RCJH; Mon, 13 Dec 2010 02:16:16 -0800 (PST) Received: from lewis.sophia.w3.org (gw.sophia.w3.org [193.51.208.72]) by core3.amsl.com (Postfix) with ESMTP id 55D863A6CF3; Mon, 13 Dec 2010 02:16:16 -0800 (PST) Received: from dsl-217-155-168-222.zen.co.uk ([217.155.168.222] helo=[192.168.1.3]) by lewis.sophia.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1PS5TJ-0003FO-IJ; Mon, 13 Dec 2010 10:17:33 +0000 From: Dave Raggett To: "Roy T. Fielding" In-Reply-To: <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> Content-Type: text/plain; charset="UTF-8" Organization: W3C Date: Mon, 13 Dec 2010 10:17:34 +0000 Message-ID: <1292235454.20343.122.camel@ivy> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 13 Dec 2010 02:44:25 -0800 Cc: Jan Camenisch , "apps-discuss@ietf.org" , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [websec] [apps-discuss] [kitten] [saag] HTTP authentication: the next generation X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 10:16:17 -0000 And let's not ignore secure privacy enhancing technologies like anonymous credentials and zero knowledge proofs, see e.g: http://www.w3.org/QA/2010/11/boosting_privacy_online_-_anon.html It is often sufficient to know that someone is a member of a group or has certain attributes rather than knowing exactly who that person is. Perhaps we could add to SASL the notion of secure anonymous access for authenticated access? This involves the client generating and passing a proof to the server that satisfies the proof specification and nonce provided by the server. [ Jan, see http://datatracker.ietf.org/wg/kitten/charter/ ] n.b. this work was carried out with support from the European PrimeLife project on privacy and identity, see http://www.primelife.eu/ On Sun, 2010-12-12 at 14:39 -0800, Roy T. Fielding wrote: > On Dec 12, 2010, at 10:40 AM, Alexey Melnikov wrote: > > > Yoav Nir wrote: > > > >> EAP has one advantage. It is easy to integrate with existing > RADIUS/DIAMETER infrastructure. > >> > > True. > > And SASL has an advantage that it is easier to integrate with LDAP > infrastructure. > > > > I think this just demonstrates that before an HTTP authentication > mechanism can be evaluated, people need to agree on a common > evaluation criteria for HTTP authentication. > > Define them all and let's have a bake-off. It has been 16 years since > HTTP auth was taken out of our hands so that the security experts could > define something perfect. Zero progress so far. We should just define > everything and let the security experts do what they do best -- find the > holes and tell us what not to implement. > > ....Roy > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > -- Dave Raggett http://www.w3.org/People/Raggett From dave@cridland.net Mon Dec 13 02:24:26 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A64D28C0E3; Mon, 13 Dec 2010 02:24:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hYtbAzJLozZ9; Mon, 13 Dec 2010 02:24:25 -0800 (PST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by core3.amsl.com (Postfix) with ESMTP id 7F1B33A6D7A; Mon, 13 Dec 2010 02:24:24 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 2834911680FB; Mon, 13 Dec 2010 10:26:00 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 718q9D-RRrSU; Mon, 13 Dec 2010 10:25:53 +0000 (GMT) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id EDEAF1168110; Mon, 13 Dec 2010 10:25:52 +0000 (GMT) References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> In-Reply-To: <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> MIME-Version: 1.0 Message-Id: <2229.1292235952.971571@puncture> Date: Mon, 13 Dec 2010 10:25:52 +0000 From: Dave Cridland To: Yoav Nir , General discussion of application-layer protocols , websec , Common Authentication Technologies - Next Generation , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" , Eliot Lear Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" X-Mailman-Approved-At: Mon, 13 Dec 2010 02:44:25 -0800 Subject: Re: [websec] [kitten] [apps-discuss] [saag] HTTP authentication: the next generation X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 10:24:26 -0000 On Sun Dec 12 22:06:29 2010, Yoav Nir wrote: > - It has to be integrated in the protocol, not the application What?! No. It must be integrated in the application. If nothing else can be learnt, then learn this one thing - we have had Basic and Digest support in the protocol for years, but because they cannot easily be integrated into the application, no serious consumer applications use them, even though what they provide is never any better than Basic. If I could wave a magic wand and have all my wishes come true, I'd embed SASL into the web browser such that: - Users are presented with visually-distinct controls embedded into a web page for authentication, much like Extended Validation. Perhaps focussing them turns the address bar red or something. - The SASL message exchanges happen over a WebSocket or equivalent low-latency bidirectional channel. (Perhaps even HTTPS, I suppose - I imagine a webbrowser gets given one or more URIs to use for communications). - The result of this is a one-time password intializer. - Subsequent requests and responses occur with traditional HTTP auth, using some OTP mechanism that requires only a single message. The two parts of the protocol can, and should, be split - many existing websites use a cookie as the result of authentication, and having a more secure variant of this alone would be extremely useful. Note that the key portion of this - embedded SASL - is not really HTTP auth at all, but a Web Application Auth - since that's really the other party to the authentication, it seems quite obvious to me that this should be the authenticating entity. > - It has to be secure against phishing - if the attacker gets you > to authenticate, they can't later use that authentication to > connect to the real server > - If the authentication succeeded, then (a) you typed your password > correctly, and (b) this is really the server > > EAP has some methods that do this. SASL can probably be made to do > this, but with an extra layer. > > SASL also has methods that will do this, I think - I'm not sure what additional layer you're referring to here. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From adrien@qbik.com Mon Dec 13 02:53:39 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64E4F28C0DB; Mon, 13 Dec 2010 02:53:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.769 X-Spam-Level: X-Spam-Status: No, score=-5.769 tagged_above=-999 required=5 tests=[AWL=-3.170, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QA-g+RFm1zpx; Mon, 13 Dec 2010 02:53:37 -0800 (PST) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by core3.amsl.com (Postfix) with ESMTP id 796D63A6E85; Mon, 13 Dec 2010 02:53:36 -0800 (PST) Received: From [192.168.1.10] (unverified [125.237.244.120]) by SMTP Server [210.55.214.35] (WinGate SMTP Receiver v7.0.0 (Build 3102)) with SMTP id <0017850742@smtp.qbik.com>; Mon, 13 Dec 2010 23:55:11 +1300 Message-ID: <4D05FB8F.3070804@qbik.com> Date: Mon, 13 Dec 2010 23:55:11 +1300 From: Adrien de Croy User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Dave Cridland References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> <2229.1292235952.971571@puncture> In-Reply-To: <2229.1292235952.971571@puncture> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 13 Dec 2010 03:56:45 -0800 Cc: Eliot Lear , General discussion of application-layer protocols , websec , Common Authentication Technologies - Next Generation , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [websec] [kitten] [apps-discuss] [saag] HTTP authentication: the next generation X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 10:53:39 -0000 you might want to reconsider. for instance what would you propose for non-browsers, which perform a large proportion of all HTTP transactions. Also, it seems like it would make the problem about a billion times worse putting the auth into the application, where there are no standards, and therefore it would need to be re-implemented for each different application... kinda like what we have now already. SASL is an orthogonal concept. It's just a framework to negotiate auth, whether that's over HTTP or something else. So, it's a bit of a red herring in this. Yoav is correct, the auth must be in the protocol (1 of these) as opposed to the application (too many of these). The trick is to get the application to actually use the auth of the protocol. Adrien On 13/12/2010 11:25 p.m., Dave Cridland wrote: > On Sun Dec 12 22:06:29 2010, Yoav Nir wrote: >> - It has to be integrated in the protocol, not the application > > What?! No. It must be integrated in the application. If nothing else > can be learnt, then learn this one thing - we have had Basic and > Digest support in the protocol for years, but because they cannot > easily be integrated into the application, no serious consumer > applications use them, even though what they provide is never any > better than Basic. > > If I could wave a magic wand and have all my wishes come true, I'd > embed SASL into the web browser such that: > > - Users are presented with visually-distinct controls embedded into a > web page for authentication, much like Extended Validation. Perhaps > focussing them turns the address bar red or something. > - The SASL message exchanges happen over a WebSocket or equivalent > low-latency bidirectional channel. (Perhaps even HTTPS, I suppose - I > imagine a webbrowser gets given one or more URIs to use for > communications). > - The result of this is a one-time password intializer. > - Subsequent requests and responses occur with traditional HTTP auth, > using some OTP mechanism that requires only a single message. > > The two parts of the protocol can, and should, be split - many > existing websites use a cookie as the result of authentication, and > having a more secure variant of this alone would be extremely useful. > > Note that the key portion of this - embedded SASL - is not really HTTP > auth at all, but a Web Application Auth - since that's really the > other party to the authentication, it seems quite obvious to me that > this should be the authenticating entity. > > >> - It has to be secure against phishing - if the attacker gets you to >> authenticate, they can't later use that authentication to connect to >> the real server >> - If the authentication succeeded, then (a) you typed your password >> correctly, and (b) this is really the server >> >> EAP has some methods that do this. SASL can probably be made to do >> this, but with an extra layer. >> >> > SASL also has methods that will do this, I think - I'm not sure what > additional layer you're referring to here. > > Dave. -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com From dave@cridland.net Mon Dec 13 03:21:34 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6325F28C0D0; Mon, 13 Dec 2010 03:21:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zj7BugRYLD1g; Mon, 13 Dec 2010 03:21:33 -0800 (PST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by core3.amsl.com (Postfix) with ESMTP id 63DCA3A6CD9; Mon, 13 Dec 2010 03:21:32 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id E14FD1168112; Mon, 13 Dec 2010 11:23:08 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPfyXaB0kJvE; Mon, 13 Dec 2010 11:23:04 +0000 (GMT) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 43BFF1168110; Mon, 13 Dec 2010 11:23:04 +0000 (GMT) References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> <2229.1292235952.971571@puncture> <4D05FB8F.3070804@qbik.com> In-Reply-To: <4D05FB8F.3070804@qbik.com> MIME-Version: 1.0 Message-Id: <2229.1292239384.281779@puncture> Date: Mon, 13 Dec 2010 11:23:04 +0000 From: Dave Cridland To: Adrien de Croy , Yoav Nir , General discussion of application-layer protocols , websec , Common Authentication Technologies - Next Generation , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" , Eliot Lear Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" X-Mailman-Approved-At: Mon, 13 Dec 2010 03:56:45 -0800 Subject: Re: [websec] [kitten] [apps-discuss] [saag] HTTP authentication: the next generation X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 11:21:34 -0000 On Mon Dec 13 10:55:11 2010, Adrien de Croy wrote: > for instance what would you propose for non-browsers, which perform > a large proportion of all HTTP transactions. > > I agree a solution is needed for non-browsers (including IPP, for example). I disagree this needs to be, or should be, the same as a solution for web apps. I disagree that non-browser security is even a major priority at this point in time - it's adequately served by TLS and client certificates and/or Basic auth, depending on the security model desired - this latter I appreciate is a personal opinion. However there is no doubt at all that current webapp deployments are in need of a serious improvement in security, given that these generally use TLS only during authentication itself, and use plaintext usernames and passwords for the authentication itself. > Also, it seems like it would make the problem about a billion times > worse putting the auth into the application, where there are no > standards, and therefore it would need to be re-implemented for > each different application... kinda like what we have now already. Yet every webapp currently uses a form, and it's so close a standard that browsers can, and do, spot login forms and allow the credentials to be cached. As such, I fail to see why we wouldn't want to place better authentication at that layer, where it's quite likely to be actually used. > SASL is an orthogonal concept. It's just a framework to negotiate > auth, whether that's over HTTP or something else. So, it's a bit > of a red herring in this. Right, that's fair enough. > The trick is to get the application to actually use the auth of the > protocol. Yes, but the problem is that existing, deployed, webapps could use Basic right now - they all just ask for a username and password after all. Yet none of them do, in part because of integration issues, but mostly I suspect due to usability and branding issues. We could deploy some more advanced mechanisms in HTTP auth tomorrow, and nobody would use those either. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From lear@cisco.com Mon Dec 13 03:28:02 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C92723A6E8A; Mon, 13 Dec 2010 03:28:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.104 X-Spam-Level: X-Spam-Status: No, score=-110.104 tagged_above=-999 required=5 tests=[AWL=0.495, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6ZgrQY9HnNt; Mon, 13 Dec 2010 03:28:01 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 299D23A6D9A; Mon, 13 Dec 2010 03:28:00 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApkEABmSBU2Q/khNgWdsb2JhbACDXKAgFQEBFiIppjSKSZAggSGDNXQEink X-IronPort-AV: E=Sophos;i="4.59,335,1288569600"; d="scan'208";a="71514783" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 13 Dec 2010 11:29:37 +0000 Received: from dhcp-10-61-107-163.cisco.com (dhcp-10-61-107-163.cisco.com [10.61.107.163]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id oBDBTack011491; Mon, 13 Dec 2010 11:29:36 GMT Message-ID: <4D0603AA.7000004@cisco.com> Date: Mon, 13 Dec 2010 12:29:46 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Yoav Nir References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> In-Reply-To: <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Mon, 13 Dec 2010 03:56:45 -0800 Cc: "apps-discuss@ietf.org" , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [websec] [apps-discuss] [kitten] [saag] HTTP authentication: the next generation X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 11:28:02 -0000 And here-in lies the problem: I am concerned that in a large group we will not be able to reduce down to a single requirements list – AT THIS TIME. Also- my own experience is that having some decent proposals in front of you often helps drive at least SOME consolidation. From cabo@tzi.org Mon Dec 13 04:12:36 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB5B63A6D9E; Mon, 13 Dec 2010 04:12:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.316 X-Spam-Level: X-Spam-Status: No, score=-106.316 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vlx35im81SA2; Mon, 13 Dec 2010 04:12:35 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id A20C03A6DAA; Mon, 13 Dec 2010 04:12:34 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id oBDCE5FS003904; Mon, 13 Dec 2010 13:14:05 +0100 (CET) Received: from [192.168.217.101] (p5489B2BC.dip.t-dialin.net [84.137.178.188]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 908AF497; Mon, 13 Dec 2010 13:14:04 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <2229.1292239384.281779@puncture> Date: Mon, 13 Dec 2010 13:14:03 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org> References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> <2229.1292235952.971571@puncture> <4D05FB8F.3070804@qbik.com> <2229.1292239384.281779@puncture> To: General discussion of application-layer protocols , http-auth@ietf.org X-Mailer: Apple Mail (2.1082) Cc: Common Authentication Technologies - Next Generation , websec , saag@ietf.org, "ietf-http-wg@w3.org Group" Subject: Re: [websec] [kitten] [apps-discuss] [saag] HTTP authentication: the next generation X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 12:12:36 -0000 On Dec 13, 2010, at 12:23, Dave Cridland wrote: > every webapp currently uses a form Yes. Nice demonstration of conflicting requirements. As a webapp developer, I want to control the user interface during = authentication. Leaving the user alone with the bland and unforgiving browser user = interface for HTTP auth is suicide. I want to provide extra buttons for forgotten passwords, maybe even = password hints, and a "sign up" method. HTML/CSS/JS lends itself well to providing such a friendly user = interface. As a security geek, I recognize this as exactly the problem that creates = the potential for phishing. Having the user type credentials into a random form is never going to be = secure, HSTS notwithstanding. Maybe the only way to address both requirements is to have something in = HTML/CSS/JS that addresses authentication interactions. Replacing for the 21st century. This would = allow web app designers to design a nice context for this interaction, = and would allow running security protocols that are binding themselves = to a browser-server security association that may be identical to or = different from the TLS envelope. "Storing passwords" in the browser = might turn into storing those security associations. This is not "HTTP authentication", but it might be more useful in the = long run. We'll need the browser people to start any such effort. Gruesse, Carsten PS.: And I'd still like to have some better form of authentication for = machine-to-machine that can be independent from the TLS envelope. But = that is a completely different animal. From ynir@checkpoint.com Mon Dec 13 05:07:02 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6DB528C0DC; Mon, 13 Dec 2010 05:07:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.611 X-Spam-Level: X-Spam-Status: No, score=-9.611 tagged_above=-999 required=5 tests=[AWL=0.988, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QbzEQ2t+Rgvk; Mon, 13 Dec 2010 05:07:01 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 6A0423A6DA5; Mon, 13 Dec 2010 05:07:01 -0800 (PST) X-CheckPoint: {4D061AD6-A-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id oBDD8b6B008607; Mon, 13 Dec 2010 15:08:37 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 13 Dec 2010 15:08:37 +0200 From: Yoav Nir To: Carsten Bormann Date: Mon, 13 Dec 2010 15:08:40 +0200 Thread-Topic: [websec] [kitten] [apps-discuss] [saag] HTTP authentication: the next generation Thread-Index: AcuaxtqbIpwUgQEmQVSWqnfszltQeg== Message-ID: <5D5AF795-22AB-4726-B791-3706693466C3@checkpoint.com> References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> <2229.1292235952.971571@puncture> <4D05FB8F.3070804@qbik.com> <2229.1292239384.281779@puncture> <96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org> In-Reply-To: <96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: General discussion of application-layer protocols , websec , - Next Generation , "ietf-http-wg@w3.org Group" , "http-auth@ietf.org" , Common, "saag@ietf.org" Subject: Re: [websec] [kitten] [apps-discuss] [saag] HTTP authentication: the next generation X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 13:07:03 -0000 On Dec 13, 2010, at 2:14 PM, Carsten Bormann wrote: > On Dec 13, 2010, at 12:23, Dave Cridland wrote: >=20 >> every webapp currently uses a form >=20 > Yes. Nice demonstration of conflicting requirements. >=20 > As a webapp developer, I want to control the user interface during authen= tication. > Leaving the user alone with the bland and unforgiving browser user interf= ace for HTTP auth is suicide. > I want to provide extra buttons for forgotten passwords, maybe even passw= ord hints, and a "sign up" method. > HTML/CSS/JS lends itself well to providing such a friendly user interface= . Yes. That's a big part of the problem. To get the security result we're loo= king for, the login field has to be clearly marked. A user should never be = allowed to make the mistake of thinking that a regular input field is actua= lly the password field. With Basic Auth you get some very distinctive clues= (like the sheet in Safari). So if we invent , how can the browser show it that would not be possible to replicate wit= h HTML/CSS/JS ? >=20 > As a security geek, I recognize this as exactly the problem that creates = the potential for phishing. > Having the user type credentials into a random form is never going to be = secure, HSTS notwithstanding. Agree. > Maybe the only way to address both requirements is to have something in H= TML/CSS/JS that addresses authentication interactions. > Replacing for the 21st century. This would al= low web app designers to design a nice context for this interaction, and wo= uld allow running security protocols that are binding themselves to a brows= er-server security association that may be identical to or different from t= he TLS envelope. "Storing passwords" in the browser might turn into storin= g those security associations. I don't think the security requirements can be met using this (although I'd= love to hear differently from browser people). Maybe if we could customize= the authentication dialog with some kind of icon (like favicon), and maybe= a frame or a div with some HTML elements (buttons, links). I am not a UI = expert (IANAUIE ?) but I think it's important that user authentication be q= uite distinct from the rest of the flow. IOW the user should know that at t= his point, she is not just surfing, but actually authenticating to a partic= ular server, and if she's ever presented with some web form that says "user= name:_______ password:_______" she's going to know that something is wrong. >=20 > This is not "HTTP authentication", but it might be more useful in the lon= g run. > We'll need the browser people to start any such effort. Fully agree. We really need to hear from both browser people and web applic= ation developers. No point in designing something really secure if the peop= le in google/amazon/BOA then say "no, we'll never use that" >=20 > Gruesse, Carsten >=20 > PS.: And I'd still like to have some better form of authentication for ma= chine-to-machine that can be independent from the TLS envelope. But that i= s a completely different animal. >=20 > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec >=20 > Scanned by Check Point Total Security Gateway. From rstruik.ext@gmail.com Mon Dec 13 06:23:01 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1FFC3A6E96; Mon, 13 Dec 2010 06:23:01 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id peEEE9tCYakK; Mon, 13 Dec 2010 06:23:00 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 409653A690B; Mon, 13 Dec 2010 06:23:00 -0800 (PST) Received: by yxt33 with SMTP id 33so3650044yxt.31 for ; Mon, 13 Dec 2010 06:24:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=1tT+GrexpAZ7NlzzSLDH+8X2oYIY0smLBeIbflLlu/g=; b=lD5LVzV1VT4YSDgf2C7YbGx/+CBTIhrAdHYN77SDx1iAKZN+Cy8gfGhXQwX+JzI5sN cXWHk63csW2f9OZ5gvMszB4VSieVxzBPcJJAwgEm7yYIT1AG//TlR8r/hwzpVjJT7bj1 +SIcmXQoOsNmkmh4d0AQCPM+fD3DUZIeTqVro= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=qL4CAk0pZRGvXXOVfPdAnZPuos+9hTkJxxZMgrMDtNI0GLzx7CUnOvDllWM8WyqqPl beV46mb1o0S1n5gJAbZV11+4jROxbYgSUVGGaNoWO1yCLn6/2ksag385Ypk8h1qRlqN1 Xq1DWG760BZNvzaud8SMXBuvyCCGMyYYrDVn8= Received: by 10.42.179.131 with SMTP id bq3mr2768968icb.193.1292250277616; Mon, 13 Dec 2010 06:24:37 -0800 (PST) Received: from [192.168.1.102] (CPE0013100e2c51-CM00186851d6f6.cpe.net.cable.rogers.com [99.231.117.243]) by mx.google.com with ESMTPS id 8sm6276699iba.10.2010.12.13.06.24.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 13 Dec 2010 06:24:36 -0800 (PST) Message-ID: <4D062CA2.8040402@gmail.com> Date: Mon, 13 Dec 2010 09:24:34 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Yoav Nir References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> <4D056D83.2020704@extendedsubset.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ietf-http-wg@w3.org Group" , "http-auth@ietf.org" , websec , "saag@ietf.org" Subject: Re: [websec] [saag] [kitten] HTTP authentication: the next generation X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 14:23:02 -0000 Hi Yoav: Could you summarize the main problems with client certificates. To my knowledge, there are no technical problems with computational bottlenecks on the client side yet. The only problem area I could think of would be storage of private keys, but this seems solvable. Similarly, if you could point out main usability problems with certs that would be great (is this a general problem, or just an artifact of the way these are currently used?). Problems stem from realistic requirements not being met, so it is good to capture these. Rene == [excerpt email Yoav Nir as of Monday December 13, 2010, 3:49am EST] Client certificates would work even better, but client certificates have their own set of problems, which is why they're not widely used. I agree with you that layering whatever authentication on top of HTTP without at least message authentication is not a good idea, so TLS seems like the right choice - all those bank and email sites are already doing it. But we do need something more useable than certificates, and for now, this means passwords. On 13/12/2010 3:49 AM, Yoav Nir wrote: > On Dec 13, 2010, at 2:49 AM, Marsh Ray wrote: > >> On 12/12/2010 04:39 PM, Roy T. Fielding wrote: >>> Define them all and let's have a bake-off. It has been 16 years >>> since HTTP auth was taken out of our hands so that the security >>> experts could define something perfect. Zero progress so far. >> Perhaps it's a bad idea? > Disagree. Authentication is very much needed in the web. The current state is that websites have you fill in a form, and store a session cookie. We all know how this fails. An attacker can make a login page that looks like google's or paypal's or bankleumi.co.il just as easily as the respective organizations, and gain access to their credentials. > > This is good enough for Google, who need the cookies to track your searches and emails so as to match them to ads. A little bit of someone searching the web with someone else's userid doesn't make much difference to them. But if I have some important information in my gmail account, or money in bankleumi, I would like to avoid sending my password in the clear to an attacker's site. And things like SRP can do this. If SRP succeeds with a remote server, I know that it's the right server. > > Client certificates would work even better, but client certificates have their own set of problems, which is why they're not widely used. > > I agree with you that layering whatever authentication on top of HTTP without at least message authentication is not a good idea, so TLS seems like the right choice - all those bank and email sites are already doing it. But we do need something more useable than certificates, and for now, this means passwords. > >>> We >>> should just define everything and let the security experts do what >>> they do best -- find the holes and tell us what not to implement. >> I know some professional pen-testers who would love that! >> >> Check out these videos. This is what happens when you take a >> general-purpose authentication protocol and repurpose it for use across >> the internet for an insecure application protocol: >> >> http://extendedsubset.com/smb_relay_fully_patched.wmv >> http://extendedsubset.com/smb_reflection_arp_poisoning.wmv >> http://extendedsubset.com/?p=36 >> >> This case is NTLMv2, but the phenomenon is not limited to that. >> >> The problem is that most general-purpose authentication protocols do not >> require enough specificity about the context of the authentication: who >> and what are you authenticating, to whom, and how does each side know >> it's operating under the same beliefs as the other? >> >> This means that even if the client wants to be careful and authenticate >> only for the purpose of setting up a secure connection, the attacker can >> possibly forward that authentication to auth his own connection or >> transaction on some other service (on the same or even a different server). >> >> Most auth protocols don't let the client strongly verify the server's >> identity before the client has to authenticate with his own. This is >> probably at least in part because it requires some common infrastructure >> to do this. So Kerberos and x509 PKI systems can authenticate the server >> (and sometimes even the target service), but most others do not. >> >> Since HTTP lacks connection integrity, it's meaningless to speak of "an >> authenticated client". Perhaps the only thing that could be meaningfully >> authenticated is the request data itself. But auth protocols designed >> for setting up persistent connections typically don't have defined >> inputs for the message data/digest being signed, so it's often >> impractical to reuse them for that purpose. >> >> These issues have been mostly addressed at the protocol level for TLS >> client cert authentication. If it really just comes down to deployment >> and client usability issues, it's hard to imagine coming up with >> something at another layer which would have less risk than building on >> top of that. >> >> Deploying new uses of compatible, standard authentication protocols over >> insecure application protocols can be bad for the greater security >> ecosystem because it widens the field for cross-protocol attacks. >> >> - Marsh >> _______________________________________________ >> websec mailing list >> websec@ietf.org >> https://www.ietf.org/mailman/listinfo/websec >> >> Scanned by Check Point Total Security Gateway. > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag -- email: rstruik.ext@gmail.com Skype: rstruik cell: +1 (647) 867-5658 USA Google voice: +1 (415) 690-7363 From benl@google.com Mon Dec 13 04:07:11 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADD643A6E90 for ; Mon, 13 Dec 2010 04:07:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G+B6EZFuRkF8 for ; Mon, 13 Dec 2010 04:07:10 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id DD7303A6D9E for ; Mon, 13 Dec 2010 04:07:08 -0800 (PST) Received: from kpbe19.cbf.corp.google.com (kpbe19.cbf.corp.google.com [172.25.105.83]) by smtp-out.google.com with ESMTP id oBDC8jS6000349 for ; Mon, 13 Dec 2010 04:08:46 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1292242126; bh=IjyN8R0N33aGAIFAsPoKvVzfyyw=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=Yb3kzYgDWRmY5mxDWtFvaHfcsHnwpFnk7d/XudI0GYrG1a01QcMwyKKbTQO+DQwjw xZY2rLIyubGVind62c8pw== Received: from pzk28 (pzk28.prod.google.com [10.243.19.156]) by kpbe19.cbf.corp.google.com with ESMTP id oBDC8hET027905 for ; Mon, 13 Dec 2010 04:08:44 -0800 Received: by pzk28 with SMTP id 28so729539pzk.2 for ; Mon, 13 Dec 2010 04:08:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=jnk/rIg1eD9tZ2qzrBPET1JpYPZwhSbJgLeKzkK3VjE=; b=xbhr0gmJzm0BSQVE4EXZPxPvzxwDbzk8RYeu/+ztSagtknC/eRAIHNvgO9f4wsz56P CYomMJegFuaBAnXh8Dng== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Rw1xtelJDClcXIznUGgalnYuvnVjjorS/PQoclxpboKmnhAPy2zJmoWpritlHxlap0 Y59t0yFafY3Qv7+O0gBw== MIME-Version: 1.0 Received: by 10.142.199.20 with SMTP id w20mr3107000wff.419.1292242123701; Mon, 13 Dec 2010 04:08:43 -0800 (PST) Received: by 10.142.47.14 with HTTP; Mon, 13 Dec 2010 04:08:43 -0800 (PST) In-Reply-To: References: <4D02AF81.6000907@stpeter.im> Date: Mon, 13 Dec 2010 12:08:43 +0000 Message-ID: From: Ben Laurie To: Yoav Nir Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Mailman-Approved-At: Mon, 13 Dec 2010 06:35:19 -0800 Cc: "apps-discuss@ietf.org" , "pgut001@cs.auckland.ac.nz" , websec , Paul Hoffman , "kitten@ietf.org" , Yaron Sheffer , "http-auth@ietf.org" , "saag@ietf.org" , Hannes Tschofenig , "ietf-http-wg@w3.org Group" Subject: Re: [websec] [saag] HTTP authentication: the next generation X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 12:07:11 -0000 On 11 December 2010 23:10, Yoav Nir wrote: > TLS client certificates work, but as we've learned both with the web and with IPsec clients, people would much rather not use them. A few IETFs ago (Chicago?), a bunch of us tried to push the idea of TLS with EAP authentication. I think what we've learnt is that we need to provide good UI and portability if we want people to use them. From lear@cisco.com Mon Dec 13 05:44:17 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 689453A6E96; Mon, 13 Dec 2010 05:44:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.119 X-Spam-Level: X-Spam-Status: No, score=-110.119 tagged_above=-999 required=5 tests=[AWL=0.480, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txPFAo4BN0aO; Mon, 13 Dec 2010 05:44:16 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id B6EF53A6E8E; Mon, 13 Dec 2010 05:44:15 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApkEALOxBU2Q/khNgWdsb2JhbACDXKAlFQEBFiIppxWKSZAogSGBcYFEdASKeQ X-IronPort-AV: E=Sophos;i="4.59,335,1288569600"; d="scan'208";a="71525320" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 13 Dec 2010 13:45:53 +0000 Received: from dhcp-10-61-107-163.cisco.com (dhcp-10-61-107-163.cisco.com [10.61.107.163]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id oBDDjqBp005402; Mon, 13 Dec 2010 13:45:52 GMT Message-ID: <4D06239A.60208@cisco.com> Date: Mon, 13 Dec 2010 14:46:02 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Carsten Bormann References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> <2229.1292235952.971571@puncture> <4D05FB8F.3070804@qbik.com> <2229.1292239384.281779@puncture> <96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org> In-Reply-To: <96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 13 Dec 2010 06:35:19 -0800 Cc: General discussion of application-layer protocols , websec , Common Authentication Technologies - Next Generation , http-auth@ietf.org, saag@ietf.org, "ietf-http-wg@w3.org Group" Subject: Re: [websec] [apps-discuss] [kitten] [saag] HTTP authentication: the next generation X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 13:44:17 -0000 On 12/13/10 1:14 PM, Carsten Bormann wrote: > As a webapp developer, I want to control the user interface during authentication. > Leaving the user alone with the bland and unforgiving browser user interface for HTTP auth is suicide. > I want to provide extra buttons for forgotten passwords, maybe even password hints, and a "sign up" method. > HTML/CSS/JS lends itself well to providing such a friendly user interface. On the other hand, that's what you have today. What is it you want for tomorrow? Eliot From rstruik.ext@gmail.com Mon Dec 13 06:13:58 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2C523A6E96; Mon, 13 Dec 2010 06:13:58 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tBiJIxnDrIpw; Mon, 13 Dec 2010 06:13:57 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 74CD03A6D95; Mon, 13 Dec 2010 06:13:57 -0800 (PST) Received: by ywk9 with SMTP id 9so3651354ywk.31 for ; Mon, 13 Dec 2010 06:15:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=P5i8Kc7u5FqhkDnMlie+rutuFLwUoSYU5do7NyZWsbQ=; b=CisR3nG+yxO9DW0XZLSg8U/OW/FIWtiN0S+/2iOHlTWGoRqsiVxYJ/ShDdidUQGdcE 6QLjIQEtFXST/s5842N8lpaF68T2oF4Np/xXMfp9vxOuu3xopvf7nPXtRRp/gTOwjSkK mA0EBv0PXZWXDLOyAkrJF3q4IkrOw0PBuzCbU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=DTIqYuoWJKnu8bXvuGkZB4OkOOM8m2VPPP27IdY9balJxMirPQilOfSbIIPyO8ug1R Hwr1MGfucNvcyZOeC0JWXj8oQpvY4/ZBYIwVSXhlMbzfGE/8nv3qrizWCyheZtOpLht+ 3uirOY7QqUZSxHwFp1OhCt1AR65gy5CglH7QI= Received: by 10.42.241.132 with SMTP id le4mr2775035icb.356.1292249734922; Mon, 13 Dec 2010 06:15:34 -0800 (PST) Received: from [192.168.1.102] (CPE0013100e2c51-CM00186851d6f6.cpe.net.cable.rogers.com [99.231.117.243]) by mx.google.com with ESMTPS id y8sm15060ica.14.2010.12.13.06.15.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 13 Dec 2010 06:15:33 -0800 (PST) Message-ID: <4D062A83.5070107@gmail.com> Date: Mon, 13 Dec 2010 09:15:31 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Yoav Nir References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> <4D056D83.2020704@extendedsubset.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 13 Dec 2010 06:35:19 -0800 Cc: "ietf-http-wg@w3.org Group" , "http-auth@ietf.org" , websec , "saag@ietf.org" Subject: Re: [websec] [saag] [kitten] HTTP authentication: the next generation X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 14:13:58 -0000 Hi Yoav: Could you summarize the main problems with client certificates. To my knowledge, there are no technical problems with computational bottlenecks on the client side yet. The only problem area I could think of would be storage of private keys, but this seems solvable. Similarly, if you could point out main usability problems with certs that would be great (is this a general problem, or just an artifact of the way these are currently used?). Problems stem from realistic requirements not being met, so it is good to capture these. Rene == [excerpt email Yoav Nir as of Monday December 13, 2010, 3:49am EST] Client certificates would work even better, but client certificates have their own set of problems, which is why they're not widely used. I agree with you that layering whatever authentication on top of HTTP without at least message authentication is not a good idea, so TLS seems like the right choice - all those bank and email sites are already doing it. But we do need something more useable than certificates, and for now, this means passwords. On 13/12/2010 3:49 AM, Yoav Nir wrote: > Client certificates would work even better, but client certificates have their own set of problems, which is why they're not widely used. > > I agree with you that layering whatever authentication on top of HTTP without at least message authentication is not a good idea, so TLS seems like the right choice - all those bank and email sites are already doing it. But we do need something more useable than certificates, and for now, this means passwords. -- email: rstruik.ext@gmail.com Skype: rstruik cell: +1 (647) 867-5658 USA Google voice: +1 (415) 690-7363 From aland@deployingradius.com Mon Dec 13 06:15:21 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0275E3A6E96; Mon, 13 Dec 2010 06:15:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G+DQnsAnEMXX; Mon, 13 Dec 2010 06:15:20 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id 1E2D728C0E4; Mon, 13 Dec 2010 06:15:20 -0800 (PST) Message-ID: <4D062AD8.4080805@deployingradius.com> Date: Mon, 13 Dec 2010 15:16:56 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Yoav Nir References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> In-Reply-To: <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 13 Dec 2010 06:35:19 -0800 Cc: Eliot Lear , "apps-discuss@ietf.org" , websec , "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [websec] [saag] [apps-discuss] [kitten] HTTP authentication: the next generation X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 14:15:21 -0000 Yoav Nir wrote: > Because I'd rather not implement too many mechanisms in my browser or in my web server. > > And if EAP integrates better with RADIUS, It's more "already integrated with RADIUS", and "RADIUS integrates with LDAP". > while SASL integrates better with LDAP, it's still bad design to expose the server's backend to the client by the authentication protocol. EAP is already being transported over PPP, ethernet, RADIUS, Diameter, and other transport/authentication protocols. It's used because adding it is easy, and it separates the authentication protocols from the application. As for SASL, that's not my area. Alan DeKok. From ynir@checkpoint.com Mon Dec 13 07:27:43 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A56A28C0F8; Mon, 13 Dec 2010 07:27:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.642 X-Spam-Level: X-Spam-Status: No, score=-9.642 tagged_above=-999 required=5 tests=[AWL=0.956, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M51piqqtxI41; Mon, 13 Dec 2010 07:27:42 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id CC7693A6DCB; Mon, 13 Dec 2010 07:27:41 -0800 (PST) X-CheckPoint: {4D063BCF-4-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id oBDFTFYC004878; Mon, 13 Dec 2010 17:29:15 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 13 Dec 2010 17:29:15 +0200 From: Yoav Nir To: Rene Struik Date: Mon, 13 Dec 2010 17:29:17 +0200 Thread-Topic: [saag] [websec] [kitten] HTTP authentication: the next generation Thread-Index: Acua2n+idFmWhOqaTwCnviBIng6kdQ== Message-ID: <1D87D846-45C8-40EC-A0B9-96D61E5F6E65@checkpoint.com> References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> <4D056D83.2020704@extendedsubset.com> <4D062CA2.8040402@gmail.com> In-Reply-To: <4D062CA2.8040402@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_1D87D84645C840ECA0B996D61E5F6E65checkpointcom_" MIME-Version: 1.0 Cc: "ietf-http-wg@w3.org Group" , "http-auth@ietf.org" , websec , "saag@ietf.org" Subject: Re: [websec] [saag] [kitten] HTTP authentication: the next generation X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 15:27:43 -0000 --_000_1D87D84645C840ECA0B996D61E5F6E65checkpointcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Dec 13, 2010, at 4:24 PM, Rene Struik wrote: Hi Yoav: Could you summarize the main problems with client certificates. To my knowledge, there are no technical problems with computational bottlenecks on the client side yet. The only problem area I could think of would be storage of private keys, but this seems solvable. Similarly, if you could point out main usability problems with certs that would be great (is this a general problem, or just an artifact of the way these are currently used?). Problems stem from realistic requirements not being met, so it is good to capture these. I can see several problems with client certificates, most related to usabil= ity, but some also to security: * Certificates do not authenticate the user. They authenticate a device.= Placing a certificate on my laptop is a close enough approximation to auth= enticating *me*, but then I can't use the same certificate on my home compu= ter, my phone, or the computer at some Internet cafe or hotel business cent= er. Passwords, on the other hand, are with me wherever I go, and can be use= d with any device. * A possible solution to the first problem would be to issue multiple ce= rtificates for use in phone, laptop and desktop. But this makes the managem= ent of all these certificates even more complicated, and increases the atta= ck surface. * While some places of business, governments and militaries are willing = to spend the money and effort required to provision certificates for all em= ployees, I don't see companies doing it for customers. It's never a good id= ea to bet that something is too big for Google to do, but I can't imagine t= hem issuing client certificates to all gmail users. Even banks, with real m= oney at stake don't do it, because the support costs would exceed the losse= s to phishing. * Issuing certificates does not solve the problem with Internet cafes. I= t makes no sense for me to install a browser certificate on some random com= puter. But don't take my word for it. Certificates are so inconvenient, that peopl= e would rather use some two-factor authentication solution, where you type = in a password, and then get a one-time code on either a fob or through an S= MS message to your phone, which is what Marsh's company does. --_000_1D87D84645C840ECA0B996D61E5F6E65checkpointcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
On Dec 13, 2= 010, at 4:24 PM, Rene Struik wrote:

Hi Yoav:

Could you summarize th= e main problems with client certificates. To my
knowledge, there are no= technical problems with computational
bottlenecks on the client side y= et. The only problem area I could think
of would be storage of private = keys, but this seems solvable.

Similarly, if you could point out mai= n usability problems with certs
that would be great (is this a general = problem, or just an artifact of
the way these are currently used?). Pro= blems stem from realistic
requirements not being met, so it is good to = capture these.

I can see several probl= ems with client certificates, most related to usability, but some also to s= ecurity:

  • Certificate= s do not authenticate the user. They authenticate a device. Placing a certi= ficate on my laptop is a close enough approximation to authenticating *me*,= but then I can't use the same certificate on my home computer, my phone, o= r the computer at some Internet cafe or hotel business center. Passwords, o= n the other hand, are with me wherever I go, and can be used with any devic= e.
  • A possible solution to the first problem would be to issue multi= ple certificates for use in phone, laptop and desktop. But this makes the m= anagement of all these certificates even more complicated, and increases th= e attack surface.
  • While some places of business, governments and mi= litaries are willing to spend the money and effort required to provision ce= rtificates for all employees, I don't see companies doing it for customers.= It's never a good idea to bet that something is too big for Google to do, = but I can't imagine them issuing client certificates to all gmail users. Ev= en banks, with real money at stake don't do it, because the support costs w= ould exceed the losses to phishing.
  • Issuing certificates does not s= olve the problem with Internet cafes. It makes no sense for me to install a= browser certificate on some random computer. 

But don't take my word for it. Certificates are so inconvenient, that= people would rather use some two-factor authentication solution, where you= type in a password, and then get a one-time code on either a fob or throug= h an SMS message to your phone, which is what Marsh's company does.

= --_000_1D87D84645C840ECA0B996D61E5F6E65checkpointcom_-- From julian.reschke@gmx.de Mon Dec 13 07:37:49 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2075C28C111 for ; Mon, 13 Dec 2010 07:37:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.877 X-Spam-Level: X-Spam-Status: No, score=-104.877 tagged_above=-999 required=5 tests=[AWL=-2.278, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0MW3wAQ0OWU for ; Mon, 13 Dec 2010 07:37:48 -0800 (PST) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id A26833A6DD2 for ; Mon, 13 Dec 2010 07:37:47 -0800 (PST) Received: (qmail invoked by alias); 13 Dec 2010 15:39:23 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.133]) [217.91.35.233] by mail.gmx.net (mp013) with SMTP; 13 Dec 2010 16:39:23 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18UHbgtRrAUjdGBQU5gg4BvM7LRRZTDqhBbrFmn67 sCLQ8sxb3b/4dZ Message-ID: <4D063E2A.3010108@gmx.de> Date: Mon, 13 Dec 2010 16:39:22 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Peter Saint-Andre References: <4D02AF81.6000907@stpeter.im> In-Reply-To: <4D02AF81.6000907@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "apps-discuss@ietf.org" , websec@ietf.org, "kitten@ietf.org" , http-auth@ietf.org, saag@ietf.org, "ietf-http-wg@w3.org Group" Subject: Re: [websec] HTTP authentication: the next generation X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 15:37:49 -0000 On 10.12.2010 23:53, Peter Saint-Andre wrote: > Is it time to start thinking about next-generation authentication > technologies for HTTP? > > We all know that BASIC and DIGEST are ancient and crufty and lacking > many features and security properties we might want, but there hasn't > been much discussion about more modern approaches. Here are a few things > I've found: > ... Probably. But while doing so, we need to look at the existing base as well. HTTPbis now includes the HTTP authentication framework (essentially RFC2617 minus Basic and Digest). The HTTPbis WG is interested on feedback on the remaining issues (such as Realm required?, and considerations for new schemes). Also, I believe Basic is not going to go away, and I'd really like to fix its I18N problem. Proposal here: . Best regards, Julian From dave@cridland.net Mon Dec 13 07:14:43 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F7A83A6EA8; Mon, 13 Dec 2010 07:14:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oai1jUCwfRGx; Mon, 13 Dec 2010 07:14:42 -0800 (PST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by core3.amsl.com (Postfix) with ESMTP id 751923A6EA4; Mon, 13 Dec 2010 07:14:40 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 640601168110; Mon, 13 Dec 2010 15:16:17 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fI2-sW0P2Uy5; Mon, 13 Dec 2010 15:16:12 +0000 (GMT) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 9E21A11680FB; Mon, 13 Dec 2010 15:16:12 +0000 (GMT) References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> <2229.1292235952.971571@puncture> <4D05FB8F.3070804@qbik.com> <2229.1292239384.281779@puncture> <96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org> In-Reply-To: <96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org> MIME-Version: 1.0 Message-Id: <2229.1292253372.639419@puncture> Date: Mon, 13 Dec 2010 15:16:12 +0000 From: Dave Cridland To: Carsten Bormann , Common Authentication Technologies - Next Generation , websec , "saag@ietf.org" , "ietf-http-wg@w3.org Group" , General discussion of application-layer protocols , "http-auth@ietf.org" Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" X-Mailman-Approved-At: Mon, 13 Dec 2010 08:02:45 -0800 Subject: Re: [websec] [apps-discuss] [kitten] [saag] HTTP authentication: the next generation X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 15:14:43 -0000 On Mon Dec 13 12:14:03 2010, Carsten Bormann wrote: > Maybe the only way to address both requirements is to have > something in HTML/CSS/JS that addresses authentication interactions. > Replacing for the 21st century. This > would allow web app designers to design a nice context for this > interaction, and would allow running security protocols that are > binding themselves to a browser-server security association that > may be identical to or different from the TLS envelope. "Storing > passwords" in the browser might turn into storing those security > associations. > > Or storing credentials rather than username/password pairs, possibly. But in any case, I think that's close to what we want. As I say, I think we need to establish a session credential of some kind that can be used over unencrypted sessions with some improvement in security over typical fixed cookies that exist today. I'm fine if one of these credential options happens to tie into a TLS property, but I think we'll have to have reasonable security over non-TLS, too. (And by "reasonable", I'm expecting this to be "not as good as if you had TLS") And I absolutely agree that this effort needs strong support from the browser implementors from the start - we also need the same from a few major webapps. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From yaronf.ietf@gmail.com Mon Dec 13 07:31:32 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A940F28C113; Mon, 13 Dec 2010 07:31:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.999 X-Spam-Level: X-Spam-Status: No, score=-102.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZ8HbcaePJoN; Mon, 13 Dec 2010 07:31:29 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 9A8C328C111; Mon, 13 Dec 2010 07:31:28 -0800 (PST) Received: by wyf23 with SMTP id 23so6133663wyf.31 for ; Mon, 13 Dec 2010 07:33:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=+0szgrNyk3mkmUDxf309oDZ+9GRtr8meNZqDA8AcMUE=; b=dNDusxC6geA5feEhxkQO/3IBIf77RSA4FBQR+bRQEH5tRXO/8PbfYInvGtfM9K8trB hcCmyCPLhLZDyJghltMS9GriRS04fRXtgKCYQbBqKzCt67nUbMaoehetoJAzO/+z7NgW Qd/tH93nfYIo2etamhq1o40Uf5iY0/vfVQCus= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=ordqzJOVIbEfXFOsrikEoukznWeWMJCAiKTavCcDclq3YG2b4+ifhCv+/xIbEbrVvF bUpQvvk84xgm+pBbhP2bOCrwpM3LeQDpzqpCaAtJBKdvymqaMMv5wGqUxNRmsyHZ+S/T Mco8vjpjuS7KD/s07YacFrp4iBmzd1JkDQZMU= Received: by 10.227.155.138 with SMTP id s10mr1735853wbw.61.1292254386127; Mon, 13 Dec 2010 07:33:06 -0800 (PST) Received: from [10.0.0.1] (bzq-79-176-46-32.red.bezeqint.net [79.176.46.32]) by mx.google.com with ESMTPS id m10sm4489129wbc.16.2010.12.13.07.32.56 (version=SSLv3 cipher=RC4-MD5); Mon, 13 Dec 2010 07:33:04 -0800 (PST) Message-ID: <4D063CA5.8060907@gmail.com> Date: Mon, 13 Dec 2010 17:32:53 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Yoav Nir References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> <2229.1292235952.971571@puncture> <4D05FB8F.3070804@qbik.com> <2229.1292239384.281779@puncture> <96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org> <5D5AF795-22AB-4726-B791-3706693466C3@checkpoint.com> In-Reply-To: <5D5AF795-22AB-4726-B791-3706693466C3@checkpoint.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 13 Dec 2010 08:02:45 -0800 Cc: Common@core3.amsl.com, General discussion of application-layer protocols , websec , - Next Generation , "http-auth@ietf.org" , "ietf-http-wg@w3.org Group" , "saag@ietf.org" Subject: Re: [websec] [saag] [kitten] [apps-discuss] HTTP authentication: the next generation X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 15:31:33 -0000 Just like the phrase "I am not a lawyer" is always followed by amateur legal advice (I know that for sure, I've done it myself), the same goes for "I am not a UI expert". Two comments: - There are in fact a few security-usability experts. I don't know if any of them participate in the IETF. This is an emerging research field, see e.g. http://oreilly.com/catalog/9780596008277. - (I am not a UI expert, but...) Devising UI cues is extremely difficult. People will gladly enter their password when the web site displays a JPEG-rendered padlock icon. In fact *legitimate* sites have been known to display such icons, strange as it may sound. Thanks, Yaron On 12/13/2010 03:08 PM, Yoav Nir wrote: > > On Dec 13, 2010, at 2:14 PM, Carsten Bormann wrote: > >> On Dec 13, 2010, at 12:23, Dave Cridland wrote: >> >>> every webapp currently uses a form >> >> Yes. Nice demonstration of conflicting requirements. >> >> As a webapp developer, I want to control the user interface during authentication. >> Leaving the user alone with the bland and unforgiving browser user interface for HTTP auth is suicide. >> I want to provide extra buttons for forgotten passwords, maybe even password hints, and a "sign up" method. >> HTML/CSS/JS lends itself well to providing such a friendly user interface. > > Yes. That's a big part of the problem. To get the security result we're looking for, the login field has to be clearly marked. A user should never be allowed to make the mistake of thinking that a regular input field is actually the password field. With Basic Auth you get some very distinctive clues (like the sheet in Safari). So if we invent, how can the browser show it that would not be possible to replicate with HTML/CSS/JS ? > >> >> As a security geek, I recognize this as exactly the problem that creates the potential for phishing. >> Having the user type credentials into a random form is never going to be secure, HSTS notwithstanding. > > Agree. > >> Maybe the only way to address both requirements is to have something in HTML/CSS/JS that addresses authentication interactions. >> Replacing for the 21st century. This would allow web app designers to design a nice context for this interaction, and would allow running security protocols that are binding themselves to a browser-server security association that may be identical to or different from the TLS envelope. "Storing passwords" in the browser might turn into storing those security associations. > > I don't think the security requirements can be met using this (although I'd love to hear differently from browser people). Maybe if we could customize the authentication dialog with some kind of icon (like favicon), and maybe a frame or a div with some HTML elements (buttons, links). I am not a UI expert (IANAUIE ?) but I think it's important that user authentication be quite distinct from the rest of the flow. IOW the user should know that at this point, she is not just surfing, but actually authenticating to a particular server, and if she's ever presented with some web form that says "username:_______ password:_______" she's going to know that something is wrong. > >> >> This is not "HTTP authentication", but it might be more useful in the long run. >> We'll need the browser people to start any such effort. > > Fully agree. We really need to hear from both browser people and web application developers. No point in designing something really secure if the people in google/amazon/BOA then say "no, we'll never use that" > >> >> Gruesse, Carsten >> >> PS.: And I'd still like to have some better form of authentication for machine-to-machine that can be independent from the TLS envelope. But that is a completely different animal. >> >> _______________________________________________ >> websec mailing list >> websec@ietf.org >> https://www.ietf.org/mailman/listinfo/websec >> >> Scanned by Check Point Total Security Gateway. > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From ynir@checkpoint.com Mon Dec 13 07:49:17 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D15E28C0FB; Mon, 13 Dec 2010 07:49:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.673 X-Spam-Level: X-Spam-Status: No, score=-9.673 tagged_above=-999 required=5 tests=[AWL=0.926, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zflb53p1RFGT; Mon, 13 Dec 2010 07:49:16 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id D009628C0E4; Mon, 13 Dec 2010 07:49:15 -0800 (PST) X-CheckPoint: {4D0640DD-4-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id oBDFooSV009459; Mon, 13 Dec 2010 17:50:50 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 13 Dec 2010 17:50:50 +0200 From: Yoav Nir To: Yaron Sheffer Date: Mon, 13 Dec 2010 17:50:52 +0200 Thread-Topic: [saag] [websec] [kitten] [apps-discuss] HTTP authentication: the next generation Thread-Index: Acua3YNg2kbXw68wS5e96OwOd0Ko4A== Message-ID: <878FA115-D801-4063-AD87-DB2C2B2DE0D1@checkpoint.com> References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> <2229.1292235952.971571@puncture> <4D05FB8F.3070804@qbik.com> <2229.1292239384.281779@puncture> <96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org> <5D5AF795-22AB-4726-B791-3706693466C3@checkpoint.com> <4D063CA5.8060907@gmail.com> In-Reply-To: <4D063CA5.8060907@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 13 Dec 2010 08:02:45 -0800 Cc: "Common@core3.amsl.com" , protocols , websec , -, General, Generation , "http-auth@ietf.org" , "ietf-http-wg@w3.org Group" , "saag@ietf.org" Subject: Re: [websec] [saag] [kitten] [apps-discuss] HTTP authentication: the next generation X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 15:49:17 -0000 On Dec 13, 2010, at 5:32 PM, Yaron Sheffer wrote: > Just like the phrase "I am not a lawyer" is always followed by amateur=20 > legal advice (I know that for sure, I've done it myself), the same goes=20 > for "I am not a UI expert". >=20 > Two comments: >=20 > - There are in fact a few security-usability experts. I don't know if=20 > any of them participate in the IETF. This is an emerging research field,= =20 > see e.g. http://oreilly.com/catalog/9780596008277. >=20 > - (I am not a UI expert, but...) Devising UI cues is extremely=20 > difficult. People will gladly enter their password when the web site=20 > displays a JPEG-rendered padlock icon. I don't know how to stop them, unless the "special" UI cue becomes so ubiqu= itous, that its absence causes the user to think, "wait a minute. This does= not look like authentication!" As long as every website has authentication that looks different and not di= fferent enough from regular web browsing, people are going to accept any we= b form as a legitimate authentication dialog. > In fact *legitimate* sites have=20 > been known to display such icons, strange as it may sound. >=20 > Thanks, > Yaron From stpeter@stpeter.im Mon Dec 13 09:49:14 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA63B28C112 for ; Mon, 13 Dec 2010 09:49:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.806 X-Spam-Level: X-Spam-Status: No, score=-102.806 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id opEAOHscI-fK for ; Mon, 13 Dec 2010 09:49:14 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 01A6D28C0F7 for ; Mon, 13 Dec 2010 09:49:14 -0800 (PST) Received: from dhcp-64-101-72-234.cisco.com (dhcp-64-101-72-234.cisco.com [64.101.72.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2ACB6400F6 for ; Mon, 13 Dec 2010 11:03:11 -0700 (MST) Message-ID: <4D065CFE.8060109@stpeter.im> Date: Mon, 13 Dec 2010 10:50:54 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: websec@ietf.org X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080204080703090501000203" Subject: [websec] where to discuss HTTP authentication X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 17:49:15 -0000 This is a cryptographically signed message in MIME format. --------------ms080204080703090501000203 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Howdy. As you've noticed, the websec list has been full of discussion about HTTP authentication. However, I cc'd the websec list only to keep people here in the loop about the discussion. If you are interested in this topic, please join the http-auth list (and don't cc websec): https://www.ietf.org/mailman/listinfo/http-auth Thanks! Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms080204080703090501000203 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTIx MzE3NTA1NFowIwYJKoZIhvcNAQkEMRYEFANFj1CqJxuI2sW0f2obZ+XS7JuXMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQANUf8uXEbkYJhP5SfKXv2PJhkDlybfox8Th9+KSit92Y8NwjtsmKVLz2T3 4DodHbyjH3D3nJ1IN43XVo87z9YmJ6VGDVI1xMibW5mxMhLgwvcGfcETErWxPg+IpzS8LoZg 7/0fBa8Y7/oWYaRsGeOofZMyFSl3UbQEcYHKzusd9g2TXgG6k9jizu2H9ros3SnOQhx4oaUQ we82tKXjdsjYH6rORV6S7FfFmd9pj6ccMqruJmBn/y4ddMt378klNhaAE8yN9qAV9IWk/lpF /rLJBRKuXqpuOkOSnTFPkHSuIYy6qF9TdI3Pohr7+fhq2r7IL3w5g2pajWDWvDRSHYSPAAAA AAAA --------------ms080204080703090501000203-- From tobias.gondrom@gondrom.org Mon Dec 13 10:03:10 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 269AA3A6EB9 for ; Mon, 13 Dec 2010 10:03:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.124 X-Spam-Level: X-Spam-Status: No, score=-95.124 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xl8PBQe4Rlmp for ; Mon, 13 Dec 2010 10:03:09 -0800 (PST) Received: from lvps83-169-7-107.dedicated.hosteurope.de (lvps83-169-7-107.dedicated.hosteurope.de [83.169.7.107]) by core3.amsl.com (Postfix) with ESMTP id A94063A6DE5 for ; Mon, 13 Dec 2010 10:03:08 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=XC4qhtXxSBi41iqCq0jEKophYqJ7kgds+nujUL6H9oMmXEG2x7qHbE3t9sjU+qNP//nZ9c5PdEQaIJ5FfCl1pAbzqqNmrjfpGP/zCXyu7ujmLDSNwrE9Ln5QQC7EA6CQ; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:X-Priority:References:In-Reply-To:X-Enigmail-Version:Content-Type; Received: (qmail 16357 invoked from network); 13 Dec 2010 19:04:05 +0100 Received: from 94-194-102-93.zone8.bethere.co.uk (HELO seraphim.heaven) (94.194.102.93) by lvps83-169-7-107.dedicated.hosteurope.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 13 Dec 2010 19:04:05 +0100 Message-ID: <4D066076.1010206@gondrom.org> Date: Mon, 13 Dec 2010 18:05:42 +0000 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101026 SUSE/3.1.6 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: websec@ietf.org, apps-discuss@ietf.org X-Priority: 4 (Low) References: <4D065CFE.8060109@stpeter.im> In-Reply-To: <4D065CFE.8060109@stpeter.im> X-Enigmail-Version: 1.1.1 Content-Type: multipart/alternative; boundary="------------080507010505020108050902" Subject: Re: [websec] where to discuss HTTP authentication X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 18:03:10 -0000 This is a multi-part message in MIME format. --------------080507010505020108050902 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Thank you Peter for the info. If you're interested in the topic of HTTP auth, please don't copy WEBSEC on your messages but instead join the http-auth list: https://www.ietf.org/mailman/listinfo/http-auth Unless you believe it is of explicit interest to the websec wg's work. Tobias chair of websec On 12/13/2010 05:50 PM, Peter Saint-Andre wrote: > Howdy. As you've noticed, the websec list has been full of discussion > about HTTP authentication. However, I cc'd the websec list only to keep > people here in the loop about the discussion. If you are interested in > this topic, please join the http-auth list (and don't cc websec): > > https://www.ietf.org/mailman/listinfo/http-auth > > Thanks! > > Peter > > > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec --------------080507010505020108050902 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Thank you Peter for the info.
If you're interested in the topic of HTTP auth, please don't copy WEBSEC on your messages but instead join the http-auth list:

https://www.ietf.org/mailman/listinfo/http-auth

Unless you believe it is of explicit interest to the websec wg's work.

Tobias
chair of websec




On 12/13/2010 05:50 PM, Peter Saint-Andre wrote: 
Howdy. As you've noticed, the websec list has been full of discussion
about HTTP authentication. However, I cc'd the websec list only to keep
people here in the loop about the discussion. If you are interested in
this topic, please join the http-auth list (and don't cc websec):

https://www.ietf.org/mailman/listinfo/http-auth

Thanks!

Peter



_______________________________________________
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

--------------080507010505020108050902-- From marsh@extendedsubset.com Mon Dec 13 11:23:03 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7037028C0DF; Mon, 13 Dec 2010 11:23:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eiu44KNobs2s; Mon, 13 Dec 2010 11:23:01 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 11CFF3A6DEB; Mon, 13 Dec 2010 11:23:01 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1PSE0k-000367-F9; Mon, 13 Dec 2010 19:24:38 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 794AD60C6; Mon, 13 Dec 2010 19:24:34 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/Q37PlkAZHnTRK33n7uni+GlAsvheYsbA= Message-ID: <4D0672F2.4070600@extendedsubset.com> Date: Mon, 13 Dec 2010 13:24:34 -0600 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Yoav Nir References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> <2229.1292235952.971571@puncture> <4D05FB8F.3070804@qbik.com> <2229.1292239384.281779@puncture> <96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org> <5D5AF795-22AB-4726-B791-3706693466C3@checkpoint.com> <4D063CA5.8060907@gmail.com> <878FA115-D801-4063-AD87-DB2C2B2DE0D1@checkpoint.com> In-Reply-To: <878FA115-D801-4063-AD87-DB2C2B2DE0D1@checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 13 Dec 2010 12:55:04 -0800 Cc: "Common@core3.amsl.com" , protocols , websec , General@core3.amsl.com, Generation , Yaron Sheffer , "http-auth@ietf.org" , "ietf-http-wg@w3.org Group" , "saag@ietf.org" Subject: Re: [websec] [saag] [kitten] [apps-discuss] HTTP authentication: the next generation X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2010 19:23:03 -0000 On 12/13/2010 09:29 AM, Yoav Nir wrote: > > On Dec 13, 2010, at 4:24 PM, Rene Struik wrote: > >> Hi Yoav: >> >> Could you summarize the main problems with client certificates. To >> my knowledge, there are no technical problems with computational >> bottlenecks on the client side yet. The only problem area I could >> think of would be storage of private keys, but this seems >> solvable. >> >> Similarly, if you could point out main usability problems with >> certs that would be great (is this a general problem, or just an >> artifact of the way these are currently used?). Problems stem from >> realistic requirements not being met, so it is good to capture >> these. > > I can see several problems with client certificates, most related to > usability, but some also to security: > > * Certificates do not authenticate the user. They authenticate a > device. I don't think they do that exactly either. The client cert is generally public, its private key is a secret like a password, but one that's too hard to memorize. > Placing a certificate on my laptop is a close enough > approximation to authenticating *me*, but then I can't use the same > certificate on my home computer, my phone, Why not? > or the computer at some > Internet cafe or hotel business center. But there's nothing that you can do securely on an untrusted computer. Sometimes people propose the idea of a secure boot CD users carry around, but those can't defend against trojaned firmware or hardware. > Passwords, on the other hand, > are with me wherever I go, and can be used with any device. They have some pretty significant limitations too. > * A possible solution to the first problem would be to issue multiple > certificates for use in phone, laptop and desktop. But this makes the > management of all these certificates even more complicated, N users, M sites. N is billions, M is millions. N * M = a big number. Perhaps if we accept it as an inherently complicated problem then we can give people tools that they need? > and increases the attack surface. Honestly, could it be any worse? > * While some places of business, governments and militaries are > willing to spend the money and effort required to provision > certificates for all employees, I don't see companies doing it for > customers. It's never a good idea to bet that something is too big > for Google to do, but I can't imagine them issuing client > certificates to all gmail users. Ha! I bet if we double-dog dared them, they just might. Remember that they went all-TLS for gmail, when every other smaller site was saying it was un-economic. > Even banks, with real money at stake > don't do it, because the support costs would exceed the losses to > phishing. My understanding is that some banks do, in fact, use client certs. But from what I've seen, the economics and risk motivations of the banking sector are just really weird. It varies by country, and in the US it's still not entirely clear yet who's liable for losses due to online security. Banking is just so different than everyone else that it's usually not helpful to use it as an example it in general security discussion. > * Issuing certificates does not solve the problem with Internet > cafes. It makes no sense for me to install a browser certificate on > some random computer. Again, there's nothing you can do to make a login session secure from an untrusted machine. Perhaps we should throw this scenario out for the purposes of this discussion? > But don't take my word for it. Certificates are so inconvenient, that > people would rather use some two-factor authentication solution, > where you type in a password, and then get a one-time code on either > a fob or through an SMS message to your phone, which is what Marsh's > company does. The key thing is that the phone is something most people already have and are comfortable using. It's hard to overstate the value of that. Nevertheless, what we (well, Marketing in particular :-) are continually up against is this: on some level, the entire purpose of strengthening the authentication is to make it harder to log in to the computer. We can do our best to minimize how much harder it is for the legitimate user, and maximize how much harder it is for the bad guy, but at the end of the day the system ends up having more ways to say 'no'. For most systems, the vast majority of 'no's are not actual attacks. Theatrics that don't provide real security are obviously worthless, but so are strong systems that people don't use. This trade-off between security and usability is very real, not theoretical. Perfect example: On 12/13/2010 06:14 AM, Carsten Bormann wrote: > > As a webapp developer, I want to control the user interface during > authentication. Leaving the user alone with the bland and > unforgiving browser user interface for HTTP auth is suicide. I want > to provide extra buttons for forgotten passwords, maybe even > password hints, and a "sign up" method. Yeah. How did the user select their password for the website in the first place, if not by an HTML form POST? If it was good enough for the initial sign up, why should the web designer use something other than HTML form POST for the regular login? (These are rhetorical questions.) > HTML/CSS/JS lends itself > well to providing such a friendly user interface. > > As a security geek, I recognize this as exactly the problem that > creates the potential for phishing. Having the user type > credentials into a random form is never going to be secure, HSTS > notwithstanding. Right. Any time there's an untrusted app painting into a rectangle (e.g. the browser window) the only ways to communicate with the user securely is outside of that rectangle. Which is why the URL and lock icon are in the browser chrome (and why we're in the out-of-band authentication business). As people use more mobile devices with smaller screens, this chrome gets mostly optimized away (and may confuse the degree to which the phone is truly out-of-band). There's clearly a large set of users for whom this "rectangle" principle is too complicated. (It probably doesn't help that browsers allow web pages to open new windows, set the title bar and icon, and that they repurpose the untrusted rectangle to discuss certificate errors.) The most secure way I've seen to handle password entry is (don't laugh) MS Windows NT through Vista. Windows NT implemented Orange Book security and required a "secure attention key" sequence (ctrl+alt+del) before every password request. Vista UAC, though a failure in many ways, would switch the entire console session, going so far as to reinitializing hardware drivers in the process. It performs a whole-screen dimming effect which was said to be difficult to duplicate (I'm not sure in practice). So IMHO, significant improvements in web authentication would be greatly beneficial. But they will have to: * Require connection integrity. This probably means mandatory TLS. * Require a user interaction that takes place outside the insecure browser rectangle and feels different enough that it's easy to explain the difference. * Not leak info to untrusted parties. These days privacy is often more important than traditional security. * Support browser vendors in making a UI that "sucks less" to have to use, or possibly have to use it less. Put users in control of their identity and auth credentials without nagging them repeatedly until they give in and click the "Yes to all" button. * Represent an actual improvement in security over the current standard of HTML form POST password and secret HTTP session cookie. - Marsh From y.oiwa@aist.go.jp Mon Dec 13 22:24:41 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EEE13A6E3A; Mon, 13 Dec 2010 22:24:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.345 X-Spam-Level: X-Spam-Status: No, score=-5.345 tagged_above=-999 required=5 tests=[AWL=-5.255, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QB+AzlpHWPT6; Mon, 13 Dec 2010 22:24:39 -0800 (PST) Received: from faust.rcis.jp (faust.rcis.jp [61.194.89.210]) by core3.amsl.com (Postfix) with ESMTP id DAB4E3A6E3C; Mon, 13 Dec 2010 22:24:38 -0800 (PST) Received: from [192.168.58.137] (pl432.nas936.p-tokyo.nttpc.ne.jp [219.102.56.176]) (authenticated bits=0) by faust.rcis.jp (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id oBE6PkkY015716 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 14 Dec 2010 15:25:49 +0900 Message-ID: <4D070DEC.707@aist.go.jp> Date: Tue, 14 Dec 2010 15:25:48 +0900 From: Yutaka OIWA Organization: RCIS, AIST User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Yoav Nir References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <2230EA03-32C5-4D34-BC6B-304E813BE3A7@gbiv.com> <4D056D83.2020704@extendedsubset.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "ietf-http-wg@w3.org Group" , "http-auth@ietf.org" , websec , "saag@ietf.org" Subject: Re: [websec] [http-auth] [kitten] [saag] HTTP authentication: the next generation X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: http-auth@ietf.org List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2010 06:24:41 -0000 Dear Yoav, [notice: Reply-to limited] (1) I largely agree with your view on Cookie and Client certificates. Client certificates are only useful for Web world in very limited cases. In reality, many banks in Japan (may be in US too?) introduce cert authentication for corporate-account on-line banking but not for personal account counterparts. It introduce heavy burden for both server and client sides, which cannot be justified for required security. Also, use cases of Web authentication is not limited to the "strong identity" which usually tied with the client certificates and CA hierarchies. In many use-cases sites introduce simple interfaces accepting "almost anonymous" registrations. Issuing a certificate for every user of every such services is unlikely, and tieing those accounts with existing client certificates introduces serious privacy concerns. (2) However, I am not agreeing with putting the authentication in the layer lower than HTTP. TLS authentication will only work for site-wide fixed setting of authentications, which is not deployable for large numbers of websites. See how Yahoo serves for both unauthenticated and authenticated users, and how Google implements their "GMail for your domains" (log in/out control is independent for each domain-account, hosted on the single server). More technically, It is semantically wrong. HTTP has two layers of "messaging channels" inside it: the lower level is a "keep-alive" stream transport (TCP and TLS), and the higher level is a packet interface made by pairs of a request and a response. From the application point of view, the authorization happens on the higher level. For each resources the server may either request or not request the authentication, and the clients respond with that. The resources on a single server may belong to several separate "authentication realms", including special "unauthenticated" one. For such settings, authentication should be tied to the "higher level" in whatever way. If you put authentication in the lower level, requests for the different realms wil mix up in the inappropriate lower channel. Changing those semantics is too hard and seems inappropriate for any deployments. This gives an answer for the reason that *for some Web/HTTP application* TLS auth works: each of these is so simple enough that it only have a one "authentication realm" inside it. The corporate banking is so, and so is IPP. It is also true for many non-HTTP TLS applications such as POP3 and IMAP. But it is not true for general Web applications, end we cannot enforce such design restrictions for Web services. People often concern about the security impact which arise from putting auth in the higher layer. Such a problem can be solved technically, for example by using channel bindings. Careful designs of protocols can gives even better operational properties than TLS-based authentications. For example, our Mutual auth proposal can be used securely on HTTPS, preventing man-in-the-middle credential forwarding attacks, while allowing off-loading of TLS overhead to existing hardware TLS accelerators without any changes. (4) For non-TLS applications: in the real world I've heard too much voices about inapplicabilities of HTTPS in the real systems. I think that authentication in the non-HTTPS world MUST be improved, too. In fact, not a single person asked (requested) me whether our Mutual authentication can be used for integrity protection on non-HTTPS responces, as HTTPS is not deployable for whole their services, and they need to improve authentication (and integrity). On 2010/12/13 17:49, Yoav Nir wrote: > > On Dec 13, 2010, at 2:49 AM, Marsh Ray wrote: > >> On 12/12/2010 04:39 PM, Roy T. Fielding wrote: >>> >>> Define them all and let's have a bake-off. It has been 16 years >>> since HTTP auth was taken out of our hands so that the security >>> experts could define something perfect. Zero progress so far. >> >> Perhaps it's a bad idea? > > Disagree. Authentication is very much needed in the web. The current state is that websites have you fill in a form, and store a session cookie. We all know how this fails. An attacker can make a login page that looks like google's or paypal's or bankleumi.co.il just as easily as the respective organizations, and gain access to their credentials. > > This is good enough for Google, who need the cookies to track your searches and emails so as to match them to ads. A little bit of someone searching the web with someone else's userid doesn't make much difference to them. But if I have some important information in my gmail account, or money in bankleumi, I would like to avoid sending my password in the clear to an attacker's site. And things like SRP can do this. If SRP succeeds with a remote server, I know that it's the right server. > > Client certificates would work even better, but client certificates have their own set of problems, which is why they're not widely used. > > I agree with you that layering whatever authentication on top of HTTP without at least message authentication is not a good idea, so TLS seems like the right choice - all those bank and email sites are already doing it. But we do need something more useable than certificates, and for now, this means passwords. > >> >>> We >>> should just define everything and let the security experts do what >>> they do best -- find the holes and tell us what not to implement. >> >> I know some professional pen-testers who would love that! >> >> Check out these videos. This is what happens when you take a >> general-purpose authentication protocol and repurpose it for use across >> the internet for an insecure application protocol: >> >> http://extendedsubset.com/smb_relay_fully_patched.wmv >> http://extendedsubset.com/smb_reflection_arp_poisoning.wmv >> http://extendedsubset.com/?p=36 >> >> This case is NTLMv2, but the phenomenon is not limited to that. >> >> The problem is that most general-purpose authentication protocols do not >> require enough specificity about the context of the authentication: who >> and what are you authenticating, to whom, and how does each side know >> it's operating under the same beliefs as the other? >> >> This means that even if the client wants to be careful and authenticate >> only for the purpose of setting up a secure connection, the attacker can >> possibly forward that authentication to auth his own connection or >> transaction on some other service (on the same or even a different server). >> >> Most auth protocols don't let the client strongly verify the server's >> identity before the client has to authenticate with his own. This is >> probably at least in part because it requires some common infrastructure >> to do this. So Kerberos and x509 PKI systems can authenticate the server >> (and sometimes even the target service), but most others do not. >> >> Since HTTP lacks connection integrity, it's meaningless to speak of "an >> authenticated client". Perhaps the only thing that could be meaningfully >> authenticated is the request data itself. But auth protocols designed >> for setting up persistent connections typically don't have defined >> inputs for the message data/digest being signed, so it's often >> impractical to reuse them for that purpose. >> >> These issues have been mostly addressed at the protocol level for TLS >> client cert authentication. If it really just comes down to deployment >> and client usability issues, it's hard to imagine coming up with >> something at another layer which would have less risk than building on >> top of that. >> >> Deploying new uses of compatible, standard authentication protocols over >> insecure application protocols can be bad for the greater security >> ecosystem because it widens the field for cross-protocol attacks. >> >> - Marsh >> _______________________________________________ >> websec mailing list >> websec@ietf.org >> https://www.ietf.org/mailman/listinfo/websec >> >> Scanned by Check Point Total Security Gateway. > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth -- 大岩 寛 Yutaka Oiwa 独立行政法人 産業技術ç·åˆç ”究所 情報セキュリティ研究センター ソフトウェアセキュリティ研究ãƒãƒ¼ãƒ  , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] From gregory@is.naist.jp Wed Dec 15 08:30:12 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9851E28C19A for ; Wed, 15 Dec 2010 08:30:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aZKjXDI2Dp+M for ; Wed, 15 Dec 2010 08:30:11 -0800 (PST) Received: from mailrelay11.naist.jp (mailrelay11.naist.jp [163.221.80.162]) by core3.amsl.com (Postfix) with ESMTP id CDF5F28C199 for ; Wed, 15 Dec 2010 08:30:11 -0800 (PST) Received: from mailpost11.naist.jp (mailscan11.naist.jp [163.221.80.161]) by mailrelay11.naist.jp (Postfix) with ESMTP id 87121FFD for ; Thu, 16 Dec 2010 01:31:53 +0900 (JST) Received: from naist.jp (mailbox11-a.naist.jp [163.221.80.153]) by mailpost11.naist.jp (Postfix) with ESMTP id 7B6A2FFC for ; Thu, 16 Dec 2010 01:31:53 +0900 (JST) Received: from [127.0.0.1] (Forwarded-For: 163.221.52.181) by webmail11.naist.jp (mshttpd); Thu, 16 Dec 2010 01:31:53 +0900 From: "Blanc Gregory" To: websec Message-ID: <71c0e78249b5.4d096c09@naist.jp> Date: Thu, 16 Dec 2010 01:31:53 +0900 X-Mailer: Sun Java(tm) System Messenger Express 7.3-11.01 64bit (built Sep 1 2009) MIME-Version: 1.0 Content-Language: ja X-Accept-Language: ja Priority: normal In-Reply-To: <4D01201E.8000007@gondrom.org> References: <4D01201E.8000007@gondrom.org> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable X-TM-AS-Product-Ver: IMSS-7.0.0.8105-6.0.0.1038-17832.000 X-TM-AS-Result: No--26.369-5.0-31-1 X-imss-scan-details: No--26.369-5.0-31-1 Subject: Re: [websec] request for feedback on adoption of drafts to WG - until Dec-16 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Dec 2010 16:30:12 -0000 Hello=2C I would say yes though hodges-strict-transport-sec is about enforcing secure HTTP transport which I though was out of the scope=2E Am I mistak= en=3F Regards=2C Greg 12/10/10 =E3=81=AB=E3=80=81Tobias Gondrom =3Ctobias=2Egondrom=40gondrom= =2Eorg=3E =E3=81=95=E3=82=93=E3=81=AF=E6=9B=B8=E3=81=8D=E3=81=BE=E3=81=97= =E3=81=9F=3A =3E Hello dear fellow websec members=2C = =3E = =3E = =3E = =3E during the hasmat BOF in July and the websec charter consensus t= hree =3E individual drafts were listed as to be worked on as first items = in =3E our working group=2E I did so far not formally ask for WG consen= sus on =3E adopting these three documents until now=3B our area director =3E suggested that it would be appropriate to do so before they are =3E re-submitted as working group drafts=2E = =3E = =3E = =3E = =3E So I would like to ask for your feedback on adopting the followi= ng =3E three individual drafts as WG documents (as outlined in the =3E charter)=3A = =3E = =3E = =3E = =3E - draft-abarth-origin=3A = =3E = =3E http=3A//tools=2Eietf=2Eorg/tools/rfcmarkup/rfcmarkup=2Ecgi=3Fdr= aft=3Ddraft-abarth-origin =3E = =3E =C2=A0=C2=A0=C2=A0 = =3E = =3E - hodges-strict-transport-sec=3A = =3E = =3E =C2=A0 http=3A//tools=2Eietf=2Eorg/tools/rfcmarkup/rfcmarkup=2Ec= gi=3Fdraft=3Ddraft-hodges-strict-transport-sec =3E = =3E = =3E = =3E - draft-abarth-mime-sniff=3A = =3E = =3E http=3A//tools=2Eietf=2Eorg/tools/rfcmarkup/rfcmarkup=2Ecgi=3Fdr= aft=3Ddraft-abarth-mime-sniff =3E = =3E = =3E = =3E Please reply (=22yes=22 (for adoption) or =22no=22 (against adop= tion)=2C both =3E are important) - either for each draft individually or for all t= hree =3E drafts as a bundle - to the list by Thurs 16th December 2010 =3E (24=3A00GMT)=2E = =3E = =3E = =3E = =3E Kind regards and thanks a lot=2C = =3E = =3E = =3E = =3E Tobias =3E = =3E chair of websec =3E = =3E = =3E = =3E = =3E = =3E = =3E = =3E = =3E = =3E = =3E =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =3E websec mailing list =3E websec=40ietf=2Eorg =3E https=3A//www=2Eietf=2Eorg/mailman/listinfo/websec From marsh@extendedsubset.com Thu Dec 16 11:31:19 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E5B93A69C8; Thu, 16 Dec 2010 11:31:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PaS+aehBc6ck; Thu, 16 Dec 2010 11:31:18 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 435043A69C7; Thu, 16 Dec 2010 11:31:17 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1PTJZW-000DRV-CF; Thu, 16 Dec 2010 19:33:02 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 8B07360C6; Thu, 16 Dec 2010 19:32:58 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/FJrTY9uCYiXUNsZ5gCCuFYP7jyQqh5RI= Message-ID: <4D0A6969.7010309@extendedsubset.com> Date: Thu, 16 Dec 2010 13:32:57 -0600 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: der Mouse References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> <2229.1292235952.971571@puncture> <4D05FB8F.3070804@qbik.com> <2229.1292239384.281779@puncture> <96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org> <5D5AF795-22AB-4726-B791-3706693466C3@checkpoint.com> <4D063CA5.8060907@gmail.com> <878FA115-D801-4063-AD87-DB2C2B2DE0D1@checkpoint.com> <4D0672F2.4070600@extendedsubset.com> <201012161827.NAA03511@Sparkle.Rodents-Montreal.ORG> In-Reply-To: <201012161827.NAA03511@Sparkle.Rodents-Montreal.ORG> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org, websec@ietf.org, kitten@ietf.org, http-auth@ietf.org, ietf-http-wg@w3.org, saag@ietf.org Subject: Re: [websec] [http-auth] [saag] [kitten] [apps-discuss] HTTP authentication: the next generation X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2010 19:31:19 -0000 On 12/16/2010 12:27 PM, der Mouse wrote: > > Quite aside from memorizability, few-to-no humans are capable of > performing the cryptographic operations (large-number arithmetic, > usually) necessary to carry out certificate operations, at least not > with the required levels of reliability. (I can do multi-hundred-digit > arithmetic, yes, but not nearly either fast enough or free enough of > mistakes to be useful for the purpose.) Which is a good argument for it being an example of something a computer is better at. Many auth systems have a component which involves something humans are good at and computers are lousy at. > Certificates, at best, determine that some device which is capable of > performing the cryptographic operations has been given access to the > corresponding private data.... All passwords demonstrate is > that some device capable of injecting data into the comm channel in > question knows the password. That's a good way to describe it. > But passwords rarely lull people into > forgetting the difference. Pen-and-paper signatures work because people have thousands of years of history behind pen technology. It fits well the courtroom test "did you or did you not sign that document". It surely happens, but is extremely rare that someone who actually signed a contract would later claim that it was a forgery, or that their pen and paper were compromised by an attacker. >> For most systems, the vast majority of 'no's are not actual attacks. > > Are you sure of that? There are an awful lot of doorknob-rattlers out > there. Most of the login failures I see on my machines actually _are_ > attackers poking to see if I've made stupid mistakes. OK so there's a baseline attack rate for any given port number. If you use the system infrequently enough, attackers outweigh the legitimate users. But, for example, I personally mistype my password about 10 to 25% of the time. That's a correct 'authentication denied' scenario but it's not an attack. Systems with a meaningful amount of legitimate activity, and are not specially targeted for some reason, are going to have many more mistyped passwords than credible attacks. >> Yeah. How did the user select their password for the website in the >> first place, if not by an HTML form POST? > >> If it was good enough for the initial sign up, why should the web >> designer use something other than HTML form POST for the regular >> login? > > For all that that's rhetorical, there is an answer: because one occurs > only once while the other occurs many times. I bet for a lot of systems, people sign up once and try it out then go away and leave their accounts dormant. E.g., I might create an account to buy tickets for something and never go back. So why can't the attacker attack it that one time then? You've never signed up for a new account from a hotel or a public wifi? Even still, how do you convince a web designer that they must give up their HTML login form for security when they have an HTML login form to choose the password in the first place? - Marsh From hallam@gmail.com Sat Dec 18 08:46:57 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60F373A6B32; Sat, 18 Dec 2010 08:46:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.351 X-Spam-Level: X-Spam-Status: No, score=-3.351 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sV17309iSGMG; Sat, 18 Dec 2010 08:46:56 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 6A1333A6B31; Sat, 18 Dec 2010 08:46:55 -0800 (PST) Received: by ywk9 with SMTP id 9so813314ywk.31 for ; Sat, 18 Dec 2010 08:48:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=ijwI0GcNw4czVPTgUUhQd5LnD/RhxnVpgX9bs7S46fo=; b=f96paZmYl+d36RVMk/yETNHaI+A0ENWSmj9gEcmHadBN3MOj2LNYl7KGFFCjRSpSZl qzAVYfc3oq62xCBzMEpSAqxmVjTbNL8qfBAuJIwDLwT9JR+FkXDZEHKr8uuAO/foYCMT uK8nrOVgxXkHnHcly1gWX0vlutoC5GSyY4nQs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=W15I6zVxvEU7S1jlvsHCHLRXhE4NgdTTYqYbij3m0QzKNxBHgjmx+2rjdXGf4nkr1H VxhhU7heQRETf1mM/zhx2oVrjmblBwQgMTEz4MPWcVnuz0oBbUUzN02nTGeP11GS4djp 4xqDuMZueByWSToL4nYZwhauFryx8cPJdLEUc= MIME-Version: 1.0 Received: by 10.101.67.16 with SMTP id u16mr1380812ank.1.1292690922503; Sat, 18 Dec 2010 08:48:42 -0800 (PST) Received: by 10.100.31.8 with HTTP; Sat, 18 Dec 2010 08:48:42 -0800 (PST) In-Reply-To: <2229.1292253372.639419@puncture> References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> <2229.1292235952.971571@puncture> <4D05FB8F.3070804@qbik.com> <2229.1292239384.281779@puncture> <96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org> <2229.1292253372.639419@puncture> Date: Sat, 18 Dec 2010 16:48:42 +0000 Message-ID: From: Phillip Hallam-Baker To: Common Authentication Technologies - Next Generation , websec , "saag@ietf.org" , "ietf-http-wg@w3.org Group" , General discussion of application-layer protocols , "http-auth@ietf.org" Content-Type: multipart/alternative; boundary=00163662e65b3d7fce0497b20fd7 Subject: Re: [websec] [apps-discuss] [kitten] [saag] HTTP authentication: the next generation X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Dec 2010 16:46:57 -0000 --00163662e65b3d7fce0497b20fd7 Content-Type: text/plain; charset=ISO-8859-1 I think that we need to distinguish between an authentication mechanism and an authentication infrastructure. Part of the problem with HTTP authentication is that it was quickly superseded by HTML based authentication mechanisms. And these in turn suffer from the problem that password authentication fails when people share their passwords across sites, which of course they have no choice but to do when every stupid web site requires them to create yet another stupid account. Since Digest Authentication became an RFC, I don't think there has ever been more than about 6 weeks elapsed without someone suggesting to me that we include SHA1 or SHA2 as a digest algorithm. Which is of course pointless when the major flaw in the authentication infrastructure is the lack of an authentication infrastructure. The original reason for designing Digest the way that I did was that public key cryptography was encumbered. Had public key cryptography been available, I would have used it. By authentication infrastructure, I mean an infrastructure that allows the user to employ the same credentials at multiple sites with minimal or no user interaction. I do not mean a framework that allows for the use of 20 different protocols for verifying a username and password. We do have almost as many proposals for federated authentication as authentication schemes of course. But each time there seems to be an obsession with things that technocrats obsess about and at best contempt for the actual user. OpenID almost succeeded. But why on earth did we have to adopt URIs as the means of representing a user account? And why was it necessary to design a spec around the notion that what mattered most in the design of the spec was the ability to hack together an account manager using obsolete versions of common scripting languages? Another feature of that debate I cannot understand is why we had to start talking about 'identity' as if it was some new and somehow profound problem that had only just been discovered. There is of course a standard for representing federated user accounts that has already emerged on the net. And once that is realized, the technical requirements of a solution become rather obvious. As Web sites discover that their account holders cannot remember their username, most have adopted email addresses as account identifiers. That is what we should use as the basis for federated web authentication. So if the user account identifier looks like username@example.com, how does an entity verify that a purported user has a valid claim to that account? The obvious mechanism in my view is to use DNS based discovery of an authentication service. For example, we might use the ESRV scheme I have been working on: _auth._ws.example.com ESRV 0 prot "_saml._ws" _auth._ws.example.com ESRV 0 prot "_xcat._ws" Which declares that the SAML and 'XCAT' (presumably kitten in XML) protocols may be used to resolve authentication requests. One major advantage of this approach is that it makes it easy for sites to move to using the new federated auth scheme. Most sites already store an email address that is used to validate the account. The actual mechanism by which the authentication claim is verified is not very interesting, nor does it particularly need to be standardized. What does require standardization is the ability to embed the protocol in 'the Web' in a fluent and secure manner. Here is how I suggest this be achieved: 1) HTTP header The Web browser attaches an offer of authentication by means of an account attached to a specific domain to (potentially) every request: Auth-N: domain=example.com If the server does not support Auth-N, the header will simply be ignored. Otherwise the server can ask for automated authentication. 2) HTTP Response If the server decides to use the authentication mechanism, it responds with information that tells the client what level of authentication is required. For example, a bank might require a 2 factor scheme. There is going to be at a minimum a nonce. Auth-N: snonce=<128bits> 3) HTTP Request It should be possible for the client to prove that it has ownership of the authentication token corresponding to the account. It is not necessarily the case that the account owner wants to reveal to the site all their information. For example, it may not even want the site to know the account name. This is all fairly easy to set up using symmetric techniques. Auth-N: domain=example.com; blindedaccount=<> snonce=<128bits>; cnonce=<128bits> One feature that the OpenID work has highlighted the need for is some form of user directed account manager. If the user is going to be in control of this process, they need to be able to specify what information is made available to specific sites. Conclusion: I think that what we require here is not yet another authentication framework or protocol. What we need is the glue to bind it into an infrastructure that makes it useful. The most important design decision is to make use of RFC822 email address format as the format for federated authentication accounts. Once that decision is made, the rest will simply fall out of stating the requirements precisely. The risk here is that yet again we end up redo-ing the parts that we know how to build rather than focus on the real problem which is fitting them together. Above all, the user has to be the first priority in any design. --00163662e65b3d7fce0497b20fd7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think that we need to distinguish between an authentication mechanism and= an authentication infrastructure.

Part of the problem with HTTP authentication is that it= was quickly=A0superseded by HTML based authentication mechanisms. And thes= e in turn suffer from the problem that password authentication fails when p= eople share their passwords across sites, which of course they have no choi= ce but to do when every stupid web site requires them to create yet another= stupid account.=A0

Since Digest Authentication became an RFC, I don't = think there has ever been more than about 6 weeks elapsed without someone s= uggesting to me that we include SHA1 or SHA2 as a digest algorithm. Which i= s of course pointless when the major flaw in the authentication infrastruct= ure is the lack of an authentication infrastructure. The original reason fo= r designing Digest the way that I did was that public key cryptography was = encumbered. Had public key cryptography been available, I would have used i= t.

By authentication infrastructure, I mean an infrastruct= ure that allows the user to employ the same credentials at multiple sites w= ith minimal or no user interaction. I do not mean a framework that allows f= or the use of 20 different protocols for verifying a username and password.=


We do have almost as many proposals for = federated authentication as authentication schemes of course. But each time= there seems to be an obsession with things that technocrats obsess about a= nd at best contempt for the actual user.

OpenID almost succeeded. But why on earth did we have t= o adopt URIs as the means of representing a user account? And why was it ne= cessary to design a spec around the notion that what mattered most in the d= esign of the spec was the ability to hack together an account manager using= obsolete versions of common scripting languages?

Another feature of that debate I cannot understand is w= hy we had to start talking about 'identity' as if it was some new a= nd somehow profound problem that had only just been discovered.


There is of course a standard for representin= g federated user accounts that has already emerged on the net. And once tha= t is realized, the technical requirements of a solution become rather obvio= us.

As Web sites discover that their account holders cannot= remember their username, most have adopted email addresses as account iden= tifiers. That is what we should use as the basis for federated web authenti= cation.=A0


So if the user account identifier looks = like username@example.com, how = does an entity verify that a purported user has a valid claim to that accou= nt?

The obvious mechanism in my view is to use DNS based di= scovery of an authentication service. For example, we might use the ESRV sc= heme I have been working on:

_auth._ws.example.com =A0ESRV 0 prot "_saml._ws"=
_auth._ws.ex= ample.com =A0ESRV 0 prot "_xcat._ws"

Which declares that the SAML and 'XCAT' (presumably kitten in XML)= protocols may be used to resolve authentication requests.


One major advantage of this approach is = that it makes it easy for sites to move to using the new federated auth sch= eme. Most sites already store an email address that is used to validate the= account.=A0


The actual mechanism by which the authen= tication claim is verified is not very interesting, nor does it particularl= y need to be standardized. What does require standardization is the ability= to embed the protocol in 'the Web' in a fluent and secure manner.<= /div>

Here is how I suggest this be achieved:

<= /div>
1) HTTP header

The Web browser attaches = an offer of authentication by means =A0of an account attached to a specific= domain to (potentially) every request:

Auth-N: domain=3Dexample= .com

If the server does not support Auth-N, th= e header will simply be ignored. Otherwise =A0the server can ask for automa= ted authentication.


2) HTTP Response

If the server decides to use the authentication mechanism, it responds wi= th information that tells the client what level of authentication is requir= ed. For example, a bank might require a 2 factor scheme. There is going to = be at a minimum a nonce.

Auth-N: snonce=3D<128bits>= ;



3) HTTP Request

It should be possible for the client to prove that i= t has ownership of the authentication token corresponding to the account.= =A0

It is not necessarily the case that the account owner w= ants to reveal to the site all their information. For example, it may not e= ven want the site to know the account name. This is all fairly easy to set = up using symmetric techniques.

Auth-N: domain=3Dexample.com; blindedaccount=3D<> snonce=3D<12= 8bits>; cnonce=3D<128bits>


One feature that the OpenID work has highlighted the need for is some form= of user directed account manager. If the user is going to be in control of= this process, they need to be able to specify what information is made ava= ilable to specific sites.


Conclusion:

I t= hink that what we require here is not yet another authentication framework = or protocol. What we need is the glue to bind it into an infrastructure tha= t makes it useful.

The most important design decision is to make use of RF= C822 email address format as the format for federated authentication accoun= ts.=A0

Once that decision is made, the rest will s= imply fall out of stating the requirements precisely.=A0

The risk here is that yet again we end up redo-ing the = parts that we know how to build rather than focus on the real problem which= is fitting them together.=A0

Above all, the user = has to be the first priority in any design.=A0
--00163662e65b3d7fce0497b20fd7-- From nathan@webr3.org Sun Dec 19 05:52:06 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E7C63A68FB for ; Sun, 19 Dec 2010 05:52:06 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CEK3BB5mXuiG for ; Sun, 19 Dec 2010 05:52:06 -0800 (PST) Received: from p3plsmtpa01-10.prod.phx3.secureserver.net (p3plsmtpa01-10.prod.phx3.secureserver.net [72.167.82.90]) by core3.amsl.com (Postfix) with SMTP id 70C123A68F7 for ; Sun, 19 Dec 2010 05:52:02 -0800 (PST) Received: (qmail 8465 invoked from network); 19 Dec 2010 13:47:14 -0000 Received: from unknown (86.156.126.71) by p3plsmtpa01-10.prod.phx3.secureserver.net (72.167.82.90) with ESMTP; 19 Dec 2010 13:47:13 -0000 Message-ID: <4D0E0CDA.6030605@webr3.org> Date: Sun, 19 Dec 2010 13:47:06 +0000 From: Nathan Organization: webr3 User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Adrien de Croy References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> <2229.1292235952.971571@puncture> <4D05FB8F.3070804@qbik.com> <2229.1292239384.281779@puncture> <96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org> <2229.1292253372.639419@puncture> <4D0DE882.50201@qbik.com> In-Reply-To: <4D0DE882.50201@qbik.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 19 Dec 2010 05:57:36 -0800 Cc: General discussion of application-layer protocols , websec , foaf-protocols , Common Authentication Technologies - Next Generation , "http-auth@ietf.org" , "saag@ietf.org" , Story Henry , "ietf-http-wg@w3.org Group" Subject: Re: [websec] [apps-discuss] [kitten] [saag] HTTP authentication: the next generation X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: nathan@webr3.org List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Dec 2010 13:52:06 -0000 Hi Adrien, All, What you describe sounds very much like WebID Protocol (formerly FOAF+SSL) - there's an incubator group just starting at the W3C [1] although the protocol [2] has been under development for some time. Essentially it leverages X509 certificates on the client side, which contains an identifier (in the form of a URI) which can then be dereferenced to machine readable data (containing the public key from the x509 and any other data the entity wishes to expose), it serves as decentralized stateless authentication / identification, compatible with and built on the deployed stack of internet technologies, and further enables all kinds of trust & reputation hooks. cc'd: Henry Story, foaf-protocols [1] http://bblfish.net/tmp/2010/12/15/webid-charter-draft.html [2] http://getwebid.org/spec/drafts/ED-webid-20100809/index.html Best, Nathan Adrien de Croy wrote: > I think we need to go a bit further and consider the issue of trust. > > one problem with delegating account-holding back to a domain under the control > of the account-holder, is you have no trust. I could be hacker@hackyou.com or > spammer@spamyou.com. I can set up whatever account I like. Websites have no > information about whether I'm trustworthy or not, and have to build up their own > individual profile of me. > > To be really useful, the account-holding must be with a trusted independent > organisation able to be relied on by other websites. > > The organisation then has the opportunity to add value by > > a) verifying the true identity of the account holder > b) maintaining reputation information about the account holder > c) revoking abusive accounts. > > Ends up looking a lot like X.509 certificate infrastructure. Imagine if > everyone needed a client certificate to send any mail. We'd have no spam. > > Of course these sorts of concepts are completely unpalatable to many people on > account of privacy issues. Some of these activities are the sort of things that > governments should really be doing (and already are in many cases). > > Solving this problem has implications for all internet use, not just HTTP. > > Regards > > Adrien > > On 19/12/2010 5:48 a.m., Phillip Hallam-Baker wrote: >> I think that we need to distinguish between an authentication mechanism and an >> authentication infrastructure. >> >> Part of the problem with HTTP authentication is that it was quickly superseded >> by HTML based authentication mechanisms. And these in turn suffer from the >> problem that password authentication fails when people share their passwords >> across sites, which of course they have no choice but to do when every stupid >> web site requires them to create yet another stupid account. >> >> Since Digest Authentication became an RFC, I don't think there has ever been >> more than about 6 weeks elapsed without someone suggesting to me that we >> include SHA1 or SHA2 as a digest algorithm. Which is of course pointless when >> the major flaw in the authentication infrastructure is the lack of an >> authentication infrastructure. The original reason for designing Digest the >> way that I did was that public key cryptography was encumbered. Had public key >> cryptography been available, I would have used it. >> >> By authentication infrastructure, I mean an infrastructure that allows the >> user to employ the same credentials at multiple sites with minimal or no user >> interaction. I do not mean a framework that allows for the use of 20 different >> protocols for verifying a username and password. >> >> >> We do have almost as many proposals for federated authentication as >> authentication schemes of course. But each time there seems to be an obsession >> with things that technocrats obsess about and at best contempt for the actual >> user. >> >> OpenID almost succeeded. But why on earth did we have to adopt URIs as the >> means of representing a user account? And why was it necessary to design a >> spec around the notion that what mattered most in the design of the spec was >> the ability to hack together an account manager using obsolete versions of >> common scripting languages? >> >> Another feature of that debate I cannot understand is why we had to start >> talking about 'identity' as if it was some new and somehow profound problem >> that had only just been discovered. >> >> >> There is of course a standard for representing federated user accounts that >> has already emerged on the net. And once that is realized, the technical >> requirements of a solution become rather obvious. >> >> As Web sites discover that their account holders cannot remember their >> username, most have adopted email addresses as account identifiers. That is >> what we should use as the basis for federated web authentication. >> >> >> So if the user account identifier looks like username@example.com >> , how does an entity verify that a purported user >> has a valid claim to that account? >> >> The obvious mechanism in my view is to use DNS based discovery of an >> authentication service. For example, we might use the ESRV scheme I have been >> working on: >> >> _auth._ws.example.com ESRV 0 prot "_saml._ws" >> _auth._ws.example.com ESRV 0 prot "_xcat._ws" >> >> Which declares that the SAML and 'XCAT' (presumably kitten in XML) protocols >> may be used to resolve authentication requests. >> >> >> One major advantage of this approach is that it makes it easy for sites to >> move to using the new federated auth scheme. Most sites already store an email >> address that is used to validate the account. >> >> >> The actual mechanism by which the authentication claim is verified is not very >> interesting, nor does it particularly need to be standardized. What does >> require standardization is the ability to embed the protocol in 'the Web' in a >> fluent and secure manner. >> >> Here is how I suggest this be achieved: >> >> 1) HTTP header >> >> The Web browser attaches an offer of authentication by means of an account >> attached to a specific domain to (potentially) every request: >> >> Auth-N: domain=example.com >> >> If the server does not support Auth-N, the header will simply be ignored. >> Otherwise the server can ask for automated authentication. >> >> >> 2) HTTP Response >> >> If the server decides to use the authentication mechanism, it responds with >> information that tells the client what level of authentication is required. >> For example, a bank might require a 2 factor scheme. There is going to be at a >> minimum a nonce. >> >> Auth-N: snonce=<128bits> >> >> >> >> 3) HTTP Request >> >> It should be possible for the client to prove that it has ownership of the >> authentication token corresponding to the account. >> >> It is not necessarily the case that the account owner wants to reveal to the >> site all their information. For example, it may not even want the site to know >> the account name. This is all fairly easy to set up using symmetric techniques. >> >> Auth-N: domain=example.com ; blindedaccount=<> >> snonce=<128bits>; cnonce=<128bits> >> >> >> One feature that the OpenID work has highlighted the need for is some form of >> user directed account manager. If the user is going to be in control of this >> process, they need to be able to specify what information is made available to >> specific sites. >> >> >> Conclusion: >> >> I think that what we require here is not yet another authentication framework >> or protocol. What we need is the glue to bind it into an infrastructure that >> makes it useful. >> >> The most important design decision is to make use of RFC822 email address >> format as the format for federated authentication accounts. >> >> Once that decision is made, the rest will simply fall out of stating the >> requirements precisely. >> >> The risk here is that yet again we end up redo-ing the parts that we know how >> to build rather than focus on the real problem which is fitting them together. >> >> Above all, the user has to be the first priority in any design. > > -- > Adrien de Croy - WinGate Proxy Server - http://www.wingate.com > From benl@google.com Sun Dec 19 13:48:07 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E138D3A6905 for ; Sun, 19 Dec 2010 13:48:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.295 X-Spam-Level: X-Spam-Status: No, score=-105.295 tagged_above=-999 required=5 tests=[AWL=-0.531, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_MILLIONS=1.213, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6nh1y4CSRjVr for ; Sun, 19 Dec 2010 13:48:07 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 1C89A3A6901 for ; Sun, 19 Dec 2010 13:48:07 -0800 (PST) Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id oBJLnvRa002414 for ; Sun, 19 Dec 2010 13:49:57 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1292795398; bh=uWfAZT2M3FpdI4YhLUhCaX5+M+w=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=OD1uee4PbeTNIzspa9tXpfqfld3OoNVEeo9VJpa48wXtODEiONuRIfoOimAhPwD/q YndRSlESn9E7uh84txA4A== Received: from qwe5 (qwe5.prod.google.com [10.241.194.5]) by kpbe14.cbf.corp.google.com with ESMTP id oBJLnueC024739 for ; Sun, 19 Dec 2010 13:49:56 -0800 Received: by qwe5 with SMTP id 5so2442823qwe.26 for ; Sun, 19 Dec 2010 13:49:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=MfXLHtS0HhUmrdwYRuE7bZ/eaVoK3BSZWCEkYhNpwsM=; b=RS5mloI+ufvR0ZaoyqZrPac8GNuGrEPoI57fwDihC+87Dj4AEkALfT8JXCW5yfAdIp ccynlurtA78G5JQuY/Ww== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=jEZ4eidTTY/ulcVKzn0G7Y5AUrzK1L8k2PDf1jp/J1txMZwtXuRzacanp9VZi89s0d NVl9hMudenCxuH3MfY+w== MIME-Version: 1.0 Received: by 10.229.81.12 with SMTP id v12mr3084026qck.35.1292795396286; Sun, 19 Dec 2010 13:49:56 -0800 (PST) Received: by 10.220.126.219 with HTTP; Sun, 19 Dec 2010 13:49:56 -0800 (PST) In-Reply-To: <4D0DE882.50201@qbik.com> References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> <2229.1292235952.971571@puncture> <4D05FB8F.3070804@qbik.com> <2229.1292239384.281779@puncture> <96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org> <2229.1292253372.639419@puncture> <4D0DE882.50201@qbik.com> Date: Sun, 19 Dec 2010 21:49:56 +0000 Message-ID: From: Ben Laurie To: Adrien de Croy Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: General discussion of application-layer protocols , websec , Common Authentication Technologies - Next Generation , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [websec] [saag] [apps-discuss] [kitten] HTTP authentication: the next generation X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Dec 2010 21:48:08 -0000 On 19 December 2010 11:12, Adrien de Croy wrote: > Imagine if > everyone needed a client certificate to send any mail.=A0 We'd have no sp= am. Nonsense. We'd just restrict spam to owned machines, of which there are only a few tens or hundreds of milliions, if we're lucky. From marsh@extendedsubset.com Sun Dec 19 14:02:03 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67EF43A6911; Sun, 19 Dec 2010 14:02:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.985 X-Spam-Level: X-Spam-Status: No, score=-1.985 tagged_above=-999 required=5 tests=[AWL=-0.599, BAYES_00=-2.599, SARE_OBFU_MILLIONS=1.213] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8qCV2TyjfYu; Sun, 19 Dec 2010 14:02:02 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id A327C3A6910; Sun, 19 Dec 2010 14:02:02 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1PURMA-000Jc4-IS; Sun, 19 Dec 2010 22:03:54 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id A4FA360C7; Sun, 19 Dec 2010 22:03:52 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18timQ4um115qKSoyKjKv9Us5qWv7NZVf4= Message-ID: <4D0E8148.7060607@extendedsubset.com> Date: Sun, 19 Dec 2010 16:03:52 -0600 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Ben Laurie References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> <2229.1292235952.971571@puncture> <4D05FB8F.3070804@qbik.com> <2229.1292239384.281779@puncture> <96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org> <2229.1292253372.639419@puncture> <4D0DE882.50201@qbik.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: General discussion of application-layer protocols , Adrien de Croy , websec , Common Authentication Technologies - Next Generation , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [websec] [saag] [apps-discuss] [kitten] HTTP authentication: the next generation X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Dec 2010 22:02:03 -0000 On 12/19/2010 03:49 PM, Ben Laurie wrote: > On 19 December 2010 11:12, Adrien de Croy wrote: >> Imagine if >> everyone needed a client certificate to send any mail. We'd have no spam. > > Nonsense. We'd just restrict spam to owned machines, of which there > are only a few tens or hundreds of milliions, if we're lucky. Nonsense. We'd have no mail. Or rather some other store-and-forward messaging system would arise and not be called mail. Look back far enough and you'll find all kinds of "electronic mail" services implementing the full range of peer and end user authentication, and sender-pays models. There was no spam on those systems, or at least not enough that anyone felt like they needed a word for it. Guess why we use the one we use today. - Marsh From benl@google.com Mon Dec 20 03:21:00 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74C703A6A20 for ; Mon, 20 Dec 2010 03:21:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.482 X-Spam-Level: X-Spam-Status: No, score=-104.482 tagged_above=-999 required=5 tests=[AWL=-2.505, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3x+z2zKvqhec for ; Mon, 20 Dec 2010 03:20:59 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 79A473A6996 for ; Mon, 20 Dec 2010 03:20:59 -0800 (PST) Received: from hpaq13.eem.corp.google.com (hpaq13.eem.corp.google.com [172.25.149.13]) by smtp-out.google.com with ESMTP id oBKAoCEx000728 for ; Mon, 20 Dec 2010 02:50:12 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1292842212; bh=bajceOOo7ZhkMfCRIoZ6DZTpuHM=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=wjs/qfOYP4SRFLXSpi5Qk4BY6dgSQE48/ETGb5ATcDra57cTTq3+EUGTZ6fs6MTJ3 S8OrcEjNnn0UmNWK0ZWIQ== Received: from pvh11 (pvh11.prod.google.com [10.241.210.203]) by hpaq13.eem.corp.google.com with ESMTP id oBKAoAxg007370 for ; Mon, 20 Dec 2010 02:50:10 -0800 Received: by pvh11 with SMTP id 11so608980pvh.32 for ; Mon, 20 Dec 2010 02:50:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=ytdwEhHK3ZyxYn4/Tw7dUnwqK5e/li/rp4GY+cOWS1Y=; b=NwEscFDea7GxAdpdBM9LRj0d9drGhPtj57XvxnrZ8oBd7anConpwUxY7Qdi+O0oYSZ 7RQN4TPnn7hM5T3ma/ZA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=INUMAT+lgNGZT4lrzj+jY88/zZA0u1jobDAgnFBvlf3alLonE+1EccK7OldJfqU4fx vVZlQ7N0EUpDOJqgte/w== MIME-Version: 1.0 Received: by 10.142.229.8 with SMTP id b8mr3240793wfh.20.1292842209794; Mon, 20 Dec 2010 02:50:09 -0800 (PST) Received: by 10.142.47.14 with HTTP; Mon, 20 Dec 2010 02:50:09 -0800 (PST) In-Reply-To: <55DC663C2F4F9F439F23543E0078E8B3046101@EXC001> References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> <2229.1292235952.971571@puncture> <4D05FB8F.3070804@qbik.com> <2229.1292239384.281779@puncture> <96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org> <2229.1292253372.639419@puncture> <55DC663C2F4F9F439F23543E0078E8B3046101@EXC001> Date: Mon, 20 Dec 2010 10:50:09 +0000 Message-ID: From: Ben Laurie To: Josh Howlett Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: General discussion of application-layer protocols , websec , Common Authentication Technologies - Next Generation , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [websec] [saag] [apps-discuss] [kitten] HTTP authentication: the next generation X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2010 11:21:00 -0000 On 20 December 2010 09:25, Josh Howlett wrote: >> As Web sites discover that their account holders cannot remember their >> username, most have adopted email addresses as account identifiers. >> That is what we should use as the basis for federated web >> authentication. > > Unfortunately this approach transgresses the fourth Law of Identity: 'Directed Identity'. > > "A universal system must support both omni-directional identifiers for use by public entities and unidirectional identifiers for use by private entities, thus facilitating discovery while preventing unnecessary release of correlation handles" Of course these are not actually laws, just good ideas. However: the core failing seems to be the requirement that users should remember any more than their one "master identity" which is used to store all the others (see my Nigori work for how). > > Josh. > > JANET(UK) is a trading name of The JNT Association, a company limited > by guarantee which is registered in England under No. 2881024 > and whose Registered Office is at Lumen House, Library Avenue, > Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From hallam@gmail.com Tue Dec 21 18:06:44 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24AAC3A695E; Tue, 21 Dec 2010 18:06:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.4 X-Spam-Level: X-Spam-Status: No, score=-3.4 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dm3p9CHzs6QV; Tue, 21 Dec 2010 18:06:42 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 065FE3A6953; Tue, 21 Dec 2010 18:06:41 -0800 (PST) Received: by gyd12 with SMTP id 12so2087789gyd.31 for ; Tue, 21 Dec 2010 18:08:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=/OBpDxIGVnuTvTy89iuDk01J0co6lWZLFRhL9rLCI6Q=; b=TxYs8CaOWzmRmcvntots3pocMWPSvJI5QGoxBNehNqJygt0ua9hOqhHePmpPoxnIl2 +3K51lyktOUdTB8fGRTx6JuAa2uRO4DIGXb5pyNgWvAf2rQvSXeqiBTh1rqof+tO2Xd2 1SkUiO5AA2871KVjzgS9Pkl/RgZChq0zsnIhQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=q0SFOZuF8Otihl3+ehyAu+mAxfB0moPAT/bmrMWuBtPMJsrUDNaJfgGURE8F9MP4VA /ZAowIxWGmTeSOUdR4oargvEesKtzGBpQZmovog/mBFHhOyvd6qRQGRUORo7xUFYjRq1 XRoj9P7kXHhwX7uzpAJgdrXhqeLx0/B6IOht0= MIME-Version: 1.0 Received: by 10.100.57.11 with SMTP id f11mr565295ana.205.1292983718641; Tue, 21 Dec 2010 18:08:38 -0800 (PST) Received: by 10.100.31.8 with HTTP; Tue, 21 Dec 2010 18:08:38 -0800 (PST) In-Reply-To: <1292958219.2800.22.camel@destiny> References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> <2229.1292235952.971571@puncture> <4D05FB8F.3070804@qbik.com> <2229.1292239384.281779@puncture> <96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org> <2229.1292253372.639419@puncture> <11189_1292792454_oBJL0qAU019377_AANLkTi=iGWnBtOgPhN9tRtaJTxQhvRkjq3p0UCkRdT8=@mail.gmail.com> <1292958219.2800.22.camel@destiny> Date: Wed, 22 Dec 2010 02:08:38 +0000 Message-ID: From: Phillip Hallam-Baker To: Jeffrey Hutzelman Content-Type: multipart/alternative; boundary=0016e644c7044000210497f63b9d Cc: General discussion of application-layer protocols , websec , Common Authentication Technologies - Next Generation , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [websec] [saag] [apps-discuss] [kitten] HTTP authentication: the next generation X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 02:06:44 -0000 --0016e644c7044000210497f63b9d Content-Type: text/plain; charset=ISO-8859-1 On Tue, Dec 21, 2010 at 7:03 PM, Jeffrey Hutzelman wrote: > On Sat, 2010-12-18 at 16:48 +0000, Phillip Hallam-Baker wrote: > > > > > As Web sites discover that their account holders cannot remember their > > username, most have adopted email addresses as account identifiers. > > That is what we should use as the basis for federated web > > authentication. > > > > > > > > > > So if the user account identifier looks like username@example.com, how > > does an entity verify that a purported user has a valid claim to that > > account? > > > > > > The obvious mechanism in my view is to use DNS based discovery of an > > authentication service. For example, we might use the ESRV scheme I > > have been working on: > > > > > > _auth._ws.example.com ESRV 0 prot "_saml._ws" > > _auth._ws.example.com ESRV 0 prot "_xcat._ws" > > > > > > Which declares that the SAML and 'XCAT' (presumably kitten in XML) > > protocols may be used to resolve authentication requests. > > > > > I see two fundamental technical problems with this approach: > > 1) It relies on unsecured DNS to be secure. Particularly, you suggest > that, in order to discover a means to securely authenticate users > associated with some entity with which I have no prior relationship, I > should look up information about that entity in the DNS. But DNSSEC is > not widely-deployed enough (yet) for that to be realistic. Further, I'm > generally opposed to schemes that rely on the integrity of the DNS to > secure applications, because, at the enterprise level and below, the > operators of the DNS are frequently not entrusted with the security of > applications. I mistrust any system which insists on forcing that to > change, while providing no recourse to those for whom such a policy is > unacceptable (and no, "advertise in the DNS whether to use the DNS" is > not such a recourse!). > No, there is no reliance on DNSSEC here, ideally the relationship is authenticated end-to-end using an EV cert. DNSSEC would be acceptable however. > 2) It makes the assumption that my email service provider is interested > in providing authentication services to me, and that I'm interested in > giving them the ability to impersonate me to my bank. > > > > > Again, no. The assumption is that you will choose an authentication provider that may or may not be your current email provider. It is assumed that there will be certain email forwarding taking place - at the account holder's discretion. But if you use lame.com as your email you would end up going somewhere else for your authentication if they won't support it. I'd be much happier to see a model wherein, at registration time, I tell > a service my public key, and then it uses public-key cryptography to > authenticate me in the future. Unfortunately, there are a number of > practical problems there, such as dealing with multiple clients per > user, kiosks, reinstalling machines, stolen credentials, etc., and it's > really preferable to avoid having every service provider deal with those > issues, rather than a much smaller number of authentication providers. > Raw public keys work less well than people think here. A public key identifies a device, never a person. To make a binding to a person you need infrastructure like I am describing here. We are in the UK for Xmas, between the four of us we brought ten computers (three laptops, on kindle, on iPad, two nintendo DS and three iPhones). Only some of those devices are single user and four of the devices are shared by all four of us. So I would very much like to pair a federated authentication scheme for people with a device level public key. I would also like to employ strong two factor schemes that can be tied to device level keying. But client certs alone do not serve this need. -- Website: http://hallambaker.com/ --0016e644c7044000210497f63b9d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Dec 21, 2010 at 7:03 PM, Jeffrey= Hutzelman <jhutz@cmu= .edu> wrote:
On Sat, 2010-12-18 at 16:48 +0000, Phillip Hallam-Baker w= rote:

>
> As Web sites discover that their account holders cannot remember their=
> username, most have adopted email addresses as account identifiers. > That is what we should use as the basis for federated web
> authentication.
>
>
>
>
> So if the user account identifier looks like username@example.com, how
> does an entity verify that a purported user has a va= lid claim to that
> account?
>
>
> The obvious mechanism in my view is to use DNS based discovery of an > authentication service. For example, we might use the ESRV scheme I > have been working on:
>
>
> _auth._ws.ex= ample.com =A0ESRV 0 prot "_saml._ws"
> _auth._ws.example.= com =A0ESRV 0 prot "_xcat._ws"
>
>
> Which declares that the SAML and 'XCAT' (presumably kitten in = XML)
> protocols may be used to resolve authentication requests.
>


I see two fundamental technical problems with this approach:

1) It relies on unsecured DNS to be secure. =A0Particularly, you suggest that, in order to discover a means to securely authenticate users
associated with some entity with which I have no prior relationship, I
should look up information about that entity in the DNS. =A0But DNSSEC is not widely-deployed enough (yet) for that to be realistic. =A0Further, I= 9;m
generally opposed to schemes that rely on the integrity of the DNS to
secure applications, because, at the enterprise level and below, the
operators of the DNS are frequently not entrusted with the security of
applications. =A0I mistrust any system which insists on forcing that to
change, while providing no recourse to those for whom such a policy is
unacceptable (and no, "advertise in the DNS whether to use the DNS&quo= t; is
not such a recourse!).

No, there is no = reliance on DNSSEC here, ideally the relationship is authenticated end-to-e= nd using an EV cert.

DNSSEC would be acceptable ho= wever.

=A0
2) It makes the assumption that my email service provider is interested
in providing authentication services to me, and that I'm interested in<= br> giving them the ability to impersonate me to my bank.
>
>

Again, no.

The assumption is that you will choose an authentication provider th= at may or may not be your current email provider. It is assumed that there = will be certain email forwarding taking place - at the account holder's= discretion.=A0

But if you = use lame.com as your email you would end up= going somewhere else for your authentication if they won't support it.=


<= div class=3D"gmail_quote">

I'd be much happier to see a model wherein, at registration time, I tel= l
a service my public key, and then it uses public-key cryptography to
authenticate me in the future. =A0Unfortunately, there are a number of
practical problems there, such as dealing with multiple clients per
user, kiosks, reinstalling machines, stolen credentials, etc., and it's=
really preferable to avoid having every service provider deal with those issues, rather than a much smaller number of authentication providers.

Raw public keys work less well than people think her= e.

A public key identifies a device, never a person. To = make a binding to a person you need infrastructure like I am describing her= e.=A0

We are in the UK for Xmas, between the four of us we br= ought ten computers (three laptops, on kindle, on iPad, two nintendo DS and= three iPhones). Only some of those devices are single user and four of the= devices are shared by all four of us.

So I would very much like to pair a federated authentication= scheme for people with a device level public key. I would also like to emp= loy strong two factor schemes that can be tied to device level keying. But = client certs alone do not serve this need.=A0
--0016e644c7044000210497f63b9d-- From hallam@gmail.com Wed Dec 22 10:09:52 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0ADE23A6A5E; Wed, 22 Dec 2010 10:09:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.802 X-Spam-Level: X-Spam-Status: No, score=-2.802 tagged_above=-999 required=5 tests=[AWL=-0.404, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOAdsWMLNZPB; Wed, 22 Dec 2010 10:09:50 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id B4FF63A6909; Wed, 22 Dec 2010 10:09:49 -0800 (PST) Received: by yxt33 with SMTP id 33so2525129yxt.31 for ; Wed, 22 Dec 2010 10:11:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=mgKG9c/gWb6yXrkNacHqTGcIIEx1fZwdJJ2oemn7EBE=; b=ouWRplaVcxdpWHtQknwuz/4RfsDgTv5PCyZYgV/Z0CrvuSBUxfEbCSs8pRscEu9eW7 IEyno24F4oT8WrMwQyUvldBSOKDnnd7XNxy8CgXOwzEZJs2TqNws4T4Y8/63HMEABJoC YGPtV2ct38z60i8WYDotABc42sBc2aAounMSo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=V2DkssJFO1EzI+GoRXLSjxB86w5n3uEIPiCbjDvXvrY+LuKGwndt4k2QGQs/lditlp HXviFBtABeaLsqWoEkDQPgB6Au503ToQdEGp1LZVRamJlJbNVmH/9aepavlxD/883VUV WPVKauUGDFpkeGle8otm8Z0snefpwPfQ16vgE= MIME-Version: 1.0 Received: by 10.100.96.1 with SMTP id t1mr4377735anb.137.1293041508118; Wed, 22 Dec 2010 10:11:48 -0800 (PST) Received: by 10.100.31.8 with HTTP; Wed, 22 Dec 2010 10:11:47 -0800 (PST) In-Reply-To: References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com> <4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com> <4D051731.1020400@isode.com> <4D054041.7010203@cisco.com> <0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com> <2229.1292235952.971571@puncture> <4D05FB8F.3070804@qbik.com> <2229.1292239384.281779@puncture> <96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org> <2229.1292253372.639419@puncture> <11189_1292792454_oBJL0qAU019377_AANLkTi=iGWnBtOgPhN9tRtaJTxQhvRkjq3p0UCkRdT8=@mail.gmail.com> <1292958219.2800.22.camel@destiny> Date: Wed, 22 Dec 2010 18:11:47 +0000 Message-ID: From: Phillip Hallam-Baker To: Jeffrey Hutzelman Content-Type: multipart/alternative; boundary=0016e644caf0c57c01049803af96 Cc: General discussion of application-layer protocols , websec , Common Authentication Technologies - Next Generation , "http-auth@ietf.org" , "saag@ietf.org" , "ietf-http-wg@w3.org Group" Subject: Re: [websec] [saag] [apps-discuss] [kitten] HTTP authentication: the next generation X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 18:09:52 -0000 --0016e644caf0c57c01049803af96 Content-Type: text/plain; charset=ISO-8859-1 [We seem to have dropped off the mailing lists, Jeffrey suggested I post this which shows where we ended up.] On Wed, Dec 22, 2010 at 3:02 AM, Jeffrey Hutzelman wrote: > On Wed, 2010-12-22 at 02:08 +0000, Phillip Hallam-Baker wrote: > > > No, there is no reliance on DNSSEC here, ideally the relationship is > > authenticated end-to-end using an EV cert. > > > > > > DNSSEC would be acceptable however. > > > > I don't follow. Your example shows an advertisement to service > providers that users from example.com can be authenticated to the SP by > using one of two authentication services. > Yes, it is assumed that there is some means of authenticating this binding, I did not specify what. > Unless I'm misunderstanding > you, this is about how the SP knows who to trust, and _not_ about how > the user's software talks to the user's identity provider. Thus EV is > really mostly irrelevant, since EV is about being able to make claims > that are really only meaningful when the relying party is controlled by > a human (the green bar is pretty, but I've yet to see an email server > that evaluates users' credentials on the basis of what color location > bar it sees). > You do not understand the purpose of EV then. EV is about accountability. The green bar is displayed because the issuer applied validation practices that ensure a measure of accountability. > So, to accept a user's credentials, the SP needs to know two things: > 1) Is the assertion of user identity authentic? > 2) Does the assertion of user identity come from an authorized entity? > > The answer to (1) is provided by the authentication protocol in use, > which may well be public-key based. But that's not the part I'm worried > about. > > I am worried about (2). You show an example of one way to answer part > or all of (2). But you don't show how that answer is itself > authenticated. DNSSEC is certainly an acceptable answer to that, modulo > a whole bunch of conditions and issues that I'm willing to handwave > away, for now. But I don't think it can be the _only_ answer, for > reasons I've already raised. So, what's the other answer? > If there is a federated mechanism, there is going to have to be some registry of federation points available somewhere. We could use fred#facebook, jim#google and so on. But if there are friendly user identifiers and multiple auth providers there are going to be multiple repositories to disambiguate. So there is going to be some PKI involved however you do it. My preference is to use DNS for the signaling layer and DNSSEC to authenticate the in-zone data. How you authenticate the server when you arrive at it is another matter entirely. My view is that authentication providers should be considered to require substantial levels of infrastructure and planning. I totally reject the view floated in OpenID that it should be a design requirement that some fred in a shed can whack an authentication provider together from some Perl scripts without even bothering to upgrade to a recent version of perl. > > I'd be much happier to see a model wherein, at registration > > time, I tell > > a service my public key, and then it uses public-key > > cryptography to > > authenticate me in the future. Unfortunately, there are a > > number of > > practical problems there, such as dealing with multiple > > clients per > > user, kiosks, reinstalling machines, stolen credentials, etc., > > and it's > > really preferable to avoid having every service provider deal > > with those > > issues, rather than a much smaller number of authentication > > providers. > > > > Raw public keys work less well than people think here. > > > Raw public keys, usually wrapped in the completely unnecessary trappings > of a self-signed certificate, work surprisingly well in a wide variety > of circumstances. But they basically require first-order one-to-one > relationships between every client and every service provider, with all > the trappings required to deal with loss or compromise of the key, and > that simply doesn't scale to the Internet. CardSpace works perfectly well as a method of authenticating the client to the authentication service. Less well as a means of federated authentication. Various people have proposed 'CardSpace' in the cloud. Which sounds really convincing until you realize that they have not thought the problem through at all. > > To make a binding to a person you need infrastructure like I am > > describing here. > > > Not necessarily. I could imagine an infrastructure in which a user > authenticates to some key-management service, which then hands the user > his private key (the key belongs to the user, not the key-management > service, so revealing it to the user is OK). The user then uses that > key for authentication with whatever other services he wants. In fact, > to services other than the key-management service, this is > indistinguishable from the user having had the key all along. Of > course, it does involve the user handing his private key to some other > service, which has its own problems. > I don't like that approach because in my view a private key is something that should only ever exist in one place where it is created and later destroyed. I prefer an approach where the client-authentication provider authentication uses whatever tool is best and then the authentication provider supplies some form of token that can be used for authentication to at least one third party. That token could use public key, but symmetric is sufficient and more efficient. -- Website: http://hallambaker.com/ --0016e644caf0c57c01049803af96 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
[We seem to have dropp= ed off the mailing lists, Jeffrey suggested I post this which shows where w= e ended up.]

On Wed, Dec 22, 2010 at 3:02 AM, Jef= frey Hutzelman=A0<jhutz@cmu.edu>wrote:
On= Wed, 2010-12-22 at 02:08 +0000, Phillip Hallam-Baker wrote:

<= div class=3D"im" style=3D"color: rgb(80, 0, 80); ">> No, there is no rel= iance on DNSSEC here, ideally the relationship is
> authenticated end-to-end using an EV cert.
>
>
> DNS= SEC would be acceptable however.
>

I don't follow. =A0Your exam= ple shows an advertisement to service
providers that users from=A0example.com=A0can be authenticate= d to the SP by
using one of two authentication services.

Yes, it is assumed that there is some means of authenticatin= g this binding, I did not specify what.

=A0
=A0Unless I'm misunderstanding
you, this is about how the SP knows w= ho to trust, and _not_ about how
the user's software talks to the us= er's identity provider. =A0Thus EV is
really mostly irrelevant, sinc= e EV is about being able to make claims
that are really only meaningful when the relying party is controlled by
= a human (the green bar is pretty, but I've yet to see an email serverthat evaluates users' credentials on the basis of what color location=
bar it sees).

You do not understa= nd the purpose of EV then.=A0

EV is about accounta= bility. The green bar is displayed because the issuer applied validation pr= actices that ensure a measure of accountability.=A0

=A0=
So, to accept a user's credentials, the SP needs to know two things:1) Is the assertion of user identity authentic?
2) Does the assertion o= f user identity come from an authorized entity?

The answer to (1) is= provided by the authentication protocol in use,
which may well be public-key based. =A0But that's not the part I'm = worried
about.

I am worried about (2). =A0You show an example of = one way to answer part
or all of (2). =A0But you don't show how that= answer is itself
authenticated. =A0DNSSEC is certainly an acceptable answer to that, modulo<= br>a whole bunch of conditions and issues that I'm willing to handwave<= br>away, for now. =A0But I don't think it can be the _only_ answer, for=
reasons I've already raised. =A0So, what's the other answer?

If there is a federated mechanism, ther= e is going to have to be some registry of federation points available somew= here. We could use fred#facebook, jim#google and so on. But if there are fr= iendly user identifiers and multiple auth providers there are going to be m= ultiple repositories to disambiguate.

So there is going to be some PKI involved however you d= o it.


My preference is to use DNS f= or the signaling layer and DNSSEC to authenticate the in-zone data. How you= authenticate the server when you arrive at it is another matter entirely.= =A0

My view is that authentication providers should be cons= idered to require substantial levels of infrastructure and planning. I tota= lly reject the view floated in OpenID that it should be a design requiremen= t that some fred in a shed can whack an authentication provider together fr= om some Perl scripts without even bothering to upgrade to a recent version = of perl.

=A0=
> =A0 =A0 =A0 =A0 I'd be much happier to see a model wherein, a= t registration
> =A0 =A0 =A0 =A0 time, I tell
> =A0 =A0 =A0 =A0= a service my public key, and then it uses public-key
> =A0 =A0 =A0 = =A0 cryptography to
> =A0 =A0 =A0 =A0 authenticate me in the future. = =A0Unfortunately, there are a
> =A0 =A0 =A0 =A0 number of
> =A0 =A0 =A0 =A0 practical problems t= here, such as dealing with multiple
> =A0 =A0 =A0 =A0 clients per
= > =A0 =A0 =A0 =A0 user, kiosks, reinstalling machines, stolen credential= s, etc.,
> =A0 =A0 =A0 =A0 and it's
> =A0 =A0 =A0 =A0 really preferable to avoid having every service provid= er deal
> =A0 =A0 =A0 =A0 with those
> =A0 =A0 =A0 =A0 issues, = rather than a much smaller number of authentication
> =A0 =A0 =A0 =A0= providers.
>
> Raw public keys work less well than people thin= k here.
>
Raw public keys, usually wrapped in the completely unnecessar= y trappings
of a self-signed certificate, work surprisingly well in a wi= de variety
of circumstances. =A0But they basically require first-order o= ne-to-one
relationships between every client and every service provider, with all
= the trappings required to deal with loss or compromise of the key, and
t= hat simply doesn't scale to the Internet.

CardSpace works perfectly well as a method of authenticating the= client to the authentication service. Less well as a means of federated au= thentication.

Various people have proposed 'Ca= rdSpace' in the cloud. Which sounds really convincing until you realize= that they have not thought the problem through at all.

=A0=
> To make a binding to a person you need infrastructure like I am> describing here.
>
Not necessarily. =A0I could imagin= e an infrastructure in which a user
authenticates to some key-management= service, which then hands the user
his private key (the key belongs to the user, not the key-management
ser= vice, so revealing it to the user is OK). =A0The user then uses that
key= for authentication with whatever other services he wants. =A0In fact,
t= o services other than the key-management service, this is
indistinguishable from the user having had the key all along. =A0Of
cour= se, it does involve the user handing his private key to some other
servi= ce, which has its own problems.

I don't= like that approach because in my view a private key is something that shou= ld only ever exist in one place where it is created and later destroyed.
I prefer an approach where the client-authentication provider auth= entication uses whatever tool is best and then the authentication provider = supplies some form of token that can be used for authentication to at least= one third party.

That token could use public key, but symmetric is suffi= cient and more efficient.
--0016e644caf0c57c01049803af96-- From hallam@gmail.com Wed Dec 22 13:37:38 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BB5B3A6B37; Wed, 22 Dec 2010 13:37:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.297 X-Spam-Level: X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5 tests=[AWL=-0.899, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, J_CHICKENPOX_48=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ehVB8lML9y+F; Wed, 22 Dec 2010 13:37:36 -0800 (PST) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (p-us1-iereast-outbound-tmp.us1.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id D3FB93A68BE; Wed, 22 Dec 2010 13:37:29 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlomAIf+EU3GmAcF/2dsb2JhbACUVYE0jhAIc6klgQgCiGuHKC6IXIJyglcEiwSDHQYUh3s X-IronPort-AV: E=Sophos;i="4.60,215,1291611600"; d="txt'?scan'208";a="51313747" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 22 Dec 2010 16:39:27 -0500 X-IronPort-AV: E=Sophos;i="4.60,215,1291611600"; d="txt'?scan'208";a="559921885" Received: from unknown (HELO 307622ANEX1.global.avaya.com) ([135.64.140.10]) by co300216-co-erhwest-out.avaya.com with ESMTP; 22 Dec 2010 16:39:26 -0500 Received: from mail pickup service by 307622ANEX1.global.avaya.com with Microsoft SMTPSVC; Wed, 22 Dec 2010 22:38:46 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CBA220.9C973700" Received: from 307622ANEX2.global.avaya.com ([135.64.140.15]) by 307622ANEX1.global.avaya.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Dec 2010 19:13:08 +0100 Received: from co300216-co-erhwest.avaya.com ([198.152.7.5]) by 307622ANEX2.global.avaya.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Dec 2010 19:11:58 +0100 Received: from co300216-co-outbound.net.avaya.com ([198.152.13.100]) by co300216-co-erhwest.avaya.com with ESMTP; 22 Dec 2010 13:11:58 -0500 Received: from mail.ietf.org ([64.170.98.32]) by co300216-co-ierwest.avaya.com with ESMTP; 22 Dec 2010 13:11:57 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B13843A6B37; Wed, 22 Dec 2010 10:09:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0ADE23A6A5E; Wed, 22 Dec 2010 10:09:52 -0800 (PST) Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOAdsWMLNZPB; Wed, 22 Dec 2010 10:09:50 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id B4FF63A6909; Wed, 22 Dec 2010 10:09:49 -0800 (PST) Received: by yxt33 with SMTP id 33so2525129yxt.31 for ; Wed, 22 Dec 2010 10:11:48 -0800 (PST) Received: by 10.100.96.1 with SMTP id t1mr4377735anb.137.1293041508118; Wed, 22 Dec 2010 10:11:48 -0800 (PST) Received: by 10.100.31.8 with HTTP; Wed, 22 Dec 2010 10:11:47 -0800 (PST) Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5 X-OriginalArrivalTime: 22 Dec 2010 18:13:08.0215 (UTC) FILETIME=[E2B2A070:01CBA203] Date: Wed, 22 Dec 2010 19:11:47 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [apps-discuss] [saag] [websec] [kitten] HTTP authentication: the next generation Thread-Index: AcuiA7mTehF0T8iMSHeVmmOflr3UqQ== References: <4D02AF81.6000907@stpeter.im> <78BD0B98-0F20-478B-85F1-DBB45691EB0D@padl.com><4D0479E3.4050508@gmail.com> <4D04D7D6.4090105@isode.com><4D051731.1020400@isode.com> <4D054041.7010203@cisco.com><0435D11C-DF55-464D-B23F-F5D114DEE2C3@checkpoint.com><2229.1292235952.971571@puncture> <4D05FB8F.3070804@qbik.com><2229.1292239384.281779@puncture><96517E19-5DC7-47A0-8C21-C710F6F8F772@tzi.org><2229.1292253372.639419@puncture><11189_1292792454_oBJL0qAU019377_AANLkTi=iGWnBtOgPhN9tRtaJTxQhvRkjq3p0UCkRdT8=@mail.gmail.com><1292958219.2800.22.camel@destiny> From: "Phillip Hallam-Baker" Sender: To: "Jeffrey Hutzelman" Cc: General discussion of application-layer protocols , websec , Common Authentication Technologies - Next Generation , http-auth@ietf.org, saag@ietf.org, ietf-http-wg@w3.org Subject: Re: [websec] [apps-discuss] [saag] [kitten] HTTP authentication: the next generation X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2010 21:37:38 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBA220.9C973700 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CBA220.9C973700" ------_=_NextPart_002_01CBA220.9C973700 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [We seem to have dropped off the mailing lists, Jeffrey suggested I post = this which shows where we ended up.] On Wed, Dec 22, 2010 at 3:02 AM, Jeffrey Hutzelmanwrote: On Wed, 2010-12-22 at 02:08 +0000, Phillip Hallam-Baker wrote: > No, there is no reliance on DNSSEC here, ideally the relationship is > authenticated end-to-end using an EV cert. > > > DNSSEC would be acceptable however. > I don't follow. Your example shows an advertisement to service providers that users fromexample.com can be = authenticated to the SP by using one of two authentication services. Yes, it is assumed that there is some means of authenticating this = binding, I did not specify what. Unless I'm misunderstanding you, this is about how the SP knows who to trust, and _not_ about how the user's software talks to the user's identity provider. Thus EV is really mostly irrelevant, since EV is about being able to make claims that are really only meaningful when the relying party is controlled by a human (the green bar is pretty, but I've yet to see an email server that evaluates users' credentials on the basis of what color location bar it sees). You do not understand the purpose of EV then. EV is about accountability. The green bar is displayed because the = issuer applied validation practices that ensure a measure of = accountability. So, to accept a user's credentials, the SP needs to know two things: 1) Is the assertion of user identity authentic? 2) Does the assertion of user identity come from an authorized entity? The answer to (1) is provided by the authentication protocol in use, which may well be public-key based. But that's not the part I'm worried about. I am worried about (2). You show an example of one way to answer part or all of (2). But you don't show how that answer is itself authenticated. DNSSEC is certainly an acceptable answer to that, modulo a whole bunch of conditions and issues that I'm willing to handwave away, for now. But I don't think it can be the _only_ answer, for reasons I've already raised. So, what's the other answer? If there is a federated mechanism, there is going to have to be some = registry of federation points available somewhere. We could use = fred#facebook, jim#google and so on. But if there are friendly user = identifiers and multiple auth providers there are going to be multiple = repositories to disambiguate. So there is going to be some PKI involved however you do it. My preference is to use DNS for the signaling layer and DNSSEC to = authenticate the in-zone data. How you authenticate the server when you = arrive at it is another matter entirely. My view is that authentication providers should be considered to require = substantial levels of infrastructure and planning. I totally reject the = view floated in OpenID that it should be a design requirement that some = fred in a shed can whack an authentication provider together from some = Perl scripts without even bothering to upgrade to a recent version of = perl. > I'd be much happier to see a model wherein, at registration > time, I tell > a service my public key, and then it uses public-key > cryptography to > authenticate me in the future. Unfortunately, there are a > number of > practical problems there, such as dealing with multiple > clients per > user, kiosks, reinstalling machines, stolen credentials, etc., > and it's > really preferable to avoid having every service provider deal > with those > issues, rather than a much smaller number of authentication > providers. > > Raw public keys work less well than people think here. > Raw public keys, usually wrapped in the completely unnecessary trappings of a self-signed certificate, work surprisingly well in a wide variety of circumstances. But they basically require first-order one-to-one relationships between every client and every service provider, with all the trappings required to deal with loss or compromise of the key, and that simply doesn't scale to the Internet. CardSpace works perfectly well as a method of authenticating the client = to the authentication service. Less well as a means of federated = authentication. Various people have proposed 'CardSpace' in the cloud. Which sounds = really convincing until you realize that they have not thought the = problem through at all. > To make a binding to a person you need infrastructure like I am > describing here. > Not necessarily. I could imagine an infrastructure in which a user authenticates to some key-management service, which then hands the user his private key (the key belongs to the user, not the key-management service, so revealing it to the user is OK). The user then uses that key for authentication with whatever other services he wants. In fact, to services other than the key-management service, this is indistinguishable from the user having had the key all along. Of course, it does involve the user handing his private key to some other service, which has its own problems. I don't like that approach because in my view a private key is something = that should only ever exist in one place where it is created and later = destroyed. I prefer an approach where the client-authentication provider = authentication uses whatever tool is best and then the authentication = provider supplies some form of token that can be used for authentication = to at least one third party. That token could use public key, but symmetric is sufficient and more = efficient. -- Website:http://hallambaker.com/ ------_=_NextPart_002_01CBA220.9C973700 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
[We seem to have dropped = off the mailing lists, Jeffrey suggested I post this which shows where = we ended up.]

On Wed, Dec 22, 2010 at = 3:02 AM, Jeffrey Hutzelman<jhutz@cmu.edu>wrote:
I don't follow. Your example shows = an advertisement to service
providers that users fromexample.comcan = be authenticated to the SP by
using one of two authentication = services.

Yes, it is assumed that there is some means of = authenticating this binding, I did not specify what.
Unless I'm misunderstanding
you, this is about how the SP knows = who to trust, and _not_ about how
the user's software talks to = the user's identity provider. Thus EV is
really mostly = irrelevant, since EV is about being able to make claims
that are really only meaningful when the relying party is controlled = by
a human (the green bar is pretty, but I've yet to see an email = server
that evaluates users' credentials on the basis of what = color location
bar it sees).

You do not = understand the purpose of EV then.

EV is about = accountability. The green bar is displayed because the issuer applied = validation practices that ensure a measure of accountability.
So, to accept a user's credentials, the SP needs to know two = things:
1) Is the assertion of user identity authentic?
2) Does = the assertion of user identity come from an authorized = entity?

The answer to (1) is provided by the authentication = protocol in use,
which may well be public-key based. But that's not the part I'm = worried
about.

I am worried about (2). You show an example of = one way to answer part
or all of (2). But you don't show how that = answer is itself
authenticated. DNSSEC is certainly an acceptable answer to that, = modulo
a whole bunch of conditions and issues that I'm willing to = handwave
away, for now. But I don't think it can be the _only_ = answer, for
reasons I've already raised. So, what's the other = answer?

If there is a = federated mechanism, there is going to have to be some registry of = federation points available somewhere. We could use fred#facebook, = jim#google and so on. But if there are friendly user identifiers and = multiple auth providers there are going to be multiple repositories to = disambiguate.

So there is going to be some PKI involved however = you do it.


My preference is to = use DNS for the signaling layer and DNSSEC to authenticate the in-zone = data. How you authenticate the server when you arrive at it is another = matter entirely.

My view is that authentication providers should be = considered to require substantial levels of infrastructure and planning. = I totally reject the view floated in OpenID that it should be a design = requirement that some fred in a shed can whack an authentication = provider together from some Perl scripts without even bothering to = upgrade to a recent version of perl.
> I'd be much happier to see a model wherein, at = registration
> time, I tell
> a service my public = key, and then it uses public-key
> cryptography to
> = authenticate me in the future. Unfortunately, there are a
> number of
> practical problems there, such as dealing = with multiple
> clients per
> user, kiosks, = reinstalling machines, stolen credentials, etc.,
> and = it's
> really preferable to avoid having every service provider = deal
> with those
> issues, rather than a much = smaller number of authentication
> providers.
>
> = Raw public keys work less well than people think here.
>
Raw public keys, usually wrapped in the completely = unnecessary trappings
of a self-signed certificate, work surprisingly = well in a wide variety
of circumstances. But they basically require = first-order one-to-one
relationships between every client and every service provider, with = all
the trappings required to deal with loss or compromise of the = key, and
that simply doesn't scale to the = Internet.

CardSpace works perfectly well as a method of authenticating = the client to the authentication service. Less well as a means of = federated authentication.

Various people have = proposed 'CardSpace' in the cloud. Which sounds really = convincing until you realize that they have not thought the problem = through at all.
> To make a binding to a person you need infrastructure like I = am
> describing here.
>
Not necessarily. I could = imagine an infrastructure in which a user
authenticates to some = key-management service, which then hands the user
his private key (the key belongs to the user, not the = key-management
service, so revealing it to the user is OK). The user = then uses that
key for authentication with whatever other services he = wants. In fact,
to services other than the key-management service, = this is
indistinguishable from the user having had the key all along. = Of
course, it does involve the user handing his private key to some = other
service, which has its own = problems.

I don't like that approach = because in my view a private key is something that should only ever = exist in one place where it is created and later destroyed.

I prefer an approach where the client-authentication provider = authentication uses whatever tool is best and then the authentication = provider supplies some form of token that can be used for authentication = to at least one third party.

That token could use public key, but symmetric is = sufficient and more efficient.
 ------_=_NextPart_002_01CBA220.9C973700-- ------_=_NextPart_001_01CBA220.9C973700 Content-Type: text/plain; name="ATT2808037.txt" Content-Transfer-Encoding: base64 Content-Description: ATT2808037.txt Content-Disposition: inline; filename="ATT2808037.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmFwcHMtZGlz Y3VzcyBtYWlsaW5nIGxpc3QNCmFwcHMtZGlzY3Vzc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hcHBzLWRpc2N1c3MNCg== ------_=_NextPart_001_01CBA220.9C973700-- From tobias.gondrom@gondrom.org Fri Dec 24 03:23:14 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D7DE3A67B4 for ; Fri, 24 Dec 2010 03:23:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.503 X-Spam-Level: X-Spam-Status: No, score=-93.503 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzhJPkbSbUUd for ; Fri, 24 Dec 2010 03:23:13 -0800 (PST) Received: from lvps83-169-7-107.dedicated.hosteurope.de (lvps83-169-7-107.dedicated.hosteurope.de [83.169.7.107]) by core3.amsl.com (Postfix) with ESMTP id D25AE3A67CF for ; Fri, 24 Dec 2010 03:23:12 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=lliZIDs7M5uMi72lthk/lWqV8LOoIqeNbOR1UgD5DiCKnKYBq/2vvTiIXdvXLIgg789iwfIGJG1sJl3dHNH31L1dEcPWV5L6wFVv2eJNJ86Ym+OIm4BQERkRJQB4HGPt; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:X-Priority:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; Received: (qmail 1909 invoked from network); 24 Dec 2010 12:24:58 +0100 Received: from unknown (HELO seraphim.heaven) (62.145.29.194) by lvps83-169-7-107.dedicated.hosteurope.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 24 Dec 2010 12:24:58 +0100 Message-ID: <4D148311.6010208@gondrom.org> Date: Fri, 24 Dec 2010 11:25:05 +0000 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101026 SUSE/3.1.6 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: websec@ietf.org X-Priority: 4 (Low) References: <4D01201E.8000007@gondrom.org> <71c0e78249b5.4d096c09@naist.jp> In-Reply-To: <71c0e78249b5.4d096c09@naist.jp> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [websec] request for feedback on adoption of drafts to WG - until Dec-16 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Dec 2010 11:23:14 -0000 Hello Greg, thank you for your comment. Btw. actually hodges-strict-transport-sec is about the _policy_ to enforce secure HTTP transport, which is in scope, as also outlined in the charter. So there will be no problem with that. Kind regards, Tobias On 12/15/2010 04:31 PM, Blanc Gregory wrote: > Hello, > > I would say yes though hodges-strict-transport-sec is about enforcing > secure HTTP transport which I though was out of the scope. Am I mistaken? > > Regards, > > Greg > > 12/10/10 ã«ã€Tobias Gondrom ã•ã‚“ã¯æ›¸ãã¾ã—ãŸ: > >> Hello dear fellow websec members, >> >> >> >> during the hasmat BOF in July and the websec charter consensus three >> individual drafts were listed as to be worked on as first items in >> our working group. I did so far not formally ask for WG consensus on >> adopting these three documents until now; our area director >> suggested that it would be appropriate to do so before they are >> re-submitted as working group drafts. >> >> >> >> So I would like to ask for your feedback on adopting the following >> three individual drafts as WG documents (as outlined in the >> charter): >> >> >> >> - draft-abarth-origin: >> >> http://tools.ietf.org/tools/rfcmarkup/rfcmarkup.cgi?draft=draft-abarth-origin >> >> >> >> - hodges-strict-transport-sec: >> >> http://tools.ietf.org/tools/rfcmarkup/rfcmarkup.cgi?draft=draft-hodges-strict-transport-sec >> >> >> >> - draft-abarth-mime-sniff: >> >> http://tools.ietf.org/tools/rfcmarkup/rfcmarkup.cgi?draft=draft-abarth-mime-sniff >> >> >> >> Please reply ("yes" (for adoption) or "no" (against adoption), both >> are important) - either for each draft individually or for all three >> drafts as a bundle - to the list by Thurs 16th December 2010 >> (24:00GMT). >> >> >> >> Kind regards and thanks a lot, >> >> >> >> Tobias >> >> chair of websec >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> websec mailing list >> websec@ietf.org >> https://www.ietf.org/mailman/listinfo/websec > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From tobias.gondrom@gondrom.org Fri Dec 24 03:29:42 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67C0A3A6768 for ; Fri, 24 Dec 2010 03:29:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.948 X-Spam-Level: X-Spam-Status: No, score=-92.948 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qh7HCsTNYBjW for ; Fri, 24 Dec 2010 03:29:41 -0800 (PST) Received: from lvps83-169-7-107.dedicated.hosteurope.de (lvps83-169-7-107.dedicated.hosteurope.de [83.169.7.107]) by core3.amsl.com (Postfix) with ESMTP id 0AB643A672E for ; Fri, 24 Dec 2010 03:29:40 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=ctv3wL/mDUMJBwSq9nWK1wE7GrNbCcf5ioxy5ykuFJ2GVURZiA25GyIjnNMg/YY6feVax2vvjQlhCZ+TPpy5qEPw933LFKbwbvpcFLU8Q9y4bCQxh8+qpf1XtivTSWTy; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; Received: (qmail 19841 invoked from network); 24 Dec 2010 12:31:28 +0100 Received: from dslb-088-064-212-036.pools.arcor-ip.net (HELO seraphim.heaven) (88.64.212.36) by lvps83-169-7-107.dedicated.hosteurope.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 24 Dec 2010 12:31:28 +0100 Message-ID: <4D148498.2060502@gondrom.org> Date: Fri, 24 Dec 2010 11:31:36 +0000 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101026 SUSE/3.1.6 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: websec References: <4D01201E.8000007@gondrom.org> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [websec] request for feedback on adoption of drafts to WG - until Dec-16 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Dec 2010 11:29:42 -0000 Dear all, thank you very much for your feedback and input. >From reading all comments, I can see we have consensus to adopt the three documents. To the authors: please resubmit your drafts in the next couple of days as websec WG drafts. Wishing you all a merry Christmas and happy New Year and a good holiday! Many greetings, Tobias On 12/09/2010 06:46 PM, Adam Barth wrote: >> Hello dear fellow websec members, >> >> during the hasmat BOF in July and the websec charter consensus three >> individual drafts were listed as to be worked on as first items in our >> working group. I did so far not formally ask for WG consensus on adopting >> these three documents until now; our area director suggested that it would >> be appropriate to do so before they are re-submitted as working group >> drafts. >> >> So I would like to ask for your feedback on adopting the following three >> individual drafts as WG documents (as outlined in the charter): >> >> - draft-abarth-origin: >> http://tools.ietf.org/tools/rfcmarkup/rfcmarkup.cgi?draft=draft-abarth-origin >> >> - hodges-strict-transport-sec: >> >> http://tools.ietf.org/tools/rfcmarkup/rfcmarkup.cgi?draft=draft-hodges-strict-transport-sec >> >> - draft-abarth-mime-sniff: >> http://tools.ietf.org/tools/rfcmarkup/rfcmarkup.cgi?draft=draft-abarth-mime-sniff >> >> Please reply ("yes" (for adoption) or "no" (against adoption), both are >> important) - either for each draft individually or for all three drafts as a >> bundle - to the list by Thurs 16th December 2010 (24:00GMT). >> >> Kind regards and thanks a lot, >> >> Tobias >> chair of websec >> >> >> >> _______________________________________________ >> websec mailing list >> websec@ietf.org >> https://www.ietf.org/mailman/listinfo/websec >> >> From paul.hoffman@vpnc.org Sun Dec 26 16:02:05 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF1253A6843; Sun, 26 Dec 2010 16:02:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.432 X-Spam-Level: X-Spam-Status: No, score=-100.432 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_40=-0.185, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bjTpXTQ9YFu; Sun, 26 Dec 2010 16:02:05 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 425583A6841; Sun, 26 Dec 2010 16:02:05 -0800 (PST) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id oBR0486s067537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 26 Dec 2010 17:04:09 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20101213220001.24500.52050.idtracker@localhost> <1292803814.1885.16.camel@mattlaptop2.local> <1292899636.1888.75.camel@mattlaptop2.local> <5EE049BA3C6538409BBE6F1760F328ABEB19B00699@DEN-MEXMS-001.corp.ebay.com> Date: Sun, 26 Dec 2010 16:04:06 -0800 To: keyassure@ietf.org, websec@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [websec] HASTLS and client policy preference X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Dec 2010 00:02:06 -0000 Greetings again. I still don't like the idea of a host asserting a client policy preference, but I hear many folks wanting it. I think I have added it cleanly in draft-hoffman-server-has-tls-02, but I'm not sure and would like to hear more from folks, especially those who like the current semantics in draft-hodges-strict-transport-sec. The new draft is at , and the diffs from the last draft are at . FWIW, I don't think that draft-hoffman-server-has-tls formally belongs in either DANE or WEBSEC, and will probably try to move it into the AppsArea WG in the new year, but if folks want to comment before then, that's great. --Paul Hoffman, Director --VPN Consortium From asteingruebl@paypal-inc.com Mon Dec 27 15:50:36 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE7F83A68F6; Mon, 27 Dec 2010 15:50:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.665 X-Spam-Level: X-Spam-Status: No, score=-7.665 tagged_above=-999 required=5 tests=[AWL=0.852, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9FRzKV6FDmn; Mon, 27 Dec 2010 15:50:34 -0800 (PST) Received: from den-mipot-002.corp.ebay.com (den-mipot-002.corp.ebay.com [216.113.175.153]) by core3.amsl.com (Postfix) with ESMTP id 4BB863A68ED; Mon, 27 Dec 2010 15:50:31 -0800 (PST) DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:Date: Subject:Thread-Topic:Thread-Index:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: x-ems-proccessed:x-ems-stamp:Content-Type: Content-Transfer-Encoding:MIME-Version:X-CFilter; b=isu39BI/Cp9W0XhjMFvqxS8jYAy5c9K3S9yABQc0N30FiWJYXo15NmEH pDO+IDI33i1MEqQ22suu0ScgzN6CfVxs1HEejki1qmjH8kw3TYKDsgj96 wjzN4Ytbvx2x3Cc; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=asteingruebl@paypal-inc.com; q=dns/txt; s=ppinc; t=1293493957; x=1325029957; h=from:to:date:subject:message-id:references:in-reply-to: content-transfer-encoding:mime-version; z=From:=20"Steingruebl,=20Andy"=20|To:=20Paul=20Hoffman=20,=20" keyassure@ietf.org"=0D=0A=09,=20"webs ec@ietf.org"=20|Date:=20Mon,=2027=20Dec =202010=2016:52:34=20-0700|Subject:=20RE:=20[websec]=20HA STLS=20and=20client=20policy=20preference|Message-ID:=20< 5EE049BA3C6538409BBE6F1760F328ABEB19C1FD7D@DEN-MEXMS-001. corp.ebay.com>|References:=20<20101213220001.24500.52050. idtracker@localhost>=0D=0A=09<1292803814.1885.16.camel@ma ttlaptop2.local>=0D=0A=09=0D=0A=09=0D=0A=09=0D=0A=09=0D=0A=09<1292899636.1888.75.camel@mattlaptop 2.local>=0D=0A=09=0D =0A=09=0D=0A=09=0D =0A=09<5EE049BA3C6538409BBE6F1760F328ABEB19B00699@DEN-MEX MS-001.corp.ebay.com>=0D=0A=09=0D=0A=09=0D=0A=09=0D=0A=09=0D=0A=09=0D=0A=09=0D=0A=09=0D=0A=09=0D=0A=09 =0D=0A=20 |In-Reply-To:=20 |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=37NxVxVpl9RfapIqqfT6fxeRLJbTyFnFBGi2z1NL5Hc=; b=W//gNN429l+OlvxyVQMrJQCBzSzskZd+FAOo0IlePXeSpJ2dZ+zz53i7 5tftqE6IhFpoZnOxdpAbDjJuMfiv24s6LZzW8oVAQ9IaaqJwhZEAsSB3T 1WLZx6dqnq+4M9Q; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.60,237,1291622400"; d="scan'208";a="602502" Received: from den-vtenf-002.corp.ebay.com (HELO DEN-MEXHT-002.corp.ebay.com) ([10.101.112.213]) by den-mipot-002.corp.ebay.com with ESMTP; 27 Dec 2010 15:52:36 -0800 Received: from DEN-MEXMS-001.corp.ebay.com ([10.241.16.225]) by DEN-MEXHT-002.corp.ebay.com ([10.241.17.53]) with mapi; Mon, 27 Dec 2010 16:52:35 -0700 From: "Steingruebl, Andy" To: Paul Hoffman , "keyassure@ietf.org" , "websec@ietf.org" Date: Mon, 27 Dec 2010 16:52:34 -0700 Thread-Topic: [websec] HASTLS and client policy preference Thread-Index: AculWZjEmnCIz8UqSiiQbTZJX0O5SQAxg+3w Message-ID: <5EE049BA3C6538409BBE6F1760F328ABEB19C1FD7D@DEN-MEXMS-001.corp.ebay.com> References: <20101213220001.24500.52050.idtracker@localhost> <1292803814.1885.16.camel@mattlaptop2.local> <1292899636.1888.75.camel@mattlaptop2.local> <5EE049BA3C6538409BBE6F1760F328ABEB19B00699@DEN-MEXMS-001.corp.ebay.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A== x-ems-stamp: tKGPcji1e5ggIgpbtW2SJw== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Subject: Re: [websec] HASTLS and client policy preference X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Dec 2010 23:50:36 -0000 > -----Original Message----- > From: websec-bounces@ietf.org [mailto:websec-bounces@ietf.org] On > Behalf Of Paul Hoffman >=20 > Greetings again. I still don't like the idea of a host asserting a client= policy > preference, but I hear many folks wanting it. I think I have added it cle= anly in > draft-hoffman-server-has-tls-02, but I'm not sure and would like to hear > more from folks, especially those who like the current semantics in draft= - > hodges-strict-transport-sec. The new draft is at > , and the dif= fs > from the last draft are at server-has-tls-02.txt>. A few thoughts. 1. I think it would be useful in the security considerations to discuss (br= iefly?) the MITM threat model at play here. You discuss it in the context = of delivery of the DNS data itself, but not the motivation for this proposa= l in the first place. A major motivation is the MITM attack against the no= n-TLS version of a protocol. 2. Do you have any examples of CFB apps? A few clients such as Mozilla's T= hunderbird when in "discovery" mode will try this, but it isn't very common= in my experience, and it would be good to have a few examples I could thin= k about. 3. We argues a lot when working on HSTS about the proper behavior of a serv= er supporting HSTS and whether it SHOULD or MUST redirect all HTTP traffic = to HTTPS. You come down on the MUST front in this proposal, at least philo= sophically. Some sites (well, 1 anyway) have chosen not to. I won't go into= the details, and it isn't a major issue. 4. One way in protocols that don't support redirects to also indicate to a = client that it should not communicate "insecurely" is with error codes. PO= P/IMAP can both do this with error codes, some of which are usually shown t= o the user (in some implementations). So, though they don't support protoc= ol-level "redirects" like HTTPS, then still allow signaling to the client a= lbeit in a non-automated way. 5. Maybe this came up earlier but I'm still slightly confused on overall se= mantics of this proposal. If HASTLS is about TLS, it is odd to me that it = should talk about non-TLS policy, where it listens "insecurely", etc. I ha= ve a few thoughts on the general topic of service discovery, but HASTLS see= ms to bundle two ideas together: a) service discovery and b) whether/how th= at service operates with TLS. It seems to me that they are slighty differe= nt, and co-mingling them doesn't seem quite right. =20 Related to #5, the biggest protocol in our minds that is problematic wrt ss= lstrip-type attacks is HTTP/HTTPS, because it is the one protocol that wher= e non fully qualified names, URI(L?)'s are entered, and where the browser h= as some of its own converting between names and protocols that go on. It = is also the one protocol most easily MITM'd in a lot of ways, because much = of the web is HTTP, and active attackers can easily insert references to re= sources causing the client to retrieve them. The same isn't true of most o= ther protocols such as IMAP. Which isn't to say that this proposal isn't a= good idea for IMAP, its just that IMAP/POP aren't quite so ripe for abuse = generally. From asteingruebl@paypal-inc.com Tue Dec 28 08:23:20 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5784B3A692D; Tue, 28 Dec 2010 08:23:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.004 X-Spam-Level: X-Spam-Status: No, score=-8.004 tagged_above=-999 required=5 tests=[AWL=1.113, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dqg5Dgu88ZgL; Tue, 28 Dec 2010 08:23:19 -0800 (PST) Received: from den-mipot-002.corp.ebay.com (den-mipot-002.corp.ebay.com [216.113.175.153]) by core3.amsl.com (Postfix) with ESMTP id C63753A687F; Tue, 28 Dec 2010 08:23:18 -0800 (PST) DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:CC: Date:Subject:Thread-Topic:Thread-Index:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: x-ems-proccessed:x-ems-stamp:Content-Type: Content-Transfer-Encoding:MIME-Version:X-CFilter; b=R/VbPyZ814AAuGEwqMnw0Ca28UfzJ/s5TKbHWDPDAj7zp1sbJeP/C5Zr PjHYVLJBZqQOnSnut4sYI0S15W/f9sgCIBS0SPMo4RvuhCN/b23hHdXYT +7puSMcrwyWHVfX; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=asteingruebl@paypal-inc.com; q=dns/txt; s=ppinc; t=1293553524; x=1325089524; h=from:to:cc:date:subject:message-id:references: in-reply-to:content-transfer-encoding:mime-version; z=From:=20"Steingruebl,=20Andy"=20|To:=20Paul=20Wouters=20|CC:=20P aul=20Hoffman=20,=20"keyassure@iet f.org"=0D=0A=09,=20"websec@ietf.org" =20|Date:=20Tue,=2028=20Dec=202010=2009: 25:22=20-0700|Subject:=20RE:=20[keyassure]=20[websec]=20H ASTLS=20and=20client=20policy=20preference|Message-ID:=20 <5EE049BA3C6538409BBE6F1760F328ABEB19C1FEAE@DEN-MEXMS-001 .corp.ebay.com>|References:=20<20101213220001.24500.52050 .idtracker@localhost>=0D=0A=20<1292899636.1888.75.camel@m attlaptop2.local>=0D=0A=20=0D=0A=20=0D=0A=20=0D=0A=20<5EE049BA3C6538409BBE6F1760F328ABEB19B00699@D EN-MEXMS-001.corp.ebay.com>=0D=0A=20=0D=0A=20=0D=0A=20=0D=0A=20=0D =0A=20=0D=0A=20=0D=0A=20=0D=0A=20=0D=0A =20=0D=0A=20 =0D=0A=20<5EE049BA3C6538409BBE6F1760F328ABEB19C1FD7D@DEN- MEXMS-001.corp.ebay.com>=0D=0A=20|In-Reply-To:=20 |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=ACoEL/BBa+E3J/QBl4ocP2hdwhJ98YQCNO2nutLR31I=; b=U60blQSrnRAaQAUWeB/niiUIGlzmPglQIhxW91lOvFNYI1F+55vtW3Vq U7yy7xNZfn4d8Dh/w2TghERZFaidFagC+kTzzbruf3h3o7PasNbSOfFJk r3UopT12zpr5Yob; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.60,239,1291622400"; d="scan'208";a="607970" Received: from den-vtenf-002.corp.ebay.com (HELO DEN-MEXHT-001.corp.ebay.com) ([10.101.112.213]) by den-mipot-002.corp.ebay.com with ESMTP; 28 Dec 2010 08:25:24 -0800 Received: from DEN-MEXMS-001.corp.ebay.com ([10.241.16.225]) by DEN-MEXHT-001.corp.ebay.com ([10.241.17.52]) with mapi; Tue, 28 Dec 2010 09:25:23 -0700 From: "Steingruebl, Andy" To: Paul Wouters Date: Tue, 28 Dec 2010 09:25:22 -0700 Thread-Topic: [keyassure] [websec] HASTLS and client policy preference Thread-Index: AcumN+ceo9ielK5/TC2CIQopAbld3QAc3hxg Message-ID: <5EE049BA3C6538409BBE6F1760F328ABEB19C1FEAE@DEN-MEXMS-001.corp.ebay.com> References: <20101213220001.24500.52050.idtracker@localhost> <1292899636.1888.75.camel@mattlaptop2.local> <5EE049BA3C6538409BBE6F1760F328ABEB19B00699@DEN-MEXMS-001.corp.ebay.com> <5EE049BA3C6538409BBE6F1760F328ABEB19C1FD7D@DEN-MEXMS-001.corp.ebay.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A== x-ems-stamp: OghTtTLTovPEsnRVpS0WhQ== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Cc: "websec@ietf.org" , "keyassure@ietf.org" , Paul Hoffman Subject: Re: [websec] [keyassure] HASTLS and client policy preference X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2010 16:23:20 -0000 > -----Original Message----- > From: Paul Wouters [mailto:paul@xelerance.com] =20 > Though I blieve the HASTLS record should not become the "legitimate open > port list" of a host though, people should not trust clients to adhere to > HASTLS for their server security, and instead have proper firewall polici= es. >=20 > Personally, I would prefer not to have to build a list of insecure ports = if I have > no secure version of it available, but then again I would expect any clie= nt that > can do HASTLS to be able to do the secure version anyway. And for new > protocols to not come out with an insecure version. >=20 > Perhaps it makes sense to rename HASTLS to something else. TLSSTAT? > STATTLS? TLSAVAIL? The idea I've been toying around with is actually changing how service look= ups happen. I don't have a well-formulated idea yet but it seems that just= as many protocols/applications (I struggle for the right word here) do SRV= lookups, maybe we ought to somehow bundle the TLS preference into that loo= kup scheme. If we did, we could tackle the keys-in-dns problem and has/re= quires-TLS problem in the same SRV lookup. HASTLS would be a part of looki= ng up the properties of a service you're about to connect to. I'm more than a little inexperienced with existing SRV lookups, so can't qu= ite articulate how I think this would best work. - Andy From hallam@gmail.com Tue Dec 28 09:02:29 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 681113A6890; Tue, 28 Dec 2010 09:02:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.668 X-Spam-Level: X-Spam-Status: No, score=-3.668 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u24xp2msSJ0q; Tue, 28 Dec 2010 09:02:28 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id DCE5C3A687F; Tue, 28 Dec 2010 09:02:27 -0800 (PST) Received: by gwj17 with SMTP id 17so6036921gwj.31 for ; Tue, 28 Dec 2010 09:04:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=202S2KdgB8wm9EtfgZZSJwOfHAdUZRXLdxmMpwM5gOI=; b=W1xjc+aI+yxjeXBHyksBA1Ha6R4ybxCnIriOZIY4+wGqBkShZEvViwuk4MJio4ClIR GsPlwacNlXZM4TKJVIEd1iHNWzH3Rvn+Jix8ETKS3BzCxTlLFJIVtSN1SHtZq/RggMBC GYzy+Tzyjn10VkSjizgmILWtDgGeoDXATQbmA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=HrFiu9+gGYaGaSE0pXdPcipKMtrCaPsxlvxAGhnFls+GrTs/dmwW868YnhW9EPlnOh GoDWswN7NtZbTH4/R4enULiDVi/7CMO4Y2hvJLcFt/5h8ywjTJflkKxDovsjFvziLSUj UrtC4m4GHzXRxb0Lc9aZZYQOhwrjmHn8T2C/Q= MIME-Version: 1.0 Received: by 10.100.96.1 with SMTP id t1mr7902055anb.137.1293555872769; Tue, 28 Dec 2010 09:04:32 -0800 (PST) Received: by 10.100.31.8 with HTTP; Tue, 28 Dec 2010 09:04:32 -0800 (PST) In-Reply-To: <5EE049BA3C6538409BBE6F1760F328ABEB19C1FEAE@DEN-MEXMS-001.corp.ebay.com> References: <20101213220001.24500.52050.idtracker@localhost> <1292899636.1888.75.camel@mattlaptop2.local> <5EE049BA3C6538409BBE6F1760F328ABEB19B00699@DEN-MEXMS-001.corp.ebay.com> <5EE049BA3C6538409BBE6F1760F328ABEB19C1FD7D@DEN-MEXMS-001.corp.ebay.com> <5EE049BA3C6538409BBE6F1760F328ABEB19C1FEAE@DEN-MEXMS-001.corp.ebay.com> Date: Tue, 28 Dec 2010 17:04:32 +0000 Message-ID: From: Phillip Hallam-Baker To: "Steingruebl, Andy" Content-Type: multipart/alternative; boundary=0016e644caf04b275e04987b72f4 Cc: "keyassure@ietf.org" , "websec@ietf.org" , Paul Hoffman , Paul Wouters Subject: Re: [websec] [keyassure] HASTLS and client policy preference X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2010 17:02:29 -0000 --0016e644caf04b275e04987b72f4 Content-Type: text/plain; charset=ISO-8859-1 I think that is a great idea. SRV and extended discovery in general can deliver advantages in addition to security. I have found persuading people to change protocol behavior for the sake of security alone to be very hard. SRV offers potential reliability and performance benefits. Which makes it much easier to get adoption. On Tue, Dec 28, 2010 at 4:25 PM, Steingruebl, Andy < asteingruebl@paypal-inc.com> wrote: > > -----Original Message----- > > From: Paul Wouters [mailto:paul@xelerance.com] > > > Though I blieve the HASTLS record should not become the "legitimate open > > port list" of a host though, people should not trust clients to adhere to > > HASTLS for their server security, and instead have proper firewall > policies. > > > > Personally, I would prefer not to have to build a list of insecure ports > if I have > > no secure version of it available, but then again I would expect any > client that > > can do HASTLS to be able to do the secure version anyway. And for new > > protocols to not come out with an insecure version. > > > > Perhaps it makes sense to rename HASTLS to something else. TLSSTAT? > > STATTLS? TLSAVAIL? > > The idea I've been toying around with is actually changing how service > lookups happen. I don't have a well-formulated idea yet but it seems that > just as many protocols/applications (I struggle for the right word here) do > SRV lookups, maybe we ought to somehow bundle the TLS preference into that > lookup scheme. If we did, we could tackle the keys-in-dns problem and > has/requires-TLS problem in the same SRV lookup. HASTLS would be a part of > looking up the properties of a service you're about to connect to. > > I'm more than a little inexperienced with existing SRV lookups, so can't > quite articulate how I think this would best work. > > - Andy > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > -- Website: http://hallambaker.com/ --0016e644caf04b275e04987b72f4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think that is a great idea.

SRV and extended discovery= in general can deliver advantages in addition to security.=A0
I have found persuading people to change protocol behavior for= the sake of security alone to be very hard. SRV offers potential reliabili= ty and performance benefits. Which makes it much easier to get adoption.


On Tue, Dec 28, 2010 at = 4:25 PM, Steingruebl, Andy <asteingruebl@paypal-inc.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex;">
> -----Original Message-----
> From: Paul Wouters [mailto:paul@= xelerance.com]

> Though I blieve the HASTLS record should not become the "legitima= te open
> port list" of a host though, people should not trust clients to a= dhere to
> HASTLS for their server security, and instead have proper firewall pol= icies.
>
> Personally, I would prefer not to have to buil= d a list of insecure ports if I have
> no secure version of it available, but then again I would expect any c= lient that
> can do HASTLS to be able to do the secure version anyway. And for new<= br> > protocols to not come out with an insecure version.
>
> Perhaps it makes sense to rename HASTLS to something else. TLSSTAT? > STATTLS? TLSAVAIL?

The idea I've been toying around with is actually changing how se= rvice lookups happen. =A0I don't have a well-formulated idea yet but it= seems that just as many protocols/applications (I struggle for the right w= ord here) do SRV lookups, maybe we ought to somehow bundle the TLS preferen= ce into that lookup scheme. =A0 If we did, we could tackle the keys-in-dns = problem and has/requires-TLS problem in the same SRV lookup. =A0HASTLS woul= d be a part of looking up the properties of a service you're about to c= onnect to.

I'm more than a little inexperienced with existing SRV lookups, so can&= #39;t quite articulate how I think this would best work.

- Andy
__________________________________= _____________
keyassure mailing list
keyassure@ietf.org
https://www.ietf.org/mailman/listinfo/keyassure



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

--0016e644caf04b275e04987b72f4-- From paul@xelerance.com Sun Dec 26 19:14:19 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FA2B3A683E; Sun, 26 Dec 2010 19:14:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUvXqDmqYoRP; Sun, 26 Dec 2010 19:14:18 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 297B53A6835; Sun, 26 Dec 2010 19:14:18 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 237C0C4F3; Sun, 26 Dec 2010 22:16:21 -0500 (EST) Date: Sun, 26 Dec 2010 22:16:20 -0500 (EST) From: Paul Wouters To: Paul Hoffman In-Reply-To: Message-ID: References: <20101213220001.24500.52050.idtracker@localhost> <1292899636.1888.75.camel@mattlaptop2.local> <5EE049BA3C6538409BBE6F1760F328ABEB19B00699@DEN-MEXMS-001.corp.ebay.com> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Tue, 28 Dec 2010 16:09:26 -0800 Cc: websec@ietf.org, keyassure@ietf.org Subject: Re: [websec] [keyassure] HASTLS and client policy preference X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Dec 2010 03:14:19 -0000 On Sun, 26 Dec 2010, Paul Hoffman wrote: > Greetings again. I still don't like the idea of a host asserting a client policy preference, but I hear many folks wanting it. I think I have added it cleanly in draft-hoffman-server-has-tls-02, but I'm not sure and would like to hear more from folks, especially those who like the current semantics in draft-hodges-strict-transport-sec. The new draft is at , and the diffs from the last draft are at . I'm not sure if CIO/CSO/CFB are still described properly, because it is no longer a "client type" but it depends on the particular tripplet. For instance, if we have IN HASTLS (25 25 0 80 443 1) then what would you call the "server" or the matching "client"? They are CFB/SFB for some protocols and CSO/SSO for other protocols. 1 -- If the client could be configured as either CFB or CSO, and the host's administrator was able to configure the client, that administrator would configure the client as CSO. Stated another way, the host's administrator does not want any CFB client to access the host. This should probably have some "protocol" modifiers added, eg 1 -- If the client could be configured as either CFB or CSO for a particular service tripplet, and ..." Perhaps it should also be stated that the client policy preference MUST be 0 if either the secure or insecure port is specified as 0. Other then that, the changes address all my issues. Thanks! Paul From paul@xelerance.com Mon Dec 27 18:33:02 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F6C73A6908; Mon, 27 Dec 2010 18:33:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7pTLb5Lj174; Mon, 27 Dec 2010 18:33:00 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 4386B3A6800; Mon, 27 Dec 2010 18:32:59 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 3E10FC45B; Mon, 27 Dec 2010 21:35:03 -0500 (EST) Date: Mon, 27 Dec 2010 21:35:02 -0500 (EST) From: Paul Wouters To: "Steingruebl, Andy" In-Reply-To: <5EE049BA3C6538409BBE6F1760F328ABEB19C1FD7D@DEN-MEXMS-001.corp.ebay.com> Message-ID: References: <20101213220001.24500.52050.idtracker@localhost> <1292899636.1888.75.camel@mattlaptop2.local> <5EE049BA3C6538409BBE6F1760F328ABEB19B00699@DEN-MEXMS-001.corp.ebay.com> <5EE049BA3C6538409BBE6F1760F328ABEB19C1FD7D@DEN-MEXMS-001.corp.ebay.com> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Tue, 28 Dec 2010 16:09:26 -0800 Cc: "websec@ietf.org" , "keyassure@ietf.org" , Paul Hoffman Subject: Re: [websec] [keyassure] HASTLS and client policy preference X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2010 02:33:02 -0000 On Mon, 27 Dec 2010, Steingruebl, Andy wrote: > 5. Maybe this came up earlier but I'm still slightly confused on overall semantics of this proposal. If HASTLS is about TLS, it is odd to me that it should talk about non-TLS policy, where it listens "insecurely", etc. I have a few thoughts on the general topic of service discovery, but HASTLS seems to bundle two ideas together: a) service discovery and b) whether/how that service operates with TLS. It seems to me that they are slighty different, and co-mingling them doesn't seem quite right. You are somewhat right. For services where you have no secure/TLS version, their entries could simply be omitted and not be part of the HASTLS record. That is, you could not specify: insecure.org. IN HASTLS (80 0 0 25 25 1) but instead: insecure.org. IN HASTLS (25 25 1) An exception might be if you want to prevent clients from connecting to you at all, by specifying insecure.org. IN HASTLS () Though I blieve the HASTLS record should not become the "legitimate open port list" of a host though, people should not trust clients to adhere to HASTLS for their server security, and instead have proper firewall policies. Though I think Paul Hoffman would prefer the first entry over the second one. Though all records, including not having a HASTLS record at all, should have the same effect for clients supporting this RRTYPE. Though they could decided there is nothing on port 80 and refuse to even try in the latter two examples. Personally, I would prefer not to have to build a list of insecure ports if I have no secure version of it available, but then again I would expect any client that can do HASTLS to be able to do the secure version anyway. And for new protocols to not come out with an insecure version. Perhaps it makes sense to rename HASTLS to something else. TLSSTAT? STATTLS? TLSAVAIL? Paul From paul.hoffman@vpnc.org Tue Dec 28 16:53:16 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 542623A68F6; Tue, 28 Dec 2010 16:53:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.322 X-Spam-Level: X-Spam-Status: No, score=-101.322 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_31=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oD1gRscIh7YH; Tue, 28 Dec 2010 16:53:15 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 6C5B23A6826; Tue, 28 Dec 2010 16:53:15 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id oBT0tGUv074866 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 28 Dec 2010 17:55:19 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D1A86F4.2030209@vpnc.org> Date: Tue, 28 Dec 2010 16:55:16 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Steingruebl, Andy" References: <20101213220001.24500.52050.idtracker@localhost> <1292899636.1888.75.camel@mattlaptop2.local> <5EE049BA3C6538409BBE6F1760F328ABEB19B00699@DEN-MEXMS-001.corp.ebay.com> <5EE049BA3C6538409BBE6F1760F328ABEB19C1FD7D@DEN-MEXMS-001.corp.ebay.com> In-Reply-To: <5EE049BA3C6538409BBE6F1760F328ABEB19C1FD7D@DEN-MEXMS-001.corp.ebay.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "websec@ietf.org" , "keyassure@ietf.org" Subject: Re: [websec] HASTLS and client policy preference X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2010 00:53:16 -0000 On 12/27/10 3:52 PM, Steingruebl, Andy wrote: > 1. I think it would be useful in the security considerations to discuss (briefly?) the MITM threat model at play here. You discuss it in the context of delivery of the DNS data itself, but not the motivation for this proposal in the first place. A major motivation is the MITM attack against the non-TLS version of a protocol. Good call, yes. > 2. Do you have any examples of CFB apps? Many. Most SMTP servers, for example. Many POP and IMAP clients. Many SIP clients. And so on. > A few clients such as Mozilla's Thunderbird when in "discovery" mode will try this, but it isn't very common in my experience, and it would be good to have a few examples I could think about. You are focusing on "current web", not "TLS". > 3. We argues a lot when working on HSTS about the proper behavior of a server supporting HSTS and whether it SHOULD or MUST redirect all HTTP traffic to HTTPS. You come down on the MUST front in this proposal, at least philosophically. If I did, it was a mistake. I don't see where I do so. > Some sites (well, 1 anyway) have chosen not to. I won't go into the details, and it isn't a major issue. I think both policies are reasonable. > 4. One way in protocols that don't support redirects to also indicate to a client that it should not communicate "insecurely" is with error codes. POP/IMAP can both do this with error codes, some of which are usually shown to the user (in some implementations). So, though they don't support protocol-level "redirects" like HTTPS, then still allow signaling to the client albeit in a non-automated way. The POP and IMAP error codes are too obtuse to show to end users. > 5. Maybe this came up earlier but I'm still slightly confused on overall semantics of this proposal. If HASTLS is about TLS, it is odd to me that it should talk about non-TLS policy, where it listens "insecurely", etc. Any client-server protocol that does not require TLS all the time will have instances where the server is insecure. Some clients will want to know if a server is even offering the non-TLS version; if not, it will never try to go to the non-secure port on that server. > I have a few thoughts on the general topic of service discovery, but HASTLS seems to bundle two ideas together: a) service discovery and b) whether/how that service operates with TLS. It seems to me that they are slighty different, and co-mingling them doesn't seem quite right. HASTLS is *not* about service discovery at all. The spec states "Setting both the "insecure-port" and "secure-port" to 0 in a porttriple is explicitly undefined", but that maybe should be strengthened to a prohibition. > Related to #5, the biggest protocol in our minds that is problematic wrt sslstrip-type attacks is HTTP/HTTPS, because it is the one protocol that where non fully qualified names, URI(L?)'s are entered, and where the browser has some of its own converting between names and protocols that go on. It is also the one protocol most easily MITM'd in a lot of ways, because much of the web is HTTP, and active attackers can easily insert references to resources causing the client to retrieve them. The same isn't true of most other protocols such as IMAP. Which isn't to say that this proposal isn't a good idea for IMAP, its just that IMAP/POP aren't quite so ripe for abuse generally. I understand your emphasis on TLS, but there is a much bigger world out there, and attacks in that world are just as serious. If one security extension can cover multiple server protocols, that would be good, I think. --Paul Hoffman From paul.hoffman@vpnc.org Tue Dec 28 16:53:27 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D46E3A6962; Tue, 28 Dec 2010 16:53:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.623 X-Spam-Level: X-Spam-Status: No, score=-101.623 tagged_above=-999 required=5 tests=[AWL=0.423, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id An5pbS5EDcOs; Tue, 28 Dec 2010 16:53:26 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id E1D2B3A696E; Tue, 28 Dec 2010 16:53:26 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id oBT0tR7R074885 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 28 Dec 2010 17:55:30 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D1A86FF.5030300@vpnc.org> Date: Tue, 28 Dec 2010 16:55:27 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Paul Wouters References: <20101213220001.24500.52050.idtracker@localhost> <5EE049BA3C6538409BBE6F1760F328ABEB19B00699@DEN-MEXMS-001.corp.ebay.com> <5EE049BA3C6538409BBE6F1760F328ABEB19C1FD7D@DEN-MEXMS-001.corp.ebay.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "websec@ietf.org" , "keyassure@ietf.org" Subject: Re: [websec] [keyassure] HASTLS and client policy preference X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2010 00:53:27 -0000 On 12/27/10 6:35 PM, Paul Wouters wrote: > For services where you have no secure/TLS version, their entries could > simply be omitted and not be part of the HASTLS record. That is, you > could not specify: > > insecure.org. IN HASTLS (80 0 0 25 25 1) > > but instead: > > insecure.org. IN HASTLS (25 25 1) This does not tell an HTTP client that is CIO or CFB that there is, in fact, a server at port 80. Why do you want to prevent them from knowing that? > An exception might be if you want to prevent clients from connecting to > you at all, by specifying > > insecure.org. IN HASTLS () That is prohibited by the spec, on purpose. > Though I blieve the HASTLS record should not become the "legitimate > open port list" of a host though, people should not trust clients to > adhere to HASTLS for their server security, and instead have proper > firewall policies. Correct. > Though I think Paul Hoffman would prefer the first entry over the second > one. Though all records, including not having a HASTLS record at all, > should have the same effect for clients supporting this RRTYPE. Though > they could decided there is nothing on port 80 and refuse to even try > in the latter two examples. Yes, that's a reasonable policy. > Personally, I would prefer not to have to build a list of insecure ports > if I have no secure version of it available, but then again I would > expect any client that can do HASTLS to be able to do the secure version > anyway. And for new protocols to not come out with an insecure version. Both those expectations are probably unwise. The first assumes that all clients that use HASTLS want to do TLS; some won't. The second assumes that all applications will use TLS for security, which is probably unwise. > Perhaps it makes sense to rename HASTLS to something else. TLSSTAT? > STATTLS? TLSAVAIL? Bikeshed. From paul.hoffman@vpnc.org Tue Dec 28 16:53:42 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C42B3A68F6; Tue, 28 Dec 2010 16:53:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.626 X-Spam-Level: X-Spam-Status: No, score=-101.626 tagged_above=-999 required=5 tests=[AWL=0.420, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EU-FyB20cSDE; Tue, 28 Dec 2010 16:53:41 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id B686C3A6826; Tue, 28 Dec 2010 16:53:41 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id oBT0tYtg074888 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 28 Dec 2010 17:55:36 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D1A8706.507@vpnc.org> Date: Tue, 28 Dec 2010 16:55:34 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Paul Wouters References: <20101213220001.24500.52050.idtracker@localhost> <1292899636.1888.75.camel@mattlaptop2.local> <5EE049BA3C6538409BBE6F1760F328ABEB19B00699@DEN-MEXMS-001.corp.ebay.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: keyassure@ietf.org, websec@ietf.org Subject: Re: [websec] [keyassure] HASTLS and client policy preference X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2010 00:53:42 -0000 On 12/26/10 7:16 PM, Paul Wouters wrote: > I'm not sure if CIO/CSO/CFB are still described properly, because it is > no longer a "client type" but it depends on the particular tripplet. The client still gets to decide what its policy is. It gets to decide whether or not it conforms to the HASTLS semantics. > For instance, if we have IN HASTLS (25 25 0 80 443 1) then what would you > call the "server" or the matching "client"? I don't understand the question. There is an SMTP server and an HTTP server. The system requesting the information might have clients for both, either, or none. > They are CFB/SFB for some protocols > and CSO/SSO for other protocols. IN the above, if there is an SMTP client, it could be either CSO, CFB, or CIO. > > > 1 -- If the client could be configured as either CFB or CSO, and > the host's administrator was able to configure the client, that > administrator would configure the client as CSO. Stated another > way, the host's administrator does not want any CFB client to > access the host. > > This should probably have some "protocol" modifiers added, eg > > 1 -- If the client could be configured as either CFB or CSO for a > particular service tripplet, and ..." Good point, yes. I'll add that in the next draft. > Perhaps it should also be stated that the client policy preference > MUST be > 0 if either the secure or insecure port is specified as 0. I don't think so. This can lead to some silly states, like if you specify "1" and the TLS-based service goes down for some reason. I said in the sentence following what you quoted above: Note that specifying 1 for the client policy preference when a host does not support a protocol securely makes no sense, but it also does no harm. I still believe that is true. > > Other then that, the changes address all my issues. Thanks! Glad to hear it. From benl@google.com Wed Dec 29 05:30:54 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12E5028C0DE for ; Wed, 29 Dec 2010 05:30:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.955 X-Spam-Level: X-Spam-Status: No, score=-103.955 tagged_above=-999 required=5 tests=[AWL=-1.978, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NwlyFhPQygts for ; Wed, 29 Dec 2010 05:30:54 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id CD92128C0FB for ; Wed, 29 Dec 2010 05:30:53 -0800 (PST) Received: from hpaq2.eem.corp.google.com (hpaq2.eem.corp.google.com [172.25.149.2]) by smtp-out.google.com with ESMTP id oBTDWt8B003394 for ; Wed, 29 Dec 2010 05:32:56 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1293629579; bh=Km2UeKYIEIr0U4QE8yqKg5o0zFI=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=IdJaHxnGKKA3iLsAyiC9cmC7JEmdTUsHJmpLpUNUOM7l8VU/efKQRVZH1khIYO7ow GKd1O0MTtBXZiFrNPCzEw== Received: from qwe5 (qwe5.prod.google.com [10.241.194.5]) by hpaq2.eem.corp.google.com with ESMTP id oBTDWr07007816 for ; Wed, 29 Dec 2010 05:32:54 -0800 Received: by qwe5 with SMTP id 5so10433108qwe.12 for ; Wed, 29 Dec 2010 05:32:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/zWkUK+Oe83sDsw7RlxsGe7OE3mcDwDmBJLahEGlYEM=; b=P2gdotndFD8A11RgG/18fNv9KiEOwCjyuXOKwQpTF98L4pKQhyx0rA9q7crf6VXgCM nyNMCV/TRh92MIWsox1g== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=UQoCE47YFJBOv9WU6KFJKVA/6MJ27HPntsUOZMKPYp3vBhYx/mcD9A1zInrJObFADO gKHTqLHLKIuYNxAQUrLQ== MIME-Version: 1.0 Received: by 10.224.53.193 with SMTP id n1mr13986121qag.270.1293629571645; Wed, 29 Dec 2010 05:32:51 -0800 (PST) Received: by 10.220.88.137 with HTTP; Wed, 29 Dec 2010 05:32:51 -0800 (PST) In-Reply-To: References: <20101213220001.24500.52050.idtracker@localhost> <1292899636.1888.75.camel@mattlaptop2.local> <5EE049BA3C6538409BBE6F1760F328ABEB19B00699@DEN-MEXMS-001.corp.ebay.com> <4D1A8706.507@vpnc.org> Date: Wed, 29 Dec 2010 13:32:51 +0000 Message-ID: From: Ben Laurie To: Paul Wouters Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: websec@ietf.org, keyassure@ietf.org, Paul Hoffman Subject: Re: [websec] [keyassure] HASTLS and client policy preference X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2010 13:30:54 -0000 On 29 December 2010 05:26, Paul Wouters wrote: > On Tue, 28 Dec 2010, Paul Hoffman wrote: > > Actually, one more question. You wrote in section 2: > > =A0 =A0 =A0 =A0An example of a hash for a single certificate: > > =A0 =A0 =A0 =A0www.example.com. IN TLSA 1 2 AgHne3GdTpxjwLCgMzvgpBiOSQthj= g=3D=3D > > The hash type here is 2, and you refer to > http://www.iana.org/assignments/tls-parameters > which refers to http://tools.ietf.org/html/rfc5246 for sha1, but I did no= t > find that RFC > (about TLS) mentioning anything about encoding of the hash. > > The above listed encoding seems to not have enough characters to be a bas= e64 > string of a sha1 hash, It is 30 characters, + 2 padding, which seems just about right to me. > so I'm a little confused what you generated. Which > means it should probably get a better explanation in the text. > > Paul > _______________________________________________ > keyassure mailing list > keyassure@ietf.org > https://www.ietf.org/mailman/listinfo/keyassure > From coderrr.contact@gmail.com Wed Dec 29 13:33:15 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9F973A68AE for ; Wed, 29 Dec 2010 13:33: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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gY00oEIhzwne for ; Wed, 29 Dec 2010 13:33:15 -0800 (PST) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by core3.amsl.com (Postfix) with ESMTP id 334B53A67E9 for ; Wed, 29 Dec 2010 13:33:15 -0800 (PST) Received: by wwi17 with SMTP id 17so10808095wwi.1 for ; Wed, 29 Dec 2010 13:35:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=asVjXOCV4NMKs3nGF+ygILIG7oWnTuwMhjT2QGPf2Iw=; b=ayRZu93pcHKkJGpSOo7rYgUYfcnxJlYXrYQi1M1Dhzi/qJlx7zF6aYE0fqme+HuMOz YQLpRrb51zhHipTux9qN45ziXkTq2LV02bROnN/bsE1KtJEgHkFR6hwNvDXQDwehdBIz /QJPc+Kd/o9uueQi3AQlc40hLXotJOIc1OSCM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Ec7Zx4rJPXhLHPix4TMFardWK0S2Vb7c4eu6hMPUPh2szLdeE8FESwdPwC2eRArEBe mg5A6P0T5MRDpFLdS+t1+kXw2wX3NZTJEf6qTvzs9fdCr0J5mUsVn2oaIPC4zIYzYWem hNZXDIEN72wLsulVg2ro2HrBSFRScpmJK5dyg= MIME-Version: 1.0 Received: by 10.216.175.132 with SMTP id z4mr7205617wel.11.1293658518946; Wed, 29 Dec 2010 13:35:18 -0800 (PST) Received: by 10.216.158.12 with HTTP; Wed, 29 Dec 2010 13:35:18 -0800 (PST) Date: Thu, 30 Dec 2010 04:35:18 +0700 Message-ID: From: steve To: websec@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [websec] HSTS additional directives proposal X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2010 21:33:15 -0000 I feel there are two issues with the current HSTS spec. Both concern sites with site.com -> www.site.com 301 redirects, which is quite popular these days. I'll just address the first concern in this email: ensuring STS policy is set on both site.com and www.site.com when either are visited. Currently it seems the simplest way to do this is add a resource from https://site.com to all of the pages on www.site.com. This has some potential issues and I think it should be simpler. I'm proposing two new STS directives: related-domains=site.com,x.site.com; related-domains-ttl=86400. This would instruct browsers to make https requests to the sites listed in related-domains to check if they had an STS policy. They would need to store the time they requested the site and the specified ttl. They would skip the request for each site if the last requested time + ttl was greater than the current date. Once that was no longer the case they would make a new request the next time they encountered an STS header with those directives set. I'm not sure what the best name for related-domains-ttl would be, maybe -interval or -max-age or something else? Maybe related-domains-ttl could default to some fraction of the STS policy if not set. There could also be a restriction to only allow sub/parent domains in related-domains and possibly a limit on number of domains listed in related-domains to prevent attackers from easily polluting the STS db. It seems to me one of the main goals here should be to make it as hard as possible for website owners to get things wrong. Having everything in one place makes this is many times simpler and less error prone to setup for websites than needing to add a resource to all their pages. It also bypasses the performance implications if they screw up caching/loading of the resource. Thoughts? - steve From ietf@adambarth.com Wed Dec 29 21:46:16 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ACD328C0E7 for ; Wed, 29 Dec 2010 21:46:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.755 X-Spam-Level: X-Spam-Status: No, score=-3.755 tagged_above=-999 required=5 tests=[AWL=-1.378, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GeUylv7NN6eB for ; Wed, 29 Dec 2010 21:46:14 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id ABA0A3A6899 for ; Wed, 29 Dec 2010 21:46:14 -0800 (PST) Received: by yxt33 with SMTP id 33so4906125yxt.31 for ; Wed, 29 Dec 2010 21:48:20 -0800 (PST) Received: by 10.147.167.12 with SMTP id u12mr21354906yao.13.1293688100035; Wed, 29 Dec 2010 21:48:20 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by mx.google.com with ESMTPS id f73sm8735883yhc.4.2010.12.29.21.48.18 (version=SSLv3 cipher=RC4-MD5); Wed, 29 Dec 2010 21:48:18 -0800 (PST) Received: by iwn40 with SMTP id 40so11396408iwn.31 for ; Wed, 29 Dec 2010 21:48:17 -0800 (PST) Received: by 10.231.19.138 with SMTP id a10mr15429291ibb.127.1293688097536; Wed, 29 Dec 2010 21:48:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.11.140 with HTTP; Wed, 29 Dec 2010 21:47:47 -0800 (PST) In-Reply-To: References: From: Adam Barth Date: Wed, 29 Dec 2010 21:47:47 -0800 Message-ID: To: steve Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: websec@ietf.org Subject: Re: [websec] HSTS additional directives proposal X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2010 05:46:16 -0000 Generally speaking, it's problematic to let one origin set policy for another origin, even when the domains are "related" in some sense. HSTS already has an "includeSubDomains" attribute, which is, IMHO, somewhat pushing the envelope in this regard already. w.r.t. your proposal below, we'd need to verify that the other domains actually wanted to opt into HSTS and were able to establish an valid TLS session. That means, we'd have to open a TLS connection to those sites and receive an HSTS header from them anyway. At that point, you might as well just use the Link header with rel=3Dprefetch rather than piling more syntax onto the HSTS header. Adam On Wed, Dec 29, 2010 at 1:35 PM, steve wrote: > I feel there are two issues with the current HSTS spec. =A0Both concern > sites with site.com -> www.site.com 301 redirects, which is quite > popular these days. =A0I'll just address the first concern in this > email: ensuring STS policy is set on both site.com and www.site.com > when either are visited. > > Currently it seems the simplest way to do this is add a resource from > https://site.com to all of the pages on www.site.com. =A0This has some > potential issues and I think it should be simpler. =A0I'm proposing two > new STS directives: related-domains=3Dsite.com,x.site.com; > related-domains-ttl=3D86400. =A0This would instruct browsers to make http= s > requests to the sites listed in related-domains to check if they had > an STS policy. =A0They would need to store the time they requested the > site and the specified ttl. =A0They would skip the request for each site > if the last requested time + ttl was greater than the current date. > Once that was no longer the case they would make a new request the > next time they encountered an STS header with those directives set. > I'm not sure what the best name for related-domains-ttl would be, > maybe -interval or -max-age or something else? =A0Maybe > related-domains-ttl could default to some fraction of the STS policy > if not set. =A0There could also be a restriction to only allow > sub/parent domains in related-domains and possibly a limit on number > of domains listed in related-domains to prevent attackers from easily > polluting the STS db. > > It seems to me one of the main goals here should be to make it as hard > as possible for website owners to get things wrong. =A0Having everything > in one place makes this is many times simpler and less error prone to > setup for websites than needing to add a resource to all their pages. > It also bypasses the performance implications if they screw up > caching/loading of the resource. > > Thoughts? > > - steve > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > From oksteev@gmail.com Thu Dec 30 01:03:14 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AD8B3A6918 for ; Thu, 30 Dec 2010 01:03:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qW+TjCSOdRoA for ; Thu, 30 Dec 2010 01:03:12 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 4A4CA3A68ED for ; Thu, 30 Dec 2010 01:03:12 -0800 (PST) Received: by qwg5 with SMTP id 5so11400850qwg.31 for ; Thu, 30 Dec 2010 01:05:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=7sctK96+RkbRI+xsM4+4NU3v79DzlcLG/1xe91vQZDg=; b=NfA9atDbE74q7yN1la33TnDYiqDk78PPdbyFvOQ+Huo0//HXBiz6ZNtsp4Auv56jF0 6+YXbu1ko3AtwR9IkrymS7GVdJqF/KPstfMBw5s7pgmGbH1RQ6P2daouCbrabQuAniZA Apl9roWCdgDZJXwXpVMbFlqpV/ez06kNp20j0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=cSHwq1N7fpv5BgHIfzCJQp281f8fRornhwGOxALpqc7YGngF00096RtMvYYrjs+/J6 MhvFlEzTGeiGPJK9Po7dqiUaWFdwcv1m3zvRggHnr1CLr0/9Th3U4oixuwzV7QglLu4G B7hZcKXwnIUPCG8cykdMPinwXGyWIBvDA+RZ8= MIME-Version: 1.0 Received: by 10.224.89.74 with SMTP id d10mr14912644qam.335.1293699917692; Thu, 30 Dec 2010 01:05:17 -0800 (PST) Sender: oksteev@gmail.com Received: by 10.220.63.74 with HTTP; Thu, 30 Dec 2010 01:05:17 -0800 (PST) In-Reply-To: References: Date: Thu, 30 Dec 2010 16:05:17 +0700 X-Google-Sender-Auth: nGHWQTmd81WUmkzbm8TBZ8EbuYE Message-ID: From: steve To: Adam Barth Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: websec@ietf.org Subject: Re: [websec] HSTS additional directives proposal X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2010 09:03:58 -0000 On Thu, Dec 30, 2010 at 12:47 PM, Adam Barth wrote: > Generally speaking, it's problematic to let one origin set policy for > another origin, even when the domains are "related" in some sense. > HSTS already has an "includeSubDomains" attribute, which is, IMHO, > somewhat pushing the envelope in this regard already. To be clear I wasn't saying we should let a site set the STS policy for any other site. Merely to indicate to the browser that it must make an HTTPS connection to the related domain to check if an STS policy was set, the same way a resource would do. > > w.r.t. your proposal below, we'd need to verify that the other domains > actually wanted to opt into HSTS and were able to establish an valid > TLS session. =A0That means, we'd have to open a TLS connection to those > sites and receive an HSTS header from them anyway. =A0At that point, you > might as well just use the Link header with rel=3Dprefetch rather than > piling more syntax onto the HSTS header. I didn't think about using the Link header. If that work's I prefer it (as the preferred method) to the resource method because it's closer to having everything in one place (the headers). But... do all browsers support prefetch? Is it officially still in the HTTP spec? This site says it doesn't work with HTTPS https://developer.mozilla.org/en/link_prefetching_faq. Also this would require caching headers to be set manually on wherever you pointed the Link to as opposed to having them directly in the header. Considering we want this as a security feature it seems like it would be better to specify it exactly, as part of the STS header. I agree adding syntax to the header is not great but I think in this case it is worth it because of the simplicity it adds to setting up HSTS. - steve > > Adam > > > On Wed, Dec 29, 2010 at 1:35 PM, steve wrote: >> I feel there are two issues with the current HSTS spec. =A0Both concern >> sites with site.com -> www.site.com 301 redirects, which is quite >> popular these days. =A0I'll just address the first concern in this >> email: ensuring STS policy is set on both site.com and www.site.com >> when either are visited. >> >> Currently it seems the simplest way to do this is add a resource from >> https://site.com to all of the pages on www.site.com. =A0This has some >> potential issues and I think it should be simpler. =A0I'm proposing two >> new STS directives: related-domains=3Dsite.com,x.site.com; >> related-domains-ttl=3D86400. =A0This would instruct browsers to make htt= ps >> requests to the sites listed in related-domains to check if they had >> an STS policy. =A0They would need to store the time they requested the >> site and the specified ttl. =A0They would skip the request for each site >> if the last requested time + ttl was greater than the current date. >> Once that was no longer the case they would make a new request the >> next time they encountered an STS header with those directives set. >> I'm not sure what the best name for related-domains-ttl would be, >> maybe -interval or -max-age or something else? =A0Maybe >> related-domains-ttl could default to some fraction of the STS policy >> if not set. =A0There could also be a restriction to only allow >> sub/parent domains in related-domains and possibly a limit on number >> of domains listed in related-domains to prevent attackers from easily >> polluting the STS db. >> >> It seems to me one of the main goals here should be to make it as hard >> as possible for website owners to get things wrong. =A0Having everything >> in one place makes this is many times simpler and less error prone to >> setup for websites than needing to add a resource to all their pages. >> It also bypasses the performance implications if they screw up >> caching/loading of the resource. >> >> Thoughts? >> >> - steve >> _______________________________________________ >> websec mailing list >> websec@ietf.org >> https://www.ietf.org/mailman/listinfo/websec >> > From ietf@adambarth.com Thu Dec 30 01:25:24 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0918F28C0DC for ; Thu, 30 Dec 2010 01:25:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.244 X-Spam-Level: X-Spam-Status: No, score=-3.244 tagged_above=-999 required=5 tests=[AWL=-1.867, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_38=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVt3wqvXmE8p for ; Thu, 30 Dec 2010 01:25:22 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 9E84728B23E for ; Thu, 30 Dec 2010 01:25:22 -0800 (PST) Received: by iyi42 with SMTP id 42so10393904iyi.31 for ; Thu, 30 Dec 2010 01:27:28 -0800 (PST) Received: by 10.42.241.195 with SMTP id lf3mr14826838icb.472.1293701247339; Thu, 30 Dec 2010 01:27:27 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by mx.google.com with ESMTPS id ca7sm6302474icb.12.2010.12.30.01.27.24 (version=SSLv3 cipher=RC4-MD5); Thu, 30 Dec 2010 01:27:25 -0800 (PST) Received: by iwn40 with SMTP id 40so11509986iwn.31 for ; Thu, 30 Dec 2010 01:27:23 -0800 (PST) Received: by 10.231.199.12 with SMTP id eq12mr15836154ibb.2.1293701243466; Thu, 30 Dec 2010 01:27:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.11.140 with HTTP; Thu, 30 Dec 2010 01:26:53 -0800 (PST) In-Reply-To: References: From: Adam Barth Date: Thu, 30 Dec 2010 01:26:53 -0800 Message-ID: To: steve Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: websec@ietf.org Subject: Re: [websec] HSTS additional directives proposal X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2010 09:25:24 -0000 On Thu, Dec 30, 2010 at 1:05 AM, steve wrote: > On Thu, Dec 30, 2010 at 12:47 PM, Adam Barth wrote: >> Generally speaking, it's problematic to let one origin set policy for >> another origin, even when the domains are "related" in some sense. >> HSTS already has an "includeSubDomains" attribute, which is, IMHO, >> somewhat pushing the envelope in this regard already. > > To be clear I wasn't saying we should let a site set the STS policy > for any other site. =A0Merely to indicate to the browser that it must > make an HTTPS connection to the related domain to check if an STS > policy was set, the same way a resource would do. > >> w.r.t. your proposal below, we'd need to verify that the other domains >> actually wanted to opt into HSTS and were able to establish an valid >> TLS session. =A0That means, we'd have to open a TLS connection to those >> sites and receive an HSTS header from them anyway. =A0At that point, you >> might as well just use the Link header with rel=3Dprefetch rather than >> piling more syntax onto the HSTS header. > > I didn't think about using the Link header. =A0If that work's I prefer > it (as the preferred method) to the resource method because it's > closer to having everything in one place (the headers). =A0But... do all > browsers support prefetch? If not, we can recommend they implement prefetch at the same time they implement HSTS. >=A0Is it officially still in the HTTP spec? I believe so, but I haven't checked. > This site says it doesn't work with HTTPS > https://developer.mozilla.org/en/link_prefetching_faq. That page seems to say "Starting in Gecko 1.9.1 (Firefox 3.5), HTTPS content can be prefetched." Given that HSTS is implemented starting in Firefox 4, I think we're ok on that score. >=A0Also this > would require caching headers to be set manually on wherever you > pointed the Link to as opposed to having them directly in the header. I'm not sure I understand the connection with caching. Are you worried that the prefetch will hit some sort of cache that lacks the HSTS header? That seems to only be a problem if the site isn't sending the HSTS header consistently. > Considering we want this as a security feature it seems like it would > be better to specify it exactly, as part of the STS header. I disagree. If a more general mechanism already does what we want, it seems foolish to re-invent that mechanism poorly just because it wasn't invented in this working group. > I agree adding syntax to the header is not great but I think in this > case it is worth it because of the simplicity it adds to setting up > HSTS. In the bigger picture, however, it add complexity and redundancy, which makes it seem unnecessary. Adam >> On Wed, Dec 29, 2010 at 1:35 PM, steve wrote= : >>> I feel there are two issues with the current HSTS spec. =A0Both concern >>> sites with site.com -> www.site.com 301 redirects, which is quite >>> popular these days. =A0I'll just address the first concern in this >>> email: ensuring STS policy is set on both site.com and www.site.com >>> when either are visited. >>> >>> Currently it seems the simplest way to do this is add a resource from >>> https://site.com to all of the pages on www.site.com. =A0This has some >>> potential issues and I think it should be simpler. =A0I'm proposing two >>> new STS directives: related-domains=3Dsite.com,x.site.com; >>> related-domains-ttl=3D86400. =A0This would instruct browsers to make ht= tps >>> requests to the sites listed in related-domains to check if they had >>> an STS policy. =A0They would need to store the time they requested the >>> site and the specified ttl. =A0They would skip the request for each sit= e >>> if the last requested time + ttl was greater than the current date. >>> Once that was no longer the case they would make a new request the >>> next time they encountered an STS header with those directives set. >>> I'm not sure what the best name for related-domains-ttl would be, >>> maybe -interval or -max-age or something else? =A0Maybe >>> related-domains-ttl could default to some fraction of the STS policy >>> if not set. =A0There could also be a restriction to only allow >>> sub/parent domains in related-domains and possibly a limit on number >>> of domains listed in related-domains to prevent attackers from easily >>> polluting the STS db. >>> >>> It seems to me one of the main goals here should be to make it as hard >>> as possible for website owners to get things wrong. =A0Having everythin= g >>> in one place makes this is many times simpler and less error prone to >>> setup for websites than needing to add a resource to all their pages. >>> It also bypasses the performance implications if they screw up >>> caching/loading of the resource. >>> >>> Thoughts? >>> >>> - steve >>> _______________________________________________ >>> websec mailing list >>> websec@ietf.org >>> https://www.ietf.org/mailman/listinfo/websec >>> >> > From oksteev@gmail.com Thu Dec 30 01:39:59 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D540128C0CF for ; Thu, 30 Dec 2010 01:39:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NjobeJNjfTNh for ; Thu, 30 Dec 2010 01:39:58 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id B5D0C28B23E for ; Thu, 30 Dec 2010 01:39:57 -0800 (PST) Received: by qwg5 with SMTP id 5so11426686qwg.31 for ; Thu, 30 Dec 2010 01:42:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=UN1UNA6L4S0yeGbhXHayKfaiDU7i741BcEJfI8uMW0w=; b=GYfLNBQc+8c/Z0cQmhoSXtdSawSpobZ5ahAyn7hsJ8InXqdNcabKnhxCaXxS3uhRcY +XwU6xgwH6VuMwQY6AxM2Ndg6OJGGFKE7TyjInnk+cajbpBCOEKhtk6JotMXGhMJxUO7 Adl7f9gPUWBdriir3dVX6YMPBv9fWSr5d1jfk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=CcvInPjIoDeQechcpTuz9pJp5j7W9891pUwg/yfduClct9OlaNg3BerOl7dBEXiYX7 TbtZc0EdRRkPo0BEJq57cOyW7z+hj73Dp74B75JxfvRZqL6V6YB4sFcEhb9mPFUYtLY6 pp+eAO3d+0LRy/dUFaEoC0gJ0R+eypjZK+rxE= MIME-Version: 1.0 Received: by 10.224.11.68 with SMTP id s4mr14932435qas.385.1293702121404; Thu, 30 Dec 2010 01:42:01 -0800 (PST) Sender: oksteev@gmail.com Received: by 10.220.63.74 with HTTP; Thu, 30 Dec 2010 01:42:01 -0800 (PST) In-Reply-To: References: Date: Thu, 30 Dec 2010 16:42:01 +0700 X-Google-Sender-Auth: XoCvDZwkUac_pYiV3QunNTFwfRM Message-ID: From: steve To: Adam Barth Content-Type: text/plain; charset=ISO-8859-1 Cc: websec@ietf.org Subject: Re: [websec] HSTS additional directives proposal X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2010 09:40:00 -0000 On Thu, Dec 30, 2010 at 4:26 PM, Adam Barth wrote: > On Thu, Dec 30, 2010 at 1:05 AM, steve wrote: >> On Thu, Dec 30, 2010 at 12:47 PM, Adam Barth wrote: >>> Generally speaking, it's problematic to let one origin set policy for >>> another origin, even when the domains are "related" in some sense. >>> HSTS already has an "includeSubDomains" attribute, which is, IMHO, >>> somewhat pushing the envelope in this regard already. >> >> To be clear I wasn't saying we should let a site set the STS policy >> for any other site. Merely to indicate to the browser that it must >> make an HTTPS connection to the related domain to check if an STS >> policy was set, the same way a resource would do. >> >>> w.r.t. your proposal below, we'd need to verify that the other domains >>> actually wanted to opt into HSTS and were able to establish an valid >>> TLS session. That means, we'd have to open a TLS connection to those >>> sites and receive an HSTS header from them anyway. At that point, you >>> might as well just use the Link header with rel=prefetch rather than >>> piling more syntax onto the HSTS header. >> >> I didn't think about using the Link header. If that work's I prefer >> it (as the preferred method) to the resource method because it's >> closer to having everything in one place (the headers). But... do all >> browsers support prefetch? > > If not, we can recommend they implement prefetch at the same time they > implement HSTS. Two issues with that. One, I think it needs to be required, not a recommendation. And two, is that it makes it more probable browsers will screw things up. It won't be readily apparent that prefetch is important for HSTS unless you're going to put that in the HSTS spec (unless you're putting that directly in the spec). > >> Is it officially still in the HTTP spec? > > I believe so, but I haven't checked. > >> This site says it doesn't work with HTTPS >> https://developer.mozilla.org/en/link_prefetching_faq. > > That page seems to say "Starting in Gecko 1.9.1 (Firefox 3.5), HTTPS > content can be prefetched." > > Given that HSTS is implemented starting in Firefox 4, I think we're ok > on that score. > >> Also this >> would require caching headers to be set manually on wherever you >> pointed the Link to as opposed to having them directly in the header. > > I'm not sure I understand the connection with caching. Are you > worried that the prefetch will hit some sort of cache that lacks the > HSTS header? That seems to only be a problem if the site isn't > sending the HSTS header consistently. > Sorry I was't clear there. The caching issue isn't a security concern but a performance one. If the site doesn't get the caching right on whatever resource they point the prefetch header to it could impose double HTTPS connections every time someone visits their site. >> Considering we want this as a security feature it seems like it would >> be better to specify it exactly, as part of the STS header. > > I disagree. If a more general mechanism already does what we want, it > seems foolish to re-invent that mechanism poorly just because it > wasn't invented in this working group. In general I agree with that sentiment but for security purposes I'm not sure I do. Depending on a non security feature for HSTS seems like a bad choice to me. It requires every browser developer to keep this in mind. Maybe 3 years down the line they decide to improve prefetch and end up breaking how STS uses it. In terms of making HSTS less prone to implementation screw ups it seems better to have everything in one place. > >> I agree adding syntax to the header is not great but I think in this >> case it is worth it because of the simplicity it adds to setting up >> HSTS. > > In the bigger picture, however, it add complexity and redundancy, > which makes it seem unnecessary. If it's better/simpler security for websites that seems like a worthwhile tradeoff. - steve From Internet-Drafts@ietf.org Thu Dec 30 03:00:05 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 157D728C14E; Thu, 30 Dec 2010 03:00:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.47 X-Spam-Level: X-Spam-Status: No, score=-102.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gfXPHbApgg6; Thu, 30 Dec 2010 03:00:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70C9F28C0E5; Thu, 30 Dec 2010 03:00:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20101230110002.14872.38279.idtracker@localhost> Date: Thu, 30 Dec 2010 03:00:02 -0800 Cc: websec@ietf.org Subject: [websec] I-D Action:draft-ietf-websec-origin-00.txt X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2010 11:00:05 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Security Working Group of the IETF. Title : The Web Origin Concept Author(s) : A. Barth Filename : draft-ietf-websec-origin-00.txt Pages : 19 Date : 2010-12-29 This document defines the concept of an "origin", which represents a web principal. Typically, user agents isolate content retrieved from different origins to prevent a malicious web site operator from interfering with the operation of benign web sites. In particular, this document defines how to compute an origin from a URI, how to serialize an origin to a string, and an HTTP header, named "Origin", for indicating which origin caused the user agent to issue a particular HTTP request. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-websec-origin-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-websec-origin-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-12-30025457.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Thu Dec 30 03:00:05 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36E9228C0E5; Thu, 30 Dec 2010 03:00:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.477 X-Spam-Level: X-Spam-Status: No, score=-102.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JfVcJnjnB6DH; Thu, 30 Dec 2010 03:00:03 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14B0D28C148; Thu, 30 Dec 2010 03:00:03 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20101230110003.14872.99318.idtracker@localhost> Date: Thu, 30 Dec 2010 03:00:03 -0800 Cc: websec@ietf.org Subject: [websec] I-D Action:draft-ietf-websec-mime-sniff-00.txt X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2010 11:00:05 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Security Working Group of the IETF. Title : Media Type Sniffing Author(s) : A. Barth, I. Hickson Filename : draft-ietf-websec-mime-sniff-00.txt Pages : 20 Date : 2010-12-29 Many web servers supply incorrect Content-Type header fields with their HTTP responses. In order to be compatible with these servers, user agents consider the content of HTTP responses as well as the Content-Type header fields when determining the effective media type of the response. This document describes an algorithm for determining the effective media type of HTTP responses that balances security and compatibility considerations. Please send feedback on this draft to apps-discuss@ietf.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-websec-mime-sniff-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-websec-mime-sniff-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-12-30025659.I-D@ietf.org> --NextPart-- From paul@xelerance.com Tue Dec 28 18:14:51 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42BC128C0D6; Tue, 28 Dec 2010 18:14:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tr+TXartNzcO; Tue, 28 Dec 2010 18:14:50 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 1D53228B23E; Tue, 28 Dec 2010 18:14:50 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 66FD2C4F3; Tue, 28 Dec 2010 21:16:53 -0500 (EST) Date: Tue, 28 Dec 2010 21:16:52 -0500 (EST) From: Paul Wouters To: Paul Hoffman In-Reply-To: <4D1A8706.507@vpnc.org> Message-ID: References: <20101213220001.24500.52050.idtracker@localhost> <1292899636.1888.75.camel@mattlaptop2.local> <5EE049BA3C6538409BBE6F1760F328ABEB19B00699@DEN-MEXMS-001.corp.ebay.com> <4D1A8706.507@vpnc.org> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Thu, 30 Dec 2010 03:02:12 -0800 Cc: keyassure@ietf.org, websec@ietf.org Subject: Re: [websec] [keyassure] HASTLS and client policy preference X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2010 02:14:51 -0000 On Tue, 28 Dec 2010, Paul Hoffman wrote: > On 12/26/10 7:16 PM, Paul Wouters wrote: >> I'm not sure if CIO/CSO/CFB are still described properly, because it is >> no longer a "client type" but it depends on the particular tripplet. > The client still gets to decide what its policy is. It gets to decide whether > or not it conforms to the HASTLS semantics. I meant (as below) that a client type now belongs to a service tripplet. >> For instance, if we have IN HASTLS (25 25 0 80 443 1) then what would you >> call the "server" or the matching "client"? > I don't understand the question. Same here >> They are CFB/SFB for some protocols >> and CSO/SSO for other protocols. > IN the above, if there is an SMTP client, it could be either CSO, CFB, or > CIO. I meant to talk about servers in this aspect, because based on the HASTLS record we know what the server is. And they can be CFB for some and SFB for others, depending on service tripplet. >> This should probably have some "protocol" modifiers added, eg >> >> 1 -- If the client could be configured as either CFB or CSO for a >> particular service tripplet, and ..." > Good point, yes. I'll add that in the next draft. >> Perhaps it should also be stated that the client policy preference MUST be >> 0 if either the secure or insecure port is specified as 0. > I don't think so. This can lead to some silly states, like if you specify "1" > and the TLS-based service goes down for some reason. If either the insecure or the secure service is 0 (but not both), it means HASTLS compliant clients will only have one way to connect. So there is no "preference". You can only connect to the one secure or insecure port. > I said in the sentence following what you quoted above: > Note that specifying 1 for the client policy preference when a host > does not support a protocol securely makes no sense, but it also does > no harm. > I still believe that is true. But it does no good either. In some sense, it is "lying" because there can be no preference. Imagine an implementation first checks the 5th byte, and then blindly assumes there is a secure and insecure version (why else list the preference as 1) and then picking the secure version, while the HASTLS record stated (80 0 1) and there is none. I would still say, preference SHOULD or MUST be 0 if the service is only offered with one method. >> Other then that, the changes address all my issues. Thanks! > Glad to hear it. Thanks for your work on this! Paul From paul@xelerance.com Tue Dec 28 21:24:47 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97AA73A688C; Tue, 28 Dec 2010 21:24:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CIxgxsdT83H8; Tue, 28 Dec 2010 21:24:46 -0800 (PST) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 533793A6889; Tue, 28 Dec 2010 21:24:45 -0800 (PST) Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id AFD59C4F3; Wed, 29 Dec 2010 00:26:49 -0500 (EST) Date: Wed, 29 Dec 2010 00:26:49 -0500 (EST) From: Paul Wouters To: Paul Hoffman In-Reply-To: <4D1A8706.507@vpnc.org> Message-ID: References: <20101213220001.24500.52050.idtracker@localhost> <1292899636.1888.75.camel@mattlaptop2.local> <5EE049BA3C6538409BBE6F1760F328ABEB19B00699@DEN-MEXMS-001.corp.ebay.com> <4D1A8706.507@vpnc.org> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Thu, 30 Dec 2010 03:02:12 -0800 Cc: keyassure@ietf.org, websec@ietf.org Subject: Re: [websec] [keyassure] HASTLS and client policy preference X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2010 05:24:47 -0000 On Tue, 28 Dec 2010, Paul Hoffman wrote: Actually, one more question. You wrote in section 2: An example of a hash for a single certificate: www.example.com. IN TLSA 1 2 AgHne3GdTpxjwLCgMzvgpBiOSQthjg== The hash type here is 2, and you refer to http://www.iana.org/assignments/tls-parameters which refers to http://tools.ietf.org/html/rfc5246 for sha1, but I did not find that RFC (about TLS) mentioning anything about encoding of the hash. The above listed encoding seems to not have enough characters to be a base64 string of a sha1 hash, so I'm a little confused what you generated. Which means it should probably get a better explanation in the text. Paul From oksteev@gmail.com Thu Dec 30 11:00:21 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 905BC3A6813 for ; Thu, 30 Dec 2010 11:00:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTdzYCZOWu6s for ; Thu, 30 Dec 2010 11:00:20 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 3B91E3A67E7 for ; Thu, 30 Dec 2010 11:00:20 -0800 (PST) Received: by qyj19 with SMTP id 19so12122228qyj.10 for ; Thu, 30 Dec 2010 11:02:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=FSG5eCLCylj3R2nD15njQlImBeXrtibuREcu6wNUJWQ=; b=Hfio3nfkmXk/Gt7KSWi2ooI42aP/ct3gbR3dcIK32twzWFskmwF4m2cTB9+ZMKmfTC 3upv+AyJMuTLrk1XjCLzUzPsSbcOKdz1h/I5Nfr6OmV4SCRIHQu571piOZ/sn1fp2SSl MDjIpMsIZVwiryamr12O0+FqpfaTFaM9StPyE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=AK+0xcKUMlAusvLtS0H11k63zRmoZMwttWc7nWBPjuN7NHirTonNfY/UG+Ufc/GRo+ zIRRZg6Z40U6lLlt7XCRilleeMtBJdJ9Sq3oU24l5D3A43b+HGOx9Z8B3YmiDm7bp4/i UZg9/oGnGXhxx5wQ0OjhIlaUA838Jm89JvT1o= MIME-Version: 1.0 Received: by 10.229.89.84 with SMTP id d20mr1246964qcm.132.1293735745586; Thu, 30 Dec 2010 11:02:25 -0800 (PST) Sender: oksteev@gmail.com Received: by 10.220.63.74 with HTTP; Thu, 30 Dec 2010 11:02:25 -0800 (PST) In-Reply-To: References: Date: Fri, 31 Dec 2010 02:02:25 +0700 X-Google-Sender-Auth: XuiVgkorlItqMj-VHzwlxquBhZE Message-ID: From: steve To: Adam Barth Content-Type: text/plain; charset=ISO-8859-1 Cc: websec@ietf.org Subject: Re: [websec] HSTS additional directives proposal X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2010 19:00:21 -0000 Just to show how many people currently get this wrong, here's the sites listed in the HSTS wikipedia article that screw it up. Note that I verified none of them are using the resource technique either (at least correctly). $ curl --head http://noisebridge.net HTTP/1.1 302 Found Date: Thu, 30 Dec 2010 18:39:21 GMT Server: Apache Location: https://www.noisebridge.net/ $ curl --head http://strongspace.com HTTP/1.1 301 Moved Permanently Content-Type: text/html Date: Thu, 30 Dec 2010 18:41:44 GMT Location: https://www.strongspace.com/ Connection: Keep-Alive Content-Length: 0 $ curl --head http://www.voipscanner.com HTTP/1.1 301 Moved Permanently Date: Thu, 30 Dec 2010 18:19:31 GMT Server: Apache/2.2.3 (Debian) PHP/5.2.0-8+etch16 mod_ssl/2.2.3 OpenSSL/0.9.8c mod_wsgi/2.5 Python/2.6.1 mod_perl/2.0.2 Perl/v5.8.8 Location: https://voipscanner.com/ Content-Type: text/html; charset=iso-8859-1 $ curl --head https://voipscanner.com HTTP/1.1 303 SEE OTHER Date: Thu, 30 Dec 2010 18:19:25 GMT Server: Apache/2.2.3 (Debian) PHP/5.2.0-8+etch16 mod_ssl/2.2.3 OpenSSL/0.9.8c mod_wsgi/2.5 Python/2.6.1 mod_perl/2.0.2 Perl/v5.8.8 Location: https://voipscanner.com/voipscanner Strict-Transport-Security: max-age=1800 Content-Type: text/html; charset=UTF-8 $ curl --head ssllabs.com HTTP/1.1 301 Moved Permanently Date: Thu, 30 Dec 2010 18:43:56 GMT Server: Apache Location: https://www.ssllabs.com/ Content-Type: text/html; charset=iso-8859-1 $ curl --head http://www.squareup.com HTTP/1.1 301 Moved Permanently Date: Thu, 30 Dec 2010 18:45:08 GMT Content-Type: text/html Content-Length: 178 Location: http://squareup.com/ $ curl --head https://squareup.com HTTP/1.1 200 OK Content-Type: text/html; charset=utf-8 Content-Length: 9344 Cache-Control: private, max-age=0, must-revalidate Strict-Transport-Security: max-age=500 - steve From ietf@adambarth.com Thu Dec 30 11:07:18 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCA683A6827 for ; Thu, 30 Dec 2010 11:07:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.03 X-Spam-Level: X-Spam-Status: No, score=-4.03 tagged_above=-999 required=5 tests=[AWL=-1.053, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBz4qidk6gEe for ; Thu, 30 Dec 2010 11:07:17 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 867223A6825 for ; Thu, 30 Dec 2010 11:07:17 -0800 (PST) Received: by qyk34 with SMTP id 34so12932388qyk.10 for ; Thu, 30 Dec 2010 11:09:23 -0800 (PST) Received: by 10.229.74.206 with SMTP id v14mr3258136qcj.187.1293736161785; Thu, 30 Dec 2010 11:09:21 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by mx.google.com with ESMTPS id s10sm7925974qco.23.2010.12.30.11.09.19 (version=SSLv3 cipher=RC4-MD5); Thu, 30 Dec 2010 11:09:19 -0800 (PST) Received: by iwn40 with SMTP id 40so11924226iwn.31 for ; Thu, 30 Dec 2010 11:09:18 -0800 (PST) Received: by 10.231.156.1 with SMTP id u1mr214005ibw.52.1293736158674; Thu, 30 Dec 2010 11:09:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.11.140 with HTTP; Thu, 30 Dec 2010 11:08:48 -0800 (PST) In-Reply-To: References: From: Adam Barth Date: Thu, 30 Dec 2010 11:08:48 -0800 Message-ID: To: steve Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: websec@ietf.org Subject: Re: [websec] HSTS additional directives proposal X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2010 19:07:18 -0000 I'm not sure what conclusions we're supposed to draw from the below. What would you have expected them to do? Adam On Thu, Dec 30, 2010 at 11:02 AM, steve wrote: > Just to show how many people currently get this wrong, here's the > sites listed in the HSTS wikipedia article that screw it up. =A0Note > that I verified none of them are using the resource technique either > (at least correctly). > > $ curl --head http://noisebridge.net > HTTP/1.1 302 Found > Date: Thu, 30 Dec 2010 18:39:21 GMT > Server: Apache > Location: https://www.noisebridge.net/ > > $ curl --head http://strongspace.com > HTTP/1.1 301 Moved Permanently > Content-Type: text/html > Date: Thu, 30 Dec 2010 18:41:44 GMT > Location: https://www.strongspace.com/ > Connection: Keep-Alive > Content-Length: 0 > > $ curl --head http://www.voipscanner.com > HTTP/1.1 301 Moved Permanently > Date: Thu, 30 Dec 2010 18:19:31 GMT > Server: Apache/2.2.3 (Debian) PHP/5.2.0-8+etch16 mod_ssl/2.2.3 > OpenSSL/0.9.8c mod_wsgi/2.5 Python/2.6.1 mod_perl/2.0.2 Perl/v5.8.8 > Location: https://voipscanner.com/ > Content-Type: text/html; charset=3Diso-8859-1 > $ curl --head https://voipscanner.com > HTTP/1.1 303 SEE OTHER > Date: Thu, 30 Dec 2010 18:19:25 GMT > Server: Apache/2.2.3 (Debian) PHP/5.2.0-8+etch16 mod_ssl/2.2.3 > OpenSSL/0.9.8c mod_wsgi/2.5 Python/2.6.1 mod_perl/2.0.2 Perl/v5.8.8 > Location: https://voipscanner.com/voipscanner > Strict-Transport-Security: max-age=3D1800 > Content-Type: text/html; charset=3DUTF-8 > > $ curl --head ssllabs.com > HTTP/1.1 301 Moved Permanently > Date: Thu, 30 Dec 2010 18:43:56 GMT > Server: Apache > Location: https://www.ssllabs.com/ > Content-Type: text/html; charset=3Diso-8859-1 > > $ curl --head http://www.squareup.com > HTTP/1.1 301 Moved Permanently > Date: Thu, 30 Dec 2010 18:45:08 GMT > Content-Type: text/html > Content-Length: 178 > Location: http://squareup.com/ > $ curl --head https://squareup.com > HTTP/1.1 200 OK > Content-Type: text/html; charset=3Dutf-8 > Content-Length: 9344 > Cache-Control: private, max-age=3D0, must-revalidate > Strict-Transport-Security: max-age=3D500 > > - steve > From asteingruebl@paypal-inc.com Thu Dec 30 11:09:27 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB2BF3A6825 for ; Thu, 30 Dec 2010 11:09:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.138 X-Spam-Level: X-Spam-Status: No, score=-8.138 tagged_above=-999 required=5 tests=[AWL=0.979, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RuYTB+CjOTSC for ; Thu, 30 Dec 2010 11:09:26 -0800 (PST) Received: from den-mipot-001.corp.ebay.com (den-mipot-001.corp.ebay.com [216.113.175.152]) by core3.amsl.com (Postfix) with ESMTP id C38EA3A6813 for ; Thu, 30 Dec 2010 11:09:26 -0800 (PST) DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:CC: Date:Subject:Thread-Topic:Thread-Index:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:acceptlanguage: x-ems-proccessed:x-ems-stamp:Content-Type: Content-Transfer-Encoding:MIME-Version:X-CFilter; b=fHoC6PIg7jv5epsxlc+6joJPs0U8IQz4W33E4SpvPqDA/q/KaLSEsL0Z i2MvCeo9nhpCgoSes5WDIx0DdaJ1SRKH2ihr6fq9ojIaMLXPs2RfH0qVW nivli/Z+0zBku7e; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=asteingruebl@paypal-inc.com; q=dns/txt; s=ppinc; t=1293736293; x=1325272293; h=from:to:cc:date:subject:message-id:references: in-reply-to:content-transfer-encoding:mime-version; z=From:=20"Steingruebl,=20Andy"=20|To:=20steve=20,=20Adam =20Barth=20|CC:=20"websec@ietf.org" =20|Date:=20Thu,=2030=20Dec=202010=2012: 11:29=20-0700|Subject:=20RE:=20[websec]=20HSTS=20addition al=20directives=20proposal|Message-ID:=20<5EE049BA3C65384 09BBE6F1760F328ABEB19C20730@DEN-MEXMS-001.corp.ebay.com> |References:=20=0D=0A=09=0D=0A=09=0D =0A=09=0D=0A=09=0D=0A=20|In-Reply-To: =20|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=hFkKmcD1tpiwkdaE3bIIR5msxOcJ/xuWbdEUil8flRs=; b=DVAWgER7OkOHABTMngTMyi3NXSq8EWaOTSCuu3EE2/UoUNVSl/4JXNAp DT5rNye7l1kraxTKC/spwhLRqhdYdLFT3X0b0fG7XRj0THSjz3tH8f8wk 3TPbkmEZt9VB8b6; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.60,251,1291622400"; d="scan'208";a="149194" Received: from den-vtenf-002.corp.ebay.com (HELO DEN-MEXHT-002.corp.ebay.com) ([10.101.112.213]) by den-mipot-001.corp.ebay.com with ESMTP; 30 Dec 2010 11:11:32 -0800 Received: from DEN-MEXMS-001.corp.ebay.com ([10.241.16.225]) by DEN-MEXHT-002.corp.ebay.com ([10.241.17.53]) with mapi; Thu, 30 Dec 2010 12:11:31 -0700 From: "Steingruebl, Andy" To: steve , Adam Barth Date: Thu, 30 Dec 2010 12:11:29 -0700 Thread-Topic: [websec] HSTS additional directives proposal Thread-Index: AcuoVBuF2SKdQX2kQQG4yfLv8xvskAAANt5Q Message-ID: <5EE049BA3C6538409BBE6F1760F328ABEB19C20730@DEN-MEXMS-001.corp.ebay.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A== x-ems-stamp: 2Eghaz3KZyQbEN9wMf2fcA== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Cc: "websec@ietf.org" Subject: Re: [websec] HSTS additional directives proposal X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2010 19:09:28 -0000 > -----Original Message----- >=20 > Just to show how many people currently get this wrong, here's the sites > listed in the HSTS wikipedia article that screw it up. Note that I verif= ied none > of them are using the resource technique either (at least correctly). I expect to have an adjustment in the not-too-distant future on my end, and= to start cranking up the HSTS max-age in the same timeframe. =20 Also, lots of sites have different amount of traffic that hits their www vs= . non-www site. Also, depending on the scope of their cookies, the type of= attacks possible aren't the same. So yes, we'd like to see things slightly differently, and will consider put= ting this advice into several forums: 1. Advice in the spec itself (if appropriate) 2. in the Wikipedia article. Feel free to edit it yourself to include this= general guidance if you'd like, we probably won't get to it overnight. - Andy From oksteev@gmail.com Thu Dec 30 11:11:15 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12CDE3A6828 for ; Thu, 30 Dec 2010 11:11:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l4fO4IS61PhW for ; Thu, 30 Dec 2010 11:11:11 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 49FF53A6817 for ; Thu, 30 Dec 2010 11:11:08 -0800 (PST) Received: by qyk34 with SMTP id 34so12935459qyk.10 for ; Thu, 30 Dec 2010 11:13:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=+bmzFDBPbUMTdCNw872uHRv1bH+R/kF0tw9jwfaAyuY=; b=bBffYmUfMcdbG3vUz2OvKjnY8jjFIr4HzieXWrX9TIVxZpdDXgDkXOQ65Pm2TzbUHS SL984k96sZhp/M5cGbrDQG27B49t+wbKzstB33P9BuH/OQfjPgfHAf4wH+Kmcp9mq28N fYmgKPwWjjF/u22JwALkvNsyH0eTK2nEFGdKI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=vrXOr4x2GUCvqGciMuV3iFoKp2WT+s3ksH3NoX5yvrmSvnwqzDkZwtg1HliYki9eYi d7fCYhO4hG+mOBEF837wm68oac/lE0pxdeGgPk5pmbPn8Xvvjg4UcnkU4srEt1Zpm2Rr odJO4cuLzl6M9cocnzZf67mCge7zG0PQbvTRM= MIME-Version: 1.0 Received: by 10.224.74.83 with SMTP id t19mr15521886qaj.285.1293736393913; Thu, 30 Dec 2010 11:13:13 -0800 (PST) Sender: oksteev@gmail.com Received: by 10.220.63.74 with HTTP; Thu, 30 Dec 2010 11:13:13 -0800 (PST) In-Reply-To: References: Date: Fri, 31 Dec 2010 02:13:13 +0700 X-Google-Sender-Auth: 8Il-GhdacisWF9fXffM4dLupxAw Message-ID: From: steve To: Adam Barth Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: websec@ietf.org Subject: Re: [websec] HSTS additional directives proposal X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2010 19:11:15 -0000 Sorry, should have been more clear. These are sites which fall prey to what I talked about in my blog. Even though they set the STS header on their main https site many users will never be protected by TLS if they type in the alternate site (meaning domain.com if the main site is www.domain.com and www.domain.com if the main site is domain.com). The only thing I was trying to point out here was it's not that simple to get right. - steve On Fri, Dec 31, 2010 at 2:08 AM, Adam Barth wrote: > I'm not sure what conclusions we're supposed to draw from the below. > What would you have expected them to do? > > Adam > > > On Thu, Dec 30, 2010 at 11:02 AM, steve wrote= : >> Just to show how many people currently get this wrong, here's the >> sites listed in the HSTS wikipedia article that screw it up. =A0Note >> that I verified none of them are using the resource technique either >> (at least correctly). >> >> $ curl --head http://noisebridge.net >> HTTP/1.1 302 Found >> Date: Thu, 30 Dec 2010 18:39:21 GMT >> Server: Apache >> Location: https://www.noisebridge.net/ >> >> $ curl --head http://strongspace.com >> HTTP/1.1 301 Moved Permanently >> Content-Type: text/html >> Date: Thu, 30 Dec 2010 18:41:44 GMT >> Location: https://www.strongspace.com/ >> Connection: Keep-Alive >> Content-Length: 0 >> >> $ curl --head http://www.voipscanner.com >> HTTP/1.1 301 Moved Permanently >> Date: Thu, 30 Dec 2010 18:19:31 GMT >> Server: Apache/2.2.3 (Debian) PHP/5.2.0-8+etch16 mod_ssl/2.2.3 >> OpenSSL/0.9.8c mod_wsgi/2.5 Python/2.6.1 mod_perl/2.0.2 Perl/v5.8.8 >> Location: https://voipscanner.com/ >> Content-Type: text/html; charset=3Diso-8859-1 >> $ curl --head https://voipscanner.com >> HTTP/1.1 303 SEE OTHER >> Date: Thu, 30 Dec 2010 18:19:25 GMT >> Server: Apache/2.2.3 (Debian) PHP/5.2.0-8+etch16 mod_ssl/2.2.3 >> OpenSSL/0.9.8c mod_wsgi/2.5 Python/2.6.1 mod_perl/2.0.2 Perl/v5.8.8 >> Location: https://voipscanner.com/voipscanner >> Strict-Transport-Security: max-age=3D1800 >> Content-Type: text/html; charset=3DUTF-8 >> >> $ curl --head ssllabs.com >> HTTP/1.1 301 Moved Permanently >> Date: Thu, 30 Dec 2010 18:43:56 GMT >> Server: Apache >> Location: https://www.ssllabs.com/ >> Content-Type: text/html; charset=3Diso-8859-1 >> >> $ curl --head http://www.squareup.com >> HTTP/1.1 301 Moved Permanently >> Date: Thu, 30 Dec 2010 18:45:08 GMT >> Content-Type: text/html >> Content-Length: 178 >> Location: http://squareup.com/ >> $ curl --head https://squareup.com >> HTTP/1.1 200 OK >> Content-Type: text/html; charset=3Dutf-8 >> Content-Length: 9344 >> Cache-Control: private, max-age=3D0, must-revalidate >> Strict-Transport-Security: max-age=3D500 >> >> - steve >> > From oksteev@gmail.com Thu Dec 30 11:15:43 2010 Return-Path: X-Original-To: websec@core3.amsl.com Delivered-To: websec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 309CD3A6817 for ; Thu, 30 Dec 2010 11:15:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.479 X-Spam-Level: X-Spam-Status: No, score=-3.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5W9PtzZhMWg for ; Thu, 30 Dec 2010 11:15:42 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 479DD3A6813 for ; Thu, 30 Dec 2010 11:15:41 -0800 (PST) Received: by qyj19 with SMTP id 19so12135506qyj.10 for ; Thu, 30 Dec 2010 11:17:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=44PZoYnkv0kCW3+8s59DkgpuWUH8a/HP+A/BZo64t8U=; b=LuhvLO9OeVqpngaItuczrVnJPRiXOJSvIOYqLolI0CEEwNo2fKEmwPqOUHwPNODO60 5TPT8AbNaHlOuf93mnidVoae70dSt6wGYJbzVs7z2RNme9+f6tk7yK4k+CCPi54Fyy80 HqzRksylTPX33Xge6MI497bD1fVLmfadbBaW0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=u9gSPVDZTfWSJaeEduf76YhgKIcd3o4dbg2l4FpM8qZKSXre20mWkv4ZeJSboJhuQn Tnj/ZIZrTr1kmN6Q615a3MOFKmODMLWpNQcHyB0lIVuKSReRzrJenaQaSq/1jWvngGcL ZtPPD3uBAHWV2hOp9oReYq6ArrAEs20FR6V4g= MIME-Version: 1.0 Received: by 10.224.45.206 with SMTP id g14mr15520984qaf.235.1293736667779; Thu, 30 Dec 2010 11:17:47 -0800 (PST) Sender: oksteev@gmail.com Received: by 10.220.63.74 with HTTP; Thu, 30 Dec 2010 11:17:47 -0800 (PST) In-Reply-To: <5EE049BA3C6538409BBE6F1760F328ABEB19C20730@DEN-MEXMS-001.corp.ebay.com> References: <5EE049BA3C6538409BBE6F1760F328ABEB19C20730@DEN-MEXMS-001.corp.ebay.com> Date: Fri, 31 Dec 2010 02:17:47 +0700 X-Google-Sender-Auth: K9QJ8rRGJjwwwRRZDVuozB_3VgI Message-ID: From: steve To: "Steingruebl, Andy" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "websec@ietf.org" Subject: Re: [websec] HSTS additional directives proposal X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2010 19:15:43 -0000 Yea I understand if sites do their cookies correctly then we're mainly talking about MITM attacks here. But again, how many people actually get things right? :) It would be interesting to see the ratio of who types www. and who leaves it off. My guess is that is something that will change over time though. - steve On Fri, Dec 31, 2010 at 2:11 AM, Steingruebl, Andy wrote: >> -----Original Message----- >> >> Just to show how many people currently get this wrong, here's the sites >> listed in the HSTS wikipedia article that screw it up. =A0Note that I ve= rified none >> of them are using the resource technique either (at least correctly). > > I expect to have an adjustment in the not-too-distant future on my end, a= nd to start cranking up the HSTS max-age in the same timeframe. > > Also, lots of sites have different amount of traffic that hits their www = vs. non-www site. =A0Also, depending on the scope of their cookies, the typ= e of attacks possible aren't the same. > > So yes, we'd like to see things slightly differently, and will consider p= utting this advice into several forums: > > 1. Advice in the spec itself (if appropriate) > 2. in the Wikipedia article. =A0Feel free to edit it yourself to include = this general guidance if you'd like, we probably won't get to it overnight. > > - Andy >