From stephen.farrell@cs.tcd.ie Tue Aug 6 12:42:48 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF41311E80EE for ; Tue, 6 Aug 2013 12:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5OE48OgXEQEW for ; Tue, 6 Aug 2013 12:42:43 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id AB16711E80D1 for ; Tue, 6 Aug 2013 12:42:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B2299BE5C for ; Tue, 6 Aug 2013 20:42:40 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvdLVZIbJO4o for ; Tue, 6 Aug 2013 20:42:39 +0100 (IST) Received: from [10.87.48.8] (unknown [86.41.53.32]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 54706BE5B for ; Tue, 6 Aug 2013 20:42:39 +0100 (IST) Message-ID: <520151A5.8080704@cs.tcd.ie> Date: Tue, 06 Aug 2013 20:42:29 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: "http-auth@ietf.org" X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [http-auth] HOBA code released X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 19:42:48 -0000 Hiya, As I said in Berlin, I've been planning to release our HOBA code. That's done now. (*) Go to [1] for a pointer to the sourceforge project. That implements the -01 version of the draft. There's a separate list for stuff related to this code (signup at [2]) that isn't relevant for the WG. If someone has a chance to play about with it, I'd really appreciate feedback here or there as appropriate. Cheers, S. [1] https://hoba.ie/download.html [2] https://hoba.ie/hobalist.html (*) At least I think it is. 1st time I've used git to create a new sf project so who knows how I messed up;-) From mike@mtcc.com Tue Aug 6 16:20:31 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50FA421F9A17 for ; Tue, 6 Aug 2013 16:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58GrAQCedyBE for ; Tue, 6 Aug 2013 16:20:26 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id DE68C21F8CB4 for ; Tue, 6 Aug 2013 16:20:25 -0700 (PDT) Received: from michael-thomass-macbook.local (RIODSL-74-51-18-153.rsbgor57.rionetworks.com [74.51.18.153] (may be forged)) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r76NKCtS001476 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 6 Aug 2013 16:20:17 -0700 Message-ID: <520184A6.6060608@mtcc.com> Date: Tue, 06 Aug 2013 16:20:06 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: http-auth@ietf.org References: <520151A5.8080704@cs.tcd.ie> In-Reply-To: <520151A5.8080704@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1608; t=1375831218; x=1376695218; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Use=20of=20Well-known=20was=3A=20HOBA=20code=20 released |Sender:=20 |To:=20http-auth@ietf.org |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=Iw5mvfBb77VNHbqe55FkaFgOckVCxiPchRlW+IniNyM=; b=lmoh4v5mia2NiHVFF4wiKcXdOeB7lz+SQzPD516QZM49b78+AZWSzeBbG0 g0mPW//Z2zcNqaSYw2g8tR7QlX18/mq1X/2rbMdSCvwhfw9yt/lgxcslv/6o uyefvQnN87GNPIiw1LvsVgYyf/GkgRaJoze6GILgjdmIwHVvhLzJU=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Subject: [http-auth] Use of Well-known was: HOBA code released X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 23:20:31 -0000 On 8/6/13 12:42 PM, Stephen Farrell wrote: [] I've asked this of Stephen and Paul before what motivates the need for .well-known, and after perusing the code I still have the same question. At the very least if there is actually a good reason for it, we really need to put it into the draft. It seems to me that the only good reason for .well-known is when there is no communication path to get agreement between the server and client implementations of where to send a given http request. That doesn't normally happen in the web world because the web server is ultimately in charge of both itself, and what ends up in the client sandbox. Looking at the code, it looks pretty much like mine wrt url creation, except Stephen is saying it needs to be standardized, and mine doesn't care. The one thing I can think of is if the actual browser code (eg firefox not javascript) is reflexively answering the 401 coming back from the web server demanding hoba authentication. Even in that case, could we not either reuse the Location: header to redirect it to wherever the server wants it to go (including right back to the page it initially requested)? Or if that would amount to a bad overloading of Location: functionality, perhaps we could, instead, define a new HOBA-redirect header with its own specific semantics? In general the use of .well-known makes me sort of nervous. Not affecting the server login/join flow will make it easier to drop it in as a replacement to typical password schemes since it would look pretty much like basic, digest and non-http layer auth. Mike From stephen.farrell@cs.tcd.ie Tue Aug 6 16:36:06 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8630221E809B for ; Tue, 6 Aug 2013 16:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DdROYV18IEK for ; Tue, 6 Aug 2013 16:36:02 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id D558421E809D for ; Tue, 6 Aug 2013 16:36:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 87081BE4D; Wed, 7 Aug 2013 00:36:00 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qi2GB3QZ8YNV; Wed, 7 Aug 2013 00:35:59 +0100 (IST) Received: from [10.87.48.8] (unknown [86.41.53.32]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 46619BE3F; Wed, 7 Aug 2013 00:35:59 +0100 (IST) Message-ID: <5201885F.8000609@cs.tcd.ie> Date: Wed, 07 Aug 2013 00:35:59 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Michael Thomas References: <520151A5.8080704@cs.tcd.ie> <520184A6.6060608@mtcc.com> In-Reply-To: <520184A6.6060608@mtcc.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: http-auth@ietf.org Subject: Re: [http-auth] Use of Well-known was: HOBA code released X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 23:36:06 -0000 Hi Mike, Thanks for bringing this up. I just didn't get the problem when we mailed before, and still don't (so I definitely didn't do it justice in Berlin though I tried.) Maybe the wg will be better able to figure it out. On 08/07/2013 12:20 AM, Michael Thomas wrote: > On 8/6/13 12:42 PM, Stephen Farrell wrote: > [] > > I've asked this of Stephen and Paul before what motivates the need for > .well-known, > and after perusing the code I still have the same question. At the very > least if there > is actually a good reason for it, we really need to put it into the draft. Fair point. > It seems to me that the only good reason for .well-known is when there > is no > communication path to get agreement between the server and client > implementations > of where to send a given http request. That doesn't normally happen in > the web > world because the web server is ultimately in charge of both itself, and > what ends > up in the client sandbox. Looking at the code, it looks pretty much like > mine wrt > url creation, except Stephen is saying it needs to be standardized, and > mine doesn't > care. > > The one thing I can think of is if the actual browser code (eg firefox > not javascript) > is reflexively answering the 401 coming back from the web server > demanding hoba > authentication. Even in that case, could we not either reuse the > Location: header > to redirect it to wherever the server wants it to go (including right > back to the page > it initially requested)? Or if that would amount to a bad overloading of > Location: > functionality, perhaps we could, instead, define a new HOBA-redirect > header with > its own specific semantics? > > In general the use of .well-known makes me sort of nervous. Not > affecting the server > login/join flow will make it easier to drop it in as a replacement to > typical password > schemes since it would look pretty much like basic, digest and non-http > layer auth. So I don't share your nervousness but that might well be due to my ignorance of web deployments. As to the .well-known's we have I would justify 'em as follows: - getchal - needed for very slow signers (e.g. old phone via JS) but where web worker's work - this saves the day - logout - where else should one go? - register - this could be part of applications but seems much better to be a place to which applications can send the browser (if HOBA becomes popular then applications would only have to know "hoba" and not a "hoba, URL" pair) - login - if you assume that applications care about cookies then this seems simpler Having said that, yes a reflexive (*) approach also works with HOBA and with my code. (Check out [1], starting from a not-logged-in state.) So, if there were a cost to registering these .well-known URLs then we could survive, but I don't see the big cost of doing the IANA stuff. S. [1] https://hoba.ie/mimic401.php (*) BTW, is "reflexive" a term of art here? I figure I know what you mean but am not sure if its a term you coined for HTTP auth or is more generally known. Seems useful though. > > Mike > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > > From mike@mtcc.com Tue Aug 6 17:46:21 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ABF421F9A8C for ; Tue, 6 Aug 2013 17:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-AzSwA6G1sE for ; Tue, 6 Aug 2013 17:46:16 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id C050F11E80F2 for ; Tue, 6 Aug 2013 17:46:16 -0700 (PDT) Received: from michael-thomass-macbook.local (RIODSL-74-51-18-153.rsbgor57.rionetworks.com [74.51.18.153] (may be forged)) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r770k7es003104 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 6 Aug 2013 17:46:08 -0700 Message-ID: <520198CA.1070501@mtcc.com> Date: Tue, 06 Aug 2013 17:46:02 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Stephen Farrell References: <520151A5.8080704@cs.tcd.ie> <520184A6.6060608@mtcc.com> <5201885F.8000609@cs.tcd.ie> In-Reply-To: <5201885F.8000609@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3661; t=1375836370; x=1376700370; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[http-auth]=20Use=20of=20Well-known=20w as=3A=20HOBA=20code=20released |Sender:=20 |To:=20Stephen=20Farrell=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=wqLjqndg+6YKVJoulVsSOzEr3zPZ9u2Jp12w1t8VC3k=; b=hudpygmjPwurT3bGgf9WqyORXUL6++fk4qYI5LvyRnUsgmk3PBoRnt/EVM jgQhthINo6RXrrCjgvY8cb28RsCo59bsjMMXTcvW7LtuTvf5eEptY626rpps tfmEuIJMljjkJtPFUdk0FKDj73kEf1Fn5ACp2T53i3+Ihury+qB6I=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: http-auth@ietf.org Subject: Re: [http-auth] Use of Well-known was: HOBA code released X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 00:46:21 -0000 On 8/6/13 4:35 PM, Stephen Farrell wrote: > > So I don't share your nervousness but that might well be due to > my ignorance of web deployments. My nervousness is on a couple of fronts. One is that it seems that you'd need access to mod_rewrite in order to redirect the .well-known/hoba/xxx to your, say, php script. And that's just apache, of course. That might be problematic on, say, a hosted server. And even if it's not, it may be a configuration step too far. Similarly, things that expect RESTful behavior may not be all that happy about being forced to redirect to somewhere else... I've been playing with RoR lately and it definitely has an opinion on the way things ought to flow, so dropping these kinds of requirements onto it -- while surely possible - may be quite painful. So it's born mostly out of not wanting to rock the boat, so we can slip hoba into running deployments. > > As to the .well-known's we have I would justify 'em as follows: > > - getchal - needed for very slow signers (e.g. old phone via JS) > but where web worker's work - this saves the day For js implementations, you never need .well-known because the client and server can agree like usual. For browser-based hoba, this isn't an issue at all... it's plenty fast enough. > - logout - where else should one go? Assuming that there isn't a hoba Authorization: header generated each http request, that means you're carrying session state somehow else (typically cookies). If that's true, you don't need logout. The problem with Basic is that it keeps sending the Authorization: header and there's no way to tell the browser to stop sending it. I don't think that's the case here. > - register - this could be part of applications but seems much > better to be a place to which applications can send the browser > (if HOBA becomes popular then applications would only have to > know "hoba" and not a "hoba, URL" pair) > - login - if you assume that applications care about cookies > then this seems simpler I look at this the other way around: I want to start a (slow) transition to non-password based authentication with as little change to my server code/flow as possible. That means that whatever is putting up the authentication barrier probably wants to handle the new auth scheme (hoba) in addition to password based mechanisms. It would be nice if it didn't involve vectoring it through a different URL first and then redirect back to what they were trying to access. That is, why can't we just do as normal http auth does and retry the same url with the proper Authorization: header? That would leave it completely up to the server to decide whether it wants to redirect or not. [I looked up my Location: suggestion and as I suspected it's wrong, but the .well-known could always be emulated by doing a 3xx redirect followed by the 401 hoba.] > > Having said that, yes a reflexive (*) approach also works with HOBA > and with my code. (Check out [1], starting from a not-logged-in > state.) So, if there were a cost to registering these .well-known > URLs then we could survive, but I don't see the big cost of > doing the IANA stuff. I'm not worried about IANA. > > S. > > [1] https://hoba.ie/mimic401.php > > (*) BTW, is "reflexive" a term of art here? I figure I know > what you mean but am not sure if its a term you coined for HTTP > auth or is more generally known. Seems useful though. > I've sort of stolen "reflexive" from Christian Huitema from back in the MGCP days. Not sure if he originated it, or whether it's a term of art, but I do like it too. Mike From mcr@sandelman.ca Tue Aug 6 19:36:37 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC00E21E8063 for ; Tue, 6 Aug 2013 19:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o4YvQdqyghct for ; Tue, 6 Aug 2013 19:36:31 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id C08BC21E80B5 for ; Tue, 6 Aug 2013 19:36:31 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id F221D20172; Tue, 6 Aug 2013 23:42:49 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 4B5A4A904C; Tue, 6 Aug 2013 22:34:54 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 35F9AB8EA6; Tue, 6 Aug 2013 22:34:54 -0400 (EDT) From: Michael Richardson To: Michael Thomas In-Reply-To: <520198CA.1070501@mtcc.com> References: <520151A5.8080704@cs.tcd.ie> <520184A6.6060608@mtcc.com> <5201885F.8000609@cs.tcd.ie> <520198CA.1070501@mtcc.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: http-auth@ietf.org Subject: Re: [http-auth] Use of Well-known was: HOBA code released X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 02:36:37 -0000 --=-=-= Michael Thomas wrote: > Similarly, things that expect RESTful behavior may not be all that happy about > being forced to redirect to somewhere else... I've been playing with RoR lately and it > definitely has an opinion on the way things ought to flow, so dropping these kinds of > requirements onto it -- while surely possible - may be quite painful. Not really. A single map line on config/routes.rb (doing RoR since 2007) -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUgGyS4qHRg3pndX9AQLNKQP/YUrkM5d0180GkGjSWBLRDKCJqrBo4kdm 8uLAFwoiyK0EqLjJU/1efk1iW/P2Tm4KORN88d+aiE3eye/IUsD5F9J/BSLJ6pfc z3lmx7AivgM5MN++GcAviOoF5JZX3Xw+ph6mqLHYETDowSwymVVpsz3FyaZV3yxo 61Z2rQ5OiXM= =syX7 -----END PGP SIGNATURE----- --=-=-=-- From stephen.farrell@cs.tcd.ie Wed Aug 7 03:34:56 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C47F421F9A1D for ; Wed, 7 Aug 2013 03:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xuRH600ZlYwB for ; Wed, 7 Aug 2013 03:34:51 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 6902221F997A for ; Wed, 7 Aug 2013 03:34:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id CD207BE1C; Wed, 7 Aug 2013 11:34:46 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6t-cv+-60+6m; Wed, 7 Aug 2013 11:34:46 +0100 (IST) Received: from [134.226.63.225] (cswireless63-225.scss.tcd.ie [134.226.63.225]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 40E49BE33; Wed, 7 Aug 2013 11:34:46 +0100 (IST) Message-ID: <520222C7.7030905@cs.tcd.ie> Date: Wed, 07 Aug 2013 11:34:47 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Michael Thomas References: <520151A5.8080704@cs.tcd.ie> <520184A6.6060608@mtcc.com> <5201885F.8000609@cs.tcd.ie> <520198CA.1070501@mtcc.com> In-Reply-To: <520198CA.1070501@mtcc.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: http-auth@ietf.org Subject: Re: [http-auth] Use of Well-known was: HOBA code released X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 10:34:56 -0000 Hi Mike, On 08/07/2013 01:46 AM, Michael Thomas wrote: > On 8/6/13 4:35 PM, Stephen Farrell wrote: >> >> So I don't share your nervousness but that might well be due to >> my ignorance of web deployments. > > My nervousness is on a couple of fronts. One is that it seems that you'd > need > access to mod_rewrite in order to redirect the .well-known/hoba/xxx to > your, > say, php script. And that's just apache, of course. That might be > problematic > on, say, a hosted server. And even if it's not, it may be a > configuration step > too far. > > Similarly, things that expect RESTful behavior may not be all that happy > about > being forced to redirect to somewhere else... I've been playing with RoR > lately and it > definitely has an opinion on the way things ought to flow, so dropping > these kinds of > requirements onto it -- while surely possible - may be quite painful. > > So it's born mostly out of not wanting to rock the boat, so we can slip > hoba > into running deployments. I'm fully sympathetic there. Maybe what we need to do is craft text that shows that there's a benefit in each of the .well-known's we register and also text that shows that you don't have to use them if your application context would make that difficult. > >> >> As to the .well-known's we have I would justify 'em as follows: >> >> - getchal - needed for very slow signers (e.g. old phone via JS) >> but where web worker's work - this saves the day > > For js implementations, you never need .well-known because the client > and server can agree like usual. Disagree. Its true that you don't need this getchal but its also true that JS on some devices/UAs is dog slow. And some of those slow devices/UAs do support web workers. This .well-known means you can offload the signing to a worker and have a fresh response (signed challenge) ready when the UI needs one. (Our code does that when it can and it makes a huge difference to responsiveness.) > For browser-based hoba, this isn't an > issue > at all... it's plenty fast enough. Sure, that's true of modern browsers, but there could be other HTTP UAs that are slow. I agree that's a bit speculative since I don't know of one such. >> - logout - where else should one go? > > Assuming that there isn't a hoba Authorization: header generated each http > request, that means you're carrying session state somehow else (typically > cookies). If that's true, you don't need logout. The problem with Basic is > that it keeps sending the Authorization: header and there's no way to tell > the browser to stop sending it. I don't think that's the case here. Oddly, lots of web application people do seem to want logout. While I don't fully get why that's the case, I've heard it from quite a few folks now. >> - register - this could be part of applications but seems much >> better to be a place to which applications can send the browser >> (if HOBA becomes popular then applications would only have to >> know "hoba" and not a "hoba, URL" pair) >> - login - if you assume that applications care about cookies >> then this seems simpler > > I look at this the other way around: I want to start a (slow) transition > to non-password based authentication with as little change to my server > code/flow as possible. That means that whatever is putting up the > authentication > barrier probably wants to handle the new auth scheme (hoba) in addition to > password based mechanisms. It would be nice if it didn't involve vectoring > it through a different URL first and then redirect back to what they were > trying to access. > > That is, why can't we just do as normal http auth does and retry the > same url > with the proper Authorization: header? That would leave it completely up > to the > server to decide whether it wants to redirect or not. Yes, you can do that. I think that having register and login will make that easier for some sites though. For example, the wordpress plugin we did was simpler because of the .well-known's. > > [I looked up my Location: suggestion and as I suspected it's wrong, but the > .well-known could always be emulated by doing a 3xx redirect followed > by the 401 hoba.] > >> >> Having said that, yes a reflexive (*) approach also works with HOBA >> and with my code. (Check out [1], starting from a not-logged-in >> state.) So, if there were a cost to registering these .well-known >> URLs then we could survive, but I don't see the big cost of >> doing the IANA stuff. > > I'm not worried about IANA. Me neither:-) >> >> S. >> >> [1] https://hoba.ie/mimic401.php >> >> (*) BTW, is "reflexive" a term of art here? I figure I know >> what you mean but am not sure if its a term you coined for HTTP >> auth or is more generally known. Seems useful though. >> > > I've sort of stolen "reflexive" from Christian Huitema from back in the > MGCP > days. Not sure if he originated it, or whether it's a term of art, but I > do like > it too. Yup. So going back to the top of this mail I think what we need to do is to craft text that talks about how either the reflexive or .well-known approaches can both work. S. > > Mike > From stephen.farrell@cs.tcd.ie Wed Aug 7 04:19:11 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89EB221E80EE for ; Wed, 7 Aug 2013 04:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TmPqt01DGv+P for ; Wed, 7 Aug 2013 04:19:05 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 82DB611E8122 for ; Wed, 7 Aug 2013 04:19:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0366CBE29; Wed, 7 Aug 2013 12:19:04 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ij+0bt+85qij; Wed, 7 Aug 2013 12:19:03 +0100 (IST) Received: from [134.226.63.225] (cswireless63-225.scss.tcd.ie [134.226.63.225]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D1668BE1C; Wed, 7 Aug 2013 12:19:03 +0100 (IST) Message-ID: <52022D28.9020905@cs.tcd.ie> Date: Wed, 07 Aug 2013 12:19:04 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Yaron Sheffer X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "http-auth@ietf.org" Subject: [http-auth] HOBA mutual auth - could do it but too complex X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 11:19:11 -0000 I had a discussion with Yaron after the httpauth session about the fact that HOBA -01 isn't doing mutual auth and so does depend to an extent on using TLS for server auth. Yaron is understandably keen that we try do mutual-auth if we can. I guess I'm less concerned since our main design goal is to try be a drop-in but better replacement for passwords. We did sketch out a possible mutual authentication feature for HOBA - that'd involve the server signing the challenges and the server telling the UA the server's public key (for verifying challenges) as part of the registration flow. Later when I was chatting with Paul about this, we figured that it wasn't so simple really, if you consider that a web origin might have loads of servers, each with a different challenge-signing key and where those keys get changed now and then. My conclusion for now is that that'd be about as complex as server key pinning and so we shouldn't do it, but we do need to properly document how and why HOBA needs server auth TLS and what can go wrong if you don't have that. (Basically, a MITM could try replay within the validity window of a challenge, depending on how the server constructs challenges. We also need to look at the registration flow and say what a MITM could do then too.) I also plan to look at an option to use TLS channel bindings if the UA and server support that. I need to check out what'd work for that in practice though. Anyone know what, if anything, really works easily there? Cheers, S. From yaronf.ietf@gmail.com Wed Aug 7 06:27:05 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0151B21F9991 for ; Wed, 7 Aug 2013 06:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kNIooNDTtOf2 for ; Wed, 7 Aug 2013 06:27:04 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 4032421F9BB4 for ; Wed, 7 Aug 2013 06:27:04 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id m15so1530438wgh.5 for ; Wed, 07 Aug 2013 06:27:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=E8vScWdbM7LZudl/yqcACEcZ42v/kFMBHNR/0Oy2OUc=; b=GM8u3RonUzEmU0+gbkPAylcMfmwf11VNYwoitgnKhNE35oPwNne8E1Fdtdl32AdqLI GHJQAr8/AyZG4fkGo+ejQMQvh57BbbU+KB9kNLwpfI2bP6zD8ywwPXWzxXaDqH1w7Qvo 8Lh28dkyHTDfNk2pfHfXEjaiVeuPKzqXuqhMsqGOfg254UVQDATaO5NnrGKSwu/Kx+hp KW63KlGyGDzVPi5HjTbhN8fJs9R68ZVK0u0D5MerBYcpacZLGpyakGvFBii3jujjmc0Q mpBNuKunQwKHfJULandHg+FFGWACIgEF089Dq5t3keuvoMtdSX8fIPA7Mm9C1ZLL6m0C wFLw== X-Received: by 10.194.110.39 with SMTP id hx7mr471110wjb.4.1375882023382; Wed, 07 Aug 2013 06:27:03 -0700 (PDT) Received: from [192.168.1.129] ([95.35.54.209]) by mx.google.com with ESMTPSA id a4sm9581504wik.11.2013.08.07.06.27.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 07 Aug 2013 06:27:02 -0700 (PDT) Message-ID: <52024B23.7060900@gmail.com> Date: Wed, 07 Aug 2013 16:26:59 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Stephen Farrell References: <52022D28.9020905@cs.tcd.ie> In-Reply-To: <52022D28.9020905@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "http-auth@ietf.org" Subject: Re: [http-auth] HOBA mutual auth - could do it but too complex X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 13:27:05 -0000 Hi, I may be mis-remembering, but I think the idea mutated a little since we discussed it. I was thinking of a per-user (actually, per-UA) public key for the server, so that the public key is generated on registration, and has the same life cycle as the user's credentials. So you don't need to synch it between servers and this doesn't become similar to key pinning. Thanks, Yaron On 2013-08-07 14:19, Stephen Farrell wrote: > > I had a discussion with Yaron after the httpauth session > about the fact that HOBA -01 isn't doing mutual auth and > so does depend to an extent on using TLS for server auth. > Yaron is understandably keen that we try do mutual-auth > if we can. I guess I'm less concerned since our main > design goal is to try be a drop-in but better replacement > for passwords. > > We did sketch out a possible mutual authentication feature > for HOBA - that'd involve the server signing the challenges > and the server telling the UA the server's public key (for > verifying challenges) as part of the registration flow. > > Later when I was chatting with Paul about this, we figured > that it wasn't so simple really, if you consider that a > web origin might have loads of servers, each with a different > challenge-signing key and where those keys get changed now > and then. > > My conclusion for now is that that'd be about as complex > as server key pinning and so we shouldn't do it, but we do > need to properly document how and why HOBA needs server > auth TLS and what can go wrong if you don't have that. > (Basically, a MITM could try replay within the validity > window of a challenge, depending on how the server > constructs challenges. We also need to look at the > registration flow and say what a MITM could do then > too.) > > I also plan to look at an option to use TLS channel > bindings if the UA and server support that. I need to > check out what'd work for that in practice though. Anyone > know what, if anything, really works easily there? > > Cheers, > S. > From stephen.farrell@cs.tcd.ie Wed Aug 7 06:30:39 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E343021E811B for ; Wed, 7 Aug 2013 06:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wiQZcQ08iwnq for ; Wed, 7 Aug 2013 06:30:34 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4E31F21F99ED for ; Wed, 7 Aug 2013 06:30:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B77FFBE38; Wed, 7 Aug 2013 14:30:29 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qbp3VPymVvvc; Wed, 7 Aug 2013 14:30:29 +0100 (IST) Received: from [134.226.63.225] (cswireless63-225.scss.tcd.ie [134.226.63.225]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 98AECBE25; Wed, 7 Aug 2013 14:30:29 +0100 (IST) Message-ID: <52024BF6.3020402@cs.tcd.ie> Date: Wed, 07 Aug 2013 14:30:30 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Yaron Sheffer References: <52022D28.9020905@cs.tcd.ie> <52024B23.7060900@gmail.com> In-Reply-To: <52024B23.7060900@gmail.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "http-auth@ietf.org" Subject: Re: [http-auth] HOBA mutual auth - could do it but too complex X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 13:30:40 -0000 On 08/07/2013 02:26 PM, Yaron Sheffer wrote: > Hi, > > I may be mis-remembering, but I think the idea mutated a little since we > discussed it. I was thinking of a per-user (actually, per-UA) public key > for the server, so that the public key is generated on registration, and > has the same life cycle as the user's credentials. So you don't need to > synch it between servers and this doesn't become similar to key pinning. Yeah, but per-UA keys have a catch-22 - which key to use to sign a challenge before you know who's going to respond? (Same gotcha as a symmetric scheme would have). Which leads to per-origin keys which leads to the level of complexity of HPKP. (I think, corrections welcome;-) S. > > Thanks, > Yaron > > On 2013-08-07 14:19, Stephen Farrell wrote: >> >> I had a discussion with Yaron after the httpauth session >> about the fact that HOBA -01 isn't doing mutual auth and >> so does depend to an extent on using TLS for server auth. >> Yaron is understandably keen that we try do mutual-auth >> if we can. I guess I'm less concerned since our main >> design goal is to try be a drop-in but better replacement >> for passwords. >> >> We did sketch out a possible mutual authentication feature >> for HOBA - that'd involve the server signing the challenges >> and the server telling the UA the server's public key (for >> verifying challenges) as part of the registration flow. >> >> Later when I was chatting with Paul about this, we figured >> that it wasn't so simple really, if you consider that a >> web origin might have loads of servers, each with a different >> challenge-signing key and where those keys get changed now >> and then. >> >> My conclusion for now is that that'd be about as complex >> as server key pinning and so we shouldn't do it, but we do >> need to properly document how and why HOBA needs server >> auth TLS and what can go wrong if you don't have that. >> (Basically, a MITM could try replay within the validity >> window of a challenge, depending on how the server >> constructs challenges. We also need to look at the >> registration flow and say what a MITM could do then >> too.) >> >> I also plan to look at an option to use TLS channel >> bindings if the UA and server support that. I need to >> check out what'd work for that in practice though. Anyone >> know what, if anything, really works easily there? >> >> Cheers, >> S. >> > > From mike@mtcc.com Wed Aug 7 09:04:59 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89D9511E8150 for ; Wed, 7 Aug 2013 09:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nTSLXiEdJ8qk for ; Wed, 7 Aug 2013 09:04:54 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE1821E8064 for ; Wed, 7 Aug 2013 09:04:48 -0700 (PDT) Received: from michael-thomass-macbook.local (RIODSL-74-51-18-153.rsbgor57.rionetworks.com [74.51.18.153] (may be forged)) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r77G4b9W013590 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 7 Aug 2013 09:04:40 -0700 Message-ID: <5202700F.5050501@mtcc.com> Date: Wed, 07 Aug 2013 09:04:31 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Stephen Farrell References: <520151A5.8080704@cs.tcd.ie> <520184A6.6060608@mtcc.com> <5201885F.8000609@cs.tcd.ie> <520198CA.1070501@mtcc.com> <520222C7.7030905@cs.tcd.ie> In-Reply-To: <520222C7.7030905@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4069; t=1375891481; x=1376755481; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[http-auth]=20Use=20of=20Well-known=20w as=3A=20HOBA=20code=20released |Sender:=20 |To:=20Stephen=20Farrell=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=NxlZz/iWuUdeW3Cg42Li9HL5R9NnOBzsTPFugVQeLU8=; b=E4mnv3tNWon4Jwa8YiP6x/8FAUckWZpSf1apY8WlIVA6c2jv1hHOhNR2KR Bw3svun597S7HdFBJ5grck4lLQBROiVidcm2+TnReu5kaXDN5ZeEdiBQwbQb WgWJ0Emf03bXJI9ooBDuGMZNJPZYnWJPva2h3xEQDkmfeAp6kGixY=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: http-auth@ietf.org Subject: Re: [http-auth] Use of Well-known was: HOBA code released X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 16:04:59 -0000 On 8/7/13 3:34 AM, Stephen Farrell wrote: > >>> As to the .well-known's we have I would justify 'em as follows: >>> >>> - getchal - needed for very slow signers (e.g. old phone via JS) >>> but where web worker's work - this saves the day >> For js implementations, you never need .well-known because the client >> and server can agree like usual. > Disagree. Its true that you don't need this getchal but its > also true that JS on some devices/UAs is dog slow. And some of > those slow devices/UAs do support web workers. This .well-known > means you can offload the signing to a worker and have a > fresh response (signed challenge) ready when the UI needs one. > (Our code does that when it can and it makes a huge difference > to responsiveness.) We're not communicating. I'm not saying that it's not useful. I'm saying that it doesn't require .well-known to achieve that functionality. If it's javascript code, it never requires .well-known because the server that caused the code to ultimately be loaded knows the url which implements the service. The server has to know. Therefore it can inform the js where to get it in the usual ways. > >> For browser-based hoba, this isn't an >> issue >> at all... it's plenty fast enough. > Sure, that's true of modern browsers, but there could be other > HTTP UAs that are slow. I agree that's a bit speculative since > I don't know of one such. We're talking about crypto written in C here, so I think it's ignorable. > >>> - logout - where else should one go? >> Assuming that there isn't a hoba Authorization: header generated each http >> request, that means you're carrying session state somehow else (typically >> cookies). If that's true, you don't need logout. The problem with Basic is >> that it keeps sending the Authorization: header and there's no way to tell >> the browser to stop sending it. I don't think that's the case here. > Oddly, lots of web application people do seem to want logout. > While I don't fully get why that's the case, I've heard it > from quite a few folks now. I'd like to see an actual use case where it's needed. I fully sympathize with the problems of Basic -- I've bitten by it too. But if we're not shipping an Authorization: header with each http request, I don't think there's a problem. BTW: I've looked several times in the text to try to figure out whether hoba-http does or does not require the Authorization: header to be applied to each request from the UA and couldn't find it. So I think we need to have some clarifying text, and/or maybe a couple of ladder diagrams. > > > Yes, you can do that. I think that having register and login > will make that easier for some sites though. For example, the > wordpress plugin we did was simpler because of the .well-known's. I still don't think we're communicating. I have no issue at all vectoring the auth pieces off onto its own page -- some sites will find that convenient, some won't. I just question whether we need to use .well-known to do that. If we don't absolutely, positively need to use .well-known, I'd rather we not. As far I can see, we can achieve the same functionality for the reflexive case by: UA -------------> Protected Resource at https://example.com/foo.html UA <------------- 30x, Location: https://example.com/hobalogin.php UA --------------> (to https://example.com/hobalogin.php) // the next two are optional, but probably typical: UA <-------------- (login/join/whatever page) UA --------------> (submit form, do XHR, etc to "login/join/whatever") UA <-------------- 401 hoba UA --------------> Authorization: hoba [server can now redirect back to https://example.com/foo.html, or whatever else it wants to do] If this is all messed up, can you fix what's wrong... and maybe we can put it into the draft? :) Note that this is pretty much the way you'd do it with non-hoba as well -- my feeling is that if we're stuck requiring .well-known, we're probably not thinking about it right. Mike From stephen.farrell@cs.tcd.ie Wed Aug 7 09:17:05 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68CA011E8134 for ; Wed, 7 Aug 2013 09:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DsS-e7lj8wo for ; Wed, 7 Aug 2013 09:16:59 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 50FBF21F9A96 for ; Wed, 7 Aug 2013 09:16:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0BFB0BE35; Wed, 7 Aug 2013 17:16:58 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2WcAZUArY6D; Wed, 7 Aug 2013 17:16:57 +0100 (IST) Received: from [134.226.63.225] (cswireless63-225.scss.tcd.ie [134.226.63.225]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D4F4EBDE3; Wed, 7 Aug 2013 17:16:57 +0100 (IST) Message-ID: <520272FA.4070502@cs.tcd.ie> Date: Wed, 07 Aug 2013 17:16:58 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Michael Thomas References: <520151A5.8080704@cs.tcd.ie> <520184A6.6060608@mtcc.com> <5201885F.8000609@cs.tcd.ie> <520198CA.1070501@mtcc.com> <520222C7.7030905@cs.tcd.ie> <5202700F.5050501@mtcc.com> In-Reply-To: <5202700F.5050501@mtcc.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: http-auth@ietf.org Subject: Re: [http-auth] Use of Well-known was: HOBA code released X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 16:17:05 -0000 On 08/07/2013 05:04 PM, Michael Thomas wrote: > On 8/7/13 3:34 AM, Stephen Farrell wrote: >> >>>> As to the .well-known's we have I would justify 'em as follows: >>>> >>>> - getchal - needed for very slow signers (e.g. old phone via JS) >>>> but where web worker's work - this saves the day >>> For js implementations, you never need .well-known because the client >>> and server can agree like usual. >> Disagree. Its true that you don't need this getchal but its >> also true that JS on some devices/UAs is dog slow. And some of >> those slow devices/UAs do support web workers. This .well-known >> means you can offload the signing to a worker and have a >> fresh response (signed challenge) ready when the UI needs one. >> (Our code does that when it can and it makes a huge difference >> to responsiveness.) > > We're not communicating. Yeah, I think we're agreeing actually, except about whether having the .well-known's defined is useful even if they're not always necessary. > I'm not saying that it's not useful. I'm > saying that it doesn't require .well-known to achieve that functionality. > If it's javascript code, it never requires .well-known because the server > that caused the code to ultimately be loaded knows the url which implements > the service. The server has to know. Therefore it can inform the js > where to > get it in the usual ways. In the case of getchal though, the worker has to know where to go and without having a side-effect on the application so I think that one is really useful to the point that we defo want it in. >>> For browser-based hoba, this isn't an >>> issue >>> at all... it's plenty fast enough. >> Sure, that's true of modern browsers, but there could be other >> HTTP UAs that are slow. I agree that's a bit speculative since >> I don't know of one such. > > We're talking about crypto written in C here, so I think it's ignorable. That's probably fair. >>>> - logout - where else should one go? >>> Assuming that there isn't a hoba Authorization: header generated each >>> http >>> request, that means you're carrying session state somehow else >>> (typically >>> cookies). If that's true, you don't need logout. The problem with >>> Basic is >>> that it keeps sending the Authorization: header and there's no way to >>> tell >>> the browser to stop sending it. I don't think that's the case here. >> Oddly, lots of web application people do seem to want logout. >> While I don't fully get why that's the case, I've heard it >> from quite a few folks now. > > I'd like to see an actual use case where it's needed. I fully sympathize > with the > problems of Basic -- I've bitten by it too. But if we're not shipping an > Authorization: > header with each http request, I don't think there's a problem. > > BTW: I've looked several times in the text to try to figure out whether > hoba-http > does or does not require the Authorization: header to be applied to each > request > from the UA and couldn't find it. So I think we need to have some > clarifying text, > and/or maybe a couple of ladder diagrams. Yep. >> Yes, you can do that. I think that having register and login >> will make that easier for some sites though. For example, the >> wordpress plugin we did was simpler because of the .well-known's. > > I still don't think we're communicating. I have no issue at all vectoring > the auth pieces off onto its own page -- some sites will find that > convenient, > some won't. I just question whether we need to use .well-known to do that. > If we don't absolutely, positively need to use .well-known, I'd rather > we not. And its only on that last sentence that we disagree I think. I would like that we define the .well-knowns and that sites using hoba would make those available. I'm fine if an application on the site doesn't need 'em. > > As far I can see, we can achieve the same functionality for the > reflexive case by: > > UA -------------> Protected Resource at https://example.com/foo.html > > UA <------------- 30x, Location: https://example.com/hobalogin.php > > UA --------------> (to https://example.com/hobalogin.php) > > // the next two are optional, but probably typical: > > UA <-------------- (login/join/whatever page) > > UA --------------> (submit form, do XHR, etc to "login/join/whatever") > > UA <-------------- 401 hoba > > UA --------------> Authorization: hoba > > [server can now redirect back to https://example.com/foo.html, or > whatever else > it wants to do] > > If this is all messed up, can you fix what's wrong... and maybe we can > put it > into the draft? :) Note that this is pretty much the way you'd do it > with non-hoba > as well -- my feeling is that if we're stuck requiring .well-known, > we're probably > not thinking about it right. I agree. I don't think we require .well-known's (other than getchal) are used but I do think its beneficial if we define 'em and say that sites MUST/SHOULD/MAY offer 'em. (I'm not so fussed on the 2119 keyword we pick I think, maybe SHOULD is right.) I fully agree that we need to describe all this better. S. > > Mike > > From mike@mtcc.com Wed Aug 7 10:21:01 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7DC21F9F44 for ; Wed, 7 Aug 2013 10:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oT2jldpTIsqd for ; Wed, 7 Aug 2013 10:20:51 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 5C6C621F9D52 for ; Wed, 7 Aug 2013 10:20:36 -0700 (PDT) Received: from michael-thomass-macbook.local (RIODSL-74-51-18-153.rsbgor57.rionetworks.com [74.51.18.153] (may be forged)) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r77HKTNI008974 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 7 Aug 2013 10:20:30 -0700 Message-ID: <520281D7.7020807@mtcc.com> Date: Wed, 07 Aug 2013 10:20:23 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Stephen Farrell References: <520151A5.8080704@cs.tcd.ie> <520184A6.6060608@mtcc.com> <5201885F.8000609@cs.tcd.ie> <520198CA.1070501@mtcc.com> <520222C7.7030905@cs.tcd.ie> <5202700F.5050501@mtcc.com> <520272FA.4070502@cs.tcd.ie> In-Reply-To: <520272FA.4070502@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2984; t=1375896031; x=1376760031; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[http-auth]=20Use=20of=20Well-known=20w as=3A=20HOBA=20code=20released |Sender:=20 |To:=20Stephen=20Farrell=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=6BNEIRw28WfUsWcRoudBFMh2oDQwxaLNXTq2SnZsCus=; b=MfpIMogv8Cy7nXiI9vo4ixuHColDxGcCQbpE0z5cvVhoFiB8Op0bcFHuiT LFoNINF6A8ABjhh3XfYxg5xM1aglrkoQ5ooPCme3aoZP1kJz65AMlBa+yUFF wvq9CAkXMa6/CAohMo+EXnv3rIKa9vJzjNymiPgZiG5dPRIN0iKZY=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: http-auth@ietf.org Subject: Re: [http-auth] Use of Well-known was: HOBA code released X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 17:21:01 -0000 On 8/7/13 9:16 AM, Stephen Farrell wrote: > > In the case of getchal though, the worker has to know where to > go and without having a side-effect on the application so I think > that one is really useful to the point that we defo want it in. Sure, but in the js case which is what you're talking about the server can just insert: So it's not really needed. >>> >> I'd like to see an actual use case where it's needed. I fully sympathize >> with the >> problems of Basic -- I've bitten by it too. But if we're not shipping an >> Authorization: >> header with each http request, I don't think there's a problem. So do we agree that we should lose logout unless somebody can really show why it's really necessary? >> >> BTW: I've looked several times in the text to try to figure out whether >> hoba-http >> does or does not require the Authorization: header to be applied to each >> request >> from the UA and couldn't find it. So I think we need to have some >> clarifying text, >> and/or maybe a couple of ladder diagrams. > Yep. Since I've already done one ladder diagram below, I guess I can take the action to generalize/finish it. I personally find ladder diagrams enormously helpful to understand what's going on. >> As far I can see, we can achieve the same functionality for the >> reflexive case by: >> >> UA -------------> Protected Resource at https://example.com/foo.html >> >> UA <------------- 30x, Location: https://example.com/hobalogin.php >> >> UA --------------> (to https://example.com/hobalogin.php) >> >> // the next two are optional, but probably typical: >> >> UA <-------------- (login/join/whatever page) >> >> UA --------------> (submit form, do XHR, etc to "login/join/whatever") >> >> UA <-------------- 401 hoba >> >> UA --------------> Authorization: hoba >> >> [server can now redirect back to https://example.com/foo.html, or >> whatever else >> it wants to do] >> >> If this is all messed up, can you fix what's wrong... and maybe we can >> put it >> into the draft? :) Note that this is pretty much the way you'd do it >> with non-hoba >> as well -- my feeling is that if we're stuck requiring .well-known, >> we're probably >> not thinking about it right. > I agree. I don't think we require .well-known's (other than getchal) > are used but I do think its beneficial if we define 'em and say that > sites MUST/SHOULD/MAY offer 'em. (I'm not so fussed on the 2119 > keyword we pick I think, maybe SHOULD is right.) > > I think if we keep them, it should be optional at most. If we find later that they are more than optional -- ie, that there is actually some really interesting things that it enables -- then we could bump it up to should/must in a -bis draft IMO (and I can't imagine that we won't do a -bis if this becomes popular :) Mike From mike@mtcc.com Wed Aug 7 12:07:40 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1601621E812F for ; Wed, 7 Aug 2013 12:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DqWF0BILWVSr for ; Wed, 7 Aug 2013 12:07:34 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 703AD21E8153 for ; Wed, 7 Aug 2013 12:07:32 -0700 (PDT) Received: from michael-thomass-macbook.local (RIODSL-74-51-18-153.rsbgor57.rionetworks.com [74.51.18.153] (may be forged)) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r77J7TK3015551 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 7 Aug 2013 12:07:31 -0700 Message-ID: <52029AEB.6060607@mtcc.com> Date: Wed, 07 Aug 2013 12:07:23 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: http-auth@ietf.org References: <52022D28.9020905@cs.tcd.ie> <52024B23.7060900@gmail.com> In-Reply-To: <52024B23.7060900@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=849; t=1375902452; x=1376766452; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[http-auth]=20HOBA=20mutual=20auth=20-= 20could=20do=20it=20but=20too=20complex |Sender:=20 |To:=20http-auth@ietf.org |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=uyJLCpyXHz8dJuJQ5Mx1sCqmYLQOkLWgyFZHm23cFOA=; b=j+TOoQJWevwGUIlmxUkUy58nE4yPLYdvBAdM/hf4LUOG9puEOYK1svsiRX j65YWiPgKhA0IQHBCkraB3MErH8JFYag7xea9qnO35yKQAww9g01G6OFSynk i2waELvk7dS1w9pPYTA7QICiJNdtPUQYPHEn/VpAO8aoXrNpB8QFc=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Subject: Re: [http-auth] HOBA mutual auth - could do it but too complex X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 19:07:40 -0000 On 8/7/13 6:26 AM, Yaron Sheffer wrote: > Hi, > > I may be mis-remembering, but I think the idea mutated a little since we discussed it. I was thinking of a per-user (actually, per-UA) public key > for the server, so that the public key is generated on registration, and has the same life cycle as the user's credentials. So you don't need to > synch it between servers and this doesn't become similar to key pinning. > Yaron -- one thing that we should for sure do is make certain that we're future-proofed such that future versions could be made backward compatible for things like mutual. I'm not sure if the current message structure is amenable to that or not. Maybe take a look and see if you could graft your idea on later assuming that Stephen is right here? Mike, especially since this is destined for experimental status From yaronf.ietf@gmail.com Thu Aug 8 09:12:05 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E491021E8091 for ; Thu, 8 Aug 2013 09:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PYSwsZJmgnfO for ; Thu, 8 Aug 2013 09:12:05 -0700 (PDT) Received: from mail-ea0-x232.google.com (mail-ea0-x232.google.com [IPv6:2a00:1450:4013:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE7021E8089 for ; Thu, 8 Aug 2013 09:12:04 -0700 (PDT) Received: by mail-ea0-f178.google.com with SMTP id a15so1513615eae.37 for ; Thu, 08 Aug 2013 09:12:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=JZcxP+ZKvoOIav5NdMyBCTmPRRKn2dYLnh1eGvOttPY=; b=CeonYKhVzxaon4A29QRoJp7hbgLjI5qb7yNkuSVjGylpywAbfD4ZboDt9a1oj1vgcP diFm+Ym9psWQv31Sso0nHIvURYXkIRpcdqUR8gsf/xTsNxURmVouu0v+GOllRIp4mCYZ uFR07i5/Gg1JTWGJudGIyVz7+bjTHs7WzChY2Agk+FQV1FSvoW6oz6DtBlzt+ljp7iJ4 Kuc1ywj/pUxDVdEl2ULKBuJcxJfq5r7eL04kMaVE/bhJO88NuAMOiPesS/PgE64RrwMT +PLmcYRHFraMPgD/fVaBA8ore8FcYQj8msfx+Yvg+/viRj7ipFXw8pXqUGAtRwNQPeW4 HbwA== X-Received: by 10.15.21.76 with SMTP id c52mr8951964eeu.135.1375978324210; Thu, 08 Aug 2013 09:12:04 -0700 (PDT) Received: from [10.0.0.3] (46-116-127-98.bb.netvision.net.il. [46.116.127.98]) by mx.google.com with ESMTPSA id m54sm20374094eex.2.2013.08.08.09.12.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 08 Aug 2013 09:12:03 -0700 (PDT) Message-ID: <5203C351.50804@gmail.com> Date: Thu, 08 Aug 2013 19:12:01 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Michael Thomas References: <52022D28.9020905@cs.tcd.ie> <52024B23.7060900@gmail.com> <52029AEB.6060607@mtcc.com> In-Reply-To: <52029AEB.6060607@mtcc.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: http-auth@ietf.org Subject: Re: [http-auth] HOBA mutual auth - could do it but too complex X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 16:12:06 -0000 I'm not sure I understand the protocol's details well enough to say. A few message-level examples would certainly help. One way we could add mutual authentication using a per-UA server public key is by having the client send a header containing a non-secret "hint", a pointer to the client's identity on the server. The client could add the header to any interaction with the host (like a cookie, sigh) or maybe just to accesses to .well-known/hoba/*. Hoba-mutual-auth-hint: qwerty123456asdf This assumes that after registration, the UA knows what origins are associated with its CPK, and so, also with the SPK. Thanks, Yaron On 2013-08-07 22:07, Michael Thomas wrote: > On 8/7/13 6:26 AM, Yaron Sheffer wrote: >> Hi, >> >> I may be mis-remembering, but I think the idea mutated a little since >> we discussed it. I was thinking of a per-user (actually, per-UA) >> public key for the server, so that the public key is generated on >> registration, and has the same life cycle as the user's credentials. >> So you don't need to synch it between servers and this doesn't become >> similar to key pinning. >> > > Yaron -- one thing that we should for sure do is make certain that we're > future-proofed > such that future versions could be made backward compatible for things > like mutual. > I'm not sure if the current message structure is amenable to that or > not. Maybe take a > look and see if you could graft your idea on later assuming that Stephen > is right here? > > Mike, especially since this is destined for experimental status > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth From internet-drafts@ietf.org Wed Aug 14 13:23:48 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BEFD11E818F; Wed, 14 Aug 2013 13:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XnaIAG+Jnhc2; Wed, 14 Aug 2013 13:23:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 08DB211E8187; Wed, 14 Aug 2013 13:23:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130814202347.27045.46033.idtracker@ietfa.amsl.com> Date: Wed, 14 Aug 2013 13:23:47 -0700 Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-rest-auth-00.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 20:23:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Hypertext Transfer Protocol Authenticatio= n Working Group of the IETF. Title : RESTful Authentication Pattern for the Hypertext Transpo= rt Protocol (HTTP) Author(s) : Nicolas Williams Filename : draft-ietf-httpauth-rest-auth-00.txt Pages : 28 Date : 2013-08-14 Abstract: This document proposes a "RESTful" pattern of authentication for HTTP/1.0, 1.1, and 2.0. The goal is to make it easy to add authentication mechanisms to HTTP and to make it easy to implement them even without much help from the HTTP stack (though it is best to integrate authentication into the stack, of course). Among other benefits of RESTauth: it is orthogonal to "HTTP routers" and proxies, it results in session Uniform Resource Identifiers (URIs) that can be DELETEd to logout, naturally supports multi-legged authentication schemes, and it can be universally implemented on the server side with the Common Gateway Interface (CGI) and FastCGI. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-rest-auth There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-httpauth-rest-auth-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Wed Aug 14 17:21:23 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60A4011E80F3; Wed, 14 Aug 2013 17:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1NJBE6n1UIw7; Wed, 14 Aug 2013 17:21:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ECE6F21F9EDB; Wed, 14 Aug 2013 17:21:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130815002122.4531.50688.idtracker@ietfa.amsl.com> Date: Wed, 14 Aug 2013 17:21:22 -0700 Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-rest-auth-01.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 00:21:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Hypertext Transfer Protocol Authenticatio= n Working Group of the IETF. Title : RESTful Authentication Pattern for the Hypertext Transpo= rt Protocol (HTTP) Author(s) : Nicolas Williams Filename : draft-ietf-httpauth-rest-auth-01.txt Pages : 33 Date : 2013-08-14 Abstract: This document proposes a "RESTful" pattern of authentication for HTTP/1.0, 1.1, and 2.0. The goal is to make it easy to add authentication mechanisms to HTTP applications and to make it easy to implement them even without much help from the HTTP stack (though it is best to integrate authentication into the stack, of course). Another goal is to make it easy to reuse existing authentication mechanisms by allowing the user (that is, the server's operators) to choose what concrete authentication mechanism(s) to use. Among other benefits of RESTauth: it is orthogonal to "HTTP routers" and proxies, it results in session Uniform Resource Identifiers (URIs) that can be DELETEd to logout, naturally supports multi-legged authentication schemes, naturally supports clustering, and can be universally implemented on the server side with such server<->application interfaces as the Common Gateway Interface (CGI) and FastCGI, among others. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-rest-auth There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-httpauth-rest-auth-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-httpauth-rest-auth-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nico@cryptonector.com Wed Aug 14 17:26:21 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07A0811E80F9 for ; Wed, 14 Aug 2013 17:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lis7GW7IMeLa for ; Wed, 14 Aug 2013 17:26:16 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id B8F3A21F91B7 for ; Wed, 14 Aug 2013 17:26:16 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id 63922598056 for ; Wed, 14 Aug 2013 17:26:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:content-type; s= cryptonector.com; bh=SmXDEAuwiT4xkA1H/8L0hOnUtGI=; b=tMCHQU6cQLm FBZQ+1t7dPXxrjigVs0s2icgshQaXZy37aHPN0XMHO2/gFlZ5sY0PmgLnKASlwVF Zgm8xyx2MCAeiWFYlNuwgMsq2pnCupp5pwYhWPaZJLk4L34ZAYc32zr4sU7F6/lL 8mkXLiN2LPKYg5euGZLMkrX+dicbxXYE= Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPSA id 08938598055 for ; Wed, 14 Aug 2013 17:26:15 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id x12so101567wgg.12 for ; Wed, 14 Aug 2013 17:26:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=HeNUsGwWwmZbrjulAQiN6DQsY+iGIgAhJqiURBziqL0=; b=PoD8exkZTFANu5qKyDMyCyD9eYj1PjH6BhMP9EjhyeZsP9YW4yRbOmsbdAf0fyX2se cr82B1DARc/Iwu9zXIXUu8g83gA/jP0GB4CsZBhLx4WtEC5In02wojcQeIw2b8ZfeYMu OTaPcCCe6tfTmAocjlpqiPqWuXfYZlwoLgs+lGbrPOaYOcOpn1Wx6oPZeSHTkU7v40uS xUmswCLfgQJNuIpdYzzB8JHRGktG1obhnsSCoukQDII9KOoIsNgkWeUc8K1yREOc4PHf h6toivN1i09v8XoJkHBjOK4QhV6DD04ZjayH+r8/Y6QsdcxTNsgsY8jxELosSply4U85 WnYA== MIME-Version: 1.0 X-Received: by 10.180.198.79 with SMTP id ja15mr145341wic.36.1376526374400; Wed, 14 Aug 2013 17:26:14 -0700 (PDT) Received: by 10.216.31.193 with HTTP; Wed, 14 Aug 2013 17:26:14 -0700 (PDT) Date: Wed, 14 Aug 2013 19:26:14 -0500 Message-ID: From: Nico Williams To: "http-auth@ietf.org" Content-Type: text/plain; charset=UTF-8 Subject: [http-auth] New of RESTauth: draft-ietf-httpauth-rest-auth-01.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 00:26:21 -0000 I've updated the I-D. Below are the URLs from the new I-D announcement. I've re-worked the introduction, added a section on motivation, re-worked and moved the section on alternatives, and made other less notable changes. I think that the sections on motivation and alternatives should be of particular interest to reviewers and authors of other proposals. Comments will be most welcomed. URL: http://www.ietf.org/internet-drafts/draft-ietf-httpauth-rest-auth-01.txt Status: http://datatracker.ietf.org/doc/draft-ietf-httpauth-rest-auth Htmlized: http://tools.ietf.org/html/draft-ietf-httpauth-rest-auth-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-rest-auth-01 From mlepinski.ietf@gmail.com Wed Aug 21 12:22:33 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BBEE21F9B91 for ; Wed, 21 Aug 2013 12:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jAzb8cbC5N0s for ; Wed, 21 Aug 2013 12:22:31 -0700 (PDT) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id BE1DC21F9B85 for ; Wed, 21 Aug 2013 12:22:26 -0700 (PDT) Received: by mail-qc0-f181.google.com with SMTP id k15so473678qcv.26 for ; Wed, 21 Aug 2013 12:22:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=l41QKkxY6/MQqirEA9jlNRyRZq/z37DOYzoccGzFGn0=; b=m7/6w5LaeDDdI9yRIVpbhcxxyHlkLrfuQpoRVnV8JnESIsnWoEqk28u6dWvqFbpEu6 aJ1RKwajN/yz4fcPgEZQgQefyMX225UzW3wjQwni/FdXxnDo0lGdwKV275Yz588srNl9 DM0vcWjWdwKd+FfrBlxkzpLLmxus0OY24RwK48+k4X1nHhFJGenZWxVuqiCyNTPHsZYq a23vHigx5ZAfiQkSHXw8xBbhw6XI2ZF5QdaBLDkTP/yluhK4CGsspcr8diMciNvQBXgA fcSOWTZa/l2oa2b9SaDQGVaprAUbm48cgwT0aV8bi/sCdkrYRxyDE14s0IME9BWj+qhC 0ajw== MIME-Version: 1.0 X-Received: by 10.229.49.8 with SMTP id t8mr594683qcf.21.1377112946162; Wed, 21 Aug 2013 12:22:26 -0700 (PDT) Received: by 10.49.42.66 with HTTP; Wed, 21 Aug 2013 12:22:26 -0700 (PDT) Date: Wed, 21 Aug 2013 15:22:26 -0400 Message-ID: From: Matthew Lepinski To: http-auth@ietf.org Content-Type: multipart/alternative; boundary=001a1133b592f8c28d04e47a177f Subject: [http-auth] Draft Minutes Posted for IETF 87 HTTP-AUTH Session X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 19:22:33 -0000 --001a1133b592f8c28d04e47a177f Content-Type: text/plain; charset=ISO-8859-1 Draft minutes for the HTTP-AUTH session have been posted. They can be found at: http://www.ietf.org/proceedings/87/minutes/minutes-87-httpauth If you notice any omissions or other errors in the minutes, please let us know. Thanks, - Yoav and Matt --001a1133b592f8c28d04e47a177f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Draft minutes for the HTTP-AUTH session have been posted.<= div>
They can be found at:=A0http://www.ietf.org/proceedings/= 87/minutes/minutes-87-httpauth

