From nobody Fri Jul 4 07:49:40 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB821B2D9E; Fri, 4 Jul 2014 07:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5fddTPsKl6oZ; Fri, 4 Jul 2014 07:49:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD461B2A5B; Fri, 4 Jul 2014 07:49:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704144937.2335.1288.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 07:49:37 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/8nXIapxQ-V2RxNGS6iTlF-p8wzI Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-scram-auth-02.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 14:49:38 -0000 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 : Salted Challenge Response (SCRAM) HTTP Authentication Mechanism Author : Alexey Melnikov Filename : draft-ietf-httpauth-scram-auth-02.txt Pages : 19 Date : 2014-07-04 Abstract: The secure authentication mechanism most widely deployed and used by Internet application protocols is the transmission of clear-text passwords over a channel protected by Transport Layer Security (TLS). There are some significant security concerns with that mechanism, which could be addressed by the use of a challenge response authentication mechanism protected by TLS. Unfortunately, the HTTP Digest challenge response mechanism presently on the standards track failed widespread deployment, and have had success only in limited use. This specification describes a family of HTTP authentication mechanisms called the Salted Challenge Response Authentication Mechanism (SCRAM), which addresses the security concerns and meets the deployability requirements. When used in combination with TLS or an equivalent security layer, a mechanism from this family could improve the status-quo for application protocol authentication. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-scram-auth/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-httpauth-scram-auth-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-scram-auth-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 4 08:26:11 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F04541B2A63; Fri, 4 Jul 2014 08:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NtFmjToreY-S; Fri, 4 Jul 2014 08:26:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 744961B29EC; Fri, 4 Jul 2014 08:26:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704152606.522.62339.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 08:26:06 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/egqNfympbQHkVpaoDbswKgb6F94 Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-basicauth-update-01.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 15:26:08 -0000 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 : The 'Basic' HTTP Authentication Scheme Author : Julian F. Reschke Filename : draft-ietf-httpauth-basicauth-update-01.txt Pages : 13 Date : 2014-07-04 Abstract: This document defines the "Basic" Hypertext Transfer Protocol (HTTP) Authentication Scheme, which transmits credentials as userid/password pairs, obfuscated by the use of Base64 encoding. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-basicauth-update/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-httpauth-basicauth-update-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-basicauth-update-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 4 08:43:07 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 343021B2DCC; Fri, 4 Jul 2014 08:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hP5VHy6i3xOh; Fri, 4 Jul 2014 08:42:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A8C11B2DC9; Fri, 4 Jul 2014 08:42:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704154252.11595.15130.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 08:42:52 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/Rm7jk0gMWOPE9AZEbA2e4RJsOG8 Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-basicauth-enc-04.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 15:43:02 -0000 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 : An Encoding Parameter for HTTP Basic Authentication Author : Julian F. Reschke Filename : draft-ietf-httpauth-basicauth-enc-04.txt Pages : 2 Date : 2014-07-04 Abstract: This draft is obsolete. Its contents has been integrated into draft-ietf-httpauth-basicauth-update-01. 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-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-basicauth-enc-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 4 09:31:25 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 276C31B2DC6; Fri, 4 Jul 2014 09:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxURtCzNLOqn; Fri, 4 Jul 2014 09:31:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E2F511B2D7C; Fri, 4 Jul 2014 09:31:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704163122.16197.49918.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 09:31:22 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/ILr8wo53uIMgUh-8GhsejUc93lo Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-scram-auth-03.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 16:31:24 -0000 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 : Salted Challenge Response (SCRAM) HTTP Authentication Mechanism Author : Alexey Melnikov Filename : draft-ietf-httpauth-scram-auth-03.txt Pages : 20 Date : 2014-07-04 Abstract: The secure authentication mechanism most widely deployed and used by Internet application protocols is the transmission of clear-text passwords over a channel protected by Transport Layer Security (TLS). There are some significant security concerns with that mechanism, which could be addressed by the use of a challenge response authentication mechanism protected by TLS. Unfortunately, the HTTP Digest challenge response mechanism presently on the standards track failed widespread deployment, and have had success only in limited use. This specification describes a family of HTTP authentication mechanisms called the Salted Challenge Response Authentication Mechanism (SCRAM), which addresses the security concerns and meets the deployability requirements. When used in combination with TLS or an equivalent security layer, a mechanism from this family could improve the status-quo for application protocol authentication. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-scram-auth/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-httpauth-scram-auth-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-scram-auth-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 4 09:36:44 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D42741A028B for ; Fri, 4 Jul 2014 09:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tH7Bmmkq9Khi for ; Fri, 4 Jul 2014 09:36:39 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 552AA1A0262 for ; Fri, 4 Jul 2014 09:36:39 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id z12so81078wgg.4 for ; Fri, 04 Jul 2014 09:36:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=blrJ+wEjNL7Jj3huxd7jDdh1RFeBY36MTYXLmMvX5OI=; b=sCnvw6iUBYmv8wXj1aOPLVXDv2WR6cXRq6vnAt6OS8u1xarR0cAv0VxM+IASqGlphE pnBPX+ss5m9/3HAJYweA96qLAXrQNngOAJ5AJZeE+IjRvis45KlUiaoXAMUO8BgFG5a/ I55wgzrLUC6P83/xRmfifcyLNXYOI7LlD2yXG0/vCVuPSvtHrGA+agTN1VFWe4SwivsF hiGJZetzyBhaDM4IVVPmf0kWnYJ3VxAl8oVF/1tQVFdLGbFl+6ulyMzJOKzn7tVhkXkD Zyjouy0yVn6hSURBf3It3Vc+sFWxOo0cUEjGc934wWAmILt1CeI+8lOytLnGI4wcIwsu HaEg== X-Received: by 10.180.108.208 with SMTP id hm16mr57201831wib.80.1404491797915; Fri, 04 Jul 2014 09:36:37 -0700 (PDT) Received: from [192.168.1.103] (bzq-84-109-50-18.red.bezeqint.net. [84.109.50.18]) by mx.google.com with ESMTPSA id wu6sm69985640wjb.46.2014.07.04.09.36.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 04 Jul 2014 09:36:37 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Yoav Nir In-Reply-To: <20140704152606.522.62339.idtracker@ietfa.amsl.com> Date: Fri, 4 Jul 2014 19:36:37 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <18B6BA3F-26F5-44BA-A024-DF457216F2E4@gmail.com> References: <20140704152606.522.62339.idtracker@ietfa.amsl.com> To: "Julian F. Reschke" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/DJf3WaiIs0VLBJ-S15CYq7mv9bU Cc: IETF HTTP Auth Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-basicauth-update-01.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 16:36:43 -0000 Thanks you, Julian! Group: we=92ll be discussing this draft at the Toronto meeting (Thursday = morning, 24-Jul). Please read it and send comments to the list. Yoav On Jul 4, 2014, at 6:26 PM, internet-drafts@ietf.org wrote: >=20 > 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. >=20 > Title : The 'Basic' HTTP Authentication Scheme > Author : Julian F. Reschke > Filename : draft-ietf-httpauth-basicauth-update-01.txt > Pages : 13 > Date : 2014-07-04 >=20 > Abstract: > This document defines the "Basic" Hypertext Transfer Protocol (HTTP) > Authentication Scheme, which transmits credentials as = userid/password > pairs, obfuscated by the use of Base64 encoding. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-httpauth-basicauth-update/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-httpauth-basicauth-update-01 >=20 > A diff from the previous version is available at: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-httpauth-basicauth-update-01= >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth From nobody Fri Jul 4 15:02:22 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 731FD1A0040; Fri, 4 Jul 2014 15:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWZRWnslxXuX; Fri, 4 Jul 2014 15:02:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3082A1A0025; Fri, 4 Jul 2014 15:02:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704220217.30291.17196.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 15:02:17 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/PCTr-U5Ze508BGa-HM1hJng_wdQ Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-mutual-algo-00.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 22:02:18 -0000 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 : Mutual Authentication Protocol for HTTP: KAM3-based Cryptographic Algorithms Authors : Yutaka Oiwa Hajime Watanabe Hiromitsu Takagi Kaoru Maeda Tatsuya Hayashi Yuichi Ioku Filename : draft-ietf-httpauth-mutual-algo-00.txt Pages : 15 Date : 2014-07-04 Abstract: This document specifies some cryptographic algorithms which will be used for the Mutual user authentication method for the Hyper-text Transport Protocol (HTTP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-mutual-algo/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-httpauth-mutual-algo-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Jul 5 05:44:09 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B873B1A04F1; Sat, 5 Jul 2014 05:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kutcfHeSbV9u; Sat, 5 Jul 2014 05:44:04 -0700 (PDT) Received: from emh01.mail.saunalahti.fi (emh01.mail.saunalahti.fi [62.142.5.107]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 837461A04CA; Sat, 5 Jul 2014 05:44:03 -0700 (PDT) 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 969A790049; Sat, 5 Jul 2014 15:44:00 +0300 (EEST) Date: Sat, 5 Jul 2014 15:44:00 +0300 From: Ilari Liusvaara To: http-auth@ietf.org Message-ID: <20140705124400.GA3684@LK-Perkele-VII> References: <20140704220217.30291.17196.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20140704220217.30291.17196.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/YixDXbgiVpKle7-k3Tikmpx2Hjo Cc: http-auth@ietf.org, i-d-announce@ietf.org Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-mutual-algo-00.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jul 2014 12:44:06 -0000 On Fri, Jul 04, 2014 at 03:02:17PM -0700, internet-drafts@ietf.org wrote: > > Filename : draft-ietf-httpauth-mutual-algo-00.txt Section 2.3: > where S_c1 is a random number within range [1, r-1]. The value of > K_c1 MUST represent a valid curve point, and K_c1' SHALL NOT be 0_E. > The server MUST check this condition upon reception. How this generalizes to non-cofactor-1 curves (those can be quite a bit faster than cofactor-1 ones)? Looking at the discrete-group algorithm, it generalizes as "valid point with large prime dividing order". So would: The value of K_c1 MUST represent a valid curve point, and [h]*K_c1' SHALL NOT be 0_E. The server MUST check this condition upon reception. Work? (0_E is the identity point, h is the curve cofactor.) > where S_s1 is a random number within range [1, r-1]. The value of > K_s1 MUST represent a valid curve point and satisfy [4] * P'(K_s1) <> > 0_E. If this condition is not satisfied, the server MUST retry using > another value for S_s1. The client MUST check this condition upon > reception. Same here. Also where does that multiplier 4 in check come from? Attempt at supporing h>1 curves (except that some stuff in use has h=8)? Should it be [h]*P'(K_s1) <> 0_E? Section 2.2&2.3: 2.2 has: > The value of K_s1 MUST satisfy 1 < K_s1 < q-1. If this condition > is not held, the server MUST retry using another value for S_s1. And 2.3: > The value of K_s1 MUST represent a valid curve point and satisfy > [4] * P'(K_s1) <> 0_E. If this condition is not satisfied, the > server MUST retry using another value for S_s1. If K_c1 has certain relationship (extremely unlikely) with J(pi), that will fail over and over again (no S_s1 works). Values of S_s1 that don't work are AFAICT very rare anyway (making failures be dominated by all sorts of calculation errors in K_s1). -Ilari From nobody Mon Jul 7 05:44:29 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 974361B2846 for ; Mon, 7 Jul 2014 05:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nwt0fu5tL65m for ; Mon, 7 Jul 2014 05:44:22 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CB4B1B2845 for ; Mon, 7 Jul 2014 05:44:22 -0700 (PDT) Received: from [192.168.1.106] ([217.91.35.233]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MP0LT-1X0XFT0VAl-006LMo; Mon, 07 Jul 2014 14:44:20 +0200 Message-ID: <53BA9621.5010108@gmx.de> Date: Mon, 07 Jul 2014 14:44:17 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Yoav Nir References: <20140704152606.522.62339.idtracker@ietfa.amsl.com> <18B6BA3F-26F5-44BA-A024-DF457216F2E4@gmail.com> In-Reply-To: <18B6BA3F-26F5-44BA-A024-DF457216F2E4@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:H4L1KIhmVTCqpFuBnrYenedUXV4PQujtSKeJN+SoXghes9q8GMs TswcSuJADBZUQRvbFDvb7lUt9XZHODVFu9N6xYDRs6C0hq3Ps5Jo7+wWTgIIzIsSf3aGAri atFGfuigz4rfiRlhcHfTxIbpRRtOzgYtckGZbvTBwjqGLY1auZOKLd6Y3HtAmsySRk/WgBt jEgE0LbP1pXaGCtBvOqMQ== Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/j_ERBKYYvCzTmT7Fw-U8N4dv7KU Cc: IETF HTTP Auth Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-basicauth-update-01.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 12:44:27 -0000 On 2014-07-04 18:36, Yoav Nir wrote: > Thanks you, Julian! > > Group: we’ll be discussing this draft at the Toronto meeting (Thursday morning, 24-Jul). Please read it and send comments to the list. > > Yoav > ... Indeed. It's late, and I'm sorry about that. So this has been put together in a kind of a hurry, so I totally expect that some more editorial work is needed (both with respect to structure and language). Other than that please look for: - security considerations - these are more or less the same as in RFC 2617, and if people want to improve those please go ahead, after all, this is the Security area (but keep in mind to focus on considerations *specific* to the Basic scheme). - we have some implementation specific stuff we may want to discuss in a new section (handling of ":" in user-id, NFC, ...) - the part about when credentials can be re-used and sent proactively needs to be rephrased (with respect to hierarchy in HTTP URLs, *and* tested) Best regards, Julian From nobody Mon Jul 7 07:15:37 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E2451A01A8 for ; Mon, 7 Jul 2014 07:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 056OFdPsZDin for ; Mon, 7 Jul 2014 07:15:34 -0700 (PDT) Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BEF71A011C for ; Mon, 7 Jul 2014 07:15:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1404742532; x=2268656132; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=CzCo3fi702L2QP+mK8dZ061DF47fi3feCwvz9fQMRys=; b=iRtfDWzep6fxD4K24L1PjnXVMDHlGo35efOn66Du3T6isH7QXROIUZaux9HFIsuD nb/1qfMVu0J2yVtwlUoe5Rrh3lHaDNpUMplCTtuvN02nKJKNaGDtycfA4RDbrBEb 44PDY57t+H3rkLNlfN9aixKJdKbrg1UEgnOaokVbLpRFsi2sVIqvXSDXVq/EL/vz Q19CIDEKok50/nAMIS2CnkXML54g8w/XLvsMWAHAt116JWYBXjTOE8mykXtWcpy+ ffGhTADbq+XkodqmqmxDe5zWPlHTk7jZYrbg++KWRJA3FU04bl5xnI+lynz70REk SLY47Ty/zX8cE4cyvHYDEQ==; Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id 1A.F9.32596.48BAAB35; Mon, 7 Jul 2014 07:15:32 -0700 (PDT) MIME-version: 1.0 Received: from relay4.apple.com ([17.128.113.87]) by local.mail-out.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTP id <0N8C00IMUI9LA6B0@local.mail-out.apple.com> for http-auth@ietf.org; Mon, 07 Jul 2014 07:15:32 -0700 (PDT) X-AuditID: 11973e15-f79d66d000007f54-0b-53baab84351f Received: from fenugreek.apple.com (fenugreek.apple.com [17.128.115.97]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay4.apple.com (Apple SCV relay) with SMTP id A3.73.03493.78BAAB35; Mon, 7 Jul 2014 07:15:35 -0700 (PDT) Received: from [17.153.49.136] (unknown [17.153.49.136]) by fenugreek.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0N8C005ECI9UJM60@fenugreek.apple.com> for http-auth@ietf.org; Mon, 07 Jul 2014 07:15:32 -0700 (PDT) Content-type: multipart/signed; boundary="Apple-Mail=_B0F16256-AE4B-405D-8B33-F28659FA96E0"; protocol="application/pkcs7-signature"; micalg=sha1 From: Michael Sweet In-reply-to: <20140704163122.16197.49918.idtracker@ietfa.amsl.com> Date: Mon, 07 Jul 2014 10:15:29 -0400 Message-id: <32E94943-CE0C-4D93-B1C3-868597606950@apple.com> References: <20140704163122.16197.49918.idtracker@ietfa.amsl.com> To: http-auth@ietf.org X-Mailer: Apple Mail (2.1878.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJLMWRmVeSWpSXmKPExsUiON3OWLdl9a5gg9nzjSw+7J/D5MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujH3nZ7IWzA6ouDtrOnsD4x3PLkZODgkBE4k/z7vZIWwxiQv3 1rN1MXJxCAnMYpK48PcqE0iCV0BQ4sfkeywQiZlMEjvOzGKH6Z6y+yEzRGIyk8S1xlWMcO2P e86xgzjMAlMYJWa+2ccC0iIs4CXRcf4hI4jNJqAm8XtSHyuIzSngJHFl8UMwm0VAVeL4nrms ELttJGYseAi2TkjAUeLcwQNsILYI0LEnplyDOkNe4sOH42DLJAQWsUmsm7eBeQKj0Cwkt89C dghIgllAW2LZwtfMsxg5gGwdickLGSHCphJP3m5ng7CtJX7OeQQVV5SY0v2QfQEj+ypGodzE zBzdzDwzvcSCgpxUveT83E2MkLgQ3cF4ZpXVIUYBDkYlHt4Dq3YGC7EmlhVX5h5ilOZgURLn PW21K1hIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QD420hw6trMnLuR4VmzXX8bXViU/lDLb/5 9wI0b9Rfmr5qqmLiy8KI5a+Wfr6kL7YmJaR3k/3ij3ZyCX/rpQp2f3uS5rY/bbM20wJP1vOr 7/wS03iXt/KDSpb5bn6dsMLCdI67O+NP/v5lqa+S5vRCq1Yk3YgnbHu73CnVO9MexumfOSv5 sWRNhRJLcUaioRZzUXEiACZArO5sAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUi2FCcqNu+elewwb4XmhYf9s9hcmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxr7zM1kLZgdU3J01nb2B8Y5nFyMnh4SAicSU3Q+ZIWwxiQv3 1rN1MXJxCAlMZpLYNfcZK4Qzi0nicc85dhCHWWAKo8TMN/tYQFp4BQwkXv18DNYuLOAl0XH+ ISOIzSagJvF7Uh8riM0p4CRxZfFDMJtFQFXi+J65rBC9NhIzFjxkB7GFBBwlzh08wAZiiwCd cWLKNXaIk+QlPnw4zj6BkW8Wst2zkOwGsZkFtCWWLXwNZHMA2ToSkxcyQoRNJZ683c4GYVtL /JzzCCquKDGl+yH7Akb2VYwCRak5iZUmeokFBTmpesn5uZsYwcFaGL6D8d8yq0OMAhyMSjy8 Emt3BguxJpYVV+YeYlQBGvFow+oLjFIsefl5qUoivCuW7woW4k1JrKxKLcqPLyrNSS0+xCjN waIkzqsEkhJITyxJzU5NLUgtgskycXBKNTBukgy7WvPkxNOCVd7b5dpibpSwe4Zm7l4Vbqb2 zCPasy43cHvNZz4/Bqe/4St/KxSHrb2V8dLiWF0Cn173BfblHaGFu95/fP/w+p+kN3UbVrVy z1hY+HzHkT3XtgUfyroTZSTxXfdP3q4Knh0hf3g02bY2q35IXrmkUj+dXetz6J0d3YmGS08q sRRnJBpqMRcVJwIAVwRZBF4CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/GK5ybN_pn0T5kROs3XBwBSL9DPI Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-scram-auth-03.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 14:15:36 -0000 --Apple-Mail=_B0F16256-AE4B-405D-8B33-F28659FA96E0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Quick comments: - Isn't SHA-1 broken? =20 - Saying that the username and password MUST be UTF-8 is not sufficient, = and I don't think you want to require that the client and server support = and try all normalization forms (which the text on page 6 would seem to = indicate) - I'm confused by what section 4 (SCRAM Mechanism Names) and section 8 = (IANA Considerations) are saying. Section 4 seems to indicate you are = registering a family of auth schemes starting with SCRAM-, but section 8 = says each one has to be registered and defined separately. If the = latter, I would prefer to see a non-broken hash function be defined = first and made mandatory. On Jul 4, 2014, at 12:31 PM, internet-drafts@ietf.org wrote: >=20 > 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. >=20 > Title : Salted Challenge Response (SCRAM) HTTP = Authentication Mechanism > Author : Alexey Melnikov > Filename : draft-ietf-httpauth-scram-auth-03.txt > Pages : 20 > Date : 2014-07-04 >=20 > Abstract: > The secure authentication mechanism most widely deployed and used by > Internet application protocols is the transmission of clear-text > passwords over a channel protected by Transport Layer Security = (TLS). > There are some significant security concerns with that mechanism, > which could be addressed by the use of a challenge response > authentication mechanism protected by TLS. Unfortunately, the HTTP > Digest challenge response mechanism presently on the standards track > failed widespread deployment, and have had success only in limited > use. >=20 > This specification describes a family of HTTP authentication > mechanisms called the Salted Challenge Response Authentication > Mechanism (SCRAM), which addresses the security concerns and meets > the deployability requirements. When used in combination with TLS = or > an equivalent security layer, a mechanism from this family could > improve the status-quo for application protocol authentication. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-httpauth-scram-auth/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-httpauth-scram-auth-03 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-httpauth-scram-auth-03 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Apple-Mail=_B0F16256-AE4B-405D-8B33-F28659FA96E0 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPJTCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBSIwggQKoAMC AQICEQDlB7dXxclLEedquPvGX8CGMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBMB4XDTEzMTIxNzAwMDAwMFoXDTE0MTIxNzIzNTk1OVowITEfMB0GCSqG SIb3DQEJARYQbXN3ZWV0QGFwcGxlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ANdvQYZRCVzc0wIYvIOn/0Pv7zUwuIvbAfM/W3FyemqZx3fdKxX4WxN2x5NC3hhBHGrUWirJH7rl 6It12bGQ61uHAK5jsJikV5k+mOYjZaKNIKxj0uYIk3MKQmsmM8t3nddq5mp2mxwV/U7AFPTz1fgh dkqTb/NkHY5eA8KqksaeqwfMgoaiGVeCUhptWnXosca8PAkb+i9u5rEok5zgY+QP0IuWLJENfA4q dEMsH+OAwMGOv9fNCgcdapFnjeSYaj70m6qUiq446+8a2rhUsEUKQayOMgjnm2bgUuNx7pOvs/Jg zIlZoTz/llmE1HWREGzSjRnLWwQ98fspfeZWA+8CAwEAAaOCAeAwggHcMB8GA1UdIwQYMBaAFHoT TgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTtKBJoG9kxZisTqJg4+wr12l4stjAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIw EQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUH AgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6 Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1h aWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9j YS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggr BgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMBsGA1UdEQQUMBKBEG1zd2VldEBhcHBs ZS5jb20wDQYJKoZIhvcNAQEFBQADggEBABg5KLQK5u9gGI75u+vYH/i6uMDKlpTILO/r/FpN2ibq pwAB2ln9oKvPIA1/r3o+DBC87TqnlJAiPW4ADFHpRmqlprb0Tu9p98nP/wl5tBZjEP8dY4iH0TB3 B2r9JHwRwwJQ20CqJpuCn9dmvL215sZSqvJfluVlIcAQCLxp3ZKMIC2pNKitswdjjHduaKuj2TMe xrzMtrRGRtFF9pcMcnsqE2QtJUqXPV7/M4WT2yRUmI4ThPt9O9fmPH2ku52hdb6t4qXvwdQSkDHt xo3J/Vc/jDR2/feedDhQmG0V9j6tHsuG6bVVhcGiWnSmSoPfg13FlQwlxZTyFtiMZ2jILyoxggOu MIIDqgIBATCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAOUHt1fFyUsR 52q4+8ZfwIYwCQYFKw4DAhoFAKCCAdkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTQwNzA3MTQxNTMwWjAjBgkqhkiG9w0BCQQxFgQU8HISE0cM5X38aSQCRrHirsXh +VkwgboGCSsGAQQBgjcQBDGBrDCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx OTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIRAOUHt1fFyUsR52q4+8ZfwIYwgbwGCyqGSIb3DQEJEAILMYGsoIGpMIGTMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgU2VjdXJlIEVtYWlsIENBAhEA5Qe3V8XJSxHnarj7xl/AhjANBgkqhkiG9w0BAQEFAASC AQANF1SPrHkEzNwSdHml7WOk5ncD1SmkZBqgxrezlXuDf9sjB8Jmrg3KdiSZIiH1Z5dTA1p7lpEc h0/G+avHdzuJzFl4d1fjm1XESHMFoUYy5vX9vLB5uW5pH7tkA003oSX7APAQAitG8yYmueiFVWnk Uakx1uVkVtFZMp3osVWV1ben3XsCid0ADGBl09Mjji8Ee3aMXFPIMh/hWkMfezpxbnwquPXe9bxU hwgJ4y2nIXFkrDD9QKG3LB5EJtkukcy3336EJ0fBxrJM+k/+TafrmREQM9QKEorId9c/EumftDrn I6Wky0yzduKT9vej1/cfAj519FFQccHPlqyngWsBAAAAAAAA --Apple-Mail=_B0F16256-AE4B-405D-8B33-F28659FA96E0-- From nobody Mon Jul 7 08:46:07 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51E6F1A0166 for ; Mon, 7 Jul 2014 08:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxRStR0ujyhF for ; Mon, 7 Jul 2014 08:45:59 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F3441A031F for ; Mon, 7 Jul 2014 08:45:59 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id u56so4629434wes.36 for ; Mon, 07 Jul 2014 08:45:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fsvPcSDJm2v2290mEUm5lsflJ8HeW+PRB5CEjeUFlTs=; b=EbUxeFPeWdESTSEqSmDpLO1om+KMPPiVc4/pFNdwJVnW7P39Zi+hJZZrstm1g/ou38 1f3wi33dy5Xe9Y5k1SPp58LPER7ZOHDvwOAnhyrXtFqhjUjAIEGWpyg8NZLa7L8r92iY aHjeV77b3M3YeQ5kxt08O0uptqzuaudVnHi/ky5pe2VwM2SBa6UGtIsFYqj5b/k87nZX LVCTh9KMRiC2eElCqe9L7CTwUySmUQvKBmXPOJ+BCOW59jWigpTW2YZkRju+ZvX+NOhX CVAWu6FWKEEAc7uar6mrOWELsuj3zIIWmttT3cUMSuZh9vzBvh/JWLrcdU+2cjOtR9n6 dTkQ== X-Received: by 10.180.184.36 with SMTP id er4mr36966719wic.37.1404747955087; Mon, 07 Jul 2014 08:45:55 -0700 (PDT) Received: from [10.4.37.47] ([80.179.9.115]) by mx.google.com with ESMTPSA id lq17sm15616240wic.19.2014.07.07.08.45.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 07 Jul 2014 08:45:54 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Yoav Nir In-Reply-To: <32E94943-CE0C-4D93-B1C3-868597606950@apple.com> Date: Mon, 7 Jul 2014 18:45:13 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140704163122.16197.49918.idtracker@ietfa.amsl.com> <32E94943-CE0C-4D93-B1C3-868597606950@apple.com> To: Michael Sweet X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/zPxqNFHcpQbYmc3HdG75QeWbjOw Cc: http-auth@ietf.org Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-scram-auth-03.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 15:46:02 -0000 On Jul 7, 2014, at 5:15 PM, Michael Sweet wrote: > Quick comments: >=20 > - Isn't SHA-1 broken? =20 Define =93broken=94. There is a break of collision resistance of SHA-1. That has been known = for over 5 years now, but for some reason, I don=92t believe anyone=92s = published a pair of colliding buffers. I guess once the theoretical = proof was there, the effort of actually creating colliding buffers = wasn=92t worth it. Anyway, SCRAM-Auth doesn=92t use straight SHA-1, but HMAC-SHA-1. AFAIK = this is still considered safe.=20 > - Saying that the username and password MUST be UTF-8 is not = sufficient, and I don't think you want to require that the client and = server support and try all normalization forms (which the text on page 6 = would seem to indicate) > - I'm confused by what section 4 (SCRAM Mechanism Names) and section 8 = (IANA Considerations) are saying. Section 4 seems to indicate you are = registering a family of auth schemes starting with SCRAM-, but section 8 = says each one has to be registered and defined separately. If the = latter, I would prefer to see a non-broken hash function be defined = first and made mandatory. SHA2-256 is our usual go-to algorithm these days, and HMAC-SHA2-256 is = widely implemented. But it=92s not like HMAC-SHA1 is considered broken. Yoav=20 (with no hats) From nobody Mon Jul 7 10:22:03 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C26F1A02F2 for ; Mon, 7 Jul 2014 10:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDqLRlqeEEKv for ; Mon, 7 Jul 2014 10:21:58 -0700 (PDT) Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2D761A035B for ; Mon, 7 Jul 2014 10:21:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1404753718; x=2268667318; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=68YvqyiwFuLr0Mzo4fY9si4IThquo+ySBtle1VpT5VI=; b=v0pi4tfaNxInC9EByszuCFz0eYGyvHNwm7XLCiPxAcUpd3is6TbsqHzs7E3fMHSf RtXudNn8ELVmbP/7axO1Y5mylw0fM+Gh2AQEKZyoLSYQhTxTpGXpw5JvTUT9tZka XVau0L7xIoprUGR2jARx+VnEXUwfW4G/W3wjIyj1uek+hA9nedMevf42OuebyeIy 8pD4R1pPPTLtI+Plxusj5LwDYZ8O4slSomS9DIY90rS1VivwsckcGgPSxdK0kVxd ao69BbUjXhVKK4aqGfALg9RqcnhnoGAjVfcZAkf6X3jc8PnX/O3aJdyCUhq9Smz6 4Itg10bQOVWI2nXNaWPKIg==; Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id C1.F5.32596.637DAB35; Mon, 7 Jul 2014 10:21:58 -0700 (PDT) MIME-version: 1.0 Received: from relay2.apple.com ([17.128.113.67]) by local.mail-out.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTP id <0N8C00BU1QWJCRM1@local.mail-out.apple.com> for http-auth@ietf.org; Mon, 07 Jul 2014 10:21:58 -0700 (PDT) X-AuditID: 11973e15-f79d66d000007f54-1c-53bad73687d6 Received: from fenugreek.apple.com (fenugreek.apple.com [17.128.115.97]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay2.apple.com (Apple SCV relay) with SMTP id 44.E1.19003.637DAB35; Mon, 7 Jul 2014 10:21:58 -0700 (PDT) Received: from [17.153.49.136] (unknown [17.153.49.136]) by fenugreek.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0N8C00H1WQWI1W40@fenugreek.apple.com> for http-auth@ietf.org; Mon, 07 Jul 2014 10:21:57 -0700 (PDT) Content-type: multipart/signed; boundary="Apple-Mail=_9FD183E0-569C-4672-9A66-34CFC988EAE5"; protocol="application/pkcs7-signature"; micalg=sha1 From: Michael Sweet In-reply-to: Date: Mon, 07 Jul 2014 13:21:54 -0400 Message-id: References: <20140704163122.16197.49918.idtracker@ietfa.amsl.com> <32E94943-CE0C-4D93-B1C3-868597606950@apple.com> To: Yoav Nir X-Mailer: Apple Mail (2.1878.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUiON3OUNfs+q5ggymnRSw+7J/D5MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujNc/P7IVLPKquHxzIUsD43eXLkZODgkBE4mzV2+wQthiEhfu rWfrYuTiEBKYxSQx7eolsASvgKDEj8n3WEBsIYGZTBKP51bANB9/84kZomEyk8Ti1cuY4bqb 904D6xAW8JLoOP+QEcRmFpjCKNH3PwXEZhNQk/g9qQ9sA6eArUTLkgNsIDaLgKrEzXcfmSHq xSQ6Hl5ig7jCRmLS351Q5y1nlDjUOR0sISKgJHH4yldmiJPkJT58OM4OUiQhsIhNYvmPi6wT GIVnIXljFpJDIGxtiWULXzND2AYSTztfsULYphJP3m5ng7CtJX7OecQIYStKTOl+yL6AkX0V o1BuYmaObmaemV5iQUFOql5yfu4mRki0iO5gPLPK6hCjAAejEg8vw5FdwUKsiWXFlbmHGKU5 WJTEeU9bAYUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwzkq6uO2cQqGH/beZorP/8XB5n896 /mD92j6Lv/8Czxz6/S53avWFH8f2L9zy+6SAiK/zrT95C1u52hr1T9iuYDlhuSertDriuMWH GzNVPIw3bjdYWvAveB+vdfYr6WfMzP9Y86sVLug+2yi09VlyVcY8f/dAy+2CP7hu7Pv4VJBV 4p3FnpSXIUosxRmJhlrMRcWJAPuQRUd3AgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUi2FCcqGt2fVewweut7BYf9s9hcmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxuufH9kKFnlVXL65kKWB8btLFyMnh4SAicTxN5+YIWwxiQv3 1rN1MXJxCAlMZpJ482AyO4Qzi0miee80FpAqYQEviY7zDxlBbF4BA4lXPx+DdTMLTGGU6Puf AmKzCahJ/J7UxwpicwrYSrQsOcAGYrMIqErcfPcRql5MouPhJTaIOTYSk/7uhNq8nFHiUOd0 sISIgJLE4Stfoc6Tl/jw4Tj7BEb+WUh2z0KyG8LWlli28DVU3EDiaecrVgjbVOLJ2+1sELa1 xM85jxghbEWJKd0P2Rcwsq9iFChKzUmsNNJLLCjISdVLzs/dxAgO4kLnHYzHllkdYhTgYFTi 4WU4sitYiDWxrLgy9xCjCtCIRxtWX2CUYsnLz0tVEuFdsRwozZuSWFmVWpQfX1Sak1p8iFGa g0VJnPfNFqCUQHpiSWp2ampBahFMlomDU6qBcZVxO/NyT6+YnbWKj40n+ooddlydVSNnJt27 8sGPq0z51w+mTTC/Lmbrz7Kh/5F/xuFtrGtPP5n/8FDOXqetWzi/nNhxs4tjwsPZzySnlNTN mSY0K+29Wvv0QxuPpnHv+dktIhLx5qDvOukTknwlso9/MvgvdPcSXyrofNnsw/uE629YRMtk LJVYijMSDbWYi4oTAUg6gGhqAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/GhDGpKWh-LimnG4elBDw_1SifWY Cc: http-auth@ietf.org Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-scram-auth-03.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 17:22:00 -0000 --Apple-Mail=_9FD183E0-569C-4672-9A66-34CFC988EAE5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Yoav, On Jul 7, 2014, at 11:45 AM, Yoav Nir wrote: >=20 > On Jul 7, 2014, at 5:15 PM, Michael Sweet wrote: >=20 >> Quick comments: >>=20 >> - Isn't SHA-1 broken? =20 >=20 > Define =93broken=94. As in deprecated by NIST and don't use for any new standards broken? (I know the TLS guys are pulling it from TLS 1.3, and it is not included = in the Digest update) > There is a break of collision resistance of SHA-1. That has been known = for over 5 years now, but for some reason, I don=92t believe anyone=92s = published a pair of colliding buffers. I guess once the theoretical = proof was there, the effort of actually creating colliding buffers = wasn=92t worth it. >=20 > Anyway, SCRAM-Auth doesn=92t use straight SHA-1, but HMAC-SHA-1. AFAIK = this is still considered safe.=20 Well, as long as the security guys are happy. >> - Saying that the username and password MUST be UTF-8 is not = sufficient, and I don't think you want to require that the client and = server support and try all normalization forms (which the text on page 6 = would seem to indicate) >> - I'm confused by what section 4 (SCRAM Mechanism Names) and section = 8 (IANA Considerations) are saying. Section 4 seems to indicate you are = registering a family of auth schemes starting with SCRAM-, but section 8 = says each one has to be registered and defined separately. If the = latter, I would prefer to see a non-broken hash function be defined = first and made mandatory. >=20 > SHA2-256 is our usual go-to algorithm these days, and HMAC-SHA2-256 is = widely implemented. But it=92s not like HMAC-SHA1 is considered broken. May I suggest, then, that we add HMAC-SHA2-256 to this document and make = *both* required? At least then we start out with a little bit of = algorithmic agility and don't need to immediately do a series of SCRAM = drafts (the next one could add HMAC-SHA3-256 and HMAC-SHAKE-256, once = that process is finished?) Oh, and definitely clear up the wording so that sections 4 and 8 = explicitly agree with each other. ("the intent is to define a family of = SCRAM-xxx authentication schemes. This document defines SCRAM-SHA-1 and = SCRAM-SHA2-256." or something like that in section 4...) _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Apple-Mail=_9FD183E0-569C-4672-9A66-34CFC988EAE5 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPJTCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBSIwggQKoAMC AQICEQDlB7dXxclLEedquPvGX8CGMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBMB4XDTEzMTIxNzAwMDAwMFoXDTE0MTIxNzIzNTk1OVowITEfMB0GCSqG SIb3DQEJARYQbXN3ZWV0QGFwcGxlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ANdvQYZRCVzc0wIYvIOn/0Pv7zUwuIvbAfM/W3FyemqZx3fdKxX4WxN2x5NC3hhBHGrUWirJH7rl 6It12bGQ61uHAK5jsJikV5k+mOYjZaKNIKxj0uYIk3MKQmsmM8t3nddq5mp2mxwV/U7AFPTz1fgh dkqTb/NkHY5eA8KqksaeqwfMgoaiGVeCUhptWnXosca8PAkb+i9u5rEok5zgY+QP0IuWLJENfA4q dEMsH+OAwMGOv9fNCgcdapFnjeSYaj70m6qUiq446+8a2rhUsEUKQayOMgjnm2bgUuNx7pOvs/Jg zIlZoTz/llmE1HWREGzSjRnLWwQ98fspfeZWA+8CAwEAAaOCAeAwggHcMB8GA1UdIwQYMBaAFHoT TgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTtKBJoG9kxZisTqJg4+wr12l4stjAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIw EQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUH AgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6 Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1h aWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9j YS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggr BgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMBsGA1UdEQQUMBKBEG1zd2VldEBhcHBs ZS5jb20wDQYJKoZIhvcNAQEFBQADggEBABg5KLQK5u9gGI75u+vYH/i6uMDKlpTILO/r/FpN2ibq pwAB2ln9oKvPIA1/r3o+DBC87TqnlJAiPW4ADFHpRmqlprb0Tu9p98nP/wl5tBZjEP8dY4iH0TB3 B2r9JHwRwwJQ20CqJpuCn9dmvL215sZSqvJfluVlIcAQCLxp3ZKMIC2pNKitswdjjHduaKuj2TMe xrzMtrRGRtFF9pcMcnsqE2QtJUqXPV7/M4WT2yRUmI4ThPt9O9fmPH2ku52hdb6t4qXvwdQSkDHt xo3J/Vc/jDR2/feedDhQmG0V9j6tHsuG6bVVhcGiWnSmSoPfg13FlQwlxZTyFtiMZ2jILyoxggOu MIIDqgIBATCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAOUHt1fFyUsR 52q4+8ZfwIYwCQYFKw4DAhoFAKCCAdkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTQwNzA3MTcyMTU0WjAjBgkqhkiG9w0BCQQxFgQUthUIK59TlY4pKBKGWcBbd0gm BA4wgboGCSsGAQQBgjcQBDGBrDCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx OTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIRAOUHt1fFyUsR52q4+8ZfwIYwgbwGCyqGSIb3DQEJEAILMYGsoIGpMIGTMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgU2VjdXJlIEVtYWlsIENBAhEA5Qe3V8XJSxHnarj7xl/AhjANBgkqhkiG9w0BAQEFAASC AQC+xDK1rUJQzZ7sUR2E8KWvnJZ0Fbh2m5bS0nrxdBi4Y4FylknxQfJgV36Wu7zM4mZcTIARXQX+ UQioxikaaCKLBSYdErzPAdwmvMVzpDC1X5UgKtune490+Lj+RF0k+S26BM/a2p6C1zlVf8O1s5qu DnGWbblQJIwKXTz9pp9WZkmPI9SpOZQzvJIMvpOIRTffQt2kJkL1X+Tfhh536Hh0tFx/8zJ0AehX 70LccRqMFo9QwRL8ldNASXQS2K8vlyPpVRha7Ss7JOPfPO1tUeQVrY3W0fHhPd5i5dBXOGAj3uEA dPylwFw+cswNbBkc92IUWe51ZI8LtN5/UyTQRHdlAAAAAAAA --Apple-Mail=_9FD183E0-569C-4672-9A66-34CFC988EAE5-- From nobody Tue Jul 8 12:21:20 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30DF81A024E for ; Tue, 8 Jul 2014 12:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QexO3pEJNMko for ; Tue, 8 Jul 2014 12:21:12 -0700 (PDT) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5B851A02D7 for ; Tue, 8 Jul 2014 12:21:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1404847272; x=2268760872; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=RH7s/euar/eBo4sp7qUKFjrEDQ1alCPKVKeSbxVmCGk=; b=XDaXAZqVjwEOhb1y9zzmLL9COMx41P7aGNbsQshFTao2Bfibr9CZF0xUcfRVONAP chKlrGLmyKuQ2js4WCwciPeQvi5pppzzabOLfdpYNzHON6VK6TPuMNZXMKurKXSF txNO8LYg0bryGR6vUvodCWRkT9pqgcLuosPAooDznHTD5OrBXlxbQ90Df2COxpqs NsM9UKAYGvBcCWI1U/vgPczVDRP5glHWf9DqUr89WOja38NzOXTwakWCjHage5js HDnvxMdTr5Pxnu7m5ANlVvZoRbLpDXSVUTd+bJx1i4KyHOUYGXXAUyAtDZcAOCn0 wKamx4g6EwDbvKuONhpK2Q==; Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id AB.8A.08063.8A44CB35; Tue, 8 Jul 2014 12:21:12 -0700 (PDT) MIME-version: 1.0 Received: from relay3.apple.com ([17.128.113.83]) by local.mail-out.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTP id <0N8E00HJYR2NLQ42@local.mail-out.apple.com> for http-auth@ietf.org; Tue, 08 Jul 2014 12:21:12 -0700 (PDT) X-AuditID: 11973e13-f79d56d000001f7f-f3-53bc44a8e3bd Received: from fenugreek.apple.com (fenugreek.apple.com [17.128.115.97]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay3.apple.com (Apple SCV relay) with SMTP id 8B.78.08757.AA44CB35; Tue, 8 Jul 2014 12:21:14 -0700 (PDT) Received: from [17.153.49.136] (unknown [17.153.49.136]) by fenugreek.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0N8E00273R397P70@fenugreek.apple.com> for http-auth@ietf.org; Tue, 08 Jul 2014 12:21:12 -0700 (PDT) From: Michael Sweet Content-type: multipart/signed; boundary="Apple-Mail=_E83F8A72-58CD-452E-9A07-657CF14EB03E"; protocol="application/pkcs7-signature"; micalg=sha1 Date: Tue, 08 Jul 2014 15:21:09 -0400 To: http-auth@ietf.org Message-id: <9F9B2F65-031C-43A1-84F3-8A3B0CC24E0C@apple.com> X-Mailer: Apple Mail (2.1878.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUiON3OSHeFy55ggysHxS0+7J/D5MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujP17r7EUXHGqeHw1oYHxo10XIyeHhICJxLwbp5ggbDGJC/fW s4HYQgKzmCSm9QWB2LwCghI/Jt9jgYjPZJLYvDEKpnfRzXbGLkYuoPhkJolLd0CKuCCa16w5 DTaVTUBN4vekPlaQBLPAFEaJpqfPwBIsAqoSHyc/YAaxhQWcJd6cOccIYosAnXFiyjV2iNU2 Egc2zmSGWCcv8eHDcXaQQRICzWwSa+bdZpzAKDALyYmzkC0BSTALaEssW/iaeRYjB5CtIzF5 ISNE2FTiydvtbBC2tcTPOY+g4ooSU7ofsi9gZF/FKJSbmJmjm5lnqpdYUJCTqpecn7uJERLg wjsYT6+yOsQowMGoxMOrwLMnWIg1say4MvcQozQHi5I471xpoJBAemJJanZqakFqUXxRaU5q 8SFGJg5OqQZGw8QDxwTrFJ2j2Swd3ylO6MwsY76YeK/3R/Lp+zweDUYrU5q3+nr/WiuwPijw y+m7UxSnLZ78UtSh23+9cJTBxm1HqguWv9Y6eIllhfpM0bsX389ST/Wo/vnj1ZEpEjGnbRn0 cq19fc5s3NmREOp36k7Z3EnvoqeanK9N+Dd5te8FXd7Ew0yqSizFGYmGWsxFxYkAq7YLY1EC AAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrELMWRmVeSWpSXmKPExsUi2FCcqLvKZU+wwfUf0hYf9s9hcmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxv6911gKrjhVPL6a0MD40a6LkZNDQsBEYtHNdkYIW0ziwr31 bF2MXBxCApOZJP5tP8cM4cxikliz5jQTSBWbgJrE70l9rCAJZoEpjBJNT5+BJVgEVCU+Tn7A DGILCzhLvDlzDmysCNDYE1OusYPYvAI2Egc2zmSGsA0kXv18zAyxWl7iw4fj7BMYeWYhmzsL SR2IzSygLbFs4WsgmwPI1pGYvJARImwq8eTtdjYI21ri55xHUHFFiSndD9kXMLKvYhQoSs1J rDTWSywoyEnVS87P3cQIDr3C4B2Mf5ZZHWIU4GBU4uFV4NkTLMSaWFZcmXuIUQVoxKMNqy8w SrHk5eelKonwLhcESvOmJFZWpRblxxeV5qQWH2KU5mBREuf9cnx3sJBAemJJanZqakFqEUyW iYNTqoFRYNKkds7/vvUhK2yX333k1i7ZlHr30Kwfj1xLrOwin6YbPnx3a6rwl3LP609Vf2+8 z+jEHcL2pEJ1t+n141MWrU9m/q70L+nywxkHpW68yvvYyzptwtvz+y6HWj3VkXILeX7+vzFT ztne/b2n/76O12X//XirFWOqVOAJaesJoVefz/ULuyTNp8RSnJFoqMVcVJwIAAoaSJpFAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/76cI-TGsDH0rWJJG5PGueSXsEd8 Subject: [http-auth] Proposal: username parameter for HTTP Basic authentication X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 19:21:17 -0000 --Apple-Mail=_E83F8A72-58CD-452E-9A07-657CF14EB03E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii All, I'd like to propose a new "username" parameter for the HTTP Basic = Update: http://tools.ietf.org/html/draft-ietf-httpauth-basicauth-update-01 The purpose of this parameter is to provide the username to be used with = a password provided by the user/client. The use case is authenticated = access to an embedded device such as a printer, video camera, router, = etc. where separate user accounts may not make sense but where you want = to have some form of authentication to prevent casual access to the = device. Currently you have to remember what a given device's chosen = username is ("root", "admin", "user", "config", etc.), which makes for a = poor user experience. AirPrint has been using this parameter as an extension to HTTP Basic for = several years now... The text changes are outlined below... .... Section 2 (The 'Basic' Authentication Scheme), add a new bullet: o the authentication parameter "username" is OPTIONAL (see Section = 2.2) New Section 2.2 (The 'username' auth-param) with the following text: In challenges, servers can use the "username" authentication parameter = to indicate the only supported "userid" value that can be supplied in a = subsequent Authorization request header. The value MUST conform to the = "userid" ABNF rules. _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Apple-Mail=_E83F8A72-58CD-452E-9A07-657CF14EB03E Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPJTCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBSIwggQKoAMC AQICEQDlB7dXxclLEedquPvGX8CGMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBMB4XDTEzMTIxNzAwMDAwMFoXDTE0MTIxNzIzNTk1OVowITEfMB0GCSqG SIb3DQEJARYQbXN3ZWV0QGFwcGxlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ANdvQYZRCVzc0wIYvIOn/0Pv7zUwuIvbAfM/W3FyemqZx3fdKxX4WxN2x5NC3hhBHGrUWirJH7rl 6It12bGQ61uHAK5jsJikV5k+mOYjZaKNIKxj0uYIk3MKQmsmM8t3nddq5mp2mxwV/U7AFPTz1fgh dkqTb/NkHY5eA8KqksaeqwfMgoaiGVeCUhptWnXosca8PAkb+i9u5rEok5zgY+QP0IuWLJENfA4q dEMsH+OAwMGOv9fNCgcdapFnjeSYaj70m6qUiq446+8a2rhUsEUKQayOMgjnm2bgUuNx7pOvs/Jg zIlZoTz/llmE1HWREGzSjRnLWwQ98fspfeZWA+8CAwEAAaOCAeAwggHcMB8GA1UdIwQYMBaAFHoT TgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTtKBJoG9kxZisTqJg4+wr12l4stjAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIw EQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUH AgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6 Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1h aWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9j YS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggr BgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMBsGA1UdEQQUMBKBEG1zd2VldEBhcHBs ZS5jb20wDQYJKoZIhvcNAQEFBQADggEBABg5KLQK5u9gGI75u+vYH/i6uMDKlpTILO/r/FpN2ibq pwAB2ln9oKvPIA1/r3o+DBC87TqnlJAiPW4ADFHpRmqlprb0Tu9p98nP/wl5tBZjEP8dY4iH0TB3 B2r9JHwRwwJQ20CqJpuCn9dmvL215sZSqvJfluVlIcAQCLxp3ZKMIC2pNKitswdjjHduaKuj2TMe xrzMtrRGRtFF9pcMcnsqE2QtJUqXPV7/M4WT2yRUmI4ThPt9O9fmPH2ku52hdb6t4qXvwdQSkDHt xo3J/Vc/jDR2/feedDhQmG0V9j6tHsuG6bVVhcGiWnSmSoPfg13FlQwlxZTyFtiMZ2jILyoxggOu MIIDqgIBATCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAOUHt1fFyUsR 52q4+8ZfwIYwCQYFKw4DAhoFAKCCAdkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTQwNzA4MTkyMTEwWjAjBgkqhkiG9w0BCQQxFgQUVYv/q7yhVFDpAd8mCn0ZkX3S YFIwgboGCSsGAQQBgjcQBDGBrDCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx OTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIRAOUHt1fFyUsR52q4+8ZfwIYwgbwGCyqGSIb3DQEJEAILMYGsoIGpMIGTMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgU2VjdXJlIEVtYWlsIENBAhEA5Qe3V8XJSxHnarj7xl/AhjANBgkqhkiG9w0BAQEFAASC AQAeiUwcyYfSi9/dIVZrluWd7HZoyrV+O400KWuE/3hUnrTKuC92/MAdDHR3bKbLY07LoJmYc+hQ ERXJRC7V/h5q40H1KnTrds5cuGjvORSE9iL3w3gqTyOYzPfNEhSbmEJcIMPUlEXJqCs0J5Ag3fIT KB+MqiJydTgLUPdq4rOCwRAIFtc2xScT0Gm63wFvsHofKSRzfCLn1rvUHFTVigDu35f43t0C2n7P dOhUHAu6Be+UwyMzlbJU02m4fXzyfEN6p3dCNNeu91qgluHEncRNcQSNffOFjmrFqYu/rrAE2egH tm4JXTJITSUti7FA/rJY5Ec2aAeG7eeDs8HEckVpAAAAAAAA --Apple-Mail=_E83F8A72-58CD-452E-9A07-657CF14EB03E-- From nobody Tue Jul 8 14:36:26 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F56C1A013B for ; Tue, 8 Jul 2014 14:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVvLmay1941F for ; Tue, 8 Jul 2014 14:36:23 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A034B1A0117 for ; Tue, 8 Jul 2014 14:36:22 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id x48so6532888wes.37 for ; Tue, 08 Jul 2014 14:36:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=gv7Au8dcLdLMxTXmpYA3blnyJfgPaIewjQr4LhgJjvw=; b=yAnyabi/uaV91EV3aUJiBEQs35wROkUrvuQRFX2lN5r+IVeZp8tRylvkUl+obEpLOD CtC4m5A1UXH8URnjbgg3cbB/FiuuxmvDaLV8uvfWioXqByWbOOm/pugl5UrIrGlQhbxb K2CPlC9YVoHbKoEwudTl8k/a17Ok73Yq0lC7q9KnEg6G1DrhivEBLW1SVecpA2TOesi6 iWiHLqEXs4z78zITP3yIfnSfZJC5XKU+IlWJ2Sx3dxvgCuKO5lTMfZ6C+0sp6/0d9znD Ntj8jGaWqUrPLwhDjjxZp6+rioG2gw8Ox55eApq/RRJYWsBfIMl+Fp5own32XhzeirIZ 1Dhw== X-Received: by 10.180.104.40 with SMTP id gb8mr6643431wib.59.1404855381194; Tue, 08 Jul 2014 14:36:21 -0700 (PDT) Received: from [192.168.1.101] (bzq-84-109-50-18.red.bezeqint.net. [84.109.50.18]) by mx.google.com with ESMTPSA id gc5sm11494377wic.6.2014.07.08.14.36.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 08 Jul 2014 14:36:20 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_E2D84778-3D53-49C3-AD96-CCCFB92DF142" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Yoav Nir In-Reply-To: <9F9B2F65-031C-43A1-84F3-8A3B0CC24E0C@apple.com> Date: Wed, 9 Jul 2014 00:36:17 +0300 Message-Id: <0DCD8299-B5AE-4609-BD01-2D3F03EBF872@gmail.com> References: <9F9B2F65-031C-43A1-84F3-8A3B0CC24E0C@apple.com> To: Michael Sweet X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/eDVKSUrkeK8i5JVoC5kfAXBFAG0 Cc: http-auth@ietf.org Subject: Re: [http-auth] Proposal: username parameter for HTTP Basic authentication X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 21:36:24 -0000 --Apple-Mail=_E2D84778-3D53-49C3-AD96-CCCFB92DF142 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, Michael. Just to make sure that I understand you correctly, in your use case = there are two people (let=92s call them =93Michael=94 and =93Yoav=94) = but only one userid, let=92s say =93prtuser=94, There is a single = password: =93passw0rd=94 (because we care about security) So the client sends something like: Authorization: Basic cHJ0dXNlcjpwYXNzdzByZA=3D=3D username=3D=93Michael" So what does the server do with this string? Does it appear in a log? = Does the server verify that it belongs to some list of authorized users? = It=92s pretty easy to spoof if I know your username and the = userid/password combination. So I=92m not sure it counts as = =93authentication=94, although it might be useful. Yoav On Jul 8, 2014, at 10:21 PM, Michael Sweet wrote: > All, >=20 > I'd like to propose a new "username" parameter for the HTTP Basic = Update: >=20 > http://tools.ietf.org/html/draft-ietf-httpauth-basicauth-update-01 >=20 > The purpose of this parameter is to provide the username to be used = with a password provided by the user/client. The use case is = authenticated access to an embedded device such as a printer, video = camera, router, etc. where separate user accounts may not make sense but = where you want to have some form of authentication to prevent casual = access to the device. Currently you have to remember what a given = device's chosen username is ("root", "admin", "user", "config", etc.), = which makes for a poor user experience. >=20 > AirPrint has been using this parameter as an extension to HTTP Basic = for several years now... >=20 > The text changes are outlined below... >=20 > .... >=20 > Section 2 (The 'Basic' Authentication Scheme), add a new bullet: >=20 > o the authentication parameter "username" is OPTIONAL (see Section = 2.2) >=20 > New Section 2.2 (The 'username' auth-param) with the following text: >=20 > In challenges, servers can use the "username" authentication parameter = to indicate the only supported "userid" value that can be supplied in a = subsequent Authorization request header. The value MUST conform to the = "userid" ABNF rules. >=20 > _________________________________________________________ > Michael Sweet, Senior Printing System Engineer, PWG Chair --Apple-Mail=_E2D84778-3D53-49C3-AD96-CCCFB92DF142 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi, = Michael.

Just to make sure that I understand you = correctly, in your use case there are two people (let=92s call them = =93Michael=94 and =93Yoav=94) but only one userid, let=92s say = =93prtuser=94, There is a single password: =93passw0rd=94 (because we = care about security)

So the client sends = something like:
Authorization: Basic cHJ0dXNlcjpwYXNzdzByZA=3D=3D= username=3D=93Michael"

So what does the server = do with this string? Does it appear in a log? Does the server verify = that it belongs to some list of authorized users?  It=92s pretty = easy to spoof if I know your username and the userid/password = combination.  So I=92m not sure it counts as =93authentication=94= , although it might be useful.

Yoav

On Jul 8, 2014, at 10:21 PM, Michael = Sweet <msweet@apple.com> = wrote:

All,

I'd like to propose a new "username" parameter = for the HTTP Basic Update:

   http://tools.ietf.org/html/draft-ietf-httpauth-basicauth-update-01
The purpose of this parameter is to provide the username to be = used with a password provided by the user/client.  The use case is = authenticated access to an embedded device such as a printer, video = camera, router, etc. where separate user accounts may not make sense but = where you want to have some form of authentication to prevent casual = access to the device.  Currently you have to remember what a given = device's chosen username is ("root", "admin", "user", "config", etc.), = which makes for a poor user experience.

AirPrint has been using = this parameter as an extension to HTTP Basic for several years = now...

The text changes are outlined = below...

....

Section 2 (The 'Basic' Authentication = Scheme), add a new bullet:

   o  the = authentication parameter "username" is OPTIONAL (see Section = 2.2)

New Section 2.2 (The 'username' auth-param) with the = following text:

In challenges, servers can use the "username" = authentication parameter to indicate the only supported "userid" value = that can be supplied in a subsequent Authorization request header. The = value MUST conform to the "userid" ABNF = rules.

_________________________________________________________Michael Sweet, Senior Printing System Engineer, PWG = Chair

= --Apple-Mail=_E2D84778-3D53-49C3-AD96-CCCFB92DF142-- From nobody Tue Jul 8 17:09:42 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC6F71A0194 for ; Tue, 8 Jul 2014 17:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6DLNpoZNd41 for ; Tue, 8 Jul 2014 17:09:35 -0700 (PDT) Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 718691A0190 for ; Tue, 8 Jul 2014 17:09:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1404864574; x=2268778174; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=tySDvdcaxwBr08nt3WOGuIDBJHcIcBZHagFL7lym51A=; b=EdwNaxz7Xsg7rtH8Y4ZR7oBvHIEG+l0MgCyVhuAmhCmjrV/+fkMbOj5Jx8lVpZZB 6GGQOS+y4hiaDZpLB8Ow3JJAxtazN2xpYGjpLqbMtS34OZzeGvR/q8Fcw7JeWKUg 1wzO0fEQUOCgEiHAA8w8crCYnveGT/OMHFaXGQDoIsgilDhRqgj+v1qL0Ob/rI50 bGx3s0DjfQUhRF/rhORmfyN/P3MyQasDlHFemWiV0IDBwnoKwG8SBriutfyhN320 DFrF6phYTHROhyXlmdcFGZXpLoZH2pqOk9XCYblMtudpWP2Xqcl52AXwqZa8wY6d koEN8KWeWxvkRWHBbnzrHg==; Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id C3.15.09894.E388CB35; Tue, 8 Jul 2014 17:09:34 -0700 (PDT) MIME-version: 1.0 Received: from relay7.apple.com ([17.128.113.101]) by local.mail-out.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTP id <0N8F00GX64FJUSK1@local.mail-out.apple.com> for http-auth@ietf.org; Tue, 08 Jul 2014 17:09:34 -0700 (PDT) X-AuditID: 11973e11-f79256d0000026a6-bf-53bc883e37f2 Received: from fenugreek.apple.com (fenugreek.apple.com [17.128.115.97]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay7.apple.com (Apple SCV relay) with SMTP id 94.D7.19908.C288CB35; Tue, 8 Jul 2014 17:09:16 -0700 (PDT) Received: from [17.153.49.136] (unknown [17.153.49.136]) by fenugreek.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0N8F00CZW4FV5130@fenugreek.apple.com> for http-auth@ietf.org; Tue, 08 Jul 2014 17:09:34 -0700 (PDT) Content-type: multipart/signed; boundary="Apple-Mail=_779EE972-1596-466F-9128-A32E5B96F4BE"; protocol="application/pkcs7-signature"; micalg=sha1 From: Michael Sweet In-reply-to: <0DCD8299-B5AE-4609-BD01-2D3F03EBF872@gmail.com> Date: Tue, 08 Jul 2014 20:09:32 -0400 Message-id: <7957705E-E585-4A10-9876-34F10F9FAB6E@apple.com> References: <9F9B2F65-031C-43A1-84F3-8A3B0CC24E0C@apple.com> <0DCD8299-B5AE-4609-BD01-2D3F03EBF872@gmail.com> To: Yoav Nir X-Mailer: Apple Mail (2.1878.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkkeLIzCtJLcpLzFFi42IRnG5nqGvXsSfY4NY5K4sP++cwOTB6LFny kymAMYrLJiU1J7MstUjfLoEr4/vn7SwFZ+oqZn64w97A2FbcxcjJISFgInH49CcWCFtM4sK9 9WxdjFwcQgIzmSQez7zOBpLgFRCU+DH5HgtEYhaTxKTz/9lhuvceOcUOkZjMJNHZ94QNrqpn 7z9GkCphgVCJFfd3sIIkmAWmMEqsPrQLbC6bgJrE70l9rCA2p4CtxKZP/WA2i4CqxMyTS8Fs ZqCjOh5egrrDRmLPn5NgtpBAvsSllrdgh4sIKEkcvvKVGeIkeYkPH45DnbePTWLuQYUJjMKz kLwxC9kds8B2JEkse3CTBcLWlli28DUzhG0g8bTzFSumuL7Em3dzmCBsU4knb7dDzbGW+Dnn ESOErSgxpfsh+wJGrlWMQrmJmTm6mXlGeokFBTmpesn5uZsYIXEnuIPx+CqrQ4wCHIxKPLwK PHuChVgTy4orcw8xSnOwKInzzpUGCgmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamAMYLa4mnyv W9G4gG3mDNumnzuMFb50amTnzJGTOhjY2qQ4d9Fj49oIz+OOJttdYr/xCM1/3ci3rcjpY4Oa /+yd73sunlCqDpv26Gk644oNN153mIQpzhA8u0uN1S5J98EXp8On3Cb8u5528lHc62vWj/+4 bXjKPf+n+r+Xc9n7lrA5NgRqMXIosRRnJBpqMRcVJwIA8CLI1pwCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUi2FCcqKvTsSfY4MM8Y4sP++cwOTB6LFny kymAMYrLJiU1J7MstUjfLoEr4/vn7SwFZ+oqZn64w97A2FbcxcjJISFgIrH3yCl2CFtM4sK9 9WxdjFwcQgKTmSTuLn8K5cxikujZ+48RpEpYIFRixf0drCA2r4CBxKufj5lBipgFpjBKrD60 iw0kwSagJvF7Uh9YEaeArcSmT/1gNouAqsTMk0vBbGagdR0PL7FBDLKR2PPnJJgtJJAvcanl LQuILSKgJHH4yldmiPPkJT58OM4+gZF/FpLds5DtngU2N0li2YObLBC2tsSyha+ZIWwDiaed r1gxxfUl3rybwwRhm0o8ebsdao61xM85jxghbEWJKd0P2Rcwcq1iFChKzUmsNNdLLCjISdVL zs/dxAiOh8LUHYyNy60OMQpwMCrx8Crw7AkWYk0sK67MPcSoAjTi0YbVFxilWPLy81KVRHi/ uQGleVMSK6tSi/Lji0pzUosPMUpzsCiJ8z48vjtYSCA9sSQ1OzW1ILUIJsvEwSnVwJiqzlAf eFn36/nK/8dXSQQFh+6UMYvYfGuvhMevc5OkTrt1Oeh3pB9a/1TUPuHL/DcXrZ2KIhf/VJT5 f1cwyLIkMbVHITh/WU7V4lP6ka3Jxiv86t3Y99zfqCVsmfeZz2On4G05G6ubJ5R8wnjtvnPl Ry95ZFbvKHHs09mah9crBEXOv+hnUmIpzkg01GIuKk4EANQ2AECPAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/HuyXavVCCYNDeeMqse_aZVHJMg4 Cc: http-auth@ietf.org Subject: Re: [http-auth] Proposal: username parameter for HTTP Basic authentication X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 00:09:37 -0000 --Apple-Mail=_779EE972-1596-466F-9128-A32E5B96F4BE Content-Type: multipart/alternative; boundary="Apple-Mail=_1D132F9C-1068-4989-9869-7CEE32C21E1C" --Apple-Mail=_1D132F9C-1068-4989-9869-7CEE32C21E1C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Yoav, On Jul 8, 2014, at 5:36 PM, Yoav Nir wrote: > Hi, Michael. >=20 > Just to make sure that I understand you correctly, in your use case = there are two people (let=92s call them =93Michael=94 and =93Yoav=94) = but only one userid, let=92s say =93prtuser=94, There is a single = password: =93passw0rd=94 (because we care about security) >=20 > So the client sends something like: > Authorization: Basic cHJ0dXNlcjpwYXNzdzByZA=3D=3D username=3D=93Michael"= No, the client just sends the standard Authorization header as before, = with "prtuser:passw0rd" Base64-encoded into the auth string like so: Authorization: Basic cHJ0dXNlcjpwYXNzdzByZA=3D=3D The challenge from the server for this would look like: WWW-Authenticate: Basic realm=3D"My Super Secure = Printer",charset=3D"UTF-8",username=3D"prtuser" > So what does the server do with this string? Does it appear in a log? = Does the server verify that it belongs to some list of authorized users? = It=92s pretty easy to spoof if I know your username and the = userid/password combination. So I=92m not sure it counts as = =93authentication=94, although it might be useful. The server is just authenticating as usual, and the "username" in the = WWW-Authenticate header tells the client that there is only one possible = username/account to authenticate against. >=20 > Yoav >=20 > On Jul 8, 2014, at 10:21 PM, Michael Sweet wrote: >=20 >> All, >>=20 >> I'd like to propose a new "username" parameter for the HTTP Basic = Update: >>=20 >> http://tools.ietf.org/html/draft-ietf-httpauth-basicauth-update-01 >>=20 >> The purpose of this parameter is to provide the username to be used = with a password provided by the user/client. The use case is = authenticated access to an embedded device such as a printer, video = camera, router, etc. where separate user accounts may not make sense but = where you want to have some form of authentication to prevent casual = access to the device. Currently you have to remember what a given = device's chosen username is ("root", "admin", "user", "config", etc.), = which makes for a poor user experience. >>=20 >> AirPrint has been using this parameter as an extension to HTTP Basic = for several years now... >>=20 >> The text changes are outlined below... >>=20 >> .... >>=20 >> Section 2 (The 'Basic' Authentication Scheme), add a new bullet: >>=20 >> o the authentication parameter "username" is OPTIONAL (see = Section 2.2) >>=20 >> New Section 2.2 (The 'username' auth-param) with the following text: >>=20 >> In challenges, servers can use the "username" authentication = parameter to indicate the only supported "userid" value that can be = supplied in a subsequent Authorization request header. The value MUST = conform to the "userid" ABNF rules. >>=20 >> _________________________________________________________ >> Michael Sweet, Senior Printing System Engineer, PWG Chair >=20 _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Apple-Mail=_1D132F9C-1068-4989-9869-7CEE32C21E1C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Yoav,

On Jul 8, 2014, at 5:36 PM, = Yoav Nir <ynir.ietf@gmail.com> = wrote:
Hi, Michael.

Just to make sure = that I understand you correctly, in your use case there are two people = (let=92s call them =93Michael=94 and =93Yoav=94) but only one userid, = let=92s say =93prtuser=94, There is a single password: =93passw0rd=94 = (because we care about security)

So the client = sends something like:
Authorization: Basic cHJ0dXNlcjpwYXNzdzByZA=3D=3D = username=3D=93Michael"

No, = the client just sends the standard Authorization header as before, with = "prtuser:passw0rd" Base64-encoded into the auth string like = so:

    Authorization: = Basic cHJ0dXNlcjpwYXNzdzByZA=3D=3D

The = challenge from the server for this would look = like:

    WWW-Authenticate: = Basic realm=3D"My Super Secure = Printer",charset=3D"UTF-8",username=3D"prtuser"

=
So what does the server do = with this string? Does it appear in a log? Does the server verify that = it belongs to some list of authorized users?  It=92s pretty easy to = spoof if I know your username and the userid/password combination. =  So I=92m not sure it counts as =93authentication=94, although = it might be useful.

The = server is just authenticating as usual, and the "username" in the = WWW-Authenticate header tells the client that there is only one possible = username/account to authenticate = against.



Yoav

On Jul 8, 2014, at 10:21 PM, Michael = Sweet <msweet@apple.com> = wrote:

All,

I'd like to propose a new "username" parameter = for the HTTP Basic Update:

   http://tools.ietf.org/html/draft-ietf-httpauth-basicauth-update-01
The purpose of this parameter is to provide the username to be = used with a password provided by the user/client.  The use case is = authenticated access to an embedded device such as a printer, video = camera, router, etc. where separate user accounts may not make sense but = where you want to have some form of authentication to prevent casual = access to the device.  Currently you have to remember what a given = device's chosen username is ("root", "admin", "user", "config", etc.), = which makes for a poor user experience.

AirPrint has been using = this parameter as an extension to HTTP Basic for several years = now...

The text changes are outlined = below...

....

Section 2 (The 'Basic' Authentication = Scheme), add a new bullet:

   o  the = authentication parameter "username" is OPTIONAL (see Section = 2.2)

New Section 2.2 (The 'username' auth-param) with the = following text:

In challenges, servers can use the "username" = authentication parameter to indicate the only supported "userid" value = that can be supplied in a subsequent Authorization request header. The = value MUST conform to the "userid" ABNF = rules.

_________________________________________________________Michael Sweet, Senior Printing System Engineer, PWG = Chair


_________________________________________________________
Michael = Sweet, Senior Printing System Engineer, PWG = Chair

= --Apple-Mail=_1D132F9C-1068-4989-9869-7CEE32C21E1C-- --Apple-Mail=_779EE972-1596-466F-9128-A32E5B96F4BE Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPJTCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBSIwggQKoAMC AQICEQDlB7dXxclLEedquPvGX8CGMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBMB4XDTEzMTIxNzAwMDAwMFoXDTE0MTIxNzIzNTk1OVowITEfMB0GCSqG SIb3DQEJARYQbXN3ZWV0QGFwcGxlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ANdvQYZRCVzc0wIYvIOn/0Pv7zUwuIvbAfM/W3FyemqZx3fdKxX4WxN2x5NC3hhBHGrUWirJH7rl 6It12bGQ61uHAK5jsJikV5k+mOYjZaKNIKxj0uYIk3MKQmsmM8t3nddq5mp2mxwV/U7AFPTz1fgh dkqTb/NkHY5eA8KqksaeqwfMgoaiGVeCUhptWnXosca8PAkb+i9u5rEok5zgY+QP0IuWLJENfA4q dEMsH+OAwMGOv9fNCgcdapFnjeSYaj70m6qUiq446+8a2rhUsEUKQayOMgjnm2bgUuNx7pOvs/Jg zIlZoTz/llmE1HWREGzSjRnLWwQ98fspfeZWA+8CAwEAAaOCAeAwggHcMB8GA1UdIwQYMBaAFHoT TgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTtKBJoG9kxZisTqJg4+wr12l4stjAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIw EQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUH AgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6 Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1h aWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9j YS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggr BgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMBsGA1UdEQQUMBKBEG1zd2VldEBhcHBs ZS5jb20wDQYJKoZIhvcNAQEFBQADggEBABg5KLQK5u9gGI75u+vYH/i6uMDKlpTILO/r/FpN2ibq pwAB2ln9oKvPIA1/r3o+DBC87TqnlJAiPW4ADFHpRmqlprb0Tu9p98nP/wl5tBZjEP8dY4iH0TB3 B2r9JHwRwwJQ20CqJpuCn9dmvL215sZSqvJfluVlIcAQCLxp3ZKMIC2pNKitswdjjHduaKuj2TMe xrzMtrRGRtFF9pcMcnsqE2QtJUqXPV7/M4WT2yRUmI4ThPt9O9fmPH2ku52hdb6t4qXvwdQSkDHt xo3J/Vc/jDR2/feedDhQmG0V9j6tHsuG6bVVhcGiWnSmSoPfg13FlQwlxZTyFtiMZ2jILyoxggOu MIIDqgIBATCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAOUHt1fFyUsR 52q4+8ZfwIYwCQYFKw4DAhoFAKCCAdkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTQwNzA5MDAwOTMyWjAjBgkqhkiG9w0BCQQxFgQUnXN+a1kY26EpHTsANb/qap/t edMwgboGCSsGAQQBgjcQBDGBrDCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx OTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIRAOUHt1fFyUsR52q4+8ZfwIYwgbwGCyqGSIb3DQEJEAILMYGsoIGpMIGTMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgU2VjdXJlIEVtYWlsIENBAhEA5Qe3V8XJSxHnarj7xl/AhjANBgkqhkiG9w0BAQEFAASC AQDRIwKq6t7dIYvOrV9lbLybya19tmMUSweaHM/Q7VxGZqo2/mb6Z1l6mTwsCUxWVlCEINHqt/mU wF+GpfJHlL7FvrluRk3mqMhDKJq72JgGZgO/wf7MVkRZp5T08xVCu8NfG3edx4Uukr2iAHAP368u Uu52yXWr5KG1x8/bRuZ6gL4SBV/lse9LuflEGsnDhzfXGycoC+dBGj0C/7Py7MJWfx1eNH2CroOW kmFMrvSscmWUbHaLobGjIr+TquNWaOyMrxTCxBqmQdmN43bAySyqwFk4APhd6yYSV75f7xPCvzWC EwZeWzKQagTJc1ZZpJYvj7+N95kSOALQc0ookVwBAAAAAAAA --Apple-Mail=_779EE972-1596-466F-9128-A32E5B96F4BE-- From nobody Tue Jul 8 18:55:08 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0D921A0243 for ; Tue, 8 Jul 2014 18:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.85 X-Spam-Level: X-Spam-Status: No, score=-4.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7JJDmwz3YB9V for ; Tue, 8 Jul 2014 18:55:03 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C124C1A024E for ; Tue, 8 Jul 2014 18:55:03 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s691sxMs026434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 9 Jul 2014 01:55:00 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s691swUp022195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Jul 2014 01:54:59 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s691sveZ023477; Wed, 9 Jul 2014 01:54:58 GMT Received: from [25.69.103.141] (/24.114.25.46) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 08 Jul 2014 18:54:57 -0700 References: <9F9B2F65-031C-43A1-84F3-8A3B0CC24E0C@apple.com> <0DCD8299-B5AE-4609-BD01-2D3F03EBF872@gmail.com> <7957705E-E585-4A10-9876-34F10F9FAB6E@apple.com> Mime-Version: 1.0 (1.0) In-Reply-To: <7957705E-E585-4A10-9876-34F10F9FAB6E@apple.com> Content-Type: multipart/alternative; boundary=Apple-Mail-07D36201-D35E-436B-A138-84FAAEFA21A0 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (11D257) From: Phil Hunt Date: Tue, 8 Jul 2014 18:54:53 -0700 To: Michael Sweet X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/F5FKaT6prFX39yKuIu7J9o9XWZk Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Proposal: username parameter for HTTP Basic authentication X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 01:55:06 -0000 --Apple-Mail-07D36201-D35E-436B-A138-84FAAEFA21A0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Certainly nice from a device ui perspective. But also screams attack me usin= g this account cause I'm a router/printer etc.=20 What about a username printed on the device? At least the UI problem gets ea= sier and the username is obtained "out-of-band".=20 There is also some other approaches being discussed in the ACE WG.=20 Phil > On Jul 8, 2014, at 17:09, Michael Sweet wrote: >=20 > Yoav, >=20 >> On Jul 8, 2014, at 5:36 PM, Yoav Nir wrote: >> Hi, Michael. >>=20 >> Just to make sure that I understand you correctly, in your use case there= are two people (let=E2=80=99s call them =E2=80=9CMichael=E2=80=9D and =E2=80= =9CYoav=E2=80=9D) but only one userid, let=E2=80=99s say =E2=80=9Cprtuser=E2= =80=9D, There is a single password: =E2=80=9Cpassw0rd=E2=80=9D (because we c= are about security) >>=20 >> So the client sends something like: >> Authorization: Basic cHJ0dXNlcjpwYXNzdzByZA=3D=3D username=3D=E2=80=9CMic= hael" >=20 > No, the client just sends the standard Authorization header as before, wit= h "prtuser:passw0rd" Base64-encoded into the auth string like so: >=20 > Authorization: Basic cHJ0dXNlcjpwYXNzdzByZA=3D=3D >=20 > The challenge from the server for this would look like: >=20 > WWW-Authenticate: Basic realm=3D"My Super Secure Printer",charset=3D"U= TF-8",username=3D"prtuser" >=20 >> So what does the server do with this string? Does it appear in a log? Doe= s the server verify that it belongs to some list of authorized users? It=E2= =80=99s pretty easy to spoof if I know your username and the userid/password= combination. So I=E2=80=99m not sure it counts as =E2=80=9Cauthentication=E2= =80=9D, although it might be useful. >=20 > The server is just authenticating as usual, and the "username" in the WWW-= Authenticate header tells the client that there is only one possible usernam= e/account to authenticate against. >=20 >=20 >>=20 >> Yoav >>=20 >>> On Jul 8, 2014, at 10:21 PM, Michael Sweet wrote: >>>=20 >>> All, >>>=20 >>> I'd like to propose a new "username" parameter for the HTTP Basic Update= : >>>=20 >>> http://tools.ietf.org/html/draft-ietf-httpauth-basicauth-update-01 >>>=20 >>> The purpose of this parameter is to provide the username to be used with= a password provided by the user/client. The use case is authenticated acce= ss to an embedded device such as a printer, video camera, router, etc. where= separate user accounts may not make sense but where you want to have some f= orm of authentication to prevent casual access to the device. Currently you= have to remember what a given device's chosen username is ("root", "admin",= "user", "config", etc.), which makes for a poor user experience. >>>=20 >>> AirPrint has been using this parameter as an extension to HTTP Basic for= several years now... >>>=20 >>> The text changes are outlined below... >>>=20 >>> .... >>>=20 >>> Section 2 (The 'Basic' Authentication Scheme), add a new bullet: >>>=20 >>> o the authentication parameter "username" is OPTIONAL (see Section 2= .2) >>>=20 >>> New Section 2.2 (The 'username' auth-param) with the following text: >>>=20 >>> In challenges, servers can use the "username" authentication parameter t= o indicate the only supported "userid" value that can be supplied in a subse= quent Authorization request header. The value MUST conform to the "userid" A= BNF rules. >>>=20 >>> _________________________________________________________ >>> Michael Sweet, Senior Printing System Engineer, PWG Chair >=20 > _________________________________________________________ > Michael Sweet, Senior Printing System Engineer, PWG Chair >=20 > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth --Apple-Mail-07D36201-D35E-436B-A138-84FAAEFA21A0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Certainly nice from a device ui perspe= ctive. But also screams attack me using this account cause I'm a router/prin= ter etc. 

What about a username printed on the= device? At least the UI problem gets easier and the username is obtained "o= ut-of-band". 

There is also some other approac= hes being discussed in the ACE WG. 

Phil

On= Jul 8, 2014, at 17:09, Michael Sweet <msweet@apple.com> wrote:

Yoav,

On Jul 8, 2014, at 5:36 PM, Yoav Nir <ynir.ietf@gmail.com> wrote:
Hi, Michael.

Just to make sure that I understand you correctly, in your use case= there are two people (let=E2=80=99s call them =E2=80=9CMichael=E2=80=9D and= =E2=80=9CYoav=E2=80=9D) but only one userid, let=E2=80=99s say =E2=80=9Cprt= user=E2=80=9D, There is a single password: =E2=80=9Cpassw0rd=E2=80=9D (becau= se we care about security)

So the client sends some= thing like:
Authorization: Basic cHJ0dXN= lcjpwYXNzdzByZA=3D=3D username=3D=E2=80=9CMichael"

No, the client just sends the standard Authorization he= ader as before, with "prtuser:passw0rd" Base64-encoded into the auth string l= ike so:

    Authorization: Basic cHJ= 0dXNlcjpwYXNzdzByZA=3D=3D

The challenge from the se= rver for this would look like:

    W= WW-Authenticate: Basic realm=3D"My Super Secure Printer",charset=3D"UTF-8",u= sername=3D"prtuser"

So what does the serve= r do with this string? Does it appear in a log? Does the server verify that i= t belongs to some list of authorized users?  It=E2=80=99s pretty easy t= o spoof if I know your username and the userid/password combination.  S= o I=E2=80=99m not sure it counts as =E2=80=9Cauthentication=E2=80=9D, a= lthough it might be useful.

Th= e server is just authenticating as usual, and the "username" in the WWW-Auth= enticate header tells the client that there is only one possible username/ac= count to authenticate against.


Yoav

On Jul 8, 2014, at 10:21 PM, Michael Sweet <= msweet@apple.com> wrote:
All,

I= 'd like to propose a new "username" parameter for the HTTP Basic Update:
=
   http://tools.ietf.org/html/draft-ietf-httpauth-bas= icauth-update-01

The purpose of this parameter is to provide the u= sername to be used with a password provided by the user/client.  The us= e case is authenticated access to an embedded device such as a printer, vide= o camera, router, etc. where separate user accounts may not make sense but w= here you want to have some form of authentication to prevent casual access t= o the device.  Currently you have to remember what a given device's cho= sen username is ("root", "admin", "user", "config", etc.), which makes for a= poor user experience.

AirPrint has been using this parameter as an e= xtension to HTTP Basic for several years now...

The text changes are o= utlined below...

....

Section 2 (The 'Basic' Authentication Sc= heme), add a new bullet:

   o  the authenticatio= n parameter "username" is OPTIONAL (see Section 2.2)

New Section 2.2 (= The 'username' auth-param) with the following text:

In challenges, se= rvers can use the "username" authentication parameter to indicate the only s= upported "userid" value that can be supplied in a subsequent Authorization r= equest header. The value MUST conform to the "userid" ABNF rules.

___= ______________________________________________________
Michael Sweet, Sen= ior Printing System Engineer, PWG Chair


_________________________________________________________
Michael Swe= et, Senior Printing System Engineer, PWG Chair

__________= _____________________________________
http-auth mailing list=
http-auth@ietf.org
https://www.ietf.org/mailman/listinfo/http-auth
= --Apple-Mail-07D36201-D35E-436B-A138-84FAAEFA21A0-- From nobody Tue Jul 8 22:12:10 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 223F21A0334 for ; Tue, 8 Jul 2014 22:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8vs_by_9zRB7 for ; Tue, 8 Jul 2014 22:12:03 -0700 (PDT) Received: from posteo.de (mx02.posteo.de [89.146.194.165]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C5171A026C for ; Tue, 8 Jul 2014 22:12:03 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.posteo.de (Postfix) with ESMTP id 2232125B17CD; Wed, 9 Jul 2014 07:12:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at posteo.de Received: from posteo.de ([10.125.125.178]) by localhost (amavis1.posteo.de [10.125.125.165]) (amavisd-new, port 10026) with ESMTP id eu-XOO-Znaky; Wed, 9 Jul 2014 07:11:58 +0200 (CEST) Received: from mail.posteo.de (localhost [127.0.0.1]) by mail.posteo.de (Postfix) with ESMTPSA id 4F63E2C00F6; Wed, 9 Jul 2014 07:11:53 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Sophie Bremer In-Reply-To: Date: Wed, 9 Jul 2014 07:11:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <78D3508F-92F9-431B-BB9B-723859D76081@netzkonform.de> References: <9F9B2F65-031C-43A1-84F3-8A3B0CC24E0C@apple.com> <0DCD8299-B5AE-4609-BD01-2D3F03EBF872@gmail.com> <7957705E-E585-4A10-9876-34F10F9FAB6E@apple.com> To: Phil Hunt X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/lgRBbvCe6InXFCvVd9-pLS4b3rs Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Proposal: username parameter for HTTP Basic authentication X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 05:12:06 -0000 I like the idea, because the username is internal and may be unique for = device and client - like a special nonce. For example, you may use username =3D H( Serial : ClientIP : UserAgent = ). Sophie On 09 Jul 2014, at 03:54, Phil Hunt wrote: > Certainly nice from a device ui perspective. But also screams attack = me using this account cause I'm a router/printer etc.=20 >=20 > What about a username printed on the device? At least the UI problem = gets easier and the username is obtained "out-of-band".=20 >=20 > There is also some other approaches being discussed in the ACE WG.=20 >=20 > Phil >=20 > On Jul 8, 2014, at 17:09, Michael Sweet wrote: >=20 >> Yoav, >>=20 >> On Jul 8, 2014, at 5:36 PM, Yoav Nir wrote: >>> Hi, Michael. >>>=20 >>> Just to make sure that I understand you correctly, in your use case = there are two people (let=92s call them =93Michael=94 and =93Yoav=94) = but only one userid, let=92s say =93prtuser=94, There is a single = password: =93passw0rd=94 (because we care about security) >>>=20 >>> So the client sends something like: >>> Authorization: Basic cHJ0dXNlcjpwYXNzdzByZA=3D=3D username=3D=93Michae= l" >>=20 >> No, the client just sends the standard Authorization header as = before, with "prtuser:passw0rd" Base64-encoded into the auth string like = so: >>=20 >> Authorization: Basic cHJ0dXNlcjpwYXNzdzByZA=3D=3D >>=20 >> The challenge from the server for this would look like: >>=20 >> WWW-Authenticate: Basic realm=3D"My Super Secure = Printer",charset=3D"UTF-8",username=3D"prtuser" >>=20 >>> So what does the server do with this string? Does it appear in a = log? Does the server verify that it belongs to some list of authorized = users? It=92s pretty easy to spoof if I know your username and the = userid/password combination. So I=92m not sure it counts as = =93authentication=94, although it might be useful. >>=20 >> The server is just authenticating as usual, and the "username" in the = WWW-Authenticate header tells the client that there is only one possible = username/account to authenticate against. >>=20 >>=20 >>>=20 >>> Yoav >>>=20 >>> On Jul 8, 2014, at 10:21 PM, Michael Sweet wrote: >>>=20 >>>> All, >>>>=20 >>>> I'd like to propose a new "username" parameter for the HTTP Basic = Update: >>>>=20 >>>> = http://tools.ietf.org/html/draft-ietf-httpauth-basicauth-update-01 >>>>=20 >>>> The purpose of this parameter is to provide the username to be used = with a password provided by the user/client. The use case is = authenticated access to an embedded device such as a printer, video = camera, router, etc. where separate user accounts may not make sense but = where you want to have some form of authentication to prevent casual = access to the device. Currently you have to remember what a given = device's chosen username is ("root", "admin", "user", "config", etc.), = which makes for a poor user experience. >>>>=20 >>>> AirPrint has been using this parameter as an extension to HTTP = Basic for several years now... >>>>=20 >>>> The text changes are outlined below... >>>>=20 >>>> .... >>>>=20 >>>> Section 2 (The 'Basic' Authentication Scheme), add a new bullet: >>>>=20 >>>> o the authentication parameter "username" is OPTIONAL (see = Section 2.2) >>>>=20 >>>> New Section 2.2 (The 'username' auth-param) with the following = text: >>>>=20 >>>> In challenges, servers can use the "username" authentication = parameter to indicate the only supported "userid" value that can be = supplied in a subsequent Authorization request header. The value MUST = conform to the "userid" ABNF rules. >>>>=20 >>>> _________________________________________________________ >>>> Michael Sweet, Senior Printing System Engineer, PWG Chair >>>=20 >>=20 >> _________________________________________________________ >> Michael Sweet, Senior Printing System Engineer, PWG Chair >>=20 >> _______________________________________________ >> 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 nobody Tue Jul 8 23:22:43 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 213DF1A02E7 for ; Tue, 8 Jul 2014 23:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sOkqA9KGu3N2 for ; Tue, 8 Jul 2014 23:22:40 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90D271A01AF for ; Tue, 8 Jul 2014 23:22:40 -0700 (PDT) Received: from [192.168.2.160] ([93.217.71.236]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LfCX2-1WG2F83wSW-00okER; Wed, 09 Jul 2014 08:22:35 +0200 Message-ID: <53BCDFA8.90403@gmx.de> Date: Wed, 09 Jul 2014 08:22:32 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Michael Sweet , http-auth@ietf.org References: <9F9B2F65-031C-43A1-84F3-8A3B0CC24E0C@apple.com> In-Reply-To: <9F9B2F65-031C-43A1-84F3-8A3B0CC24E0C@apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:E8Ecl7ACOrlq9akEu2RhOXzirTWhXToK4fKiSIAr1RDrSXh+dv0 P+dbVShacCDm8VBjdIU6ufet9Ek8xdZpMk0coNV/eTpLmLDCRLvCGo51FS5cvhKHrwXknXO J0Wqwh3Qz/NA2gKAVkf7zxpW7SuNbOHvi5BM2Wj46SQSDh0HYxsHqgxVjzos8+VcBEJkt4l e/ZA1tsnhBhxV8s4lI8dA== Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/Os1AHhZOJaOAlC7qHzuDhPVQpPk Subject: Re: [http-auth] Proposal: username parameter for HTTP Basic authentication X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 06:22:42 -0000 On 2014-07-08 21:21, Michael Sweet wrote: > All, > > I'd like to propose a new "username" parameter for the HTTP Basic Update: > > http://tools.ietf.org/html/draft-ietf-httpauth-basicauth-update-01 > > The purpose of this parameter is to provide the username to be used with a password provided by the user/client. The use case is authenticated access to an embedded device such as a printer, video camera, router, etc. where separate user accounts may not make sense but where you want to have some form of authentication to prevent casual access to the device. Currently you have to remember what a given device's chosen username is ("root", "admin", "user", "config", etc.), which makes for a poor user experience. > > AirPrint has been using this parameter as an extension to HTTP Basic for several years now... > > The text changes are outlined below... > > .... > > Section 2 (The 'Basic' Authentication Scheme), add a new bullet: > > o the authentication parameter "username" is OPTIONAL (see Section 2.2) > > New Section 2.2 (The 'username' auth-param) with the following text: > > In challenges, servers can use the "username" authentication parameter to indicate the only supported "userid" value that can be supplied in a subsequent Authorization request header. The value MUST conform to the "userid" ABNF rules. > ... I've got two concerns: 1) If we add this parameter it sort of indicates that new parameters are needed in practice, in which case we should make this an extension and define a registry. 2) It adds a new parameter with broken internationalization. (We could invoke RFC5987 for realm and username, though). Best regards, Julian From nobody Wed Jul 9 06:58:27 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E39791A0233 for ; Wed, 9 Jul 2014 06:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.951 X-Spam-Level: X-Spam-Status: No, score=-4.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3lbrSAHFBTm for ; Wed, 9 Jul 2014 06:58:21 -0700 (PDT) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 969851A01F4 for ; Wed, 9 Jul 2014 06:58:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1404914300; x=2268827900; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=qKa2ubg8lISigchrCJA63ZjEHLqoFa4HfFwJbOn8rlY=; b=TApir/0IIILOnx1WkOpA8eVtVezL7B72f9o4E1FdIuJn529RNvLMzAGR3fPNySvZ q/Zs9WaRSSLGMssAPrO6pp2nZJJ49+5sJ9Ae2nBwc9UigyZ724n5clzvZYnGDw1n 9S3N37SQgNIp/QKuh4y1EWa/vJS/Boi8APUF0trWMJXJa0H8mgs2PzoeC8zX6skB eXYXDjIrVOmDWezfM/YEN4QpfbkgakSIJdTU3Xk8p2R6JVGxa4pIlo7CsfsxImdB 6ZAgUFWziL3qP1M3co6LYkK+xubGUwwdizAyqD2u+USIsrpCNqarJTk2occztMKB YORdv+NpXX4hvm0p5AJM0A==; Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id 51.8F.32327.C7A4DB35; Wed, 9 Jul 2014 06:58:20 -0700 (PDT) MIME-version: 1.0 Received: from relay7.apple.com ([17.128.113.101]) by local.mail-out.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTP id <0N8G00EOU6T02PF0@local.mail-out.apple.com> for http-auth@ietf.org; Wed, 09 Jul 2014 06:58:20 -0700 (PDT) X-AuditID: 11973e12-f79586d000007e47-ca-53bd4a7c3057 Received: from spicerack.apple.com (spicerack.apple.com [17.128.115.40]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay7.apple.com (Apple SCV relay) with SMTP id B1.74.19908.A6A4DB35; Wed, 9 Jul 2014 06:58:02 -0700 (PDT) Received: from [17.153.59.246] (unknown [17.153.59.246]) by spicerack.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0N8G00J6H6T5GH60@spicerack.apple.com> for http-auth@ietf.org; Wed, 09 Jul 2014 06:58:20 -0700 (PDT) Content-type: multipart/signed; boundary="Apple-Mail=_091F0877-A4F9-45A3-A2E4-DFCBE2542549"; protocol="application/pkcs7-signature"; micalg=sha1 From: Michael Sweet In-reply-to: Date: Wed, 09 Jul 2014 09:58:17 -0400 Message-id: <996D8E94-68CC-42C7-A0A6-617D3C36DEDF@apple.com> References: <9F9B2F65-031C-43A1-84F3-8A3B0CC24E0C@apple.com> <0DCD8299-B5AE-4609-BD01-2D3F03EBF872@gmail.com> <7957705E-E585-4A10-9876-34F10F9FAB6E@apple.com> To: Phil Hunt X-Mailer: Apple Mail (2.1878.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkkeLIzCtJLcpLzFFi42IRnG5nqFvjtTfYYOZtLYsP++cwOTB6LFny kymAMYrLJiU1J7MstUjfLoErY+KdNraCpxsZKzr//mJuYPw7j7GLkZNDQsBEYuu+RSwQtpjE hXvr2boYuTiEBGYxSSzoOcgGkuAVEJT4MfkeC1ziwo/1bDDda19NguqYzCQx7+J2RriqDx2P 2UGqhAVCJVbc38EKYjMLTGGUmDg/BcRmE1CT+D2pDyjOwcEpYCfx+YsvSJhFQFVi3qZDbBDl vhI/L19mgbjCRuLxlRdgtpDANUaJG9N0QGwRARWJb1evQ70jL/Hhw3F2kBskBA6xSfSdnsI0 gVF4FpIvZiE5A8JOkrg68R4bhK0tsWzha2YI20DiaecrVkxxfYk37+YwQdimEk/ebofqtZb4 OecRI4StKDGl+yH7AkauVYxCuYmZObqZeSZ6iQUFOal6yfm5mxghcSe0g/HUKqtDjAIcjEo8 vIo8e4KFWBPLiitzDzFKc7AoifPOkQYKCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYCyPXt+W 1vCLMf3v3Gnzssr1Lhmk1+9+e7ldLUPAIiHx/AX921PzZrEcnvB7oqw+d6apxyz3RWufM2qK LA9+Wxq083f1R4G40tjDO68cjOyYMGl94anf0U8cL8vxHJ5ZcmXZ5ujTD+/uEhH1+X6vNX77 xPnNM/Rs/Zu3v9vV/Cvtp/iuy2LnOY4qsRRnJBpqMRcVJwIAp2WhWJwCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUi2FCsoZvltTfY4NFBFYsP++cwOTB6LFny kymAMYrLJiU1J7MstUjfLoErY+KdNraCpxsZKzr//mJuYPw7j7GLkZNDQsBEYu2rSWwQtpjE hXvrgWwuDiGByUwSZ7b0MEE4s5gkPnQ8ZgepEhYIlVhxfwcriM0rYCDx6udjZhCbWWAKo8TE +SkgNpuAmsTvSX1ANRwcnAJ2Ep+/+IKEWQRUJeZtOsQGUe4r8fPyZRaIMTYSj6+8ALOFBK4x StyYpgNiiwioSHy7eh3qUHmJDx+Os09g5J+FZPMsJJsh7CSJqxPvsUHY2hLLFr6GqjGQeNr5 ihVTXF/izbs5TBC2qcSTt9uheq0lfs55xAhhK0pM6X7IvoCRaxWjQFFqTmKluV5iQUFOql5y fu4mRnA0FKbuYGxcbnWIUYCDUYmHV4FnT7AQa2JZcWXuIUYVoBGPNqy+wCjFkpefl6okwuvq vDdYiDclsbIqtSg/vqg0J7X4EKM0B4uSOO/D47uDhQTSE0tSs1NTC1KLYLJMHJxSDYxHU//u W6m3PnUCY+MLg+3XrvJMeaf+qbx9emJrELPu66WCnMbWNeXFwjcfH1XxNNvv4KaifZ899idX wvYnczIOa4rltX8Il88Lf/hA+/Gnkvxrcr998wXnbTFZ0LfEps+uSnQ1d53Pp5o7Ic0M9hJn 0m7zrfQVXndhfcTz2n0/wwMPBuQ0CCmxFGckGmoxFxUnAgDnbWinjgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/cwbRN_2ASJ9vg6Y1sEYrOIA42B4 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Proposal: username parameter for HTTP Basic authentication X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 13:58:25 -0000 --Apple-Mail=_091F0877-A4F9-45A3-A2E4-DFCBE2542549 Content-Type: multipart/alternative; boundary="Apple-Mail=_6E783AE4-FBA8-425A-8EFF-3B80D636B230" --Apple-Mail=_6E783AE4-FBA8-425A-8EFF-3B80D636B230 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Phil, On Jul 8, 2014, at 9:54 PM, Phil Hunt wrote: > Certainly nice from a device ui perspective. But also screams attack = me using this account cause I'm a router/printer etc.=20 The Server header in the HTTP response is enough for that. And nmap and = other tools are pretty good at identifying embedded devices on your = network already, so I don't think adding this one parameter will make it = more likely that the device will be attacked... > What about a username printed on the device? At least the UI problem = gets easier and the username is obtained "out-of-band".=20 I don't know about you, but my Wi-Fi access points are in out-of-the-way = locations, and such stickers/labels are usually on the back side or = bottom of the unit - not exactly convenient (particularly for a = printer...) and usually in the dark so it is impossible to read... > There is also some other approaches being discussed in the ACE WG. Ah, hadn't noticed that group was formed, however their focus is on = constrained devices - IoT stuff - and not on "peripheral" devices like = home routers, printers, cameras, etc. The assumption in that WG is that = all constrained devices use RESTful APIs, and many of the current drafts = focus on using 3-party auth schemes like OAuth or certificate validation = to authorize access to them. Auto-configuration for that environment = will be very important, and it will be interesting to see how they = address scaling, discovery, and network boundaries - something that the = Homenet and DNSSD WG are working on... Was there a particular approach you were thinking of that could be used = with printers, etc. in place of the "username" parameter? > On Jul 8, 2014, at 17:09, Michael Sweet wrote: >=20 >> Yoav, >>=20 >> On Jul 8, 2014, at 5:36 PM, Yoav Nir wrote: >>> Hi, Michael. >>>=20 >>> Just to make sure that I understand you correctly, in your use case = there are two people (let=92s call them =93Michael=94 and =93Yoav=94) = but only one userid, let=92s say =93prtuser=94, There is a single = password: =93passw0rd=94 (because we care about security) >>>=20 >>> So the client sends something like: >>> Authorization: Basic cHJ0dXNlcjpwYXNzdzByZA=3D=3D username=3D=93Michae= l" >>=20 >> No, the client just sends the standard Authorization header as = before, with "prtuser:passw0rd" Base64-encoded into the auth string like = so: >>=20 >> Authorization: Basic cHJ0dXNlcjpwYXNzdzByZA=3D=3D >>=20 >> The challenge from the server for this would look like: >>=20 >> WWW-Authenticate: Basic realm=3D"My Super Secure = Printer",charset=3D"UTF-8",username=3D"prtuser" >>=20 >>> So what does the server do with this string? Does it appear in a = log? Does the server verify that it belongs to some list of authorized = users? It=92s pretty easy to spoof if I know your username and the = userid/password combination. So I=92m not sure it counts as = =93authentication=94, although it might be useful. >>=20 >> The server is just authenticating as usual, and the "username" in the = WWW-Authenticate header tells the client that there is only one possible = username/account to authenticate against. >>=20 >>=20 >>>=20 >>> Yoav >>>=20 >>> On Jul 8, 2014, at 10:21 PM, Michael Sweet wrote: >>>=20 >>>> All, >>>>=20 >>>> I'd like to propose a new "username" parameter for the HTTP Basic = Update: >>>>=20 >>>> = http://tools.ietf.org/html/draft-ietf-httpauth-basicauth-update-01 >>>>=20 >>>> The purpose of this parameter is to provide the username to be used = with a password provided by the user/client. The use case is = authenticated access to an embedded device such as a printer, video = camera, router, etc. where separate user accounts may not make sense but = where you want to have some form of authentication to prevent casual = access to the device. Currently you have to remember what a given = device's chosen username is ("root", "admin", "user", "config", etc.), = which makes for a poor user experience. >>>>=20 >>>> AirPrint has been using this parameter as an extension to HTTP = Basic for several years now... >>>>=20 >>>> The text changes are outlined below... >>>>=20 >>>> .... >>>>=20 >>>> Section 2 (The 'Basic' Authentication Scheme), add a new bullet: >>>>=20 >>>> o the authentication parameter "username" is OPTIONAL (see = Section 2.2) >>>>=20 >>>> New Section 2.2 (The 'username' auth-param) with the following = text: >>>>=20 >>>> In challenges, servers can use the "username" authentication = parameter to indicate the only supported "userid" value that can be = supplied in a subsequent Authorization request header. The value MUST = conform to the "userid" ABNF rules. >>>>=20 >>>> _________________________________________________________ >>>> Michael Sweet, Senior Printing System Engineer, PWG Chair >>>=20 >>=20 >> _________________________________________________________ >> Michael Sweet, Senior Printing System Engineer, PWG Chair >>=20 >> _______________________________________________ >> http-auth mailing list >> http-auth@ietf.org >> https://www.ietf.org/mailman/listinfo/http-auth _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Apple-Mail=_6E783AE4-FBA8-425A-8EFF-3B80D636B230 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Phil,

On Jul 8, 2014, at 9:54 PM, = Phil Hunt <phil.hunt@oracle.com> = wrote:
Certainly = nice from a device ui perspective. But also screams attack me using this = account cause I'm a router/printer = etc. 

The Server header in = the HTTP response is enough for that.  And nmap and other tools are = pretty good at identifying embedded devices on your network already, so = I don't think adding this one parameter will make it more likely that = the device will be attacked...

What about a username printed on = the device? At least the UI problem gets easier and the username is = obtained "out-of-band". 

I = don't know about you, but my Wi-Fi access points are in out-of-the-way = locations, and such stickers/labels are usually on the back side or = bottom of the unit - not exactly convenient (particularly for a = printer...) and usually in the dark so it is impossible to = read...

There is also some other approaches being discussed in = the ACE WG.

Ah, hadn't noticed = that group was formed, however their focus is on constrained devices - = IoT stuff - and not on "peripheral" devices like home routers, printers, = cameras, etc.  The assumption in that WG is that all constrained = devices use RESTful APIs, and many of the current drafts focus on using = 3-party auth schemes like OAuth or certificate validation to authorize = access to them.  Auto-configuration for that environment will be = very important, and it will be interesting to see how they address = scaling, discovery, and network boundaries - something that the Homenet = and DNSSD WG are working on...

Was there a = particular approach you were thinking of that could be used with = printers, etc. in place of the "username" = parameter?


On Jul 8, 2014, at 17:09, Michael = Sweet <msweet@apple.com> = wrote:

Yoav,

On Jul 8, 2014, at 5:36 = PM, Yoav Nir <ynir.ietf@gmail.com> = wrote:
Hi, Michael.

Just to make sure = that I understand you correctly, in your use case there are two people = (let=92s call them =93Michael=94 and =93Yoav=94) but only one userid, = let=92s say =93prtuser=94, There is a single password: =93passw0rd=94 = (because we care about security)

So the client = sends something like:
Authorization: Basic cHJ0dXNlcjpwYXNzdzByZA=3D=3D = username=3D=93Michael"

No, = the client just sends the standard Authorization header as before, with = "prtuser:passw0rd" Base64-encoded into the auth string like = so:

    Authorization: = Basic cHJ0dXNlcjpwYXNzdzByZA=3D=3D

The = challenge from the server for this would look = like:

    WWW-Authenticate: = Basic realm=3D"My Super Secure = Printer",charset=3D"UTF-8",username=3D"prtuser"

=
So what does the server do with this string? Does it = appear in a log? Does the server verify that it belongs to some list of = authorized users?  It=92s pretty easy to spoof if I know your = username and the userid/password combination.  So I=92m not sure it = counts as =93authentication=94, although it might be = useful.

The server is just = authenticating as usual, and the "username" in the WWW-Authenticate = header tells the client that there is only one possible username/account = to authenticate = against.



Yoav

On Jul 8, 2014, at 10:21 PM, Michael = Sweet <msweet@apple.com> = wrote:

All,

I'd like to propose a new "username" parameter = for the HTTP Basic Update:

   http://tools.ietf.org/html/draft-ietf-httpauth-basicauth-update-01
The purpose of this parameter is to provide the username to be = used with a password provided by the user/client.  The use case is = authenticated access to an embedded device such as a printer, video = camera, router, etc. where separate user accounts may not make sense but = where you want to have some form of authentication to prevent casual = access to the device.  Currently you have to remember what a given = device's chosen username is ("root", "admin", "user", "config", etc.), = which makes for a poor user experience.

AirPrint has been using = this parameter as an extension to HTTP Basic for several years = now...

The text changes are outlined = below...

....

Section 2 (The 'Basic' Authentication = Scheme), add a new bullet:

   o  the = authentication parameter "username" is OPTIONAL (see Section = 2.2)

New Section 2.2 (The 'username' auth-param) with the = following text:

In challenges, servers can use the "username" = authentication parameter to indicate the only supported "userid" value = that can be supplied in a subsequent Authorization request header. The = value MUST conform to the "userid" ABNF = rules.

_________________________________________________________Michael Sweet, Senior Printing System Engineer, PWG = Chair


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

_________________________________________________________
Michael = Sweet, Senior Printing System Engineer, PWG = Chair

= --Apple-Mail=_6E783AE4-FBA8-425A-8EFF-3B80D636B230-- --Apple-Mail=_091F0877-A4F9-45A3-A2E4-DFCBE2542549 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPJTCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBSIwggQKoAMC AQICEQDlB7dXxclLEedquPvGX8CGMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBMB4XDTEzMTIxNzAwMDAwMFoXDTE0MTIxNzIzNTk1OVowITEfMB0GCSqG SIb3DQEJARYQbXN3ZWV0QGFwcGxlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ANdvQYZRCVzc0wIYvIOn/0Pv7zUwuIvbAfM/W3FyemqZx3fdKxX4WxN2x5NC3hhBHGrUWirJH7rl 6It12bGQ61uHAK5jsJikV5k+mOYjZaKNIKxj0uYIk3MKQmsmM8t3nddq5mp2mxwV/U7AFPTz1fgh dkqTb/NkHY5eA8KqksaeqwfMgoaiGVeCUhptWnXosca8PAkb+i9u5rEok5zgY+QP0IuWLJENfA4q dEMsH+OAwMGOv9fNCgcdapFnjeSYaj70m6qUiq446+8a2rhUsEUKQayOMgjnm2bgUuNx7pOvs/Jg zIlZoTz/llmE1HWREGzSjRnLWwQ98fspfeZWA+8CAwEAAaOCAeAwggHcMB8GA1UdIwQYMBaAFHoT TgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTtKBJoG9kxZisTqJg4+wr12l4stjAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIw EQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUH AgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6 Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1h aWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9j YS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggr BgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMBsGA1UdEQQUMBKBEG1zd2VldEBhcHBs ZS5jb20wDQYJKoZIhvcNAQEFBQADggEBABg5KLQK5u9gGI75u+vYH/i6uMDKlpTILO/r/FpN2ibq pwAB2ln9oKvPIA1/r3o+DBC87TqnlJAiPW4ADFHpRmqlprb0Tu9p98nP/wl5tBZjEP8dY4iH0TB3 B2r9JHwRwwJQ20CqJpuCn9dmvL215sZSqvJfluVlIcAQCLxp3ZKMIC2pNKitswdjjHduaKuj2TMe xrzMtrRGRtFF9pcMcnsqE2QtJUqXPV7/M4WT2yRUmI4ThPt9O9fmPH2ku52hdb6t4qXvwdQSkDHt xo3J/Vc/jDR2/feedDhQmG0V9j6tHsuG6bVVhcGiWnSmSoPfg13FlQwlxZTyFtiMZ2jILyoxggOu MIIDqgIBATCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAOUHt1fFyUsR 52q4+8ZfwIYwCQYFKw4DAhoFAKCCAdkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTQwNzA5MTM1ODE3WjAjBgkqhkiG9w0BCQQxFgQUxDnz/pj4CIHa22X8aWq4hQfe 7+AwgboGCSsGAQQBgjcQBDGBrDCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx OTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIRAOUHt1fFyUsR52q4+8ZfwIYwgbwGCyqGSIb3DQEJEAILMYGsoIGpMIGTMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgU2VjdXJlIEVtYWlsIENBAhEA5Qe3V8XJSxHnarj7xl/AhjANBgkqhkiG9w0BAQEFAASC AQAB7F1HYZ75/cwDEkRazqOeRxdZPhG8pm0DbOEBXgOjG6DMdzuyZihl5YOXNZD6Z5XaGlGEpw8s UI480dW0O3CqccOf5AS1uggw2NZP3/Ay0ZtW+4d/Wk3t1+uMsdeZ5DMWz1JzNo8zON86bF/FwlmZ sKQreJezEDqiGO/D1+puiSjdrYQFJLqJUmPa8U9vBFG5hgN5LFpGZSVliPIphr66Q411sA/4Y06i +ezUtU9g91oiaOe65MoW9e+2dJ3SoBfozRLDN91W7wjgBxe57czy24r8n26g2idjrb3Zj7UqPHB9 a5j2q6kFdIk4gNQvxMgR0CCPNhPWU1ZknTnEo5eLAAAAAAAA --Apple-Mail=_091F0877-A4F9-45A3-A2E4-DFCBE2542549-- From nobody Wed Jul 9 07:29:42 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6363B1A0AD6 for ; Wed, 9 Jul 2014 07:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.952 X-Spam-Level: X-Spam-Status: No, score=-4.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6KQojlLOJd4n for ; Wed, 9 Jul 2014 07:29:38 -0700 (PDT) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 768821A0AD5 for ; Wed, 9 Jul 2014 07:29:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1404916178; x=2268829778; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Gnik5M/0yCBpfbYe6OUFclRI+zTDlPtCihazhLamXOk=; b=GVfg6VXWoAKvkYqBGEkJ/FtNx/KT22vkmUiC5/Po1n1svdwz/aoLq9OcxKx5rNL9 lZRBWRzFKgIl3kuga/mbHZlOC6Y8kXGOtwChKZKtzqZjP/okHaVm5GPCdMQZMZ+Q pgKgz/IoahzaA6FJ8r7yyCAF76IJzJaokKGUKIZi0R2NYWR7YkIdzYZqfd1nujFg LdMhSb0dk2HAanB5vNav94438kwqq79EU9OiU2LWgMHSfBhwSi7ANzmB54arY/pr +GNXOKUmctnwVRMradxrCRYQqaj+8kpOLxwcE+/+GcQCze5Z8jbfXjFhjoPlcaPh My4fH/waIFkdZAyWTyko/g==; Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id 75.62.32327.1D15DB35; Wed, 9 Jul 2014 07:29:38 -0700 (PDT) MIME-version: 1.0 Received: from relay7.apple.com ([17.128.113.101]) by local.mail-out.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTP id <0N8G00HK0896M6G1@local.mail-out.apple.com> for http-auth@ietf.org; Wed, 09 Jul 2014 07:29:37 -0700 (PDT) X-AuditID: 11973e12-f79586d000007e47-22-53bd51d1afb1 Received: from spicerack.apple.com (spicerack.apple.com [17.128.115.40]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay7.apple.com (Apple SCV relay) with SMTP id D2.31.19908.FB15DB35; Wed, 9 Jul 2014 07:29:19 -0700 (PDT) Received: from [17.153.59.246] (unknown [17.153.59.246]) by spicerack.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0N8G00JN789BGH70@spicerack.apple.com> for http-auth@ietf.org; Wed, 09 Jul 2014 07:29:37 -0700 (PDT) Content-type: multipart/signed; boundary="Apple-Mail=_B4356BCD-214F-4E87-BFD7-E597BD448A5F"; protocol="application/pkcs7-signature"; micalg=sha1 From: Michael Sweet In-reply-to: <78D3508F-92F9-431B-BB9B-723859D76081@netzkonform.de> Date: Wed, 09 Jul 2014 10:29:35 -0400 Message-id: References: <9F9B2F65-031C-43A1-84F3-8A3B0CC24E0C@apple.com> <0DCD8299-B5AE-4609-BD01-2D3F03EBF872@gmail.com> <7957705E-E585-4A10-9876-34F10F9FAB6E@apple.com> <78D3508F-92F9-431B-BB9B-723859D76081@netzkonform.de> To: Sophie Bremer X-Mailer: Apple Mail (2.1878.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUiON3OWPdS4N5gg0XeFh/2z2FyYPRYsuQn UwBjFJdNSmpOZllqkb5dAlfGwh/3GAs6EyvWLq5sYOyP6GLk5JAQMJG4NruHDcIWk7hwbz2Q zcUhJDCHSWJT0ypmkASvgKDEj8n3WCASs5gkbi1ezwrT/fj0D2aIxGQmiUdXLoCNAqu6+pwD xBYWCJVYcX8HK0gRs8AURondD46wgyTYBNQkfk/qA5vEKeAksWjWcbB1LAKqEs8WNoMNYhbw l+ie/YAJ4gwbiS/3O6DO6GOSeLx1M1hCRMBAounUIxaIk+QlPnw4zg5SJCGwiU3i3ueFbBMY hWch+WMWsktmgW3Rlli28DUzhG0g8bTzFSuEbSrx5O12NgjbWuLnnEeMELaixJTuh+wLGNlX MQrlJmbm6GbmmeglFhTkpOol5+duYoREi9AOxlOrrA4xCnAwKvHwKvLsCRZiTSwrrsw9xCjN waIkzjtHGigkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBcaH0njMLZHlV39/g2vC5V+HhrW1K fIv39uS2GzrUSYXOfTORe8djnsuRe9/8uTeFXUP4Ya7fDf5JJY2MJpICbA1T+p9vsDVom/ne Sr1vmYfP/7BVGl7VnzdWBL708p2WZlOvfuKDx7MjqcVFvyrW/N42J2HFtIvcRfobHty58OjR rp15c273MCmxFGckGmoxFxUnAgDqrV5OdwIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUi2FCsobs/cG+wwYQVVhYf9s9hcmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxsIf9xgLOhMr1i6ubGDsj+hi5OSQEDCReHz6BzOELSZx4d56 ti5GLg4hgclMEhMbH7OBJIQEZjFJXH3OAWILC4RKrLi/gxXE5hUwkHj18zEzSAOzwBRGid0P jrCDJNgE1CR+T+oDK+IUcJJYNOs42AYWAVWJZwubwYYyC/hLdM9+wAQxyEbiy/0OFojNfUwS j7duBkuIAG1oOvWIBeI8eYkPH46zT2Dkn4Vk+Sxky2eBDdaWWLbwNTOEbSDxtPMVK4RtKvHk 7XY2CNta4uecR4wQtqLElO6H7AsY2VcxChSl5iRWmuslFhTkpOol5+duYgQHcWHqDsbG5VaH GAU4GJV4eBV49gQLsSaWFVfmHmJUARrxaMPqC4xSLHn5ealKIryuznuDhXhTEiurUovy44tK c1KLDzFKc7AoifM+PL47WEggPbEkNTs1tSC1CCbLxMEp1cBotHKTW2DfwznNcXuk1m/uPLfN 8NJzg0+nHoW6O/Z9nzBJRqbr7tadvjvXOl4WrUn9pMHltfq1LeesRXef9DQuPLr/wh623bu/ PWzOvcXIvffcmf2Nj/++NY0oF9G8a7JipfpUu0t9h18v6H+xiGNp1RnzY4oPPjis/2s4YUHK gdm685y2JuwwlVViKc5INNRiLipOBABI2fuoagIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/BPUzilF58VGg06j3J7FJxbwT1Qc Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Proposal: username parameter for HTTP Basic authentication X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 14:29:40 -0000 --Apple-Mail=_B4356BCD-214F-4E87-BFD7-E597BD448A5F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Sophie, That's an interesting idea, however since web browsers currently do not = support the "username" parameter how would the user discover the correct = username to use? An alternative is for devices to have uniquely-generated usernames = (printed on the unit) - that at least avoids the default account = backdoor, e.g., username "root", password "root" for a Wi-Fi Router. = That should probably be a recommendation if "username" is adopted. Neither approach will protect against a brute-force attack, something we = should perhaps talk about in the security considerations (for any usage = of Basic, not just when "username" is present...) On Jul 9, 2014, at 1:11 AM, Sophie Bremer = wrote: > I like the idea, because the username is internal and may be unique = for device and client - like a special nonce. >=20 > For example, you may use username =3D H( Serial : ClientIP : UserAgent = ). >=20 > Sophie >=20 > On 09 Jul 2014, at 03:54, Phil Hunt wrote: >=20 >> Certainly nice from a device ui perspective. But also screams attack = me using this account cause I'm a router/printer etc.=20 >>=20 >> What about a username printed on the device? At least the UI problem = gets easier and the username is obtained "out-of-band".=20 >>=20 >> There is also some other approaches being discussed in the ACE WG.=20 >>=20 >> Phil >>=20 >> On Jul 8, 2014, at 17:09, Michael Sweet wrote: >>=20 >>> Yoav, >>>=20 >>> On Jul 8, 2014, at 5:36 PM, Yoav Nir wrote: >>>> Hi, Michael. >>>>=20 >>>> Just to make sure that I understand you correctly, in your use case = there are two people (let=92s call them =93Michael=94 and =93Yoav=94) = but only one userid, let=92s say =93prtuser=94, There is a single = password: =93passw0rd=94 (because we care about security) >>>>=20 >>>> So the client sends something like: >>>> Authorization: Basic cHJ0dXNlcjpwYXNzdzByZA=3D=3D = username=3D=93Michael" >>>=20 >>> No, the client just sends the standard Authorization header as = before, with "prtuser:passw0rd" Base64-encoded into the auth string like = so: >>>=20 >>> Authorization: Basic cHJ0dXNlcjpwYXNzdzByZA=3D=3D >>>=20 >>> The challenge from the server for this would look like: >>>=20 >>> WWW-Authenticate: Basic realm=3D"My Super Secure = Printer",charset=3D"UTF-8",username=3D"prtuser" >>>=20 >>>> So what does the server do with this string? Does it appear in a = log? Does the server verify that it belongs to some list of authorized = users? It=92s pretty easy to spoof if I know your username and the = userid/password combination. So I=92m not sure it counts as = =93authentication=94, although it might be useful. >>>=20 >>> The server is just authenticating as usual, and the "username" in = the WWW-Authenticate header tells the client that there is only one = possible username/account to authenticate against. >>>=20 >>>=20 >>>>=20 >>>> Yoav >>>>=20 >>>> On Jul 8, 2014, at 10:21 PM, Michael Sweet = wrote: >>>>=20 >>>>> All, >>>>>=20 >>>>> I'd like to propose a new "username" parameter for the HTTP Basic = Update: >>>>>=20 >>>>> = http://tools.ietf.org/html/draft-ietf-httpauth-basicauth-update-01 >>>>>=20 >>>>> The purpose of this parameter is to provide the username to be = used with a password provided by the user/client. The use case is = authenticated access to an embedded device such as a printer, video = camera, router, etc. where separate user accounts may not make sense but = where you want to have some form of authentication to prevent casual = access to the device. Currently you have to remember what a given = device's chosen username is ("root", "admin", "user", "config", etc.), = which makes for a poor user experience. >>>>>=20 >>>>> AirPrint has been using this parameter as an extension to HTTP = Basic for several years now... >>>>>=20 >>>>> The text changes are outlined below... >>>>>=20 >>>>> .... >>>>>=20 >>>>> Section 2 (The 'Basic' Authentication Scheme), add a new bullet: >>>>>=20 >>>>> o the authentication parameter "username" is OPTIONAL (see = Section 2.2) >>>>>=20 >>>>> New Section 2.2 (The 'username' auth-param) with the following = text: >>>>>=20 >>>>> In challenges, servers can use the "username" authentication = parameter to indicate the only supported "userid" value that can be = supplied in a subsequent Authorization request header. The value MUST = conform to the "userid" ABNF rules. >>>>>=20 >>>>> _________________________________________________________ >>>>> Michael Sweet, Senior Printing System Engineer, PWG Chair >>>>=20 >>>=20 >>> _________________________________________________________ >>> Michael Sweet, Senior Printing System Engineer, PWG Chair >>>=20 >>> _______________________________________________ >>> 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 >=20 _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Apple-Mail=_B4356BCD-214F-4E87-BFD7-E597BD448A5F Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPJTCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBSIwggQKoAMC AQICEQDlB7dXxclLEedquPvGX8CGMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBMB4XDTEzMTIxNzAwMDAwMFoXDTE0MTIxNzIzNTk1OVowITEfMB0GCSqG SIb3DQEJARYQbXN3ZWV0QGFwcGxlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ANdvQYZRCVzc0wIYvIOn/0Pv7zUwuIvbAfM/W3FyemqZx3fdKxX4WxN2x5NC3hhBHGrUWirJH7rl 6It12bGQ61uHAK5jsJikV5k+mOYjZaKNIKxj0uYIk3MKQmsmM8t3nddq5mp2mxwV/U7AFPTz1fgh dkqTb/NkHY5eA8KqksaeqwfMgoaiGVeCUhptWnXosca8PAkb+i9u5rEok5zgY+QP0IuWLJENfA4q dEMsH+OAwMGOv9fNCgcdapFnjeSYaj70m6qUiq446+8a2rhUsEUKQayOMgjnm2bgUuNx7pOvs/Jg zIlZoTz/llmE1HWREGzSjRnLWwQ98fspfeZWA+8CAwEAAaOCAeAwggHcMB8GA1UdIwQYMBaAFHoT TgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTtKBJoG9kxZisTqJg4+wr12l4stjAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIw EQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUH AgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6 Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1h aWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9j YS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggr BgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMBsGA1UdEQQUMBKBEG1zd2VldEBhcHBs ZS5jb20wDQYJKoZIhvcNAQEFBQADggEBABg5KLQK5u9gGI75u+vYH/i6uMDKlpTILO/r/FpN2ibq pwAB2ln9oKvPIA1/r3o+DBC87TqnlJAiPW4ADFHpRmqlprb0Tu9p98nP/wl5tBZjEP8dY4iH0TB3 B2r9JHwRwwJQ20CqJpuCn9dmvL215sZSqvJfluVlIcAQCLxp3ZKMIC2pNKitswdjjHduaKuj2TMe xrzMtrRGRtFF9pcMcnsqE2QtJUqXPV7/M4WT2yRUmI4ThPt9O9fmPH2ku52hdb6t4qXvwdQSkDHt xo3J/Vc/jDR2/feedDhQmG0V9j6tHsuG6bVVhcGiWnSmSoPfg13FlQwlxZTyFtiMZ2jILyoxggOu MIIDqgIBATCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAOUHt1fFyUsR 52q4+8ZfwIYwCQYFKw4DAhoFAKCCAdkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTQwNzA5MTQyOTM2WjAjBgkqhkiG9w0BCQQxFgQUpcO4XyoTJyQR+WjrKTLqnIy6 IW4wgboGCSsGAQQBgjcQBDGBrDCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx OTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIRAOUHt1fFyUsR52q4+8ZfwIYwgbwGCyqGSIb3DQEJEAILMYGsoIGpMIGTMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgU2VjdXJlIEVtYWlsIENBAhEA5Qe3V8XJSxHnarj7xl/AhjANBgkqhkiG9w0BAQEFAASC AQAfh7DMD5WYXGfx4zy/eA4CGrecNt4QHSWxcpLcG5rfz2uhCfoea3uqWrR7934BLfj1Ii6GHPEO hDf2dSjAX+hDfkSn2j9ZZrKlXSo/h3Z0JTMpmHj951hLvD3bUZJanCkzZOBiXRdAB9pKDulOFmJo pZmT6qQEFGt1bQl96gg4XZen19LdO7cGhhXLhtFRqP2YMuDULm8gslE2gEn4xx5YeJ+9aG2ldpGg GC4sl+p3/2FyTdlJ5QjyqB6K94cGQpUEAkNHABwsnnt++FpwRugelNXK23NY64qytEqVyVyQGkd8 YBsa+cUPfatA9At0QlP6ryeqB0YsHvgWjTa/mSSJAAAAAAAA --Apple-Mail=_B4356BCD-214F-4E87-BFD7-E597BD448A5F-- From nobody Wed Jul 9 07:39:52 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 764731A0AC7 for ; Wed, 9 Jul 2014 07:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t71rfO23tHPp for ; Wed, 9 Jul 2014 07:39:49 -0700 (PDT) Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A0E01A0AD4 for ; Wed, 9 Jul 2014 07:39:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1404916788; x=2268830388; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=8ihJRls5afuoSAZ+5vUjDtV/qGOoBaRdGTfSJL7jwWU=; b=0pB4trkOuae6lQDx+zAPOBhA0PptU/7yHpA42bY/7OVywzFXBfBpvvoKA2vAGIsz jaEnuqZkWZXFgkA8ZUTCZgStHAjo7UaHcZj3vQo7nSCxSkCIUymesm81+U020V19 1j2W4TXHsWRuh/Bb0PoHiQZckc1T/mkUbOLSUdp2igfkmAuBqzjAeo09TXaSDxM6 p29/HZHkxwkxQBba3EsZHv89ODREnDRtbCd5CxKvP4F6JY3gEg9yB1v851n6I46f /f8c+7vKuHCQtTZ4NPDiUsCOWWwtLpl1tFtraNspPBzhrMZVwIhmVt7ic3keg31w 1iwI8ZUzVIaGzglULL26IA==; Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id 28.E0.32596.4345DB35; Wed, 9 Jul 2014 07:39:48 -0700 (PDT) MIME-version: 1.0 Received: from relay7.apple.com ([17.128.113.101]) by local.mail-out.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTP id <0N8G00KHK8Q1XE90@local.mail-out.apple.com> for http-auth@ietf.org; Wed, 09 Jul 2014 07:39:48 -0700 (PDT) X-AuditID: 11973e15-f79d66d000007f54-7a-53bd5434ead4 Received: from spicerack.apple.com (spicerack.apple.com [17.128.115.40]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay7.apple.com (Apple SCV relay) with SMTP id 15.F5.19908.2245DB35; Wed, 9 Jul 2014 07:39:30 -0700 (PDT) Received: from [17.153.59.246] (unknown [17.153.59.246]) by spicerack.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0N8G00J598QAGH80@spicerack.apple.com> for http-auth@ietf.org; Wed, 09 Jul 2014 07:39:47 -0700 (PDT) From: Michael Sweet Content-type: multipart/signed; boundary="Apple-Mail=_4AA920FE-F71C-4748-A7F6-9DDE644F34E2"; protocol="application/pkcs7-signature"; micalg=sha1 Date: Wed, 09 Jul 2014 10:39:46 -0400 To: http-auth@ietf.org Message-id: <48E58805-14E7-425A-9069-D679BA9F305F@apple.com> X-Mailer: Apple Mail (2.1878.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUiON3OSNckZG+wQftrTosP++cwOTB6LFny kymAMYrLJiU1J7MstUjfLoEro+d9L2PBdtuKCcveMDUwXrXqYuTkkBAwkfi/dCsThC0mceHe erYuRi4OIYGZTBJvnnaBJXgFBCV+TL7HApGYxSTx61cXcxcjB1j3o7O2EPHJTBLrvj9ghSva eHYJC0g3m4CaxO9JfWAJZoEpjBL7px8AS7AIqEpcu/iKHcQWFoiUuDh1MSOILQJ0x4kp19gh VttIHFrawwJxn7zEhw/H2UEGSQh0sEkcWf6UZQKjwCwkJ85CtgQkwSygLbFs4WvmWUDnMgvo SExeyAgRNpV48nY7G4RtLfFzziOouKLElO6H7AsY2VcxCuUmZuboZuaZ6SUWFOSk6iXn525i hAS56A7GM6usDjEKcDAq8fAq8OwJFmJNLCuuzD3EKM3BoiTOO1caKCSQnliSmp2aWpBaFF9U mpNafIiRiYNTqoGRQ1bp1UPp4KeBsi8SLswzVJh3R0nteH3mqb6uG+uK7+8KUVX4Krn47KI9 LieefglsvhBwqOf/9/jZLOe1v7nOvHpyr1GWikBJ/u30PRpNSe+bFy+0T1LxSu3l2DiJUdHU 9MrhrmnZLLsPzZq+89yU7klnJGNlajpqZHnfcK4ST6iwKZnTqXhciaU4I9FQi7moOBEAkPLg WVMCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrELMWRmVeSWpSXmKPExsUi2FCsoasUsjfY4N8UVosP++cwOTB6LFny kymAMYrLJiU1J7MstUjfLoEro+d9L2PBdtuKCcveMDUwXrXqYuTgkBAwkXh01raLkRPIFJO4 cG89WxcjF4eQwGQmiTWXpzNCOLOYJDaeXcICUsUmoCbxe1IfK0iCWWAKo8T+6QfAEiwCqhLX Lr5iB7GFBSIlLk5dzAhiiwCNPTHlGlicV8BG4tDSHhYI20Di1c/HzBCr5SU+fDjOPoGRZxay ubOQ1IHYzALaEssWvgayOYBsHYnJCxkhwqYST95uZ4OwrSV+znkEFVeUmNL9kH0BI/sqRoGi 1JzESnO9xIKCnFS95PzcTYzg0CtM3cHYuNzqEKMAB6MSD68Cz55gIdbEsuLK3EOMKkAjHm1Y fYFRiiUvPy9VSYTX1XlvsBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXHeh8d3BwsJpCeWpGanphak FsFkmTg4pRoYL2j6pIdnrTpVJHOTs+Pf9FM6iQYTea5Zv4u/+fdjURJzvJ3wpH+/VsaLPFC7 9OeLYUGTKePPzensuSfXrs7b1Db5vWO/bMhRAeZEI76FcXHPLPTTNsVxu0o8lt9aUL7rW/uD iD+8D7ZGVhqx+rU6LYiJSynmm9Wxw736jtKdDS3FizjzYiSVWIozEg21mIuKEwGbfffwRQIA AA== Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/vODr8IoScM1HyjqGKVgMFmRxSw4 Subject: [http-auth] Additional security considerations for draft-ietf-httpauth-basicauth-update-01 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 14:39:51 -0000 --Apple-Mail=_4AA920FE-F71C-4748-A7F6-9DDE644F34E2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii All, I think we should say something about brute-force attacks on HTTP Basic; = since the client has to do basically no work to provide a Basic = Authorization header, it is very easy for an attacker to try thousands = of common usernames and passwords in a short period of time. A server = can mitigate this somewhat by tracking the number of failed = authentication attempts over a specific time span from a given IP = address and either return 403's for all subsequent attempts or delay = responses; the latter approach could lead to more DoS opportunities, of = course... I'm happy to draft up something official - comments welcome! _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Apple-Mail=_4AA920FE-F71C-4748-A7F6-9DDE644F34E2 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPJTCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBSIwggQKoAMC AQICEQDlB7dXxclLEedquPvGX8CGMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBMB4XDTEzMTIxNzAwMDAwMFoXDTE0MTIxNzIzNTk1OVowITEfMB0GCSqG SIb3DQEJARYQbXN3ZWV0QGFwcGxlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ANdvQYZRCVzc0wIYvIOn/0Pv7zUwuIvbAfM/W3FyemqZx3fdKxX4WxN2x5NC3hhBHGrUWirJH7rl 6It12bGQ61uHAK5jsJikV5k+mOYjZaKNIKxj0uYIk3MKQmsmM8t3nddq5mp2mxwV/U7AFPTz1fgh dkqTb/NkHY5eA8KqksaeqwfMgoaiGVeCUhptWnXosca8PAkb+i9u5rEok5zgY+QP0IuWLJENfA4q dEMsH+OAwMGOv9fNCgcdapFnjeSYaj70m6qUiq446+8a2rhUsEUKQayOMgjnm2bgUuNx7pOvs/Jg zIlZoTz/llmE1HWREGzSjRnLWwQ98fspfeZWA+8CAwEAAaOCAeAwggHcMB8GA1UdIwQYMBaAFHoT TgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTtKBJoG9kxZisTqJg4+wr12l4stjAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIw EQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUH AgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6 Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1h aWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9j YS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggr BgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMBsGA1UdEQQUMBKBEG1zd2VldEBhcHBs ZS5jb20wDQYJKoZIhvcNAQEFBQADggEBABg5KLQK5u9gGI75u+vYH/i6uMDKlpTILO/r/FpN2ibq pwAB2ln9oKvPIA1/r3o+DBC87TqnlJAiPW4ADFHpRmqlprb0Tu9p98nP/wl5tBZjEP8dY4iH0TB3 B2r9JHwRwwJQ20CqJpuCn9dmvL215sZSqvJfluVlIcAQCLxp3ZKMIC2pNKitswdjjHduaKuj2TMe xrzMtrRGRtFF9pcMcnsqE2QtJUqXPV7/M4WT2yRUmI4ThPt9O9fmPH2ku52hdb6t4qXvwdQSkDHt xo3J/Vc/jDR2/feedDhQmG0V9j6tHsuG6bVVhcGiWnSmSoPfg13FlQwlxZTyFtiMZ2jILyoxggOu MIIDqgIBATCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAOUHt1fFyUsR 52q4+8ZfwIYwCQYFKw4DAhoFAKCCAdkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTQwNzA5MTQzOTQ2WjAjBgkqhkiG9w0BCQQxFgQUvrfIXummzaaFM9bp4XaB05CC YKowgboGCSsGAQQBgjcQBDGBrDCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx OTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIRAOUHt1fFyUsR52q4+8ZfwIYwgbwGCyqGSIb3DQEJEAILMYGsoIGpMIGTMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgU2VjdXJlIEVtYWlsIENBAhEA5Qe3V8XJSxHnarj7xl/AhjANBgkqhkiG9w0BAQEFAASC AQBKOpMICQeGw3Y0dDygANojU1pkc7ZRhW+Vq9S51q9FINbIA6ODxJVhhGRlgIQ3METjHxags46E KqL7pEOhistY2R58UfTjm2zwMH7DceT10y4vOa+ckOHJ3ueBZmZ3LZc9rlGxhc1jqPNOHP0SvZDJ 7Ebp2FvQVxsH/E9GdLTFJlNTrJPgbeHKXlqe2MOTxGV4xg6uRWEhAtVyfS/NrSDXRBgKHSLeQ2aA bdEDqrShvXzqY9rWhBx8yoaIkc4/ttq0Q/wzv4tKMr6DBnBnsPKN4lWNPXBrC4abLytoGyqTOhCj MQ0QzS4jykb4GOTZk7RgcMjG+bMi7L3gulusWo5bAAAAAAAA --Apple-Mail=_4AA920FE-F71C-4748-A7F6-9DDE644F34E2-- From nobody Wed Jul 9 07:41:51 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 780EC1A0AC7 for ; Wed, 9 Jul 2014 07:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z2MoLOFzW2RO for ; Wed, 9 Jul 2014 07:41:48 -0700 (PDT) Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82C1B1A0AC5 for ; Wed, 9 Jul 2014 07:41:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1404916908; x=2268830508; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ZJPB5BwbKrHLDHzWPKnjSIJQEyObcj8AwqwpMXb+cvs=; b=cL5LwlJECISche3ou8jE7k3zXVv1PIocf/Sv2dQ3K0AyukAprnfAI4NU9T3kdtxz rWV8XKJt64e+FM4s7qe6L+zQYBcg2PeBgrxItrW45eqeBlfaiqUPNe1So7nafhRm JQxUJY3c60WffGKvR4lct3Ca69fNwvrXllrxwNtBWqhY9SIr6iva1gryUnoVVknb aX6m8eUigOIyPff+qdVKmB8Mmzgq3YsDDEZwWxb9jigQ2S6y9ZuRmpoNVh4IG/ed LzDGM+mBOJQ0yyoVN9MLygacgtlmPej0YFMhyuc62coIw+k0YulB9d4B4pg6cdKg FXqpblsF5q9+2LxgCoC7vg==; Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id 00.61.32596.CA45DB35; Wed, 9 Jul 2014 07:41:48 -0700 (PDT) MIME-version: 1.0 Received: from relay8.apple.com ([17.128.113.102]) by local.mail-out.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTP id <0N8G00E038TI2PK0@local.mail-out.apple.com> for http-auth@ietf.org; Wed, 09 Jul 2014 07:41:48 -0700 (PDT) X-AuditID: 11973e15-f79d66d000007f54-7a-53bd54ac1557 Received: from spicerack.apple.com (spicerack.apple.com [17.128.115.40]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay8.apple.com (Apple SCV relay) with SMTP id DB.DA.11638.CA45DB35; Wed, 9 Jul 2014 07:41:48 -0700 (PDT) Received: from [17.153.59.246] (unknown [17.153.59.246]) by spicerack.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0N8G00J898TLGH80@spicerack.apple.com> for http-auth@ietf.org; Wed, 09 Jul 2014 07:41:47 -0700 (PDT) Content-type: multipart/signed; boundary="Apple-Mail=_2151D37F-DDA1-4B20-B343-6B5014A36EE1"; protocol="application/pkcs7-signature"; micalg=sha1 From: Michael Sweet In-reply-to: <53BCDFA8.90403@gmx.de> Date: Wed, 09 Jul 2014 10:41:45 -0400 Message-id: <88004C25-6224-4A9B-B3E0-4DB64F7EDF7C@apple.com> References: <9F9B2F65-031C-43A1-84F3-8A3B0CC24E0C@apple.com> <53BCDFA8.90403@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1878.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUiON3OUHdNyN5gg2c7eCw+7J/D5MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujJ17O9gK/thWfJtl2cDYad3FyMkhIWAicXzjB3YIW0ziwr31 bF2MXBxCAjOZJD4+3w+W4BUQlPgx+R4LiC0kMItJYsfncpjmtZ07mSAaJjNJrDn3AMoBKjq2 ZTEzSJWwQKjEivs7WEESzAJTGCXmP13CBpJgE1CT+D2pjxXE5hRQkVj25wNYnEVAVWL+ncNg zcxAN3U8vMQGcYaNxO/Fl1khzgiTuL3kFFhcREBL4va9vYwQJ8lLfPhwnB1kmYTAOjaJk+sP sk1gFJ6F5I1ZyA6ZBbZEW2LZwtfMELaexMumd+wQtqnEk7fboWqsJX7OecQIYStKTOl+yL6A kX0Vo1BuYmaObmaemV5iQUFOql5yfu4mRki0iO5gPLPK6hCjAAejEg+vAs+eYCHWxLLiytxD jNIcLErivHOlgUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYoze+3Nm6TUvk+sTvXSWndDra 6jYciXmy1dfqWuLdDX1JVcequSYvrP2twyGr+vHRf84wba0nz5oWNhuUn7/8d/OFOS18M/Ln Gu/0bsyMNTwk3fI9PKP1e+wFuUJp0biYIkm2s5Z5Rx9/en7owbOD3gtmdV6Z+GlarIvMs7n1 G3SWbJznYG6VrsRSnJFoqMVcVJwIALu9Zn53AgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUi2FCsobsmZG+wwfRTOhYf9s9hcmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxs69HWwFf2wrvs2ybGDstO5i5OSQEDCRWNu5kwnCFpO4cG89 WxcjF4eQwGQmiVk3fzFBOLOYJI5tWcwMUiUsECqx4v4OVhCbV8BA4tXPx8wgRcwCUxgl5j9d wgaSYBNQk/g9qQ+siFNARWLZnw9gcRYBVYn5dw6DDWIGWtfx8BIbxCAbid+LL4PVCwmESdxe cgosLiKgJXH73l5GiPPkJT58OM4+gZF/FpLds5DtngU2V1ti2cLXzBC2nsTLpnfsELapxJO3 26FqrCV+znnECGErSkzpfsi+gJF9FaNAUWpOYqWFXmJBQU6qXnJ+7iZGcBAXpu1gbFpudYhR gINRiYf3BOeeYCHWxLLiytxDjCpAIx5tWH2BUYolLz8vVUmE19V5b7AQb0piZVVqUX58UWlO avEhRmkOFiVx3s/HdwcLCaQnlqRmp6YWpBbBZJk4OKUaGA//fX5pzVRjq3vzFmi+WfTwXL/c jHz1C60rGKJexUSL7D7jMjUl87PghEf7RcXOTS0/eb/OmkF705X8HzLO9S6BPfX3TyccO5he YV+Tyv5r3uopzg8EJ1TNO/GHSWvyZdYtH37d+SUbtvWPWFBjXsobk3n/3ik392qzc3/Tt9t0 /u+DFrlzbZuVWIozEg21mIuKEwGoU/1lagIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/sxXml6Xgh4yTIwSxMb1sVBi24aU Cc: http-auth@ietf.org Subject: Re: [http-auth] Proposal: username parameter for HTTP Basic authentication X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 14:41:50 -0000 --Apple-Mail=_2151D37F-DDA1-4B20-B343-6B5014A36EE1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Julian, On Jul 9, 2014, at 2:22 AM, Julian Reschke = wrote: > ... > I've got two concerns: >=20 > 1) If we add this parameter it sort of indicates that new parameters = are needed in practice, in which case we should make this an extension = and define a registry. Happy to go either way; as an extension we could make specific = recommendations about the username value, security considerations, etc. = that don't apply to Basic in general. > 2) It adds a new parameter with broken internationalization. (We could = invoke RFC5987 for realm and username, though). Broken how? We can define "charset" as applying to the username value = (and realm, too, for that matter). _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Apple-Mail=_2151D37F-DDA1-4B20-B343-6B5014A36EE1 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPJTCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBSIwggQKoAMC AQICEQDlB7dXxclLEedquPvGX8CGMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBMB4XDTEzMTIxNzAwMDAwMFoXDTE0MTIxNzIzNTk1OVowITEfMB0GCSqG SIb3DQEJARYQbXN3ZWV0QGFwcGxlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ANdvQYZRCVzc0wIYvIOn/0Pv7zUwuIvbAfM/W3FyemqZx3fdKxX4WxN2x5NC3hhBHGrUWirJH7rl 6It12bGQ61uHAK5jsJikV5k+mOYjZaKNIKxj0uYIk3MKQmsmM8t3nddq5mp2mxwV/U7AFPTz1fgh dkqTb/NkHY5eA8KqksaeqwfMgoaiGVeCUhptWnXosca8PAkb+i9u5rEok5zgY+QP0IuWLJENfA4q dEMsH+OAwMGOv9fNCgcdapFnjeSYaj70m6qUiq446+8a2rhUsEUKQayOMgjnm2bgUuNx7pOvs/Jg zIlZoTz/llmE1HWREGzSjRnLWwQ98fspfeZWA+8CAwEAAaOCAeAwggHcMB8GA1UdIwQYMBaAFHoT TgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTtKBJoG9kxZisTqJg4+wr12l4stjAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIw EQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUH AgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6 Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1h aWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9j YS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggr BgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMBsGA1UdEQQUMBKBEG1zd2VldEBhcHBs ZS5jb20wDQYJKoZIhvcNAQEFBQADggEBABg5KLQK5u9gGI75u+vYH/i6uMDKlpTILO/r/FpN2ibq pwAB2ln9oKvPIA1/r3o+DBC87TqnlJAiPW4ADFHpRmqlprb0Tu9p98nP/wl5tBZjEP8dY4iH0TB3 B2r9JHwRwwJQ20CqJpuCn9dmvL215sZSqvJfluVlIcAQCLxp3ZKMIC2pNKitswdjjHduaKuj2TMe xrzMtrRGRtFF9pcMcnsqE2QtJUqXPV7/M4WT2yRUmI4ThPt9O9fmPH2ku52hdb6t4qXvwdQSkDHt xo3J/Vc/jDR2/feedDhQmG0V9j6tHsuG6bVVhcGiWnSmSoPfg13FlQwlxZTyFtiMZ2jILyoxggOu MIIDqgIBATCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAOUHt1fFyUsR 52q4+8ZfwIYwCQYFKw4DAhoFAKCCAdkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTQwNzA5MTQ0MTQ1WjAjBgkqhkiG9w0BCQQxFgQUY/ifnTC3oJXyJV7XaYwShJG+ HIYwgboGCSsGAQQBgjcQBDGBrDCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx OTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIRAOUHt1fFyUsR52q4+8ZfwIYwgbwGCyqGSIb3DQEJEAILMYGsoIGpMIGTMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgU2VjdXJlIEVtYWlsIENBAhEA5Qe3V8XJSxHnarj7xl/AhjANBgkqhkiG9w0BAQEFAASC AQBGoY64tQnn8x1r/nUp/0bGqueYK8KuAucjwSvD2ADy0nko5l0DCFySjMK/9xOrgEvpQBW6Xaz5 KgkhJd/5yCHUxPSDOKXJWby+McvLoH4gMIRdS/lInyemEkadt/jlMS0fukyFHcQ/V31AGIy+NW2U nTZ/8Zfz9u45z4bLFNi3E2Si78LkSZV2UFIKKZJMmmYLmakBZTeH0geciwA4YbQXoqlUOAsRSZ/C v8v8q4++Zc7vyjuPFxcKpa2DjrexRGxABH4Iqn2UabEe3N/M9gQH3YInhukDg7k02anY43c2e2ok p1T0ZW7JHeVlYOxMegFgJod4USky6HUi58G7OT4uAAAAAAAA --Apple-Mail=_2151D37F-DDA1-4B20-B343-6B5014A36EE1-- From nobody Wed Jul 9 08:12:34 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7144D1A0AC7 for ; Wed, 9 Jul 2014 08:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8CbKxVJ6GBvA for ; Wed, 9 Jul 2014 08:12:31 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E67E1A0396 for ; Wed, 9 Jul 2014 08:12:30 -0700 (PDT) Received: from [192.168.1.106] ([217.91.35.233]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Ld4xA-1WN4Lh0oWO-00iAqD; Wed, 09 Jul 2014 17:12:25 +0200 Message-ID: <53BD5BD5.7030009@gmx.de> Date: Wed, 09 Jul 2014 17:12:21 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Michael Sweet References: <9F9B2F65-031C-43A1-84F3-8A3B0CC24E0C@apple.com> <53BCDFA8.90403@gmx.de> <88004C25-6224-4A9B-B3E0-4DB64F7EDF7C@apple.com> In-Reply-To: <88004C25-6224-4A9B-B3E0-4DB64F7EDF7C@apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:IX1i+thFjhjreeWlfTmt5oVynk9yKa6DkDYI0B2d3e2mi3VU1u9 q1bF7lZhzKegHmPq28Oux8mt+K0dLh/V0V4MOBoU1CUg+jYEPsdikl9O7i0kZDh5bEcFaB8 fruYDDxKapy/gKNmtMLlx7f0BqBr4GMnqVsDrev4hGokO3CXy5LRKHtZn/Wf88IxLu3hhtO M6h8gqjHcd6QcVtJ7hmPA== Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/WhIAwzp8vNU6RSkXikNIBrO3PPg Cc: http-auth@ietf.org Subject: Re: [http-auth] Proposal: username parameter for HTTP Basic authentication X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 15:12:33 -0000 On 2014-07-09 16:41, Michael Sweet wrote: > Julian, > > On Jul 9, 2014, at 2:22 AM, Julian Reschke wrote: >> ... >> I've got two concerns: >> >> 1) If we add this parameter it sort of indicates that new parameters are needed in practice, in which case we should make this an extension and define a registry. > > Happy to go either way; as an extension we could make specific recommendations about the username value, security considerations, etc. that don't apply to Basic in general. > >> 2) It adds a new parameter with broken internationalization. (We could invoke RFC5987 for realm and username, though). > > Broken how? We can define "charset" as applying to the username value (and realm, too, for that matter). I wouldn't count on intermediaries and APIs passing through non-ASCII octets intact. Best regards, Julian From nobody Wed Jul 9 08:14:51 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A586D1A03E3 for ; Wed, 9 Jul 2014 08:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id St0hKVfM0RYO for ; Wed, 9 Jul 2014 08:14:44 -0700 (PDT) Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD8351A0396 for ; Wed, 9 Jul 2014 08:14:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1404918884; x=2268832484; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=NVPAaSI/ki85ZA8KlQf5suhfBG66pOQ1XnJNvFqUGWA=; b=OoxTegQ2loVGq1P8duzaEgV3KLk0y2xoCiEmEGEsjs8TEKHYJcyXY72bH6jFRlwv jJD6WD0NFIzJuWxBNqarxewaNgKEwYtKMWTpuv1TBj4paA1LIw9yrKposoFnnL9Q Y0ZjEY1DT4ddIO4mrv+AUWtnmOHNPh1vyEwzXdzQSyf1AFztmqjv3BKM2wWMST2O aUtUJPzO52TGRfvQeDNXIAzdPZbmMp0l2MQ60UWgi7B5Lf/VB1b3yZG90r0wYXLm vX3o8rlA0N7QM53Yd+gaE9EwReQtuqMU6BfA3MevzSdX7q7MO4MwBjebbM+Ugx0j wF1ocy7VYP11X1jrhmWo4g==; Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id 85.8D.09894.46C5DB35; Wed, 9 Jul 2014 08:14:44 -0700 (PDT) MIME-version: 1.0 Received: from relay5.apple.com ([17.128.113.88]) by local.mail-out.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTP id <0N8G00K9LAB1XED0@local.mail-out.apple.com> for http-auth@ietf.org; Wed, 09 Jul 2014 08:14:44 -0700 (PDT) X-AuditID: 11973e11-f79256d0000026a6-c7-53bd5c64b79b Received: from spicerack.apple.com (spicerack.apple.com [17.128.115.40]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id 45.A1.31858.46C5DB35; Wed, 9 Jul 2014 08:14:44 -0700 (PDT) Received: from [17.153.59.246] (unknown [17.153.59.246]) by spicerack.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0N8G0088GACI7C10@spicerack.apple.com> for http-auth@ietf.org; Wed, 09 Jul 2014 08:14:44 -0700 (PDT) Content-type: multipart/signed; boundary="Apple-Mail=_D206D9F9-DACB-4D88-AAD1-D91A390C1F40"; protocol="application/pkcs7-signature"; micalg=sha1 From: Michael Sweet In-reply-to: <53BD5BD5.7030009@gmx.de> Date: Wed, 09 Jul 2014 11:14:42 -0400 Message-id: References: <9F9B2F65-031C-43A1-84F3-8A3B0CC24E0C@apple.com> <53BCDFA8.90403@gmx.de> <88004C25-6224-4A9B-B3E0-4DB64F7EDF7C@apple.com> <53BD5BD5.7030009@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1878.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGLMWRmVeSWpSXmKPExsUiON3OSDclZm+wQccfRYsP++cwOTB6LFny kymAMYrLJiU1J7MstUjfLoEr48mnN8wFi20rXsydxNjAeMyqi5GTQ0LAROLhmVYmCFtM4sK9 9WxdjFwcQgIzmSS2/djDDpLgFRCU+DH5Hgtc4szu30AdHGDdR47FQsQnM0lsf3SfGcKZxSSx ua0NbKywQKjEivs7WEESzAJTGCWa9r1jA0mwCahJ/J7UxwpicwLZC67uYQaxWQRUJd68/wi2 mhnopo6Hl9ggzrCRWDGtBeq+xYwSBw62gyVEBLQkbt/bywjxhLzEhw/H2UGKJATWsUnsm3iF bQKj8Cwkf8xCdskssC3aEssWvmaGsPUkXja9Y4ewTSWevN0OVWMt8XPOI0YIW1FiSvdD9gWM 7KsYhXITM3N0M/OM9BILCnJS9ZLzczcxQiJGcAfj8VVWhxgFOBiVeHgVePYEC7EmlhVX5h5i lOZgURLnnSsNFBJITyxJzU5NLUgtii8qzUktPsTIxMEp1cD4kcFS9/Zsq6biwIPy0w+a+RWb /ub3+JF48u1JJjnzzjzP0vBXWr1aRxkOH157IMr1emzTmwstx+Y3x59atueIqEBPvPXTFSwz s11NVwtZZDx/tC23pjCIeWLDjEd3OnLSnrMZXg09fczLWMdqXqBpr1iLpYhEU0NH17VJF2+c 9zxW9f6y3gQlluKMREMt5qLiRACVJX6AeQIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUi2FCsoZsSszfYYMM6E4sP++cwOTB6LFny kymAMYrLJiU1J7MstUjfLoEr48mnN8wFi20rXsydxNjAeMyqi5GDQ0LAROLIsdguRk4gU0zi wr31bCC2kMBkJomWn+JdjFxA9iwmic1tbUwgCWGBUIkV93ewgti8AgYSr34+ZgYpYhaYwijR tO8dWDebgJrE70l9YEWcQPaCq3uYQWwWAVWJN+8/soPYzEDbOh5eYoMYZCOxYloLG8S2xYwS Bw62gyVEBLQkbt/bywhxnrzEhw/H2Scw8s9CsnwWsuWzwAZrSyxb+JoZwtaTeNn0jh3CNpV4 8nY7VI21xM85jxghbEWJKd0P2Rcwsq9iFChKzUmsNNVLLCjISdVLzs/dxAgO4sKIHYz/l1kd YhTgYFTi4VXg2RMsxJpYVlyZe4hRBWjEow2rLzBKseTl56UqifAKh+0NFuJNSaysSi3Kjy8q zUktPsQozcGiJM77+fjuYCGB9MSS1OzU1ILUIpgsEwenVANjzOHexxt2XC2Svx375MahLN0p e4MiZfz8mjeKFb03uVOckfb5ieo9p+Y47q9cjYsi3/9q4Kw7WfXpZniB6c+MjJuvX7dkBx5/ uFRhzjPJSoXP/b3zr+/SEN09f+m82QLRDFneZq/4PA7clz5VkXn2j8T9RfW/mbpbI6au2H3t qN/0HexHP1UbKrEUZyQaajEXFScCANLF7UpqAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/AnxZd4pKUVtNV541mt7yX7Nz4OA Cc: http-auth@ietf.org Subject: Re: [http-auth] Proposal: username parameter for HTTP Basic authentication X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 15:14:46 -0000 --Apple-Mail=_D206D9F9-DACB-4D88-AAD1-D91A390C1F40 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Julian, On Jul 9, 2014, at 11:12 AM, Julian Reschke = wrote: >> ... >>> 2) It adds a new parameter with broken internationalization. (We = could invoke RFC5987 for realm and username, though). >>=20 >> Broken how? We can define "charset" as applying to the username value = (and realm, too, for that matter). >=20 > I wouldn't count on intermediaries and APIs passing through non-ASCII = octets intact. Oh, right, because HTTP field values are not UTF-8 safe... I would = argue this is more of a problem for realm than the username parameter, = but we should say something regardless... _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Apple-Mail=_D206D9F9-DACB-4D88-AAD1-D91A390C1F40 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPJTCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBSIwggQKoAMC AQICEQDlB7dXxclLEedquPvGX8CGMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBMB4XDTEzMTIxNzAwMDAwMFoXDTE0MTIxNzIzNTk1OVowITEfMB0GCSqG SIb3DQEJARYQbXN3ZWV0QGFwcGxlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ANdvQYZRCVzc0wIYvIOn/0Pv7zUwuIvbAfM/W3FyemqZx3fdKxX4WxN2x5NC3hhBHGrUWirJH7rl 6It12bGQ61uHAK5jsJikV5k+mOYjZaKNIKxj0uYIk3MKQmsmM8t3nddq5mp2mxwV/U7AFPTz1fgh dkqTb/NkHY5eA8KqksaeqwfMgoaiGVeCUhptWnXosca8PAkb+i9u5rEok5zgY+QP0IuWLJENfA4q dEMsH+OAwMGOv9fNCgcdapFnjeSYaj70m6qUiq446+8a2rhUsEUKQayOMgjnm2bgUuNx7pOvs/Jg zIlZoTz/llmE1HWREGzSjRnLWwQ98fspfeZWA+8CAwEAAaOCAeAwggHcMB8GA1UdIwQYMBaAFHoT TgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTtKBJoG9kxZisTqJg4+wr12l4stjAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIw EQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUH AgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6 Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1h aWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9j YS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggr BgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMBsGA1UdEQQUMBKBEG1zd2VldEBhcHBs ZS5jb20wDQYJKoZIhvcNAQEFBQADggEBABg5KLQK5u9gGI75u+vYH/i6uMDKlpTILO/r/FpN2ibq pwAB2ln9oKvPIA1/r3o+DBC87TqnlJAiPW4ADFHpRmqlprb0Tu9p98nP/wl5tBZjEP8dY4iH0TB3 B2r9JHwRwwJQ20CqJpuCn9dmvL215sZSqvJfluVlIcAQCLxp3ZKMIC2pNKitswdjjHduaKuj2TMe xrzMtrRGRtFF9pcMcnsqE2QtJUqXPV7/M4WT2yRUmI4ThPt9O9fmPH2ku52hdb6t4qXvwdQSkDHt xo3J/Vc/jDR2/feedDhQmG0V9j6tHsuG6bVVhcGiWnSmSoPfg13FlQwlxZTyFtiMZ2jILyoxggOu MIIDqgIBATCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAOUHt1fFyUsR 52q4+8ZfwIYwCQYFKw4DAhoFAKCCAdkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTQwNzA5MTUxNDQyWjAjBgkqhkiG9w0BCQQxFgQU7NDOzSUfKuVamBo95roRBInD HEwwgboGCSsGAQQBgjcQBDGBrDCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx OTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIRAOUHt1fFyUsR52q4+8ZfwIYwgbwGCyqGSIb3DQEJEAILMYGsoIGpMIGTMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgU2VjdXJlIEVtYWlsIENBAhEA5Qe3V8XJSxHnarj7xl/AhjANBgkqhkiG9w0BAQEFAASC AQC3LbEvr1eP1RArFckrw1tqhwpXoJBRSUIi29sIAihCDPaXtXYLdDCjbp4iydG1VO34wQ/nGISS RQCFp0v8PNaPaakHQqVFYznAynq0nzsnVfvczF6meAhxUtnns6ktouvxZpMbruISf0ooBiw80KBL fwgEd/2cZ1ZWSLI+v4MO2khUUA0VHnDvCuSGpeomiAhTNgSneSVQ3Oe0qvKEIymgqI/TdySx6qX1 MTUkYuzCdJvD8kmDeN7s7hyOXRIVkGxcn+Ax85oeOTLrkERZlJ4rXS/BQux7+SJH8ohLpVLzPhSp Wy6on/psj2dLfFuSXoGmqZjS+9J07lojbauLnQ8BAAAAAAAA --Apple-Mail=_D206D9F9-DACB-4D88-AAD1-D91A390C1F40-- From nobody Wed Jul 9 09:00:21 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1B421A0B09 for ; Wed, 9 Jul 2014 09:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dQTAL4lj8_3 for ; Wed, 9 Jul 2014 09:00:16 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B9861A0B13 for ; Wed, 9 Jul 2014 09:00:13 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s69G09jY023645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 9 Jul 2014 16:00:10 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s69G08Gw017500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 9 Jul 2014 16:00:08 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s69G07XR017431; Wed, 9 Jul 2014 16:00:08 GMT Received: from [192.168.1.188] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 09 Jul 2014 09:00:07 -0700 Content-Type: multipart/alternative; boundary="Apple-Mail=_F6D34E90-38C7-42CB-934B-E25ECFF631F5" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Phil Hunt In-Reply-To: <996D8E94-68CC-42C7-A0A6-617D3C36DEDF@apple.com> Date: Wed, 9 Jul 2014 09:00:05 -0700 Message-Id: <97F4552B-DBE5-48FE-888F-463DF65FF62E@oracle.com> References: <9F9B2F65-031C-43A1-84F3-8A3B0CC24E0C@apple.com> <0DCD8299-B5AE-4609-BD01-2D3F03EBF872@gmail.com> <7957705E-E585-4A10-9876-34F10F9FAB6E@apple.com> <996D8E94-68CC-42C7-A0A6-617D3C36DEDF@apple.com> To: Michael Sweet X-Mailer: Apple Mail (2.1878.6) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/ZwIr6XrYh8mjFFdrDFXUk0zoAS8 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Proposal: username parameter for HTTP Basic authentication X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 16:00:19 -0000 --Apple-Mail=_F6D34E90-38C7-42CB-934B-E25ECFF631F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 See inliine Phil @independentid www.independentid.com phil.hunt@oracle.com On Jul 9, 2014, at 6:58 AM, Michael Sweet wrote: > Phil, >=20 > On Jul 8, 2014, at 9:54 PM, Phil Hunt wrote: >> Certainly nice from a device ui perspective. But also screams attack = me using this account cause I'm a router/printer etc.=20 >=20 > The Server header in the HTTP response is enough for that. And nmap = and other tools are pretty good at identifying embedded devices on your = network already, so I don't think adding this one parameter will make it = more likely that the device will be attacked=85 [PH}Maybe, but randomize the userid helps doesn=92t it? >=20 >> What about a username printed on the device? At least the UI problem = gets easier and the username is obtained "out-of-band".=20 >=20 > I don't know about you, but my Wi-Fi access points are in = out-of-the-way locations, and such stickers/labels are usually on the = back side or bottom of the unit - not exactly convenient (particularly = for a printer...) and usually in the dark so it is impossible to read=85 [PH] True. But when you first install it, it is visible. I think this = speaks to a need for identity memory in the home domain. How do clients = remember what identities to use with specific devices, etc. Should there = be a repository of identities in the router, in the cloud? Password = based auth seems like an anti-pattern even here. May be a token based = system... See ACE comment below... >=20 >> There is also some other approaches being discussed in the ACE WG. >=20 > Ah, hadn't noticed that group was formed, however their focus is on = constrained devices - IoT stuff - and not on "peripheral" devices like = home routers, printers, cameras, etc. The assumption in that WG is that = all constrained devices use RESTful APIs, and many of the current drafts = focus on using 3-party auth schemes like OAuth or certificate validation = to authorize access to them. Auto-configuration for that environment = will be very important, and it will be interesting to see how they = address scaling, discovery, and network boundaries - something that the = Homenet and DNSSD WG are working on... >=20 > Was there a particular approach you were thinking of that could be = used with printers, etc. in place of the "username" parameter? [PH] The constrained protocol aspects aren=92t really an interest in = your case. But there=92s certainly an IoT aspect of how to register = clients and service providers that have limited capability to do = sophisticated access or ID management. As in your case, the device only = has one basic auth enabled userid and password.=20 A token based architecture might be the path to simplicity here. If ACE = deals with the IoT registration and discovery issue, then very likely it = would work well for home =93network=94 domains. =20 The idea here would be to get away from fixed attackable user-ids and = allow the home network to depend less on its firewall/NAT security. >=20 >=20 >> On Jul 8, 2014, at 17:09, Michael Sweet wrote: >>=20 >>> Yoav, >>>=20 >>> On Jul 8, 2014, at 5:36 PM, Yoav Nir wrote: >>>> Hi, Michael. >>>>=20 >>>> Just to make sure that I understand you correctly, in your use case = there are two people (let=92s call them =93Michael=94 and =93Yoav=94) = but only one userid, let=92s say =93prtuser=94, There is a single = password: =93passw0rd=94 (because we care about security) >>>>=20 >>>> So the client sends something like: >>>> Authorization: Basic cHJ0dXNlcjpwYXNzdzByZA=3D=3D = username=3D=93Michael" >>>=20 >>> No, the client just sends the standard Authorization header as = before, with "prtuser:passw0rd" Base64-encoded into the auth string like = so: >>>=20 >>> Authorization: Basic cHJ0dXNlcjpwYXNzdzByZA=3D=3D >>>=20 >>> The challenge from the server for this would look like: >>>=20 >>> WWW-Authenticate: Basic realm=3D"My Super Secure = Printer",charset=3D"UTF-8",username=3D"prtuser" >>>=20 >>>> So what does the server do with this string? Does it appear in a = log? Does the server verify that it belongs to some list of authorized = users? It=92s pretty easy to spoof if I know your username and the = userid/password combination. So I=92m not sure it counts as = =93authentication=94, although it might be useful. >>>=20 >>> The server is just authenticating as usual, and the "username" in = the WWW-Authenticate header tells the client that there is only one = possible username/account to authenticate against. >>>=20 >>>=20 >>>>=20 >>>> Yoav >>>>=20 >>>> On Jul 8, 2014, at 10:21 PM, Michael Sweet = wrote: >>>>=20 >>>>> All, >>>>>=20 >>>>> I'd like to propose a new "username" parameter for the HTTP Basic = Update: >>>>>=20 >>>>> = http://tools.ietf.org/html/draft-ietf-httpauth-basicauth-update-01 >>>>>=20 >>>>> The purpose of this parameter is to provide the username to be = used with a password provided by the user/client. The use case is = authenticated access to an embedded device such as a printer, video = camera, router, etc. where separate user accounts may not make sense but = where you want to have some form of authentication to prevent casual = access to the device. Currently you have to remember what a given = device's chosen username is ("root", "admin", "user", "config", etc.), = which makes for a poor user experience. >>>>>=20 >>>>> AirPrint has been using this parameter as an extension to HTTP = Basic for several years now... >>>>>=20 >>>>> The text changes are outlined below... >>>>>=20 >>>>> .... >>>>>=20 >>>>> Section 2 (The 'Basic' Authentication Scheme), add a new bullet: >>>>>=20 >>>>> o the authentication parameter "username" is OPTIONAL (see = Section 2.2) >>>>>=20 >>>>> New Section 2.2 (The 'username' auth-param) with the following = text: >>>>>=20 >>>>> In challenges, servers can use the "username" authentication = parameter to indicate the only supported "userid" value that can be = supplied in a subsequent Authorization request header. The value MUST = conform to the "userid" ABNF rules. >>>>>=20 >>>>> _________________________________________________________ >>>>> Michael Sweet, Senior Printing System Engineer, PWG Chair >>>>=20 >>>=20 >>> _________________________________________________________ >>> Michael Sweet, Senior Printing System Engineer, PWG Chair >>>=20 >>> _______________________________________________ >>> http-auth mailing list >>> http-auth@ietf.org >>> https://www.ietf.org/mailman/listinfo/http-auth >=20 > _________________________________________________________ > Michael Sweet, Senior Printing System Engineer, PWG Chair >=20 --Apple-Mail=_F6D34E90-38C7-42CB-934B-E25ECFF631F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 See = inliine

On Jul 9, 2014, at 6:58 AM, Michael Sweet <msweet@apple.com> = wrote:

Phil,

On Jul 8, 2014, at 9:54 PM, = Phil Hunt <phil.hunt@oracle.com> = wrote:
Certainly nice = from a device ui perspective. But also screams attack me using this = account cause I'm a router/printer = etc. 

The Server header in the = HTTP response is enough for that.  And nmap and other tools are = pretty good at identifying embedded devices on your network already, so = I don't think adding this one parameter will make it more likely that = the device will be attacked=85
[PH}Maybe, = but randomize the userid helps doesn=92t it?

What about a username printed on the = device? At least the UI problem gets easier and the username is obtained = "out-of-band". 

I don't know about = you, but my Wi-Fi access points are in out-of-the-way locations, and = such stickers/labels are usually on the back side or bottom of the unit = - not exactly convenient (particularly for a printer...) and usually in = the dark so it is impossible to read=85
[PH]= True. But when you first install it, it is visible. I think this speaks = to a need for identity memory in the home domain. How do clients = remember what identities to use with specific devices, etc. Should there = be a repository of identities in the router, in the cloud? Password = based auth seems like an anti-pattern even here. May be a token based = system...  See ACE comment below...

There is also some other approaches = being discussed in the ACE WG.

Ah, = hadn't noticed that group was formed, however their focus is on = constrained devices - IoT stuff - and not on "peripheral" devices like = home routers, printers, cameras, etc.  The assumption in that WG is = that all constrained devices use RESTful APIs, and many of the current = drafts focus on using 3-party auth schemes like OAuth or certificate = validation to authorize access to them.  Auto-configuration for = that environment will be very important, and it will be interesting to = see how they address scaling, discovery, and network boundaries - = something that the Homenet and DNSSD WG are working = on...

Was there a particular approach you were = thinking of that could be used with printers, etc. in place of the = "username" parameter?

[PH] =  The constrained protocol aspects aren=92t really an interest in = your case. But there=92s certainly an IoT aspect of how to register = clients and service providers that have limited capability to do = sophisticated access or ID management. As in your case, the device only = has one basic auth enabled userid and = password. 

A token based architecture = might be the path to simplicity here. If ACE deals with the IoT = registration and discovery issue, then very likely it would work well = for home =93network=94 domains.  

The idea = here would be to get away from fixed attackable user-ids and allow the = home network to depend less on its firewall/NAT = security.


On Jul 8, 2014, at 17:09, Michael = Sweet <msweet@apple.com> = wrote:

Yoav,

On Jul 8, 2014, at 5:36 = PM, Yoav Nir <ynir.ietf@gmail.com> = wrote:
Hi, Michael.

Just to make sure = that I understand you correctly, in your use case there are two people = (let=92s call them =93Michael=94 and =93Yoav=94) but only one userid, = let=92s say =93prtuser=94, There is a single password: =93passw0rd=94 = (because we care about security)

So the client = sends something like:
Authorization: Basic cHJ0dXNlcjpwYXNzdzByZA=3D=3D = username=3D=93Michael"

No, = the client just sends the standard Authorization header as before, with = "prtuser:passw0rd" Base64-encoded into the auth string like = so:

    Authorization: = Basic cHJ0dXNlcjpwYXNzdzByZA=3D=3D

The = challenge from the server for this would look = like:

    WWW-Authenticate: = Basic realm=3D"My Super Secure = Printer",charset=3D"UTF-8",username=3D"prtuser"

=
So what does the server do with this string? Does it = appear in a log? Does the server verify that it belongs to some list of = authorized users?  It=92s pretty easy to spoof if I know your = username and the userid/password combination.  So I=92m not sure it = counts as =93authentication=94, although it might be = useful.

The server is just = authenticating as usual, and the "username" in the WWW-Authenticate = header tells the client that there is only one possible username/account = to authenticate = against.



Yoav

On Jul 8, 2014, at 10:21 PM, Michael = Sweet <msweet@apple.com> = wrote:

All,

I'd like to propose a new "username" parameter = for the HTTP Basic Update:

   http://tools.ietf.org/html/draft-ietf-httpauth-basicauth-update-01
The purpose of this parameter is to provide the username to be = used with a password provided by the user/client.  The use case is = authenticated access to an embedded device such as a printer, video = camera, router, etc. where separate user accounts may not make sense but = where you want to have some form of authentication to prevent casual = access to the device.  Currently you have to remember what a given = device's chosen username is ("root", "admin", "user", "config", etc.), = which makes for a poor user experience.

AirPrint has been using = this parameter as an extension to HTTP Basic for several years = now...

The text changes are outlined = below...

....

Section 2 (The 'Basic' Authentication = Scheme), add a new bullet:

   o  the = authentication parameter "username" is OPTIONAL (see Section = 2.2)

New Section 2.2 (The 'username' auth-param) with the = following text:

In challenges, servers can use the "username" = authentication parameter to indicate the only supported "userid" value = that can be supplied in a subsequent Authorization request header. The = value MUST conform to the "userid" ABNF = rules.

_________________________________________________________Michael Sweet, Senior Printing System Engineer, PWG = Chair


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

In-reply-to: <97F4552B-DBE5-48FE-888F-463DF65FF62E@oracle.com> Date: Wed, 09 Jul 2014 15:02:07 -0400 Message-id: <9D28D2D0-3154-4D48-8E17-68E4344B7E00@apple.com> References: <9F9B2F65-031C-43A1-84F3-8A3B0CC24E0C@apple.com> <0DCD8299-B5AE-4609-BD01-2D3F03EBF872@gmail.com> <7957705E-E585-4A10-9876-34F10F9FAB6E@apple.com> <996D8E94-68CC-42C7-A0A6-617D3C36DEDF@apple.com> <97F4552B-DBE5-48FE-888F-463DF65FF62E@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.1878.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgkeLIzCtJLcpLzFFi42IRnG5nrLt14t5ggxlneCw+7J/D5MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujE/PT7MW3K2s2LB0BlsD48G8LkYODgkBE4ldB9K7GDmBTDGJ C/fWs3UxcnEICcxiklhy+wsjSIJXQFDix+R7LHCJ97/uMUN0mEh0tzcyQyQmM0lc/nqVHa5q 768HYO3CAqESK+7vYAVJMAtMYZSYufopWIJNQE3i96Q+VhCbU8BOovHGGWaQm1gEVCX+tHGB hJkFfCV+Xr7MAnGGjcSiqzuh7tvLJLHv8FKwXhEBFYlvV68zQpwkL/Hhw3F2CHsfm8Tk91wT GIVnIXljFrI7ZoEtSZI4+2ARE4StLbFs4WtmCNtA4mnnK1ZMcX2JN+/mQNWbSjx5u50NwraW +DnnEdRMRYkp3Q/ZFzByrWIUyk3MzNHNzDPTSywoyEnVS87P3cQIiTrRHYxnVlkdYhTgYFTi 4dXo2hssxJpYVlyZe4hRmoNFSZy3vwIoJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgfHKPP/o xdy1t4UZrzM9dp1X8GTi+smr2dOZ3oe9yFdYri165G2+l9yZY+3Vi+5e5F8i+SxqzdSPy09H O6g9+bZJX6WzbjXPl+mzy6ID5X8d6f/GtDan2vMMfyKT9o4bt91t9N/Y2b3gVn3UdeXhtZQD CxjeOElUCd7/6ryfv3zOfrZlbb15ge5KLMUZiYZazEXFiQAkNL8WmwIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUi2FCsobt54t5gg4Yr6hYf9s9hcmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqfnp1kL7lZWbFg6g62B8WBeFyMnh4SAiUR3eyMzhC0mceHe erYuRi4OIYHJTBL73v5khHBmMUns/fWAEaRKWCBUYsX9HawgNq+AgcSrn4+ZQYqYBaYwSsxc /RSsiE1ATeL3pD6wIk4BO4nGG2eAijg4WARUJf60cYGEmQV8JX5evswCMcdGYtHVnVCb9wJt PrwUrFdEQEXi29XrjBDnyUt8+HCcfQIj/ywku2ch2z0LbHCSxNkHi5ggbG2JZQtfM0PYBhJP O1+xYorrS7x5Nweq3lTiydvtbBC2tcTPOY+gZipKTOl+yL6AkWsVo0BRak5ipYVeYkFBTqpe cn7uJkZwPBSm7WBsWm51iFGAg1GJh1eja2+wEGtiWXFl7iFGFaARjzasvsAoxZKXn5eqJMJ7 qwQozZuSWFmVWpQfX1Sak1p8iFGag0VJnPfz8d3BQgLpiSWp2ampBalFMFkmDk6pBsa1T/9X Osa3BJ6ZcP7JxZ0vWsNrfj5WOGp7Sog7TH73JJ7QTK3fHWd6Zsutbld5/rBtfv7SXC/1lXyX lGteRkSt+qVopsxW6r78/7qHNWyblHps+HfMsX62VLSg7mxbP0/YcpGp7/IrOVp/lrhJ5uz7 E7NEwN2pLGV227Q9MXWLeGqlgiX5o5VYijMSDbWYi4oTAaBesE2PAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/0VJrl0pDjN2q3Sql-xVHkW68Vd0 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Proposal: username parameter for HTTP Basic authentication X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 19:02:16 -0000 --Apple-Mail=_EF91DACA-E4D0-4C25-832A-CD6526889082 Content-Type: multipart/alternative; boundary="Apple-Mail=_C8F18F3D-D2E7-4740-AD51-242F3110B6B5" --Apple-Mail=_C8F18F3D-D2E7-4740-AD51-242F3110B6B5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Phil, On Jul 9, 2014, at 12:00 PM, Phil Hunt wrote: >>> ... >>> Certainly nice from a device ui perspective. But also screams attack = me using this account cause I'm a router/printer etc.=20 >>=20 >> The Server header in the HTTP response is enough for that. And nmap = and other tools are pretty good at identifying embedded devices on your = network already, so I don't think adding this one parameter will make it = more likely that the device will be attacked=85 > [PH}Maybe, but randomize the userid helps doesn=92t it? Possibly, but if the other headers provide enough information to = identify the device it still really depends on the strength of the = password. The key today is to have a (good) random initial password that is hard = to brute-force. That isn't too hard to incorporate into manufacturing, = and more devices are doing this now... >>> What about a username printed on the device? At least the UI problem = gets easier and the username is obtained "out-of-band".=20 >>=20 >> I don't know about you, but my Wi-Fi access points are in = out-of-the-way locations, and such stickers/labels are usually on the = back side or bottom of the unit - not exactly convenient (particularly = for a printer...) and usually in the dark so it is impossible to read=85 > [PH] True. But when you first install it, it is visible. I think this = speaks to a need for identity memory in the home domain. How do clients = remember what identities to use with specific devices, etc. Should there = be a repository of identities in the router, in the cloud? Password = based auth seems like an anti-pattern even here. May be a token based = system... See ACE comment below... There are a lot of tricks you can play to authenticate endpoints (chips = of various kinds, etc.) to show you are an authorized endpoint, but they = doesn't authorize the *user*. That's why ACE is looking at 3-party auth = like OAuth... > ... > A token based architecture might be the path to simplicity here. If = ACE deals with the IoT registration and discovery issue, then very = likely it would work well for home =93network=94 domains. =20 Agreed, but I think that is at least a couple years away from being put = into products, and longer until we can rely on it exclusively... _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Apple-Mail=_C8F18F3D-D2E7-4740-AD51-242F3110B6B5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Phil,

On Jul 9, 2014, at 12:00 PM, = Phil Hunt <phil.hunt@oracle.com> = wrote:
...
Certainly nice from a device ui = perspective. But also screams attack me using this account cause I'm a = router/printer etc. 

The Server = header in the HTTP response is enough for that.  And nmap and other = tools are pretty good at identifying embedded devices on your network = already, so I don't think adding this one parameter will make it more = likely that the device will be = attacked=85
[PH}Maybe, but randomize the = userid helps doesn=92t = it?

Possibly, but if the = other headers provide enough information to identify the device it still = really depends on the strength of the = password.

The key today is to have a (good) = random initial password that is hard to brute-force.  That isn't = too hard to incorporate into manufacturing, and more devices are doing = this now...

What about a username printed on the = device? At least the UI problem gets easier and the username is obtained = "out-of-band". 

I don't know about = you, but my Wi-Fi access points are in out-of-the-way locations, and = such stickers/labels are usually on the back side or bottom of the unit = - not exactly convenient (particularly for a printer...) and usually in = the dark so it is impossible to read=85
[PH] True. But = when you first install it, it is visible. I think this speaks to a need = for identity memory in the home domain. How do clients remember what = identities to use with specific devices, etc. Should there be a = repository of identities in the router, in the cloud? Password based = auth seems like an anti-pattern even here. May be a token based = system...  See ACE comment = below...

There are a lot = of tricks you can play to authenticate endpoints (chips of various = kinds, etc.) to show you are an authorized endpoint, but they doesn't = authorize the *user*.  That's why ACE is looking at 3-party auth = like OAuth...

...
A token based = architecture might be the path to simplicity here. If ACE deals with the = IoT registration and discovery issue, then very likely it would work = well for home =93network=94 domains. =  

Agreed, but I think that = is at least a couple years away from being put into products, and longer = until we can rely on it exclusively...

_________________________________________________________
Michael = Sweet, Senior Printing System Engineer, PWG = Chair

= --Apple-Mail=_C8F18F3D-D2E7-4740-AD51-242F3110B6B5-- --Apple-Mail=_EF91DACA-E4D0-4C25-832A-CD6526889082 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPJTCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBSIwggQKoAMC AQICEQDlB7dXxclLEedquPvGX8CGMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBMB4XDTEzMTIxNzAwMDAwMFoXDTE0MTIxNzIzNTk1OVowITEfMB0GCSqG SIb3DQEJARYQbXN3ZWV0QGFwcGxlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ANdvQYZRCVzc0wIYvIOn/0Pv7zUwuIvbAfM/W3FyemqZx3fdKxX4WxN2x5NC3hhBHGrUWirJH7rl 6It12bGQ61uHAK5jsJikV5k+mOYjZaKNIKxj0uYIk3MKQmsmM8t3nddq5mp2mxwV/U7AFPTz1fgh dkqTb/NkHY5eA8KqksaeqwfMgoaiGVeCUhptWnXosca8PAkb+i9u5rEok5zgY+QP0IuWLJENfA4q dEMsH+OAwMGOv9fNCgcdapFnjeSYaj70m6qUiq446+8a2rhUsEUKQayOMgjnm2bgUuNx7pOvs/Jg zIlZoTz/llmE1HWREGzSjRnLWwQ98fspfeZWA+8CAwEAAaOCAeAwggHcMB8GA1UdIwQYMBaAFHoT TgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTtKBJoG9kxZisTqJg4+wr12l4stjAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIw EQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUH AgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6 Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1h aWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9j YS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggr BgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMBsGA1UdEQQUMBKBEG1zd2VldEBhcHBs ZS5jb20wDQYJKoZIhvcNAQEFBQADggEBABg5KLQK5u9gGI75u+vYH/i6uMDKlpTILO/r/FpN2ibq pwAB2ln9oKvPIA1/r3o+DBC87TqnlJAiPW4ADFHpRmqlprb0Tu9p98nP/wl5tBZjEP8dY4iH0TB3 B2r9JHwRwwJQ20CqJpuCn9dmvL215sZSqvJfluVlIcAQCLxp3ZKMIC2pNKitswdjjHduaKuj2TMe xrzMtrRGRtFF9pcMcnsqE2QtJUqXPV7/M4WT2yRUmI4ThPt9O9fmPH2ku52hdb6t4qXvwdQSkDHt xo3J/Vc/jDR2/feedDhQmG0V9j6tHsuG6bVVhcGiWnSmSoPfg13FlQwlxZTyFtiMZ2jILyoxggOu MIIDqgIBATCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAOUHt1fFyUsR 52q4+8ZfwIYwCQYFKw4DAhoFAKCCAdkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTQwNzA5MTkwMjA3WjAjBgkqhkiG9w0BCQQxFgQURjff/DrlzS6MQd6DR7VVAZIb odYwgboGCSsGAQQBgjcQBDGBrDCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx OTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIRAOUHt1fFyUsR52q4+8ZfwIYwgbwGCyqGSIb3DQEJEAILMYGsoIGpMIGTMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgU2VjdXJlIEVtYWlsIENBAhEA5Qe3V8XJSxHnarj7xl/AhjANBgkqhkiG9w0BAQEFAASC AQBVmqK3GHAyT8XWUsK8Qri/yngGVjTpNGs4WiB2EdYAZsxrx4sEE5fAaBXeSbNDpAfPYMxr9sNd J/RZ/fnTvuP0O57fOrurI731w4SkNqWc6s4IskoSxunrqlz1narjGnIpSggl+m6INB3MQYC3yENr Ki2Ck2RiIXq7cU4xcNOYXYjDIloJJ02vDIXRzjo+O2GuTsTgCFz5QasZFVUsrOGKLCAtVvJjfA3w R/JeszLOkVCylmdu0jJqWjQVvHtlEYiwaUfRUMaYIHVwwk688W6xDow0SbO2S2tuluKVT9PcVKJR 8t5FTlG/oXCquNC0cSlZeUDP1mNBe1BovhGzwT80AAAAAAAA --Apple-Mail=_EF91DACA-E4D0-4C25-832A-CD6526889082-- From nobody Tue Jul 15 04:11:21 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 149F91B2836 for ; Tue, 15 Jul 2014 04:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uyt8VC4YYuPI for ; Tue, 15 Jul 2014 04:11:18 -0700 (PDT) Received: from waldorf.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id 716161B27D0 for ; Tue, 15 Jul 2014 04:11:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1405422677; d=isode.com; s=selector; i=@isode.com; bh=SgqcFvxb+kzE7hs1kl3ZVLIHY9YtaAjOH1zxUgYNxwg=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=DXsMNRSpxYum9CG0HzXAjMIIO2Qp/HTFhpaM+3NCbRhVCKz3k9JNpMaA7bJ2RASuuB79kY qD/B8PH/r0QpSxmwQWBIjFcMe9tC6tdTaZi735xkP9Hy/CB7P51eec4IeRSq6mCCD9+3vj FB+CcpxrISEJhSqWjkKlh59PtI9Vo0A=; Received: from [172.20.1.47] ((unknown) [217.34.220.158]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 15 Jul 2014 12:11:17 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <53C50C56.6090207@isode.com> Date: Tue, 15 Jul 2014 12:11:18 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 To: Yoav Nir , Michael Sweet References: <20140704163122.16197.49918.idtracker@ietfa.amsl.com> <32E94943-CE0C-4D93-B1C3-868597606950@apple.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-transfer-encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/YjOegQuf-69fYn_BeOyYd4my4e4 Cc: http-auth@ietf.org Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-scram-auth-03.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 11:11:20 -0000 On 07/07/2014 16:45, Yoav Nir wrote: > On Jul 7, 2014, at 5:15 PM, Michael Sweet wrote: > >> Quick comments: >> >> - Isn't SHA-1 broken? > Define =93broken=94. > > There is a break of collision resistance of SHA-1. That has been known for= over 5 years now, but for some reason, I don=92t believe anyone=92s publish= ed a pair of colliding buffers. I guess once the theoretical proof was there= , the effort of actually creating colliding buffers wasn=92t worth it. > > Anyway, SCRAM-Auth doesn=92t use straight SHA-1, but HMAC-SHA-1. AFAIK thi= s is still considered safe. > >> - Saying that the username and password MUST be UTF-8 is not sufficient, = and I don't think you want to require that the client and server support and= try all normalization forms (which the text on page 6 would seem to indicat= e) >> - I'm confused by what section 4 (SCRAM Mechanism Names) and section 8 (I= ANA Considerations) are saying. Section 4 seems to indicate you are registe= ring a family of auth schemes starting with SCRAM-, but section 8 says each = one has to be registered and defined separately. If the latter, I would pre= fer to see a non-broken hash function be defined first and made mandatory. > SHA2-256 is our usual go-to algorithm these days, and HMAC-SHA2-256 is wid= ely implemented. But it=92s not like HMAC-SHA1 is considered broken. Agreed. SHA1 matches registered use in the SASL framework, but I don't mind=20 making HMAC-SHA2-256 the default for HttpAuth. > > Yoav > (with no hats) From nobody Fri Jul 18 01:10:01 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A26C1A016A for ; Fri, 18 Jul 2014 01:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.679 X-Spam-Level: X-Spam-Status: No, score=-3.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTnFFpd1NIBP for ; Fri, 18 Jul 2014 01:09:56 -0700 (PDT) Received: from na3sys010aog112.obsmtp.com (na3sys010aog112.obsmtp.com [74.125.245.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13B061A011F for ; Fri, 18 Jul 2014 01:09:56 -0700 (PDT) Received: from mail-vc0-f178.google.com ([209.85.220.178]) (using TLSv1) by na3sys010aob112.postini.com ([74.125.244.12]) with SMTP ID DSNKU8jWU27BNsE8YECXm+q+IzTP5SBpWmqO@postini.com; Fri, 18 Jul 2014 01:09:56 PDT Received: by mail-vc0-f178.google.com with SMTP id la4so6656392vcb.37 for ; Fri, 18 Jul 2014 01:09:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=UXY30sbiE0QwihGnneFOyDH+s99B4Ddx4GSjsJ4mfZw=; b=t8nkyU3cqGLq5LZCg7bZ8lxwCvkDsF4gSruXvR1199LvesGeeD71x6iUNB7KPU78TD K24E7xektYi2RcAr0O5pu97AjAEJp75sfq/UdWhVo+N94n49Jcsf+o8FpW9zx6gFcpSq R9PAffQV4TYMXl0wYLByOlCkt6cw+BZhhIAJo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=UXY30sbiE0QwihGnneFOyDH+s99B4Ddx4GSjsJ4mfZw=; b=lRw11JeUaQlJwKHxkNFoG/szQIevhv4DGl3kCu0GFg50UaAXgFkC8rixiTiOUfnO4o eGTwt3B5WCCGQ+LOi5KnEt9eLsgRD+usvq9ywzWFGHgbBVal5nJ245mw1BErRJ7O9XG9 oUnFlyrxV9whHcGgj4uFUxiVTuSdzW3nA8JvZ5ymteOpNrnDG9tgV4cASdRD7SoAttjY ZO2Dzc9oPKWS47G2vqGip6kEl3KAqSL+LE30+uNdWDEpHf7HS6HUInCHLh//it0zg1Hd 1AkTR2Z+eVOZrJZNI58OpK2gxlPJK+7vwGB0u3SMwi1pOnZOI3FuI2PWQggQ8H9a07On VluA== X-Gm-Message-State: ALoCoQmNZwB358DicfeeZccRTeBwrZg5VRuhBVRc7UHHcLgj4q2dUC2a0hOLppVEjKbKRHntDQpPVxg9KbyUSrPueUNKww7z6GKB0w3rQELulKFtvZLPi8nSlNcjz0zUKWePAwmxjrHL X-Received: by 10.52.178.66 with SMTP id cw2mr733532vdc.93.1405670994928; Fri, 18 Jul 2014 01:09:54 -0700 (PDT) X-Received: by 10.52.178.66 with SMTP id cw2mr733526vdc.93.1405670994861; Fri, 18 Jul 2014 01:09:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.154.198 with HTTP; Fri, 18 Jul 2014 01:09:34 -0700 (PDT) In-Reply-To: <20140705124400.GA3684@LK-Perkele-VII> References: <20140704220217.30291.17196.idtracker@ietfa.amsl.com> <20140705124400.GA3684@LK-Perkele-VII> From: Yutaka OIWA Date: Fri, 18 Jul 2014 17:09:34 +0900 Message-ID: To: Ilari Liusvaara Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/Z07T98LMSsc5RJt7g2Gj4TfrnmM Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-mutual-algo-00.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 08:09:58 -0000 Dear Ilari, Thank you very much for valuable comments. We'd asked our cryptographer colleagues' assistance for answering, and please forgive us that we needed some time to prepare these answers. BTW, 2014-07-05 21:44 GMT+09:00 Ilari Liusvaara : > On Fri, Jul 04, 2014 at 03:02:17PM -0700, internet-drafts@ietf.org wrote: >> >> Filename : draft-ietf-httpauth-mutual-algo-00.txt > > Section 2.3: > >> where S_c1 is a random number within range [1, r-1]. The value of >> K_c1 MUST represent a valid curve point, and K_c1' SHALL NOT be 0_E. >> The server MUST check this condition upon reception. > > How this generalizes to non-cofactor-1 curves (those can be quite a bit > faster than cofactor-1 ones)? > > Looking at the discrete-group algorithm, it generalizes as "valid point > with large prime dividing order". > > So would: > > The value of K_c1 MUST represent a valid curve point, and [h]*K_c1' > SHALL NOT be 0_E. The server MUST check this condition upon reception. > > Work? > (0_E is the identity point, h is the curve cofactor.) > >> where S_s1 is a random number within range [1, r-1]. The value of It seems to work. We need to modify some other parts of documents (e.g. introducing the parameter h). Original ISO specification also has a consideration for non-cofactor-1 curves in the exactly same way. I'd like to incorporate it in the next revision. >> K_s1 MUST represent a valid curve point and satisfy [4] * P'(K_s1) <> >> 0_E. If this condition is not satisfied, the server MUST retry using >> another value for S_s1. The client MUST check this condition upon >> reception. > > Same here. > > Also where does that multiplier 4 in check come from? Attempt at > supporing h>1 curves (except that some stuff in use has h=8)? > > Should it be [h]*P'(K_s1) <> 0_E? It is copied from the original ISO specification, and it seems to be corresponding to the DL-case checking "[t]he value of K_s1 MUST satisfy 1 < K_s1 < q-1", that is to check K_s1 is not equivalent to either 1 or -1. For this purpose, it should at least be [2] * P'(K_s1) <> 0_E. I don't have a strict idea on why this is 4 instead of 2, though. Does anyone have idea on this? (Our colleague currently considers this 4 as not related to the cofactor setting). > Section 2.2&2.3: > > 2.2 has: >> The value of K_s1 MUST satisfy 1 < K_s1 < q-1. If this condition >> is not held, the server MUST retry using another value for S_s1. > > And 2.3: >> The value of K_s1 MUST represent a valid curve point and satisfy >> [4] * P'(K_s1) <> 0_E. If this condition is not satisfied, the >> server MUST retry using another value for S_s1. > > If K_c1 has certain relationship (extremely unlikely) with > J(pi), that will fail over and over again (no S_s1 works). > > Values of S_s1 that don't work are AFAICT very rare anyway (making > failures be dominated by all sorts of calculation errors in K_s1). I'd like to answer this in a separate mail. -- Yutaka OIWA, Ph.D. Leader, System Life-cycle 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 nobody Fri Jul 18 01:31:33 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A4FD1A00B9 for ; Fri, 18 Jul 2014 01:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.679 X-Spam-Level: X-Spam-Status: No, score=-3.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3cnGv9uZl6BU for ; Fri, 18 Jul 2014 01:31:30 -0700 (PDT) Received: from na3sys010aog101.obsmtp.com (na3sys010aog101.obsmtp.com [74.125.245.70]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D8851A00B5 for ; Fri, 18 Jul 2014 01:31:30 -0700 (PDT) Received: from mail-vc0-f170.google.com ([209.85.220.170]) (using TLSv1) by na3sys010aob101.postini.com ([74.125.244.12]) with SMTP ID DSNKU8jbYTlaPBW3Sgf1YXPktAqWrG5+kQNn@postini.com; Fri, 18 Jul 2014 01:31:30 PDT Received: by mail-vc0-f170.google.com with SMTP id lf12so6786103vcb.15 for ; Fri, 18 Jul 2014 01:31:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=VEeh5MKxNq69M2wLShRheCltIqfmnkhpE0OZoVIgSJQ=; b=EgRKrwG/sOAkb81JX241YOPQGJsgp89HRyY3SQc4StZnJuU+sFVWCNtq4qJF6bUaAW n8Do8NZI2+ExwjSB/b/AarfGvrGnIhlpDnMhj6WhOgwdqz+3NfdIz8LoTxjQ2wpeqBM8 nStSOCg2YmSuIlsgS9NzdRyC30R/W6RzvH5Cw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=VEeh5MKxNq69M2wLShRheCltIqfmnkhpE0OZoVIgSJQ=; b=Yx5zScDqSbQIzJgjK7VdfJ6GMHgmoguz0qUpotPtfOdVSjw0ejM7bGKnfqsgGErV1s dUX6yHmYFPovw5ZASpyU08vq2eyhJpBx6E9VE6wrsNlzBb1083HQRgJ9+dmgeCqX8CW6 XNoz0zyaMr9Q1RwWbDVzaF5gLa8G0XziTFnQdooA4KC6HoibKo+wvoW5ZV3wYO8wJcJK eig1YxuBfiTmMhvesbhqF/eP/aYSLPFl30xV14n4+HG4VysKPgZtLaMdABVV7uFLIUib hVRj9vR09H/m182HjxibFauTlA1GweJHdTwVIwj+ySCBzA9MZn37eCkCzIK9zlQhLmvH 0VXw== X-Gm-Message-State: ALoCoQn2m4LeZasQ6XAal8ZdKBQ1z/Z2g/Qw84AdiHL14Yt+ALDu41Ylo0Nr2p9wZUiUHYrGCIT8/av+j2H8SAclJ+UWWU2QB0T0Of2ZbUIwDn7Dl2F8GupMr55TYOCxjPAp4cPe/xO2 X-Received: by 10.52.157.41 with SMTP id wj9mr2605404vdb.1.1405672289353; Fri, 18 Jul 2014 01:31:29 -0700 (PDT) X-Received: by 10.52.157.41 with SMTP id wj9mr2605391vdb.1.1405672289239; Fri, 18 Jul 2014 01:31:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.154.198 with HTTP; Fri, 18 Jul 2014 01:31:09 -0700 (PDT) In-Reply-To: <20140705124400.GA3684@LK-Perkele-VII> References: <20140704220217.30291.17196.idtracker@ietfa.amsl.com> <20140705124400.GA3684@LK-Perkele-VII> From: Yutaka OIWA Date: Fri, 18 Jul 2014 17:31:09 +0900 Message-ID: To: Ilari Liusvaara Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/OSmGRUGkp5xReg1C59l3WvtLFgc Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-mutual-algo-00.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 08:31:32 -0000 Dear Ilari, 2014-07-05 21:44 GMT+09:00 Ilari Liusvaara : > Section 2.2&2.3: > > 2.2 has: >> The value of K_s1 MUST satisfy 1 < K_s1 < q-1. If this condition >> is not held, the server MUST retry using another value for S_s1. > > And 2.3: >> The value of K_s1 MUST represent a valid curve point and satisfy >> [4] * P'(K_s1) <> 0_E. If this condition is not satisfied, the >> server MUST retry using another value for S_s1. > > If K_c1 has certain relationship (extremely unlikely) with > J(pi), that will fail over and over again (no S_s1 works). > > Values of S_s1 that don't work are AFAICT very rare anyway (making > failures be dominated by all sorts of calculation errors in K_s1). I've checked and analyzed our current draft and original ISO specification. Current our specification is exactly corresponding to the original spec in this aspect. However, as you have mentioned, If (J(pi) + [t_1] * K_c1') = 0_E or similar, the K_s1 will always be 0_E, regardless of the choice of S_s1. The value t_1 is also derived from K_c1 using a hash function. If this happens, it causes a denial-of-service condition on server-side. It depends on how J(pi) is stored in the server-side. If J(pi) is computed on server-side from the plain-text password pi, finding S_c1 which causes this problem is pretty hard. It can be done off-line by clients, but it requires brute-force search on the whole candidates of S_c1. However, if J(pi) is provided from client-side, it is easy to cause the problematic condition, by * choose an arbitrary S_c1 randomly, * compute J as -([t_1] * K_c1'), and send it to server as J(pi), * talk to server with per-determined S_c1. The similar problem also exists in DL setting. Verifying whether J is valid (correctly derived from some plain-text password pi) is impossible. Could someone double-check my observations above? The fix is quite easy in one of two ways: * check that [4] * (J(pi) + [t_1] * K_c1') <> 0_E upon reception of K_c1, or * limit number of retries of S_s1 selection (to some small numbers). In either ways, if the client is not malicious, possibility of invoking this condition accidentally is cryptographically negligible. I'll incorporate one of these additional checks into the next revision. -- Yutaka OIWA, Ph.D. Leader, System Life-cycle 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 nobody Fri Jul 18 04:20:41 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35E5B1A0AA9 for ; Fri, 18 Jul 2014 04:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4p9Gseqzaor for ; Fri, 18 Jul 2014 04:20:35 -0700 (PDT) Received: from emh02.mail.saunalahti.fi (emh02.mail.saunalahti.fi [62.142.5.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 436141A0A6D for ; Fri, 18 Jul 2014 04:20:34 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh02.mail.saunalahti.fi (Postfix) with ESMTP id 177A38183D; Fri, 18 Jul 2014 14:20:27 +0300 (EEST) Date: Fri, 18 Jul 2014 14:20:27 +0300 From: Ilari Liusvaara To: Yutaka OIWA Message-ID: <20140718112027.GA9740@LK-Perkele-VII> References: <20140704220217.30291.17196.idtracker@ietfa.amsl.com> <20140705124400.GA3684@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/MA9KBAN3Q3bczsfWR7sJlXNXl5o Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-mutual-algo-00.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 11:20:38 -0000 On Fri, Jul 18, 2014 at 05:09:34PM +0900, Yutaka OIWA wrote: Looks like there are unstated assumptions: - q for discrete groups has to be safe prime. - r for elliptic curve has to be prime (hr = #E). All the groups defined in -00 do satisfy these conditions. > It is copied from the original ISO specification, and > it seems to be corresponding to the DL-case checking > "[t]he value of K_s1 MUST satisfy 1 < K_s1 < q-1", > that is to check K_s1 is not equivalent to either 1 or -1. > For this purpose, it should at least be [2] * P'(K_s1) <> 0_E. > I don't have a strict idea on why this is 4 instead of 2, though. > Does anyone have idea on this? > (Our colleague currently considers this 4 as not related to > the cofactor setting). It seems to me that if h=1, then [4] * X = 0_E iff X = 0_E. And if h=2, then [4] * X = 0_E iff [2] * X = 0_E. Regarding the 4, maybe its origin can be traced to some standards specifying h to be 1, 2 or 4. > However, if J(pi) is provided from client-side, it is easy to cause > the problematic condition, by > * choose an arbitrary S_c1 randomly, > * compute J as -([t_1] * K_c1'), and send it to server as J(pi), > * talk to server with per-determined S_c1. > The similar problem also exists in DL setting. Yeah, forgot about that. > Verifying whether J is valid (correctly derived from some > plain-text password pi) is impossible. Doing ZKP for discrete logarithm is presumably not practical, due to extra values incurred. > The fix is quite easy in one of two ways: > * check that [4] * (J(pi) + [t_1] * K_c1') <> 0_E upon > reception of K_c1, or > * limit number of retries of S_s1 selection (to some small numbers). > In either ways, if the client is not malicious, possibility of > invoking this condition accidentally is cryptographically negligible. > I'll incorporate one of these additional checks into the next revision. Actually, given that r is prime, it seems to me that: [h] * (J(pi) + [t_1] * K_c1') <> 0_E <=> [h] * [S_s1] * (J(pi) + [t_1] * K_c1') <> 0_E (scalar multiplication commutes and Z_r is a field). So one would never need to retry. -Ilari From nobody Fri Jul 18 09:43:59 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A71B1ABB1D for ; Fri, 18 Jul 2014 09:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.979 X-Spam-Level: X-Spam-Status: No, score=-0.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MISSING_HEADERS=1.021, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTHzZO1hGkKT for ; Fri, 18 Jul 2014 09:43:57 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AC771A0301 for ; Fri, 18 Jul 2014 09:43:56 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id rl12so4755465iec.15 for ; Fri, 18 Jul 2014 09:43:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=s4rr72BBb6wNTnVlrYug6dJbqZAAe9umeZisiFwuy3s=; b=H+BVjzTxbLPXn9x3moO4gJdx5+k3VqvDRm18fst4gGA8FVhE6uwUQD90SWnv0Nkja4 K7/MZEBUu6j9NAeoAKpIMuPfXZoSA5DMUBVqFfpAQEN9Bk+heJH1Fr8ztoa+/FijA05g FTanYngzeTw7PgJ0vakxM3o1pgahfLQJN8IH1y5Ev47jNJcobcnCVmp/yp6KWQ5eXE3d M5RvkrD0I4gYtGPQfEDxEYgu/QcAv5wgQ7hXqoyMxMPazqGB+TaOf+0nwBKCxmSwE2VS boF/jOaVKmLAMLNjwqTOtWnRIRh6Iwmq1fkA/bBl9iogIBOVUSwnq/XYIWTOZMRbWoww d0nQ== X-Received: by 10.50.43.234 with SMTP id z10mr41198612igl.28.1405701836247; Fri, 18 Jul 2014 09:43:56 -0700 (PDT) Received: from [192.168.1.103] (CPE0013100e2c51-CM001cea35caa6.cpe.net.cable.rogers.com. [99.231.3.110]) by mx.google.com with ESMTPSA id v8sm7332453igh.19.2014.07.18.09.43.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Jul 2014 09:43:55 -0700 (PDT) Message-ID: <53C94EC6.3000103@gmail.com> Date: Fri, 18 Jul 2014 12:43:50 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 CC: http-auth@ietf.org References: <20140704220217.30291.17196.idtracker@ietfa.amsl.com> In-Reply-To: <20140704220217.30291.17196.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/TcXCMKVewk4MEt3MyK7h1TxljVY Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-mutual-algo-00.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 16:43:58 -0000 Dear authors: The algorithms in the draft seem to be based on the Augmented PAKE protocol, but differ in various aspects (e.g., hash function definition, details of cryptographic operation). Thus, it is not a priori clear whether the results in the AugPAKE paper apply here. If there is a technical write-up that analyzes the cryptographic properties of this (specific) protocol in detail that would be great. Best regards, Rene On 7/4/2014 6:02 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 : Mutual Authentication Protocol for HTTP: KAM3-based Cryptographic Algorithms > Authors : Yutaka Oiwa > Hajime Watanabe > Hiromitsu Takagi > Kaoru Maeda > Tatsuya Hayashi > Yuichi Ioku > Filename : draft-ietf-httpauth-mutual-algo-00.txt > Pages : 15 > Date : 2014-07-04 > > Abstract: > This document specifies some cryptographic algorithms which will be > used for the Mutual user authentication method for the Hyper-text > Transport Protocol (HTTP). > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-httpauth-mutual-algo/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-httpauth-mutual-algo-00 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 From nobody Fri Jul 18 18:37:46 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B839A1A01AF for ; Fri, 18 Jul 2014 18:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-nv1Dx9ExxC for ; Fri, 18 Jul 2014 18:37:42 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BADF41A0316 for ; Fri, 18 Jul 2014 18:37:41 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id s7so3327426lbd.8 for ; Fri, 18 Jul 2014 18:37:39 -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 :content-type; bh=148OrslD2SsBALSejy//J0NkNfZ3Hbe7lMMyGS8qizE=; b=OGh1rxZtiY5ms+3j53PTKa9OupJgOsQDJmMT6S/q49uyGuRfyoacndzxS5qhO6kNdZ xYERX85jFDwQV2xalviFcf8IwZJFPs0TgtGHQEacR7ODZSwuGgzg4l5m8wz6i4H4I/gF 7hZCYZtz3SpJU13TMqDwDfx95PqtT7ceKx1VKZITL+F3Ht4dpChce3RvXAcXOBylT6Cg gL/xWsbfk6yvhWO6POuKAby4R7VaRBhPuAyd0W/KepbvuhIQnbhoyCIpnsFMScoHfAfj 1aEXUOFEVK8vvn0Vm10JVPu+do3uItV8/Cm01vUU/N1E9K5DLMt2fwUiYu0PSXJqlkRn zy+g== MIME-Version: 1.0 X-Received: by 10.112.235.72 with SMTP id uk8mr8850872lbc.80.1405733859916; Fri, 18 Jul 2014 18:37:39 -0700 (PDT) Received: by 10.112.207.73 with HTTP; Fri, 18 Jul 2014 18:37:39 -0700 (PDT) In-Reply-To: References: Date: Fri, 18 Jul 2014 21:37:39 -0400 Message-ID: From: Kathleen Moriarty To: http-auth@ietf.org Content-Type: multipart/alternative; boundary=001a11c3dbc25e823704fe81eb5f Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/M8qPfLoB5kOTjTrQoVYjqdmVH9M Subject: [http-auth] Fwd: Privacy considerations X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jul 2014 01:37:43 -0000 --001a11c3dbc25e823704fe81eb5f Content-Type: text/plain; charset=UTF-8 Hello, As an FYI, If drafts raise privacy concerns, we need to work on including those in the Security considerations section. It will get added before publication, so we should address this concern in drafts within each WG (if relevant). If drafts have a lot of ground to cover, it may require it's own section. I read through https://datatracker.ietf.org/doc/draft-ietf-httpauth-basicauth-update and think you can add a few sentences to address this as it fits in with the existing discussion in that section. Here is some proposed text with examples, please feel free to come up with better examples or a variant on the text. I just care that the points are addressed. Security Considerations, suggest adding the following at the end of paragraph 5: This raises both security and privacy concerns [RFC6973]. If the same username and password combination is in use to access email accounts or an account on a health portal, personal information could be exposed. As for the digest draft, that also discourages it's use as not being a secure method of authentication, but does say it's stronger than basic authentication. As a result, similar concerns should be mentioned in terms of privacy in this draft as well. Both drafts already cover the protection of the session in terms of exposing data and the lack of confidentiality protections, so that should cover privacy as well (IMO). If the WG wanted to add text or explicitly use the terms privacy related information or personal information, that would not be a bad idea. In the digest draft, sect 5.2 might be the right place as it already covers confidentiality concerns with the possible exposure of information. Thanks. -- Best regards, Kathleen -- Best regards, Kathleen --001a11c3dbc25e823704fe81eb5f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

As an FYI, If drafts raise privac= y concerns, we need to work on including those in the Security consideratio= ns section. =C2=A0It will get added before publication, so we should addres= s this concern in drafts within each WG (if relevant). =C2=A0If drafts have= a lot of ground to cover, it may require it's own section.

I read through=C2=A0https://da= tatracker.ietf.org/doc/draft-ietf-httpauth-basicauth-update and think y= ou can add a few sentences to address this as it fits in with the existing = discussion in that section.

Here is some proposed text with examples, please feel f= ree to come up with better examples or a variant on the text. =C2=A0I just = care that the points are addressed.

Security Consi= derations, suggest adding the following at the end of paragraph 5:
This raises both security and privacy concerns [RFC6973]. =C2=A0If the= same username and password combination is in use to access email accounts = or an account on a health portal, personal information could be exposed.

As for the digest draft, that also discourages it= 's use as not being a secure method of authentication, but does say it&= #39;s stronger than basic authentication. =C2=A0As a result, similar concer= ns should be mentioned in terms of privacy in this draft as well.

Both drafts already cover the protection of the session= in terms of exposing data and the lack of confidentiality protections, so = that should cover privacy as well (IMO). =C2=A0If the WG wanted to add text= or explicitly use the terms privacy related information or personal inform= ation, that would not be a bad idea. =C2=A0In the digest draft, sect 5.2 mi= ght be the right place as it already covers confidentiality concerns with t= he possible exposure of information.

Thanks.
--

Best regards,
Kathleen=



--

Best regards,
Kathleen
--001a11c3dbc25e823704fe81eb5f-- From nobody Sat Jul 19 18:29:47 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 008C71B2B51 for ; Sat, 19 Jul 2014 18:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cm4wiYucP32u for ; Sat, 19 Jul 2014 18:29:44 -0700 (PDT) Received: from emh07.mail.saunalahti.fi (emh07.mail.saunalahti.fi [62.142.5.117]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B64D1B2B4B for ; Sat, 19 Jul 2014 18:29:42 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id A03233FE4; Sun, 20 Jul 2014 04:29:38 +0300 (EEST) Date: Sun, 20 Jul 2014 04:29:38 +0300 From: Ilari Liusvaara To: Yutaka OIWA Message-ID: <20140720012938.GA28212@LK-Perkele-VII> References: <20140704220217.30291.17196.idtracker@ietfa.amsl.com> <20140705124400.GA3684@LK-Perkele-VII> <20140718112027.GA9740@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20140718112027.GA9740@LK-Perkele-VII> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/Q0IniHvYTWDue1hojrXIc0JBUrE Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-mutual-algo-00.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 01:29:46 -0000 On Fri, Jul 18, 2014 at 02:20:27PM +0300, Ilari Liusvaara wrote: > > Actually, given that r is prime, it seems to me that: > > [h] * (J(pi) + [t_1] * K_c1') <> 0_E > <=> > [h] * [S_s1] * (J(pi) + [t_1] * K_c1') <> 0_E > > (scalar multiplication commutes and Z_r is a field). Seems like following assumptions are sufficient for proving this: A) Base field of E is finite, and B) r=|| is prime, and C) #E <> 0 (mod r^2) In practice, these are always true in ECC. -Ilari From nobody Sat Jul 19 18:42:49 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 978071B2B52 for ; Sat, 19 Jul 2014 18:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.678 X-Spam-Level: X-Spam-Status: No, score=-3.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mi-9J_YCiMmN for ; Sat, 19 Jul 2014 18:42:47 -0700 (PDT) Received: from na3sys010aog106.obsmtp.com (na3sys010aog106.obsmtp.com [74.125.245.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EDBE1A030C for ; Sat, 19 Jul 2014 18:42:47 -0700 (PDT) Received: from mail-vc0-f178.google.com ([209.85.220.178]) (using TLSv1) by na3sys010aob106.postini.com ([74.125.244.12]) with SMTP ID DSNKU8selqWqqgzCusDotbdI0vxt01hO3+4E@postini.com; Sat, 19 Jul 2014 18:42:47 PDT Received: by mail-vc0-f178.google.com with SMTP id la4so10027110vcb.9 for ; Sat, 19 Jul 2014 18:42:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GUM2s08y1Lq9l296qdZuBfiZUr9nHhtGVI7wtFFHnYQ=; b=RjSiWTrqQ9gLvDLoYJ/xXjROEkDKh/Nw0qt1ttnfZmHyLAhbz4uSBptG2fv+x+H2Cu MA1O3LYGcclL9v5xDt1Ko76ouv5v67lvzKkrwVnnuMJQ0kaLth8NyFVFzt7hw7iJuiWN cQaffugmTIshNGxiXdmM+bbTSEo1wt8JCuvrA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=GUM2s08y1Lq9l296qdZuBfiZUr9nHhtGVI7wtFFHnYQ=; b=LE2mroMmGBj8rAhaQ7U1nL3NtGGTjjr7sekmTfOc58l2NSrhpBSAuaRiuMiIRpbEV1 1920zZOL20CMoW+51Sw6YnfsDwg+SmniQ6fYALKnQk3KPLAbHsNWUSQ+s4RI+I/h5iO5 7hp8tTGaEaIgHj5Idnf59ZLnwSmOqEtM0Tw/uxL5w47aR2KinMwK3kaC2AefJy4IDiY3 iN8GAP1wGxlZvxunZs0mFypKCONIbIG97SfIUZ5QUvTnDXeMeBVY9gfM09rJsAYZ69ce rc8tbcnOPQTOoYxP+TGiYl+kS0gMjg//tPd57ehe3jQg/KrO5oN7+BN11IdlNG/OIvUr qK1Q== X-Gm-Message-State: ALoCoQl/JcPLyEMVopYFvCs3sKk0hzpTyrRREGGpJR0zlNVxuTqno05n33+cgpJwexbifwI4odOhtaxeQun6gqoFjmg83WtdB57EZRvm+3EWhOVBjOXelS04LwvbkhnYjL5T5QrK5IP5 X-Received: by 10.52.239.6 with SMTP id vo6mr295712vdc.59.1405820566229; Sat, 19 Jul 2014 18:42:46 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.52.239.6 with SMTP id vo6mr295700vdc.59.1405820566077; Sat, 19 Jul 2014 18:42:46 -0700 (PDT) Received: by 10.58.154.198 with HTTP; Sat, 19 Jul 2014 18:42:45 -0700 (PDT) Received: by 10.58.154.198 with HTTP; Sat, 19 Jul 2014 18:42:45 -0700 (PDT) In-Reply-To: <20140720012938.GA28212@LK-Perkele-VII> References: <20140704220217.30291.17196.idtracker@ietfa.amsl.com> <20140705124400.GA3684@LK-Perkele-VII> <20140718112027.GA9740@LK-Perkele-VII> <20140720012938.GA28212@LK-Perkele-VII> Date: Sun, 20 Jul 2014 10:42:45 +0900 Message-ID: From: Yutaka OIWA To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a1135f47675a2c304fe961be7 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/6flmFNyhRU4gSd3nkOJLX1yY4-E Cc: http-auth@ietf.org Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-mutual-algo-00.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 01:42:48 -0000 --001a1135f47675a2c304fe961be7 Content-Type: text/plain; charset=UTF-8 Hello from Narita, Thank you. I don't know why the original ISO spec says about retry only for this point, and it seems to be good to revise the clause by our own investigation, also considering the possible DoS. Please wait a while for new draft. -- Yutaka OIWA on mobile 2014/07/20 10:29 "Ilari Liusvaara" : > On Fri, Jul 18, 2014 at 02:20:27PM +0300, Ilari Liusvaara wrote: > > > > Actually, given that r is prime, it seems to me that: > > > > [h] * (J(pi) + [t_1] * K_c1') <> 0_E > > <=> > > [h] * [S_s1] * (J(pi) + [t_1] * K_c1') <> 0_E > > > > (scalar multiplication commutes and Z_r is a field). > > Seems like following assumptions are sufficient for proving > this: > > A) Base field of E is finite, and > B) r=|| is prime, and > C) #E <> 0 (mod r^2) > > > In practice, these are always true in ECC. > > > > -Ilari > --001a1135f47675a2c304fe961be7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hello from Narita,

Thank you.=C2=A0 I don't know why the original ISO spec = says about retry only for this point,
and it seems to be good to revise the clause by our own investigation, also= considering the possible DoS.
Please wait a while for new draft.

--
Yutaka OIWA <y.oiwa@aist.go.jp&= gt; on mobile

2014/07/20 10:29 "Ilari Liusvaara" <= ;ilari.liusvaara@elisanet.fi= >:
On Fri, Jul 18, 2014 at 02:20:27PM +0300, Ilari Liusvaara wrote:
>
> Actually, given that r is prime, it seems to me that:
>
> [h] * (J(pi) + [t_1] * K_c1') <> 0_E
> <=3D>
> [h] * [S_s1] * (J(pi) + [t_1] * K_c1') <> 0_E
>
> (scalar multiplication commutes and Z_r is a field).

Seems like following assumptions are sufficient for proving
this:

A) Base field of E is finite, and
B) r=3D|<G>| is prime, and
C) #E <> 0 (mod r^2)


In practice, these are always true in ECC.



-Ilari
--001a1135f47675a2c304fe961be7-- From nobody Sun Jul 20 01:00:55 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 757A71B2B7F for ; Sun, 20 Jul 2014 01:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvZvydBWlK9R for ; Sun, 20 Jul 2014 01:00:52 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 056481B2B7E for ; Sun, 20 Jul 2014 01:00:51 -0700 (PDT) Received: from [192.168.43.245] ([82.113.106.88]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LtUHA-1WRuKK0Mpo-010y00; Sun, 20 Jul 2014 10:00:50 +0200 Message-ID: <53CB7723.5080609@gmx.de> Date: Sun, 20 Jul 2014 10:00:35 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Kathleen Moriarty , http-auth@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:W8WAjs8wGzdBZRCP7nVh/Zr5+oN+0MmtsqTDgYensMYrZ/vDPhl hG5+P2r/17G3fM9+LAZUbGC9k10t0qRS6MmsFa6WCTBmS0MXZ5J0zCMkDpdgJ0yzxpmmlHK QkaV2I4XBljq1zICXKMvT5ttLdkbzfZ+A6XJ1a23+heZeH6gY+s3068uHftPXpwxURCJkwZ M3ZK9gAgNGbrtUHw2dJow== Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/TA8RTZzYtDwO0dATc1mqJkuGAwQ Subject: Re: [http-auth] Fwd: Privacy considerations X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 08:00:53 -0000 On 2014-07-19 03:37, Kathleen Moriarty wrote: > ... > Security Considerations, suggest adding the following at the end of > paragraph 5: > This raises both security and privacy concerns [RFC6973]. If the same > username and password combination is in use to access email accounts or > an account on a health portal, personal information could be exposed. > ... Thanks! -> Best regards, Julian From nobody Sun Jul 20 06:16:05 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57CF71B2C1E for ; Sun, 20 Jul 2014 06:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3F2GK2iSO5ft for ; Sun, 20 Jul 2014 06:15:57 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76A8F1B2C11 for ; Sun, 20 Jul 2014 06:15:57 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id v6so3844097lbi.11 for ; Sun, 20 Jul 2014 06:15:55 -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=NPpj7FlyICey6fFy6Mv8NF81t5OPngsQMBj67CT5H08=; b=V0e+ksxvygOn1Hzw/np5CzYmr+Mdo6IzqXtAzYJYRXMVwkp7O3P7/f0oOVCYI9yY+B Gy6+3YQTkSqRpsdjbJoY5tf4gRLoTeZeG6FT7RJ/KzcIScHW5CFsJcbEoD8ndMBJ1Qet c1NLoXh6y0Ux10P7jPbjYwTbb/+CprCyFq9wdt+OGMuMv7o3q87c7hIG4M6HysOlmrIF qmz5VwbMGoUtWfLdyKVvemflHO5eUi+JNUE6qRryo8zbNs1ZyTuumXkcNp1Qw4LwoZqX 5Pyr3BsD0ScbkVe2aUQqvPuReSNJGrzdTsG6kOUMhZJ++D/G2YTmKz+hjJC5Ace6M9SE oPeg== MIME-Version: 1.0 X-Received: by 10.112.16.230 with SMTP id j6mr2842087lbd.90.1405862155759; Sun, 20 Jul 2014 06:15:55 -0700 (PDT) Received: by 10.112.207.73 with HTTP; Sun, 20 Jul 2014 06:15:55 -0700 (PDT) In-Reply-To: <53CB7723.5080609@gmx.de> References: <53CB7723.5080609@gmx.de> Date: Sun, 20 Jul 2014 09:15:55 -0400 Message-ID: From: Kathleen Moriarty To: Julian Reschke Content-Type: multipart/alternative; boundary=001a11c3c6d2663c5d04fe9fca03 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/0bh64jGMUGF2vzPk9jdRBGBTjTc Cc: http-auth@ietf.org Subject: Re: [http-auth] Fwd: Privacy considerations X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 13:16:03 -0000 --001a11c3c6d2663c5d04fe9fca03 Content-Type: text/plain; charset=UTF-8 Thanks, Julian! Looking at this with fresh eyes, could you adjust the last sentence to make it clear that those are just possible examples and not the full set of possibilities. Perhaps the following: If the same username and password combination is in use to access other accounts, such as an email or health portal account, personal information could be exposed. On Sun, Jul 20, 2014 at 4:00 AM, Julian Reschke wrote: > On 2014-07-19 03:37, Kathleen Moriarty wrote: > >> ... >> >> Security Considerations, suggest adding the following at the end of >> paragraph 5: >> This raises both security and privacy concerns [RFC6973]. If the same >> username and password combination is in use to access email accounts or >> an account on a health portal, personal information could be exposed. >> ... >> > > Thanks! -> > > Best regards, Julian > -- Best regards, Kathleen --001a11c3c6d2663c5d04fe9fca03 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks, Julian!

Looking at this with fr= esh eyes, could you adjust the last sentence to make it clear that those ar= e just possible examples and not the full set of possibilities. =C2=A0Perha= ps the following:

If the same
username and password combi= nation is in use to access other accounts, such as an email or= =C2=A0health portal account, personal information could be exposed.<= br>


O= n Sun, Jul 20, 2014 at 4:00 AM, Julian Reschke <julian.reschke@gmx.de<= /a>> wrote:
On 2014-07-19 03:37, Kathleen Moriarty wrote= :
...

Security Considerations, suggest adding the following at the end of
paragraph 5:
This raises both security and privacy concerns [RFC6973]. =C2=A0If the same=
username and password combination is in use to access email accounts or
an account on a health portal, personal information could be exposed.
...

Thanks! -> <http://trac.tools.ietf.org/wg/httpauth= /trac/changeset/73>

Best regards, Julian



--

Best regards,
Kathleen
--001a11c3c6d2663c5d04fe9fca03-- From nobody Sun Jul 20 17:45:50 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC051B2A70 for ; Sun, 20 Jul 2014 17:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.896 X-Spam-Level: X-Spam-Status: No, score=0.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9bHESjb5Vo9 for ; Sun, 20 Jul 2014 17:45:46 -0700 (PDT) Received: from mail.digitalbazaar.com (unknown [216.252.204.51]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D06FE1B2A64 for ; Sun, 20 Jul 2014 17:45:45 -0700 (PDT) Received: from [192.168.100.5] by mail.digitalbazaar.com with esmtp (Exim 4.72) (envelope-from ) id 1X91jZ-0001bh-0M; Sun, 20 Jul 2014 20:45:43 -0400 Message-ID: <53CC62AF.6040305@digitalbazaar.com> Date: Sun, 20 Jul 2014 20:45:35 -0400 From: Manu Sporny User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Icedove/24.5.0 MIME-Version: 1.0 To: Mark Nottingham References: <536BFA23.9020900@digitalbazaar.com> <44475C73-A79F-4C54-A09D-A9842FD49CA2@mnot.net> In-Reply-To: <44475C73-A79F-4C54-A09D-A9842FD49CA2@mnot.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/E-x_DiAjGL2AGfQek3k5u2Vu-qA Cc: "Julian F. Reschke" , IETF HTTP Auth , Web Payments CG Subject: Re: [http-auth] Review Request for third draft of "Signing HTTP Messages" X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 00:45:47 -0000 On 05/18/2014 08:33 PM, Mark Nottingham wrote: > This is looking pretty good IMO. Hey Mark, sorry for the very delayed response to your comments. My four day jobs got in the way. Responses and fixes below. > * I think you need to strip out all of the motivation text (i.e., > substantial portions of 1.x); it makes claims that are hard to > justify about how this helps with pervasive monitoring, and it also > omits a lot of other potential uses for the spec. Just keep it > simple. Done: https://github.com/web-payments/web-payments.org/commit/406758440f22291f115fc54cd6491572dcf6a393 > * Section 2.1.3 - Is Date the default value if no ‘headers’ is > specified, or is it always in the set of headers? It isn’t clear > from this text. It's the default value if no 'headers' are specified. It is not always in the set of headers. For example, if the developer doesn't include it in the list of headers, it's not automagically added. I've tried to clarify the text: https://github.com/web-payments/web-payments.org/commit/c25f8c5c969f5500c3fd7868d98a5989bde0b1c8 > * Section 2.3. - How is whitespace around field-values handled — is > it included in the value or not? Note that as per > , > it isn’t (but it would be good if you made this explicit, both in > spec and with examples) Whitespace around field values is not included. The spec now refers to the appropriate section in draft-ietf-httpbis-p1-messaging-26: https://github.com/web-payments/web-payments.org/commit/2e00f1a30dc99e80b18deebb30f4d4b03d4b4a75 > * Section 2.3 - Request-line is HTTP/1 specific, and — again — the > HTTP version is a hop-by-hop attribute of the message, so you’re > going to get signature failures through intermediaries. Suggestion: > use HTTP/2’s :method, :authority and :path pseudo-headers. Are you asking me to: 1) Change the name `(request-line)` to something else like `(request-target)`? 2) Specify that the header field value should be constructed by concatenating the lowercased :method, an ASCII space, the :authority, an ASCII space, and :path pseudo-headers? I'm assuming that you think that :scheme shouldn't be included because it'll break when proxied internally between https->http? Speaking about proxies, isn't using :authority going to break the signature from hop-to-hop? Is it worth specifying that servers sitting behind a proxy should use the X-Forwarded-Host or Forwarded-Host headers as a replacement for :authority when recreating the signature? Now I'm wondering if there is an attack that allows an attacker to inject both X-Forwarded-Host and Forwarded-Host that would result in a compromised signature. I made both changes above, let me know if that's not what you wanted. https://github.com/web-payments/web-payments.org/commit/495584b09f88acd439734fcfa9f9826bf40173c3 > * Can trailers be included in a signature? In theory, yes. We've got another spec in the works about how to do this (although it's horribly out of date and we don't know if we're going to finish it any time soon... not much demand for it as far as we can tell): https://web-payments.org/specs/source/http-signature-trailers/ I imagine that if/when we do, we'll require something like this header: Signature: location=trailer and then have the actual signature in the trailers. > * Can a Signature header be included in the message trailers? In theory, yes. We need to spec exactly how this would work. The feature was deemed low-priority and out of scope for the base Signing HTTP Messages spec. > * You talk (often implicitly) about how a signature is created, but > not what constitutes a valid signature. This is going to be > especially important for the authentication scheme. I tried to clarify by adding two sections. The first specifies how a signature is created, and the second specifies how a signature is verified: https://github.com/web-payments/web-payments.org/commit/d535b92c05f676c040c3e4efd417bd2e5b68ef68 ... but don't know if that's what you were looking for. Thanks a bunch for the input, let me know if some of the changes aren't in line w/ what you wanted. -- manu -- Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) Founder/CEO - Digital Bazaar, Inc. blog: The Marathonic Dawn of Web Payments http://manu.sporny.org/2014/dawn-of-web-payments/ From nobody Sun Jul 20 18:36:03 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37F6C1B2ABF for ; Sun, 20 Jul 2014 18:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.897 X-Spam-Level: X-Spam-Status: No, score=0.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, SPF_PASS=-0.001, URIBL_RED=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2K7lzs6OfdP for ; Sun, 20 Jul 2014 18:36:01 -0700 (PDT) Received: from mail.digitalbazaar.com (unknown [216.252.204.51]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D884F1B2ABD for ; Sun, 20 Jul 2014 18:36:00 -0700 (PDT) Received: from [192.168.100.5] by mail.digitalbazaar.com with esmtp (Exim 4.72) (envelope-from ) id 1X92WD-0002jB-Hp; Sun, 20 Jul 2014 21:35:59 -0400 Message-ID: <53CC6E77.9080108@digitalbazaar.com> Date: Sun, 20 Jul 2014 21:35:51 -0400 From: Manu Sporny User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Icedove/24.5.0 MIME-Version: 1.0 To: Yoav Nir References: <536BFA23.9020900@digitalbazaar.com> <73FEA0D3-E9EE-4020-8467-9DEAFA2630E1@gmail.com> In-Reply-To: <73FEA0D3-E9EE-4020-8467-9DEAFA2630E1@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/vnZ-7BLZ8R5vF7l8-WLtJJkwZos Cc: IETF HTTP Auth , Web Payments CG Subject: Re: [http-auth] Review Request for third draft of "Signing HTTP Messages" X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 01:36:02 -0000 On 05/22/2014 02:04 AM, Yoav Nir wrote: > Interesting draft. I finally found the time to go over it. Hi Yoav, thanks and apologies for the very belated response. > * I agree with Mark about keeping the motivation part simpler. > Signing prevents forgeries, not monitoring. I've tried to fix this issue here: https://github.com/web-payments/web-payments.org/commit/406758440f22291f115fc54cd6491572dcf6a393 > * To my mind, the main motivation for this is that HTTP (and HTTPS) > are often not deployed end-to-end. There are internal proxies, > decrypting proxies, next-generation firewalls, load balancers, TLS > routers, and probably a dozen others I’ve forgotten. Each hop of an > HTTP connection may or may not be protected by TLS, may or may not > strip the encryption, and may or may not re-encrypt (and > re-authenticate) for the next hop. Signing requests are responses > provides end-to-end integrity, which current HTTP(S) does not > provide. That's true and well said. We also needed a very simple way to authenticate the caller in one message. OAuth1/2 was too complex for our needs. Do you think we should put something about single message authentication in to the introductory text? I've tried to address both points here: https://github.com/web-payments/web-payments.org/commit/c0f262910c5385f736e9a0f7c556d12205fca9af > * About the text in section 1 regarding password cracking: > > Digest authentication, while providing a little more protection, > still leaves the scheme open to brute-force attacks that are capable > of discovering a weak or random 8 character password in less than 3 > hours using a single commodity computer > > I’m not sure how you can crack 8-character random passwords on a > commodity computer in 3 hours. Brute force won’t get you there. I > suggest you either explain how, point to a reference, or even better, > pull it out. Yes, the figure was wrong. I've pulled the text out. That's what I get for using buggy online brute force password attack calculators. :) > * The URL of signature schemes ( > http://www.iana.org/assignments/signature-algorithms ) is broken and > I couldn’t figure out the one you meant. There isn't one as far as I know. I'm requesting that IANA create one, see Appendix E.2: http://web-payments.org/specs/source/http-signatures/#sa-registry > * 2.1.3: some headers may appear more than once (if their value is > defined as a comma-separated list). If there are such header lines, > I’m guessing the signature applies to all or none, right? (that’s > not a bad thing - just a clarification question) The signature applies to all of them, correct. See section 2.3 Signature String Construction: https://web-payments.org/specs/source/http-signatures/#canonicalization Specifically, this sentence: """ If there are multiple instances of the same header field, all header field values associated with the header field MUST be concatenated and used in the order in which they will appear in the transmitted HTTP message. """ I'm not positive that this algorithm would survive all proxies, but I couldn't think of a better approach. > * I’m wondering if the WWW-Authenticate header should have a > “headers” parameter. Otherwise, the server demands a signature, and > then the client signs something, which may or may not cover > everything the server policy says should be signed. This could be > pre-arranged between client and server, but then the client should > also know in advance when to sign. So I think the server should > specify which fields need to be included in the signature. You're right, that's a problem. I've tried to remedy that here: https://github.com/web-payments/web-payments.org/commit/deefa4df47446c5ba6944e85021bd6b90659bfc3 Do you think it should be possible for the server to specify a particular challenge as well? The challenge could be used to prevent replay attacks of digitally signed messages. That said, it would complicate the protocol and would be re-implementing TLS to a degree. It would be useful for non-TLS connections, but I would imagine that those sorts of connections would be using a nonce of some kind anyway. We've kept this challenge-response feature out for the time being to simplify the protocol. Thanks for the feedback, Yoav. Let me know if those responses don't address all of your concerns. -- manu -- Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) Founder/CEO - Digital Bazaar, Inc. blog: The Marathonic Dawn of Web Payments http://manu.sporny.org/2014/dawn-of-web-payments/ From nobody Mon Jul 21 06:18:52 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D3C21B2DEE for ; Mon, 21 Jul 2014 06:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTvzkZic1esa for ; Mon, 21 Jul 2014 06:18:42 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81E691B2BCD for ; Mon, 21 Jul 2014 06:17:24 -0700 (PDT) Received: from [31.133.160.134] ([31.133.160.134]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MBmvH-1XHECz0n5j-00AkMR; Mon, 21 Jul 2014 15:17:22 +0200 Message-ID: <53CD12E2.2020608@gmx.de> Date: Mon, 21 Jul 2014 15:17:22 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Kathleen Moriarty References: <53CB7723.5080609@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:LnKRGlAeHXlaMF3igPRdvSMv2/2RPdfeW19xvRBCReq8pX7Q3SM mtgGyh/XqOTFjMME1BWnRDkt8tacAXydASRGsOo7rpdoGrNRnYNRjSYEPNpTSNcJ9eiFO8Q Kbcvdss1DdmzkI/NA7Aykp2F1AcXNvTVJeiw27wAwlBvKMFsX0/o0WVtPOFk2yy1uQm50Oi 39h2m+02wLpPQXQqJBecA== Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/2lMjaItWo5U_d3T-6SI7-9feGG4 Cc: http-auth@ietf.org Subject: Re: [http-auth] Fwd: Privacy considerations X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 13:18:48 -0000 On 2014-07-20 15:15, Kathleen Moriarty wrote: > Thanks, Julian! > > Looking at this with fresh eyes, could you adjust the last sentence to > make it clear that those are just possible examples and not the full set > of possibilities. Perhaps the following: > > If the same > username and password combination is in use to access other accounts, > such as an email or health portal account, personal information could be > exposed. Sure. . Best regards, Julian From nobody Mon Jul 21 06:19:33 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 261B61B2BDD for ; Mon, 21 Jul 2014 06:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvvpx-Ul6efL for ; Mon, 21 Jul 2014 06:19:28 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18D5B1B2DE5 for ; Mon, 21 Jul 2014 06:18:31 -0700 (PDT) Received: by mail-lb0-f173.google.com with SMTP id p9so1583990lbv.32 for ; Mon, 21 Jul 2014 06:18:30 -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=u/zohbBxIAX0Oq2Bke0k3XASgiAMzRssn/H1X8t6k9A=; b=zxZApfeZfMQt5QRbdj2UumaFXoAvrlyu2DhBjTPEQ9o8HUEKgosSzdQ7+8VTlKoS+Q SFf+ZWLjNzr+xExxlQ4DPtTnb5dljBYdjIpBlTIymZtVca+nuBcVr3ExL3ILiGx+Aunk QAwSmAnLXzMuYlZwotKt8DQqrFUg2nRu53t4sg4HDkihtu0+9WcGB+XF1ReGheipI5pT sKTTBxIWJnwwQ0zq8FhtrduL1TkMON/cekPuLJ6zEDWzza9s/10J5M/g+v95BiDI4M3+ I5jeg73WZQ08FkHKq3fq5ye44xqA0p3JsDfS9MHj6LBGonVUFQTZhp/Nw2gPZvDm5V82 7aXQ== MIME-Version: 1.0 X-Received: by 10.152.228.164 with SMTP id sj4mr26448157lac.7.1405948709654; Mon, 21 Jul 2014 06:18:29 -0700 (PDT) Received: by 10.112.207.73 with HTTP; Mon, 21 Jul 2014 06:18:29 -0700 (PDT) In-Reply-To: <53CD12E2.2020608@gmx.de> References: <53CB7723.5080609@gmx.de> <53CD12E2.2020608@gmx.de> Date: Mon, 21 Jul 2014 09:18:29 -0400 Message-ID: From: Kathleen Moriarty To: Julian Reschke Content-Type: multipart/alternative; boundary=001a113437166956da04feb3f1fb Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/Jyiwxu3uWymIquvjzFYGjpJ70ko Cc: http-auth@ietf.org Subject: Re: [http-auth] Fwd: Privacy considerations X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 13:19:30 -0000 --001a113437166956da04feb3f1fb Content-Type: text/plain; charset=UTF-8 Thank you, that closes out my comments. On Mon, Jul 21, 2014 at 9:17 AM, Julian Reschke wrote: > On 2014-07-20 15:15, Kathleen Moriarty wrote: > >> Thanks, Julian! >> >> Looking at this with fresh eyes, could you adjust the last sentence to >> make it clear that those are just possible examples and not the full set >> of possibilities. Perhaps the following: >> >> If the same >> username and password combination is in use to access other accounts, >> such as an email or health portal account, personal information could be >> exposed. >> > > Sure. . > > Best regards, Julian > > > > -- Best regards, Kathleen --001a113437166956da04feb3f1fb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you, that closes out my comments.


On Mon, Jul 21, 2014 at 9:= 17 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
On 2014-07-20 15:15, Kathlee= n Moriarty wrote:
Thanks, Julian!

Looking at this with fresh eyes, could you adjust the last sentence to
make it clear that those are just possible examples and not the full set of possibilities. =C2=A0Perhaps the following:

If the same
username and password combination is in use to access other accounts,
such as an email or health portal account, personal information could be exposed.

Sure. <http://trac.tools.ietf.org/wg/httpauth/trac/ch= angeset/74>.

Best regards, Julian






--

Best regards,
Kathleen
--001a113437166956da04feb3f1fb-- From nobody Mon Jul 21 13:40:47 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12ED81A0326 for ; Mon, 21 Jul 2014 13:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.679 X-Spam-Level: X-Spam-Status: No, score=-3.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxWt6mbuBScW for ; Mon, 21 Jul 2014 13:40:39 -0700 (PDT) Received: from na3sys010aog106.obsmtp.com (na3sys010aog106.obsmtp.com [74.125.245.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59CCF1A0444 for ; Mon, 21 Jul 2014 13:40:36 -0700 (PDT) Received: from mail-vc0-f181.google.com ([209.85.220.181]) (using TLSv1) by na3sys010aob106.postini.com ([74.125.244.12]) with SMTP ID DSNKU816w/5BDLiiLmltzcgVIlxNf0sCRU/j@postini.com; Mon, 21 Jul 2014 13:40:36 PDT Received: by mail-vc0-f181.google.com with SMTP id lf12so13160381vcb.40 for ; Mon, 21 Jul 2014 13:40:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=+4pJcPep+wbxi9IBPZdi/jdGOjbJce6VwwUCdUChPqo=; b=hOAiZkOcXcAcNIwOu4nIlX31r/rxGFLbTsVoH+3JbpFkBzdjur3HRf9LQPHYxAhU9t FZ2hww0bjclq3k1lUspf/hdVfxCTVfFN7X2xja/nKxgLHaS9RvvefvjHm7e20OMIcX7K GOMCQ9yqyLZ122Rhe0OXWDwZIXo0ydIM07RGk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=+4pJcPep+wbxi9IBPZdi/jdGOjbJce6VwwUCdUChPqo=; b=Lo5FXU63EGHTd1DXEQgT32BmjCvPk8sCXDwzQwtBCsGAY8jX9fYB9RXE46t+eaW3v9 eNxYgmwmTLY/UcCKTZMLDYDkM2qfo1DnMFJV7+PHAcXxdSoaIaAvbZrA53PJXDftASlS 39DouBZlns5lf7TgjBdnzMIZf06tyQcWQmrAqNmjZk7JrjGZ637hPNUQk7MaU1fQMV05 qtxvwmwpcqcqvCN277kkbvhyg4DF+3L6C7WiZ+hWQoasWGNCcdr3AMKDdu6/GSk/8SUz YwQYJF+yp9U9SnVf3TDGLFKd7gPEvnQUVvHX+kAathyGcLy6Jfc80ddbtEnzZ9HW2aWV Svzw== X-Gm-Message-State: ALoCoQmESFekEwcjZywhuzb0HqbWNGDHv0crEP3eA0iVRyXt+P3dV1AsorTRIx8GM0C5zVMftMvKQ69MWT/WnWKcxOR4JFpyDGmqDYrzb5eR2DOWC/WqHLr9dpQIfrevjv3wbO0mCmhi X-Received: by 10.52.166.10 with SMTP id zc10mr13117180vdb.61.1405975235356; Mon, 21 Jul 2014 13:40:35 -0700 (PDT) X-Received: by 10.52.166.10 with SMTP id zc10mr13117150vdb.61.1405975235161; Mon, 21 Jul 2014 13:40:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.154.198 with HTTP; Mon, 21 Jul 2014 13:40:15 -0700 (PDT) In-Reply-To: <20140718112027.GA9740@LK-Perkele-VII> References: <20140704220217.30291.17196.idtracker@ietfa.amsl.com> <20140705124400.GA3684@LK-Perkele-VII> <20140718112027.GA9740@LK-Perkele-VII> From: Yutaka OIWA Date: Tue, 22 Jul 2014 05:40:15 +0900 Message-ID: To: Ilari Liusvaara Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/xc-18TJvXpUl0T_y6_ghlf2DN8E Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-mutual-algo-00.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 20:40:45 -0000 Dear Ilari and all httpauth WG people, I've prepared a candidate for next revision of the draft available at the following location: https://www.rcis.aist.go.jp/special/MutualAuth/files/spec/draft-ietf-httpauth-mutual-algo-00.1.txt This incorporates updates from the discussions and suggestions in this thread. I'm currently self-reviewing again about the changes. (Final question in my mind: is is safe to reject "seems to be invalid" K_c1 immediately? Isn't it leaking some information to the client? If you have any idea, I appreciate it.) I will soon submit it as revision -01. Thank you really for valuable suggestions and discussions. 2014-07-18 20:20 GMT+09:00 Ilari Liusvaara : > On Fri, Jul 18, 2014 at 05:09:34PM +0900, Yutaka OIWA wrote: > > Looks like there are unstated assumptions: > - q for discrete groups has to be safe prime. > - r for elliptic curve has to be prime (hr = #E). > > All the groups defined in -00 do satisfy these conditions. > >> It is copied from the original ISO specification, and >> it seems to be corresponding to the DL-case checking >> "[t]he value of K_s1 MUST satisfy 1 < K_s1 < q-1", >> that is to check K_s1 is not equivalent to either 1 or -1. >> For this purpose, it should at least be [2] * P'(K_s1) <> 0_E. >> I don't have a strict idea on why this is 4 instead of 2, though. >> Does anyone have idea on this? >> (Our colleague currently considers this 4 as not related to >> the cofactor setting). > > It seems to me that if h=1, then [4] * X = 0_E iff X = 0_E. > > And if h=2, then [4] * X = 0_E iff [2] * X = 0_E. > > Regarding the 4, maybe its origin can be traced to some standards > specifying h to be 1, 2 or 4. > >> However, if J(pi) is provided from client-side, it is easy to cause >> the problematic condition, by >> * choose an arbitrary S_c1 randomly, >> * compute J as -([t_1] * K_c1'), and send it to server as J(pi), >> * talk to server with per-determined S_c1. >> The similar problem also exists in DL setting. > > Yeah, forgot about that. > >> Verifying whether J is valid (correctly derived from some >> plain-text password pi) is impossible. > > Doing ZKP for discrete logarithm is presumably not practical, due > to extra values incurred. > >> The fix is quite easy in one of two ways: >> * check that [4] * (J(pi) + [t_1] * K_c1') <> 0_E upon >> reception of K_c1, or >> * limit number of retries of S_s1 selection (to some small numbers). >> In either ways, if the client is not malicious, possibility of >> invoking this condition accidentally is cryptographically negligible. >> I'll incorporate one of these additional checks into the next revision. > > Actually, given that r is prime, it seems to me that: > > [h] * (J(pi) + [t_1] * K_c1') <> 0_E > <=> > [h] * [S_s1] * (J(pi) + [t_1] * K_c1') <> 0_E > > (scalar multiplication commutes and Z_r is a field). > > So one would never need to retry. > > > > -Ilari -- Yutaka OIWA, Ph.D. Leader, System Life-cycle 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 nobody Wed Jul 23 06:18:48 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A70E1A0ADC for ; Wed, 23 Jul 2014 06:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.679 X-Spam-Level: X-Spam-Status: No, score=-3.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRYJ589M2gTS for ; Wed, 23 Jul 2014 06:18:45 -0700 (PDT) Received: from na3sys010aog109.obsmtp.com (na3sys010aog109.obsmtp.com [74.125.245.86]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42CAB1B27A4 for ; Wed, 23 Jul 2014 06:18:45 -0700 (PDT) Received: from mail-vc0-f169.google.com ([209.85.220.169]) (using TLSv1) by na3sys010aob109.postini.com ([74.125.244.12]) with SMTP ID DSNKU8+2NKe6FeLtId2yL1pY5ebjmhtvPevP@postini.com; Wed, 23 Jul 2014 06:18:45 PDT Received: by mail-vc0-f169.google.com with SMTP id hu12so2125979vcb.0 for ; Wed, 23 Jul 2014 06:18:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ycNBz8yBoVvQaGFULmY84scbuyg6LMGzPvgcZmAWEjM=; b=Ll5X0rVUt8i7RzbAa18ejaLDiozA+JIfl9n/DXQEs2NDXwY8ty0nGKCIcCcP3oTDm+ bo9TzDF5KNmJbuqa1h8/F9+jvikfeQOe2tvaEZA+NY7zXXGj5Fb1/NXzOH9UV2iigPW9 VVwmGBmfKAXtENH+gUhnAHslR7hn1+tfS8i2U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ycNBz8yBoVvQaGFULmY84scbuyg6LMGzPvgcZmAWEjM=; b=e4ZIlPREUMtBDKYeUUDh60lISFtiNvaEldv1Ten/jYSS6UGb9sPiIDMb3hWNQb9deq 2ndRDZFctbi/PHbE0dulDH9sO+VnNaXoNx9W7mBWvQA/JNeHJzNcsclMNxdYarKVaXZq XKlvKbQhSLcmqq0oiJoGcsWAYG7rjQLsK7+H6+QTjtq4rPeEnumHKxRiMD2yqimWSEcp aMSjxTRJ0WUR27bAj9NYufe+xj927ZxsAEz+wN55xvFGvOA2maNjIL7UGvJ5YA3hKfb9 GXbOA2ZUVVwuc7mlL/WPk5IQYM//8fHyy/azqcAbw4HL39qSOj9BgOaKCs14Nt6z0qQB GjgQ== X-Gm-Message-State: ALoCoQlbTpAFNl1UT+kenotTqAG1KP+1EWxMLoMMqPg/N3tsNvJsy1Adtt1P6riBLNXQyCBFEQ9GLbKs063V2ZMj2j3odYQpyFnhqTQ91/n81F6Gykhis5JIGyICCZ99TVZZREXEeZt2 X-Received: by 10.221.38.129 with SMTP id ti1mr1960080vcb.9.1406121524175; Wed, 23 Jul 2014 06:18:44 -0700 (PDT) X-Received: by 10.221.38.129 with SMTP id ti1mr1960061vcb.9.1406121524036; Wed, 23 Jul 2014 06:18:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.154.198 with HTTP; Wed, 23 Jul 2014 06:18:23 -0700 (PDT) In-Reply-To: <53C94EC6.3000103@gmail.com> References: <20140704220217.30291.17196.idtracker@ietfa.amsl.com> <53C94EC6.3000103@gmail.com> From: Yutaka OIWA Date: Wed, 23 Jul 2014 22:18:23 +0900 Message-ID: To: Rene Struik Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/ASnDq-Q9tgCTENn-aEn5FiM9Jb8 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-mutual-algo-00.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 13:18:47 -0000 Dear Rene, this protocol is based on KAM3 of ISO/IEC 11770-4:2006. ISO-spec says it is also called {DL, EC}APKAS-AMP in IEEE P1363.2, proposed by T. Kwon. There seems to be several literature written by the original author. http://www.isoc.org/isoc/conferences/ndss/01/papers/kwon.pdf seems to be the most "academic" paper with analysis to (some older revision of) this primitive, and there are also several revisions submitted to P1363. http://grouper.ieee.org/groups/1363/passwdPK/contributions/ampsummary.pdf http://grouper.ieee.org/groups/1363/passwdPK/contributions/amp_final_revision.pdf http://dasan.sejong.ac.kr/~tkwon/research/ampsummary2.pdf I hope these will be helpful for reviewing and analyzing the proposal. Using some other Augmented PAKE primitives with my Mutual base proposal (draft-ietf-httpauth-mutual) is easy in general. 2014-07-19 1:43 GMT+09:00 Rene Struik : > Dear authors: > > The algorithms in the draft seem to be based on the Augmented PAKE protocol, > but differ in various aspects (e.g., hash function definition, details of > cryptographic operation). Thus, it is not a priori clear whether the results > in the AugPAKE paper apply here. If there is a technical write-up that > analyzes the cryptographic properties of this (specific) protocol in detail > that would be great. > > Best regards, Rene > > > On 7/4/2014 6:02 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 : Mutual Authentication Protocol for HTTP: >> KAM3-based Cryptographic Algorithms >> Authors : Yutaka Oiwa >> Hajime Watanabe >> Hiromitsu Takagi >> Kaoru Maeda >> Tatsuya Hayashi >> Yuichi Ioku >> Filename : draft-ietf-httpauth-mutual-algo-00.txt >> Pages : 15 >> Date : 2014-07-04 >> >> Abstract: >> This document specifies some cryptographic algorithms which will be >> used for the Mutual user authentication method for the Hyper-text >> Transport Protocol (HTTP). >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-httpauth-mutual-algo/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-httpauth-mutual-algo-00 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> http-auth mailing list >> http-auth@ietf.org >> https://www.ietf.org/mailman/listinfo/http-auth > > > > -- > email: rstruik.ext@gmail.com | Skype: rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 > > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth -- Yutaka OIWA, Ph.D. Leader, System Life-cycle 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 nobody Wed Jul 23 06:47:09 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79E841A0AC9 for ; Wed, 23 Jul 2014 06:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.679 X-Spam-Level: X-Spam-Status: No, score=-3.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yl3F_rIhKoG7 for ; Wed, 23 Jul 2014 06:47:00 -0700 (PDT) Received: from na3sys010aog113.obsmtp.com (na3sys010aog113.obsmtp.com [74.125.245.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9328C1B280A for ; Wed, 23 Jul 2014 06:46:57 -0700 (PDT) Received: from mail-vc0-f178.google.com ([209.85.220.178]) (using TLSv1) by na3sys010aob113.postini.com ([74.125.244.12]) with SMTP ID DSNKU8+80WJ/hB7B7l1wiiNRmrPJ+QRIyysi@postini.com; Wed, 23 Jul 2014 06:46:57 PDT Received: by mail-vc0-f178.google.com with SMTP id la4so2192864vcb.9 for ; Wed, 23 Jul 2014 06:46:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:from:date:message-id:subject:to:content-type; bh=j3F3WNrsnexQVDlHN4PcOSF1aKXvficGuHqS3waRAdQ=; b=mrCd4EN6VngM7jG0yyZDahq9SVSHmpgUL931Pmx76S34mYxWHv6i6IGju2qS5mxuDH nE3HaSYi2BzWA9+8zYS3FRbGSkLGoKHCoYL+7hamD0R4SVotjsRTioGBqfwPJX0Ic6QS c2poQwB7lqv7/V/7Dloy1uRm/hJ/dhWpthlXM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=j3F3WNrsnexQVDlHN4PcOSF1aKXvficGuHqS3waRAdQ=; b=SGqm2x0IDT7aK9xVZTqFxgipCgMtaucXsViQAxWaoN9EqEQJ3xWBxHbduu3VPUtgIr M8uNN4K+1wM3Jw5Md1InyuGoW/zthAIRZTam1/+W8Q1/9dan/cbZImad/74emreSbaxH rR4qkIyAqCEMS+5rbiCdga5A64455QbJtCs3swoHpUt59N4CN6yzmCmzWDvA62eLQSbC 7eU6uZOKGmoHTLx8nWvb3P7HnAcSzEI+mPmn6XuodEnUR9lTfYG4ASpUwKCGfCieG/Xh hPMZPXBB+a17AX0SafP6ndaZ6o+C2JR6DHklmYCoZSxIeNwrgVc9lJZpvptOTJ8oqKv4 kTaQ== X-Gm-Message-State: ALoCoQl6wxitmB21baRZ6fBT36RFzlrRtIJvDGyaow09Z0B7W7uFc+lfuwkDuE3fvYVs0ljLDvtlm720dRoBtxmZGAkBp23OjFBXkE6HA7ZCubLaGlFpu8ouoeCUlUtsuPF6ARWVF2ll X-Received: by 10.52.157.41 with SMTP id wj9mr1890247vdb.1.1406123216717; Wed, 23 Jul 2014 06:46:56 -0700 (PDT) X-Received: by 10.52.157.41 with SMTP id wj9mr1890229vdb.1.1406123216567; Wed, 23 Jul 2014 06:46:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.154.198 with HTTP; Wed, 23 Jul 2014 06:46:36 -0700 (PDT) From: Yutaka OIWA Date: Wed, 23 Jul 2014 22:46:36 +0900 Message-ID: To: http-auth Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/ANeq7_ctXyt4-QwcI6Kv7hQU9Eg Subject: [http-auth] Mutual: ticket #4 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 13:47:02 -0000 Dear http-auth readers, Regarding open ticket #4 (http://trac.tools.ietf.org/wg/httpauth/trac/ticket/4), I plan some modification to the current draft. Feedback comments are appreciated. I'm considering to change the "single-port" type auth-realm token, harmonized with Web Origin's string construction. It will then mean: "http://www.example.com:8080" for HTTP on port 8080 only, "http://www.example.com" for HTTP on port 80 only, "https://www.example.com" for HTTPS on port 443 only, and "www.example.com" for both HTTP/HTTPS on any port. Currently, the 2nd and 3rd ones have explicit port notifications, like "http://www.example.com:80" to emphasis single-port-only nature. These will be changed in the next revision if no objection exists. If this change is not satisfactory, please give me a comment. -- Yutaka OIWA, Ph.D. Leader, System Life-cycle 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 nobody Wed Jul 23 06:56:12 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF4D51B29A2 for ; Wed, 23 Jul 2014 06:56:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.079 X-Spam-Level: X-Spam-Status: No, score=-3.079 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtkPkaeZGylf for ; Wed, 23 Jul 2014 06:56:09 -0700 (PDT) Received: from na3sys010aog101.obsmtp.com (na3sys010aog101.obsmtp.com [74.125.245.70]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D083D1B2984 for ; Wed, 23 Jul 2014 06:56:08 -0700 (PDT) Received: from mail-vc0-f175.google.com ([209.85.220.175]) (using TLSv1) by na3sys010aob101.postini.com ([74.125.244.12]) with SMTP ID DSNKU8+++K24izzQ6IPMe+PNY9a1Nky1XtZn@postini.com; Wed, 23 Jul 2014 06:56:08 PDT Received: by mail-vc0-f175.google.com with SMTP id hu12so2144081vcb.6 for ; Wed, 23 Jul 2014 06:56:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:from:date:message-id:subject:to:content-type; bh=DvWKBocusJrFSDk4x025lRfiE0S3mI6KKYYpVu7Zj6A=; b=DGJee9Au8bgmjpUFCx9va0TuVCNOC1DhxgWTk/ypt9Ib+2u81PfdUusM/rD74crrSc 16eGKrayBNFocd9zjT1tvOuiJz4IM5XKVe+DL5D4Xc7104lsn7W/rESd07Htl1Kkxf6G 2yptcnIccJ1KDa21cEqbxGsXBn+Xnq6VBW1/E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=DvWKBocusJrFSDk4x025lRfiE0S3mI6KKYYpVu7Zj6A=; b=Yw4WWbTrCjunfT+X9Xn7kEeTmf8//zN0eJDzS/v5SnedBf+/ncfqopK3pCO6rtwe4E 6I0/mc4SK2bCwC83uvewq1kOJCt30S+lUPEZamD+kU2yzIhGGA8zgPe7GDm2u+gCflMd UOaFEQzZ0AzcqSfkH9PlPYyP9+UOpv8eZWIMdFLRRp1qQNwImwCgciMnHmoecY4cZ2OX Oh9n4B75P3ojvJVx0nshPAWfdq8mo8D02Aq8bi+1L/yoXil2UDY86ZmwvHYC01SmYsQt rz72a9f8Mjn+TgL8lHBcAECu505R/7dqYeCPr4cOKB5gr+Ia5GV6PURQqdqmJJ8ANPYR In9Q== X-Gm-Message-State: ALoCoQkjKdiJRqLaomXqia9QqsjYkJTjpUFsLT0FldLmUeKjznmXqiFuFxW+qHiqcfnW7tbO5oCYIq55h4uqv4rIEsUg9ydGLE0HG7lkqbZICScFju/uxtN4pPjkx/B0g6Q9H6Gc+61Q X-Received: by 10.220.74.10 with SMTP id s10mr2144614vcj.61.1406123767754; Wed, 23 Jul 2014 06:56:07 -0700 (PDT) X-Received: by 10.220.74.10 with SMTP id s10mr2144595vcj.61.1406123767581; Wed, 23 Jul 2014 06:56:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.154.198 with HTTP; Wed, 23 Jul 2014 06:55:47 -0700 (PDT) From: Yutaka OIWA Date: Wed, 23 Jul 2014 22:55:47 +0900 Message-ID: To: http-auth Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/31cp5N48Ts-UxQTjUFOVlv8pJdo Subject: [http-auth] Mutual: ticket #9 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 13:56:11 -0000 Dear all, Regarding the open ticket #9 (http://trac.tools.ietf.org/wg/httpauth/trac/ticket/9), As the crypto primitive is involved, simple-enough, detailed-enough "crypto-style" notion is quite difficult. It may possibly go to something like "C->S: f1(n), S->C: f2(m, n), C->S: f3(m, n, o)...." in extreme, which is quite non-meaningful. Seeking for some compromise level, I made some "still-complicated" version which may be helpful for some readers, attached below. It omits all kinds of "group" operations (mod q, mod r, etc.), hiding all details of hashing, and so many other things such as border-case error handling. If this is satisfactory for readers in this working group, I'd like to add it to the next revisions of the "algo" draft. Comments are really appreciated. ======== C: S_c1 = random C: K_c1 = g^(S_c1) ----- id, K_c1 -----> C: t_1 = H1(K_c1) S: t_1 = H1(K_c1) S: fetch J = g^pi by id S: S_s1 = random S: K_s1 = (J * K_c1^(t_1))^(S_s1) <----- K_s1 ----- C: t_2 = H2(K_c1, K_s1) S: t_2 = H2(K_c1, K_s1) C: z = K_s1^((S_c1 + t_2) / (S_c1 * t_1 + pi)) S: z' = (K_c1 * g^(t_2))^(S_s1) (assumption at this point: z = z' if authentication succeeded) C: VK_c = H4(K_c1, K_s1, z) S: VK_c' = H4(K_c1, K_s1, z') ----- VK_c -------> S: assert(VK_c = VK_c') C: VK_s' = H3(K_c1, K_s1, z) S: VK_s = H3(K_c1, K_s1, z') <----- VK_s ------ C: assert(VK_s = VK_s') ======== -- Yutaka OIWA, Ph.D. Leader, System Life-cycle 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 nobody Wed Jul 23 19:47:46 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B4BE1A029D for ; Wed, 23 Jul 2014 19:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BvvJ9JcCqooB for ; Wed, 23 Jul 2014 19:47:42 -0700 (PDT) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C3A61A0151 for ; Wed, 23 Jul 2014 19:47:42 -0700 (PDT) Received: by mail-ig0-f170.google.com with SMTP id h3so6061566igd.5 for ; Wed, 23 Jul 2014 19:47:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=kG7GlvlNhMW/luAKsy4Z+Nw0vIIp1j0VLLWAp7Smnfo=; b=JvHPooFrpYZD75A70Mr1MmusGK+qy6bpOjlAQAVG2fq0/786XNg+i+/etZdWNXI5NN HQ5bkBA9A3vsk7JeCPwdN8ORye4FEjR1ZQizzfPUCzukJ+363yjknuiGxmlEZobEmy2L N7U1APK3YB+Iu2/1QeLiuFgcrudKEaQrunoNme+LBc/DFAnMMVK/fJx9q5nH/ehiCQI8 C7YGW00Iw5eQQlzJsq2VQfo6jWRsx3C2Rp2ahW/OnTezGxgWCoUwmiJcJZ143d946NdF 4KkEoBtdmTVeWaK46C++mX4QUyhkg8imGNrW1Z4V//AXNwATtcprc24tVGPZ3v150zXb iQTg== X-Received: by 10.50.43.167 with SMTP id x7mr9956477igl.36.1406170061814; Wed, 23 Jul 2014 19:47:41 -0700 (PDT) Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.118.107]) by mx.google.com with ESMTPSA id dx6sm65607832igb.15.2014.07.23.19.47.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Jul 2014 19:47:41 -0700 (PDT) Message-ID: <53D073C9.2080805@gmail.com> Date: Wed, 23 Jul 2014 22:47:37 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Yutaka OIWA References: <20140704220217.30291.17196.idtracker@ietfa.amsl.com> <53C94EC6.3000103@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/yH9QmOs1me4k3fLXNHV20BPJj18 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-mutual-algo-00.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 02:47:44 -0000 Hi Oiwa: Thanks for the references. I gave this a brief look (sorry - no time yet to study this in full detail). Wouldn't the security rely on the strong Diffie-Hellman assumption, similar to the AugPAKE scheme? It may help to briefly explain differences between this protocol and the AugPAKE protocol, both from protocol and security perspective. If you could indicate why the scalar factor (S_{c1}+t2) is included in the formula at the end of Section 2 of draft-ietf-httpauth-mutual-algo-00 that would be great. This factor seems to increase the online computational cost on the server's side by one full fixed point scalar multiplication and it would be good to appreciate the rationale for this. I have an agenda conflict tomorrow am, but will try and be at part of the httpauth session, so as to appreciate your draft better. Best regards, Rene On 7/23/2014 9:18 AM, Yutaka OIWA wrote: > Dear Rene, > > this protocol is based on KAM3 of ISO/IEC 11770-4:2006. > ISO-spec says it is also called {DL, EC}APKAS-AMP in > IEEE P1363.2, proposed by T. Kwon. > > There seems to be several literature written by the original > author. > http://www.isoc.org/isoc/conferences/ndss/01/papers/kwon.pdf > seems to be the most "academic" paper with analysis > to (some older revision of) this primitive, and there are also > several revisions submitted to P1363. > http://grouper.ieee.org/groups/1363/passwdPK/contributions/ampsummary.pdf > http://grouper.ieee.org/groups/1363/passwdPK/contributions/amp_final_revision.pdf > http://dasan.sejong.ac.kr/~tkwon/research/ampsummary2.pdf > > I hope these will be helpful for reviewing and analyzing the proposal. > > Using some other Augmented PAKE primitives with > my Mutual base proposal (draft-ietf-httpauth-mutual) > is easy in general. > > > > 2014-07-19 1:43 GMT+09:00 Rene Struik : >> Dear authors: >> >> The algorithms in the draft seem to be based on the Augmented PAKE protocol, >> but differ in various aspects (e.g., hash function definition, details of >> cryptographic operation). Thus, it is not a priori clear whether the results >> in the AugPAKE paper apply here. If there is a technical write-up that >> analyzes the cryptographic properties of this (specific) protocol in detail >> that would be great. >> >> Best regards, Rene >> >> >> On 7/4/2014 6:02 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 : Mutual Authentication Protocol for HTTP: >>> KAM3-based Cryptographic Algorithms >>> Authors : Yutaka Oiwa >>> Hajime Watanabe >>> Hiromitsu Takagi >>> Kaoru Maeda >>> Tatsuya Hayashi >>> Yuichi Ioku >>> Filename : draft-ietf-httpauth-mutual-algo-00.txt >>> Pages : 15 >>> Date : 2014-07-04 >>> >>> Abstract: >>> This document specifies some cryptographic algorithms which will be >>> used for the Mutual user authentication method for the Hyper-text >>> Transport Protocol (HTTP). >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-httpauth-mutual-algo/ >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-httpauth-mutual-algo-00 >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> http-auth mailing list >>> http-auth@ietf.org >>> https://www.ietf.org/mailman/listinfo/http-auth >> >> >> -- >> email: rstruik.ext@gmail.com | Skype: rstruik >> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >> >> >> _______________________________________________ >> http-auth mailing list >> http-auth@ietf.org >> https://www.ietf.org/mailman/listinfo/http-auth > > -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 From nobody Thu Jul 24 06:41:35 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49E981A0303 for ; Thu, 24 Jul 2014 06:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TXZp34k5XLbt for ; Thu, 24 Jul 2014 06:41:32 -0700 (PDT) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0F351A02FA for ; Thu, 24 Jul 2014 06:41:31 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id w62so2821511wes.1 for ; Thu, 24 Jul 2014 06:41:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=Ho/J+B68JUD1AdC1wnl5b73L0E6FDiID1jROEXzNWGs=; b=MBRe9AH8L7AcdrCo0MqbMOeF7i/mqkXA9+AdY5KrXoHthMBSRUe8rrUR7KQOttdl55 nzdDBAXQAmSBHdoGCAGkD6ZiV606xXf4/JLMK5vK1s794x1F51Gqp/douSvKNHEie0x1 nInVUb0kas9wVbY124FUgWM7FArx0IkhiUvgFZ2ItLnEnKz1c/qiaBWO12eIxuuEwcM1 iQxZoiz8oYGWvCwOzcCABIqbR0OeGAD6GBb5m/BjqBGT0hnlAGi24XVLKzQJKFhPSXGK TA48f3TFysc6jiWy7LEyX07ZYrjQFOiVgjfbza6TH9Ccx7jPsG50D7l3DtRNJB/bZdWh iNOQ== X-Received: by 10.180.87.199 with SMTP id ba7mr12737326wib.49.1406209289953; Thu, 24 Jul 2014 06:41:29 -0700 (PDT) Received: from wireless-v6.meeting.ietf.org ([2001:67c:370:160:dc5c:e333:b9ee:8b96]) by mx.google.com with ESMTPSA id jy8sm16022555wjc.7.2014.07.24.06.41.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Jul 2014 06:41:29 -0700 (PDT) From: Yoav Nir Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Thu, 24 Jul 2014 09:41:27 -0400 To: IETF HTTP Auth Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/aUYj9lUuF1YCeX9CtIQyrMwrlw8 Subject: [http-auth] Meeting Reminder X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 13:41:33 -0000 Hi all This is to remind you that the HTTP-Auth meeting will begin at 10:00 AM = in room Salon B. If you come to the room now, you will notice an ABFAB meeting in = progress. Worry not. They will be done within 20 minutes. As a reminder: the agenda is here: = https://datatracker.ietf.org/meeting/90/agenda/httpauth/ Hope to see you all there in 20 minutes. Yoav= From nobody Thu Jul 24 08:26:30 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB7D91A0309 for ; Thu, 24 Jul 2014 08:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.453 X-Spam-Level: X-Spam-Status: No, score=-0.453 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lTGXakj-wBXq for ; Thu, 24 Jul 2014 08:26:16 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76C071A0350 for ; Thu, 24 Jul 2014 08:24:07 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id k48so2961289wev.40 for ; Thu, 24 Jul 2014 08:24:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=CVnhQYA7ChkW4XX51VpZ7M4SUPJbBFaow0cPcuCTurU=; b=Yv+pL4ilwqs17UTnX2gF5fk+JtX/lKiwIFGnig175VVMOzCBNQN2gOsrJxFNjiyAhY 4UWyd0ZTExGSNPHdIwW2P4yTcBqGmZp1e5QBIGaqEqjo8iw22iyaDyItg6mXDC2Mj25S znhQwoOgQ85TFW3pPbcxU5vXVjnTTTDLMU9JcCf24VaedXW/ttyaP7xnYx9s4ZzzkWLY zjRtnFXC29oCjJOIoIQTimth8RgLCul/gl2kgcxHY/O1ZRWO6Q1lsomtBK4Fi+mOH5fp FZpG+6qF8ySg9kbu3YyiRje4q8SvfLcZWTiGskbsoUMTZbG0ZX8cmHtn+bQoAsvQj0xc YfZA== X-Received: by 10.180.207.105 with SMTP id lv9mr13580975wic.23.1406215445244; Thu, 24 Jul 2014 08:24:05 -0700 (PDT) Received: from wireless-v6.meeting.ietf.org ([2001:67c:370:160:7856:1adf:d96b:6f7c]) by mx.google.com with ESMTPSA id bp9sm24186226wib.7.2014.07.24.08.24.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 24 Jul 2014 08:24:04 -0700 (PDT) From: Yoav Nir Content-Type: multipart/alternative; boundary="Apple-Mail=_27EFF9DD-FAAA-424A-B6AA-3B9D82132CD8" Message-Id: <3DD81803-39CF-42D7-AB71-CC3813E7EDAB@gmail.com> Date: Thu, 24 Jul 2014 11:24:02 -0400 To: IETF HTTP Auth Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/FlUdrG0b99O3mFjc-76H0UnhbAU Subject: [http-auth] Modifications to Basic & Digest X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 15:26:17 -0000 --Apple-Mail=_27EFF9DD-FAAA-424A-B6AA-3B9D82132CD8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi A question we raised at the HTTP-Auth meeting today was whether or not = we=92d like to make any changes to Basic and Digest. The charter requires us to add to things to these protocols: Adding internationalization support for user names and passwords Adding modern hash functions to Digest so that an implementation does = not depend on MD5. There are a few additional extensions proposed. The Digest draft = includes optional username hashing, which (when used) will prevent the = cleartext username from being sent on the wire. This sounds (to me) to = be a good idea privacy-wise, but there is a claim that Basic and Digest = are so horribly broken anyway, that we don=92t want to add security = features to them, even if said security features seem like a good idea = (hence the =93lipstick on a pig=94 comment I made at the session [1]). So the question I=92m asking the group here is, do we want to tinker = with Basic and Digest, potentially making them somewhat better, or do we = want to clamp down on all such discussion, and stick only to the = mandates in the charter? Yoav [1] --Apple-Mail=_27EFF9DD-FAAA-424A-B6AA-3B9D82132CD8 Content-Type: multipart/related; type="text/html"; boundary="Apple-Mail=_C41F0392-D320-44D4-AD2A-E41289F90BC6" --Apple-Mail=_C41F0392-D320-44D4-AD2A-E41289F90BC6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi

A question we raised at the = HTTP-Auth meeting today was whether or not we=92d like to make any = changes to Basic and Digest.

The charter = requires us to add to things to these protocols:
  1. Adding internationalization support for user = names and passwords
  2. Adding modern hash functions to Digest so = that an implementation does not depend on = MD5.

There are a few additional = extensions proposed. The Digest draft includes optional username = hashing, which (when used) will prevent the cleartext username from = being sent on the wire. This sounds (to me) to be a good idea = privacy-wise, but there is a claim that Basic and Digest are so horribly = broken anyway, that we don=92t want to add security features to them, = even if said security features seem like a good idea (hence the = =93lipstick on a pig=94 comment I made at the session = [1]).

So the question I=92m asking the group = here is, do we want to tinker with Basic and Digest, potentially making = them somewhat better, or do we want to clamp down on all such = discussion, and stick only to the mandates in the = charter?

Yoav

[1]
<= div>
3D"lipstick_pig_080910_mn1.jpg"
= --Apple-Mail=_C41F0392-D320-44D4-AD2A-E41289F90BC6 Content-Transfer-Encoding: base64 Content-Disposition: inline; filename=lipstick_pig_080910_mn1.jpg Content-Type: image/jpeg; name="lipstick_pig_080910_mn1.jpg" Content-Id: /9j/4AAQSkZJRgABAQEASABIAAD/2wBDAAQCAwMDAgQDAwMEBAQEBQkGBQUFBQsICAYJDQsNDQ0L DAwOEBQRDg8TDwwMEhgSExUWFxcXDhEZGxkWGhQWFxb/2wBDAQQEBAUFBQoGBgoWDwwPFhYWFhYW FhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhYWFhb/wAARCADwAUADASIA AhEBAxEB/8QAHAAAAAcBAQAAAAAAAAAAAAAAAAECAwUGBwQI/8QARxAAAgECBQIEBAQDBQUHAwUA AQIDBBEABQYSITFBBxNRkSJhcYEIFDJCFaHRI1JisfAWFzPB4SRDcoKSovE0NXNTY5Oys//EABsB AAIDAQEBAAAAAAAAAAAAAAACAQMEBQYH/8QANREAAQMCBAIIBQUAAwEAAAAAAQACEQMhBBIxQVFx BRNhgZGhscEiMtHh8AYUI0LxFSRSM//aAAwDAQACEQMRAD8Anwo/0cAAX/64cUc9sHtHyxMLk5k3 tHqPfBgAAdPfDgAHYYAAsOBggqZCbsD/APOBt+If1w4FA7DB2G4cD3wQiQkCwUf1wdumF7RYdMKs LjgYIUSmQovhSgbR9cLAF+g98KUAgdOuCFMhNi1h/XAsOOmHAv6emB6cD3wQozJBHHH+eAv6v+uH LfD0HXAVfiPTBCMyacAnBWFsPMAB2wRAI6AYIUSmgBhYC8c4WALdBhW0cdMEKUmyluDfB2B/+cLA G7tg1A9BiYQkoo29uvrhSgBsKUC3QdcHYA3NhbviYQpDSORV+ptQQZRly2lmYb5ipKQJ3dvkPTue MW3xSyDSmncmSgyoVM1ckyq1S73DED4h8x1t6cjFx8CsriyTRZrzGor83lJMhuWWML8KfKxBP3xn /i+ZBq8U7iyRQBk+rE3JH2thASX5QtfVNZhy9wudFUgLsPr64UFHPTDlgD074MDk8DF4WRNgKL8j rhwAX6j3wYAJ6DC7C9rDEoSQFKjkYAA/0cOKosOmFBR6DAhNEf6vg7DjDhHyGFW6cDAhNqBz/XB2 X/Rw6oHPAx2acy9c1z+ky1p1gFTMEMpFwg9bfy++BGqjSBt+nrhVh2tia1tpuv0vm6ZfmBjfzohJ DMn6JFuQQD6ji4+YxFKBc8DApIIMFNAXXt74BXnth6wt0GDKi/QYiFCZAHPTBEDn+uOjaADwMJsO eBiCEKuBcAKb9vbC1Av1/ng7AdCPfEEJUjab9vbACmw6e2F4MAbRz/PBCE3tPy9sHY7h09sKAv8A /OD2jcP64IQkWNh09sHtNx09sLtwOMGBdgMRCEhBzxb2we02HT2wtVsfT74O3A/rgiEJAH6entg9 p46e2DAHw9MHx/eHviYQk2Nug9sBQbnp7YVcW6g8+uDA5PI98EISCPp7YJhYC4HthZFu498BhwOf 54IQCkKDboPbCrdOntg1BsP64UAOORghMiA+Lt7YWq+gHtgEC/UYNTY9f54IQgoNu3X0xK6OyKo1 FqGny2IhI3dWqpStxFEOXJ9bgEAdyRiNS1u3vjSvBmk/h2kcx1CzENVzrTDcOkcZ5A+rMb9vh+WF qODGFx2V2HomtVawbq+100O/8rQoI4qdQsMSftVOg+pFxij+P2Vo+WZXn8IUtv8Ay9SFHC7hcEn5 MP8A3YkcvzCR6pa0t/xXDSIvJQENuP3H+Z+eJupyqLU2nc007PKVWeNKmkk/eki83sOoBCj53Pyx iw9bM6Tuu7jcL/EWjZYSQb9B19MKC9eB7Y6s4y6ryrM5MurlVaiEjdtN1YdiPkcc4HJ5x0l5wgix RKvXgdfTCgvPb2wpALHkdfXDgC36j3wISFQlR09sGFI9PbDiAWHI98Gqj5e+GQmyD8vbC9p46e2F lfpg7dMCiUhQeeB7YfyyU02ZU1QB8UcysLWB64QotfFi8NdPTZ7nyHaVpqd7yPb4S9uFv26g/TCu iDKdklwA1V81bDR6i01JltapFXFD+ay9iPiDlf0rxyCbrb1tjHwjADctjboVtjR85zyOs1vPTUb3 p8ujjp0kB+F5Lhm57W49+cUzVdJ+T1NX0pQRiOY7VXoFIBH9fvjNhn5gWjQLodJUcjmvjUKLCXF7 D2wZXnoMOBRt7e+DKi//AFxpXNSNvB4GC29eB7YdCjnp74G0c9PfAhVhR8hhQAv2wYHyGAFBPb2w qVFbntgwvA6YBXn/AKYBIVLsVCjqW4AwI7EABgAAMOlsSGldP5/qeQpp7J5q5VazT22QIfnI1h9h z8safpPwJLqk2q88dnHLUmXDYi/IysNzfYDFJrD+gn08VrZg6hu/4R26+H1hY5LNFGVV5EDE2C7u T9BiayHSmrc6YHKdMZjMrdJZUEMZ/wDNIQMeldKaI0ppobsnyKjp5DwZym+Vh83a7fa9sWAAWA44 whNQ6mOX57LQ3DUG6gu52HgPqvPmTeB2sKlVfMMxyrLwRconmTuvyPCrf6E4sOX+AVEGBzPVNfKO 60sCQ+xO7/LGyAfT2wTYMk6knvVoyt+VoHcPdZxl3gboSDmpgzGuI71Fe6//AOezEhB4QeHcQsNN xMP/ANypmkP/ALnOLyOmAfpiOqZwTdY/Yqmf7qvD21v9lqH3e/vfDU/hD4dSizabiX/wVMyf/wBX GLvbA74OqZwCnran/o+KzSv8DNDz3NP/ABSi+UFczAf/AMgbEFmXgHFZjlmqapD+1aqlWQfcqVON otfBFR8sHVt2soLyfmvzAPqvOOeeDWusuQyUiZbmyKf0U85hlI9drgL9t2KZm9JmOTzeXnWVVuWs Tb/tUDIh+jdD749fqvfDdTTw1FO0M8Mc0bizI6BlYfMHg4aHt+V3iqnUqL9Wxyt9QvICFHAZSrKe 4IIwpVF78Y3nWHgvpTM2epyjzcjq2uQaM/2JPXmI8W+S2xkettF6m0gzyZtRipoFNhmNIpeMf/kX rH9+Pn3wza0fOI9FS/BnWmZ7ND4b93goRFYgLGoLsyqqk2uSbD/PGy18CZNp6g0/EwH5anCMw/fI OSzenTr88ZTpGIVuo8uijKOk1VGLixBUG5+vTGhavqXmz55C3xK24La1wO3vinHVMrABut3QtDNV c47Kt1WYy5Jm0UkpKwNIJLnkHb1BHdSLj+eNJgqRl+f5RUXUpIhTdusCrMAB8yQQR9MZnmlNDqCm eikVvOZy0Mi3LIbEg24va3P0xe9aQyQZfl0JcPLBDCA4HLOsagNb5nt88c6gS3MRpZehxga5zARB IM+Fil+Kenxn+W1dRSx7syy1/MiZF5qYrcpb+8ot7YyGMAi/GNi01nrxvDU1D7TLYyEgkxsSm7m3 1N/kcVfxE0kqVdVnOXSKIZ52leELwikbiV+5Jtjs0XhwheUxuGLXZgFSQovewwoKC3bCmjaNzG67 WHUEdDg1U3PA9saFzZQVRYdMKUWva2DUEKOntgwD6D2xMKERHyGD4HWwHrgyvyHtic0bpbMtRT7q dfJpI2Xzqpx8KjqQvq1r29DiTAuUNDnGGiVwZJlVfm07QZbTGaQEKQOgJIHJ6Drf6Yv2qmh0DoOD IqWVJcxrS35ibdbki7uPQBRa/oPU2xccupss0rpoGBEiihQ7CQCzHu7H1x5X8SvEGXO9T5jWGohW KnfYzNdgxB+BE5sQLBiDwccrHYsNblG69J0R0bmqZ3bKX1JqSGkR1yx7tTfChZwbv5il3Nu5PwgH 1ti56tngzeky3UUSgCvpQjlTYF1PB+fHB+2PO01fJUGOOmcNKTGR/wB4xs3HxcX55JAtfnG36Gqo a/wppVaYST5bOIQF/aALc+ptz98YeisQXVy06Fdf9R4AU8G10XBlAAAdB07YUQCe2DAO3oPbCtvT pj0RXhZSQBz0wLDnphe2wPT2wQBN+nthCpVVUg+mBwD8sGSsas7sFVbkkm1sXbwr8Mc11hszHMvN y3JDYq1ts9YP8AP6U/xHr2uMVVKgbbfgraOHfVNrAan81PYqppzKc31Fmn8NyDLpK2oAvIy/DFCP WR+i/wCZ9MbL4feCmVUKR1uqphm9YDf8uLrTRfLbwXPzbj5Y0fTWRZVp/K48uyegho6aL9McQ6/M nqx+ZucSfFuemKC0vu49233XQptZSEUxfjv9u5M0dPT0tLHBSQRQQxKFjjiUKqD0AHAH0w+ABwLD 6YG5fUYG5b2vixSjvxfAuMNSTwxlBJKiGRtqBmA3H0HqcN5jV01BQTVtZPHBTU8bSTSyMFWNFF2Y k9AADgQnx9sC+Moy38Qnh3V55S0QkzWGjr5/IpM3qMueKhnkJsFWRrHn1KgfPCPxFeMU3hnmWV0l Ppxs2auglqqhhOU/LwxugZiApvw5PbpzbFJr0w0umwVow9UuDMsE8bLWQTxcDADDobc84wv8WXiF q7T2jNLai8P81SOnzerVHP5eOT8wroHjW7g7bgEcWPPUHEP4reIbZ3prww8Rsmr6qjpV1FFRZxRJ MUWOR7b0mXvsMb2uOQ4P7hhXYlgJbuI81YzCPcGu2MjvHFb7n2b5XkmWPX51mVFl1FHYNU1dQsMa kni7MQBfFX0/4u+G2c6mj0/lWsssrMwnO2GGKQkSn+6j22sfkCTiL/FzlP8AGPw7amhjjDSU1MtW nF7eU6ux/wDSrYxHXue6L1t4TaM09oelpqvWyT0Mgjy2j2yUjqlpGldVAUX63PXnsbJWruY6BGk8 +wJsPhmVWBxnWLaC2pXo7Qevck1ppyvzfTn5ipjy+eSmeOSPy3eWNQxUA+twAfW/pjPct8TfEzXu jKPUnhpprIoqOWOZao5tVu8kM0bsPLVI9u66hWB/xWw1+FtXyPxX8UNHTyDdS50lfEhP/d1AZwQP Tbs9x64c/CBbJc18RdDEALkWp5ZYFAttgmv5YA+kRP3woe9+UExMi3EJnU2MLyBMQRPA/wChH+F/ OfEfX2W0Ovs+1fl75RVefH/BabLghV1doxuk6ggqGHLcEY2wAW7c4xD8GLfwv/bnRbNzkWpp2iXp sil4VR8rxsfvjccXYaTSBOqpxQArOAEDblqEf+uuESRxyRmN0VldbMpFwQeoI9MOYGL1Qsq1R4VU VFqSm1LpV0oWp6hZKqgIJglS/wATRj9j2J4HB+WIbMqeGrqis6KpQnaeu4E9Se2NkzT/AO21FgD/ AGbcfbGPmctObKSdxuSOhv8A5fPnGHEtAgLq9HPcS47qupl8tJqmDcCwnmUuqtcBb/HyOQOhJvi6 apdajNZFZkKQtHHGSwFztvx8745qGigq8zDRhmkj3FwWFiCLAn1t04xIVGXSGSRyoZiN1gOt+Pfj FVJmVpA0W7E1Q57S7UD3VKq6+KmoiYUcVEddHsJfhgFa/XoLsSb8WBxb9BLUtpdXzohWqN5VSxsI 2/SvPPI5+hw9PkFHFLTxzQq5hkE4seCbEWbgXBuD87WNsdDlRE0m0IAJGsSTtuxP3PSw7X+WNLMz brn1nNqNygaqBz/SOUZpmLyR1RpCCFZo/iv36Hj1645Kjw1LPeizpdoJ3+dHY27bbdfv9cWSSFY4 grLteViGs9rH9wPU369PQ454PzUr+Ysu0XJKq36ubj7/ACxaMQ9qwuwVJ2yqdL4fahkmMbmiUC/P n3vzbpa/zB9+cHUeH2oEUmNIJT2VZgCQOtr9fpxi/Uks0SEOwCoxBNuthx/PHQMxqUUPdAYxewF+ L2t8+b4sGKduqf8Aj2beqqunPDc/wpanOZQsk7WEaN0W4t9z1+V8XuNIKSiFNSpHHFFcBV4UW/zx C1ubVc9XHKZ/gj3jaBb4um4+tgTb644s+1HDBlciRgIoBAa/LW5Y/wAsV1MRm1WqhggyMqrX4gNV /kNHZlLE6N+WpXPLWuSQim3fkjHj/M5d89Llao62HmtEARYuOBY8sSvxc/3vTHobxGr4s1yTMpJo vNp3mpomiJ+FkE8ZLE/IjnGGZ7llZk3ibmdNXLJLO04ljdR8TRSIHQ2NiBY97EW6Y4ePcS3OvWdC sAqhgEkX+67/AMsMsyhmG1ptlioNwl/2378dcaV4DTodAZjBKN1Q06Skg9AxIHb/AA4zqoKVEAgE gFyAG/VcgjqOP+uNA8DUvkubzsNqy1ECoHFrbUZjY973xX0WScSyPyy0/qamG9HVHOM6eJIVvAuv /XB25H9cOoAF5scGQCe2PYFfKgEzbg9PfBAWv098dBUWPTBKo56YUqVNeBfhl/HGh1NqWnIoAweg oZF/+o7iSQH9t7EL36nG9RxhF2oFAAsABYDBxKiKFQABeAB0GDNrHnGRrYubldckQGtEAaBROts8 ptM6Wr8+rKaqnpsvgaeZKWLzJNi8sQtxew5PPQHFI1h4w5RQ+Ah8Tsipv4hTyiMU1NK4iYyNKI2R yN21l+K4F/02vzfGlSpHKhR1VlYbSp5BHoRjyN4maCzPS/jBk/hnSMo0RrHUMGZUsLPxTNGw8+Fb 9Phbgdxs73xnxL6jBLd7cjsVpwlOnUdDtRfmBqFpdJ4ieJ2ttV5lkOgcv09Qtp6CEZrUZq0jK9W6 XaGNV5AVgy3P90n0GKt4j+LGpM88Am1NTPVZHn2j9TwQago6KdkEgRyjRnm/luzLdSTypHPXFn8D tuR/il8S9OVLFZMzaHNqUsbebG1yxX1Cma31B9MU/V2QSZj4jeO2mMuhMqV2U0eYpAi3/t1jEh2j uzEufmT3xnc6oaZM3JcPCY9PNaWNpCpGUQA0+MTPirh+MudcvyTRGuaWXcmR6kpqgulyHhf4iOOo OxfsT64uf4o4p6j8PGrlpQS38Kkc7T1RbM322hvrjGvErW+l9S/gcoqV88oZM5Slo6eOjNQpqTUR OiMPLvuB2hmuR0I9Rj0Fp6gbN/C6hyvO4WD1uURwVsbcMC8IVwR68nFzTnc8A/MB9FU8Gk2mXD5X EeEFVXSuRaP1r+G7TdHqGjp5cjbJqKokR5miSExxKSd4YFNpBBII/cCeTjOfFvUmjD+J7KDqLOKL /Zo6NngadpvMilEzyxlQy33blsL88g+mF5Jprxk054W5l4RUek6DNcvm8+loNQPmsccUNPKxJ3wm 8hK7n4Hra/GJrwk8GMw054p0eY5tFllfk+V6dhy6laUB5HnG1nkVGU7V3mSxvexxWc7g0Nbe0yOH snAZTLy58i8QRv6FZCNQR6g/CjqHS1LXjManw9zWGsyqpW6moo/OKI9uD8Ku/W1ht9Lnr/FHQS6f 0hUZplVOzaW8RIaXMU8ocUGZqFlMi+glj33HruI/TtO86/8ABvKtT+I8uqGzWagizDJZcnzaip4F tXQupVW3k/AyXUg7TyidhY2ZdA6Zfw4otDZjRfxLJqGCKCKKtfexWO2y7C3IsBxbjC/tnlpaTtAP KfZN+9pNLXNG8kc49xKVkFRT658HqWepCmHUWRoZwvItNDZh9txH2xRvwQNN/uEoaKtpDBWZVWVN FMTFsLlZC4IJAJG11F++3Goafpcqy3KosryeOngpKFFjjggI2wqBwtu3GOfRmpcg1Tl0uYaezOGv poZ3p5JYb7VlW25eQORuHvjZl+JribgfRYes+BzALEg+qzLxA0jr7T/jZL4keHuXZfm38Vy1aHNs tq6gQXZCu2VWJA4VVHXix454lvATQuosjz/U+s9ZT0QzzVlRE81JQgmCkjiVgiAn9TfFyef0jk84 a8fvGel8MM6yzLZMgqM1auhapmaGoCfloEYB3K2JawubcA2tcY0vL6qCsoIK2knjngqIllhlQ3WR GAIYH0IIOEYymahg3BmOBKd76opDMLERO5A2/OCq+jPD/L9N+ImpNXUVdUNLqVo3qKZgvlRMgtuW wuSSWJue+LhuFv0488ZHl2pddeOuu9J534h6ryuDJZUly6nyisjpwIpbldx2EmwZCOR88Z3Rak1F FrTSk2f5tLmbaO11NkLZlI5P5mOTbs3MOG/RKbm5sR6Yr/cNYLNgSfW6u/auqG77gDwiy9Vay11o /Sc8cOpNRZflksw3Rx1E4VmW9r7etr97W/niYyTMqDN8rhzHK6ynrKSpQPFPTyB45F9VYcHGC+HE GmMy8avF/Otb0lBVrk1TBF5uZQCVKWj8uS9gwICkJyQOg+eLf+GPMvDSHK8z0z4cZ5V5jTUlW1ZM lQJNtOZj+iMuq/BdDYAHre5uSbKdYucJiDPOypqUGtBiZETwuJWp1Kb6eRODuUjp8sY3JITWTQSR sjLKV2utj35B6H3xtA5XrijawyWSkqp6qCF5aee7MsaglT3uLcjBiWEw4bK7A1m03Frt1X9JUMlX nqSRO6CmG49wzHgqfXjF9EMNMhsoJHO4j2xX9BCIeZIqspBAKtcFTiwTOpQkj4TYHntiKDcrJKMX UL6nYFG1qxvNCW/TC25rjm63K29eb8YgczlQ08YPwbrC7A8tw4Xp6KevQE4sNVDsZSDyzXJvewvu uPuMQOaKgNQ+42Qk3bhSrLY/+0tfEvSMK4Vc7aSmiLAMjByOqoLsD9SBf/zHHTT+XThaUhWZbHao 6dfh/l7DHJRIC1SGA86S0asOLxjaCR8rED3wsSrJLJKNrQySmVpd3HlgWLE3uQSdoA67r4qndXW0 UjLHdAFKsgYPfoTuUjcfnce3thIlKSmOxBbatttgL9/uDgNJI8TK8uzq8rKLWJudvrYfXqfseKoa OCd9oYSOSBCx+Jm/uKOt+53dvS2LFWOC68xEUUBcbVUkjd3IPAHvc4y7xQrpmkajguokdY1/axCg s9vvtU/e1+L2/Oc0dIXfzF2sdxkjO4AAdEH77C/xKLDjrihajaqHmTRxLtQfrmUuYl/bc87pG6hR a3Hc8U1PistdB+W5VI1bms+WaWrKirjeKBnDMALu6ruchR3uUCjt16jGNadzfM83zeozbNJS09S+ 6ZQb7AAFCjk9AAvzsT3xdfHLOaioopaSQTALHtjhFg26ygs5HQ7QvA/ytinaShFJQxu4EfQ3t+kj pb7Y5OMBcWs2XoOin5Xl41Vnimj3Syy2DMNgUC/P0xrf4f6Bz4c5nWzWZp68vCE5uEVV5P3Y27XG MNjf8xULZmeGAf8ADW1jz+4+px6Z0xSLlmhcpy1Y0UpRo0uxbKzv8Z7fMfPgXxp6JoziM42Wb9T4 7/p9UdXEeV0ai69B9hgypv8A9MOAfDza/wAjgFRf/rj06+dJNuDx/LBAWvx/LDoHX+uCItf+uFKF 6RAweE7gBftjnzCshoaCetqGKxU8bSSta5VVFybD5DGddbVP8bb9cZt4+6DznWNZpLMdP1FHBXac z6HMC9XIyAxKQXUFVa5JVOLWNuTjh1J48aWosn0/XZLlmcZ//tPJNFlUdFTqpleJwjK3mMpU3YW4 PBBxz5X46Q02e12T630Zm2lqymyyfM6aOd0mFZBEjSOEK2G/ajHbz0IvfGepUpOGVx/Oa0U6NdhD mtvf6GynfFfwtotZZ7l+o6DPMx09n+WRtDBmeXsA5ja90cH9QuSRyOpvcG2Ozwm8Oct0P/EqlMwr s2zXOJFlzLM8wl3zVLKLKPkqgmw569cZxBrzx0zHRVH4g5TpjT1TktW8c0OSU7zTZg9O7hQd1gm6 xvx0HNhYgVz8Vej86yTQD64qtdasraeTNYZKvLJq0xw01LK7XjWNLAMpZF3H54qfUYAajWExfh3q 1tOo6KLniDbj3f6VudNo3w3otSLmcGm9OQZtLKxSdaWFZ2kHJsbX3DrxyMN+IHihoPRVYlJqbU1J Q1TpvFNteWXb/eMcaswHzIGMb8YtFab8K63w51FpaCSChodVqat5Kh5S61CRpI92Nh/ZwgccfzxP /h8p4Kzx/wDFc5nTpPWrmUSI06BmFOfMCqLj9JAT7AYnrXB2QAAz7T2KDRaWdY5xLY79Y7YVxzrx e07T53o+lywDNaHWNRJBSZjTTL5UTJtBDC173cC3Bw3lPiDmud/iEzDQ+TUdK+UZDRLLm1a+5pBO 19sSWO0dV6i/wvxjMPxJ6By3ww8Icuz3SQnByPVsObqlQ+9Iy90KKABtQsIhb0GC/CPqCs0jrCv0 br+hNDnur2TOqTMZm5rjKl/LY9AwO6wH7t69QLp11QVQx1tPTTvKs/b0jRNRl9R266x2Bab+J/Wm daO0RQR6baKHNc9zOHLaWplQOlMZL3k2ngkAcAgi56HFQzWt1x4P+IemHzzWlXqfTmpKwZbWmugR GpKlv+G6MOgPJte1la/NiJf8bWVVlT4OxZ7l8LSzaazSDMmVBz5aEq5t8twY+gUnEP8AjLzagz/8 MlBneU1Ec0ldmFDUZU6MN0krE2CDuwUvx1Fj6Yms5wc8zoAR7qKDGubTbFnEg+UeCzbwUzSq8KPG bVU809tMx6jbKc4jJJFIkjOaSpb/AA/C6k9h63GNT/CLJ/CtY+JOkbhY6DUbVUKdts24XHytGnuM RceQ5fW/iw19orOIFfLNZ6fiqHj7s6BAHX0ZT5hB9QD2xF/hQyHWelvxDaoyvUWX181MMuWl/ijU rrBUeR5SwkSW2lmiO7re98VUw6m9o2kjl/tlorFtSm8zBytPPTz1Up431+l3/FRR0Grs0pcvykaO qYZpqmZYkHnM6WBbjdYkj5jEv+CHWVLnGha3RrZjDXVOlapqaCeM3SqpCx8qVL8leGW3YBb9RiUj 8O6/M/xUZnrTPcooarIkyGOioGqdkx8/ejllRrlNoEgvYfq46nEyPDOKk8dIvEbKc1WgEmXGir8u jpQVqx2bfuG21k42n9APc4tZTqCpnGknw/Asr6tI0hT3geP4VmPidpGDMfxpU2WT51nGUUuqtP8A mNLlVX+XkqJodwMbNZrr5cakiw7YkvxNeHmRaS/CzXUelKH8r/BK6nzSJy5aR5hIEaV3blm2u3ON a1Bo3Is61nkuqa2GU5nkBlFBIkpVV8wAPdRw1wLc+pxL57DllRk9RDnEVLLQtGfzK1aK0JQcneG+ G3F+eMWftxDgd5vz+6X90QaZH9YkcvssBzLMp9HeMY8TP4FX5ro7xAyKD87+QpTU+TMY0KeZGOSC vAvwQ7DtiKyCHxEPiNrLX+ktMVGRU2ocldsn/iMCRCN4GhAMyN8EfmKJSu4/PpbG0f70PDDL6iny mPWmnoitoYYoayPYluAoKnaoHAtcWtg6LX2ms51hqXR09PUJLkFIs2ZfmoE/LyQulzt+Ill2kXuo 4PfsvVskfHv5/kpxWeAf49ovw2t4BTHhhmtTnnhxp/Oq4f8AasxyqnqZ+AP7R4lZuBwOSemJ8Hv8 sYFH41a4k0i2u8j8NYpdD00hVH/PBayWBX2GVIgLAAg/DY9OtrnG36fzKnzjJaPNKUSinrqdJ4xK hRwrqGAZTyDY8g9MX0qjXCAVlq0nNMkWnw7EWY00SEzpGoZjZjb9XzxWKXM6iuzWojpo5FpqVyry ulvNt+rbf04Fxx1xP66zBMr0pmGZSTQwrQ00lQzzg+WAiFvitzbjtziheBOq0154U0Wu4Karp4tQ wE00VUNjhRI6FrXNlbZuU91Yd8S4SVZSjKSdVY6uWeIsjJdyCioo+Hqoufsf5nFdqhLUzRwodqvF JK7hjYXIVAfltDE/MDFr1DHEqJFI1iFDsyixUAWZv9d7YrVYVWEkopjMhZxYDzFRQB1txyL9uT1O KnBOw7hNUzO99kSlANpZmuLXuR8+XH3AwtVmjR0srAFBAt1vxwXI6C1uB6m/bCMqaZ4HZ2VLs0qq yAfAWIU278Xa/pt4wismNLRtO63dWVGVRctwCFHa5JHP1OFiE0mU9KY2h3xzMt7eS0bhQUvyQxBA 3Hkt+o/TERVCGGRlp5YTM4AcRq0nwn4SSTZnB9AVXkki2OXVGp8u0vl0FXmElzUSrBHEto06fLr3 HS5sbA9o7KdT5TqOjkjyrMohVxoWS5DkEi4vw1rcAi1/QcHCyDZOGuAzRZO5hXUmXUqR1ZL1cjbI oVAkksWFidlwt+guxAtYdMUfWj1dY3lwLB5gPPmTgqhPJsokvbtyO3S547c3zbMaDNFXMvNpHjZv NVKgtvfrdWZAGFuihQQD0PXEdmmZmtiZ96mEgbFibamzoOCTf64RztkzRN1lHiLkEig+bOrljwqk LbkXAHW31xW1oKl1SBWVYueDf/LGv5npqSqgWorZly+klPE1VG9mAtchFux4IseAcSen9PeGkeXm eXMM7r5oP+6WnSGI9yeNzEdPnbGJ1M1HWXUo1upZPoqb4FeHMmrNU06yi+XUbq9WWFlsOQvQC7mw tybelsbnnayrmckc0JidDtIIte/f6dvtiR0RHRSZZBHlCx0lCATAqx8XbkFf/wBT583scWityqgz Cnl/sDKyMRUNe0kUg/UPtYGw7HHTwVNtEc1xOlKj8U69o2Wd7QF7DjAIF+2LFm2lKuBTJR2qIrA7 RbeAfl3xBSwskpR12kdVIsRjphwdouA9jmmHBNgdeBgrA3vbDmy1+B7YIr14/liEqun4y8vmr/w7 589MziaiEVWAjEcJIu+9v8BY2+WLn4fV0eo/DLJ8xkIdMyyqF3IN774l3f5nHXr7KY8+0LnORyfo zLL56VvpJGy/88YN+HTxx0NpvwMyHI9T508OdUCSUr0EFLLPNZJXCcIpA+Db1I6HHNe9rK0uMAj0 P3Xfax1TDw0SQfUfZZnHLNp7wUpswYebWeG3iMVkVTY+UT8SD0DOij3xs8uk9WeKPixkupNZ6Rh0 5p/IqGrhWjmr46iozD8xEYnD+VwqbT0J9fUjFUqtDai1TF4p02TZFUDKNb09BnOST1YEKtOdszo2 4/C+6Rrg9CtsehfD+mzKk0Jk9JnQT+JQZfDFWbH3r5ioqsQe4JBP3xTQok2Py28ifaFqxNcNALIz X5gECfOQsN01oPXendMVL+EHjJRZvkuXSSLBQVMUVTHCy/G0PnKWW/xciygE9sSed6jqPFz8F2dZ vX0cMGYfkpfzMUN/LEtO4cslySFIUNYk2va56mVm8CBT5pmv+zWv8/0/k2dztPXZVRbNhZ+G8t+q X6dDwLcjGhaL0Zp/TWhYtIZZQoMqjhaFoZTvMyvfeXJ/UWub/XDsovuCIEEazyhVPxDLOBlwIMxB 7Z43WJ+LUh1Z+AzLM5BMs1FQ0NQzA8s8brE5v/6icdBfUelfE+g8Xcj01mOocl1hkNOmdUuWRebU w1AjTZKsY5YEKo+7k9sbE0uidK5AmStLkeU5fECiUbyRQxi5uQENh1N+nXDH+3+joNO57m38Vijo NL1ElLmbmF0FNJGFLR7SoLH41A2ggkgAk4Y0hIJdeB4jdKKzoLWskEnwMW9FjZ8OtV+I1P4k6lzL JpchfV9LSU2T5fmMtpEEBUiSZRfy7lFsOou3HOL9rTwmXW3hBp/INQV4o9Q5FTQfls4plLvTzoqB nW5UlW2AkXHIU9VGI7LPHzLTnWUwZxozUuSZVntQlNl+a5jTCOGV3/4YIuSA3rc+2L14xasTQ3hp m+qpKU1Ry6AMkKtt8x2dUQE9hudbnsL4GNolrjM8fVQ99drmiIvb0/1S2WZbIum4sqziqXNW/LCC qlmhUCqFtrF05HxDqOnJxSdP+CPhbpzUMWe0WnYY6mnlMsBmqZHjp2vfciOxVeeeB1tip0+ZePv8 N0/q6GqybPqHN5YXq8hoKNYDT08qbtyzu97qOpJ/URwRcYpP4jPC3J9J5lpDNcxznP8APMuzPUUV Dm8ebZi0gaOX4gBsC7QAj/1xFSoC3NkmOP4VNOkQ7J1kTw7PBehKvUGiKXMnzCozfI1rY6OSV5RP G0/5ePczkWuxRdrk24Fj88SelM7yrUeQU2d5JWLV0FZHvgnQFQ63IvZgCOQeoxg/ippDTmhfHLwz bI8pp6DJ8zNXkdTBCtl/tlIQEm9yzTuefT54sn4F6uX/AHKy6fqGvPpvOazLnBtfh/Mv7ykfbDNr ONXI4Rr7fVI+g0UesaSdNe8eyt/hP4hprXP9UZS2VNl8+l81egkDTiTzrFgJB8I2g7Txz9cXdh64 xLw5P8A/GprjJrbIdR5NS5vCLAAtHsia3zLO5+x9MbcSMWUXEtM6gkearrsa1wy6EA+IXlWu17qz IvHrOtYVefVtRpTKtTjIq3L3mYwQQyIwEwTp8LIDfrxa/wAWPS+qMviz3SWY5SzL5eZUUkG4ci0i Fbj3vjy3oLK9c670z4l5Dp/TmT1uVZ9qWrSbMcyrjD5Ei7WXYiozFlvE4Yi1z3scbB+EbV1XqPwv GUZyx/jml5myrMEc/GfL4Rm732jaT3ZGPfGbDPMlrtHSfP6LZi6YDQ5sS2BbkInvlYNo/N/CsfhK rskz2kycav21cFJFHSK2YPUB2ML7gu8AMVBYkDaCCeebBoXKM5yTxYyvJc4jeCv1j4bGmlEoO78x HGyhWB/csUSXGL1+GHK6LKvGDxPyCfLafzaLPxXUc7wAusc4ZtqOReygJwDxuxZfGjRuoM48WvD7 VenqWKT+AV8ozB3nVDHTShA5F+WO0OAB6/PFbKJyNdwgQOwx6J312io5uxkyTxEjzVO/DpnWspvw sZFDoWlyafNcsq6mjrkzSWQRwKryOCAhuzWaL4bj9RPbF8/DHryu8QfCiHUeb/lkrhUSw1K06FI1 KsdtgST+kr3xXZPBzVWS59nQ0D4gNkGRainaesoHy5Kh6eR+HMLkjZcEgegt12g4tHhL4d5Z4bZB XZJk9dUz0dZWCqQVABMJMaIwv+65j3Hgct06YvpNqtLc2gEH7Kis6i4OLTcmRa/bKX4s5VRa40Zn Wlc4lEOS5pQSUVZJchkWQbdyn+8DYr8xzhHhDofKPDvw609oXJ2Y0On6VYIy5AeZySzyuB0Z3Z3I HF2IxYWpVNMTKAQzcKeef7x+mEPu2yC4EtS3lRsDfr/QXxfmKptFlFZtI0ldNPKLNKFjiVrn+zUk 2A9WFr+hPyxwVMEM7mQMCFBcgdDwdifMA3P1Pt25mW/NiZCHjQEgv0sRYXPWxAvfk8n1xD1lWomq 4wVESoscTlCBypAI+VrfT7YpJvdWiYsiM6RUzTzhRtVIrh/ilbjcCLcckC3pfnENU5pDFGsrzMr+ czm4PwllDXUdrdB8sc2f5vAIW2m8cMkqwkHgkrZiOOv6jz02t2xSNQ5tm1Xl9YYAzSRs8cYYEfEx ADFh+kDgfYcYqfUyrVQo5jdVHxj1jSxa0lnzWSGfLNOR76hapt0Dmyj4wLFlFydlxuIUHEG2v8h1 /llRmWn6nJ5RAux4Vy2TLas3UsYlXayPa1iBJx14O0GN8UfCXNs6pq7J8mzHLsyzHOKGozDNUzGt aGGmgit5T7kBLMZNx2i3CXHXER4X+BWZ5D4f0tZR5pQ5tXVmZJ5q5dUlkip5oHj3LuCkskhiZtq2 2oWu1wMDWgtkm6trktfkbdsarUtIaqr6nLIo5NlRSwwfE0wKTlFJAYngPt5VgwuLcGxvi26Co6PM J0Jo0ZjMqb1BG4nkAjsCLWO217At8XFX0rpc5b4J0Gc1P5yPN4IDRSKZCsscyuxINiLE3sNpuCou LEkWTwJWGt1JRN5Sw/mUlG5EAjSoUx7gOQLNcPsHHLDghMQGnMAs8gNJGy4vHuuiq9VU0ccUQkCk JUeUVcJGShQsDyAQAOOLcXxX8ip1nrI4PMkKEF3DMAb2vfcRwfQ8X+WO7xVraOu1ZPT0jPBWZSZK fM6D9dMJtwV3iLfEu/8As3B+FbnqpJ38en6vMaQRpSSxrKWVSsnVUYFSCDf4OoYEg/XvW4fyFamu igAOC0TwmqZ2izGiCfnHogspR0KPGQedg7v1PA/UoHIbGj1GZwvmMslPSyRr/YyCVhZXMigpLt62 I3RkkfqQL2GMk8OqmnyHUk2aWliVN1PmMakXpJBtMfmMOoHJWRbghub2W8/qXN5Kaqkqpg5p6BZK etla+80EnxSwkH9UsMh3x+qxsoO5+drNFzKl3StAoa5Qm2VdsiOYJlBBMcikhgPUcfyv3wrOMsoM 1iCzxIHIDLMh+ID1Bt0Pp2xTcqnWGorEaRWmkpo2qHV1kViFBSVTe5NviAF9yXF7riQfUMFJFMZI yBGyNNtf4YtwukiHoyNY83tut2OHDouFWWB1jdN51paro4mmpb1MYuSotuUevz+wxXynXp740TLM 1Rqjy5HAa/Rh1Frg/WxHGCzfTmX5jE8kKx08xFyyEgXt1IHXFzKs6rDVwu7Fe6qeCGneWeWOONRd ndgqgfMnjFc05NoSlyytrdN/wH8vRhpKs5UsTCMrdm3CP93B+eMj/GhleR/7ceHOealp4pskXNno M0SZysXlS7CGcg8BArt9L4hNC/7vqj8WWWR+F1Zl9PlEmS1EOepBPsirCysqJGrG8rBvLJKggBRz 6431yKmWBqB237F02YcGnnk3BOlrbTxW3w+IWRV3hPV+IORtLmmV0tLPUKsaGOSURFgwAexB+A9e 3PfGYav8YfE6Xw9k13pPRWVLppaJKoVlbV+ZLtJCuvlIwN1a9+1lJvh/8G9KtT4T6r0FmLhzlec1 uWToeqqw2sLel9/88Mfheo5NS/hLzrRVYFFTRvmOSzg/scqWHt5q+2E6ypUDYMSDpxCfqqdIvkTB GvAq8eAc3iDm2TpqXWGf5PXUWb0UM9DSZdRtGKfcN12duWJUgEeoxSM4oarVH4mtW+HWoc+zuPJs 0ymjzSgipq54hTmFkVkj5sA5ZywA5289Bi1fgwzn+Mfh0095hInoI5KKVT1UxyMqj/0bMQPi6pyP 8YXh5nv6Y83pKjLXIHBIDdfvKn8sSYNJhNxae/8A1DLV6jQIMGO649FUPCzwv0NQfik1Ro3Nchgz OjpcvgrMsXMC0vlD4NwsTZrmTuD+nF+1h4NZhm+ReJWUx5rTRUmtKiCsoE2sDTTx7HJk46PIguRc 2+eOLxAvkX41tFZtfy4dRZNU5cx7O8W9+vc/HEPbGzZ1Sfn8oqqBaianNTC8XnQOUkj3KRuVhyGF 7g+oxNOiwhzSNCfMfQqK1eoCx4OoHkfqFgdTr3xT0RpalPiR4U0+b5ZlAjM2Z5fVROYlQbRMEO4b rHrdOp5XGvV76Z174VS1FURUZBneXGWRnBUiFluSe6svX1DD5Yyil0V48Dw/qvDiqzLTtZltQJID qGtqZpqxqeR2LBkI+J7MQCTwOPQ42Dw+03S6V0DlWmKeZqiDLaRafzJAAZbDkkdBc347XtiaIeSQ ZiN+PDtCWuaYAc2M0/14cY2Kw2i0VqHT3hdNq/wi8Z8xq8koaeWqpKCvjSppZUj37olZv0D4WHC9 R2/Vjs8bMyqPEb8EKarmgWnrvIp8wtHe0cscwR2W/QW3kegOLQn4edIxmqoqfP8AVdNkVbM00+n6 fNdlA5Y3ZSgXftPcb+ePTGk0mQZLS6Zi09HllL/CoYBTrRNEGi8sCwQqbgj64VtF5a5psCI1m6Z2 IYHNcLkGZgC3ArFPxU1k+oPw8aV13lkDPV0lfl2bwLGpLKzpe1hzwXF/piL0HmuttAeJ+u4ck8N8 51DQ57miV1C8dqWBd6lyTI4INxIoNgbbOcei6GlpKChipKSCGmp4ECxwwxhEjUdAqjgAegw5bm1+ nbFhw5L8+aD/AKqxiQKfVlsi/wBfL3WEV2hvFfWevcr8Q4nyzQmb0dLLQSRPavYxH9L2FlY/G/DE WKjGi+GukdU6frqyt1P4g5hqiaqiVFjnpI6aGAgk7kjTgE9L/wCeLt06nAJBHXDMoBpzSZ5+2iR9 dzm5YAHL3181WPDHQ+SaByKoyrIUmWGrrXrJ2mk3s8rhQxvYdkUAD0xL5XkuVZbWVdZQZVRUtRXv 5lXLBTJG9S3J3SMou55PJ9TiS9sAn6YtDQAABoqi5xJJOqSkaqxYIoLdSB1woD6YBNsNyypEpeRl VFXczM1gB6nE6KEZPwgle+If89DXUoqqV1khLlUdeQ4Btcet7H/PGU+J3iJNqeoOn9LPIuVvMIa3 MIyVapBYBkhPZeeX734xq1LTR0dLBSQxIkVMiJGqcKgVbAfzwmbNpongNME34cEiq3iM72XexsFA +H/wj1tiPzerFPtEe0TbLRqOt7X47X/ocdGY1IR1FwzFrdbAYqWc1ZgmmacvJIVKqqnagbaLAnrx cG/9MVPdGi0MbOqKtzBTBIXXaCVEo3bSRbnjoOCALd/riGzKrd4aun8yOnqJylKvlnhGCsd3P7iz dewABw1HWSUlSqVU0U8SAKWAF26XsB0Fh88V7UudUdW8v5He1VGwRVhDXc3ubcX6Dp156gYozFaA 0BOawemqvMoIJd4jn2Rilh3sCt2YuxsPitYAXHrwORklJTG8WxpVnbfVLHYuQvxNZSCCfsCMQlFm ca7hUZxAsfltF+WgCrGh53HzD+s9B6C55OJDK5oUrInjq4T5pV45WIKeYeQjMANit0Di6m1rjjEi CVJJaFxHL10jnqPQ01FI1bLUFa6JPikjB3IXJuSSC9kvYKE9Tew5Dn2XwLFBNQQUspSSW8MI2XUM T0AuCBwVPFwD+oXh6rNanJ87my2SneeeOZqhoklsqdA7G4st0deSLN8LHjHZmWa5NK0deKZRFCwR ik3kFXPAup3AkFFO3g3UDcV4IDlMJZkXU94tRQv4TZtUQpEomVmnfarRrtF1Yg/qXnkg3t63xF+E VBLTVMKxhI/MSOVitmAYMyuOT+vlGseHW2JOvzCSv0TVK9NE6EFCrHYGjkRo+NwKoQGNg3wkEhrC xEF4JzRVNNE0kqmRqi8LkMDZCVMTgkkGzHjrYEXPBxb/AGBVYnK4BZj4z1Dp46ajjlg8pmrdl2VS DHIisri1/ga26zdGL3tfiW0rlk1WCs+XQ1IpYjKIYiUnQEDa6AC+1rDoDYj5LeW/E/l0sfjNS5gq 3p66mgQo8Sg2cyKVv1fbJE1+PhMi9Q3HdorKzSZ82nauZRHS3FFVr/xIWJBVDb9hZgrLzyOmKcn8 hV3WA0RHBK1I0OfVAkg3x5pNl3l0jT02yDNdh8wCTYdokUxtHJG1rBm4sVITllUuY5QFnn3NO3lS K1WHWsgMQAKlxwSIEBva0isRtu1+bXbTJWST12Xzw1GYrH+fpYZx5X8QgYr50LMbo7KQSejWUm5u DHtTQpnFU5aVqWraNpiwsSwuTdT3B5sf1XI9b2F11QBIlTuSTz5bqHK82qa1aaCaoSkzOoi3LTTo qhUmdT+l1YlWPFiGHdbyNd/G1ynM8uq3p4TBUrHTTRybHi/UkcrDo0TsFjcXBRrG5XjEFRSrQTRU zxfmKdZ2dY5iZI23IFZJAf1RuAAT1uFbqDd7XUIy7MJKnKjUS5Y1DHNCs8gdo7EI8Q7sqgDrz8Fw TiM1lOW4Vo0DmtRPRinr6d2anjVDFfZNTEX2hb8sps20jpyh7Y0fLKiJ6csXBmhVFkYL8HThh8m4 P/mPpjGqKeL/AO7IDHKP7GSTcfLO0KNz97foJP7rdiDu0XIs8iNdXQEBQsSOqv8A8Qg3BiPzQhlF uxQ9+LKbklVsmVA/jMfL9S/hw/2jyqpiqqWhrqarSRORYt5ZBHY3kAIP0OKl4u59o3xCm0Xl3hfT U9ZqamzimqnkyuiKrQQhCXEkwAVQG2G1zbaePXk0/mlZkU035SClrqCpIatymtjD01VY3BKkEBxY EG3UDG7eFmuNKajpkocrSLK6xEs2WSRrFInc7AOHX5r/ACwj6Li8h5iY744FFDEs6tppgmCTrpPE bjyKo82m/Ejw98W9TZ7obS9JqXJ9WyJVzU75hHSvRVQDbmJe25GLMeATyPTmz/hx0NnOjNNZxLqO akkzjUWcz5tWxUZPkQPLb+zQnkgW6/O1za+NINuowQ/SQSB9MXNoNDsw7fNVPxDnMykDbmY0VL8E /D6n8O8ozTLaTMpKuDMc0lzBVeIIKcyBQY15NwNg/wBHE3qfSWn9R5nleYZzlsdVVZLUGpy+V3YG nkNrsLEX6Dg3HAxOW+ntguh7YcMaG5QLKsve52Ym656ihoqmphqaijglmpiTBJJGGaIm1ypIut7D p6DHURfBdu2Bbph0qFhgwLYIfbB4EIYGAOmBYYEIYGCIvgfuwIR4GCPAubYFx/oYEJI/Tgx09MRe pc+ybT1CazOcypqKHmxmkCliOyjqx+QxlOtPGWtrWNJoyh8uPoczro7A/wD44+p+rW+mFLwDGpUh tsxsOJWna21Xkmlct/OZ1XR06m/lxD4pJj/dRRyxv9vW2MM8Qtb53rhvy8qPlmSDlaJW/tan0MzD t/gHHrfEBKlRV5nJmWZ1cuYV8v66qoO5voo6KB6DjHRBCXYA2Vf3N6D/AJ9Og64ltIuu/Th9VnqY oN+Glrx+inPDLL4qzWmWQRxxtHHMsoUC20JybgccWHX1xruqM1NFExiVWla5VWawA73xSvA/msrp mXZHFAFQMAWHIuSbm/p8IAHT0v1azrVgnepmDui/pWNC7tYdlHOEruiy0YOnInilDPJUpJZ6yQNI ObnhUPrfFNzzUOZzxzyU4oqtYQFYLNZ9ve1wLm1gfmT6Yj9TZ/mqZdF5cNFFFKGM0NcjqYwG+E/p K3v2JxSMynzycotdpuS9grtBLuMZbqUZONtubOOpxznVotqu0zCuIzaKbpcxSXN5aKSkenrI7yrE JeWFwWCkHpzfkkWGJfLmnnzE07TyRSngKAwiYMOivcXFvTk884o1MaOlzKnqYs2qJolFi6Rm0ySj 4gB+4G6gegHQdMWHTWZtWMHhielVjsSQneUIc8vYcXFuDwB3XDNO6rLdiu7OcuqqGeWBaGAj9BMU FkHFwEC83sL+uOHLxRROs89Y8JttjkZW2xk2azvfi5H6WFuR05OLlBNSV2+FJEeSJCrNtVgWte3w ngnoRYfXELUvEMyno3gctUqXUzuHSw/evDA2PFwTYMdyjFkA3VRdsVLakXKKegpcxzISSrZYaash lXzIgLWRgLXFgTu5uCwI5KmvT1iRmTMHoKfMoIisXm0wZ5UW11M0JY70AsfMTqB0+FhhyqpMjKiG ilfK/NCNG6t59I8gs214oyQB8PAB5AuLAkYq2tXWinMkMcUWYwlJqOekq3SJkaxeJib3FwWVhYni /N8KTdQArJqnUOYU+k3NIsEMlZHJHNSvN5iSra1lXdc2J3q45AKi6g2Pd4Q0nlLRx0sqQyrMryBZ PhPPDfNSNtz1Bse5GKfelzp4zXwinqpSjMxc7HN9okFxYi+0G3UHm+L9pNp8tl/iMMDVETs0skYC s6uoAcKfXlrDoeVOJacxlSYa0jiuj8QOWZfmzaWzapnRolq5InRZWXcWUX2sLgcC4vyGUFeCww7W 5DTZjpmopJ6qcz7QVroW8mrD7GAYMBZhtCPuFwSqEjk47fEmjyqTR9RRu8QWNhWQM4Ee+qQ70Zrf pIAtu6NyOCTivJm75Vpql8mRpKfa608iyhJAOGZNttruvxfCCAy3IIN7XmJus4+WAqpneaVeZ5xD l+ZLHPXUYFNOz7Cs5VQd9lNlLIQTtsLgEcGw7Mjd5K6N2VkVUjmVWHBUixAa/JuD16Ei+K9U1cVV rennWmoisnDTQuGSVGG5CFJ3RkNcbLWUkEXHAtFHPZE8tnZFjJi+AAsG+IGxPYgEj0J74p1KvGi7 MppY4MxkoI3Z1ikL0rs3wsNxIXjtZvb6YBglqKYQXJpoKKpkYGzG4dQx59QQbfX1wqkMUVZTOGCj zFRWYfoLOzJe3H7wv3+eG8vdxlkrxSXkvUHYeN0ZO8Rn0uUaw/xHEqCjUtSSVUFREjxRQbjFYm+2 ICw+dtp98FSVNVl+bJmrM4iemhWUqQf1AAMR0I2kHn+7hykqmrcwp0jjsknwqSvxNG6Na5A5s3Pc W4wnUdR5unZPLMUE8dLSooNjtKIioSfQk7bnj4iO2DRQZlRSgeow3U00FRsZ1tJGdySKSHQ9irDk e+Hl59MGBz2x1HNDhBC861xaczTBVo0h4may0+VgqJkz6hUAeVVvtqVH+GUfq/8AMD9caNpvxj0d mLJTV9RNk9S1gI8wTYpPykF1+5IxiYAJwToskex0VlPVSLj2xSaRHymFrbjJ/wDo2e0WP08l6ooq ykq4FmpamGeNhdXikDKR8iMdFwTbvjyTFBLl4aqyWony+rT4o3ppWjG8ci6jgi/YjHpbw01FTaq0 XRZzCV3TRgVCd4pQLOhHyN/qCD3woLg7K5XNcx7czDzlWO4wLjAwD0wyZJGAcZ94j+JtPpTUcWTR ZLUZjUGATy+XOsYiViwX9XUna30tivv441ZFo9GTA/48wS38hhM4mBPgU2WNSBzIHutgUf6tgMbY xabxqz9ltBpehjbsZa9jb7Kn/PEVmHixr+qRkhbJaBW6PFSvK6/d32/+3BJ2afzmllg1cPGfSVvq 8LxjkzXNcsyyn87M8wpKKMdXqJ1jX3YjHm/MtR6yzMEZhrDM3VuClMUplI9LRqMRDZfSyVLT1CGp mI/4tQ7SP7tc/bDBtR2gjn9lW6vQb/aeQ+sei23PfGfR1KHiyt6rOplNttFAdgN+8jWX7i+KNqbx W1lm5MWWRUmQ0x4uv/aKgj/xMAo+w49TipCygBVUAdABYDAJv6YkUSfnd4W/PFVOxn/hsc7/AG8k zUQGrrzX5jU1GYVbdairlMjj6E8AfIAYeHQXNz9cBQD6YUe3TFzWNaIaIWR9R7zLjKFxcdOvrhyN bkGw2juThAtu5sBjoiW0e5bMzXAT0Fv1N8ubD7+mG5JR2q1aYz/LtD6Trc9zuomFMSkUcESh5JGJ DWQdzYetgCe5xkLeJuo9R6wlrauBKSlm+OmpY7N5EYPG6/LMeCSbemFfiAzXNZcny/LsrgMjJEZZ WQAgbm22CgcCyAC33vjHdDaomm8T6PRVTTyJUZj5kVNMrElZAu4q67QQpAPNztPXjnHBxb6lSoWt 0C930TQoUMMyo9slw14L0rR59XT0wFTGjRCMMAyKCfnwB6Y48xpciziAGuUR1G0+VUsLlNxv1PPX tiOpr/w+OSoliKoqs/AUJyegI5+p6nr0tirV2vdO/n48irczhFTK4SKOoKJJKA/DgFhYAdP9DGWH TxXQ/icYIhWqsNTlFfR6dzugoVkdgsFaEDCeMgBTEgvuAO0FeouO3OOujrUotcVGVGSn8lYwglZw CpKFlZVHIBuALfMXxG5gINYZbQ6ZmzxKSqo6sVeQVytYCZVYNTyHraRdwU/FZ1U7WtY13UE8ea+I zVdHDIrFUFOoKftQEcE7SASQQD1txjW0jLIXHr0nNqwf9Wq6eiZqxJlPnuyM24M5AO29wSNy3562 xHZoIqnOWSkrJVgSNBJTqDG5kbi5RlZWvawv16X5w54WVivntNFJM9JVZmu6kh2ARVNtwcBtp2n9 JHPFjcdsV/PapKjNM1q6SN0zaJSjl0cqrKeUdOCrCw3JYNZmILg7jdo1YyPiuuxaLKKtZZIzV0Ke btaEAtCtujeV8Bt24sR6dhF0VIE1I8VGymBFDbyrMUcgbg1xd0NvkR/eNsdsdZTZq8C1KXWpiEoW V973K23G/wCogqQSvUgm174ay2r/AC+3ZE/lAhAs7MDcngIQRa5HqL+l8KRaSpBJsFMJQQ/nkp4a cij3BmVGVwH7OvPHF1YchupsenacwnoszenSoaxcv5bWAYjkAmzAdLMpI3LYrtdQcVx81p489p57 oZYkB2zMFeTggsGsLsL2INuP247TXfmFrZp1o4Iaml8t/wAwWW12Cssh/ba4+KxIFz2BEtKHJ7VO bltOZjl0ldUqFklo5mqk+PL0dbxrJtt5qblssgvddyk3VS1arMzU5S9MtbJGkscceaZc7JUNHOqf BVQEXVjYi7CzAqTZrkGGzrNVyLM2amzR6ykKWRZ4YmE3CgBZBckDi4PUkcg3xXJXjgoajbEGp0Qm MByzFOoCt2IHT6W5xJcSkDQF0ZHVqc5aGpkjWclk3xJsWV05VgALK1hyAACelr2xp2Vq1RSU80ci xyQpIylRy6uOb8X67bfQYynSpEMDsJXMkZEkEzD4lI5G7j/pa+NV0vMklBLEFLeTVo8LAfFsY2At fnlitvTacK3VWHSy7jKZaMKY7X2MFDFeQLgfPgk39UXtfC44JopVkhqNm0K/mKAWYgfFYdGNhfbf nb6k46aZPzUTSBRujs6qyFdqoTfjubADpzzhmppfyCmWlj3xDbLsRNwIuLkXPFidwP8Ad39bYcpN U3Uxy0VU8LQJG1O3mRCF7gRsFay36qwYEW+Q45w1nB8ygM8ytEGSSmdRco8dt29T+0pvvYj9w682 6fNkeBWE0bLAm2NXXlowegP7gvQqbGwv2w9R1No6mnlgleOqAglgYgtEyk7Oe9gWXk3sw62wIUQo t6YMdebe2CH298KBHHT3x1l5oI1A+Xtgft7e2CuL9vfAA4HT3xEIKK5tia8OtXVWh8/aqJaXJ66Q HMacLcxnp5yD1H7h3A7mxEOOPT3wDYtbgg8EXwr6YcO1PQrGk6dRuOK9TZXW0mYZfDW0VTFUU8yh o5YmDK49QcdB6HpjzR4fatzXQ1aWoI2rcpmYvU5dvsUJ6yRG3wt6r0Py6j0DpLUOU6lyaLNMnq0q KeUW4/VG3dXXqrDuDjOCQcrhB/NF0gWubmYZHpzWJ+PalPF+e4Hx5XTleOu15r/5jFV5IF7Xxf8A 8T9FJBq7I86ZP+zVNPJQM46LJu3oCfVhut/4Tigmxta1vri2gfhLeBPnf3WTGNio1/EDyt7IuSB/ TBWPp/LCgRYf1wVx/o4uWO2yH1t98GvJPT2wdgR9/XAUfEf64EQUkj5D2wCD6D2wbfb3wLi3b3wK USjjt7YAB44HtgwR8vfCuOOnvgQjA+Lt7YcpwWcIS209Qvp6+nphrjd298ORuQNq2set+/1xMIRZ pR0rZjQytHNURQnyZhGu4LckrJ6kA/CT0BI+WLHmNfpvLqOKoo8oooqtIvKaZIAZALcjeRwDfpfE TA0TUwpp2ZoJRumCvwAei8dT3t6kX6Yy7Xuf5lpbNjDncarT1AL0D7maKoi3GzB2tyDwwPNxjl4t rqZzDQr1PROIZVpim8wW6do+yvE8GX1FDMfLUCU7fgW1ib9+2PNXiX4Gak1Trd5tLGGpmkmUXncI CQBax+XA+2NSyjxGo62ErGrSmJ9jsqkKvHK3A6kfyxatFary+lronRjGicMwcIqfLnte/wA8Y2kS F2nNDgTqFXpfCjUOk9AU1TqrUk82d0I85mMtxA8ZBUh+G3IQLN1vziY0zSVNdqOXM6qFFpZKkclg AkrgSpewAXlgBIOeALHpjh8UdevquSpo5axctyjz9lZVzTBJJjtJZE3c/EQATboxv0xV/E3XdNDp +HL6GrMFfLAGhpY2LxUtuY23i25gECgsDxYm/GFljXEjRX0ujMbjnUqNJhk7wcoFt+C2UaoyvT9N WyrW0s2fQQWcRMvkxAyNE529d69HdQeG4vxiq1mamp1MNSBD+bqY1WqSaQkumyMLvKk3Q2UBwTte MEfEbt5soVr86zfzGM7VdTLucnczHj4WRRyDawJ+RHQ41l6AZDlqw0+pajL5jErRUjbZUIkjR2Dq eVBYfK1hzcYhmKnUWC9Di/0LSpNY1lcmq/QFpM8flkgdpEDc7q+1jQz0Kmme3kyNPCsqgbgx+NDb hWVxcsODuJ4viMqa9I0kjYBkmjO+OSxKX6bh3X0IvYgYgNI6uq6rLpvzcdPIIJfJM1OzKPMA7JzY nnobWGHa3MY3djskZwTYKwI+wUkjFzXioMzdF4rpHo3EdG4h2HxEZhwIP3HeAnqSvlqX8upnpJyp JY1CNvUWN+Qbjjuet8OZrmWXQUxjioWqTGQzQDMGkiVVW1yGUMqktYrbn5DEM01TMdiuyve9o+oN +p6AfXn7Yj54VhjCR7mJYi0SbVB5vbr9yeTziwWXPJlLYmqqxKPKiF7AKLKF5NgOthci/fntbCcw SGnpHVE/tmCnavKML8Gx6gHj5XOOzLXVaYyMJDxYmJf08dL/APW2OXN5VklKQ7iGDK7MLb7qeR26 +mAmEC67tNu0ZgKKDESHMYB3KhH6lPWytbg9gb98alpeiCU9OI3ARoliue3IspPoSQAeo22xk2lr zVkdPb4wEkUDhZdwa/0seSPn3xsmiooxTRO0jiOwUsGuky8gBrDryef8IOBoTbKytEikyCRopkaz sgG6RCQ1wD1F/Q44M3aqiRWgjDLu/SnJYcq9mF+f8OJBqlhTyRoVlPk7t242e/BJ68Hg3HfERU1d XNI10ESCzmSAm7IRfcQTYkEcmwNjhiolRdHWS0RYVBEtIsiq0xUF1QkqokP77MbBu6k35Ax0SsrZ pJC8SKyHyJmXl77V2OR0dNuwbhz09DbjSWaesUnerSxstlsENmF+nY3RgPU8YcoKlHoVWA2gjQxb QLEKQSR3F1PS/ZhhUdqMc+mB7YIfb2wYHPb2x2F5cIwL+mFftHTCALHt7YMdB09sCaUftgfuHTCf b2wP3Dp7YEiUeg6dcKyeqzPI82GZ6fr3oKs8SbQGjqB/dkjPDD59R2PTDfYdPbBr+odPbCvY1why enVfTdLTCvNd4kZdqjS1VpnXeXLRPVLtjzGnUtSq45SRuS8dmA/vfUYz7LakmR6GeSGSppgA8kMi vHOOnmRsvBU9fvjqHXsfqMNw01PFIZIoIo3b9TKgVm+pHXFTaTmvzNdbtWqpiWVKRa5sO2I0lPDo OmABf0wABZeR7YBFvTGlZLIEgC3GDUgntgj07e2DXr29sEIMhE3Ttgft7YJ+nb2wXbt7YghAKP2w odumEoL+ntg+46e2CEJdrHtg0A/0cJPXt7YNOnb2w0IS0IZuQvBHw24x0moM0EkE6RTxysGkSVBI rnm1w1x3xyJcci17+mFA2Pb2xEA6qQSNEjN8g0pnOWtR1+mcrkZwQZooFp5Va3DLJGFYHte/T1xl movDWiyhJKuXNc0GW00bPMIAhkm2gG5bb0tcdO2NXDn2t2xU/G/OHyvwwr44gzTZg0dJEqxhyWY7 jwe21W6Yx4jDsaxzxaF6HoB9XF9I0MG4SHvaDxib+AledvNhzjOJqmCiZImdoqOCQM6xluAik/E5 6cm5OOilyuqmqWoqOklmqDGSh8k73QG1iT0At9uMbdkGm9OZPpyhqRp1KzNqOhWeCn2FXhLi53fF Y3beQ1iSAOL4hdY641Pns6adoMlhy2OkjdfJip0eaclPMPO0ggixHexHcY4tXBlrZc7Xhcr7/hel a78QaGGothoIzvcGi24aJcWwIBgDUA7qq0FNBpClWtqZ4J83qAEp44zcwL3JY8XF16YiMkNVXZ/I 1SWrVpormlJ3GUc3VVHJ6cnqOuK8lNW5rmcgqqyTzY5iPJe/awKqo73t7YvHh/HLRV8dTTRRNFSu 6fmQ4QrIfiJQjlrEck8i5GMTKfWOAGgWnF9IHovBVMTiHA1XanQcAACbNGwmZJOpVgymipYqAGAR U6zLuIUbI9xta3JKnYVHPcHCjBsJTg2F3LSXAH2I98dEtfSo63EEbPc7iO/W9vT/ADxz1clLUlVm rUZbX8sg8i/oOMdZgDWwF8K6QxlXF4h1V5Jnj684AXHVVSohhpf7Vuu5bbI/5/F9ecHTUqoQ7uJZ LWF3Nj1v9Th6epy6BQwqVW3AUR2H15H88RtfXzyqfKEcUZHxEn4yPW445w5MCywC5Ss5zCaJvJjR ZSOGJS9rdhewJxwRyCWUVEJIlhO+QWIJXjcNvNuDf7enOFwxQiK1PUzRsoJsT5g68mxJv/yw9RQx SVIctuaM33rDsCg9gwbj14GEndPEWU9o2leasWR1EcqujBiCp8wEDv2PHS+Nd0kixUC1MZXabpLE eFDgeh/Sebc9bX74z/R8VQpSl/Lbo+CkTKjA+tt3Ptcc9Bi45NU17ymOKhtKq7BIk3wHi+yRGBvc cc36A34xa1KdFYyaaODyiqpGpLQsTsZSLH/w35I5/wCeILP6t6SllnpthdJ1bahIeMg2DAWuvBt7 cm+OjO6mBlhqXQxwTqySwyKQg6glgvIU35+ht0xAZlFSQlRsDRufLMgn3GNbcbWA+g+IgfS/MlR2 pyapRsqnljIE1M/mo6IV8tgLEWHY+n26kYbqHV6mrjhm/spgrmMkgElCQVPa3HPcXHbCamvomnRK lUoqg7SG8p13Fha6lvXkbSefnjkqqqFamOGOVC6J/wB4g233L8NvQ7u3AO04Q2UyrEvXt74O4v29 8GpHoMD2x2F5cSiuL9vfABFh098H7YMdB0wKEjj5e+DFtw5/ng/bA/cOmJhCIkf6ODH6h098DsOm FfuHTBCEQtft74McgW/zwB17YXH26dcSp0RA8D+uC446e+FenTA9OmJhEouo7e+Attx6e+DvYdB1 wB+o9MSoSbi/b3wTfb3wr2wG/SOmIKkJKkW7e+FAdOnvgJzxxhQI46YgBSiPJ7e+DXj098HcA9sB SD6YZRKAI+XX1wARu7e+DXp264Mfq7YEShcWPTr644sxyyDMMzy+qqQJI8vd5kiYBkMhACsQQeVu SCOhx3dj064NTwOmILQ4QVowmLq4WsK1Iw6CJ7CC0x2wTfbVM6lqq1qGZsv8uKo8lxAxj3hpAgKM B+2wVvTqcGZKmm2z5bS0iSx1CzIJV+EgKB0sbEW4I9Ld8P2s3X0HB64K9vr9cR1YXQZ03XpsYGNE t89NdJ03neFjnijpGryrPDmb1DO+ZMJXqaKPy23BfiW5va5HNrcc+uIyhnjOXGOzRRRDbcptQf8A lsCel+f+uNvzahpc0yyXL61bwyA2YD4oz/eGMU1tkmZ5HnRocwDeVIx/LyqPgkXsyG3P3vY449XC 9S4xoV2q3T2K6UDTiHyW7aR3Bckhkdw+8jfYLuUdAL/bCmdQpiPJY33Ak2++GE3KpRmdR3IJ9bk+ h7dPTDqght1yVbghvTFPNZ7nRJK3IRLFuxBAOGHpWd7zkEDobC4PexPF/bHS8O8X8okLyQLC/Ha3 OGtl77SFW3LMb9vmOvyxMwohKggpFUlpWW3F1j5uelwo5+uJnIaS48/+y2RgsJdgDKO56A4i6EOs gAkCgi/wgE8fXEzQMQyqKZpxbgNMsZv8zfj7YCmarPRtGKVQKmpUkXvTKX3AdipH+dsd+W1EYKVM dQJBe0bAC5J7dbr3FjcX474iqG5pyVpJlcn4YY65iotxfcAeD2ufrjqSSSWM75Py8rAq0VQg3MLc kMync33t88O02SEKc/OpEY18xOSWTzUNmH6S1xwGA4PPItfHLW00VOWgp4paN5ozITGNyysCOe9u LfEoIA6gWBwhZo4YYnhp5YJIgXk/MKFjl3gbm3btlza3B5t2wVVW+WVngjZZYgoaHeAvycWJCt6d CR64ZQm6t5pBEaujWKQRussTICrWIO8XJsQSSR8r8jkV/URks0K0+1/OVZ0BLqAAV3LboD8OOytz UGqn2wR0k7AMyAk73BsSwLEEFSeRbtiJzaX83XK6EK0cu51P91hyPn+kdcI42UhaQnPp7YPv29sA AfIYMAX6j3x2oXl52Rd+3tgx0HT2wOL9R74AI46e+JRCKx9B7YPadw4HthVx8vfBE/EP64FCFuB0 9sDuOntg7iw/rgAjcOnvgQgoJPb2wtRYA8dfTBLa/b3wdxYdPfEwhDsOntgvTp7YAIsOnvgccdPf EoQPTt7YNevb2wRIt298H9PTAhEft7YJug6e2Fd8JJH+jgQgvA7e2DHbp7YJSLdvfB+mBCMk37e2 AhNu3tgcXwpLW7YEIL07dfTBjg9vbAW1u3X1wVxft74mEJQNwenX0wa9B09sEpFj06+uFKRYdPfE oQJN+3X0wAb36e2CJF+3X1wYIuenvgQj/d2xL0eUUeqdEZlk9dQJU/k28+FmAupYG4U9Qfhvf7dM RFxzyPfFo8LJz/FMwoSwVail33HX4SL2+xxViG5qZWnBuy129q8+Z9pV6RZZcvk86JVLiFxaWFT2 ZR1H+ICxxF0YpxEV3RgG3FxdG+Z9Max4p5ClPm5rKVpY5I32rJGx3CTqQCLDi9j24xmWeVcgqGXM qeEysDaUIFDDtcjv6449jYr0TmFsObompKdAiqosoIsCvNuLnn7++GGp4jMvmAFCCtyLhrjp/lhd JXxk7NhdUUHbe7qD/rjC6mojEG5LNH0VgOb+h7g4QtjRQHA2K5qqmNKJDArEKBfyxZxb0+WOjL6i mh2yNCfh7NL8IP1HXDMdYYHRzdluADuFwSOvP3wiqFNA8EtOTFFUMVMka/8ACPXn6k4QmNVaBOit 1BLShlcLl8Tn4rjh7+u4ckfU4lozUTRbg0dTHfeybbIvBsAG/Sep+ED/AJGDyN43kETDexFyqneH +e23B6/XFjGU0kiCQ0cYKoCGIC37dLi/v74dqQiVzQSfk5vKkMQlc7SpR1ZiRc/EqkHrfaBzzjjr UWpkampaOtBF1DiBUjB62QA773v6D5YlaVkpozDTpK3mcM0UMoT5gWFz72wiunmLmNUaMr8TAII2 jAHJNzcA/wCIj5XxZKQiFS80qkeqhojJLLNGCD5z3PPa4JsOOtz3x0rS1MJiM8EjK63LqjEelgx6 npjvSoovNaMWlQHaBEiqS1jdmN+flc26YczCmF1naCmSSSNdqvKZJ5LC/wC0ABQOe3fCEWQFeVIP pgAXPbBKLHBgW9PbHcK8xEo7c9sADgdMDv29sAdB09sQjKUftgcbh0wX2GB+4cDDKIKM9OgwP3Dp gieBwPbAUXI6e2BQlJ16DCuw6YSo57e2D7Dp7YEIx0HTBW6cDAX9vT2wq/Tge2BCSRx0GFJ+rt0w CeOg9sEv6j09sCEo9e2G269sG3Hp7YIi/p7YEIL07YX6dMIUcdvbB+nT2wISz17YC9O2Enr26+mD At6dPTDISl6duuAOT2wS9O3X0wYFj29sCEYFgenXBjoOmC7Hp19MBeg6e2BCUevbrgHv0wk9e3X0 wYF79PbAhH69Md2mK0ZfqKkqi21PMEcpH9xvhPte/wBscFuvT2wToSGC2DHofniSMwhSHZSHDZW3 xEoKeWMU+wKUuHdQbm5/Tf07k4xjXdBDUQtC8LNIRfpyV7WB6DG5ZqWzHJcvrLfDPChdQbEkjsPq CecZZ4h0Qhq2dLuFcAtYhSW9D3AtjgVW5XEL11B2ZgWH59TTUNSI5QwVLlJAf7QE9jbt6f8APCaT P44mMdbKqj9s3FmHo1uo+eL9nGTw1u/zFTzCLAfTvftjMNYZQKSaRCjKGJLAXAP26YqzOCd1JsKw CWORz+VdSXFwjHg/NG7/AE+eExPMszQAkRsCXUgXUgcG31wPw96cg1Fm9bQ5g0q0FLTmc+SwV1cs FTaebck+2LXn2j84yKr80wrmlAhOyshS0kY6f2qDkehIuv0xb1bnMzRZZutYyp1ea6YyKSrMKMhW ZFFgrKPgPa1+x9ORfti45XPEIFjbzJZlsVVFA2fXd8PtijZFVI8MkIj3xbwoA4Zeep6j5j1++LXk 85mYLbz+AAvkK209+eo9jhRA0VkzqpOqkepY7s0CsCLRLOHcfLy0G2/3viAzenp5keSsqZ/IXlYZ 5CiFvUheWPyJxYqiWFqUebVNZwP+zQ2AQ/4itiPvbEBnMqs7D8kIuweyFQP5Mfpc/TEykOqiqaOk ljKQUqqDa7LHa3pYk9Tbn5Xw3V1NNBTiGlRlsC08zy73l+vovYLhuqdSSjVLSxhdttlmYWuQD0VO 5P8APEPnsu2kZBwZeNyiwt9O3+vXCOKkC91//9k= --Apple-Mail=_C41F0392-D320-44D4-AD2A-E41289F90BC6-- --Apple-Mail=_27EFF9DD-FAAA-424A-B6AA-3B9D82132CD8-- From nobody Thu Jul 24 09:49:38 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 874071A04B0 for ; Thu, 24 Jul 2014 09:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.665 X-Spam-Level: X-Spam-Status: No, score=-1.665 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8i7W8ad9Wbi for ; Thu, 24 Jul 2014 09:49:35 -0700 (PDT) Received: from homiemail-a36.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 0B6BE1A04CA for ; Thu, 24 Jul 2014 09:49:35 -0700 (PDT) Received: from homiemail-a36.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTP id D4EDD778061; Thu, 24 Jul 2014 09:49:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=gbiv.com; bh=v1SnF3lfqlhS5GRti7rF1mT1+3o=; b=F Lm9L2yVszFoE141fH7wvGkIL4aRMNQmFqCpswkDyENa+I9aSrvSPCsEUgR29LpDH N9f1ntyrraDaJyF4Pb7/SCUKF2dNuoYdlszV3Od5im2L3dKFv3Rwd2KTjwkP9UKq lVyjOkv+rFIg4nEYrh8rGLIUqi5h/Rzz7ea1oVubmY= Received: from [192.168.1.5] (ip68-228-83-124.oc.oc.cox.net [68.228.83.124]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTPSA id 7EF9C77805F; Thu, 24 Jul 2014 09:49:34 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_99D4F95B-6DD1-49C0-9BEE-A36462ADF344" From: "Roy T. Fielding" In-Reply-To: <3DD81803-39CF-42D7-AB71-CC3813E7EDAB@gmail.com> Date: Thu, 24 Jul 2014 09:49:34 -0700 Message-Id: References: <3DD81803-39CF-42D7-AB71-CC3813E7EDAB@gmail.com> To: Yoav Nir X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/D3Nrj1HIKyvgGsQ5qJTKPNiFseE Cc: IETF HTTP Auth Subject: Re: [http-auth] Modifications to Basic & Digest X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 16:49:37 -0000 --Apple-Mail=_99D4F95B-6DD1-49C0-9BEE-A36462ADF344 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jul 24, 2014, at 8:24 AM, Yoav Nir wrote: > Hi >=20 > A question we raised at the HTTP-Auth meeting today was whether or not = we=92d like to make any changes to Basic and Digest. >=20 > The charter requires us to add to things to these protocols: > Adding internationalization support for user names and passwords > Adding modern hash functions to Digest so that an implementation does = not depend on MD5. >=20 > There are a few additional extensions proposed. The Digest draft = includes optional username hashing, which (when used) will prevent the = cleartext username from being sent on the wire. This sounds (to me) to = be a good idea privacy-wise, but there is a claim that Basic and Digest = are so horribly broken anyway, that we don=92t want to add security = features to them, even if said security features seem like a good idea = (hence the =93lipstick on a pig=94 comment I made at the session [1]). Yeah, that's what they said in 1994. Look how well that worked out. > So the question I=92m asking the group here is, do we want to tinker = with Basic and Digest, potentially making them somewhat better, or do we = want to clamp down on all such discussion, and stick only to the = mandates in the charter? Basic could be easily extended by optionally replacing the cleartext credentials with a prefix and one-time hash, where the prefix indicates how to compute the hash. It makes no difference to the wire protocol other than a server indication that it implements the extension. This is essentially how OTP works in Basic, though OTP relies on users knowing how to generate the "hash" each time. Digest could be easily extended so that the hash-of-hashed password form doesn't require the server to maintain session state. Neither improvement achieves perfect security, but they would help. ....Roy --Apple-Mail=_99D4F95B-6DD1-49C0-9BEE-A36462ADF344 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hi

A question we raised at the = HTTP-Auth meeting today was whether or not we=92d like to make any = changes to Basic and Digest.

The charter = requires us to add to things to these protocols:
  1. Adding internationalization support for user = names and passwords
  2. Adding modern hash functions to Digest so = that an implementation does not depend on = MD5.

There are a few additional = extensions proposed. The Digest draft includes optional username = hashing, which (when used) will prevent the cleartext username from = being sent on the wire. This sounds (to me) to be a good idea = privacy-wise, but there is a claim that Basic and Digest are so horribly = broken anyway, that we don=92t want to add security features to them, = even if said security features seem like a good idea (hence the = =93lipstick on a pig=94 comment I made at the session = [1]).

Yeah, that's what they said = in 1994.  Look how well that worked out.

So the question I=92m = asking the group here is, do we want to tinker with Basic and Digest, = potentially making them somewhat better, or do we want to clamp down on = all such discussion, and stick only to the mandates in the = charter?

Basic could be easily = extended by optionally replacing the cleartext
credentials = with a prefix and one-time hash, where the prefix = indicates
how to compute the hash.  It makes no = difference to the wire protocol
other than a server indication = that it implements the extension.
This is essentially how OTP = works in Basic, though OTP relies on users
knowing how to = generate the "hash" each time.

Digest could be = easily extended so that the hash-of-hashed password = form
doesn't require the server to maintain session = state.

Neither improvement achieves perfect = security, but they would = help.

....Roy

= --Apple-Mail=_99D4F95B-6DD1-49C0-9BEE-A36462ADF344-- From nobody Thu Jul 24 15:25:13 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 757E51A01E8 for ; Thu, 24 Jul 2014 15:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Q8CTF0qVhgk for ; Thu, 24 Jul 2014 15:25:07 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id D52121A0503 for ; Thu, 24 Jul 2014 15:25:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C386EBE7B; Thu, 24 Jul 2014 23:25:05 +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 uoV8OVI0s40B; Thu, 24 Jul 2014 23:25:04 +0100 (IST) Received: from [31.133.188.75] (dhcp-bc4b.meeting.ietf.org [31.133.188.75]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 06AF4BE79; Thu, 24 Jul 2014 23:25:03 +0100 (IST) Message-ID: <53D187BD.40803@cs.tcd.ie> Date: Thu, 24 Jul 2014 23:25:01 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Yoav Nir , IETF HTTP Auth References: <3DD81803-39CF-42D7-AB71-CC3813E7EDAB@gmail.com> In-Reply-To: <3DD81803-39CF-42D7-AB71-CC3813E7EDAB@gmail.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/fy1YJF6Gv2k4UGZYg-8SqYj1z48 Subject: Re: [http-auth] Modifications to Basic & Digest X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 22:25:10 -0000 I'd also be interested in whether or not these changes might impact on the liklihood of the updated versions being implemented. I don't know if they would or not, and of course we can't know for sure, but it'd be interesting to know something about that if its knowable. That is, if commenting on these, it'd be useful to say if you're an implementer and would implement 'em. S. On 24/07/14 16:24, Yoav Nir wrote: > Hi > > A question we raised at the HTTP-Auth meeting today was whether or not we’d like > to make any changes to Basic and Digest. > > The charter requires us to add to things to these protocols: > > 1. Adding internationalization support for user names and passwords > 2. Adding modern hash functions to Digest so that an implementation does not > depend on MD5. > > > There are a few additional extensions proposed. The Digest draft includes > optional username hashing, which (when used) will prevent the cleartext username > from being sent on the wire. This sounds (to me) to be a good idea privacy-wise, > but there is a claim that Basic and Digest are so horribly broken anyway, that > we don’t want to add security features to them, even if said security features > seem like a good idea (hence the “lipstick on a pig” comment I made at the > session [1]). > > So the question I’m asking the group here is, do we want to tinker with Basic > and Digest, potentially making them somewhat better, or do we want to clamp down > on all such discussion, and stick only to the mandates in the charter? > > Yoav > > [1] > lipstick_pig_080910_mn1.jpg > > > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > From nobody Thu Jul 24 19:37:11 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C177B1A03FE for ; Thu, 24 Jul 2014 19:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5bGKmcazOOP7 for ; Thu, 24 Jul 2014 19:37:07 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85BDF1A046A for ; Thu, 24 Jul 2014 19:37:06 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id e16so2630201lan.3 for ; Thu, 24 Jul 2014 19:37:04 -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=5f7xGG8DzTqdX6Qdtwa+PDn3+IHoaly1N9GDV243ICk=; b=KHaire0VI08rWd7tY5tVC1RdtSj8kd+Owg7mL/SmTQINF4iDoC49E56aGHkTlTTam3 jmPZeYB9oen3EAPpGciUGtolswRPLdQRz76Ui2BQQ2SlJnbZu30DK0RGMErnC4FK1nZ6 +imSFoBF6zpRYZz13d/bCnKG07hpVHGRwnVsplsx3kKx+L/21c5+Wo8AzKwSSwkt8zyY JqP00bQCQCt/08FTDROcPzdPI252qri+/E5p/SB4pXQi8lFXxk65Y2NBUtuCG0z9dMAZ takruVEc6UDKny73EhwO5/OMiLE+21t75AkiHR/EFNsdalmQts7krMOISip5N/0GAQgU xJew== MIME-Version: 1.0 X-Received: by 10.112.202.39 with SMTP id kf7mr12658947lbc.37.1406255824851; Thu, 24 Jul 2014 19:37:04 -0700 (PDT) Received: by 10.114.2.34 with HTTP; Thu, 24 Jul 2014 19:37:04 -0700 (PDT) In-Reply-To: References: <3DD81803-39CF-42D7-AB71-CC3813E7EDAB@gmail.com> Date: Thu, 24 Jul 2014 22:37:04 -0400 Message-ID: From: Rifaat Shekh-Yusef To: "Roy T. Fielding" Content-Type: multipart/alternative; boundary=001a11c37746e759f704fefb7279 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/Zx0CEkBjvtTKBFurxTr4L9_7sqg Cc: IETF HTTP Auth Subject: Re: [http-auth] Modifications to Basic & Digest X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 02:37:10 -0000 --001a11c37746e759f704fefb7279 Content-Type: text/plain; charset=ISO-8859-1 Thanks Roy, > Digest could be easily extended so that the hash-of-hashed password form > doesn't require the server to maintain session state. > > I am not clear on what you mean by "hash-of-hashed password form..."; can you please elaborate? The current recommendation in the draft calls for the following operation to protect the username: H(username:realm) as defined in section 3.4.4. Regards, Rifaat On Thu, Jul 24, 2014 at 12:49 PM, Roy T. Fielding wrote: > On Jul 24, 2014, at 8:24 AM, Yoav Nir wrote: > > Hi > > A question we raised at the HTTP-Auth meeting today was whether or not > we'd like to make any changes to Basic and Digest. > > The charter requires us to add to things to these protocols: > > 1. Adding internationalization support for user names and passwords > 2. Adding modern hash functions to Digest so that an implementation > does not depend on MD5. > > > There are a few additional extensions proposed. The Digest draft includes > optional username hashing, which (when used) will prevent the cleartext > username from being sent on the wire. This sounds (to me) to be a good idea > privacy-wise, but there is a claim that Basic and Digest are so horribly > broken anyway, that we don't want to add security features to them, even if > said security features seem like a good idea (hence the "lipstick on a pig" > comment I made at the session [1]). > > > Yeah, that's what they said in 1994. Look how well that worked out. > > So the question I'm asking the group here is, do we want to tinker with > Basic and Digest, potentially making them somewhat better, or do we want to > clamp down on all such discussion, and stick only to the mandates in the > charter? > > > Basic could be easily extended by optionally replacing the cleartext > credentials with a prefix and one-time hash, where the prefix indicates > how to compute the hash. It makes no difference to the wire protocol > other than a server indication that it implements the extension. > This is essentially how OTP works in Basic, though OTP relies on users > knowing how to generate the "hash" each time. > > Digest could be easily extended so that the hash-of-hashed password form > doesn't require the server to maintain session state. > > Neither improvement achieves perfect security, but they would help. > > ....Roy > > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > > --001a11c37746e759f704fefb7279 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks Roy,


Digest could be easily extended so that the hash-of-has= hed password form
doesn't require the server to maintain sess= ion state.


I am not clear on what you mean by &qu= ot;hash-of-hashed password form..."; can you please elaborate?
The current recommendation in the draft calls for = the following operation to protect the username: H(username:realm) as defin= ed in section 3.4.4.

Regar= ds,
 Rifaat



On Thu, Jul 24, 2014 = at 12:49 PM, Roy T. Fielding <fielding@gbiv.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex">
On Jul 24, 20= 14, at 8:24 AM, Yoav Nir wrote:

Hi

A question we raised at t= he HTTP-Auth meeting today was whether or not we’d like to make any c= hanges to Basic and Digest.

The charter requires us to add to things to these proto= cols:
  1. Adding internationalization support for user names = and passwords
  2. Adding modern hash functions to Digest so that an imp= lementation does not depend on MD5.

There are a few additional extensions propos= ed. The Digest draft includes optional username hashing, which (when used) = will prevent the cleartext username from being sent on the wire. This sound= s (to me) to be a good idea privacy-wise, but there is a claim that Basic a= nd Digest are so horribly broken anyway, that we don’t want to add se= curity features to them, even if said security features seem like a good id= ea (hence the “lipstick on a pig” comment I made at the session= [1]).

Yeah, that's what they said in = 1994.  Look how well that worked out.

So the que= stion I’m asking the group here is, do we want to tinker with Basic a= nd Digest, potentially making them somewhat better, or do we want to clamp = down on all such discussion, and stick only to the mandates in the charter?=

Basic could be easily extended by o= ptionally replacing the cleartext
credentials with a prefix = and one-time hash, where the prefix indicates
how to compute the&= nbsp;hash.  It makes no difference to the wire protocol
other than a server indication that it implements the extension.
=
This is essentially how OTP works in Basic, though OTP relies on users=
knowing how to generate the "hash" each time.

Digest could be easily extended so that the hash-of-has= hed password form
doesn't require the server to maintain sess= ion state.

Neither improvement achieves perfect se= curity, but they would help.

....Roy
<= div>

_____________________________________= __________
http-auth mailing list
http-auth@ietf.org
https://www.ietf.org/mailman/listinfo/http-auth


--001a11c37746e759f704fefb7279-- From nobody Fri Jul 25 09:29:27 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DCAE1B2935 for ; Fri, 25 Jul 2014 09:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yjVf_70kPkKS for ; Fri, 25 Jul 2014 09:29:25 -0700 (PDT) Received: from sentinelchicken.org (laim.sentinelchicken.org [96.126.98.9]) by ietfa.amsl.com (Postfix) with SMTP id 4E3D81A035E for ; Fri, 25 Jul 2014 09:29:25 -0700 (PDT) Received: (qmail 11832 invoked from network); 25 Jul 2014 16:29:24 -0000 Received: from unknown (HELO pascal.sentinelchicken.org) (10.81.64.2) by lelantos.sentinelchicken.org with SMTP; 25 Jul 2014 16:29:24 -0000 Received: (qmail 18458 invoked from network); 25 Jul 2014 16:29:19 -0000 Received: from unknown (HELO shannon.sentinelchicken.org) (10.81.64.4) by pascal.sentinelchicken.org with SMTP; 25 Jul 2014 16:29:18 -0000 Received: (nullmailer pid 21682 invoked by uid 1000); Fri, 25 Jul 2014 16:29:14 -0000 Date: Fri, 25 Jul 2014 09:29:14 -0700 From: Tim To: Stephen Farrell Message-ID: <20140725162914.GC1043@sentinelchicken.org> References: <3DD81803-39CF-42D7-AB71-CC3813E7EDAB@gmail.com> <53D187BD.40803@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53D187BD.40803@cs.tcd.ie> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/yy_gdOZ8IJYb6Sf8jjwOWbTdlEQ Cc: IETF HTTP Auth Subject: Re: [http-auth] Modifications to Basic & Digest X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 16:29:26 -0000 > I don't know if they would or not, and of course we can't know for > sure, but it'd be interesting to know something about that if its > knowable. That is, if commenting on these, it'd be useful to say if > you're an implementer and would implement 'em. In the case of Digest auth, I'd just be happy if major browsers actually implemented it consistently. There have been issues in the past with lack of clarity in the original RFC that created incompatibilities. That and some browsers don't bother to implement significant chunks of the protocol. Perhaps just more clarifications to the RFC on how it should work would be in order. As far as extending Digest further, I think it actually has some flexibility to be extended through the opaque value that is included in the hash. One could plausibly put all kinds of ciphertext in there to pass useful information around between clients, servers and even third-party servers (think SSO). So if Digest were just implemented consistently, one could imagine more advanced extensions that don't break RFC compliance... tim PS- Everything I just said is based on fuzzy memories of when i delved into this over a year ago, so I may be off on some details. From nobody Fri Jul 25 10:31:22 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF3D91A03CA for ; Fri, 25 Jul 2014 10:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iqKaEFyYs-qg for ; Fri, 25 Jul 2014 10:31:18 -0700 (PDT) Received: from posteo.de (mx02.posteo.de [89.146.194.165]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93AAA1A03AD for ; Fri, 25 Jul 2014 10:31:18 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.posteo.de (Postfix) with ESMTP id DE7E625A2118; Fri, 25 Jul 2014 19:31:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at posteo.de Received: from posteo.de ([10.125.125.178]) (using TLS) by localhost (amavis1.posteo.de [10.125.125.165]) (amavisd-new, port 10026) with ESMTPS id sAJhB1CBNOoY; Fri, 25 Jul 2014 19:31:11 +0200 (CEST) Received: from mail.posteo.de (localhost [127.0.0.1]) by mail.posteo.de (Postfix) with ESMTPSA id 787A02C04E7; Fri, 25 Jul 2014 19:31:09 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sophie Bremer In-Reply-To: <53D187BD.40803@cs.tcd.ie> Date: Fri, 25 Jul 2014 19:31:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3DD81803-39CF-42D7-AB71-CC3813E7EDAB@gmail.com> <53D187BD.40803@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/NVKM9BJLsZ_unULd5J1FrHi9aoI Cc: IETF HTTP Auth Subject: Re: [http-auth] Modifications to Basic & Digest X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 17:31:21 -0000 Hello, we already use Digest with username hashing in two apps for iOS and OS X = since February. And we like to implement it in the browser front end by = next year. We use username hashing to protect email addresses in case of = TLS blocking by a great firewall. If we implement it in all applications and browser front ends, it will = impact about a million users. Best regards, Sophie On 25 Jul 2014, at 00:25, Stephen Farrell = wrote: >=20 > I'd also be interested in whether or not these changes might impact > on the liklihood of the updated versions being implemented. >=20 > I don't know if they would or not, and of course we can't know for > sure, but it'd be interesting to know something about that if its > knowable. That is, if commenting on these, it'd be useful to say if > you're an implementer and would implement 'em. >=20 > S. >=20 > On 24/07/14 16:24, Yoav Nir wrote: >> Hi >>=20 >> A question we raised at the HTTP-Auth meeting today was whether or = not we=92d like=20 >> to make any changes to Basic and Digest. >>=20 >> The charter requires us to add to things to these protocols: >>=20 >> 1. Adding internationalization support for user names and passwords >> 2. Adding modern hash functions to Digest so that an implementation = does not >> depend on MD5. >>=20 >>=20 >> There are a few additional extensions proposed. The Digest draft = includes=20 >> optional username hashing, which (when used) will prevent the = cleartext username=20 >> from being sent on the wire. This sounds (to me) to be a good idea = privacy-wise,=20 >> but there is a claim that Basic and Digest are so horribly broken = anyway, that=20 >> we don=92t want to add security features to them, even if said = security features=20 >> seem like a good idea (hence the =93lipstick on a pig=94 comment I = made at the=20 >> session [1]). >>=20 >> So the question I=92m asking the group here is, do we want to tinker = with Basic=20 >> and Digest, potentially making them somewhat better, or do we want to = clamp down=20 >> on all such discussion, and stick only to the mandates in the = charter? >>=20 >> Yoav >>=20 >> [1] >> lipstick_pig_080910_mn1.jpg >>=20 >>=20 >>=20 >> _______________________________________________ >> http-auth mailing list >> http-auth@ietf.org >> https://www.ietf.org/mailman/listinfo/http-auth >>=20 >=20 > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth From nobody Fri Jul 25 11:56:20 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D2431A024F for ; Fri, 25 Jul 2014 11:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8Qz2AsLsQlq for ; Fri, 25 Jul 2014 11:56:17 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id CC8AF1A0362 for ; Fri, 25 Jul 2014 11:56:17 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id 7D8CE438079; Fri, 25 Jul 2014 11:56:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=a3PnwGi7pQ0ni+jnHFIirQ8qckk=; b=vGIgE0saL8T+d9gr7SlVvQuM1aIJ 8YXOxG/wiKEhj8Bf8LFgismRNnqgG0mktra9DStXcXd43MAgge2VJmgULPzZlvyZ 6D4aAMoildozPrf7XhRCsAYO/vShUKQS+3HCVpm8xtxqk3hKym3A+3u4kODff/9e gKIRw/J2TLMwc6A= Received: from [192.168.1.5] (ip68-228-83-124.oc.oc.cox.net [68.228.83.124]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPSA id 604F5438072; Fri, 25 Jul 2014 11:56:17 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: "Roy T. Fielding" In-Reply-To: Date: Fri, 25 Jul 2014 11:56:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3DD81803-39CF-42D7-AB71-CC3813E7EDAB@gmail.com> To: Rifaat Shekh-Yusef X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/AsGzwc8pKgdTLi_qRMxknRNPDw0 Cc: IETF HTTP Auth Subject: Re: [http-auth] Modifications to Basic & Digest X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 18:56:18 -0000 On Jul 24, 2014, at 7:37 PM, Rifaat Shekh-Yusef wrote: >> Digest could be easily extended so that the hash-of-hashed password = form >> doesn't require the server to maintain session state. >>=20 >=20 > I am not clear on what you mean by "hash-of-hashed password form..."; = can you please elaborate? Never mind -- I misremembered how A1 is calculated in both cases. I would prefer to have a version of A1 that allows the client to provide a salted hashed origin-unique password to the server. However, on = second thought, this might be better done with an extension that is independent of the authentication scheme, since the result is just another opaque password string, or with a new authentication scheme. ....Roy From nobody Sun Jul 27 18:39:14 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3275F1B27EB for ; Sun, 27 Jul 2014 18:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YM4g8zMyHOgz for ; Sun, 27 Jul 2014 18:39:08 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A350F1B27DA for ; Sun, 27 Jul 2014 18:39:08 -0700 (PDT) Received: from [192.168.1.55] (unknown [118.209.32.55]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5406E22E255; Sun, 27 Jul 2014 21:38:58 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Mark Nottingham In-Reply-To: <53CC62AF.6040305@digitalbazaar.com> Date: Mon, 28 Jul 2014 11:38:54 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <66027EA8-520D-4530-AC1E-E53FA8109E4C@mnot.net> References: <536BFA23.9020900@digitalbazaar.com> <44475C73-A79F-4C54-A09D-A9842FD49CA2@mnot.net> <53CC62AF.6040305@digitalbazaar.com> To: Manu Sporny X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/vV8c6X_vC75HR5B6ZXKt2c1TqsE Cc: "Julian F. Reschke" , IETF HTTP Auth , Web Payments CG Subject: Re: [http-auth] Review Request for third draft of "Signing HTTP Messages" X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 01:39:11 -0000 Hi Manu, This looks really good. A couple of comments below. On 21 Jul 2014, at 10:45 am, Manu Sporny = wrote: >>=20 >> * Section 2.3. - How is whitespace around field-values handled =97 is=20= >> it included in the value or not? Note that as per=20 >> = , >> it isn=92t (but it would be good if you made this explicit, both in >> spec and with examples) >=20 > Whitespace around field values is not included. The spec now refers to > the appropriate section in draft-ietf-httpbis-p1-messaging-26: >=20 > = https://github.com/web-payments/web-payments.org/commit/2e00f1a30dc99e80b1= 8deebb30f4d4b03d4b4a75 Is this straight concatenation, or with a comma? E.g., if you have Cache-Control: max-age=3D60 Cache-Control: must-revalidate Would the canonicalised string be: Cache-Control: max-age=3D60must-revalidate or Cache-Control: max-age=3D60,must-revalidate or...? While your text isn't ambiguous really, people are very used to = concatenate-delimit-with-comma (plus some whitespace, usually), and it = might be good to point out what you mean (even if with an example). >> * Section 2.3 - Request-line is HTTP/1 specific, and =97 again =97 = the=20 >> HTTP version is a hop-by-hop attribute of the message, so you=92re=20 >> going to get signature failures through intermediaries. Suggestion:=20= >> use HTTP/2=92s :method, :authority and :path pseudo-headers. >=20 > Are you asking me to: >=20 > 1) Change the name `(request-line)` to something else like > `(request-target)`? > 2) Specify that the header field value should be constructed by > concatenating the lowercased :method, an ASCII space, > the :authority, an ASCII space, and :path pseudo-headers? >=20 > I'm assuming that you think that :scheme shouldn't be included because > it'll break when proxied internally between https->http? Speaking = about > proxies, isn't using :authority going to break the signature from > hop-to-hop? Is it worth specifying that servers sitting behind a proxy > should use the X-Forwarded-Host or Forwarded-Host headers as a > replacement for :authority when recreating the signature? Now I'm > wondering if there is an attack that allows an attacker to inject both > X-Forwarded-Host and Forwarded-Host that would result in a compromised > signature. >=20 > I made both changes above, let me know if that's not what you wanted. >=20 > = https://github.com/web-payments/web-payments.org/commit/495584b09f88acd439= 734fcfa9f9826bf40173c3 I meant mostly (2).=20 What I'd suggest is to actually use the :-prefix that http/2 specifies, = because it can't be part of a valid http header field-name. The method = isn't part of the request-target, so that would leave you with these = "special" header field names: :method :uri For :uri, I'd refer to the Effective Request URI in RFC7230 Section 5.5; = that's the concept you're looking to hook onto, I think, and it should = be stable between HTTP versions. >> * Can trailers be included in a signature? >=20 > In theory, yes. We've got another spec in the works about how to do = this > (although it's horribly out of date and we don't know if we're going = to > finish it any time soon... not much demand for it as far as we can = tell): >=20 > https://web-payments.org/specs/source/http-signature-trailers/ >=20 > I imagine that if/when we do, we'll require something like this = header: >=20 > Signature: location=3Dtrailer >=20 > and then have the actual signature in the trailers. Cool. Note that the Trailer header = already allows this; = e.g. you'd have: Trailer: Signature to indicate that Signature is coming in the trailers. >> * Can a Signature header be included in the message trailers? >=20 > In theory, yes. We need to spec exactly how this would work. The = feature > was deemed low-priority and out of scope for the base Signing HTTP > Messages spec. OK.=20 >> * You talk (often implicitly) about how a signature is created, but=20= >> not what constitutes a valid signature. This is going to be=20 >> especially important for the authentication scheme. >=20 > I tried to clarify by adding two sections. The first specifies how a > signature is created, and the second specifies how a signature is = verified: >=20 > = https://github.com/web-payments/web-payments.org/commit/d535b92c05f676c040= c3e4efd417bd2e5b68ef68 >=20 > ... but don't know if that's what you were looking for. That looks like a good start. Cheers, -- Mark Nottingham https://www.mnot.net/