From nico@cryptonector.com Fri May 3 12:51:04 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAC6321F9079 for ; Fri, 3 May 2013 12:51:04 -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 57lsc185b1qe for ; Fri, 3 May 2013 12:50:59 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id CB87A21F85C3 for ; Fri, 3 May 2013 12:50:56 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id 991C521DE57 for ; Fri, 3 May 2013 12:50:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=9shkvZxSuxeSr7OZnABN Yp89tAA=; b=Y+x9f+SWlnYEWUAbsjkvcsauYUQM10A4/ckAReyA3DYJWviDX9iY xfYsCQwn3nzz/OF0/xrL+N9Bg/Jh0vTCfrZDvneGbprpbJJNl4VdGhwRZWEpoMdQ bP1IxbGnXl/EM1pADKI7RPFO6jGWtEtcuYN9q8jfsDMD9uuL+VvmXZY= 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-a30.g.dreamhost.com (Postfix) with ESMTPSA id 3B27C21DE56 for ; Fri, 3 May 2013 12:50:56 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id l18so1966601wgh.12 for ; Fri, 03 May 2013 12:50:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=SptOwrZ+qW7fwPtPfcmpDgH/QqV9DoB18j/+N2leVPo=; b=ZXhy+7er4dbfBBZTQanCwix3pe+Ru9XO/hAW5xQTPm4BhvID+l8zGD7OlarN8u6kbi GerLHEOJUQ3LS6mWKSk38jgTpID84CCFlH6iutnvhokAAdxexLq7ABK3TiH6c5xNNFo4 zYTKyeiMmxR/VlxTw/1CpXKQqyEfCDIaFm21XywgGspDNYHyRUwXSZj2OVnVpJYZE10M yZ9qMXG2453CkO8WQK+1mguVvz65BsYe8Z4s9elGxTzNDPaLEinIDFeNLaPCbu89DOPB QRe+qJfZ+FSYjpeoSLodvCiOsjK2bbIJLOrccQzHYU2Dn/OEZC8fZGci80jot263AvzT iyVw== MIME-Version: 1.0 X-Received: by 10.194.71.103 with SMTP id t7mr15890110wju.38.1367610655035; Fri, 03 May 2013 12:50:55 -0700 (PDT) Received: by 10.216.111.132 with HTTP; Fri, 3 May 2013 12:50:54 -0700 (PDT) In-Reply-To: <6B6B39DB-CC09-419C-9089-1CCEBB0F8B7D@checkpoint.com> References: <6B6B39DB-CC09-419C-9089-1CCEBB0F8B7D@checkpoint.com> Date: Fri, 3 May 2013 14:50:54 -0500 Message-ID: From: Nico Williams To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Reminder: Looking for reviewers X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 19:51:04 -0000 On Tue, Apr 30, 2013 at 2:21 AM, Yoav Nir wrote: > Hi Folks. > > On Apris 10th, we issued a call for acceptance for several drafts. One has since been withdrawn. The remaining ones are (in no particular order): > - draft-williams-http-rest-auth > - draft-farrell-httpbis-hoba > - draft-oiwa-http-mutualauth and draft-oiwa-http-auth-extension > - draft-melnikov-httpbis-scram-auth I'll review draft-melnikov-... and, possibly, draft-oiwa-... Starting now. Nico -- From ynir@checkpoint.com Fri May 3 13:36: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 B984421F91BC for ; Fri, 3 May 2013 13:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVqlBGfqEVEp for ; Fri, 3 May 2013 13:36:03 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 4C5E721F8D28 for ; Fri, 3 May 2013 13:36:03 -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 r43KZrW4030695; Fri, 3 May 2013 23:35:53 +0300 X-CheckPoint: {51841E4E-3-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Fri, 3 May 2013 23:35:54 +0300 From: Yoav Nir To: Nico Williams Thread-Topic: [http-auth] Reminder: Looking for reviewers Thread-Index: AQHORXNQnNg5usCGsUWkSSJrNCEOY5jzsdkAgAAMj4A= Date: Fri, 3 May 2013 20:35:52 +0000 Message-ID: <0111B1CC-51B7-499A-9385-0B69E60F4321@checkpoint.com> References: <6B6B39DB-CC09-419C-9089-1CCEBB0F8B7D@checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.204] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 118647030fe7dde954dfedd87e4af37c51e99ebd48 Content-Type: text/plain; charset="us-ascii" Content-ID: <452E9B5A74F3E14DA2260AF9C663FEE1@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Reminder: Looking for reviewers X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 20:36:09 -0000 Thanks! On May 3, 2013, at 10:50 PM, Nico Williams wrote: > On Tue, Apr 30, 2013 at 2:21 AM, Yoav Nir wrote: >> Hi Folks. >>=20 >> On Apris 10th, we issued a call for acceptance for several drafts. One h= as since been withdrawn. The remaining ones are (in no particular order): >> - draft-williams-http-rest-auth >> - draft-farrell-httpbis-hoba >> - draft-oiwa-http-mutualauth and draft-oiwa-http-auth-extension >> - draft-melnikov-httpbis-scram-auth >=20 > I'll review draft-melnikov-... and, possibly, draft-oiwa-... Starting no= w. >=20 > Nico > -- From nico@cryptonector.com Fri May 3 17:34:46 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 61BF121F8F43 for ; Fri, 3 May 2013 17:34:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.802 X-Spam-Level: X-Spam-Status: No, score=-1.802 tagged_above=-999 required=5 tests=[AWL=0.175, 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 p0s0KG-QE31X for ; Fri, 3 May 2013 17:34:41 -0700 (PDT) Received: from homiemail-a65.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 7127D21F8F3C for ; Fri, 3 May 2013 17:34:41 -0700 (PDT) Received: from homiemail-a65.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTP id 2BFE07E4065 for ; Fri, 3 May 2013 17:34:41 -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=QoSSSuvRkf9Fps+NRi29NvseEQc=; b=lvj5/YLLpsq BLJv7U901aRncB4K9lBxRVvSq7l6n9sLTaf6tyvqQOGKuuX0YK68bg3yEe+BfoNp 97DJvRmjsbEOTcMX7pf638ESUexxZ9L6vD8BoIn1E5Zq4NAClKqZ2TNyUcgZ4wg3 CXHQvwK9Ir9dyXhG0l0yCU2/x5uao6Tc= Received: from mail-we0-f176.google.com (mail-we0-f176.google.com [74.125.82.176]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTPSA id CB9E37E4062 for ; Fri, 3 May 2013 17:34:40 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id r6so1673989wey.7 for ; Fri, 03 May 2013 17:34:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=YX/yMMGLwvFZ40Bn0541P6gnphzXvyyfYSvHnCAZJAs=; b=bcE+CaPpfN4LAcNmbPew6RPXsO1rrmqJ36Kk5ldc47L4vYlScxiufTXjH2jfLoZoj4 wM5Pd47mVzlvojGF0vP8aEGAxpNpwJRDd16eJHOTaHFuFBJMzZHOpOaG+4zFMttW7avo OkdTE5ShlWa7k5VYbyZbnkSI9s/QkuDE5teLNCGH/cRKHJc72957BJ3DEw7d0Vf8wTs6 AIISDrDgE5zx0WT+TfR4TWMEHyOE2va9PLg5PQdzBLik4R9FxLdm8qtuiVdl8sxTrImc J/bx186H4WJqsuBHcLMgZGMsTtatEll67OLS4nJ+rwMhVT5m8zO/BpPO6vLZ2N8Px7wF YxRw== MIME-Version: 1.0 X-Received: by 10.180.183.139 with SMTP id em11mr351899wic.16.1367627679441; Fri, 03 May 2013 17:34:39 -0700 (PDT) Received: by 10.216.111.132 with HTTP; Fri, 3 May 2013 17:34:39 -0700 (PDT) Date: Fri, 3 May 2013 19:34:39 -0500 Message-ID: From: Nico Williams To: http-auth@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [http-auth] Review of draft-melnikov-httpbis-scram-auth-00 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: Sat, 04 May 2013 00:34:46 -0000 First, my level-zero comments: - As most of you know by now, I think HTTP-layer authentication is a bit of a dead end. Consider Mozilla's BrowserID: an application-layer authentication mechanism (i.e., authentication messages are POSTed). But there is room for SCRAM here: in -to borrow a term from Kerberos- pre-authentication of the user to the user's IdP. This comment applies to all proposals for authentication mechanisms that fit into the existing HTTP authentication framework. Next: - This SCRAM is not *the* SCRAM of RFC5802. Perhaps it should have a different name to distinguish the two. In particular this SCRAM a) adds various attributes such as "realm" and "sid" parameters, and b) doesn't make use of the "-PLUS" suffix per-RFCs 5801 and 5802. Nor does this mechanism add the use of the SASL framework to HTTP -- it's just an adaptation of RFC5802, not 5801. A list of all the differences between this mechanism and RFC5802 would be nice. Is the authentication database for one usable with the other? See comments about the realm attribute below. - What's to be done with the "realm" attribute? Should it be added to the salt? Or merely be used to route a SCRAM exchange to an IdP, or to find the requisite authentication database? - What's the purpose of the "sid" attribute? What can be done with it? - Why shouldn't the client name the desired server in its messages? Then the exchange could be proxied to the named realm which could authenticate the server doing the proxying. That'd be nice. No, I think it'd have to be *required* if you want to have a realm for federation purposes. - "pre-stored dictionary attack" is not how I'd phrase it. More like "pre-computation attack""using "rainbow tables"-- "a dictionary of pre-computed hash results for a given one-way function and input passwords". - Please remove the reference to "Registration of TLS server end-point channel bindings"; RFC5929 should suffice. - A channel binding type should be required to be supported by clients and servers, and it should be tls-server-end-point. - The security considerations section should mention the lack of privacy protection for the client ID when not using TLS. - Section 7, third paragraph: no, no password-based authentication mechanism protects against off-line dictionary attacks on stolen password verifiers, not even ZKPPs. I recommend striking this sentence. - Section 7, fourth paragraph: how does salting help here? Oh, by ensuring that if the user uses the same password on multiple sites/servers/realms then the verifiers will be different. - Section 7, 5th paragraph: how would one negotiate hashes in a situation in which two SCRAM flavors are available, but both aren't available for all users (because, e.g., the not all users have re-enrolled). - Section 7, 6th paragraph, can you describe channel binding type negotiation? I thought there was none. I'll save nits for some other time. Nico -- From nico@cryptonector.com Sat May 4 00:52:45 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4089621F9389 for ; Sat, 4 May 2013 00:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.577 X-Spam-Level: X-Spam-Status: No, score=-1.577 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 OsKHQ6EzKVNo for ; Sat, 4 May 2013 00:52:40 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC2A21F91F1 for ; Sat, 4 May 2013 00:52:40 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id AB0AB67C06B for ; Sat, 4 May 2013 00:52:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=yz+zfTT+SVUe2AI9o+hb e0FW+XA=; b=CMaKd9Q0MMucoEFUdIa4HttcEQ8Arc08ircTTckPKi1NOUHewTrQ BT4NcqEfRgIZllqGODfrN+Nj+lBeM59Io6FjxCWQ2nhdB9rW3HyCI/SxnM6cmkX1 KC/v9VMOC1vOL/IoTndsSIyzgcpC8b1zFsb+Huxd99oKvFBhS2A/8bY= Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPSA id 5F1E167C069 for ; Sat, 4 May 2013 00:52:38 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id h11so1236567wiv.13 for ; Sat, 04 May 2013 00:52:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=h7w4B0gZdRZuHIrvzKmU5bLbq2/bNOc1fKVbkabv/b0=; b=lmFsXEYLdYBjoSL1jS6sjSMgUx6SsAlDNwc86IG1kDO2204kMvbg3t0SxkdOBqagPI BqtB+QW32hhue3/mrmQIBSeyV4wmMoUHd4phgjhzJjYCAaaMQP7radCIQkK7UZrUnQpS BOpmPYtcfNKwqriKqageNxf5G6THUCuRhcMb4pI+0UVZEnTVFg6oj1H5HeOHJcNnUNKb OdeSzsc1BONJlXBG65DE8l7wr41qAbdGbCxwmffVBCwBiWxzvPrX7469HTN1u/1UHGE+ /+OdzanVBJ5PS/fmhNox1hR8vRBy0TCTtjWRPYODb26EsYxkz8/qvBU16UEOXSSkVDNR 0nzw== MIME-Version: 1.0 X-Received: by 10.194.11.70 with SMTP id o6mr17398466wjb.29.1367653956818; Sat, 04 May 2013 00:52:36 -0700 (PDT) Received: by 10.216.111.132 with HTTP; Sat, 4 May 2013 00:52:36 -0700 (PDT) In-Reply-To: References: Date: Sat, 4 May 2013 02:52:36 -0500 Message-ID: From: Nico Williams To: Nico Williams Content-Type: multipart/alternative; boundary=047d7b5d456c459d4f04dbdfc095 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Review of draft-melnikov-httpbis-scram-auth-00 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: Sat, 04 May 2013 07:52:45 -0000 --047d7b5d456c459d4f04dbdfc095 Content-Type: text/plain; charset=UTF-8 Also, as far as proxying authentication, and using the realm parameter for federation: the proxies get material that they can mount off-line dictionary attacks on. This is bad. When we designed SCRAM Sam opposed adding a realm parameter and federation, as I recall, because of the complexity that would have added, as well as this one issue. My recommendation is that the realm, if it remains in the protocol, be used only as a sanity check. For federation I much prefer BrowserID (full disclosure: I'm a co-author of Luke Howard's I-D specifying a BrowserID-based GSS-API mechanism), Keberos, ABFAB, or similar, where the server doesn't get material suitable for off-line dictionary attacks, nor does it get to impersonate the user to other services without permission, and so on. Nico -- --047d7b5d456c459d4f04dbdfc095 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Also, as far as proxying authentication, and using the realm parameter for = federation: the proxies get material that they can mount off-line dictionar= y attacks on. =C2=A0This is bad. =C2=A0When we designed SCRAM Sam opposed a= dding a realm parameter and federation, as I recall, because of the complex= ity that would have added, as well as=C2=A0this one issue. =C2=A0My recomme= ndation is that the realm, if it remains in the protocol, be used only as= =C2=A0a sanity check. =C2=A0For federation I much prefer BrowserID (full di= sclosure: I'm a co-author of Luke Howard's I-D specifying a Browser= ID-based GSS-API mechanism), Keberos, ABFAB, or similar, where the server d= oesn't get material suitable for off-line dictionary attacks, nor does = it get to impersonate the user to other services without permission, and so= on.

Nico
--=C2=A0
--047d7b5d456c459d4f04dbdfc095-- From mlepinski.ietf@gmail.com Mon May 6 21:00: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 D6FD321F938E for ; Mon, 6 May 2013 21:00:06 -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 r-m5ZsrKsqgg for ; Mon, 6 May 2013 21:00:06 -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 64A6021F937E for ; Mon, 6 May 2013 20:59:56 -0700 (PDT) Received: by mail-qc0-f181.google.com with SMTP id s10so69861qcv.26 for ; Mon, 06 May 2013 20:59:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=aKVOiLTHDRStSeXMZ+qNpQbndSuCTcRWyFQl56H1yZQ=; b=AOQIB8BY7p4y4IqwMMvJD51h3YaILquyL0dDiPxNdpto1IrQOOvY2+FrHgJdnYfxIR eu2AqbaVlwH6LSw1GgIyMBYwfzZ5UME7fHf155NWY4D/68Z7vjLeK1JZmd1g6CH9sp9I UE7wOPrNefpZLFSNtUZHfYJily1tzR9Ooj/dyh3RgyyILxkAA5in3abf4rcZEgXXE9KT ED8jeIhp44yO7Y6SALy2CsIiZcUDeMQvjDGm/2rga9rEludGtUe7i+/x2W+ApjTXwUUq kvMIgDzJszhJk/H4u8eFmlyjyMiL5JtlG0UbqxfhONTWj+IU1bDkXYMV/Ddtxtjk3Jda 6u3w== MIME-Version: 1.0 X-Received: by 10.224.188.134 with SMTP id da6mr473602qab.69.1367899195317; Mon, 06 May 2013 20:59:55 -0700 (PDT) Received: by 10.49.130.8 with HTTP; Mon, 6 May 2013 20:59:55 -0700 (PDT) Date: Mon, 6 May 2013 23:59:55 -0400 Message-ID: From: Matthew Lepinski To: http-auth@ietf.org Content-Type: multipart/alternative; boundary=20cf3033464fa057ce04dc18d9dd Subject: [http-auth] Working Group Acceptance of 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: Tue, 07 May 2013 04:00:07 -0000 --20cf3033464fa057ce04dc18d9dd Content-Type: text/plain; charset=ISO-8859-1 Thanks to everyone who volunteered to do a review of a potential working group document. I am pleased to announce that we were able to obtain an acceptable number of reviewers for each of the drafts. Therefore, the following documents will be accepted as HTTP-AUTH working group drafts: draft-williams-http-rest-auth draft-farrell-httpbis-hoba draft-melnikov-httpbis-scram-auth draft-oiwa-http-mutualauth and draft-oiwa-http-auth-extension The authors of each of these documents should submit a new version as draft-ietf-httpauth-whatever-00. Thanks again to everyone who volunteered to review one of these documents. Please be sure to send your reviews to the HTTP-AUTH mailing list. Of course, everyone on this list encourage to review the new working group documents regardless of whether or not you volunteered in advance to do a review. Thanks Matt & Yoav --20cf3033464fa057ce04dc18d9dd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks to everyone who volunteered to do a review of a pot= ential working group document. I am pleased to announce that we were able t= o obtain an acceptable number of reviewers for each of the drafts. Therefor= e, the following documents will be accepted as HTTP-AUTH working group draf= ts:

draft-williams-http-rest-auth
draft-f= arrell-httpbis-hoba
draft-melnikov-httpbis-scram-auth
draft-oiwa-http-mutualauth and draft-oiwa-http-auth-exte= nsion

The authors of each of these documents should submit a new=A0version= =A0as=A0draft-ietf-httpauth-whatever-00.

Th= anks again to everyone who volunteered to review one of these documents. Pl= ease be sure to send your reviews to the HTTP-AUTH mailing list. Of course,= everyone on this list encourage to review the new working group documents = regardless of whether or not you volunteered in advance to do a review.=A0<= /font>

Thanks

Matt & Yoav