If you notice any omissions or other errors in the minu= tes, please let us know.

Thanks,
- Yoav = and Matt
--001a1133b592f8c28d04e47a177f-- From ynir@checkpoint.com Thu Aug 22 00:37:49 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF6621F8CDD for ; Thu, 22 Aug 2013 00:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.703 X-Spam-Level: X-Spam-Status: No, score=-10.703 tagged_above=-999 required=5 tests=[AWL=-0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7A+GdkNVQuI for ; Thu, 22 Aug 2013 00:37:39 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 76A2721F8C9D for ; Thu, 22 Aug 2013 00:37:38 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r7M7baqM008757 for ; Thu, 22 Aug 2013 10:37:36 +0300 X-CheckPoint: {5215BFC0-2-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.105]) by DAG-EX10.ad.checkpoint.com ([169.254.3.223]) with mapi id 14.02.0342.003; Thu, 22 Aug 2013 10:37:36 +0300 From: Yoav Nir To: "http-auth@ietf.org" Thread-Topic: Ticket #1 - Determine Algorithm Agility in digest-update Thread-Index: AQHOnwp4FLJXruoPn02J91L0R9CbcQ== Date: Thu, 22 Aug 2013 07:37:35 +0000 Message-ID: <1EA692D1-FF7B-405A-87E7-AA316D643055@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.76] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 1143883cadeeb44c0a2611fe66f4fe56e38f079024 Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [http-auth] Ticket #1 - Determine Algorithm Agility in digest-update X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 07:37:49 -0000 Hi Ticket #1 ( http://trac.tools.ietf.org/wg/httpauth/trac/ticket/1 ) covers t= he question of algorithm agility in digest-update. The current draft has SHA-256 as the primary algorithm, SHA-512/256 as the = secondary algorithm, and MD5 for BC. There is text that instructs the UA to ignore unrecognized algorithms, and = move on to similar headers with recognized algorithms, and also to choose t= he most preferred algorithm, so future compatibility (the ability to add ne= w algorithms later) is (I think) addressed. There were concerns that SHA-512/256 is not widely implemented, but Tony Ha= nsen said (in Berlin) that he's working on updating RFC 6234 to add this. A= n implementer (me!) said at the meeting that adding SHA-512/256 to a code-b= ase that already had SHA-512 was trivial. Given all that, can we close this ticket as solved, or are there still obje= ctions to the algorithm agility text? Thanks Yoav From rifaat.ietf@gmail.com Tue Aug 27 06:16:19 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 421F911E833A for ; Tue, 27 Aug 2013 06:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wn+VbVDpKDqi for ; Tue, 27 Aug 2013 06:16:18 -0700 (PDT) Received: from mail-qe0-x22d.google.com (mail-qe0-x22d.google.com [IPv6:2607:f8b0:400d:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 98CAE11E8338 for ; Tue, 27 Aug 2013 06:16:18 -0700 (PDT) Received: by mail-qe0-f45.google.com with SMTP id 8so1864275qea.32 for ; Tue, 27 Aug 2013 06:16:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=n8jH/WMj6zzIdMq/lp0NA/1rGICbwEJWdrlgNdyC8uw=; b=fthwGiJCbcYI5Bd/uq8qN/P3XsSg9XiaXUuE9ZkSDAzMpBhEwPNuQUOZ4eT2iuBTK6 e3NzMvJOIPgZfU4WpvQwlf2jnKOybhdcdcsOyf2bcGYwkCoyLmaPPcJduEzSuuZJz3nK g37g3w+mjVJOSOzOzLzl6JWJWR6N+KFSPJgfC0GqxD6BlBVSbhak1PbqvcnO3YZQyEYU aQMgjC3k8MKopTNXe+0YFz5RA5UsJuA7tXf58jXU4/MNi29aWwPw0CpHEujMAQY2lNBN t1fIAFSgLW6ro5JXUnsybVyB/VtMikJ254UOp5mHI7apuTiP7EOlhnJ/QUGHDwe+EQ1z sQSA== MIME-Version: 1.0 X-Received: by 10.224.76.71 with SMTP id b7mr22881011qak.48.1377609377958; Tue, 27 Aug 2013 06:16:17 -0700 (PDT) Received: by 10.49.19.73 with HTTP; Tue, 27 Aug 2013 06:16:17 -0700 (PDT) In-Reply-To: <1EA692D1-FF7B-405A-87E7-AA316D643055@checkpoint.com> References: <1EA692D1-FF7B-405A-87E7-AA316D643055@checkpoint.com> Date: Tue, 27 Aug 2013 09:16:17 -0400 Message-ID: From: Rifaat Shekh-Yusef To: Yoav Nir Content-Type: multipart/alternative; boundary=001a11c2fd229cd0d004e4edad7d Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Ticket #1 - Determine Algorithm Agility in digest-update X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 13:16:19 -0000 --001a11c2fd229cd0d004e4edad7d Content-Type: text/plain; charset=ISO-8859-1 Yeah, based on the meeting in Berlin, I think it makes sense to close this ticket. Regards, Rifaat On Thu, Aug 22, 2013 at 3:37 AM, Yoav Nir wrote: > Hi > > Ticket #1 ( http://trac.tools.ietf.org/wg/httpauth/trac/ticket/1 ) covers > the question of algorithm agility in digest-update. > > The current draft has SHA-256 as the primary algorithm, SHA-512/256 as the > secondary algorithm, and MD5 for BC. > There is text that instructs the UA to ignore unrecognized algorithms, and > move on to similar headers with recognized algorithms, and also to choose > the most preferred algorithm, so future compatibility (the ability to add > new algorithms later) is (I think) addressed. > > There were concerns that SHA-512/256 is not widely implemented, but Tony > Hansen said (in Berlin) that he's working on updating RFC 6234 to add this. > An implementer (me!) said at the meeting that adding SHA-512/256 to a > code-base that already had SHA-512 was trivial. > > Given all that, can we close this ticket as solved, or are there still > objections to the algorithm agility text? > > Thanks > > Yoav > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > --001a11c2fd229cd0d004e4edad7d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Yeah, based on the meeting in Berlin, I think it makes sen= se to close this ticket.

Regards,
=A0Rifaat


On Thu, Aug 22, 2013 at 3:37 AM, Yoav Nir <ynir@checkpoint.com> wrote:
Hi

Ticket #1 ( http://trac.tools.ietf.org/wg/httpauth/trac/ticket/1 ) covers the question of algorithm agility in digest-update.

The current draft has SHA-256 as the primary algorithm, SHA-512/256 as the = secondary algorithm, and MD5 for BC.
There is text that instructs the UA to ignore unrecognized algorithms, and = move on to similar headers with recognized algorithms, and also to choose t= he most preferred algorithm, so future compatibility (the ability to add ne= w algorithms later) is (I think) addressed.

There were concerns that SHA-512/256 is not widely implemented, but Tony Ha= nsen said (in Berlin) that he's working on updating RFC 6234 to add thi= s. An implementer (me!) said at the meeting that adding SHA-512/256 to a co= de-base that already had SHA-512 was trivial.

Given all that, can we close this ticket as solved, or are there still obje= ctions to the algorithm agility text?

Thanks

Yoav

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

--001a11c2fd229cd0d004e4edad7d-- From ynir@checkpoint.com Wed Aug 28 01:37:00 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBB9A11E821D for ; Wed, 28 Aug 2013 01:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.645 X-Spam-Level: X-Spam-Status: No, score=-10.645 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xnvT+iNHAi93 for ; Wed, 28 Aug 2013 01:36:55 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB5911E816B for ; Wed, 28 Aug 2013 01:36:54 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r7S8ahSD022018 for ; Wed, 28 Aug 2013 11:36:44 +0300 X-CheckPoint: {521DB69B-31-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.173]) by IL-EX10.ad.checkpoint.com ([169.254.2.246]) with mapi id 14.02.0347.000; Wed, 28 Aug 2013 11:36:43 +0300 From: Yoav Nir To: "http-auth@ietf.org" Thread-Topic: Proposed Virtual Interim Meeting about MutualAuth Thread-Index: AQHOo8m51zKHalW+d0uXNI1GaQHCkg== Date: Wed, 28 Aug 2013 08:36:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.167] x-kse-antivirus-interceptor-info: protection disabled Content-Type: text/plain; charset="us-ascii" Content-ID: <26E1A1EA93CC9140A35C0422776DE637@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [http-auth] Proposed Virtual Interim Meeting about MutualAuth X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 08:37:00 -0000 Hi all Of all the experimental proposals, MutualAuth has been around for the longe= st time. There is running code ([1],[2]) and documentation for years. While= it is not deployed in either commercial products or popular open source pr= ojects, this is the best that we can hope for in terms of maturity for the = documents that this group is working on. With that in mind, we would like the reviews of the MutualAuth proposal to = begin now. Those who committed to review this, please send your comments to= the list within the next few weeks, and others are welcome to do so as wel= l. We would also like to hold a virtual interim meeting early October. Time of= day is difficult, because we truly are an international group. 8:00 AM in = California is OK for Europe but is midnight in Japan. That (1500 UTC) still= looks to me like the least combined pain proposal. If others feel differen= tly, please let me know. For date, I'm thinking Tuesday, October 8th.=20 If this conflicts with someone who wants to participate, please let Matt an= d I know soon, because interim meetings (even virtual ones) have to be anno= unced a month in advnace.=20 Also, if you plan to attend, please let us know. We are talking about a vir= tual interim meeting, so the technology is probably going to be a PSTN conf= erence call. Details will be sent later on. Thanks, Matt & Yoav From ynir@checkpoint.com Wed Aug 28 02:05:55 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2CE611E8170 for ; Wed, 28 Aug 2013 02:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.644 X-Spam-Level: X-Spam-Status: No, score=-10.644 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jva4eLRXOuzF for ; Wed, 28 Aug 2013 02:05:49 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5D611E8151 for ; Wed, 28 Aug 2013 02:05:45 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r7S95j0C001005 for ; Wed, 28 Aug 2013 12:05:45 +0300 X-CheckPoint: {521DBD68-B-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.173]) by IL-EX10.ad.checkpoint.com ([169.254.2.246]) with mapi id 14.02.0347.000; Wed, 28 Aug 2013 12:05:44 +0300 From: Yoav Nir To: "http-auth@ietf.org" Thread-Topic: Evaluation Criteria for the experimental drafts Thread-Index: AQHOo83HdDRnwscz00KWgOhds49acQ== Date: Wed, 28 Aug 2013 09:05:44 +0000 Message-ID: <275442B3-7A7C-4A21-90B7-C97A125D788B@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.167] x-kse-antivirus-interceptor-info: protection disabled Content-Type: text/plain; charset="us-ascii" Content-ID: <753C78A05D35F1498D8ACAEEAA8C84E1@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [http-auth] Evaluation Criteria for the experimental drafts X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 09:05:55 -0000 Hi As we talked in Berlin, the following is not a checklist. It is meant only = as guidance. Comments that are not covered by these guidelines are very wel= come.=20 Security: - No vulnerabilities that we should find - Assumptions, limitations should be stated up front, not left to securi= ty considerations For example, a method that requires secure storage of password equival= ents should state this up front. Clarity: - Can a reasonably competent developer implement this after reading this= document. Requirements and Assumptions about the operating environment: - It's OK to have them, but they MUST be stated. - Especially look for demands for other network components (such as AAA = servers), hardware tokens, UI elements Performance: - Shouldn't be a problem. Yoav From ilari.liusvaara@elisanet.fi Thu Aug 29 09:43:09 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8DD11E8136 for ; Thu, 29 Aug 2013 09:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.561 X-Spam-Level: X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=-3.962, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KA3ZlMYzElqA for ; Thu, 29 Aug 2013 09:43:03 -0700 (PDT) Received: from emh07.mail.saunalahti.fi (emh07.mail.saunalahti.fi [62.142.5.117]) by ietfa.amsl.com (Postfix) with ESMTP id 3117F11E8128 for ; Thu, 29 Aug 2013 09:43:01 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id F11C24143 for ; Thu, 29 Aug 2013 19:42:59 +0300 (EEST) Date: Thu, 29 Aug 2013 19:42:59 +0300 From: Ilari Liusvaara To: "http-auth@ietf.org" Message-ID: <20130829164259.GA13460@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Ilari Liusvaara Subject: [http-auth] Review of MutalAuth X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 16:43:09 -0000 Main mutualauth spec: > implementations for user authentication using HTML Forms and Web > browser rendering engines. However, that method has many potential > security weaknesses as same as the HTTP Basic authentication as it > uses plaintext. Considering server-impersonations and existence of I can't parse this... I can see it asserts that there is substantial overlap of vulernabilties between forms and HTTP Basic (true). But, does it assert one has all the vulernabilies of the other (superset), the same vulernabilties (equivalence) or just substantial overlap? > still relying on the HTTPS for the integrity and secrecy of the HTTP > payload. This protocol ensures users the integrity and secrecy of Perhaps s/secrecy/confidentiality/g ? > All character strings outside ASCII character sets MUST be encoded > using the UTF-8 encoding [RFC3629] for the ISO 10646-1 character set > [ISO.10646-1.1993], without any leading BOM characters. Both peers Why mention of ASCII? It is strict subset of UTF-8 anyway. > base64-fixed-number = 1*( ALPHA / DIGIT / > "-" / "." / "_" / "~" / "+" / "/" ) *"=" Err, mixing multiple Base64 variants? And what are "~" and "." (couldn't find in linked RFC)? > o For requests, the parameters "kc*" (where * stands for any decimal > integers), and "vks" are mutually exclusive and any challenge > MUST NOT contain two or more parameters among them. They MUST NOT > contain any "ks*" and "vks" parameters. The first "vks" is supposed to be "vkc"? > version: (mandatory extensive-token) should be the token "-wg- > draft00" in this specification. The behavior is > undefined when other values are specified. Add some note for RFC editor to replace the value (for the final RFC)? > auth-domain: (non-mandatory string) specifies the authentication > domain, the set of hosts for which the authentication > credentials are valid. It MUST be one of the strings > described in Section 5. If the value is omitted, it > is assumed to be the "single-port" type domain in > Section 5. There is no "single-port" type in section 5. You mean single-server type? > pwd-hash: (non-mandatory extensive-token) specifies the hash > algorithm (hereafter referred to by ph) used for > additionally hashing the password. The valid tokens > are > > * none: ph(p) = p > > * md5: ph(p) = MD5(p) > > * digest-md5: ph(p) = MD5(username | ":" | realm | > ":" | p), the same value as MD5(A1) for "MD5" > algorithm in [RFC2617]. > > * sha1: ph(p) = SHA1(p) None produces a octet string, whereas others produce integers. Perhaps add some OCTETS() into right places. > In the above specifications, every "scheme", "host", and "domain" > MUST be in lower-case, and any internationalized domain names beyond > the ASCII character set SHALL be represented in the way they are sent > in the underlying HTTP protocol, represented in lower-case > characters; i.e. these SHALL be in the form of the LDH labels in IDNA > [RFC5890]. All "port"s MUST be in the shortest, unsigned, decimal > number notation. Not obeying these requirements will cause failure > of valid authentication attempts. What about when dealing with DNS-SD? That uses native UTF-8 on the wire instead of Punycode. I have no idea how HTTP host names are represented in that case. > tls-key: TLS shared-key validation: The value v will be the > octet string of the shared master secret negotiated in > the underlying TLS (or SSL) connection. Any reason to deviate from tls-unique of RFC 5929 (Standards Track), which uses latest finished message instead? > pi = H(VS(algorithm) | VS(auth-domain) | VS(realm) | VS(username) | > VS(ph(password))). VS(ph(password))) is ill-defined if pwd-hash is not none, as it then tries to apply VS to an integer. > existing sessions regardless of these statuses. One way to mitigate > such attacks are that servers MAY have a number and a time limits for > unverified pending key exchange requests (in the "wa received" > status). "wa received"??? Auth extension: > The value of this parameter MUST be a string that contains an > absolute URL location. If a given URL is not absolute, the clients > MAY consider it a relative URL from the current location. Err... X MUST be Y, but if X is not Y... > When the user requests to terminate an authentication period, if the > client supports this parameter but the server response does not > contain this parameter, the client's RECOMMENDED behavior is as > follows: if the request corresponding to the current content was > idempotent (e.g. GET), reload the page without the authentication > credential. If the request was non-idempotent (e.g. POST), keep the > current content as-is and simply forget the authentication status. > The client SHOULD NOT replay a non-idempotent request without the > user's explicit approval. Should it replay PUT or DELETE (or LINK/UNLINK)? Those methods are idempotent. > 7. IANA Considerations Optional-WWW-Authenticate registration? Mutualauth algo: Is there a security analysis of (this version of) KAM3? In practicular, considering various mathematical attacks and establishing a lower bound on difficulty (e.g. Attack X is at least as hard as CDH on the group and so on)? -Ilari