--20cf3033464fa057ce04dc18d9dd-- From y.oiwa@aist.go.jp Wed May 8 23:16:34 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 D69F421F8C40 for ; Wed, 8 May 2013 23:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBPCDQJUPfov for ; Wed, 8 May 2013 23:16:30 -0700 (PDT) Received: from na3sys010aog113.obsmtp.com (na3sys010aog113.obsmtp.com [74.125.245.94]) by ietfa.amsl.com (Postfix) with ESMTP id 655B521F8B9C for ; Wed, 8 May 2013 23:16:30 -0700 (PDT) Received: from mail-ob0-f180.google.com ([209.85.214.180]) (using TLSv1) by na3sys010aob113.postini.com ([74.125.244.12]) with SMTP ID DSNKUYs/PQ6uvbBPlKjoUtt6RFIhuadWtw7p@postini.com; Wed, 08 May 2013 23:16:30 PDT Received: by mail-ob0-f180.google.com with SMTP id xk17so425369obc.11 for ; Wed, 08 May 2013 23:16:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=F+uECwk16qX3Qe80bslwhIDhUIJwsrsaYT/ARHVMR0k=; b=MLKtkB/nQ9HhylTilVlA3fn4JfkrQPbI4f6y6sFI9gicrGLRKTyX1fsCZUbvPsSplT mfporkecUZwidDKi5PjsmJkwPCKLkYTEL68oHUK+Rvge0U0xcT3Fg5PDotimvduzEZ6w nEpE5mBGuYaZnYznULM0xYqzccPT4ncqgUmPU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=F+uECwk16qX3Qe80bslwhIDhUIJwsrsaYT/ARHVMR0k=; b=NGBXyQBYZCrLOWijX/uoMVESj1sh9LXQNHfQFehZk7GCRV0sOzmbaqGE2SKD0owl3o 3GbADZ4g59kmoeip9ai1sJTMj4kFUSMzrZS942Za2wGB+K+NQRHlopXCDM7lm2i6EkQ/ FgkqHECRzad9YKmoni0onezyYIpIQSQgjcQQM8mPsizxHLysMRQcqXuzcRfdIte5bWdb p5minKdusL3U698Xu4G9LVdvIb4DWfgvPCLl9spvAg7o43Z9UTIor2LHBPDY7sfVdvyO lwJGA9tZ+PQCteYaiSuLi8CkiWPego7iDytf1FE2q8KI+46OC7poA40tgFqgrpaAtiXv XN1A== X-Received: by 10.182.56.169 with SMTP id b9mr763528obq.42.1368080189386; Wed, 08 May 2013 23:16:29 -0700 (PDT) X-Received: by 10.182.56.169 with SMTP id b9mr763527obq.42.1368080189317; Wed, 08 May 2013 23:16:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.23.132 with HTTP; Wed, 8 May 2013 23:16:09 -0700 (PDT) In-Reply-To: References: From: Yutaka OIWA Date: Thu, 9 May 2013 15:16:09 +0900 Message-ID: To: Matthew Lepinski Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmY+y+5sS1koWi0KSXugNWVFkozqzcx0ACxGyGOciYdOv5C0JgJPEpYjX8gdwNAR6+umPkIs7rbwqQ3fKJKtDUWQ+5p4wIpjUEkTur4wIP+iL9oYp8IJwZyyFjzd6kEwgcDOJWCAYr29a0NMcyaZAsFk6+vDg== Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Working Group Acceptance of 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: Thu, 09 May 2013 06:16:35 -0000 Dear Matthew, Yoav and all the volunteers, Thank you for your cooperation. I will do it within a few weeks. Cheers, Yutaka 2013/5/7 Matthew Lepinski : > Thanks to everyone who volunteered to do a review of a potential working > group document. I am pleased to announce that we were able to obtain an > acceptable number of reviewers for each of the drafts. Therefore, the > following documents will be accepted as HTTP-AUTH working group drafts: > > draft-williams-http-rest-auth > draft-farrell-httpbis-hoba > draft-melnikov-httpbis-scram-auth > draft-oiwa-http-mutualauth and draft-oiwa-http-auth-extension > > The authors of each of these documents should submit a new version as > draft-ietf-httpauth-whatever-00. > > Thanks again to everyone who volunteered to review one of these documents. > Please be sure to send your reviews to the HTTP-AUTH mailing list. Of > course, everyone on this list encourage to review the new working group > documents regardless of whether or not you volunteered in advance to do a > review. > > Thanks > > Matt & Yoav > > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > -- Yutaka OIWA, Ph.D. Leader, Software Reliability Research Group Research Institute for Secure Systems (RISEC) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] From msporny@digitalbazaar.com Fri May 10 11:29:36 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 1072521F9023 for ; Fri, 10 May 2013 11:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 xC+v57s37B7l for ; Fri, 10 May 2013 11:29:32 -0700 (PDT) Received: from mail.digitalbazaar.com (unknown [216.252.204.51]) by ietfa.amsl.com (Postfix) with ESMTP id 69F6421F9021 for ; Fri, 10 May 2013 11:29:32 -0700 (PDT) Received: from zoe.digitalbazaar.com ([192.168.0.99] ident=msporny) by mail.digitalbazaar.com with esmtp (Exim 4.72) (envelope-from ) id 1Uas4S-0002oR-4Q for http-auth@ietf.org; Fri, 10 May 2013 14:29:32 -0400 Message-ID: <518D3C8B.3080807@digitalbazaar.com> Date: Fri, 10 May 2013 14:29:31 -0400 From: Manu Sporny User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.5) Gecko/20120624 Icedove/10.0.5 MIME-Version: 1.0 To: HTTP Auth WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [http-auth] First draft of HTTP Signatures published X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 18:29:36 -0000 The HTTP Signatures spec is a digital signature mechanism for the HTTP protocol. It adds origin authentication, message integrity, and replay resistance to HTTP requests. This is useful for any application that currently depends on Basic, Digest, OAuth, or OAuth2 authentication when performing RESTful HTTP calls. Basically, if a client needs to prove to a server that it sent an HTTP-based message, it can digitally sign that message. This spec defines exactly how that happens. This spec will be used by the Web Payments / PaySwarm / Web Keys work at W3C. We're going to combine the public/private key-based signature mechanism defined in HTTP Signatures with the public key infrastructure system as defined in Web Keys to provide an easy way for nodes on the Internet to verify their identity to other nodes on the Internet. The first draft of this spec was just published via the Internet Engineering Task Force (IETF) earlier today: http://tools.ietf.org/html/draft-cavage-http-signatures-00 You can also find a datetime-stamped version of the spec here: https://payswarm.com/specs/ED/http-signatures/2013-05-04/ The latest version of the spec can be found on the PaySwarm specs page: https://payswarm.com/specs/ -- manu -- Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) Founder/CEO - Digital Bazaar, Inc. blog: Meritora - Web payments commercial launch http://blog.meritora.com/launch/ From msporny@digitalbazaar.com Fri May 10 11:31:43 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 554A921F89B2 for ; Fri, 10 May 2013 11:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 ZqLvHVICMkay for ; Fri, 10 May 2013 11:31:39 -0700 (PDT) Received: from mail.digitalbazaar.com (unknown [216.252.204.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC7321F8AA8 for ; Fri, 10 May 2013 11:31:39 -0700 (PDT) Received: from zoe.digitalbazaar.com ([192.168.0.99] ident=msporny) by mail.digitalbazaar.com with esmtp (Exim 4.72) (envelope-from ) id 1Uas6U-0002uw-Uj; Fri, 10 May 2013 14:31:39 -0400 Message-ID: <518D3D0A.1010207@digitalbazaar.com> Date: Fri, 10 May 2013 14:31:38 -0400 From: Manu Sporny User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.5) Gecko/20120624 Icedove/10.0.5 MIME-Version: 1.0 To: HTTP WG References: <518C07DD.2090307@digitalbazaar.com> <403D922E-86CF-4355-BBD2-A05F409C25F7@mnot.net> In-Reply-To: <403D922E-86CF-4355-BBD2-A05F409C25F7@mnot.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: HTTP Auth WG Subject: [http-auth] Associating URI-based identities with HTTP requests X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 18:31:43 -0000 bcc: Web Payments mailing list We published the HTTP Signatures spec via the IETF a few days ago: http://lists.w3.org/Archives/Public/public-webpayments/2013May/0008.html That spec allows HTTP messages to be digitally signed. We are also working on another spec called Web Keys, that allows people to create identities and refer to them using URLs like: https://dev.payswarm.com/i/manu You can also publish RSA keys to locations on the Web and refer to them like this: https://dev.payswarm.com/i/manu/keys/4 The Web Payments group wanted to pursue updating the HTTP "From:" Header to allow both e-mail addresses and URLs, so one could do something like this: POST /some/url HTTP/1.1 Host: example.com From: https://dev.payswarm.com/i/manu Authorization: Signature keyId="https://dev.payswarm.com/i/manu/keys/4" ... Effectively, this makes it so that an HTTP request is not only digitally signed, but also bound to an identity of some sort. This is useful for the Web Payments work because it allows us to process payments using a single HTTP request (without introducing state into the HTTP transaction). After speaking with Mark Nottingham, he made it clear that this approach may be difficult to pursue in this group because 'From' is in use and has fairly well-understood semantics at this point in time. We're looking for feedback on the best approach for adding this sort of feature to HTTP messages. So, here are some other options: Using a Link header, or defining a new HTTP Header. Is there an RFC that explains when to define a new link relation and when to define a new header? It seems like doing a link relation would be better for the Web (by reducing HTTP header proliferation)? That said, the Web Keys spec would like to introduce some form of 'identity' to be associated with a digital signature for HTTP messages. We want to send a pretty strong signal that this can be used as a simpler way to authorize HTTP requests in certain scenarios (instead of falling back to OAuth, OAuth2, etc.). Placing this in a separate header might send a better message to developers (this is a primary feature of HTTP, use it) than doing it as a Link header (which is slightly more difficult to parse and create for developers). We could also shove it into an HTTP Signatures parameter, but that would prevent applications that want to use a different authentication mechanism from having the ability to refer to an identity using a URL. So, I think the proposal would be to create a 'Sender' header (ignore the name for now, it's just a placeholder so we can discuss the semantics of the header). This header would allow any URI to be placed into the header (so you could do everything you can today with 'From', and then in addition, you could also use URLs). For example, these would all be valid uses of 'Sender': Sender: mailto:msporny@digitalbazaar.com Sender: https://dev.payswarm.com/i/manu Sender: sip:msporny@digitalbazaar.com Sender: ssh://msporny;fingerprint=f3:8f:2f:..@example.com:1234 Authentication of the sender would be up to the application. In the Web Keys spec, we'd use the Authorization: Signature field to verify the Sender. Thoughts? What would be the best way to proceed on this? Link header or HTTP header? Publish an I-D, or try to tack it on to an existing spec? -- manu -- Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) Founder/CEO - Digital Bazaar, Inc. blog: Meritora - Web payments commercial launch http://blog.meritora.com/launch/ From mike@mtcc.com Fri May 10 12:23:22 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C466721F93BF for ; Fri, 10 May 2013 12:23:22 -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 AIYpxc5l2na9 for ; Fri, 10 May 2013 12:23:18 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB8521F91CE for ; Fri, 10 May 2013 12:23:18 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r4AJNBgu023645 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 10 May 2013 12:23:12 -0700 Message-ID: <518D491F.6000001@mtcc.com> Date: Fri, 10 May 2013 12:23:11 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Manu Sporny References: <518C07DD.2090307@digitalbazaar.com> <403D922E-86CF-4355-BBD2-A05F409C25F7@mnot.net> <518D3D0A.1010207@digitalbazaar.com> In-Reply-To: <518D3D0A.1010207@digitalbazaar.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=2179; t=1368213792; x=1369077792; 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]=20Associating=20URI-based=2 0identities=20with=20HTTP=20requests |Sender:=20 |To:=20Manu=20Sporny=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=qp5JQh3ysbHy/dr+MYadFh+6oR8haKKqaMAXgH8l2Yg=; b=BigqnaN4blqtY/Vang4ZmwIzJmpCQrEs1mRKz/BQ9Ln6WYRIBwK3e+vgh1 Gels7+tyWYEZ1aRrkQRiAF4auqMuhl2Tb+EUHcs6i/eLOaKQhTf0p8WmOJJ4 78zOIjR7c8H6vfcZ5/YWtkIXz0SJR2OzbH8JyDSWjYiaoai7vZU80=; 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 WG , HTTP WG Subject: Re: [http-auth] Associating URI-based identities with HTTP requests X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 19:23:22 -0000 On 05/10/2013 11:31 AM, Manu Sporny wrote: > The Web Payments group wanted to pursue updating the HTTP "From:" Header > to allow both e-mail addresses and URLs, so one could do something like > this: > > POST /some/url HTTP/1.1 > Host: example.com > From: https://dev.payswarm.com/i/manu > Authorization: Signature keyId="https://dev.payswarm.com/i/manu/keys/4" ... > > Effectively, this makes it so that an HTTP request is not only digitally > signed, but also bound to an identity of some sort. This is useful for > the Web Payments work because it allows us to process payments using a > single HTTP request (without introducing state into the HTTP transaction). here's a question I have: is the identifier used a "handle" or is it actually an operative identifier for another purpose? That is, does the identifier just need to be unique, or does it need to also be used for its "intended" purpose? I'm sorry if this is unclear. Let me give an example: mike@mtcc.com is an email address, it has the property that it is globally unique as well as the property that if you put use it as an email address for an rfc x82[1|2] message, it will deliver email to me. 102398019380984051850923405120948102801831234092843812304 on the other hand, it a (statistically) unique identity. It doesn't have any other meaning beyond its (assumedly) uniqueness factor. If the identifier is more like the latter than the former, there is a handy way to do that, which is to use raw public keys. They have the property that they are a) statistically unique and b) provable by the sender that they possess the private key. The way I like to think of "accounts" with this is to think not in terms of a signature asserting ownership of some account identifier (email address, local handle, etc, etc), but rather that a set of one or more public keys is bound to a given account regardless of what the human factors name is (eg, username). That is, the identity that is asserted is the public key, nothing more, nothing less. It's up to the account server's logic to bind the relationships together (eg, in its users table), not the client side. Mike From jasnell@gmail.com Fri May 10 16:42:52 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DCFA21F8F28 for ; Fri, 10 May 2013 16:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, WEIRD_PORT=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 WOGY4-izJnVO for ; Fri, 10 May 2013 16:42:51 -0700 (PDT) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 3DEE421F8EC1 for ; Fri, 10 May 2013 16:42:51 -0700 (PDT) Received: by mail-ob0-f180.google.com with SMTP id xk17so2583979obc.39 for ; Fri, 10 May 2013 16:42:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=H8fbjoMV8O0tPjb3PHnv6Ljie/VNmAww37N5Y70WmU8=; b=qVyVte4SzGHDgguE1kUgNi0fshyXaz+Lp1QDiyQdTraJ+NGKb9tHj5o/7BKNuoahsU /2UVc8E6e7M2sqtNHrmcUdUwem9BcTj7k/AuT8JoOoxuAVJTjXS062U1ktHw4zkc/mSR QxsyDseOyxPkDTihzhbhgmKjLYXKaEflS0MmPuh41rhOI8Aa/jLrgXahWFj1xpLZshkw kv1+fG18mwaoQOrWRSmP5xzf0S5iS/rV+DN09AhDCWhcqMGcqRy75cPvRojLyOcD/Amo xjxFAl4OuxzteO103beL9jfbc5WEscU14o1MqxNA5CL+byfn5tlmAJNvontu7NEHb4n4 HkIw== MIME-Version: 1.0 X-Received: by 10.60.47.81 with SMTP id b17mr207812oen.63.1368229370712; Fri, 10 May 2013 16:42:50 -0700 (PDT) Received: by 10.60.3.137 with HTTP; Fri, 10 May 2013 16:42:50 -0700 (PDT) Received: by 10.60.3.137 with HTTP; Fri, 10 May 2013 16:42:50 -0700 (PDT) In-Reply-To: <518D3D0A.1010207@digitalbazaar.com> References: <518C07DD.2090307@digitalbazaar.com> <403D922E-86CF-4355-BBD2-A05F409C25F7@mnot.net> <518D3D0A.1010207@digitalbazaar.com> Date: Fri, 10 May 2013 16:42:50 -0700 Message-ID: From: James M Snell To: Manu Sporny Content-Type: multipart/alternative; boundary=001a11c1fffe9cd88d04dc65b938 X-Mailman-Approved-At: Fri, 10 May 2013 17:00:23 -0700 Cc: HTTP Auth WG , ietf-http-wg@w3.org Subject: Re: [http-auth] Associating URI-based identities with HTTP requests X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 23:42:52 -0000 --001a11c1fffe9cd88d04dc65b938 Content-Type: text/plain; charset=UTF-8 Re: when to use a link header, the rule I follow is fairly basic : if the value consists of a uri that is optionally typed and potentially requires additional metadata, and if you think the link relation will be generally useful in other scenarios (e.g. Atom links, json documents, html tags), then use a link relation. If, on the other hand it is something that only requires a uri with no additional metadata, and you don't care about non-http use cases, use a new header. Based on an initial review of your note, a new header is likely appropriate. On May 10, 2013 11:33 AM, "Manu Sporny" wrote: > bcc: Web Payments mailing list > > We published the HTTP Signatures spec via the IETF a few days ago: > > http://lists.w3.org/Archives/Public/public-webpayments/2013May/0008.html > > That spec allows HTTP messages to be digitally signed. We are also > working on another spec called Web Keys, that allows people to create > identities and refer to them using URLs like: > > https://dev.payswarm.com/i/manu > > You can also publish RSA keys to locations on the Web and refer to them > like this: > > https://dev.payswarm.com/i/manu/keys/4 > > The Web Payments group wanted to pursue updating the HTTP "From:" Header > to allow both e-mail addresses and URLs, so one could do something like > this: > > POST /some/url HTTP/1.1 > Host: example.com > From: https://dev.payswarm.com/i/manu > Authorization: Signature keyId="https://dev.payswarm.com/i/manu/keys/4" > ... > > Effectively, this makes it so that an HTTP request is not only digitally > signed, but also bound to an identity of some sort. This is useful for > the Web Payments work because it allows us to process payments using a > single HTTP request (without introducing state into the HTTP transaction). > > After speaking with Mark Nottingham, he made it clear that this approach > may be difficult to pursue in this group because 'From' is in use and > has fairly well-understood semantics at this point in time. > > We're looking for feedback on the best approach for adding this sort of > feature to HTTP messages. > > So, here are some other options: Using a Link header, or defining a new > HTTP Header. > > Is there an RFC that explains when to define a new link relation and > when to define a new header? It seems like doing a link relation would > be better for the Web (by reducing HTTP header proliferation)? > > That said, the Web Keys spec would like to introduce some form of > 'identity' to be associated with a digital signature for HTTP messages. > > We want to send a pretty strong signal that this can be used as a > simpler way to authorize HTTP requests in certain scenarios (instead of > falling back to OAuth, OAuth2, etc.). Placing this in a separate header > might send a better message to developers (this is a primary feature of > HTTP, use it) than doing it as a Link header (which is slightly more > difficult to parse and create for developers). > > We could also shove it into an HTTP Signatures parameter, but that would > prevent applications that want to use a different authentication > mechanism from having the ability to refer to an identity using a URL. > > So, I think the proposal would be to create a 'Sender' header (ignore > the name for now, it's just a placeholder so we can discuss the > semantics of the header). This header would allow any URI to be placed > into the header (so you could do everything you can today with 'From', > and then in addition, you could also use URLs). For example, these would > all be valid uses of 'Sender': > > Sender: mailto:msporny@digitalbazaar.com > Sender: https://dev.payswarm.com/i/manu > Sender: sip:msporny@digitalbazaar.com > Sender: ssh://msporny;fingerprint=f3:8f:2f:..@example.com:1234 > > Authentication of the sender would be up to the application. In the Web > Keys spec, we'd use the Authorization: Signature field to verify the > Sender. > > Thoughts? What would be the best way to proceed on this? Link header or > HTTP header? Publish an I-D, or try to tack it on to an existing spec? > > -- manu > > -- > Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) > Founder/CEO - Digital Bazaar, Inc. > blog: Meritora - Web payments commercial launch > http://blog.meritora.com/launch/ > > --001a11c1fffe9cd88d04dc65b938 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Re: when to use a link header, the rule I follow is fairly b= asic : if the value consists of a uri that is optionally typed and potentia= lly requires additional metadata,=C2=A0 and if you think the link relation = will be generally useful in other scenarios (e.g.=C2=A0 Atom links,=C2=A0 j= son documents, html tags), then use a link relation. If,=C2=A0 on the other= hand it is something that only requires a uri with no additional metadata,= and you don't care about non-http use cases, use a new header.

Based on an initial review of your note, a new header is lik= ely appropriate.

On May 10, 2013 11:33 AM, "Manu Sporny"= ; <msporny@digitalbazaar.co= m> wrote:
bcc: Web Payments mailing list

We published the HTTP Signatures spec via the IETF a few days ago:

http://lists.w3.org/Archives/Public/public-webp= ayments/2013May/0008.html

That spec allows HTTP messages to be digitally signed. We are also
working on another spec called Web Keys, that allows people to create
identities and refer to them using URLs like:

https://dev.p= ayswarm.com/i/manu

You can also publish RSA keys to locations on the Web and refer to them
like this:

https:= //dev.payswarm.com/i/manu/keys/4

The Web Payments group wanted to pursue updating the HTTP "From:"= Header
to allow both e-mail addresses and URLs, so one could do something like
this:

POST /some/url HTTP/1.1
Host: example.com
From: https:/= /dev.payswarm.com/i/manu
Authorization: Signature keyId=3D"https://dev.payswarm.com/i/manu/keys/4= " ...

Effectively, this makes it so that an HTTP request is not only digitally signed, but also bound to an identity of some sort. This is useful for
the Web Payments work because it allows us to process payments using a
single HTTP request (without introducing state into the HTTP transaction).<= br>
After speaking with Mark Nottingham, he made it clear that this approach may be difficult to pursue in this group because 'From' is in use a= nd
has fairly well-understood semantics at this point in time.

We're looking for feedback on the best approach for adding this sort of=
feature to HTTP messages.

So, here are some other options: Using a Link header, or defining a new
HTTP Header.

Is there an RFC that explains when to define a new link relation and
when to define a new header? It seems like doing a link relation would
be better for the Web (by reducing HTTP header proliferation)?

That said, the Web Keys spec would like to introduce some form of
'identity' to be associated with a digital signature for HTTP messa= ges.

We want to send a pretty strong signal that this can be used as a
simpler way to authorize HTTP requests in certain scenarios (instead of
falling back to OAuth, OAuth2, etc.). Placing this in a separate header
might send a better message to developers (this is a primary feature of
HTTP, use it) than doing it as a Link header (which is slightly more
difficult to parse and create for developers).

We could also shove it into an HTTP Signatures parameter, but that would prevent applications that want to use a different authentication
mechanism from having the ability to refer to an identity using a URL.

So, I think the proposal would be to create a 'Sender' header (igno= re
the name for now, it's just a placeholder so we can discuss the
semantics of the header). This header would allow any URI to be placed
into the header (so you could do everything you can today with 'From= 9;,
and then in addition, you could also use URLs). For example, these would all be valid uses of 'Sender':

Sender: mailto:msporny@digital= bazaar.com
Sender: https= ://dev.payswarm.com/i/manu
Sender: sip:msporny@digi= talbazaar.com
Sender: ssh://msporny;fingerprint=3Df3:8f:2f:..@example.com:1234

Authentication of the sender would be up to the application. In the Web
Keys spec, we'd use the Authorization: Signature field to verify the Se= nder.

Thoughts? What would be the best way to proceed on this? Link header or
HTTP header? Publish an I-D, or try to tack it on to an existing spec?

-- manu

--
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Meritora - Web payments commercial launch
http://blog.= meritora.com/launch/

--001a11c1fffe9cd88d04dc65b938-- From ynir@checkpoint.com Sat May 11 20:37: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 F398621F89E2 for ; Sat, 11 May 2013 20:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.45 X-Spam-Level: X-Spam-Status: No, score=-10.45 tagged_above=-999 required=5 tests=[AWL=0.149, 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 MlwlTqhB7KZ1 for ; Sat, 11 May 2013 20:37:32 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 67E7221F8916 for ; Sat, 11 May 2013 20:37:32 -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 r4C3bELu002325; Sun, 12 May 2013 06:37:14 +0300 X-CheckPoint: {518F0CA3-0-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Sun, 12 May 2013 06:37:13 +0300 From: Yoav Nir To: Manu Sporny Thread-Topic: [http-auth] First draft of HTTP Signatures published Thread-Index: AQHOTaxcGLfKsfPu0kKEZwtLkyHGXJkAtmaA Date: Sun, 12 May 2013 03:37:12 +0000 Message-ID: <14CD3EC8-7302-4D8E-8575-1400352C7465@checkpoint.com> References: <518D3C8B.3080807@digitalbazaar.com> In-Reply-To: <518D3C8B.3080807@digitalbazaar.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.52] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 11ae384d0ef537865dd8b98ce38c3c05c299b36930 Content-Type: text/plain; charset="us-ascii" Content-ID: <002B8F745C37AF4195BC6A17C9169884@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: HTTP Auth WG Subject: Re: [http-auth] First draft of HTTP Signatures published 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: Sun, 12 May 2013 03:37:37 -0000 Hi Manu The HTTP-Auth working group is chartered to work on a very specific set of = documents. OTOH, the WebSec working group is considering adopting a work it= em for session continuation. Session continuation is supposed to be a repla= cement for authorizing requests via session cookies. See the problem statem= ent here: http://tools.ietf.org/html/draft-williams-websec-session-continue-prob-00 If I understand correctly, your draft is aiming to solve that issue. So you= might prefer to take your draft there. Yoav Nir (as co-chair of both groups) On May 10, 2013, at 9:29 PM, Manu Sporny wrote: > The HTTP Signatures spec is a digital signature mechanism for the HTTP > protocol. It adds origin authentication, message integrity, and replay > resistance to HTTP requests. This is useful for any application that > currently depends on Basic, Digest, OAuth, or OAuth2 authentication when > performing RESTful HTTP calls. >=20 > Basically, if a client needs to prove to a server that it sent an > HTTP-based message, it can digitally sign that message. This spec > defines exactly how that happens. >=20 > This spec will be used by the Web Payments / PaySwarm / Web Keys work at > W3C. We're going to combine the public/private key-based signature > mechanism defined in HTTP Signatures with the public key infrastructure > system as defined in Web Keys to provide an easy way for nodes on the > Internet to verify their identity to other nodes on the Internet. >=20 > The first draft of this spec was just published via the Internet > Engineering Task Force (IETF) earlier today: >=20 > http://tools.ietf.org/html/draft-cavage-http-signatures-00 >=20 > You can also find a datetime-stamped version of the spec here: >=20 > https://payswarm.com/specs/ED/http-signatures/2013-05-04/ >=20 > The latest version of the spec can be found on the PaySwarm specs page: >=20 > https://payswarm.com/specs/ >=20 > -- manu >=20 > --=20 > Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) > Founder/CEO - Digital Bazaar, Inc. > blog: Meritora - Web payments commercial launch > http://blog.meritora.com/launch/ > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth >=20 > Email secured by Check Point From stephen.farrell@cs.tcd.ie Sun May 12 06:23:03 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD2F21F8607 for ; Sun, 12 May 2013 06:23:03 -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 vN47QubuMRbD for ; Sun, 12 May 2013 06:22: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 BC07E21F8E66 for ; Sun, 12 May 2013 06:22:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C7942BE51; Sun, 12 May 2013 14:22:32 +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 F2039oSgyp4f; Sun, 12 May 2013 14:22:28 +0100 (IST) Received: from [10.87.48.11] (unknown [86.45.51.1]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D511BBE49; Sun, 12 May 2013 14:22:28 +0100 (IST) Message-ID: <518F9794.6080905@cs.tcd.ie> Date: Sun, 12 May 2013 14:22:28 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130404 Thunderbird/17.0.5 MIME-Version: 1.0 To: Yoav Nir References: <518D3C8B.3080807@digitalbazaar.com> <14CD3EC8-7302-4D8E-8575-1400352C7465@checkpoint.com> In-Reply-To: <14CD3EC8-7302-4D8E-8575-1400352C7465@checkpoint.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: HTTP Auth WG Subject: Re: [http-auth] First draft of HTTP Signatures published 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: Sun, 12 May 2013 13:23:03 -0000 Yoav, On 05/12/2013 04:37 AM, Yoav Nir wrote: > Hi Manu > > The HTTP-Auth working group is chartered to work on a very specific set of documents. OTOH, the WebSec working group is considering adopting a work item for session continuation. Session continuation is supposed to be a replacement for authorizing requests via session cookies. See the problem statement here: > > http://tools.ietf.org/html/draft-williams-websec-session-continue-prob-00 > > If I understand correctly, your draft is aiming to solve that issue. So you might prefer to take your draft there. Fair points. But I do think some discussion of the differences between Manu's proposal and HOBA on this list might be beneficial before any conclusion as to IETF WG venue etc are reached. In addition I think Manu regards his scheme as a primary user authentication scheme and not as a session continuation scheme which again argues for discussing it here. The above discussion will be more useful when we've posted the rev of HOBA, which will be in the next few days. Cheers, S. (as participant, of course;-) > Yoav Nir (as co-chair of both groups) > > On May 10, 2013, at 9:29 PM, Manu Sporny wrote: > >> The HTTP Signatures spec is a digital signature mechanism for the HTTP >> protocol. It adds origin authentication, message integrity, and replay >> resistance to HTTP requests. This is useful for any application that >> currently depends on Basic, Digest, OAuth, or OAuth2 authentication when >> performing RESTful HTTP calls. >> >> Basically, if a client needs to prove to a server that it sent an >> HTTP-based message, it can digitally sign that message. This spec >> defines exactly how that happens. >> >> This spec will be used by the Web Payments / PaySwarm / Web Keys work at >> W3C. We're going to combine the public/private key-based signature >> mechanism defined in HTTP Signatures with the public key infrastructure >> system as defined in Web Keys to provide an easy way for nodes on the >> Internet to verify their identity to other nodes on the Internet. >> >> The first draft of this spec was just published via the Internet >> Engineering Task Force (IETF) earlier today: >> >> http://tools.ietf.org/html/draft-cavage-http-signatures-00 >> >> You can also find a datetime-stamped version of the spec here: >> >> https://payswarm.com/specs/ED/http-signatures/2013-05-04/ >> >> The latest version of the spec can be found on the PaySwarm specs page: >> >> https://payswarm.com/specs/ >> >> -- manu >> >> -- >> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) >> Founder/CEO - Digital Bazaar, Inc. >> blog: Meritora - Web payments commercial launch >> http://blog.meritora.com/launch/ >> _______________________________________________ >> http-auth mailing list >> http-auth@ietf.org >> https://www.ietf.org/mailman/listinfo/http-auth >> >> Email secured by Check Point > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > > From ynir@checkpoint.com Sun May 12 08:07: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 331D121F8D14 for ; Sun, 12 May 2013 08:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.612 X-Spam-Level: X-Spam-Status: No, score=-10.612 tagged_above=-999 required=5 tests=[AWL=-0.013, 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 8Nng6VHsCScA for ; Sun, 12 May 2013 08:07:34 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id D227721F8709 for ; Sun, 12 May 2013 08:07:33 -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 r4CF78Vf012834; Sun, 12 May 2013 18:07:14 +0300 X-CheckPoint: {518FAE4F-E-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Sun, 12 May 2013 18:04:43 +0300 From: Yoav Nir To: Stephen Farrell Thread-Topic: [http-auth] First draft of HTTP Signatures published Thread-Index: AQHOTaxcGLfKsfPu0kKEZwtLkyHGXJkAtmaAgACjdgCAAByhAA== Date: Sun, 12 May 2013 15:04:43 +0000 Message-ID: References: <518D3C8B.3080807@digitalbazaar.com> <14CD3EC8-7302-4D8E-8575-1400352C7465@checkpoint.com> <518F9794.6080905@cs.tcd.ie> In-Reply-To: <518F9794.6080905@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.25] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 11f56a36416dbcd3e44a5c04cc400720e6aaa03d22 Content-Type: text/plain; charset="iso-8859-1" Content-ID: <9EB52E84FDC1B04288E4B36A5B0B281F@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: HTTP Auth WG Subject: Re: [http-auth] First draft of HTTP Signatures published 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: Sun, 12 May 2013 15:07:39 -0000 Works for me, especially since WebSec is still a long way from deciding to = work on session continuation/management. Yoav On May 12, 2013, at 4:22 PM, Stephen Farrell wr= ote: >=20 > Yoav, >=20 > On 05/12/2013 04:37 AM, Yoav Nir wrote: >> Hi Manu >>=20 >> The HTTP-Auth working group is chartered to work on a very specific set = of documents. OTOH, the WebSec working group is considering adopting a work= item for session continuation. Session continuation is supposed to be a re= placement for authorizing requests via session cookies. See the problem sta= tement here: >>=20 >> http://tools.ietf.org/html/draft-williams-websec-session-continue-prob-0= 0 >>=20 >> If I understand correctly, your draft is aiming to solve that issue. So = you might prefer to take your draft there. >=20 > Fair points. But I do think some discussion of the differences between > Manu's proposal and HOBA on this list might be beneficial before any > conclusion as to IETF WG venue etc are reached. >=20 > In addition I think Manu regards his scheme as a primary user > authentication scheme and not as a session continuation scheme which > again argues for discussing it here. >=20 > The above discussion will be more useful when we've posted the rev > of HOBA, which will be in the next few days. >=20 > Cheers, > S. (as participant, of course;-) >=20 >=20 >=20 >=20 >=20 >> Yoav Nir (as co-chair of both groups) >>=20 >> On May 10, 2013, at 9:29 PM, Manu Sporny wro= te: >>=20 >>> The HTTP Signatures spec is a digital signature mechanism for the HTTP >>> protocol. It adds origin authentication, message integrity, and replay >>> resistance to HTTP requests. This is useful for any application that >>> currently depends on Basic, Digest, OAuth, or OAuth2 authentication whe= n >>> performing RESTful HTTP calls. >>>=20 >>> Basically, if a client needs to prove to a server that it sent an >>> HTTP-based message, it can digitally sign that message. This spec >>> defines exactly how that happens. >>>=20 >>> This spec will be used by the Web Payments / PaySwarm / Web Keys work a= t >>> W3C. We're going to combine the public/private key-based signature >>> mechanism defined in HTTP Signatures with the public key infrastructure >>> system as defined in Web Keys to provide an easy way for nodes on the >>> Internet to verify their identity to other nodes on the Internet. >>>=20 >>> The first draft of this spec was just published via the Internet >>> Engineering Task Force (IETF) earlier today: >>>=20 >>> http://tools.ietf.org/html/draft-cavage-http-signatures-00 >>>=20 >>> You can also find a datetime-stamped version of the spec here: >>>=20 >>> https://payswarm.com/specs/ED/http-signatures/2013-05-04/ >>>=20 >>> The latest version of the spec can be found on the PaySwarm specs page: >>>=20 >>> https://payswarm.com/specs/ >>>=20 >>> -- manu >>>=20 >>> --=20 >>> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) >>> Founder/CEO - Digital Bazaar, Inc. >>> blog: Meritora - Web payments commercial launch >>> http://blog.meritora.com/launch/ >>> _______________________________________________ >>> http-auth mailing list >>> http-auth@ietf.org >>> https://www.ietf.org/mailman/listinfo/http-auth >>>=20 >>> Email secured by Check Point >>=20 >> _______________________________________________ >> http-auth mailing list >> http-auth@ietf.org >> https://www.ietf.org/mailman/listinfo/http-auth >>=20 >>=20 >=20 > Email secured by Check Point From msporny@digitalbazaar.com Sun May 12 11:15: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 E4F8A21F84EF for ; Sun, 12 May 2013 11:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.758 X-Spam-Level: X-Spam-Status: No, score=-1.758 tagged_above=-999 required=5 tests=[AWL=-1.263, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 xM2wkQ7Dt9lJ for ; Sun, 12 May 2013 11:15:53 -0700 (PDT) Received: from mail.digitalbazaar.com (unknown [216.252.204.51]) by ietfa.amsl.com (Postfix) with ESMTP id 3757021F84D4 for ; Sun, 12 May 2013 11:15:53 -0700 (PDT) Received: from [192.168.100.5] by mail.digitalbazaar.com with esmtp (Exim 4.72) (envelope-from ) id 1UbaoI-00039d-6t; Sun, 12 May 2013 14:15:51 -0400 Message-ID: <518FDC50.9040007@digitalbazaar.com> Date: Sun, 12 May 2013 14:15:44 -0400 From: Manu Sporny User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.4) Gecko/20120510 Icedove/10.0.4 MIME-Version: 1.0 To: Yoav Nir References: <518D3C8B.3080807@digitalbazaar.com> <14CD3EC8-7302-4D8E-8575-1400352C7465@checkpoint.com> In-Reply-To: <14CD3EC8-7302-4D8E-8575-1400352C7465@checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: HTTP Auth WG Subject: Re: [http-auth] First draft of HTTP Signatures published 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: Sun, 12 May 2013 18:15:57 -0000 On 05/11/2013 11:37 PM, Yoav Nir wrote: > The HTTP-Auth working group is chartered to work on a very specific > set of documents. OTOH, the WebSec working group is considering > adopting a work item for session continuation. Session continuation > is supposed to be a replacement for authorizing requests via session > cookies. See the problem statement here: > > http://tools.ietf.org/html/draft-williams-websec-session-continue-prob-00 > > If I understand correctly, your draft is aiming to solve that issue. > So you might prefer to take your draft there. Session management is out-of-scope for the HTTP Signatures spec. It's true that a session management scheme could be built on top of HTTP Signatures, but that is a second step. We know that many others are working on session management right now, and would rather they see if HTTP Signatures could be useful for them rather than try to shove session management capabilities into HTTP Signatures. The HTTP Signatures spec is a fairly simple, straightforward spec as-is. We'd like to keep it that way. :) -- manu -- Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) Founder/CEO - Digital Bazaar, Inc. blog: Meritora - Web payments commercial launch http://blog.meritora.com/launch/ From msporny@digitalbazaar.com Sun May 12 11:17:57 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1E0521F8C40 for ; Sun, 12 May 2013 11:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.505 X-Spam-Level: X-Spam-Status: No, score=-1.505 tagged_above=-999 required=5 tests=[AWL=-1.010, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 ep8FaHC2jHEV for ; Sun, 12 May 2013 11:17:54 -0700 (PDT) Received: from mail.digitalbazaar.com (unknown [216.252.204.51]) by ietfa.amsl.com (Postfix) with ESMTP id EC05721F8B38 for ; Sun, 12 May 2013 11:17:53 -0700 (PDT) Received: from [192.168.100.5] by mail.digitalbazaar.com with esmtp (Exim 4.72) (envelope-from ) id 1UbaqC-00039t-Hr; Sun, 12 May 2013 14:17:49 -0400 Message-ID: <518FDCC7.1010406@digitalbazaar.com> Date: Sun, 12 May 2013 14:17:43 -0400 From: Manu Sporny User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.4) Gecko/20120510 Icedove/10.0.4 MIME-Version: 1.0 To: Stephen Farrell References: <518D3C8B.3080807@digitalbazaar.com> <14CD3EC8-7302-4D8E-8575-1400352C7465@checkpoint.com> <518F9794.6080905@cs.tcd.ie> In-Reply-To: <518F9794.6080905@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: HTTP Auth WG Subject: Re: [http-auth] First draft of HTTP Signatures published 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: Sun, 12 May 2013 18:17:57 -0000 On 05/12/2013 09:22 AM, Stephen Farrell wrote: > Fair points. But I do think some discussion of the differences > between Manu's proposal and HOBA on this list might be beneficial > before any conclusion as to IETF WG venue etc are reached. Agreed. > In addition I think Manu regards his scheme as a primary user > authentication scheme and not as a session continuation scheme which > again argues for discussing it here. It's Mark Cavage's scheme. I just happen to believe that it's brilliant and am willing to put in the time to push it forward in a standards community. :) > The above discussion will be more useful when we've posted the rev of > HOBA, which will be in the next few days. Looking forward to it. :) -- manu -- Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) Founder/CEO - Digital Bazaar, Inc. blog: Meritora - Web payments commercial launch http://blog.meritora.com/launch/ From msporny@digitalbazaar.com Sun May 12 11:24: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 2454021F8C69 for ; Sun, 12 May 2013 11:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.337 X-Spam-Level: X-Spam-Status: No, score=-1.337 tagged_above=-999 required=5 tests=[AWL=-0.842, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 L3Cq8OTdj3Pk for ; Sun, 12 May 2013 11:24:27 -0700 (PDT) Received: from mail.digitalbazaar.com (unknown [216.252.204.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4F08521F8BB7 for ; Sun, 12 May 2013 11:24:27 -0700 (PDT) Received: from [192.168.100.5] by mail.digitalbazaar.com with esmtp (Exim 4.72) (envelope-from ) id 1UbawZ-0003GU-OJ; Sun, 12 May 2013 14:24:24 -0400 Message-ID: <518FDE52.1050009@digitalbazaar.com> Date: Sun, 12 May 2013 14:24:18 -0400 From: Manu Sporny User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.4) Gecko/20120510 Icedove/10.0.4 MIME-Version: 1.0 To: Yoav Nir References: <518D3C8B.3080807@digitalbazaar.com> <14CD3EC8-7302-4D8E-8575-1400352C7465@checkpoint.com> <518F9794.6080905@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: HTTP Auth WG Subject: Re: [http-auth] First draft of HTTP Signatures published 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: Sun, 12 May 2013 18:24:31 -0000 On 05/12/2013 11:04 AM, Yoav Nir wrote: > Works for me, especially since WebSec is still a long way from > deciding to work on session continuation/management. As an aside, the other option is to just do the work at the W3C. I could fold it into the newly forming Web Payments WG fairly quickly and get it to REC that way as well (if it's too much of a burden to do it via IETF). In the end, it doesn't really matter which organization can figure out how to do the work, as long as we can get it vetted, stabilized, and published so that implementers can start implementing it more widely. Keep in mind that we have two organizations that have already implemented and vetted the specification and are running it in production: Joyent (corporate stewards of node.js) and Digital Bazaar (corporate stewards of PaySwarm). -- manu -- Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) Founder/CEO - Digital Bazaar, Inc. blog: Meritora - Web payments commercial launch http://blog.meritora.com/launch/ From msporny@digitalbazaar.com Sun May 12 11:37: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 6069F21F86F0 for ; Sun, 12 May 2013 11:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.217 X-Spam-Level: X-Spam-Status: No, score=-1.217 tagged_above=-999 required=5 tests=[AWL=-0.722, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 QLbCh1Y-EYfv for ; Sun, 12 May 2013 11:37:35 -0700 (PDT) Received: from mail.digitalbazaar.com (unknown [216.252.204.51]) by ietfa.amsl.com (Postfix) with ESMTP id 9831221F84D9 for ; Sun, 12 May 2013 11:37:35 -0700 (PDT) Received: from [192.168.100.5] by mail.digitalbazaar.com with esmtp (Exim 4.72) (envelope-from ) id 1Ubb9H-0003ZM-Gr; Sun, 12 May 2013 14:37:33 -0400 Message-ID: <518FE165.8060600@digitalbazaar.com> Date: Sun, 12 May 2013 14:37:25 -0400 From: Manu Sporny User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.4) Gecko/20120510 Icedove/10.0.4 MIME-Version: 1.0 To: Michael Thomas References: <518C07DD.2090307@digitalbazaar.com> <403D922E-86CF-4355-BBD2-A05F409C25F7@mnot.net> <518D3D0A.1010207@digitalbazaar.com> <518D491F.6000001@mtcc.com> In-Reply-To: <518D491F.6000001@mtcc.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: HTTP Auth WG , HTTP WG Subject: Re: [http-auth] Associating URI-based identities with HTTP requests 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: Sun, 12 May 2013 18:37:39 -0000 On 05/10/2013 03:23 PM, Michael Thomas wrote: > mike@mtcc.com is an email address, it has the property that it is > globally unique as well as the property that if you put use it as an > email address for an rfc x82[1|2] message, it will deliver email to > me. This is closer to the purpose than the 'identifier' just being unique. > 102398019380984051850923405120948102801831234092843812304 on the > other hand, it a (statistically) unique identity. It doesn't have > any other meaning beyond its (assumedly) uniqueness factor. The types of identifiers that we want to use could be used w/ another RFC/REC. For example, the Web Payments work at the W3C will use the identifier: https://dev.payswarm.com/i/manu To assert the ownership of multiple keys. For example, do this: curl https://dev.payswarm.com/i/manu You will see a set of 'publicKey's associated with identity. So, as long as a message can be verified using any one of those public keys, you can assert that the owner of the public key is that identity. > The way I like to think of "accounts" with this is to think not in > terms of a signature asserting ownership of some account identifier > (email address, local handle, etc, etc), but rather that a set of one > or more public keys is bound to a given account regardless of what > the human factors name is (eg, username). That is, the identity that > is asserted is the public key, nothing more, nothing less. It's up to > the account server's logic to bind the relationships together (eg, in > its users table), not the client side. You can also go from the key to the owner of the key, for example, do this: curl https://dev.payswarm.com/i/manu/keys/4 You can see that the key has an owner, who is: https://dev.payswarm.com/i/manu However, using purely the key ID assumes that the key ID can always be discovered in all HTTP Requests. This is not always the case. For example, if the requestor has already authenticated via a cookie, but has multiple identities associated w/ the cookie, then it would be impossible to determine which identity they want to use when requesting a certain operation on the server. In short, we don't want to tightly couple the identity scheme with the authentication or authorization scheme. -- manu -- Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) Founder/CEO - Digital Bazaar, Inc. blog: Meritora - Web payments commercial launch http://blog.meritora.com/launch/ From msporny@digitalbazaar.com Sun May 12 16:07:20 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF2E21F8E59 for ; Sun, 12 May 2013 16:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.618 X-Spam-Level: X-Spam-Status: No, score=-1.618 tagged_above=-999 required=5 tests=[AWL=-1.123, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 tEtF0HAMh6-l for ; Sun, 12 May 2013 16:07:15 -0700 (PDT) Received: from mail.digitalbazaar.com (unknown [216.252.204.51]) by ietfa.amsl.com (Postfix) with ESMTP id 52EFD21F898B for ; Sun, 12 May 2013 16:07:13 -0700 (PDT) Received: from [192.168.100.5] by mail.digitalbazaar.com with esmtp (Exim 4.72) (envelope-from ) id 1UbfMF-0000gX-3h; Sun, 12 May 2013 19:07:12 -0400 Message-ID: <51902099.9080100@digitalbazaar.com> Date: Sun, 12 May 2013 19:07:05 -0400 From: Manu Sporny User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.4) Gecko/20120510 Icedove/10.0.4 MIME-Version: 1.0 To: James M Snell References: <518C07DD.2090307@digitalbazaar.com> <403D922E-86CF-4355-BBD2-A05F409C25F7@mnot.net> <518D3D0A.1010207@digitalbazaar.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: HTTP Auth WG , ietf-http-wg@w3.org Subject: Re: [http-auth] Associating URI-based identities with HTTP requests 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: Sun, 12 May 2013 23:07:20 -0000 On 05/10/2013 07:42 PM, James M Snell wrote: > Re: when to use a link header, the rule I follow is fairly basic : > if the value consists of a uri that is optionally typed and > potentially requires additional metadata, and if you think the link > relation will be generally useful in other scenarios (e.g. Atom > links, json documents, html tags), then use a link relation. The link could be typed, or it could just be a plain 'ol URI. If the link is typed, it could have multiple different types (since we're dealing with Linked Data). The purpose of the link is to express an identity, but the same link can be used for describing ownership, access control, etc. > If, on the other hand it is something that only requires a uri with > no additional metadata, and you don't care about non-http use cases, > use a new header. Yeah, I think we're in this scenario. > Based on an initial review of your note, a new header is likely > appropriate. Thanks - your basic rule was very helpful... would be good if we could put it in an RFC somewhere. :) -- manu -- Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) Founder/CEO - Digital Bazaar, Inc. blog: Meritora - Web payments commercial launch http://blog.meritora.com/launch/ From James.H.Manger@team.telstra.com Sun May 12 18:55: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 21FF321F8464 for ; Sun, 12 May 2013 18:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] 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 xT0kGCPOWQMP for ; Sun, 12 May 2013 18:55:52 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id 72C3821F8443 for ; Sun, 12 May 2013 18:55:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,658,1363093200"; d="scan'208";a="134671426" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipoavi.tcif.telstra.com.au with ESMTP; 13 May 2013 11:55:36 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7073"; a="131680663" Received: from wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) by ipcbvi.tcif.telstra.com.au with ESMTP; 13 May 2013 11:55:36 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) with mapi; Mon, 13 May 2013 11:55:36 +1000 From: "Manger, James H" To: Manu Sporny , HTTP Auth WG Date: Mon, 13 May 2013 11:55:35 +1000 Thread-Topic: [http-auth] First draft of HTTP Signatures published Thread-Index: Ac5NrFaoccskvaReTEmhcYcGKWy1ZQBwpZnA Message-ID: <255B9BB34FB7D647A506DC292726F6E1150D5134B8@WSMSG3153V.srv.dir.telstra.com> References: <518D3C8B.3080807@digitalbazaar.com> In-Reply-To: <518D3C8B.3080807@digitalbazaar.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [http-auth] First draft of HTTP Signatures published X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 01:55:56 -0000 Q29tbWVudHMgb24gZHJhZnQtY2F2YWdlLWh0dHAtc2lnbmF0dXJlcy0wMDoNCg0KMS4NCkNvbnRl bnQtTGVuZ3RoIGluIHRoZSBleGFtcGxlIGluIHNlY3Rpb24gMi4xLjIuICJTaWduYXR1cmUgU3Ry aW5nIENvbnN0cnVjdGlvbiIgc2hvdWxkIGJlIDE0LCBub3QgMTUuIFRoZSBjb250ZW50LU1ENSB2 YWx1ZSBpcyBjYWxjdWxhdGVkIG92ZXIgMTQgYnl0ZXMuDQoNCjIuDQpUaGUgc3RyaW5nIHRvIGJl IHNpZ25lZCAoc2VjdGlvbiAyLjEuMi4gIlNpZ25hdHVyZSBTdHJpbmcgQ29uc3RydWN0aW9uIikg bG9va3MgbGlrZSBsaW5lcyB0aGF0IGNvdWxkIGJlIHNlbnQgaW4gdGhlIEhUVFAgcmVxdWVzdCwg YnV0IHRoZXkgZG9u4oCZdCBxdWl0ZSBtYXRjaC4gTGluZXMgaW4gYW4gSFRUUCBoZWFkZXIgZW5k IHdpdGggXHJcbiwgd2hlcmVhcyBsaW5lcyBpbiB0aGUgc3RyaW5nIHRvIGJlIHNpZ25lZCBlbmQg aW4gXG4uDQoNCldoeSBib3RoZXIgb21pdHRpbmcgXG4gZnJvbSB0aGUgbGFzdCBsaW5lPyBJdCBp cyBzaW1wbGVyIHRvIGVuZCBhbGwgdGhlIGxpbmVzIHRoZSBzYW1lIHdheS4gSXQgaXMgYW5ub3lp bmdseSBhd2t3YXJkIHRvIHdyaXRlIGZpbGVzIHdpdGggYSB0ZXh0IGVkaXRvciB0aGF0IG9taXQg YSBmaW5hbCBcbi4NCg0KMy4NClRoZSBzaWduYXR1cmUgaXMgd3JvbmcgaW4gc2VjdGlvbiA0LjEu ICJEZWZhdWx0IFRlc3QiLiBVbnBhY2tpbmcgdGhlIHNpZ25hdHVyZSByZXZlYWxzIGEgU0hBLTI1 NiBoYXNoIG9mIEVCRjAwMkE5NUVDNEREQjdBNTBDQ0FDMDA5QkFBMkZFNUQxQjI2MDREQTdDQjg3 MUI4NzBDRUUyMUJFODVFQjkuIFRoZSBTSEEtMjU2IGhhcyBvZiAiZGF0ZTogVGh1LCAwNSBKYW4g MjAxMiAyMTozMTo0MCBHTVQiIGlzIDE5NThCNjU2QzA5RTI5ODI0QTJCQ0YwMzE5NzkyM0JDRDlC NTUzNzBGMkZGMjExOEZGNEM0N0FENzc1MTNCM0YuDQoNCjQuDQpUaGUgc2lnbmF0dXJlIGlzIHdy b25nIGluIHNlY3Rpb24gNC4yLiAiQWxsIEhlYWRlcnMgVGVzdCIuIFVucGFja2luZyB0aGUgc2ln bmF0dXJlIHJldmVhbHMgYSBTSEEtMjU2IGhhc2ggb2YgNEU3QTAzOEJDOUVGQUI5NUFDODI5QUMx NzY2NTlEQ0UwQTdCNkRDOTRGOUZBQTU0Mzc1MzkwQTVFQThBOUIzNy4gVGhlIFNIQS0yNTYgaGFz IG9mIGFsbCB0aGUgaGVhZGVycyBpcyAxMDE1NTI4QzcxRjlCQzNENDQ1QjQ1N0NBNDFEOEJDODg0 RTg5Mjc1RURERDBGMDQzNUJCQjEzQTY1QjQ1NTBELg0KDQo1Lg0KVGhlIGZpZWxkcyB0aGF0IGFy ZSBzaWduZWQgYXJlIGFic29sdXRlbHkgY3J1Y2lhbCBpbiBkZXRlcm1pbmluZyB0aGUgc2VjdXJp dHkgcHJvcGVydGllcyBhY2hpZXZlZC4gSXQgaXMgbm90IHN1ZmZpY2llbnQgZm9yIHRoZSBzcGVj IHRvIG1lcmVseSBzYXkgdGhlIGNob2ljZSBvZiBmaWVsZHMgaXMgIm91dCBvZiBzY29wZSIgaW4g YSBjbGF1c2Ugb2YgdGhlICJTZWN1cml0eSBDb25zaWRlcmF0aW9ucyIgKHNlY3Rpb24gMy41ICJS ZXF1aXJlZCBIZWFkZXJzIHRvIFNpZ24iKS4NClRoZSBpbnRyb2R1Y3Rpb24gbmVlZHMgdG8gc3Rh dGUgdGhhdDogdGhlIG1lY2hhbmlzbSBzaWducyBhICpzdWJzZXQqIG9mIGFuIEhUVFAgcmVxdWVz dDsgcmVjaXBpZW50cyBuZWVkIHRvIGJlIHByZS1jb25maWd1cmVkIHdpdGggdGhlIHN1YnNldCB0 aGV5IHJlcXVpcmUgKGFuZCBNVVNUIGNvbmZpcm0gdGhhdCAiaGVhZGVycyIgaW5jbHVkZXMgYXQg bGVhc3QgdGhhdCBzdWJzZXQpOyB0aGUgYm9keSBpcyBvbmx5IHByb3RlY3RlZCBpZiBhIENvbnRl bnQtTUQ1L0RpZ2VzdCBpcyBzaWduZWQgKGFuZCB0aGUgYm9keSBoYXNoIGlzIGNoZWNrZWQpLiBT aWduaW5nIGp1c3QgImRhdGUiIHNob3cgdGhlIG9yaWdpbmF0b3IgY29tbWl0dGVkIHRvIG9uZSBI VFRQIHJlcXVlc3QgYXQgYWJvdXQgdGhlIHRpbWUgb2YgdGhlIGRhdGUgdmFsdWUsIGJ1dCBnaXZl cyBubyBwcm90ZWN0aW9uIGFzIHRvIHRoZSBuYXR1cmUgb2YgdGhhdCByZXF1ZXN0ICh0aGUgcXVl cnkgcGFyYW1zLCBwYXRoLCBtZXRob2QsIGJvZHksIG9yIGV2ZW4gaG9zdCBldGMpLiBPbmUgc3Ry YXRlZ3kgZm9yIHJlY2lwaWVudHMgd291bGQgYmUgdG8gb25seSBwYXNzIHNpZ25lZCBmaWVsZHMg b24gdG8gdGhlIG5leHQgc3RhZ2Ugb2YgcmVxdWVzdCBwcm9jZXNzaW5nLg0KDQoNCi0tDQpKYW1l cyBNYW5nZXINCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBodHRwLWF1 dGgtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmh0dHAtYXV0aC1ib3VuY2VzQGlldGYub3JnXSBP bg0KPiBCZWhhbGYgT2YgTWFudSBTcG9ybnkNCj4gU2VudDogU2F0dXJkYXksIDExIE1heSAyMDEz IDQ6MzAgQU0NCj4gVG86IEhUVFAgQXV0aCBXRw0KPiBTdWJqZWN0OiBbaHR0cC1hdXRoXSBGaXJz dCBkcmFmdCBvZiBIVFRQIFNpZ25hdHVyZXMgcHVibGlzaGVkDQo+IA0KPiBUaGUgSFRUUCBTaWdu YXR1cmVzIHNwZWMgaXMgYSBkaWdpdGFsIHNpZ25hdHVyZSBtZWNoYW5pc20gZm9yIHRoZSBIVFRQ DQo+IHByb3RvY29sLiBJdCBhZGRzIG9yaWdpbiBhdXRoZW50aWNhdGlvbiwgbWVzc2FnZSBpbnRl Z3JpdHksIGFuZCByZXBsYXkNCj4gcmVzaXN0YW5jZSB0byBIVFRQIHJlcXVlc3RzLiBUaGlzIGlz IHVzZWZ1bCBmb3IgYW55IGFwcGxpY2F0aW9uIHRoYXQNCj4gY3VycmVudGx5IGRlcGVuZHMgb24g QmFzaWMsIERpZ2VzdCwgT0F1dGgsIG9yIE9BdXRoMiBhdXRoZW50aWNhdGlvbg0KPiB3aGVuIHBl cmZvcm1pbmcgUkVTVGZ1bCBIVFRQIGNhbGxzLg0KPiANCj4gQmFzaWNhbGx5LCBpZiBhIGNsaWVu dCBuZWVkcyB0byBwcm92ZSB0byBhIHNlcnZlciB0aGF0IGl0IHNlbnQgYW4gSFRUUC0NCj4gYmFz ZWQgbWVzc2FnZSwgaXQgY2FuIGRpZ2l0YWxseSBzaWduIHRoYXQgbWVzc2FnZS4gVGhpcyBzcGVj IGRlZmluZXMNCj4gZXhhY3RseSBob3cgdGhhdCBoYXBwZW5zLg0KPiANCj4gVGhpcyBzcGVjIHdp bGwgYmUgdXNlZCBieSB0aGUgV2ViIFBheW1lbnRzIC8gUGF5U3dhcm0gLyBXZWIgS2V5cyB3b3Jr DQo+IGF0IFczQy4gV2UncmUgZ29pbmcgdG8gY29tYmluZSB0aGUgcHVibGljL3ByaXZhdGUga2V5 LWJhc2VkIHNpZ25hdHVyZQ0KPiBtZWNoYW5pc20gZGVmaW5lZCBpbiBIVFRQIFNpZ25hdHVyZXMg d2l0aCB0aGUgcHVibGljIGtleSBpbmZyYXN0cnVjdHVyZQ0KPiBzeXN0ZW0gYXMgZGVmaW5lZCBp biBXZWIgS2V5cyB0byBwcm92aWRlIGFuIGVhc3kgd2F5IGZvciBub2RlcyBvbiB0aGUNCj4gSW50 ZXJuZXQgdG8gdmVyaWZ5IHRoZWlyIGlkZW50aXR5IHRvIG90aGVyIG5vZGVzIG9uIHRoZSBJbnRl cm5ldC4NCj4gDQo+IFRoZSBmaXJzdCBkcmFmdCBvZiB0aGlzIHNwZWMgd2FzIGp1c3QgcHVibGlz aGVkIHZpYSB0aGUgSW50ZXJuZXQNCj4gRW5naW5lZXJpbmcgVGFzayBGb3JjZSAoSUVURikgZWFy bGllciB0b2RheToNCj4gDQo+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNhdmFn ZS1odHRwLXNpZ25hdHVyZXMtMDANCj4gDQo+IFlvdSBjYW4gYWxzbyBmaW5kIGEgZGF0ZXRpbWUt c3RhbXBlZCB2ZXJzaW9uIG9mIHRoZSBzcGVjIGhlcmU6DQo+IA0KPiBodHRwczovL3BheXN3YXJt LmNvbS9zcGVjcy9FRC9odHRwLXNpZ25hdHVyZXMvMjAxMy0wNS0wNC8NCj4gDQo+IFRoZSBsYXRl c3QgdmVyc2lvbiBvZiB0aGUgc3BlYyBjYW4gYmUgZm91bmQgb24gdGhlIFBheVN3YXJtIHNwZWNz IHBhZ2U6DQo+IA0KPiBodHRwczovL3BheXN3YXJtLmNvbS9zcGVjcy8NCj4gDQo+IC0tIG1hbnUN Cj4gDQo+IC0tDQo+IE1hbnUgU3Bvcm55IChza3lwZTogbXNwb3JueSwgdHdpdHRlcjogbWFudXNw b3JueSwgRys6ICtNYW51IFNwb3JueSkNCj4gRm91bmRlci9DRU8gLSBEaWdpdGFsIEJhemFhciwg SW5jLg0KPiBibG9nOiBNZXJpdG9yYSAtIFdlYiBwYXltZW50cyBjb21tZXJjaWFsIGxhdW5jaA0K PiBodHRwOi8vYmxvZy5tZXJpdG9yYS5jb20vbGF1bmNoLw0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBodHRwLWF1dGggbWFpbGluZyBsaXN0DQo+ IGh0dHAtYXV0aEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2h0dHAtYXV0aA0K From mark.cavage@joyent.com Mon May 13 10:02: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 1700321F91F1 for ; Mon, 13 May 2013 10:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 SNOT0IkIBXth for ; Mon, 13 May 2013 10:02:32 -0700 (PDT) Received: from mail-ia0-x236.google.com (mail-ia0-x236.google.com [IPv6:2607:f8b0:4001:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 2598721F90EE for ; Mon, 13 May 2013 10:02:31 -0700 (PDT) Received: by mail-ia0-f182.google.com with SMTP id z3so401795iad.13 for ; Mon, 13 May 2013 10:02:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=NW57AYhlJkP6Gc5mRy4Tygmq26/NjPNVvayqq6xaFzw=; b=lgjRzTtvfs9RyFrA7M1/59uWi7+pkY/hcxgr/pDbiZEgDJ9blTEdu1Cuqz5RT40/Na KXWpT9a67RiiJu7DaDboGwh4+KtstjnFbKa8SKwr7YUaQPnYVY/d9YBw9tarX8fDlrNH lOpYJOxFGKl+9bMVi8gvl7KHmD2vu9X7tz2G8Qc5vRtLDMeN6J9bI6AJElBZDFAk6UPf czGg3Nbbk+4S4IBuCC5wifnMXckCjO05LKPlX4L7CcuKZKHf4k7OSFQQ6oiAx7YCbVMb QQr72xROTSyJmR80sBLM6YrP6JM8Nr6j6kmLlOZc3BwK//PGStVx4+FGIBoCR3oS/Pas CDWg== MIME-Version: 1.0 X-Received: by 10.50.72.113 with SMTP id c17mr1831819igv.51.1368464551344; Mon, 13 May 2013 10:02:31 -0700 (PDT) Received: by 10.231.234.137 with HTTP; Mon, 13 May 2013 10:02:31 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1150D5134B8@WSMSG3153V.srv.dir.telstra.com> References: <518D3C8B.3080807@digitalbazaar.com> <255B9BB34FB7D647A506DC292726F6E1150D5134B8@WSMSG3153V.srv.dir.telstra.com> Date: Mon, 13 May 2013 10:02:31 -0700 Message-ID: From: Mark Cavage To: "Manger, James H" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnXFbb2zIAE3aJIf9I6VnAovctiaWjxVul8kpdPa8ZIn7eQjAVvR53XBOu85OIZ4b3a7u/2 Cc: HTTP Auth WG Subject: Re: [http-auth] First draft of HTTP Signatures published X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 17:02:33 -0000 Hi James, Thanks for the detailed feedback. Replies inline: > 1. > Content-Length in the example in section 2.1.2. "Signature String Constru= ction" should be 14, not 15. The content-MD5 value is calculated over 14 by= tes. Nice catch, thanks. > 2. > The string to be signed (section 2.1.2. "Signature String Construction") = looks like lines that could be sent in the HTTP request, but they don=92t q= uite match. Lines in an HTTP header end with \r\n, whereas lines in the str= ing to be signed end in \n. FWIW, I didn't do \r\n simply because most client libraries (and developers) understand '\n' as the default. So thinking of it from the perspective of the average SDK and engineer, it seemed easier on people to be only \n. That said, I'm not really willing to go to the mat for this one :), so if anybody else agrees \r\n is better, we can change it. > Why bother omitting \n from the last line? It is simpler to end all the l= ines the same way. It is annoyingly awkward to write files with a text edit= or that omit a final \n. Because in lots of dynamic languages this is what a "join" call does. I.e., in Javascript: ['a', 'b', 'c'].join('\n') produces 'a\nb\nc'. Nobody is going to create the canonicalized string with a text editor, they're going to do it with code. Again, I came at this with the perspective of "what's the easiest to write code for." This one I'm less convinced adding a trailing \n (or \r\n) makes anybody's life easier, simply because the semantics of "sort | join" code in almost every toolkit is to not have a trailing separator. > 3. > The signature is wrong in section 4.1. "Default Test". Unpacking the sign= ature reveals a SHA-256 hash of EBF002A95EC4DDB7A50CCAC009BAA2FE5D1B2604DA7= CB871B870CEE21BE85EB9. The SHA-256 has of "date: Thu, 05 Jan 2012 21:31:40 = GMT" is 1958B656C09E29824A2BCF03197923BCD9B55370F2FF2118FF4C47AD77513B3F. > 4. > The signature is wrong in section 4.2. "All Headers Test". Unpacking the = signature reveals a SHA-256 hash of 4E7A038BC9EFAB95AC829AC176659DCE0A7B6DC= 94F9FAA54375390A5EA8A9B37. The SHA-256 has of all the headers is 1015528C71= F9BC3D445B457CA41D8BC884E89275EDDD0F0435BBB13A65B4550D. Thanks, there was a rev of the spec based on a security vulnerability in the original original version, and the examples are still using the old strings. Will fix. > 5. > The fields that are signed are absolutely crucial in determining the secu= rity properties achieved. It is not sufficient for the spec to merely say t= he choice of fields is "out of scope" in a clause of the "Security Consider= ations" (section 3.5 "Required Headers to Sign"). > The introduction needs to state that: the mechanism signs a *subset* of a= n HTTP request; recipients need to be pre-configured with the subset they r= equire (and MUST confirm that "headers" includes at least that subset); the= body is only protected if a Content-MD5/Digest is signed (and the body has= h is checked). Signing just "date" show the originator committed to one HTT= P request at about the time of the date value, but gives no protection as t= o the nature of that request (the query params, path, method, body, or even= host etc). One strategy for recipients would be to only pass signed fields= on to the next stage of request processing. Yes agreed, we can crisp this up in both the introduction and security considerations, and add in some more examples with explanations of "policy choice" for the recipient. > > -- > James Manger > >> -----Original Message----- >> From: http-auth-bounces@ietf.org [mailto:http-auth-bounces@ietf.org] On >> Behalf Of Manu Sporny >> Sent: Saturday, 11 May 2013 4:30 AM >> To: HTTP Auth WG >> Subject: [http-auth] First draft of HTTP Signatures published >> >> The HTTP Signatures spec is a digital signature mechanism for the HTTP >> protocol. It adds origin authentication, message integrity, and replay >> resistance to HTTP requests. This is useful for any application that >> currently depends on Basic, Digest, OAuth, or OAuth2 authentication >> when performing RESTful HTTP calls. >> >> Basically, if a client needs to prove to a server that it sent an HTTP- >> based message, it can digitally sign that message. This spec defines >> exactly how that happens. >> >> This spec will be used by the Web Payments / PaySwarm / Web Keys work >> at W3C. We're going to combine the public/private key-based signature >> mechanism defined in HTTP Signatures with the public key infrastructure >> system as defined in Web Keys to provide an easy way for nodes on the >> Internet to verify their identity to other nodes on the Internet. >> >> The first draft of this spec was just published via the Internet >> Engineering Task Force (IETF) earlier today: >> >> http://tools.ietf.org/html/draft-cavage-http-signatures-00 >> >> You can also find a datetime-stamped version of the spec here: >> >> https://payswarm.com/specs/ED/http-signatures/2013-05-04/ >> >> The latest version of the spec can be found on the PaySwarm specs page: >> >> https://payswarm.com/specs/ >> >> -- manu >> >> -- >> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) >> Founder/CEO - Digital Bazaar, Inc. >> blog: Meritora - Web payments commercial launch >> http://blog.meritora.com/launch/ >> _______________________________________________ >> http-auth mailing list >> http-auth@ietf.org >> https://www.ietf.org/mailman/listinfo/http-auth > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth From murch@andrew.cmu.edu Mon May 13 10:09:52 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3F0621F9344 for ; Mon, 13 May 2013 10:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.185 X-Spam-Level: X-Spam-Status: No, score=-4.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] 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 zghqWBXlfy63 for ; Mon, 13 May 2013 10:09:48 -0700 (PDT) Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.11.61]) by ietfa.amsl.com (Postfix) with ESMTP id 94FF521F8DD0 for ; Mon, 13 May 2013 10:09:48 -0700 (PDT) Received: from [192.168.137.22] (cpe-76-180-197-142.buffalo.res.rr.com [76.180.197.142]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.14.4/8.14.4) with ESMTP id r4DH9kk1025881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 13 May 2013 13:09:46 -0400 Message-ID: <51911E5A.1000309@andrew.cmu.edu> Date: Mon, 13 May 2013 13:09:46 -0400 From: Ken Murchison Organization: Carnegie Mellon University User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130402 Thunderbird/17.0.5 MIME-Version: 1.0 To: Mark Cavage References: <518D3C8B.3080807@digitalbazaar.com> <255B9BB34FB7D647A506DC292726F6E1150D5134B8@WSMSG3153V.srv.dir.telstra.com> <31478_1368464556_r4DH2YHq000867_CAD4=_i4cCvYccigAR1eTaNRhLOWciPHfGO2OG+ahZEaouqhFow@mail.gmail.com> In-Reply-To: <31478_1368464556_r4DH2YHq000867_CAD4=_i4cCvYccigAR1eTaNRhLOWciPHfGO2OG+ahZEaouqhFow@mail.gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.18.170322 X-SMTP-Spam-Clean: 8% ( SUPERLONG_LINE 0.05, RDNS_GENERIC_POOLED 0, RDNS_POOLED 0, RDNS_RESIDENTIAL 0, RDNS_SUSP 0, RDNS_SUSP_GENERIC 0, RDNS_SUSP_SPECIFIC 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __PHISH_PHRASE1_E 0, __RDNS_POOLED_2 0, __SANE_MSGID 0, __STOCK_SYMBOL1 0, __STOCK_SYMBOL_X1 0, __TO_MALFORMED_2 0, __USER_AGENT 0) X-SMTP-Spam-Score: 8% X-Scanned-By: MIMEDefang 2.60 on 128.2.11.61 Cc: HTTP Auth WG Subject: Re: [http-auth] First draft of HTTP Signatures published X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 17:09:52 -0000 Hi Mark, I will second the suggestion made by Cyrus Daboo on this list a few weeks ago: > That draft is very similar to the approach we have used in iSchedule > () - > which is an HTTP-based calendar and scheduling messaging protocol. We > choose to re-use existing email signing technology - DKIM > () - primarily because the > security model and key management were a good fit for our application. > There is also the benefit of code re-use, and working with a protocol > that is already deployed and used heavily in the email environment. > Also, DKIM was designed with the prospect of being applicable to > protocols beyond email technology - and I think with iSchedule we have > proven it can work with HTTP. I would definitely urge you to take a > serious look at DKIM. There are a number of interesting features there > that don't seem to have been addressed in the draft you cited. In > particular dealing with both header and body canonicalization (headers > are particular problem in HTTP due to intermediaries, caches etc). On 05/13/2013 01:02 PM, Mark Cavage wrote: > Hi James, > > Thanks for the detailed feedback. Replies inline: > >> 1. >> Content-Length in the example in section 2.1.2. "Signature String Construction" should be 14, not 15. The content-MD5 value is calculated over 14 bytes. > Nice catch, thanks. > >> 2. >> The string to be signed (section 2.1.2. "Signature String Construction") looks like lines that could be sent in the HTTP request, but they don’t quite match. Lines in an HTTP header end with \r\n, whereas lines in the string to be signed end in \n. > FWIW, I didn't do \r\n simply because most client libraries (and > developers) understand '\n' as the default. So thinking of it from > the perspective of the average SDK and engineer, it seemed easier on > people to be only \n. That said, I'm not really willing to go to the > mat for this one :), so if anybody else agrees \r\n is better, we can > change it. > >> Why bother omitting \n from the last line? It is simpler to end all the lines the same way. It is annoyingly awkward to write files with a text editor that omit a final \n. > Because in lots of dynamic languages this is what a "join" call does. > I.e., in Javascript: ['a', 'b', 'c'].join('\n') produces 'a\nb\nc'. > Nobody is going to create the canonicalized string with a text editor, > they're going to do it with code. Again, I came at this with the > perspective of "what's the easiest to write code for." This one I'm > less convinced adding a trailing \n (or \r\n) makes anybody's life > easier, simply because the semantics of "sort | join" code in almost > every toolkit is to not have a trailing separator. > >> 3. >> The signature is wrong in section 4.1. "Default Test". Unpacking the signature reveals a SHA-256 hash of EBF002A95EC4DDB7A50CCAC009BAA2FE5D1B2604DA7CB871B870CEE21BE85EB9. The SHA-256 has of "date: Thu, 05 Jan 2012 21:31:40 GMT" is 1958B656C09E29824A2BCF03197923BCD9B55370F2FF2118FF4C47AD77513B3F. >> 4. >> The signature is wrong in section 4.2. "All Headers Test". Unpacking the signature reveals a SHA-256 hash of 4E7A038BC9EFAB95AC829AC176659DCE0A7B6DC94F9FAA54375390A5EA8A9B37. The SHA-256 has of all the headers is 1015528C71F9BC3D445B457CA41D8BC884E89275EDDD0F0435BBB13A65B4550D. > Thanks, there was a rev of the spec based on a security vulnerability > in the original original version, and the examples are still using the > old strings. Will fix. > >> 5. >> The fields that are signed are absolutely crucial in determining the security properties achieved. It is not sufficient for the spec to merely say the choice of fields is "out of scope" in a clause of the "Security Considerations" (section 3.5 "Required Headers to Sign"). >> The introduction needs to state that: the mechanism signs a *subset* of an HTTP request; recipients need to be pre-configured with the subset they require (and MUST confirm that "headers" includes at least that subset); the body is only protected if a Content-MD5/Digest is signed (and the body hash is checked). Signing just "date" show the originator committed to one HTTP request at about the time of the date value, but gives no protection as to the nature of that request (the query params, path, method, body, or even host etc). One strategy for recipients would be to only pass signed fields on to the next stage of request processing. > Yes agreed, we can crisp this up in both the introduction and security > considerations, and add in some more examples with explanations of > "policy choice" for the recipient. > > >> -- >> James Manger >> >>> -----Original Message----- >>> From:http-auth-bounces@ietf.org [mailto:http-auth-bounces@ietf.org] On >>> Behalf Of Manu Sporny >>> Sent: Saturday, 11 May 2013 4:30 AM >>> To: HTTP Auth WG >>> Subject: [http-auth] First draft of HTTP Signatures published >>> >>> The HTTP Signatures spec is a digital signature mechanism for the HTTP >>> protocol. It adds origin authentication, message integrity, and replay >>> resistance to HTTP requests. This is useful for any application that >>> currently depends on Basic, Digest, OAuth, or OAuth2 authentication >>> when performing RESTful HTTP calls. >>> >>> Basically, if a client needs to prove to a server that it sent an HTTP- >>> based message, it can digitally sign that message. This spec defines >>> exactly how that happens. >>> >>> This spec will be used by the Web Payments / PaySwarm / Web Keys work >>> at W3C. We're going to combine the public/private key-based signature >>> mechanism defined in HTTP Signatures with the public key infrastructure >>> system as defined in Web Keys to provide an easy way for nodes on the >>> Internet to verify their identity to other nodes on the Internet. >>> >>> The first draft of this spec was just published via the Internet >>> Engineering Task Force (IETF) earlier today: >>> >>> http://tools.ietf.org/html/draft-cavage-http-signatures-00 >>> >>> You can also find a datetime-stamped version of the spec here: >>> >>> https://payswarm.com/specs/ED/http-signatures/2013-05-04/ >>> >>> The latest version of the spec can be found on the PaySwarm specs page: >>> >>> https://payswarm.com/specs/ >>> >>> -- manu >>> >>> -- >>> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) >>> Founder/CEO - Digital Bazaar, Inc. >>> blog: Meritora - Web payments commercial launch >>> http://blog.meritora.com/launch/ >>> _______________________________________________ >>> http-auth mailing list >>> http-auth@ietf.org >>> https://www.ietf.org/mailman/listinfo/http-auth >> _______________________________________________ >> http-auth mailing list >> http-auth@ietf.org >> https://www.ietf.org/mailman/listinfo/http-auth > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University From internet-drafts@ietf.org Tue May 14 11:27:24 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 8FBAB11E8106; Tue, 14 May 2013 11:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.444 X-Spam-Level: X-Spam-Status: No, score=-102.444 tagged_above=-999 required=5 tests=[AWL=0.156, 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 FvBFQngp9bDy; Tue, 14 May 2013 11:27:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4946511E8102; Tue, 14 May 2013 11:27:16 -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.44.p7 Message-ID: <20130514182628.24312.62987.idtracker@ietfa.amsl.com> Date: Tue, 14 May 2013 11:26:30 -0700 X-Mailman-Approved-At: Tue, 14 May 2013 11:28:27 -0700 Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-hoba-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: Tue, 14 May 2013 18:27:24 -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 : HTTP Origin-Bound Authentication (HOBA) Author(s) : Stephen Farrell Paul Hoffman Michael Thomas Filename : draft-ietf-httpauth-hoba-00.txt Pages : 23 Date : 2013-05-14 Abstract: HTTP Origin-Bound Authentication (HOBA) is a design for an HTTP authentication method with credentials that are not vulnerable to phishing attacks, and that does not require a server-side password database. The design can also be used in Javascript-based authentication embedded in HTML. HOBA is an alternative to HTTP authentication schemes that require passwords with all the negative attributes that come with password-based systems. HOBA can be integrated with account management and other applications running over HTTP and supports portability, so a user can associate more than one device or origin-bound key with the same service. We also describe a way in which the HOBA design can be used from a Javascript web client. When deployed, HOBA will be a drop-in replacement for password-based HTTP authentication or JavaScript authentication. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-httpauth-hoba-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From stephen.farrell@cs.tcd.ie Tue May 14 11:35:35 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C156521F850B for ; Tue, 14 May 2013 11:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.224 X-Spam-Level: X-Spam-Status: No, score=-102.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, 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 1ykhywm8kpKi for ; Tue, 14 May 2013 11:35:29 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 97B5F21F8503 for ; Tue, 14 May 2013 11:35:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8B9E1BE6F for ; Tue, 14 May 2013 19:35:07 +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 Vc2bGKmXTz1X for ; Tue, 14 May 2013 19:35:02 +0100 (IST) Received: from [10.87.48.11] (unknown [86.44.76.96]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4DF92BE76 for ; Tue, 14 May 2013 19:35:02 +0100 (IST) Message-ID: <519283D6.9080006@cs.tcd.ie> Date: Tue, 14 May 2013 19:35:02 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130404 Thunderbird/17.0.5 MIME-Version: 1.0 To: http-auth@ietf.org References: <20130514182628.24312.62987.idtracker@ietfa.amsl.com> In-Reply-To: <20130514182628.24312.62987.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-hoba-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: Tue, 14 May 2013 18:35:36 -0000 Hi all, As you can see we've just posted the wg-00 version of the HOBA draft. Not too many changes for now, mostly some more detail of the signature and registration processes - we've tried to make it easy enough do diff this vs. the independent draft. Comments welcome, as always, in particular about the basic signature scheme. We'd most particularly welcome if someone could point us at a 20+ year old signed challenge one-way user authentication scheme with good security analyses. I'm sure there're some in the literature and I did find one that's almost a perfect match but I bet there's better. I'll send a mail later with some thoughts on hoba and draft-cavage-http-signatures. Cheers, S. On 05/14/2013 07:26 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Hypertext Transfer Protocol Authentication Working Group of the IETF. > > Title : HTTP Origin-Bound Authentication (HOBA) > Author(s) : Stephen Farrell > Paul Hoffman > Michael Thomas > Filename : draft-ietf-httpauth-hoba-00.txt > Pages : 23 > Date : 2013-05-14 > > Abstract: > HTTP Origin-Bound Authentication (HOBA) is a design for an HTTP > authentication method with credentials that are not vulnerable to > phishing attacks, and that does not require a server-side password > database. The design can also be used in Javascript-based > authentication embedded in HTML. HOBA is an alternative to HTTP > authentication schemes that require passwords with all the negative > attributes that come with password-based systems. HOBA can be > integrated with account management and other applications running > over HTTP and supports portability, so a user can associate more than > one device or origin-bound key with the same service. We also > describe a way in which the HOBA design can be used from a Javascript > web client. When deployed, HOBA will be a drop-in replacement for > password-based HTTP authentication or JavaScript authentication. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-httpauth-hoba-00 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > > From stephen.farrell@cs.tcd.ie Tue May 14 12:14:41 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 E577321F852A for ; Tue, 14 May 2013 12:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 IB1ZcOHwQYz7 for ; Tue, 14 May 2013 12:14:36 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 1011221F919D for ; Tue, 14 May 2013 12:14:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 63308BE9C for ; Tue, 14 May 2013 20:14:04 +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 gOpNowkukO4q for ; Tue, 14 May 2013 20:14:02 +0100 (IST) Received: from [10.87.48.11] (unknown [86.44.76.96]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 93082BE9F for ; Tue, 14 May 2013 20:14:02 +0100 (IST) Message-ID: <51928CF5.2020303@cs.tcd.ie> Date: Tue, 14 May 2013 20:13:57 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130404 Thunderbird/17.0.5 MIME-Version: 1.0 To: "http-auth@ietf.org" X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [http-auth] HOBA and draft-cavage signatures 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, 14 May 2013 19:14:41 -0000 Hi, So these two have a lot in common, but are in the end are a good bit different I think. Sufficiently different that they probably ought live separate lives as drafts probably, but maybe with bits in common. The common things:- - HTTP Authentication schemes - Both based on digital signatures for user authentication - Similar or could-be-the-same syntax in lots of places which does offer the possibility of some library/code re-use that might help both But there are very significant differences: #1 - HOBA aims to displace passwords and no more - draft-cavage wants to authenticate the user for payments as its main use-case #2 = HOBA doesn't try to authenticate other parts of the HTTP request (we'll probably in -01 allow TLS channel bindings but that's not the same) = draft-cavage does include other headers in the signature to authenticate those, possibly ultimately in a DKIM-like manner #3 * HOBA has a key-pair-per-web-origin, at least as a default, with no HOBA-defined linkage between the public key and any identifier with well-defined semantics (applications can do that) * draft-cavage I think wants just one or a few key pairs per user and probably with some well-defined semantics for identities associated with keys #4 - HOBA has a built-in use of .well-known/hoba for registration etc. - draft-cavage has very similar stuff in another spec but can't remember where that is:-) Other notes: - "Signature" as an HTTP authentication scheme seems way too broad - its hard to believe draft-cavage will be the only such ever (that's why I keep calling it draft-cavage above:-) - I hate the idea that the same scheme supports both digital signatures and HMAC for user authentication - I think that's a bad error - just define two HTTP auth schemes if you really see a need for HMAC, or use the updated Digest that this WG is chartered to develop - encouraging more password verifier databases is just a bad plan (with all due respect to the other proposals this wg will develop:-) - HOBA has this "demo of how to do hoba-js" aspect which isn't part of draft-cavage, us HOBA authors really like that:-) Overall, I think (not very confidently, very much open to chatting about it), were folks willing, it'd make sense to try define common syntax and signature mechanism processing for these but to progress them as separate HTTP authentication schemes that both happen to use the digital signature mechanism but for sufficiently different use-cases and security services that they're better kept apart. I'd be fine with this WG doing the work on draft-cavage if that made sense. To get an HTTP authentication scheme registered draft-cavage will have to pass IETF review in any case, as that's the rule the httpbis WG have set for new entries in that IANA registry. [1] So its not clear that taking the W3C REC route will save the dravt-cavage proponents much time, as their request for an IANA code point will end up back here anyway. (Doing stuff in one SDO is slow. Adding a 2nd SDO is a fine way to make treacle look speedy:-) But as I say, that's all fairly tentative so I wonder what others think. Cheers, S. [1] http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-22#section-2.3 From James.H.Manger@team.telstra.com Thu May 16 06:29:32 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 CCCE721F912C for ; Thu, 16 May 2013 06:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.399 X-Spam-Level: X-Spam-Status: No, score=0.399 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] 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 AFHd4lfHdPVi for ; Thu, 16 May 2013 06:29:27 -0700 (PDT) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id 5966E21F8F0F for ; Thu, 16 May 2013 06:29:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,683,1363093200"; d="scan'208";a="137672291" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipoani.tcif.telstra.com.au with ESMTP; 16 May 2013 23:29:26 +1000 X-IronPort-AV: E=McAfee;i="5400,1158,7076"; a="133981744" Received: from wsmsg3755.srv.dir.telstra.com ([172.49.40.196]) by ipcbni.tcif.telstra.com.au with ESMTP; 16 May 2013 23:29:26 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3755.srv.dir.telstra.com ([172.49.40.196]) with mapi; Thu, 16 May 2013 23:29:26 +1000 From: "Manger, James H" To: Stephen Farrell , "http-auth@ietf.org" Date: Thu, 16 May 2013 23:29:24 +1000 Thread-Topic: HOBA: registration & user interaction Thread-Index: Ac5Q0dcqyk8r7+bvRW2HY6VMMm6pUwBMoq4g Message-ID: <255B9BB34FB7D647A506DC292726F6E11519C45C85@WSMSG3153V.srv.dir.telstra.com> References: <20130514182628.24312.62987.idtracker@ietfa.amsl.com> <519283D6.9080006@cs.tcd.ie> In-Reply-To: <519283D6.9080006@cs.tcd.ie> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [http-auth] HOBA: registration & user interaction 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, 16 May 2013 13:29:32 -0000 SeKAmW0gbm90IHF1aXRlIHN1cmUgaG93IHJlZ2lzdHJhdGlvbiBhbmQgdXNlciBpbnRlcmFjdGlv biBpcyBpbnRlbmRlZCB0byB3b3JrIGluIEhPQkEtaHR0cCBbZHJhZnQtaWV0Zi1odHRwYXV0aC1o b2JhLTAwXS4NCg0KVGhlIGNvcmUgSE9CQS1odHRwIGludGVyYWN0aW9uIGxvb2tzIHNpbXBsZSBl bm91Z2g6DQoxKSBjbGllbnQgbWFrZXMgYSByZXF1ZXN0Ow0KMikgc2VydmVyIHdhbnRpbmcgYXV0 aGVudGljYXRpb24gcmVzcG9uZHMgd2l0aCBhIDQwMSB0aGF0IGluY2x1ZGVzICJXV1ctQXV0aGVu dGljYXRlOiBIT0JBIGNoYWxsZW5nZT0uLi4iOw0KMykgY2xpZW50IHJlLXRyaWVzIHRoZSByZXF1 ZXN0IHdpdGggIkF1dGhvcml6YXRpb246IEhPQkEgcmVzdWx0PWtpZC5jaGFsbGVuZ2Uubm9uY2Uu c2lnIjsNCjQpIHNlcnZlciB2ZXJpZmllcyB0aGUgc2lnbmF0dXJlIHVzaW5nIHRoZSBjbGllbnTi gJlzIHB1YmxpYyBrZXkuDQoNClRoZSBjb3JlIGludGVyYWN0aW9uIG9ubHkgd29ya3MgaWYgdGhl IHNlcnZlciBhbHJlYWR5IGhhcyB0aGUgY2xpZW504oCZcyBwdWJsaWMga2V5LiBUaGUgY2xpZW50 IGNhbiByZWdpc3RlciBhIHB1YmxpYyBrZXkgYnkgUE9TVGluZyBpdCB0byBodHRwczovL29yaWdp bi8ud2VsbC1rbm93bi9ob2JhL3JlZ2lzdGVyLiBJdCBsb29rcyBsaWtlIHRoaXMgcmVnaXN0cmF0 aW9uIGhhcyB0byBvY2N1ciB0aGUgZmlyc3QgdGltZSB0aGUgY2xpZW50IGdldHMgYSAiV1dXLUF1 dGhlbnRpY2F0ZTogSE9CQSIgcmVzcG9uc2UgZnJvbSB0aGUgc2VydmVyOiBiZXR3ZWVuIHN0ZXBz IDIgJiAzIGFib3ZlLg0KDQpUaGUgc3BlYyBpbXBsaWVzIHRoYXQgdGhlIHNlcnZlciBkZWNpZGVz IHdoYXQgc29ydCBvZiB1c2VyIGludGVyYWN0aW9uIHJlc3VsdHMgZnJvbSB0aGUgcmVnaXN0cmF0 aW9uIFBPU1QuIFBlcmhhcHMgYSBzZXJ2ZXIgd291bGQgcmV0dXJuIGFuIEhUTUwgZm9ybSBwcm9t cHRpbmcgZm9yIGEgbmFtZSBhbmQgZW1haWwgYWRkcmVzcyB0byBnbyB3aXRoIHRoZSBuZXcgYWNj b3VudCwgZm9yIGluc3RhbmNlLg0KDQpJJ20gbm90IHN1cmUgaG93IHRoZSBjbGllbnQgY2FuIHRl bGwgd2hlbiB0aGUgcmVnaXN0cmF0aW9uIGludGVyYWN0aW9uIGlzIG92ZXIgKHNvIGl0IGNhbiBn byBiYWNrIHRvIHJldHJ5aW5nIHRoZSBvcmlnaW5hbCByZXF1ZXN0IGF0IHN0ZXAgMyBhYm92ZSku IEluIGEgdXNlci1hdC1hLWJyb3dzZXIgc2l0dWF0aW9uLCBzaG91bGQgdGhlIHJlZ2lzdHJhdGlv biBQT1NUIGJlIGVmZmVjdGl2ZWx5IG1hZGUgaW4gYSBwb3B1cCB3aW5kb3cgb3IgdGhlIG1haW4g d2luZG93PyBXaGF0IGlmIHRoZSA0MDEgdHJpZ2dlcmluZyB0aGUgcmVnaXN0cmF0aW9uIHdhc27i gJl0IGEgcmVxdWVzdCBmb3IgYSBuZXcgSFRNTCBwYWdlLCBidXQgYSBsaW5rZWQgaW1hZ2UgZm9y IGluc3RhbmNlPw0KDQpUaGUgcHJvYmxlbSBpcyB0aGF0IHRoZSBzZXJ2ZXIgY2Fubm90IHRlbGwg aWYgdXNlciBpbnRlcmFjdGlvbiBpcyBhcHByb3ByaWF0ZSBhdCB0aGlzIHBvaW50LiBQcmVzdW1h Ymx5IGEgd2hvbGUgcmFuZ2Ugb2YgY2xpZW50IHJlcXVlc3RzIGNhbiByZXN1bHQgaW4gYSA0MDEs IGFueSBvZiB3aGljaCBjb3VsZCBoYXZlIHRyaWdnZXJlZCB0aGUgcmVnaXN0cmF0aW9uLiBUaGUg Y2xpZW50IG1pZ2h0IG5vdCBldmVuIGJlIGEgdXNlciBhdCBhIGJyb3dzZXIuDQoNCg0KV291bGQg YSBiZXR0ZXIgYXBwcm9hY2ggZm9yIEhPQkEtaHR0cCBiZSB0byBpbmNsdWRlIHRoZSBwdWJsaWMg a2V5IChhbmQgZGV2aWNlIGlkKSBpbiB0aGUgIkF1dGhvcml6YXRpb246IEhPQkEiIHJlc3BvbnNl IGlmIGEgbmV3IGtleSBwYWlyIGhhcyBqdXN0IGJlZW4gY3JlYXRlZD8gSWYgc29tZSB1c2VyIGlu dGVyYWN0aW9uIGlzIHJlcXVpcmVkIHRoZSBzZXJ2ZXIgaGFzIHRvIHdvcmsgb3V0IGhvdyB0aGF0 IGhhcHBlbnMuIFBlcmhhcHMgYW5vdGhlciA0MDEgaXMgcmV0dXJuZWQsIGJ1dCB0aGlzIHRpbWUg d2l0aCBhbiBIVE1MIGZvcm0gYXMgdGhlIHJlc3BvbnNlIGJvZHkgKGFuZCBubyAiV1dXLUF1dGhl bnRpY2F0ZSIgaGVhZGVyKS4NCg0KLS0NCkphbWVzIE1hbmdlcg0KDQoNCj4gT24gMDUvMTQvMjAx MyAwNzoyNiBQTSwgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIHdyb3RlOg0KPiA+DQo+ID4gCVRp dGxlICAgICAgICAgICA6IEhUVFAgT3JpZ2luLUJvdW5kIEF1dGhlbnRpY2F0aW9uIChIT0JBKQ0K PiA+IAlBdXRob3IocykgICAgICAgOiBTdGVwaGVuIEZhcnJlbGwNCj4gPiAgICAgICAgICAgICAg ICAgICAgICAgICAgIFBhdWwgSG9mZm1hbg0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAg TWljaGFlbCBUaG9tYXMNCj4gPiAJRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1odHRwYXV0 aC1ob2JhLTAwLnR4dA0KPiA+IAlQYWdlcyAgICAgICAgICAgOiAyMw0KPiA+IAlEYXRlICAgICAg ICAgICAgOiAyMDEzLTA1LTE0DQo+ID4NCj4gPiBBYnN0cmFjdDoNCj4gPiAgICBIVFRQIE9yaWdp bi1Cb3VuZCBBdXRoZW50aWNhdGlvbiAoSE9CQSkgaXMgYSBkZXNpZ24gZm9yIGFuIEhUVFANCj4g PiAgICBhdXRoZW50aWNhdGlvbiBtZXRob2Qgd2l0aCBjcmVkZW50aWFscyB0aGF0IGFyZSBub3Qg dnVsbmVyYWJsZSB0bw0KPiA+ICAgIHBoaXNoaW5nIGF0dGFja3MsIGFuZCB0aGF0IGRvZXMgbm90 IHJlcXVpcmUgYSBzZXJ2ZXItc2lkZSBwYXNzd29yZA0KPiA+ICAgIGRhdGFiYXNlLiAgVGhlIGRl c2lnbiBjYW4gYWxzbyBiZSB1c2VkIGluIEphdmFzY3JpcHQtYmFzZWQNCj4gPiAgICBhdXRoZW50 aWNhdGlvbiBlbWJlZGRlZCBpbiBIVE1MLiAgSE9CQSBpcyBhbiBhbHRlcm5hdGl2ZSB0byBIVFRQ DQo+ID4gICAgYXV0aGVudGljYXRpb24gc2NoZW1lcyB0aGF0IHJlcXVpcmUgcGFzc3dvcmRzIHdp dGggYWxsIHRoZSBuZWdhdGl2ZQ0KPiA+ICAgIGF0dHJpYnV0ZXMgdGhhdCBjb21lIHdpdGggcGFz c3dvcmQtYmFzZWQgc3lzdGVtcy4gIEhPQkEgY2FuIGJlDQo+ID4gICAgaW50ZWdyYXRlZCB3aXRo IGFjY291bnQgbWFuYWdlbWVudCBhbmQgb3RoZXIgYXBwbGljYXRpb25zIHJ1bm5pbmcNCj4gPiAg ICBvdmVyIEhUVFAgYW5kIHN1cHBvcnRzIHBvcnRhYmlsaXR5LCBzbyBhIHVzZXIgY2FuIGFzc29j aWF0ZSBtb3JlIHRoYW4NCj4gPiAgICBvbmUgZGV2aWNlIG9yIG9yaWdpbi1ib3VuZCBrZXkgd2l0 aCB0aGUgc2FtZSBzZXJ2aWNlLiAgV2UgYWxzbw0KPiA+ICAgIGRlc2NyaWJlIGEgd2F5IGluIHdo aWNoIHRoZSBIT0JBIGRlc2lnbiBjYW4gYmUgdXNlZCBmcm9tIGEgSmF2YXNjcmlwdA0KPiA+ICAg IHdlYiBjbGllbnQuICBXaGVuIGRlcGxveWVkLCBIT0JBIHdpbGwgYmUgYSBkcm9wLWluIHJlcGxh Y2VtZW50IGZvcg0KPiA+ICAgIHBhc3N3b3JkLWJhc2VkIEhUVFAgYXV0aGVudGljYXRpb24gb3Ig SmF2YVNjcmlwdCBhdXRoZW50aWNhdGlvbi4NCj4gPg0KPiA+IGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtaHR0cGF1dGgtaG9iYS0wMA0K From hallam@gmail.com Thu May 16 07:04: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 C9E3221F9344 for ; Thu, 16 May 2013 07:04:55 -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 Tvl+qHyoqMO5 for ; Thu, 16 May 2013 07:04:55 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 0640F21F92EC for ; Thu, 16 May 2013 07:04:54 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id hr14so6280398wib.15 for ; Thu, 16 May 2013 07:04:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=cmDK7pzfZxfVZX8hh0H5zdn3jQHAMvLKQMSaOeLXLwg=; b=za0koRDOTu0tmd92fVGK1t8KumR3yOG7L4RGl/RMLDbWCGXd3GcNNyV4tDn39Em63O iMEYmGcEM5mWu13fJ/nwjBEDS/X4giiVKpHFvlpJYCoclSFzR5sY2IWWZcTLIUNZSoeU ZPUmwLeSglY5KHUAEYbASyvdEuV9WDb3n2TDJZIrfHqCeKJOJVpfIpGDLfqwpfxo2NRV AncsknQYQnbR+v8IH3li56WJMqJlv9f4e/mNaDAaYTA3VV3JYacvMdrDprPcAJTm/vDu CyZgEC9OHU/1SaKmwTPs0d59XHseIK5c1mfofVkkTb9sQuoUoDVd0ioykJGtBRsJDrSV f3JA== MIME-Version: 1.0 X-Received: by 10.180.212.3 with SMTP id ng3mr25056258wic.22.1368712632037; Thu, 16 May 2013 06:57:12 -0700 (PDT) Received: by 10.194.162.8 with HTTP; Thu, 16 May 2013 06:57:11 -0700 (PDT) In-Reply-To: <51911E5A.1000309@andrew.cmu.edu> References: <518D3C8B.3080807@digitalbazaar.com> <255B9BB34FB7D647A506DC292726F6E1150D5134B8@WSMSG3153V.srv.dir.telstra.com> <31478_1368464556_r4DH2YHq000867_CAD4=_i4cCvYccigAR1eTaNRhLOWciPHfGO2OG+ahZEaouqhFow@mail.gmail.com> <51911E5A.1000309@andrew.cmu.edu> Date: Thu, 16 May 2013 09:57:11 -0400 Message-ID: From: Phillip Hallam-Baker To: Ken Murchison Content-Type: multipart/alternative; boundary=001a11c356f43b77a404dcd63ece Cc: HTTP Auth WG Subject: Re: [http-auth] First draft of HTTP Signatures published 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, 16 May 2013 14:04:56 -0000 --001a11c356f43b77a404dcd63ece Content-Type: text/plain; charset=ISO-8859-1 HTTP Session Continuation is a separate spec but I would like to share as much as possible between them. http://www.ietf.org/id/draft-hallambaker-httpsession-01.txt Early versions of the session continuation mechanism included header signing. That is a real headache. The only way that I think it can be made to work reliably is to duplicate the information that you want to sign into the signing header which is the approach in DKIM. For HTTP transactions, the only headers that I think should ever be signed are content meta-data. The reason signing is hard in SMTP and HTTP is that there is a huge confusion between headers used for routing and headers that are properly part of the content. This is perhaps a change that could be made in HTTP/2. You will find a lot of objections being made of the form 'this will break when intermediaries change content'. And they will continue to be made no matter how many times you point out that detecting changes to the content and rejecting that transaction is the whole objective. So there will need to be some statement to the effect that the intended behavior is to prevent all types of content modification. We don't yet know what the effect of intermediaries is on the request line and I suspect that as we get into tests we are going to discover that we have to do some form of canonicalization. For example, I strongly suspect that we are going to want to combine the Host-Name header and http method into the request line to make it a canonical url. --001a11c356f43b77a404dcd63ece Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
HTTP Session Continuation is a separate spec bu= t I would like to share as much as possible between them.

http://www.ietf.org/id/draft-hallambaker-httpsession-01.txt

Early versions of the session continuation mechan= ism included header signing. That is a real headache. The only way that I t= hink it can be made to work reliably is to duplicate the information that y= ou want to sign into the signing header which is the approach in DKIM.

For HTTP transactions, the only headers tha= t I think should ever be signed are content meta-data. The reason signing i= s hard in SMTP and HTTP is that there is a huge confusion between headers u= sed for routing and headers that are properly part of the content. This is = perhaps a change that could be made in HTTP/2.

You will find a lot of objections being mad= e of the form 'this will break when intermediaries change content'.= And they will continue to be made no matter how many times you point out t= hat detecting changes to the content and rejecting that transaction is the = whole objective. So there will need to be some statement to the effect that= the intended behavior is to prevent all types of content modification.

We don't yet know what the effect of in= termediaries is on the request line and I suspect that as we get into tests= we are going to discover that we have to do some form of canonicalization.= For example, I strongly suspect that we are going to want to combine the H= ost-Name header and http method into the request line to make it a canonica= l url.
--001a11c356f43b77a404dcd63ece-- From stephen.farrell@cs.tcd.ie Thu May 16 07:22:35 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C71A021F8F32 for ; Thu, 16 May 2013 07:22:35 -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 c-UCkkwy56+F for ; Thu, 16 May 2013 07:22:31 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA2E21F8F0F for ; Thu, 16 May 2013 07:22:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 58E57BE39; Thu, 16 May 2013 15:22:00 +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 nuGoJFanPoZ7; Thu, 16 May 2013 15:22:00 +0100 (IST) Received: from [IPv6:2001:770:10:203:8817:4171:3211:7ab] (unknown [IPv6:2001:770:10:203:8817:4171:3211:7ab]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 395B8BE25; Thu, 16 May 2013 15:22:00 +0100 (IST) Message-ID: <5194EB87.1050706@cs.tcd.ie> Date: Thu, 16 May 2013 15:21:59 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Manger, James H" References: <20130514182628.24312.62987.idtracker@ietfa.amsl.com> <519283D6.9080006@cs.tcd.ie> <255B9BB34FB7D647A506DC292726F6E11519C45C85@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E11519C45C85@WSMSG3153V.srv.dir.telstra.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: "http-auth@ietf.org" Subject: Re: [http-auth] HOBA: registration & user interaction 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, 16 May 2013 14:22:35 -0000 Hi James, Good questions as always, thanks. On 05/16/2013 02:29 PM, Manger, James H wrote: > I’m not quite sure how registration and user interaction is intended to work in HOBA-http [draft-ietf-httpauth-hoba-00]. > > The core HOBA-http interaction looks simple enough: > 1) client makes a request; > 2) server wanting authentication responds with a 401 that includes "WWW-Authenticate: HOBA challenge=..."; > 3) client re-tries the request with "Authorization: HOBA result=kid.challenge.nonce.sig"; > 4) server verifies the signature using the client’s public key. > > The core interaction only works if the server already has the client’s public key. The client can register a public key by POSTing it to https://origin/.well-known/hoba/register. It looks like this registration has to occur the first time the client gets a "WWW-Authenticate: HOBA" response from the server: between steps 2 & 3 above. > > The spec implies that the server decides what sort of user interaction results from the registration POST. Perhaps a server would return an HTML form prompting for a name and email address to go with the new account, for instance. > > I'm not sure how the client can tell when the registration interaction is over (so it can go back to retrying the original request at step 3 above). In a user-at-a-browser situation, should the registration POST be effectively made in a popup window or the main window? What if the 401 triggering the registration wasn’t a request for a new HTML page, but a linked image for instance? To be honest, me neither:-) I've some code for the basic crypto but haven't tried any UI stuff so far. What I was thinking of was the the WWW-Authenticate with the signature will also be part of the register POST message, since the UA is responding to a 401. In that case the server gets everything it needs and can remember the key and that the signature was ok as it pushes the user through the registration process. Once the server is happy with that it can set cookies or whatever. And next time the UA comes back it should be ok or not as the server desires. That'll also need to work as well if the user hits some "register" button on the page before ever seeing a 401. I suspect that the server would have to feed a 401 to the UA at that point and then we go from there. > The problem is that the server cannot tell if user interaction is appropriate at this point. Presumably a whole range of client requests can result in a 401, any of which could have triggered the registration. The client might not even be a user at a browser. Yep. Mike brought that up too the other day in an offlist mail. I guess there'll be all sorts of similar web things with starting off inside a frame etc. none of which I know much about. OTOH, its all under the server's control so should be easy enough if you design a site with this in mind. But we probably need to do better - to make it easy to integrate with a site that's previously been using Basic or web forms with passwords. > Would a better approach for HOBA-http be to include the public key (and device id) in the "Authorization: HOBA" response if a new key pair has just been created? If some user interaction is required the server has to work out how that happens. Perhaps another 401 is returned, but this time with an HTML form as the response body (and no "WWW-Authenticate" header). Certainly worth a look. Not sure if we'd start to hit problems with headers being too long or not though esp. for longer RSA moduli. So at this point I don't have answers. But I'd sure welcome suggestions and am happy to try 'em out as my code develops and report back. Cheers, S. > > -- > James Manger > > >> On 05/14/2013 07:26 PM, internet-drafts@ietf.org wrote: >>> >>> Title : HTTP Origin-Bound Authentication (HOBA) >>> Author(s) : Stephen Farrell >>> Paul Hoffman >>> Michael Thomas >>> Filename : draft-ietf-httpauth-hoba-00.txt >>> Pages : 23 >>> Date : 2013-05-14 >>> >>> Abstract: >>> HTTP Origin-Bound Authentication (HOBA) is a design for an HTTP >>> authentication method with credentials that are not vulnerable to >>> phishing attacks, and that does not require a server-side password >>> database. The design can also be used in Javascript-based >>> authentication embedded in HTML. HOBA is an alternative to HTTP >>> authentication schemes that require passwords with all the negative >>> attributes that come with password-based systems. HOBA can be >>> integrated with account management and other applications running >>> over HTTP and supports portability, so a user can associate more than >>> one device or origin-bound key with the same service. We also >>> describe a way in which the HOBA design can be used from a Javascript >>> web client. When deployed, HOBA will be a drop-in replacement for >>> password-based HTTP authentication or JavaScript authentication. >>> >>> http://tools.ietf.org/html/draft-ietf-httpauth-hoba-00 From stephen.farrell@cs.tcd.ie Thu May 16 07:28:08 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 4E2D921F8EDA for ; Thu, 16 May 2013 07:28:08 -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 lOXWBfHUlcqV for ; Thu, 16 May 2013 07:28:01 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 107D521F90B3 for ; Thu, 16 May 2013 07:27:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 669F2BE56 for ; Thu, 16 May 2013 15:27:37 +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 QgHt+3n-yqjU for ; Thu, 16 May 2013 15:27:37 +0100 (IST) Received: from [IPv6:2001:770:10:203:8817:4171:3211:7ab] (unknown [IPv6:2001:770:10:203:8817:4171:3211:7ab]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 49A31BE4C for ; Thu, 16 May 2013 15:27:37 +0100 (IST) Message-ID: <5194ECD8.7060604@cs.tcd.ie> Date: Thu, 16 May 2013 15:27:36 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: "http-auth@ietf.org" References: <20130514182628.24312.62987.idtracker@ietfa.amsl.com> <519283D6.9080006@cs.tcd.ie> <255B9BB34FB7D647A506DC292726F6E11519C45C85@WSMSG3153V.srv.dir.telstra.com> <5194EB87.1050706@cs.tcd.ie> In-Reply-To: <5194EB87.1050706@cs.tcd.ie> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [http-auth] HOBA: registration & user interaction 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, 16 May 2013 14:28:08 -0000 On 05/16/2013 03:21 PM, Stephen Farrell wrote: > What I was thinking of was the the WWW-Authenticate with > the signature will also be part of the register POST message, > since the UA is responding to a 401. Oops - s/WWW-Authenticate/Authorization/ above sorry;-) S. From mcr@sandelman.ca Thu May 16 07:39: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 D8E0221F90FC for ; Thu, 16 May 2013 07:39: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 PH8d+cM+xBBT for ; Thu, 16 May 2013 07:39:54 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.252.184]) by ietfa.amsl.com (Postfix) with ESMTP id B476E21F8D71 for ; Thu, 16 May 2013 07:39:54 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id B8FDC2016E; Thu, 16 May 2013 10:51:38 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 5D00863A7E; Thu, 16 May 2013 10:39:13 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 4CE5063A5E; Thu, 16 May 2013 10:39:13 -0400 (EDT) From: Michael Richardson To: Phillip Hallam-Baker In-Reply-To: References: <518D3C8B.3080807@digitalbazaar.com> <255B9BB34FB7D647A506DC292726F6E1150D5134B8@WSMSG3153V.srv.dir.telstra.com> <31478_1368464556_r4DH2YHq000867_CAD4=_i4cCvYccigAR1eTaNRhLOWciPHfGO2OG+ahZEaouqhFow@mail.gmail.com> <51911E5A.1000309@andrew.cmu.edu> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) 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 WG Subject: Re: [http-auth] First draft of HTTP Signatures published 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, 16 May 2013 14:40:00 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Phillip" =3D=3D Phillip Hallam-Baker writes: Phillip> You will find a lot of objections being made of the form 'this= will break Phillip> when intermediaries change content'. And they will continue to= be made no Phillip> matter how many times you point out that detecting changes to = the content Phillip> and rejecting that transaction is the whole objective. So ther= e will need Phillip> to be some statement to the effect that the intended Phillip> behavior is to prevent=20 Phillip> all types of content modification. And maybe we need to provide a way for intermediaries to signal their existence, and for a transitive (but decentralized) trust model to permit their inclusion. My impression is that this has worked well in SIP, although I am aware that it has also thwarted S/MIME-type security solutions in SIP. Phillip> We don't yet know what the effect of intermediaries is on the = request line Phillip> and I suspect that as we get into tests we are going to discov= er that we Phillip> have to do some form of canonicalization. For example, I stron= gly suspect Phillip> that we are going to want to combine the Host-Name header and = http method Phillip> into the request line to make it a canonical url. "http method", as in GET/PUT/POST/DELETE? (Just asking for clarification) =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUZTvkYqHRg3pndX9AQK9/QQAw5XG9h/Qo5+Qu14ezMMbJPNxHZ0tvnFe nKa500UAEGxyiF9kMYIjI1Q5pA8Bw1LfDcU0jI9Jt91b2xz/wZqXMpLJgMVKXrWo Q9A1558+WC7/P0/XuQRtZx22+Hm6jefTv1HkAa/IyTGpGNagCYKK85Fxie8shO/l glC3n1oOcCU= =OAVw -----END PGP SIGNATURE----- --=-=-=-- From hallam@gmail.com Thu May 16 08:00:02 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 860BF21F8FFA for ; Thu, 16 May 2013 08:00:02 -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, 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 43DRoPQvDR+R for ; Thu, 16 May 2013 08:00:01 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF2521F8FEB for ; Thu, 16 May 2013 08:00:01 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id hr14so2811690wib.4 for ; Thu, 16 May 2013 08:00:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=SteeysJm5yqc9wRRwdUnCPSO/sqhp8rOj8asVHaVH0I=; b=eNPzJeBg2CBKMRGLgP66zvOzjfWLdtcaywuCRZiuNPSj+MldBati9NKR455g5noxaU +wf5/LPsjcF3Ws0za0HyoKkY92ENIX/LtqEvtm/YHT2NGrxX3FIAc+V27EmZEiBAA06s mluN817TIkuLs0jRYSh6GxIzhvapt8CRDxdOBF9lFHQK4JHczbD/sefEJlMkqbxjB5TZ KLseteJlgzqczfvDNjXXf1UGrvDkDvDeGP1IpW0Sy4kWDTpoh+5FtS9GVqb0/wR+mx7z N2kh8XjMDhmWFVXlVThZOXhvV91VpqjlbcaTBklcXzMDifc6+mv5TDDyeiH2dlMxBlo+ ihFQ== MIME-Version: 1.0 X-Received: by 10.180.198.175 with SMTP id jd15mr25549089wic.28.1368716400441; Thu, 16 May 2013 08:00:00 -0700 (PDT) Received: by 10.194.162.8 with HTTP; Thu, 16 May 2013 08:00:00 -0700 (PDT) In-Reply-To: <18111.1368715153@sandelman.ca> References: <518D3C8B.3080807@digitalbazaar.com> <255B9BB34FB7D647A506DC292726F6E1150D5134B8@WSMSG3153V.srv.dir.telstra.com> <31478_1368464556_r4DH2YHq000867_CAD4=_i4cCvYccigAR1eTaNRhLOWciPHfGO2OG+ahZEaouqhFow@mail.gmail.com> <51911E5A.1000309@andrew.cmu.edu> <18111.1368715153@sandelman.ca> Date: Thu, 16 May 2013 11:00:00 -0400 Message-ID: From: Phillip Hallam-Baker To: Michael Richardson Content-Type: multipart/alternative; boundary=047d7b624956d8c1e204dcd71e6d Cc: HTTP Auth WG Subject: Re: [http-auth] First draft of HTTP Signatures published 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, 16 May 2013 15:00:02 -0000 --047d7b624956d8c1e204dcd71e6d Content-Type: text/plain; charset=ISO-8859-1 On Thu, May 16, 2013 at 10:39 AM, Michael Richardson wrote: > > >>>>> "Phillip" == Phillip Hallam-Baker writes: > Phillip> You will find a lot of objections being made of the form > 'this will break > Phillip> when intermediaries change content'. And they will continue > to be made no > Phillip> matter how many times you point out that detecting changes to > the content > Phillip> and rejecting that transaction is the whole objective. So > there will need > Phillip> to be some statement to the effect that the intended > Phillip> behavior is to prevent > Phillip> all types of content modification. > > And maybe we need to provide a way for intermediaries to signal their > existence, and for a transitive (but decentralized) trust model to > permit their inclusion. My impression is that this has worked well in > SIP, although I am aware that it has also thwarted S/MIME-type security > solutions in SIP. > That might be useful. But right now I am focused on making sure that bad things do not happen. If an intermediary corrupts a message that is a Web Services transaction message then my desired outcome is that the transaction is aborted. People keep telling me that it is a requirement to allow random proxies that have no idea what the Web Service is doing to make random changes to transaction messages and that the protocol should still work. If the intermediary is a party to the transaction, that is a totally different situation. > Phillip> We don't yet know what the effect of intermediaries is on the > request line > Phillip> and I suspect that as we get into tests we are going to > discover that we > Phillip> have to do some form of canonicalization. For example, I > strongly suspect > Phillip> that we are going to want to combine the Host-Name header and > http method > Phillip> into the request line to make it a canonical url. > > "http method", as in GET/PUT/POST/DELETE? (Just asking for > clarification) Sorry, the scheme. The method is already in the request line. > > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works | network > architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails > [ > > -- Website: http://hallambaker.com/ --047d7b624956d8c1e204dcd71e6d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, May 16, 2013 at 10:39 AM, Michael Richardson <mcr+ietf= @sandelman.ca> wrote:

>>>>> "Phillip" =3D=3D Phillip Hallam-Baker <hallam@gmail.com> writes:
=A0 =A0 Phillip> You will find a lot of objections being made of the for= m 'this will break
=A0 =A0 Phillip> when intermediaries change content'. And they will = continue to be made no
=A0 =A0 Phillip> matter how many times you point out that detecting chan= ges to the content
=A0 =A0 Phillip> and rejecting that transaction is the whole objective. = So there will need
=A0 =A0 Phillip> to be some statement to the effect that the intended =A0 =A0 Phillip> behavior is to prevent
=A0 =A0 Phillip> all types of content modification.

And maybe we need to provide a way for intermediaries to signal their
existence, and for a transitive (but decentralized) trust model to
permit their inclusion. =A0 My impression is that this has worked well in SIP, although I am aware that it has also thwarted S/MIME-type security
solutions in SIP.

That might be u= seful. But right now I am focused on making sure that bad things do not hap= pen.=A0

If an intermediary corrupts a = message that is a Web Services transaction message then my desired outcome = is that the transaction is aborted. People keep telling me that it is a req= uirement to allow random proxies that have no idea what the Web Service is = doing to make random changes to transaction messages and that the protocol = should still work.

If the=A0intermediary=A0is a party to the transac= tion, that is a totally different situation.=A0
=A0
=A0 =A0 Phillip> We don't yet know what the effect of intermediaries= is on the request line
=A0 =A0 Phillip> and I suspect that as we get into tests we are going to= discover that we
=A0 =A0 Phillip> have to do some form of canonicalization. For example, = I strongly suspect
=A0 =A0 Phillip> that we are going to want to combine the Host-Name head= er and http method
=A0 =A0 Phillip> into the request line to make it a canonical url.

"http method", as in GET/PUT/POST/DELETE? (Just asking for
clarification)

Sorry, the scheme. The= method is already in the request line.

=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
--
] =A0 =A0 =A0 =A0 =A0 =A0 =A0 Never tell me the odds! =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 | ipv6 mesh networks [
] =A0 Michael Richardson, Sandelman Software Works =A0 =A0 =A0 =A0| network= architect =A0[
] =A0 =A0 mcr@sandelman.ca =A0http://www.sandelman.ca/<= /a> =A0 =A0 =A0 =A0| =A0 ruby on rails =A0 =A0[




-- Website: http://hallambaker.com/<= br>
--047d7b624956d8c1e204dcd71e6d-- From mike@mtcc.com Thu May 16 08:13: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 8B68521F920B for ; Thu, 16 May 2013 08:13:00 -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 WZvVhGpoMTPA for ; Thu, 16 May 2013 08:12:56 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 3E29F21F9227 for ; Thu, 16 May 2013 08:12:56 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r4GFCmYh010801 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 16 May 2013 08:12:50 -0700 Message-ID: <5194F770.3000300@mtcc.com> Date: Thu, 16 May 2013 08:12:48 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Stephen Farrell References: <20130514182628.24312.62987.idtracker@ietfa.amsl.com> <519283D6.9080006@cs.tcd.ie> <255B9BB34FB7D647A506DC292726F6E11519C45C85@WSMSG3153V.srv.dir.telstra.com> <5194EB87.1050706@cs.tcd.ie> In-Reply-To: <5194EB87.1050706@cs.tcd.ie> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4263; t=1368717170; x=1369581170; 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=3A=20registration=20 &=20user=20interaction |Sender:=20 |To:=20Stephen=20Farrell=20 |Content-Type:=20text/plain=3B=20charset=3Dwindows-1252=3B= 20format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=kX5WtTpx/R/FiyOZgEF1iVIhz+ORE1yN0Vrb8IBZWN0=; b=HPGqXHkYn6lnx4CLwQgmnopovdvU9c5wGloa4wO/GLY2EIoa1xvUntnWiY YWhBFbT0Qd69/QSbdV6COBdhMK51KrC+nbK+MzorWfmnvbFZV3bi37BeMS4O PxWmsZc+CdyTZIt+FNcyYNAczexxyXDWzvnWUxjVsZz5nGXShhULw=; 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] HOBA: registration & user interaction 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, 16 May 2013 15:13:00 -0000 On 05/16/2013 07:21 AM, Stephen Farrell wrote: > > The problem is that the server cannot tell if user interaction is appropriate at this point. Presumably a whole range of client requests can result in a 401, any of which could have triggered the registration. The client might not even be a user at a browser. > Yep. Mike brought that up too the other day in an offlist > mail. I guess there'll be all sorts of similar web things > with starting off inside a frame etc. none of which I know > much about. OTOH, its all under the server's control so > should be easy enough if you design a site with this in > mind. But we probably need to do better - to make it easy > to integrate with a site that's previously been using Basic > or web forms with passwords. As I wrote to Paul and Stephen, the question in my mind is whether HOBA-http ought to be thought of as reflexive like 401 is now. I'm thinking that way be dragons because probably the singular glaring fail of the reflexive 401 is that the browser owns the interaction and paints up a butt-ugly modal dialog. Modern web sites MUST be able to control the login/join flow programmatically (= html/js). James zeroed in on exactly the same thing I was thinking about though which are 's, say, when the session has expired. Obviously you can't flow a batch of html back -- the best you could do is capture the problem with an onerror handler, but that would be pretty ugly. So I'm thinking that it might be better for the client (= js in browser) to be proactive to determine the session state. Maybe it wants to inspect the session cookie to see if it's still valid, or whatever else kind of test it might want to perform before it interacts with the server if it knows that a session needs to be valid. Since the overall interaction between the client and server are under control of the site, that doesn't seem too unreasonable to me. Mike > >> Would a better approach for HOBA-http be to include the public key (and device id) in the "Authorization: HOBA" response if a new key pair has just been created? If some user interaction is required the server has to work out how that happens. Perhaps another 401 is returned, but this time with an HTML form as the response body (and no "WWW-Authenticate" header). > Certainly worth a look. Not sure if we'd start to hit problems > with headers being too long or not though esp. for longer RSA > moduli. > > So at this point I don't have answers. But I'd sure welcome > suggestions and am happy to try 'em out as my code develops > and report back. > > Cheers, > S. > >> -- >> James Manger >> >> >>> On 05/14/2013 07:26 PM, internet-drafts@ietf.org wrote: >>>> Title : HTTP Origin-Bound Authentication (HOBA) >>>> Author(s) : Stephen Farrell >>>> Paul Hoffman >>>> Michael Thomas >>>> Filename : draft-ietf-httpauth-hoba-00.txt >>>> Pages : 23 >>>> Date : 2013-05-14 >>>> >>>> Abstract: >>>> HTTP Origin-Bound Authentication (HOBA) is a design for an HTTP >>>> authentication method with credentials that are not vulnerable to >>>> phishing attacks, and that does not require a server-side password >>>> database. The design can also be used in Javascript-based >>>> authentication embedded in HTML. HOBA is an alternative to HTTP >>>> authentication schemes that require passwords with all the negative >>>> attributes that come with password-based systems. HOBA can be >>>> integrated with account management and other applications running >>>> over HTTP and supports portability, so a user can associate more than >>>> one device or origin-bound key with the same service. We also >>>> describe a way in which the HOBA design can be used from a Javascript >>>> web client. When deployed, HOBA will be a drop-in replacement for >>>> password-based HTTP authentication or JavaScript authentication. >>>> >>>> http://tools.ietf.org/html/draft-ietf-httpauth-hoba-00 > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth From mike@mtcc.com Thu May 16 08:39: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 26C1821F92BC for ; Thu, 16 May 2013 08:39: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 rRtzxEFH6z5N for ; Thu, 16 May 2013 08:39:36 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 06C7521F91F1 for ; Thu, 16 May 2013 08:39:36 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r4GFdWtQ019748 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 16 May 2013 08:39:32 -0700 Message-ID: <5194FDB4.5020607@mtcc.com> Date: Thu, 16 May 2013 08:39:32 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Stephen Farrell References: <20130514182628.24312.62987.idtracker@ietfa.amsl.com> <519283D6.9080006@cs.tcd.ie> <255B9BB34FB7D647A506DC292726F6E11519C45C85@WSMSG3153V.srv.dir.telstra.com> <5194EB87.1050706@cs.tcd.ie> <5194F770.3000300@mtcc.com> In-Reply-To: <5194F770.3000300@mtcc.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=5016; t=1368718772; x=1369582772; 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=3A=20registration=20 &=20user=20interaction |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=KjLFvUUbphcJiV5H7u6JMwNvp0gjHcTxyYjiFhOkuQU=; b=NuXtv0F8cvO6HrIjhKNWof8dVxYRdEeu+AM7lr5fNRzHpBNcJ+G8NfKQ02 P2nIFt5NPnP6zbihEFW2JADq7eXFqnlcZUzJYrZcO44f1q2vAQAkJiM0AqcD mBGIOzDmC8UROhyjuMcSBP2H0L1XSN5gJnSwJaLmzJAeNEqsMYzJk=; 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] HOBA: registration & user interaction 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, 16 May 2013 15:39:40 -0000 I just checked around and it seems even worse than I guessed: it seems you cannot get the HTTP status code programmatically in javascript for a tag, so a HOBA-401 would show up as a generic onerror just like a 404. I guess you could overload the prototype of the onerror property and probe your session connectivity any time you got an error of any kind but that doesn't seem like the mostest of elegantests of solutions. Mike On 05/16/2013 08:12 AM, Michael Thomas wrote: > On 05/16/2013 07:21 AM, Stephen Farrell wrote: >> >> The problem is that the server cannot tell if user interaction is appropriate at this point. Presumably a whole range of client requests can result in a 401, any of which could have triggered the registration. The client might not even be a user at a browser. >> Yep. Mike brought that up too the other day in an offlist >> mail. I guess there'll be all sorts of similar web things >> with starting off inside a frame etc. none of which I know >> much about. OTOH, its all under the server's control so >> should be easy enough if you design a site with this in >> mind. But we probably need to do better - to make it easy >> to integrate with a site that's previously been using Basic >> or web forms with passwords. > > As I wrote to Paul and Stephen, the question in my mind is whether HOBA-http > ought to be thought of as reflexive like 401 is now. I'm thinking that way be dragons > because probably the singular glaring fail of the reflexive 401 is that the browser > owns the interaction and paints up a butt-ugly modal dialog. Modern web sites > MUST be able to control the login/join flow programmatically (= html/js). > > James zeroed in on exactly the same thing I was thinking about though which > are 's, say, when the session has expired. Obviously you can't flow a batch > of html back -- the best you could do is capture the problem with an onerror handler, > but that would be pretty ugly. > > So I'm thinking that it might be better for the client (= js in browser) to be proactive > to determine the session state. Maybe it wants to inspect the session cookie to see > if it's still valid, or whatever else kind of test it might want to perform before it > interacts with the server if it knows that a session needs to be valid. Since the overall > interaction between the client and server are under control of the site, that doesn't > seem too unreasonable to me. > > Mike > >> >>> Would a better approach for HOBA-http be to include the public key (and device id) in the "Authorization: HOBA" response if a new key pair has just been created? If some user interaction is required the server has to work out how that happens. Perhaps another 401 is returned, but this time with an HTML form as the response body (and no "WWW-Authenticate" header). >> Certainly worth a look. Not sure if we'd start to hit problems >> with headers being too long or not though esp. for longer RSA >> moduli. >> >> So at this point I don't have answers. But I'd sure welcome >> suggestions and am happy to try 'em out as my code develops >> and report back. >> >> Cheers, >> S. >> >>> -- >>> James Manger >>> >>> >>>> On 05/14/2013 07:26 PM, internet-drafts@ietf.org wrote: >>>>> Title : HTTP Origin-Bound Authentication (HOBA) >>>>> Author(s) : Stephen Farrell >>>>> Paul Hoffman >>>>> Michael Thomas >>>>> Filename : draft-ietf-httpauth-hoba-00.txt >>>>> Pages : 23 >>>>> Date : 2013-05-14 >>>>> >>>>> Abstract: >>>>> HTTP Origin-Bound Authentication (HOBA) is a design for an HTTP >>>>> authentication method with credentials that are not vulnerable to >>>>> phishing attacks, and that does not require a server-side password >>>>> database. The design can also be used in Javascript-based >>>>> authentication embedded in HTML. HOBA is an alternative to HTTP >>>>> authentication schemes that require passwords with all the negative >>>>> attributes that come with password-based systems. HOBA can be >>>>> integrated with account management and other applications running >>>>> over HTTP and supports portability, so a user can associate more than >>>>> one device or origin-bound key with the same service. We also >>>>> describe a way in which the HOBA design can be used from a Javascript >>>>> web client. When deployed, HOBA will be a drop-in replacement for >>>>> password-based HTTP authentication or JavaScript authentication. >>>>> >>>>> http://tools.ietf.org/html/draft-ietf-httpauth-hoba-00 >> _______________________________________________ >> http-auth mailing list >> http-auth@ietf.org >> https://www.ietf.org/mailman/listinfo/http-auth > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth From internet-drafts@ietf.org Thu May 16 12:18:12 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE1921F925B; Thu, 16 May 2013 12:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.064, 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 ANsi0YgDhEaX; Thu, 16 May 2013 12:18:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B64B621F9343; Thu, 16 May 2013 12:18:11 -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.45 Message-ID: <20130516191811.8525.51598.idtracker@ietfa.amsl.com> Date: Thu, 16 May 2013 12:18:11 -0700 Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-basicauth-enc-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: Thu, 16 May 2013 19:18:12 -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 : An Encoding Parameter for HTTP Basic Authentication Author(s) : Julian F. Reschke Filename : draft-ietf-httpauth-basicauth-enc-00.txt Pages : 10 Date : 2013-05-16 Abstract: The "Basic" authentication scheme defined in RFC 2617 does not properly define how to treat non-ASCII characters. This has lead to a situation where user agent implementations disagree, and servers make different assumptions based on the locales they are running in. There is little interoperability for the non-ASCII characters in the ISO-8859-1 character set, and even less interoperability for any characters beyond that. This document defines a backwards-compatible extension to "Basic", specifying the server's character encoding expectation, using a new authentication scheme parameter. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-basicauth-enc There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-httpauth-basicauth-enc-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From yaronf.ietf@gmail.com Thu May 16 12:54: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 6900111E80F7 for ; Thu, 16 May 2013 12:54:49 -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 arPw-Dqum1nr for ; Thu, 16 May 2013 12:54:49 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id B498011E80DC for ; Thu, 16 May 2013 12:54:48 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id a12so875987wgh.11 for ; Thu, 16 May 2013 12:54:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=l2BpbvN++GVWxfhKjoz7tKDNUfeKCWwUozSwVV2Rf74=; b=lyWbKblXT9z9YB+TBC81huWImK0ndJUqrRxwSHhiVRqQttK+Pt1eEWYIfBSfXE50EA 4/59ktX9gpmTjLvM+F3O0fHlzDrSaygo8SnroAJHQMKtHSjM9A3wUg7MG6K0yMQVoCkz ksAQR41/Z2dyXhy9+90XtnwMLSwR9QBFAt4qAOeec1BEFDtjuoZKVhksO99Xy8QUvHMu h1bok6FILA7d6t4kBPC8GZGlQL10IBwbE02cm2XAvFeAO2YsGLNfzBytuH66gKOq67P8 6dGDAt5mDBlkZt9a74/qXbgOTTkUXsohVOg6AdR0NtnhZQa+ycyPmfGTXPKCq/n/i5wl 0Vjg== X-Received: by 10.180.182.229 with SMTP id eh5mr27906670wic.6.1368734087623; Thu, 16 May 2013 12:54:47 -0700 (PDT) Received: from [10.0.0.4] (bzq-79-182-153-201.red.bezeqint.net. [79.182.153.201]) by mx.google.com with ESMTPSA id b11sm5914201wiv.10.2013.05.16.12.54.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 16 May 2013 12:54:47 -0700 (PDT) Message-ID: <51953981.3050601@gmail.com> Date: Thu, 16 May 2013 22:54:41 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: http-auth@ietf.org References: <20130516191811.8525.51598.idtracker@ietfa.amsl.com> In-Reply-To: <20130516191811.8525.51598.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [http-auth] draft-ietf-httpauth-basicauth-enc-00 - a few comments 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, 16 May 2013 19:54:49 -0000 Hi, this draft is short and useful, but can still be improved :-) - Nit: the word "lead" in the abstract and in the intro should be "led". - Although this is clear from the example, please say explicitly that the explicit encoding is used for both the username and the password. - It's funny that the example only uses ASCII. I will be happy to provide a non-ASCII example in Hebrew (although the author's city name would do just as well). - In Sec. A.1.1, why is 8859-1 singled out? Seems to me the strategy should use the locally reasonable locale, e.g. ISO 8859-8 for the he_IL locale. Thanks, Yaron From hallam@gmail.com Thu May 16 13:27:30 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A57021F8EAD for ; Thu, 16 May 2013 13:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cUfdy7HnWcS2 for ; Thu, 16 May 2013 13:27:29 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD7E21F8EC6 for ; Thu, 16 May 2013 13:27:28 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id hr14so224549wib.3 for ; Thu, 16 May 2013 13:27:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=y1CWaFUbu1VUTf7/awDHR/95W9zhkfizr9d1jloUoto=; b=ttfz2YacvHsRw/baSKiLA3ENV/U6rVTetlIpptMMQEdRurNUxj2dKvLAcwaxSPaPza Z3o5MUc4kRm7GXQqB79td8Li9+JyMD9nopTp4IFy0xL9p5LA7QgoMvBhohfam02HWFM9 xWuRYX7r6bMklHtBkqxcBE73ZtQMXcQxxcXa4AiZKjEJtbOuJ5B55Q9y4yOEN+3YurCC DvyxvQSwyFxH/u/mxAstPJyWZqCQNyf0s7pCeT4XmqQALQpk9WxzXYkHDRTlJzRnU6/j hKIsqwI6TjM5TzSiZaNYeg0bMDiB8TZmbHwVXLTYz+N69SVZlsfqH+9TeA7BrXkAOwlN sovg== MIME-Version: 1.0 X-Received: by 10.180.37.243 with SMTP id b19mr28129464wik.12.1368736048207; Thu, 16 May 2013 13:27:28 -0700 (PDT) Received: by 10.194.162.8 with HTTP; Thu, 16 May 2013 13:27:28 -0700 (PDT) In-Reply-To: <51953981.3050601@gmail.com> References: <20130516191811.8525.51598.idtracker@ietfa.amsl.com> <51953981.3050601@gmail.com> Date: Thu, 16 May 2013 16:27:28 -0400 Message-ID: From: Phillip Hallam-Baker To: Yaron Sheffer Content-Type: multipart/alternative; boundary=e89a8f646db5f1dbbb04dcdbb115 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] draft-ietf-httpauth-basicauth-enc-00 - a few comments 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, 16 May 2013 20:27:30 -0000 --e89a8f646db5f1dbbb04dcdbb115 Content-Type: text/plain; charset=ISO-8859-1 For Digest there are two separate changes that are frequently suggested 1) Character set internationalization 2) Algorithm agility Seems to me that if we make any changes we should fix both. Applications are required to accept additional parameters on www-authenticate auth-param This directive allows for future extensions. Any unrecognized directive MUST be ignored. Since we can use www-authenticate I propose that we solve the character set issue by having the server add a flag to the response saying which charsets it accepts. If the client understands the extension and sees the flag then it MUST use one of the offered charsets (same registry as for BASIC) and include the flag. Otherwise it does what it does today... Note that with this approach we don't affect any existing code path so we don't need to investigate. If people have found a way to make Digest work internaltionalized that is not going to be affected. I really doubt that is the case though. Algorithm agility is really unnecessary from a security point of view. The double MD5 construction is more than sufficient to prevent attack and an attacker can perform a brute force dictionary attack in any case. Algorithm agility is still desirable however as MD5 is an algorithm we want to eradicate from code bases and move to SHA256 or SHA3. So I suggest we add in an algorithm using HMAC-SHAn where n is a single value TBS by the crypto folk. I would also like to clean up the construction so that the password component is clearly being used to derive the HMAC key. On Thu, May 16, 2013 at 3:54 PM, Yaron Sheffer wrote: > Hi, this draft is short and useful, but can still be improved :-) > > - Nit: the word "lead" in the abstract and in the intro should be "led". > > - Although this is clear from the example, please say explicitly that the > explicit encoding is used for both the username and the password. > > - It's funny that the example only uses ASCII. I will be happy to provide > a non-ASCII example in Hebrew (although the author's city name would do > just as well). > > - In Sec. A.1.1, why is 8859-1 singled out? Seems to me the strategy > should use the locally reasonable locale, e.g. ISO 8859-8 for the he_IL > locale. > > Thanks, > Yaron > ______________________________**_________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/**listinfo/http-auth > -- Website: http://hallambaker.com/ --e89a8f646db5f1dbbb04dcdbb115 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
For Digest there are two separate changes that are frequen= tly suggested

1) Character set internationalizatio= n
2) Algorithm agility

Seems to me that if we make any changes we should fix both.

Applications are required to accept additional parame= ters on www-authenticate
   auth-param
     This directive allows for future extensions. Any unrecognized
     directive MUST be ignored.

S= ince we can use www-authenticate I propose that we solve the character set = issue by having the server add a flag to the response saying which charsets= it accepts. If the client understands the extension and sees the flag then= it MUST use one of the offered charsets (same registry as for BASIC) and i= nclude the flag. Otherwise it does what it does today...

Note = that with this approach we don't affect any existing code path so we do= n't need to investigate. If people have found a way to make Digest work= internaltionalized that is not going to be affected. I really doubt that i= s the case though.


Algorithm agility is really unn= ecessary from a security point of view. The double MD5 construction is more= than sufficient to prevent attack and an attacker can perform a brute forc= e dictionary attack in any case.

Algorithm agility is still desirable however as MD5 is an algorithm we wan= t to eradicate from code bases and move to SHA256 or SHA3. So I suggest we = add in an algorithm using HMAC-SHAn where n is a single value TBS by the cr= ypto folk.

I would also like to clean up the construction so that the password compon= ent is clearly being used to derive the HMAC key.=A0


<= br>
On Thu, May 16, 2013 at 3:54 PM, Yaron Sheffe= r <yaronf.ietf@gmail.com> wrote:
Hi, this draft is short and useful, but can = still be improved :-)

- Nit: the word "lead" in the abstract and in the intro should be= "led".

- Although this is clear from the example, please say explicitly that the e= xplicit encoding is used for both the username and the password.

- It's funny that the example only uses ASCII. I will be happy to provi= de a non-ASCII example in Hebrew (although the author's city name would= do just as well).

- In Sec. A.1.1, why is 8859-1 singled out? Seems to me the strategy should= use the locally reasonable locale, e.g. ISO 8859-8 for the he_IL locale.
Thanks,
=A0 =A0 =A0 =A0 Yaron
_______________________________________________
http-auth mailing list
http-auth@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/http-auth



--
Website: http://hallambaker.com/
--e89a8f646db5f1dbbb04dcdbb115-- From ilari.liusvaara@elisanet.fi Thu May 16 13:52:32 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 9F21A11E8162 for ; Thu, 16 May 2013 13:52:32 -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 DZf31HCSLmKY for ; Thu, 16 May 2013 13:52:27 -0700 (PDT) Received: from emh03.mail.saunalahti.fi (emh03.mail.saunalahti.fi [62.142.5.109]) by ietfa.amsl.com (Postfix) with ESMTP id 61BD611E815E for ; Thu, 16 May 2013 13:52:27 -0700 (PDT) Received: from saunalahti-vams (vs3-11.mail.saunalahti.fi [62.142.5.95]) by emh03.mail.saunalahti.fi (Postfix) with SMTP id 7E57018893C; Thu, 16 May 2013 23:52:25 +0300 (EEST) Received: from emh03.mail.saunalahti.fi ([62.142.5.109]) by vs3-11.mail.saunalahti.fi ([62.142.5.95]) with SMTP (gateway) id A01AE87BAB8; Thu, 16 May 2013 23:52:25 +0300 Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id 6C0F418893C; Thu, 16 May 2013 23:52:25 +0300 (EEST) Date: Thu, 16 May 2013 23:52:24 +0300 From: Ilari Liusvaara To: Phillip Hallam-Baker Message-ID: <20130516205224.GA14412@LK-Perkele-VII> References: <518D3C8B.3080807@digitalbazaar.com> <255B9BB34FB7D647A506DC292726F6E1150D5134B8@WSMSG3153V.srv.dir.telstra.com> <31478_1368464556_r4DH2YHq000867_CAD4=_i4cCvYccigAR1eTaNRhLOWciPHfGO2OG+ahZEaouqhFow@mail.gmail.com> <51911E5A.1000309@andrew.cmu.edu> 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 X-Antivirus: VAMS Cc: HTTP Auth WG Subject: [http-auth] Session continuation and authentication 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, 16 May 2013 20:52:32 -0000 On Thu, May 16, 2013 at 09:57:11AM -0400, Phillip Hallam-Baker wrote: > HTTP Session Continuation is a separate spec but I would like to share as > much as possible between them. > > http://www.ietf.org/id/draft-hallambaker-httpsession-01.txt Regarding session continuation, since many of the proposed authentication schemes don't seem to have multi-request authentication, should there be some mechanism to couple authentication into session? Obviously, how to derive shared secret from authentication is method- specific, and some methods (e.g. mutual) can yield stronger secrets than others (e.g. SCRAM), and some can't yield one at all (e.g. Basic). I note that HOBA spec calls to use cookies (blech). I haven't yet figured out how mutual deals with concept of "session". Oh, and I don't think "Just use TLS" really cuts it... -Ilari From stephen.farrell@cs.tcd.ie Thu May 16 13:58: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 AB24B21F8F0E for ; Thu, 16 May 2013 13:58: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 jCu7xhXN-QuE for ; Thu, 16 May 2013 13:58: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 C0F5521F8EED for ; Thu, 16 May 2013 13:58:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 112A0BE83; Thu, 16 May 2013 21:57:44 +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 c+6fC4jHSPiv; Thu, 16 May 2013 21:57:43 +0100 (IST) Received: from [10.87.48.3] (unknown [86.46.22.170]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 59DB4BE5C; Thu, 16 May 2013 21:57:43 +0100 (IST) Message-ID: <51954847.8090202@cs.tcd.ie> Date: Thu, 16 May 2013 21:57:43 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Ilari Liusvaara References: <518D3C8B.3080807@digitalbazaar.com> <255B9BB34FB7D647A506DC292726F6E1150D5134B8@WSMSG3153V.srv.dir.telstra.com> <31478_1368464556_r4DH2YHq000867_CAD4=_i4cCvYccigAR1eTaNRhLOWciPHfGO2OG+ahZEaouqhFow@mail.gmail.com> <51911E5A.1000309@andrew.cmu.edu> <20130516205224.GA14412@LK-Perkele-VII> In-Reply-To: <20130516205224.GA14412@LK-Perkele-VII> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: HTTP Auth WG Subject: Re: [http-auth] Session continuation and authentication 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, 16 May 2013 20:58:11 -0000 On 05/16/2013 09:52 PM, Ilari Liusvaara wrote: > I note that HOBA spec calls to use cookies (blech). Yep. But that's because we're aiming to be an easy drop-in replacement for Basic or web forms. If PHB's session continuation thing or some equivalent took off, that'd be great IMO. Bearer tokens are just dangerous. Cheers, S. From mike@mtcc.com Thu May 16 14:08:29 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 DEBD211E8100 for ; Thu, 16 May 2013 14:08:27 -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 8ph+VROfxOmC for ; Thu, 16 May 2013 14:08:13 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id D1D0911E80DC for ; Thu, 16 May 2013 14:08:13 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r4GL7rNp003479 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 16 May 2013 14:07:54 -0700 Message-ID: <51954AA9.8050907@mtcc.com> Date: Thu, 16 May 2013 14:07:53 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Stephen Farrell References: <518D3C8B.3080807@digitalbazaar.com> <255B9BB34FB7D647A506DC292726F6E1150D5134B8@WSMSG3153V.srv.dir.telstra.com> <31478_1368464556_r4DH2YHq000867_CAD4=_i4cCvYccigAR1eTaNRhLOWciPHfGO2OG+ahZEaouqhFow@mail.gmail.com> <51911E5A.1000309@andrew.cmu.edu> <20130516205224.GA14412@LK-Perkele-VII> <51954847.8090202@cs.tcd.ie> In-Reply-To: <51954847.8090202@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=612; t=1368738474; x=1369602474; 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]=20Session=20continuation=20 and=20authentication |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=6G/dQVYogN5mzk6SGYJNkab8a84gMHDBmZvkbAynU20=; b=fA+G8Ycsg8pHyeABYZJiNshgZcgunK+P7+5FcgabA2OOnkSlztb/n6A5SM kCB74OS4c97zO9nNHMhDbZTWxP2SJaT7IlbtwodlZWdpshgDwX/wk9uzUyY/ qEEzRbyuxYoiRoCS18hC669oe3w2fQpcHVXAV8kWkGT93TjD0B09E=; 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 WG Subject: Re: [http-auth] Session continuation and authentication 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, 16 May 2013 21:08:29 -0000 On 05/16/2013 01:57 PM, Stephen Farrell wrote: > > On 05/16/2013 09:52 PM, Ilari Liusvaara wrote: >> I note that HOBA spec calls to use cookies (blech). > Yep. But that's because we're aiming to be an easy drop-in > replacement for Basic or web forms. If PHB's session > continuation thing or some equivalent took off, that'd be > great IMO. Bearer tokens are just dangerous. More to the point, hoba isn't trying to do anything on the session continuation front. It mentions cookies because they're pervasive and HOBA ought to work with them -- or any other session continuation technique. Mike From julian.reschke@gmx.de Fri May 17 01:11:13 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 626D421F93E8 for ; Fri, 17 May 2013 01:11:13 -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 iWIDwYeZIl0M for ; Fri, 17 May 2013 01:11:06 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 77E2221F852A for ; Fri, 17 May 2013 01:11:03 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.35]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0M9d2X-1UnOdm3j2N-00CzDJ for ; Fri, 17 May 2013 10:11:01 +0200 Received: (qmail invoked by alias); 17 May 2013 08:11:01 -0000 Received: from p54BB235C.dip0.t-ipconnect.de (EHLO [192.168.2.117]) [84.187.35.92] by mail.gmx.net (mp035) with SMTP; 17 May 2013 10:11:01 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX184K7giuEA4Q8cYjnYU+nF/MlC5b8WQKCXjBYulp1 J3+tL7g+Tdysfz Message-ID: <5195E616.2030706@gmx.de> Date: Fri, 17 May 2013 10:11:02 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Yaron Sheffer References: <20130516191811.8525.51598.idtracker@ietfa.amsl.com> <51953981.3050601@gmail.com> In-Reply-To: <51953981.3050601@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: http-auth@ietf.org Subject: Re: [http-auth] draft-ietf-httpauth-basicauth-enc-00 - a few comments X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 08:11:14 -0000 On 2013-05-16 21:54, Yaron Sheffer wrote: > Hi, this draft is short and useful, but can still be improved :-) > > - Nit: the word "lead" in the abstract and in the intro should be "led". Fixed in . > - Although this is clear from the example, please say explicitly that > the explicit encoding is used for both the username and the password. Will do. > - It's funny that the example only uses ASCII. I will be happy to > provide a non-ASCII example in Hebrew (although the author's city name > would do just as well). The example uses the POUND sign, which is not ASCII. > - In Sec. A.1.1, why is 8859-1 singled out? Seems to me the strategy > should use the locally reasonable locale, e.g. ISO 8859-8 for the he_IL > locale. > ... Because that's what RFC2617 could be read to say, and some UAs actually do that. Best regards, Julian From stephen.farrell@cs.tcd.ie Fri May 17 02:21:07 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 023B321F9227 for ; Fri, 17 May 2013 02:21:07 -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 m1ekqLtEuegO for ; Fri, 17 May 2013 02:21:01 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4752121F91BF for ; Fri, 17 May 2013 02:20:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E0F39BEB5 for ; Fri, 17 May 2013 10:20:30 +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 1W20GZauEKGM for ; Fri, 17 May 2013 10:20:30 +0100 (IST) Received: from [IPv6:2001:770:10:203:bd65:a93e:7637:a936] (unknown [IPv6:2001:770:10:203:bd65:a93e:7637:a936]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id BF3F6BEA0 for ; Fri, 17 May 2013 10:20:30 +0100 (IST) Message-ID: <5195F65F.7030803@cs.tcd.ie> Date: Fri, 17 May 2013 10:20:31 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: http-auth@ietf.org References: <20130516191811.8525.51598.idtracker@ietfa.amsl.com> In-Reply-To: <20130516191811.8525.51598.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-basicauth-enc-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: Fri, 17 May 2013 09:21:07 -0000 Nice. This looks pretty baked to me. Some nitty comments below, nothing major at all. Cheers, S. - What's the story on updating/obsoleting 2617? I don't much care but this'd be a good thing to work out before IETF LC as otherwise we might end up doing multiple LC's to get it right. Seems like httpbis-p7 doesn't obsolete 2617 and nor does this and presumably nor would an updated digest. Somehow that seems wrong;-) I can't recall if 3 RFCs can all obsolete 2617 or not but maybe that'd be worth checking out with someone who cares. I can find someone who cares and ask if that's what the wg want - the chairs can tell me if so, or that might be better as a thing the httpbis wg think about, or perhaps its all been thought about already. - An additional example or two would be good, maybe with a username and password with asian characters or something. If sticking with one Example, maybe change the title of section 4:-) - section 5: I wondered if there are any potential bad effects if a UA sends an Authorization header like this to a server that only supports ASCII. Is it worth adding a warning that servers that assume that they get ASCII after base64 decoding Authorization headers might get a surprise? Yes, it'd have to be pretty crappy server code for that to cause a security problem, but I guess it could happen. - A.1: do we know that current UAs will actually ignore the new parameter? I think I recall someone saying that is the case, but I forget. Ah - you have it in B.3 - I think it'd be better to merge those bits. The links from B.3 are great btw, thanks for doing that work. - A.1.1: trying twice made me wonder if there's any way to leverage that for some kind of side-channel/oracle attack. Can't think of one but has someone thought about that? - A.2: "as well as before" - is that being disingenuous? If so I think it'd be better not to do that since many people reading this won't get it. I'd suggest replacing that with "as well or as badly as before." - B.2: "this scheme" - I think the "this" here refers to Digest, but its ambiguous as written. - D.2: I don't understand this but then I never did and probably never will, so you could add anything and that'd work for me:-) From julian.reschke@gmx.de Fri May 17 03:37:38 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50B9C21F93FF for ; Fri, 17 May 2013 03:37:38 -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 i2BqMNefyzII for ; Fri, 17 May 2013 03:37:32 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD3E21F93F8 for ; Fri, 17 May 2013 03:37:32 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.4]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MN7As-1Ub6BP1hlI-006bz9 for ; Fri, 17 May 2013 12:37:31 +0200 Received: (qmail invoked by alias); 17 May 2013 10:37:31 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.105]) [217.91.35.233] by mail.gmx.net (mp004) with SMTP; 17 May 2013 12:37:31 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+FrEQThq+FIHHWHFGves4U1mgclCrZqc2QgooP98 2dbJMWJf5Uc6Jq Message-ID: <5196086B.3000700@gmx.de> Date: Fri, 17 May 2013 12:37:31 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Stephen Farrell References: <20130516191811.8525.51598.idtracker@ietfa.amsl.com> <5195F65F.7030803@cs.tcd.ie> In-Reply-To: <5195F65F.7030803@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: http-auth@ietf.org Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-basicauth-enc-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: Fri, 17 May 2013 10:37:38 -0000 On 2013-05-17 11:20, Stephen Farrell wrote: > > Nice. This looks pretty baked to me. Some nitty comments > below, nothing major at all. > > Cheers, > S. > > - What's the story on updating/obsoleting 2617? I don't much HTTPbis P7 obsoletes the framework part of RFC 2617. We'll need two additional specs defining Basic and Digest to get rid of RFC 2617 completely. *This* draft just addresses the I18N issue of Basic. The reason why I don't want to do it in a new Basic spec is that this *really* is experimental. There's no point putting it into something that's replacing 2617 if we don't have any evidence that it works. > care but this'd be a good thing to work out before IETF LC as > otherwise we might end up doing multiple LC's to get it right. > Seems like httpbis-p7 doesn't obsolete 2617 and nor does this > and presumably nor would an updated digest. Somehow that seems > wrong;-) I can't recall if 3 RFCs can all obsolete 2617 or > not but maybe that'd be worth checking out with someone who > cares. I can find someone who cares and ask if that's what > the wg want - the chairs can tell me if so, or that might be > better as a thing the httpbis wg think about, or perhaps its > all been thought about already. > > - An additional example or two would be good, maybe with > a username and password with asian characters or something. > If sticking with one Example, maybe change the title of > section 4:-) Ok. > - section 5: I wondered if there are any potential bad effects > if a UA sends an Authorization header like this to a server > that only supports ASCII. Is it worth adding a warning that > servers that assume that they get ASCII after base64 decoding > Authorization headers might get a surprise? Yes, it'd have > to be pretty crappy server code for that to cause a security > problem, but I guess it could happen. Clients already send non-ASCII; the issue here is making the encoding reliable. > - A.1: do we know that current UAs will actually ignore the > new parameter? I think I recall someone saying that is the > case, but I forget. Ah - you have it in B.3 - I think it'd > be better to merge those bits. The links from B.3 are great > btw, thanks for doing that work. I can do that. > - A.1.1: trying twice made me wonder if there's any way to > leverage that for some kind of side-channel/oracle attack. > Can't think of one but has someone thought about that? Feedback appreciated :-) > - A.2: "as well as before" - is that being disingenuous? If > so I think it'd be better not to do that since many people > reading this won't get it. I'd suggest replacing that with > "as well or as badly as before." Ack. > - B.2: "this scheme" - I think the "this" here refers to > Digest, but its ambiguous as written. Also, this WG actually is chartered to update Digest, so this needs work. > - D.2: I don't understand this but then I never did and > probably never will, so you could add anything and that'd > work for me:-) Thanks for the feedback! Best regards, Julian From stephen.farrell@cs.tcd.ie Fri May 17 03:49: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 CD70D21F8D31 for ; Fri, 17 May 2013 03:49:00 -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 LrL5xEJOmR8t for ; Fri, 17 May 2013 03:48:55 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6FB21F8D00 for ; Fri, 17 May 2013 03:48:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8F2B1BE9F; Fri, 17 May 2013 11:48:32 +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 JPQ7G09lsiTF; Fri, 17 May 2013 11:48:32 +0100 (IST) Received: from [IPv6:2001:770:10:203:bd65:a93e:7637:a936] (unknown [IPv6:2001:770:10:203:bd65:a93e:7637:a936]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 65917BE83; Fri, 17 May 2013 11:48:32 +0100 (IST) Message-ID: <51960B00.3030106@cs.tcd.ie> Date: Fri, 17 May 2013 11:48:32 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Julian Reschke References: <20130516191811.8525.51598.idtracker@ietfa.amsl.com> <5195F65F.7030803@cs.tcd.ie> <5196086B.3000700@gmx.de> In-Reply-To: <5196086B.3000700@gmx.de> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: http-auth@ietf.org Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-basicauth-enc-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: Fri, 17 May 2013 10:49:01 -0000 On 05/17/2013 11:37 AM, Julian Reschke wrote: > On 2013-05-17 11:20, Stephen Farrell wrote: >> >> Nice. This looks pretty baked to me. Some nitty comments >> below, nothing major at all. >> >> Cheers, >> S. >> >> - What's the story on updating/obsoleting 2617? I don't much > > HTTPbis P7 obsoletes the framework part of RFC 2617. We'll need two > additional specs defining Basic and Digest to get rid of RFC 2617 > completely. Ok so the plan is something like, this, p7 and then a new basic and a new digest all become RFCs that update 2617. When those are all done, the we can do a no-I-D IETF LC to obsolete 2617 and just get the RFC editor to change the metadata. (Updates and obsoletes relationships are not part of the RFC, but part of the metadata, and that latter can change.) I think that works. Doubtless someone'll have a problem with it somewhere along the line, but we can worry about that then:-) Ta, S. > > *This* draft just addresses the I18N issue of Basic. The reason why I > don't want to do it in a new Basic spec is that this *really* is > experimental. There's no point putting it into something that's > replacing 2617 if we don't have any evidence that it works. > >> care but this'd be a good thing to work out before IETF LC as >> otherwise we might end up doing multiple LC's to get it right. >> Seems like httpbis-p7 doesn't obsolete 2617 and nor does this >> and presumably nor would an updated digest. Somehow that seems >> wrong;-) I can't recall if 3 RFCs can all obsolete 2617 or >> not but maybe that'd be worth checking out with someone who >> cares. I can find someone who cares and ask if that's what >> the wg want - the chairs can tell me if so, or that might be >> better as a thing the httpbis wg think about, or perhaps its >> all been thought about already. >> >> - An additional example or two would be good, maybe with >> a username and password with asian characters or something. >> If sticking with one Example, maybe change the title of >> section 4:-) > > Ok. > >> - section 5: I wondered if there are any potential bad effects >> if a UA sends an Authorization header like this to a server >> that only supports ASCII. Is it worth adding a warning that >> servers that assume that they get ASCII after base64 decoding >> Authorization headers might get a surprise? Yes, it'd have >> to be pretty crappy server code for that to cause a security >> problem, but I guess it could happen. > > Clients already send non-ASCII; the issue here is making the encoding > reliable. > >> - A.1: do we know that current UAs will actually ignore the >> new parameter? I think I recall someone saying that is the >> case, but I forget. Ah - you have it in B.3 - I think it'd >> be better to merge those bits. The links from B.3 are great >> btw, thanks for doing that work. > > I can do that. > >> - A.1.1: trying twice made me wonder if there's any way to >> leverage that for some kind of side-channel/oracle attack. >> Can't think of one but has someone thought about that? > > Feedback appreciated :-) > >> - A.2: "as well as before" - is that being disingenuous? If >> so I think it'd be better not to do that since many people >> reading this won't get it. I'd suggest replacing that with >> "as well or as badly as before." > > Ack. > >> - B.2: "this scheme" - I think the "this" here refers to >> Digest, but its ambiguous as written. > > Also, this WG actually is chartered to update Digest, so this needs work. > >> - D.2: I don't understand this but then I never did and >> probably never will, so you could add anything and that'd >> work for me:-) > > Thanks for the feedback! > > Best regards, Julian > > > From duerst@it.aoyama.ac.jp Fri May 17 04:06:25 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 243CB21F93BD for ; Fri, 17 May 2013 04:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.14 X-Spam-Level: X-Spam-Status: No, score=-100.14 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, 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 6lUnHWyWtqNn for ; Fri, 17 May 2013 04:06:18 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 719AB21F9347 for ; Fri, 17 May 2013 04:06:18 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id r4HB5uJN007638; Fri, 17 May 2013 20:05:56 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 0dc4_f7cf_bf526dce_bee1_11e2_b26e_001e6722eec2; Fri, 17 May 2013 20:05:55 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id DFDB3BF4CE; Fri, 17 May 2013 20:05:08 +0900 (JST) Message-ID: <51960EFD.8000207@it.aoyama.ac.jp> Date: Fri, 17 May 2013 20:05:33 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Stephen Farrell References: <20130516191811.8525.51598.idtracker@ietfa.amsl.com> <5195F65F.7030803@cs.tcd.ie> <5196086B.3000700@gmx.de> <51960B00.3030106@cs.tcd.ie> In-Reply-To: <51960B00.3030106@cs.tcd.ie> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Julian Reschke , http-auth@ietf.org Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-basicauth-enc-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: Fri, 17 May 2013 11:06:25 -0000 On 2013/05/17 19:48, Stephen Farrell wrote: > On 05/17/2013 11:37 AM, Julian Reschke wrote: >> HTTPbis P7 obsoletes the framework part of RFC 2617. We'll need two >> additional specs defining Basic and Digest to get rid of RFC 2617 >> completely. > > Ok so the plan is something like, this, p7 and then a new > basic and a new digest all become RFCs that update 2617. > When those are all done, the we can do a no-I-D IETF LC > to obsolete 2617 and just get the RFC editor to change the > metadata. (Updates and obsoletes relationships are not part > of the RFC, but part of the metadata, and that latter can > change.) > > I think that works. Doubtless someone'll have a problem > with it somewhere along the line, but we can worry about > that then:-) I don't have a problem. A slight alternative (and the way I seem to remember it having been done in a past case) is to have the first few new RFCs use the 'update' label, and the last one use the 'obsoletes' label. That allows to get rid of one IETF Last Call. Regards, Martin. From hallam@gmail.com Fri May 17 04:48: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 6144921F8F27 for ; Fri, 17 May 2013 04:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, 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 BYnsJ75lwKPN for ; Fri, 17 May 2013 04:48:04 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 2BAB321F8ECB for ; Fri, 17 May 2013 04:48:03 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id fp13so3442902lab.8 for ; Fri, 17 May 2013 04:48:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=RoburcAY7RXXLSwESHioRGZm98EEFoXfCCu8YE1MIuY=; b=nN5sFV9SKVCmNCcEDacGvaXJfXNCan0+zhePIVfYdLCyYEUnOvwB3PO0yJpYuyCMUs 7JRnahKuIPiXNoCynDZf3xPJ1h9EcYtINw2efI815xG9mHaG28IcoefTkuEGHATbgI0l 78g7ZNP5hDFREx7n+O2mUmVow0X+WElPHOXpi55kRtXurocjuYqnTELyIcJbc1zzU+M4 XYBmZfD2jHfpig9v5RUjlBi0WNxXRH5paDJgWgDve8pj5CTfdSEes024FljQZ7NBRHGg 0aMvkCjPK3s/2/dw2zhnQCG3XCOHrxa5zH7+EmqWclt3AOzlBtHYpKbbSpiphDl7oybI 1D8Q== MIME-Version: 1.0 X-Received: by 10.112.198.199 with SMTP id je7mr4332054lbc.110.1368791282970; Fri, 17 May 2013 04:48:02 -0700 (PDT) Received: by 10.112.59.231 with HTTP; Fri, 17 May 2013 04:48:02 -0700 (PDT) In-Reply-To: <51954847.8090202@cs.tcd.ie> References: <518D3C8B.3080807@digitalbazaar.com> <255B9BB34FB7D647A506DC292726F6E1150D5134B8@WSMSG3153V.srv.dir.telstra.com> <31478_1368464556_r4DH2YHq000867_CAD4=_i4cCvYccigAR1eTaNRhLOWciPHfGO2OG+ahZEaouqhFow@mail.gmail.com> <51911E5A.1000309@andrew.cmu.edu> <20130516205224.GA14412@LK-Perkele-VII> <51954847.8090202@cs.tcd.ie> Date: Fri, 17 May 2013 07:48:02 -0400 Message-ID: From: Phillip Hallam-Baker To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a11c2ae183176ac04dce88e9d Cc: HTTP Auth WG Subject: Re: [http-auth] Session continuation and authentication X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 11:48:05 -0000 --001a11c2ae183176ac04dce88e9d Content-Type: text/plain; charset=ISO-8859-1 I don't see any reason for the session continuation mechanism to vary across credential presentation mechanisms. The aim is to have one continuation mechanism that all the authentication schemes can adopt rather than proposing slightly different ones. At root a session continuation mechanism is going to have two key pieces of information, the session identifier and the secret key. The draft is designed to support HTML Forms and other legacy mechanisms that don't know about continuation and so it describes a mechanism to establish the tokens in HTTP headers. But there is no reason why HOBA or whatever can't generate the session identifier and key by themselves. In fact that is exactly what I am doing in Omnibroker where I generate the session identifier and key using a connection maintenance Web Service. I'll try to spin that out as a separate draft since it is a fairly general problem that could be re-used often. On Thu, May 16, 2013 at 4:57 PM, Stephen Farrell wrote: > > > On 05/16/2013 09:52 PM, Ilari Liusvaara wrote: > > I note that HOBA spec calls to use cookies (blech). > > Yep. But that's because we're aiming to be an easy drop-in > replacement for Basic or web forms. If PHB's session > continuation thing or some equivalent took off, that'd be > great IMO. Bearer tokens are just dangerous. > > Cheers, > S. > > -- Website: http://hallambaker.com/ --001a11c2ae183176ac04dce88e9d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I don't see any reason for the session continuation me= chanism to vary across credential presentation mechanisms. The aim is to ha= ve one continuation mechanism that all the authentication schemes can adopt= rather than proposing slightly different ones.

At root a session continuation mechanism is going to h= ave two key pieces of information, the session identifier and the secret ke= y. The draft is designed to support HTML Forms and other legacy mechanisms = that don't know about continuation and so it describes a mechanism to e= stablish the tokens in HTTP headers.

But there is no reason why HOBA or whatever= can't generate the session identifier and key by themselves. In fact t= hat is exactly what I am doing in Omnibroker where I generate the session i= dentifier and key using a connection maintenance Web Service. I'll try = to spin that out as a separate draft since it is a fairly general problem t= hat could be re-used often.





On Thu, May 16, 201= 3 at 4:57 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:


On 05/16/2013 09:52 PM, Ilari Liusvaara wrote:
> I note that HOBA spec calls to use cookies (blech).

Yep. But that's because we're aiming to be an easy drop-in replacement for Basic or web forms. If PHB's session
continuation thing or some equivalent took off, that'd be
great IMO. Bearer tokens are just dangerous.

Cheers,
S.




--
Website: http://hallambaker.com/
--001a11c2ae183176ac04dce88e9d-- From ilari.liusvaara@elisanet.fi Fri May 17 13:44: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 C02F221F8E3C for ; Fri, 17 May 2013 13:44: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] 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 l4tmcnSgwGRZ for ; Fri, 17 May 2013 13:44:13 -0700 (PDT) Received: from emh01.mail.saunalahti.fi (emh01.mail.saunalahti.fi [62.142.5.107]) by ietfa.amsl.com (Postfix) with ESMTP id 56BCF21F89FD for ; Fri, 17 May 2013 13:44:13 -0700 (PDT) Received: from saunalahti-vams (vs3-10.mail.saunalahti.fi [62.142.5.94]) by emh01.mail.saunalahti.fi (Postfix) with SMTP id 037C790005; Fri, 17 May 2013 23:44:10 +0300 (EEST) Received: from emh01.mail.saunalahti.fi ([62.142.5.107]) by vs3-10.mail.saunalahti.fi ([62.142.5.94]) with SMTP (gateway) id A0630EF194C; Fri, 17 May 2013 23:44:09 +0300 Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id CB64590005; Fri, 17 May 2013 23:44:09 +0300 (EEST) Date: Fri, 17 May 2013 23:44:09 +0300 From: Ilari Liusvaara To: Phillip Hallam-Baker Message-ID: <20130517204409.GA19178@LK-Perkele-VII> References: <518D3C8B.3080807@digitalbazaar.com> <255B9BB34FB7D647A506DC292726F6E1150D5134B8@WSMSG3153V.srv.dir.telstra.com> <31478_1368464556_r4DH2YHq000867_CAD4=_i4cCvYccigAR1eTaNRhLOWciPHfGO2OG+ahZEaouqhFow@mail.gmail.com> <51911E5A.1000309@andrew.cmu.edu> <20130516205224.GA14412@LK-Perkele-VII> <51954847.8090202@cs.tcd.ie> 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 X-Antivirus: VAMS Cc: HTTP Auth WG Subject: Re: [http-auth] Session continuation and authentication X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 20:44:19 -0000 On Fri, May 17, 2013 at 07:48:02AM -0400, Phillip Hallam-Baker wrote: > I don't see any reason for the session continuation mechanism to vary > across credential presentation mechanisms. The aim is to have one > continuation mechanism that all the authentication schemes can adopt rather > than proposing slightly different ones. Well, the idea I had was roughly: Have an optional mode (server-initiated) where both sides do: real_session_secret = HMAC-X(shared_secret_from_auth, session_secret_on_wire) But perhaps this is a bad idea, simpler and sufficient being server being able to signal implicit session secret (real_session_secret=shared_secret_from_auth). Then various auth schemes specify how to derive shared_secret_from_auth. Threat model obviously involves connection (TLS or not) being MITM'd... Yeah, wouldn't amount to much with schemes like scram or digest, but HOBA or mutual could do much better at this. -Ilari From mlepinski.ietf@gmail.com Tue May 28 18:04: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 1E2AC21F8EFC for ; Tue, 28 May 2013 18:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.665 X-Spam-Level: X-Spam-Status: No, score=-2.665 tagged_above=-999 required=5 tests=[AWL=-0.066, 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 Q-FvUzHnVq8r for ; Tue, 28 May 2013 18:04:38 -0700 (PDT) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 1075621F8EF7 for ; Tue, 28 May 2013 18:04:37 -0700 (PDT) Received: by mail-qc0-f176.google.com with SMTP id o10so4387971qcv.21 for ; Tue, 28 May 2013 18:04:37 -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=7Bn1/MYlvIcjAGNesO5I1woWQbss8kns7OEGNDyrkvg=; b=VUnw49HugcuDGF+PVjqWsafJJ6PwWuzkcPpNyYyfe9sQropsrEuGNxachQZuD8Iowb NMKkFJ8Q4qsJHUwQ79cVK2SUG4uPNnWte6Qs2vsIsIJmZk65O5TZi/etyADm/s8Nvig3 qN2/s6Cjs0sE7/jc4QeKf8lZnZFSe8rXVb0kRxpshna9HoxDUefCiT0r6t4TNs5VALAm gefixKHF8Kisa+XqfyVRewEgFouFqZEP5mCAReFKEb/v/qFFuOKstHVi2ZpUDJrivwCq 8Fsd8IiFro1IF1d/vZEh2re25jnuDV1e6HEezDZ9B6LNk9gnensZENPvUUinQWFcy1zi vA9Q== MIME-Version: 1.0 X-Received: by 10.224.205.8 with SMTP id fo8mr810790qab.62.1369789477527; Tue, 28 May 2013 18:04:37 -0700 (PDT) Received: by 10.49.130.8 with HTTP; Tue, 28 May 2013 18:04:37 -0700 (PDT) Date: Tue, 28 May 2013 21:04:37 -0400 Message-ID: From: Matthew Lepinski To: http-auth@ietf.org Content-Type: multipart/alternative; boundary=20cf3005dc0a39a71404ddd0f73d Subject: [http-auth] Call for Adoption: draft-ahrens-httpbis-digest-auth-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: Wed, 29 May 2013 01:04:39 -0000 --20cf3005dc0a39a71404ddd0f73d Content-Type: text/plain; charset=ISO-8859-1 The HTTP-AUTH working group is chartered to produce a specification updating HTTP Digest Authentication. The following document has been submitted to the chairs as a potential starting point for the working group's efforts on digest authentication: draft-ahrens-httpbis-digest-auth-update-00 We are therefore asking the working group if you support adopting draft-ahrens-httpbis-digest-auth-update as a working group document to serve as a starting point for digest authentication work. Note that this document is only a starting point and not a complete solution. Indeed, the document does not address the issue of internationalization, and text would need to be added in a future (See for example, the following proposal http://www.ietf.org/mail-archive/web/http-auth/current/msg01264.html) The chairs are not currently aware of any alternative drafts that might serve as as starting point for our work. Thanks, Yoav & Matt --20cf3005dc0a39a71404ddd0f73d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The HTTP-AUTH working group is chartered to produce a spec= ification updating HTTP Digest Authentication.

The follo= wing document has been submitted to the chairs as a potential starting poin= t for the working group's efforts on digest authentication:
draft-ahrens-httpbis-digest-auth-update-00

We are therefore asking the working group if you support adopting= =A0draft-ahrens-httpbis-digest-auth-update as a working group document to s= erve as a starting point for digest authentication work.

Note that this document is only a starting = point and not a complete solution. Indeed, the document does not address th= e issue of internationalization, and text would need to be added in a futur= e (See for example, the following proposal=A0http://www.ietf.org/mail= -archive/web/http-auth/current/msg01264.html)

The chairs are not currently aware of any a= lternative drafts that might serve as as starting point for our work.=A0

Thanks,

Yoav & Matt
--20cf3005dc0a39a71404ddd0f73d-- From stephen.farrell@cs.tcd.ie Wed May 29 01:37:38 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBFB221F90C6 for ; Wed, 29 May 2013 01:37:38 -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 fwcLQcko76n4 for ; Wed, 29 May 2013 01:37: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 E1E1F21F90AC for ; Wed, 29 May 2013 01:37:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 044BEBEDA; Wed, 29 May 2013 09:37:12 +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 4FgKW8qcV8aL; Wed, 29 May 2013 09:37:07 +0100 (IST) Received: from [10.87.48.3] (unknown [86.44.64.164]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 12865BE8F; Wed, 29 May 2013 09:37:07 +0100 (IST) Message-ID: <51A5BE32.1050200@cs.tcd.ie> Date: Wed, 29 May 2013 09:37:06 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Matthew Lepinski References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: http-auth@ietf.org Subject: Re: [http-auth] Call for Adoption: draft-ahrens-httpbis-digest-auth-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: Wed, 29 May 2013 08:37:39 -0000 So I've two questions before I'd say yes, but would like to see the WG do this work so we can finally obsolete 2617. - What are the other deficiencies hinted at in 2.1.2 that are not being fixed (other than i18n)? They don't all need to be in the draft but we should consider 'em on the list I think. - I don't think adding a bagful of hash functions is useful, just adding sha256 would seem fine. Or I could buy other options if there are real use cases, but I bet there aren't. Question is: why not just add sha256 and be done with it? S. On 05/29/2013 02:04 AM, Matthew Lepinski wrote: > The HTTP-AUTH working group is chartered to produce a specification > updating HTTP Digest Authentication. > > The following document has been submitted to the chairs as a potential > starting point for the working group's efforts on digest authentication: > draft-ahrens-httpbis-digest-auth-update-00 > > We are therefore asking the working group if you support > adopting draft-ahrens-httpbis-digest-auth-update as a working group > document to serve as a starting point for digest authentication work. > > Note that this document is only a starting point and not a complete > solution. Indeed, the document does not address the issue of > internationalization, and text would need to be added in a future (See for > example, the following proposal > http://www.ietf.org/mail-archive/web/http-auth/current/msg01264.html) > > The chairs are not currently aware of any alternative drafts that might > serve as as starting point for our work. > > Thanks, > > Yoav & Matt > > > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > From ynir@checkpoint.com Wed May 29 02:15: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 5724021F84B1 for ; Wed, 29 May 2013 02:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCiEhnxcntYW for ; Wed, 29 May 2013 02:15:49 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 12FE121F91CB for ; Wed, 29 May 2013 02:15:40 -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 r4T9FZ69011486; Wed, 29 May 2013 12:15:35 +0300 X-CheckPoint: {51A5C737-27-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Wed, 29 May 2013 12:15:35 +0300 From: Yoav Nir To: Stephen Farrell Thread-Topic: [http-auth] Call for Adoption: draft-ahrens-httpbis-digest-auth-update Thread-Index: AQHOXAiEhA1JHXMjGUSfDphm23ZxbpkbpQoAgAAKv4A= Date: Wed, 29 May 2013 09:15:34 +0000 Message-ID: <701DD8DF-75C8-4C87-8CC0-C293416C6578@checkpoint.com> References: <51A5BE32.1050200@cs.tcd.ie> In-Reply-To: <51A5BE32.1050200@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [91.90.139.159] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 114892aa62bff953d0ad2bb522472614ebce78a37a Content-Type: text/plain; charset="us-ascii" Content-ID: <9D4A2723C3DD924D803188182494C7E8@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [http-auth] Call for Adoption: draft-ahrens-httpbis-digest-auth-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: Wed, 29 May 2013 09:15:55 -0000 Hi Stephen. Just one comment (with no hats) On May 29, 2013, at 11:37 AM, Stephen Farrell w= rote: > - I don't think adding a bagful of hash functions is > useful, just adding sha256 would seem fine. Or I > could buy other options if there are real use > cases, but I bet there aren't. Question is: why > not just add sha256 and be done with it? People like algorithm agility. This might even save us from having to proce= ss "SHA3-256 and its use in HTTP Authentication", "GOST R 34.11-94 and its = use in HTTP Authentication", and the same for djb2 and other algorithms. We probably want to make only sha256 MTI, else we don't get interoperabilit= y. But what's the harm of adding a whole bagful?= From rifatyu@avaya.com Wed May 29 05:52:47 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6FE721F8AD5 for ; Wed, 29 May 2013 05:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEE-83wu7-cb for ; Wed, 29 May 2013 05:52:42 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id B46BE21F896B for ; Wed, 29 May 2013 05:52:23 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAAH/ZlHGmAcF/2dsb2JhbABQgmUhNsFIgQcWdIIfAQEBAQMBAQEPCx00CwwEAgEIDQQEAQEBChQJBycLFAkIAgQBDQUIARIHh3IBC6A8nQwXjWSBASYLAgUGglphA5gjhQaKaIMLgXM1 X-IronPort-AV: E=Sophos;i="4.87,456,1363147200"; d="scan'208";a="13313379" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 29 May 2013 08:52:23 -0400 Received: from unknown (HELO AZ-US1EXHC01.global.avaya.com) ([135.11.85.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 29 May 2013 08:46:47 -0400 Received: from AZ-US1EXMB01.global.avaya.com ([fe80::54fa:ed52:888e:7ca8]) by AZ-US1EXHC01.global.avaya.com ([135.11.85.12]) with mapi id 14.02.0328.009; Wed, 29 May 2013 08:52:22 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: Stephen Farrell , Matthew Lepinski Thread-Topic: [http-auth] Call for Adoption: draft-ahrens-httpbis-digest-auth-update Thread-Index: AQHOXAiD09PpxeUDpUSBL0rOJ82WjpkcGmMA////NZA= Date: Wed, 29 May 2013 12:52:21 +0000 Message-ID: References: <51A5BE32.1050200@cs.tcd.ie> In-Reply-To: <51A5BE32.1050200@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.48] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Call for Adoption: draft-ahrens-httpbis-digest-auth-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: Wed, 29 May 2013 12:52:48 -0000 > -----Original Message----- > From: http-auth-bounces@ietf.org [mailto:http-auth-bounces@ietf.org] On > Behalf Of Stephen Farrell > Sent: Wednesday, May 29, 2013 4:37 AM > To: Matthew Lepinski > Cc: http-auth@ietf.org > Subject: Re: [http-auth] Call for Adoption: draft-ahrens-httpbis-digest- > auth-update >=20 >=20 > So I've two questions before I'd say yes, but would > like to see the WG do this work so we can finally > obsolete 2617. >=20 We have discussed this in the past.=20 This document will not obsolete RFC2617, but will update it. Even with the addition of the i18n text, I do not think that this draft wil= l obsolete RFC2617. Can you elaborate on what is it that you want to obsolete from RFC2617? > - What are the other deficiencies hinted at in 2.1.2 > that are not being fixed (other than i18n)? They > don't all need to be in the draft but we should > consider 'em on the list I think. >=20 I think that this is just a reminder of the text from RFC2617 section 3.1.4= . http://tools.ietf.org/html/rfc2617#section-3.1.4 > - I don't think adding a bagful of hash functions is > useful, just adding sha256 would seem fine. Or I > could buy other options if there are real use > cases, but I bet there aren't. Question is: why > not just add sha256 and be done with it? >=20 > S. >=20 > On 05/29/2013 02:04 AM, Matthew Lepinski wrote: > > The HTTP-AUTH working group is chartered to produce a specification > > updating HTTP Digest Authentication. > > > > The following document has been submitted to the chairs as a potential > > starting point for the working group's efforts on digest > authentication: > > draft-ahrens-httpbis-digest-auth-update-00 > > > > We are therefore asking the working group if you support > > adopting draft-ahrens-httpbis-digest-auth-update as a working group > > document to serve as a starting point for digest authentication work. > > > > Note that this document is only a starting point and not a complete > > solution. Indeed, the document does not address the issue of > > internationalization, and text would need to be added in a future (See > for > > example, the following proposal > > http://www.ietf.org/mail-archive/web/http-auth/current/msg01264.html) > > > > The chairs are not currently aware of any alternative drafts that > might > > serve as as starting point for our work. > > > > Thanks, > > > > Yoav & Matt > > > > > > > > _______________________________________________ > > http-auth mailing list > > http-auth@ietf.org > > https://www.ietf.org/mailman/listinfo/http-auth > > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth From rifatyu@avaya.com Wed May 29 05:55:22 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC3B21F896B for ; Wed, 29 May 2013 05:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6GpYV3ToAfIV for ; Wed, 29 May 2013 05:55:16 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id EDDDE21F87B7 for ; Wed, 29 May 2013 05:55:15 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkUHANP5pVHGmAcF/2dsb2JhbABagmghMMF7gQoWdIIjAQEBAQMBAQEPCx00CwwEAgEIDQEDBAEBAQoUCQcnCxQJCAIEAQ0FCBqHawELnXqcMhMEjmQxBwaCbWEDnXyKf4MPgic X-IronPort-AV: E=Sophos;i="4.87,764,1363147200"; d="scan'208";a="11107950" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 29 May 2013 08:55:14 -0400 Received: from unknown (HELO AZ-US1EXHC02.global.avaya.com) ([135.11.85.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 29 May 2013 08:49:37 -0400 Received: from AZ-US1EXMB01.global.avaya.com ([fe80::54fa:ed52:888e:7ca8]) by AZ-US1EXHC02.global.avaya.com ([::1]) with mapi id 14.02.0328.009; Wed, 29 May 2013 08:55:12 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: Yoav Nir , Stephen Farrell Thread-Topic: [http-auth] Call for Adoption: draft-ahrens-httpbis-digest-auth-update Thread-Index: AQHOXE0i/ZtITSky30qDkmcUkk9jepkcHlIw Date: Wed, 29 May 2013 12:55:11 +0000 Message-ID: References: <51A5BE32.1050200@cs.tcd.ie> <701DD8DF-75C8-4C87-8CC0-C293416C6578@checkpoint.com> In-Reply-To: <701DD8DF-75C8-4C87-8CC0-C293416C6578@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.48] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [http-auth] Call for Adoption: draft-ahrens-httpbis-digest-auth-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: Wed, 29 May 2013 12:55:22 -0000 I agree with Yoav. Regards, Rifaat > -----Original Message----- > From: http-auth-bounces@ietf.org [mailto:http-auth-bounces@ietf.org] On > Behalf Of Yoav Nir > Sent: Wednesday, May 29, 2013 5:16 AM > To: Stephen Farrell > Cc: > Subject: Re: [http-auth] Call for Adoption: draft-ahrens-httpbis-digest- > auth-update >=20 > Hi Stephen. >=20 > Just one comment (with no hats) >=20 > On May 29, 2013, at 11:37 AM, Stephen Farrell > wrote: >=20 > > - I don't think adding a bagful of hash functions is > > useful, just adding sha256 would seem fine. Or I > > could buy other options if there are real use > > cases, but I bet there aren't. Question is: why > > not just add sha256 and be done with it? >=20 > People like algorithm agility. This might even save us from having to > process "SHA3-256 and its use in HTTP Authentication", "GOST R 34.11-94 > and its use in HTTP Authentication", and the same for djb2 and other > algorithms. >=20 > We probably want to make only sha256 MTI, else we don't get > interoperability. But what's the harm of adding a whole bagful? > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth From hallam@gmail.com Wed May 29 10:10:36 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 DADDE21F970B for ; Wed, 29 May 2013 10:10:36 -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 tpWT7bDG4NBU for ; Wed, 29 May 2013 10:10:36 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 6905821F9743 for ; Wed, 29 May 2013 10:10:32 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id e11so6498879wgh.2 for ; Wed, 29 May 2013 10:10:31 -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=waCeNPAUo9ayI+F5lrgWIrmFwWH42heKYuPuQ7dMeRI=; b=NNvAMSf/RMiHjHiIdNJIf67i/voPUGKotZTImSD7mw4NZo53EPeMSSJRcyk7ORQ1on p13MN3HLRSIdGkEftNTuLL5rnFFq96oBg3CU4Fz6vnt3s0SmfBAxTBgsaTOOGXucZCcp qqW6jElmHV6ah4G9GG1k7dgs4CdeuxumuQwLzJVMdN+PrFCT69iZ0XwMhNOOmr163Lqp OAPamaa60lRR2jFxDTT9at0sSFfbYB7fE+oHhezUKTSQ/sh5lrXx173aFDnTvQny4wcD FDtXQ4fDLdGs/QHZFHXfUMXgdBDCd8w5zfzIB1sWnRTRecLFwFIBYMllOYIZ3QyYpiGY zRXQ== MIME-Version: 1.0 X-Received: by 10.180.79.200 with SMTP id l8mr1952309wix.60.1369847431529; Wed, 29 May 2013 10:10:31 -0700 (PDT) Received: by 10.194.44.100 with HTTP; Wed, 29 May 2013 10:10:31 -0700 (PDT) In-Reply-To: <701DD8DF-75C8-4C87-8CC0-C293416C6578@checkpoint.com> References: <51A5BE32.1050200@cs.tcd.ie> <701DD8DF-75C8-4C87-8CC0-C293416C6578@checkpoint.com> Date: Wed, 29 May 2013 13:10:31 -0400 Message-ID: From: Phillip Hallam-Baker To: Yoav Nir Content-Type: multipart/alternative; boundary=f46d043bd7768d8d6304ddde75e8 Cc: "" Subject: Re: [http-auth] Call for Adoption: draft-ahrens-httpbis-digest-auth-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: Wed, 29 May 2013 17:10:37 -0000 --f46d043bd7768d8d6304ddde75e8 Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 29, 2013 at 5:15 AM, Yoav Nir wrote: > Hi Stephen. > > Just one comment (with no hats) > > On May 29, 2013, at 11:37 AM, Stephen Farrell > wrote: > > > - I don't think adding a bagful of hash functions is > > useful, just adding sha256 would seem fine. Or I > > could buy other options if there are real use > > cases, but I bet there aren't. Question is: why > > not just add sha256 and be done with it? > > People like algorithm agility. This might even save us from having to > process "SHA3-256 and its use in HTTP Authentication", "GOST R 34.11-94 and > its use in HTTP Authentication", and the same for djb2 and other algorithms. > > We probably want to make only sha256 MTI, else we don't get > interoperability. But what's the harm of adding a whole bagful? You don't get stronger security by adding support for stronger algorithms. You get stronger security by REMOVING support for weak algorithms. Hence a scheme with a mixed bag of weak and strong algorithms is no longer considered best practice for crypto. Pick one algorithm that you think will be secure and at most one backup. Make sure it is possible to add new algorithms at a later date. In this case the only problem with the construction is that it is unfashionable to use MD5 and it is easier to change this spec than to explain to people why MD5 is ok in this particular use. So moving from MD5 to SHA1 which has the same problem is not an improvement. My vote would be SHA2-256 with SHA3-256 as a backup. -- Website: http://hallambaker.com/ --f46d043bd7768d8d6304ddde75e8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, May 29, 2013 at 5:15 AM, Yoav Nir <ynir@checkpoint.com> wrote:
Hi Stephen.

Just one comment (with no hats)

On May 29, 2013, at 11:37 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

> - I don't think adding a bagful of hash functions is
> useful, just adding sha256 would seem fine. Or I
> could buy other options if there are real use
> cases, but I bet there aren't. Question is: why
> not just add sha256 and be done with it?

People like algorithm agility. This might even save us from having to= process "SHA3-256 and its use in HTTP Authentication", "GOS= T R 34.11-94 and its use in HTTP Authentication", and the same for djb= 2 and other algorithms.

We probably want to make only sha256 MTI, else we don't get interoperab= ility. But what's the harm of adding a whole bagful?
<= br>
You don't get stronger security by adding support f= or stronger algorithms.=A0

You get stronger security by REMOVING suppo= rt for weak algorithms.

Hence a scheme= with a mixed bag of weak and strong algorithms is no longer considered bes= t practice for crypto. Pick one algorithm that you think will be secure and= at most one backup. Make sure it is possible to add new algorithms at a la= ter date.

In this case the only problem with the cons= truction is that it is unfashionable to use MD5 and it is easier to change = this spec than to explain to people why MD5 is ok in this particular use. S= o moving from MD5 to SHA1 which has the same problem is not an improvement.=


My vote would be SHA2-= 256 with SHA3-256 as a backup.=A0
=A0

-= -
Website: http://hallambaker.com/<= /a>
--f46d043bd7768d8d6304ddde75e8-- From msporny@digitalbazaar.com Wed May 29 17:56:45 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A20221F90EE for ; Wed, 29 May 2013 17:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 EXb9YL5bkpyc for ; Wed, 29 May 2013 17:56:41 -0700 (PDT) Received: from mail.digitalbazaar.com (unknown [216.252.204.51]) by ietfa.amsl.com (Postfix) with ESMTP id EAD7D21F8700 for ; Wed, 29 May 2013 17:56:40 -0700 (PDT) Received: from [192.168.100.5] by mail.digitalbazaar.com with esmtp (Exim 4.72) (envelope-from ) id 1UhrAU-0002tj-EM for http-auth@ietf.org; Wed, 29 May 2013 20:56:39 -0400 Message-ID: <51A6A3C0.60100@digitalbazaar.com> Date: Wed, 29 May 2013 20:56:32 -0400 From: Manu Sporny User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.4) Gecko/20120510 Icedove/10.0.4 MIME-Version: 1.0 To: "" References: <51A5BE32.1050200@cs.tcd.ie> <701DD8DF-75C8-4C87-8CC0-C293416C6578@checkpoint.com> In-Reply-To: <701DD8DF-75C8-4C87-8CC0-C293416C6578@checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [http-auth] Call for Adoption: draft-ahrens-httpbis-digest-auth-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, 30 May 2013 00:56:45 -0000 On 05/29/2013 05:15 AM, Yoav Nir wrote: > On May 29, 2013, at 11:37 AM, Stephen Farrell wrote: >> Question is: why not just add sha256 and be done with it? > > People like algorithm agility. This might even save us from having > to process "SHA3-256 and its use in HTTP Authentication", "GOST R > 34.11-94 and its use in HTTP Authentication", and the same for djb2 > and other algorithms. I don't think that is a very compelling argument. The specification should outline the best practice at the time and if there is a need to update it to shift to another algorithm in the future, an add-on spec can be drafted purely for that case. Dumping a bag of algorithms into a spec is also really annoying from an implementers standpoint. Making sure your implementation has support and options for umpteen hashing algorithms is annoying, especially when 90% of the use cases just use the same algorithms, and the other 9% could use the same algorithms, but choose not to because they think it buys them some sort of advantage (when it usually does not). Bags of algorithms also confuse developers and make using the API really annoying in the default case where you just want to use a set of reasonable defaults. "Should I use SHA-256 or SHA-1? Hmm, let me see what the remote end is using... crap, they're using MD5." The Web Keys specifications as well as the Web Payments specifications all outline one way of hashing and encrypting/decrypting. There are backups that are ready to go when the current approaches fail, but the specs outline the best practice and make that the only normative implementation requirement. -1 to bags of algorithms in specs, we should stop this bad practice. -- manu -- Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) Founder/CEO - Digital Bazaar, Inc. blog: Meritora - Web payments commercial launch http://blog.meritora.com/launch/