From nobody Mon Jul 6 01:35:27 2015 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 604D11A908E; Mon, 6 Jul 2015 01:35:23 -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 wpCpJgCzNR16; Mon, 6 Jul 2015 01:35:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 891331A90C7; Mon, 6 Jul 2015 01:35:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150706083518.7221.53348.idtracker@ietfa.amsl.com> Date: Mon, 06 Jul 2015 01:35:18 -0700 Archived-At: Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-mutual-05.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: Mon, 06 Jul 2015 08:35:23 -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 Authors : Yutaka Oiwa Hajime Watanabe Hiromitsu Takagi Kaoru Maeda Tatsuya Hayashi Yuichi Ioku Filename : draft-ietf-httpauth-mutual-05.txt Pages : 56 Date : 2015-07-06 Abstract: This document specifies a mutual authentication method for the Hyper- text Transfer Protocol (HTTP). This method provides a true mutual authentication between an HTTP client and an HTTP server using password-based authentication. Unlike the Basic and Digest authentication methods, the Mutual authentication method specified in this document assures the user that the server truly knows the user's encrypted password. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-mutual/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-httpauth-mutual-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-mutual-05 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 Mon Jul 6 01:35:38 2015 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 0C5981A90FD; Mon, 6 Jul 2015 01:35:28 -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 U_b72n_vBU6r; Mon, 6 Jul 2015 01:35:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9121E1A90E2; Mon, 6 Jul 2015 01:35:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150706083525.7254.31530.idtracker@ietfa.amsl.com> Date: Mon, 06 Jul 2015 01:35:25 -0700 Archived-At: Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-mutual-algo-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: Mon, 06 Jul 2015 08:35:28 -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-03.txt Pages : 16 Date : 2015-07-06 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: https://tools.ietf.org/html/draft-ietf-httpauth-mutual-algo-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-mutual-algo-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 Mon Jul 6 01:35:42 2015 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 668891A90DA; Mon, 6 Jul 2015 01:35:37 -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 6d9P6N_IGHLp; Mon, 6 Jul 2015 01:35:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D78671A9100; Mon, 6 Jul 2015 01:35:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150706083531.7241.12198.idtracker@ietfa.amsl.com> Date: Mon, 06 Jul 2015 01:35:31 -0700 Archived-At: Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-extension-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: Mon, 06 Jul 2015 08:35:37 -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 : HTTP Authentication Extensions for Interactive Clients Authors : Yutaka Oiwa Hajime Watanabe Hiromitsu Takagi Tatsuya Hayashi Yuichi Ioku Filename : draft-ietf-httpauth-extension-04.txt Pages : 26 Date : 2015-07-06 Abstract: This document specifies a few extensions of HTTP authentication framework for interactive clients. Recently, fundamental features of HTTP-level authentication is not enough for complex requirements of various Web-based applications. This makes these applications to implement their own authentication frameworks using HTML Forms and other means, which becomes one of the hurdles against introducing secure authentication mechanisms handled jointly by servers and user- agent clients. The extended framework fills gaps between Web application requirements and HTTP authentication provisions to solve the above problems, while maintaining compatibility against existing Web and non-Web uses of HTTP authentications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-extension/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-httpauth-extension-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-extension-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 Wed Jul 8 08:40:17 2015 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 96E431A00B4 for ; Wed, 8 Jul 2015 08:40:15 -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 RIm-opE7IUE4 for ; Wed, 8 Jul 2015 08:40:14 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C70DB1A0076 for ; Wed, 8 Jul 2015 08:40:10 -0700 (PDT) Received: by wibdq8 with SMTP id dq8so216710555wib.1 for ; Wed, 08 Jul 2015 08:40:09 -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=8YdNd7K2pnkCMW2NkbDC4SJXGZIa6AAi+qtxkjdp0IM=; b=B+fSuvJiQhO4h6/nFfqp0pYw7PKbCBv2HMmLDcgu+yjbPlPD/WHoFiM7CufceFiBeO Q0yL4FI1IgtGaoGAQTnrOkfHY1gmfqCNU6zc68sEg7ekTJoVtFxE+sTwacpwbnHbcVj8 WpOXJx5N+KZgpeM4JnsAbwy/0B4A1FHEebsmk6jazn+x7xQ6sN8nISANCjcjNz6y0nDw AJTy0GGUyd36E+CiRhF/2POD+Amu3MYJjHNx8KWHr44i6ShVX3i1II45iyOe3KzQbRXx bAzgB8YEE9vQAgd9hmDY9XjaUXsc0ixQN3kVFFjeIDuvpVpyt0Hjh234g4aDgzVZfsJE bOUg== X-Received: by 10.194.77.144 with SMTP id s16mr21255450wjw.145.1436370009538; Wed, 08 Jul 2015 08:40:09 -0700 (PDT) Received: from [172.24.250.202] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id um5sm4099760wjc.1.2015.07.08.08.40.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 Jul 2015 08:40:08 -0700 (PDT) From: Yoav Nir Content-Type: multipart/alternative; boundary="Apple-Mail=_A07A807F-1BD1-4315-9BF9-C3CCC26E9D22" Message-Id: Date: Wed, 8 Jul 2015 18:40:06 +0300 To: httpauth mailing list Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) X-Mailer: Apple Mail (2.2102) Archived-At: Subject: [http-auth] Agenda for Prague 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, 08 Jul 2015 15:40:15 -0000 --Apple-Mail=_A07A807F-1BD1-4315-9BF9-C3CCC26E9D22 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Just uploaded See you all there. Yoav https://www.ietf.org/proceedings/93/agenda/agenda-93-httpauth = --Apple-Mail=_A07A807F-1BD1-4315-9BF9-C3CCC26E9D22 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Just uploaded

See you all there.

Yoav


--Apple-Mail=_A07A807F-1BD1-4315-9BF9-C3CCC26E9D22-- From nobody Mon Jul 20 01:32:41 2015 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 6AAF41A1A38 for ; Mon, 20 Jul 2015 01:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_ABOUTYOU=0.5, RCVD_IN_DNSWL_NONE=-0.0001, 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 scF3r-mQc9Kh for ; Mon, 20 Jul 2015 01:32:39 -0700 (PDT) Received: from APAC01-HK1-obe.outbound.protection.outlook.com (mail-hk1on0057.outbound.protection.outlook.com [134.170.140.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2166C1A09CF for ; Mon, 20 Jul 2015 01:32:38 -0700 (PDT) Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none; Received: from [31.133.177.67] (31.133.177.67) by TY1PR01MB0207.jpnprd01.prod.outlook.com (10.161.135.142) with Microsoft SMTP Server (TLS) id 15.1.219.17; Mon, 20 Jul 2015 08:32:33 +0000 Message-ID: <55ACB208.6000208@aist.go.jp> Date: Mon, 20 Jul 2015 17:32:08 +0900 From: Yutaka OIWA User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Rifaat Shekh-Yusef , "http-auth@ietf.org" References: <20150531154835.3639.52041.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [31.133.177.67] X-ClientProxiedBy: BLUPR01CA038.prod.exchangelabs.com (25.160.23.28) To TY1PR01MB0207.jpnprd01.prod.outlook.com (25.161.135.142) X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0207; 2:4t9O/s/KbqOqr75dM2uc3fWfElAIOTB5VTV9fLBoL7nCsfGuzDAQWPbfQgnbsxGA; 3:4wzl3DNzfAQRGvx7nU2OIu5AASP/hPizK+JEBeE2EkUfVBrupgWmo7pfqRxln1QywmCAOenrwXSd4PvWJ/0FBqywYzCzQPxkkNqaoPhBhNo0DrS9OYNjIV4JASzpJJJHcDDaGmo39RxII1XmF/BVvw==; 25:NnxkUNZ5qlrq0/6L7cf+UtOMfcX+yEjBFOlqVx5YN1zqpAslimYV3OU0pAq5jlEOBoAuh3bNWbPhTYqZQ1qi2LOj2r0tA7kY+HJL5/rc0n82lK3c61LAx9ruXwz+yedMMBQDSWR/ax4+CBoeorW7bsN1kGVl4Uq+E1Wyx8z8AZpWpXNB4vorH7OUr6Yku7c4uhaM1bqjlkw43OvsACEkeG8m1dkvwoAZdDE1QocE5IP9pC8sIOhzGxLO7pcbagiXLrchP4EokVuslxmfudC2oQ== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:TY1PR01MB0207; X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0207; 20:+lDX6y+aYesz4sL4htI9ZUFSNbUYUwtsivAgfwYeOEN6iruSa613wFSZ8hg2ixUwHlfcTJrvf/JoZ/Drtao85A4WPjeDAIXJI6LSjocz/DtAJWlkyjLuCJ99R8gey0CTH83gZGSkz1VETMw9w5UzfaydZF2PIw5lSlE4rG9gzrvhiq4s6oromGxfAQNi/VIk4MOa6f3TGS85WmZiC24t/Sp1j05UNy62p10zwHHy+loEXt7/0hhhXm0ucu2kQOlwnxA7bMmoveF6CPIJ4aAzVRtAoS+Xpe1Js4oIjnMQ7ySHMPnY3KsquFtF/FiI2/gMQZyzatA/sYYXmDUcgLJxASqHLw7a57kp/YNiwAGJ5Ak19cLVU12JSOPMvzDtp5Pf9/yq8q+aay7blQjv/GAR80fqAXRhmD6HZfuRGcYf0295rWSTYnnG/X/RUebJpsVucHTfsbA696aBmgF8dtpVMGBjirPKZoytKY/t8MN5i8dwZ1paKPhtOPPqO3BCDVNX1/0ybx6JWk0defBN6xac22pJZVdjUw9TvgJlJKIZlqI7I0qbNjazrM9z4+AgYKfU7fQsUSHnqlYZhBr2KXt/nz9SP4gqUacPFF8DR1Y2GUM=; 4:tJYWJDVuk75Fzzf2DtXkgTWvaTiqGw5NJI9QZnd5UHkKgMP37NP+dZmJq8lvwBceVaUzbk2bdSD6WLD9EOPqIIdosw2XVvyJX2zCqUxSjCsR+YzawY8yGEBcyL0xr7OZgJkpVnTN/C/YjergtdH8QO4aTigyewnnA9JjqD9D72i/EF4wgMh4zzJT8tA6CycDd26n1GoH4UTzu7SaaB7PicRRBZ562Rktnr9kpDbiV7zwSpy8YqY33giOafLtP2z4hULTt4T3EHMyxUbJ4/yZqQ== TY1PR01MB0207: X-MS-Exchange-Organization-RulesExecuted X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(5005006)(3002001); SRVR:TY1PR01MB0207; BCL:0; PCL:0; RULEID:; SRVR:TY1PR01MB0207; X-Forefront-PRVS: 0643BDA83C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6009001)(6049001)(479174004)(377454003)(24454002)(2473001)(377424004)(74482002)(80316001)(4001350100001)(42186005)(59896002)(561944003)(19580405001)(33656002)(2501003)(19580395003)(64126003)(230783001)(86362001)(5001960100002)(189998001)(54356999)(92566002)(46102003)(50986999)(551544002)(23746002)(87976001)(83506001)(122386002)(87266999)(107886002)(2950100001)(15975445007)(77156002)(40100003)(77096005)(65816999)(76176999)(65956001)(65806001)(62966003)(5001920100001)(47776003)(50466002)(5001770100001)(36756003)(66066001)(7099028)(3940600001); DIR:OUT; SFP:1101; SCL:1; SRVR:TY1PR01MB0207; H:[31.133.177.67]; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; TY1PR01MB0207; 23:wazjqK4ncThdhVNq2yrGQiwm5ZnORvflmalJu?= =?Windows-1252?Q?MosMQzMwpRh6lbxzZqOHtCJ1nYXGcNzs6ncyEo7juVf8jTLpchDj14y3?= =?Windows-1252?Q?iELztmTiS8IC3+tetgabsD9+LhAfnuEehjriY/dBhlXbkj60TfUjIOdN?= =?Windows-1252?Q?3pfW/XfhlOYf7wXiych/JDOsllcViqcrV4DWyD+ImlETguLYQ463OJI2?= =?Windows-1252?Q?BovRbSywyBD/ZvX1F7YljjoPKFcjVYYsoTmmqfdEANGyZjdEigg1gRc6?= =?Windows-1252?Q?LWJZ+WawUkhs8ruyj3BjES4cKJFVMG9EBqR7xUpp9jenxBXNmcq2fimo?= =?Windows-1252?Q?FZTgNZx2ZjRVJOxAMTnjQjrYshoqmSZoAVvf32aRdKUa3lpdEQHlZHpp?= =?Windows-1252?Q?FNQmMzrBkgAc0I37iIA+ZdPUcBVforgFNRPAA0f5OxCOrSGsLPHOHdWO?= =?Windows-1252?Q?r9/qmdec+JFxrJI0/qwQeqUJIGOp+vXH+42pQqGoqSrPWAcEkhcJ9w1M?= =?Windows-1252?Q?eAx3MStUOnII2vTmb8Toj1lC8nM2QCwBe3/Xw1Ef3eoyv51JDPuaVH5Y?= =?Windows-1252?Q?chzzdfyV9mur9zSnh+huGc4Tt1NktJNK+z4JblD+Q8F82OXtR5YzLVBa?= =?Windows-1252?Q?ELgFhVZHZbqI08M5u0Nv1UGXvU+uIohy73HSWa7H7KXOGqbaTV+pnEMV?= =?Windows-1252?Q?NKoVcMdGDv+TinkLpLiP8BbRuy25o+6tvFKtxGiiIQlp2qmOLvWdY4Fv?= =?Windows-1252?Q?NKOOepu/J6OJjmwRMxg6tfdlg73m+Bn278iRh72lJHM1VMI3pclZNNbV?= =?Windows-1252?Q?GkReMs+7AZZN9EwEo0gHmI3hyL8C3txxS+czUJoRubZAchjiQPizsvUH?= =?Windows-1252?Q?ECDc5YKz7wdCXt1seCTezbZmD/t0jJ2eR4AK/LmXCHC84btiup14t8kZ?= =?Windows-1252?Q?DAI5LqzCe9OEXvcrhmzweOGNfCQahCEpN3l+vR+fabr3TyU83KFt0x77?= =?Windows-1252?Q?6GW+7eGZ5VZV5yALlHn726zdsyWd6hsEBco2FKRExgWRboRpuwSd95t2?= =?Windows-1252?Q?HSUW9XpmQ/OkOQlf6SfkjPW6q16F7WDoUXHxuPgYbJPj47WJmUgEKDHC?= =?Windows-1252?Q?SqgvobyTn9RyZ9IK7jUd7ptwQdCFGKbGmiAhZaWRbWiA+b3GkOWyXoWR?= =?Windows-1252?Q?fv+ltJah/QFXGar7FVwM92qlUC/FrALkA/5XBAmrDOrdOIXVAQxiLBBp?= =?Windows-1252?Q?5szQQpsb0fcfqTHx1wki0KBEFc9jvdsaUwWJw9d/5jCW0V3h5yoYwr2B?= =?Windows-1252?Q?xNmq5+ef/O14pyH4VzDMYaQ40tcj2ckvnE5Vk10AELNhnY3PfGbbJpXT?= =?Windows-1252?Q?U2xhySTGQw7fofT+FCkiSHfayU8Sbwli6PgREzwlbzDbzJfMWOIDeU?= =?Windows-1252?Q?=3D?= X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0207; 5:Tvq1hIyFbfTMtYMLkVmflpnrll9d4atIzMhy6DSVdD+THN+Oco3wMQxoGWg2rZcLf7R3evymAbH7Tf8II7ysrf0hcgtF0SiVDS65K8yEQw5888UQGr8UO8TX4/xHIZPWuvkcaCKXwehnh+uN+6gIww==; 24:QofL/7LuK3T9wgF83vCI7htx+WPyK04ke7W4cfw/hKDN+EHsC4wOR/mlDk1BNPVGqoe9BIzZxP1zR1KshtIKiKDEkFyCNsUCV8lAqMUOjx4=; 20:t9q//hsv84oQ143kLhfMk2/vC2Sk+wRAy8klXdikJ3RZ8HGluSXwFYYWLycSkap4jMMbwYSu+SGUTFKUEKHRAg== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: aist.go.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jul 2015 08:32:33.9490 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY1PR01MB0207 Archived-At: Subject: Re: [http-auth] Fwd: New Version Notification for draft-yusef-httpauth-srp-scheme-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, 20 Jul 2015 08:32:40 -0000 Dear Rifaat, I'm happy on seeing some interest on using strong PAKE-based cryptography on HTTP authentication, but I also have several questions/concerns about your current proposal. I'll first express my general questions and suggestions, followed by my technical reviews and suggestions in a separate email. Could you tell us why do you think this proposal is needed? Is there any specific request for this technology in this form, or is it just a general motivation for PAKE to be used in HTTP? I have been designing Mutual auth as a general framework for augmented PAKE-based HTTP authentication, and implemented several mechanisms to let it working effectively. For example, the session key caching and replay-preventing nonce-counter is a key mechanism to avoid heavy public-key cryptographic operations in every request-response pair. If you have no specific reasons for implementing SRP in that specific form, I recommend to try writing it as an additional authentication algorithm for the Mutual scheme. It will avoid re-inventing many required wheels for effective use of heavy PAKE mechanisms which your draft currently lacks. # After finishing (significant portion of) my own work for Mutual auth, # I could possibly be able to volunteer writing SRP-based auth algorithm # for Mutual scheme, to find out whether it will work successfully or not. Also, I have to mention that we've submitted our drafts first to httpbis WG in 2012 as a chairs' requirement for including it as chartered discussion candidates. That's how the current HTTPAUTH WG was formed with current candidates. I'm little bit surprised to see this proposal on this time period. If we've seen it long before, I could be working more on considering your specific requirements merged into Mutual proposal. # I also have asked several times for comments on the choice of # PAKE variants for basic Mutual uses, without any strong # suggestions for changing it from the current form. Regards, Yutaka On 2015/06/01 0:53, Rifaat Shekh-Yusef wrote: > Hi, > > Yaron and I have just submitted a draft that defines a new authentication > scheme based on the SRP protocol, to be used with the HTTP Authentication > Framework. > We would appreciate any thoughts, reviews, and feedback on this document. > > Regards, > Rifaat > > > > > ---------- Forwarded message ---------- > From: > Date: Sun, May 31, 2015 at 11:48 AM > Subject: New Version Notification for draft-yusef-httpauth-srp-scheme-00.txt > To: Rifaat Shekh-Yusef , Yaron Sheffer < > yaronf.ietf@gmail.com> > > > > A new version of I-D, draft-yusef-httpauth-srp-scheme-00.txt > has been successfully submitted by Rifaat Shekh-Yusef and posted to the > IETF repository. > > Name: draft-yusef-httpauth-srp-scheme > Revision: 00 > Title: HTTP Secure Remote Password (SRP) Authentication Scheme > Document date: 2015-05-31 > Group: Individual Submission > Pages: 11 > URL: > https://www.ietf.org/internet-drafts/draft-yusef-httpauth-srp-scheme-00.txt > Status: > https://datatracker.ietf.org/doc/draft-yusef-httpauth-srp-scheme/ > Htmlized: > https://tools.ietf.org/html/draft-yusef-httpauth-srp-scheme-00 > > > Abstract: > This document defines an HTTP Authentication Scheme that is based on > the Secure Remote Password (SRP) protocol. The SRP protocol is an > Augmented Password Authenticated Key Exchange (PAKE) protocol > suitable for authenticating users and exchanging keys over an > untrusted network. > > > > > 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. > > The IETF Secretariat > > > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > -- Yutaka OIWA, Ph.D. Cyber Physical Architecture Research Group Information Technology Research Institute 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 Mon Jul 20 01:53:58 2015 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 390C81A1A80 for ; Mon, 20 Jul 2015 01:53:57 -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 g1SDg6k8sKyT for ; Mon, 20 Jul 2015 01:53:54 -0700 (PDT) Received: from APAC01-HK1-obe.outbound.protection.outlook.com (mail-hk1on0097.outbound.protection.outlook.com [134.170.140.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 175011A1A87 for ; Mon, 20 Jul 2015 01:53:54 -0700 (PDT) Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none; Received: from [31.133.177.67] (31.133.177.67) by OS2PR01MB0204.jpnprd01.prod.outlook.com (10.161.78.142) with Microsoft SMTP Server (TLS) id 15.1.213.14; Mon, 20 Jul 2015 08:53:49 +0000 Message-ID: <55ACB70B.1070603@aist.go.jp> Date: Mon, 20 Jul 2015 17:53:31 +0900 From: Yutaka OIWA User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Rifaat Shekh-Yusef , "http-auth@ietf.org" References: <20150531154835.3639.52041.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [31.133.177.67] X-ClientProxiedBy: DM2PR10CA0081.namprd10.prod.outlook.com (10.141.241.49) To OS2PR01MB0204.jpnprd01.prod.outlook.com (25.161.78.142) X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0204; 2:q3ZrpLyhL5VFWE2Mxs1MHRrxBNDHSa0rfBeTZArjKjGyiehHk87HSk9116P5CXAc; 3:gfvCePAiwPa4a+K7fmDL/Koe4pBbDxrJpWZprMbvdv5HdmqSg8+d2q2kay+ooOmvCDyv5KZP1dZzFiYvAZvDRSbFFh0l0cv6gh5WJRekpiEciJADx790NmdgLmJz+EUiE2LjUO50JuTpW9h5JhxbKQ==; 25:Lbbjox2hEdGABli6LzO7a3vI5Dx+oqu3vhLoE8DvH4NM25XcUwgnIvqq0jeZD1wJfgsW5OeYHuqPsLnmCGor0AOYZlVOsl/Rcmecgina6fFqIrXSniQzUj/gok8JExdQRjgXNZGrO4IpnCB4sUodAgu0tvhzIcBZEy/MpHCjtao58X2IuqGSb62tmhM06DOhyq2re8NyHQAGFIl5mM5WPCqA1TuUkZZsXHxf0+g37w6CN9zhHWb/2kbW0Ea8vFiwZHxsKVNHEHjwjxCjZm8R1A== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:OS2PR01MB0204; X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0204; 20:g0QAtDDoV152n/4LODHB3JzOCSK3/9mEPBH3pWyZBFD/swKxxw8r+ZcL/RZUAmQsqWki7itYBw4E75wqQW3LbA7YF7iwco0WnmElnS6IPM7lAgo4FVacNjODjKfiUYm+otNthO7ivnnf9DnYBMRYUuLBvZLc2skIKdjA+hg0QfdqP0qgwWkkohqmzKbJSgQtCQwlFDBsF4GMPn32BAJGv750xrOEoDlacBHD+A29AT86ic6bx0kD4LglDwbrNIcfErq3O3CSvYTwQl+RL/Wg/vJ+1kwJJ+jv42lWTusuI8aELKAI4gWtVNLq37ErCLsfGjNvy+1Eimkyld/l6NGBFuEXyibaVAq51bnQyXrVVg8JoKdF3QE7gKeOQIlZLRrhnf8msZqD5NzhBwywjXV3umP8D07HBC+l6T6WXvrefAEG/0uunSCeMOooWb4KD97r/FVVIVZrFEqj2Nr3gkGFEa46GAuKzVZamcTRWbXz1WMJgVkt2Ssy3knaBIl/3MFxBIyjLFu58SrmfBMBr/tamxWl3yAfWwZmm78vAbKrsoNuZ+qALjMjZmaVqUmdP9jIpOI528jsVDtQeIR+EHGmagmP6OJdGsnh18wZJDQBgyA=; 4:4NBo+rwUAzlGNCSvhWRILV/ID/uHamIPY/L//IW5zcIWnWQGYUE5K0JptYVmOlEohb/dlaIWOycjkNM1OyHyTRU/2ZF4E4/oLIInmADWgGQ5fqw6coU2Yny24mMLwZDNckKDHgWQHxTYisuHmGQm/nLxuvZgL5z/4d4W+PadX7pcHkD0KgXe+I+lhgY+IKHWQTxeTbRwScvXP6MielGkES/xScy7aDlF5WbW64nN8MfrCbHpqNghclBlgOdM0h5GgPMxb8xADTnmMg79WaTwsw== OS2PR01MB0204: X-MS-Exchange-Organization-RulesExecuted X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(5005006)(3002001); SRVR:OS2PR01MB0204; BCL:0; PCL:0; RULEID:; SRVR:OS2PR01MB0204; X-Forefront-PRVS: 0643BDA83C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(979002)(6049001)(6009001)(377424004)(377454003)(479174004)(2473001)(24454002)(65816999)(54356999)(551544002)(59896002)(230783001)(46102003)(19580405001)(19580395003)(2501003)(50466002)(77096005)(23746002)(47776003)(66066001)(65806001)(92566002)(2950100001)(65956001)(86362001)(40100003)(42186005)(15975445007)(64126003)(33656002)(77156002)(74482002)(122386002)(87976001)(4001350100001)(62966003)(5001960100002)(5001770100001)(80316001)(50986999)(76176999)(36756003)(189998001)(5001920100001)(87266999)(83506001)(107886002)(7099028)(3940600001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:OS2PR01MB0204; H:[31.133.177.67]; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; OS2PR01MB0204; 23:YLR55xNRoMTIB8KZgmZW0AThNywYsrq2vcqKg?= =?Windows-1252?Q?glr4h04d3SGuYorJNYS2F89bOLnousnRK0r7MXDCbzqoyJPcC+kv+qyM?= =?Windows-1252?Q?nfjfRKMgT2giWzxQDXh4pVeCSs4KrhxDjn80cjzP5XtwHjtO1GYd3/AT?= =?Windows-1252?Q?W3bIZW0SCuj+0EWu1rvCJHiyVH4uJFzIcaWqExw4bofi/OPWsZh8fESV?= =?Windows-1252?Q?3Roq2o4PGT6/ljV7cTopR8CD9r4ZuxW+PM186blqkwBAfoj+BQnEdkP7?= =?Windows-1252?Q?6nBM1GV1bUwQdmfn4Qwx+CVxLU0Fasr5l4MEF9J7kojq8cjfY8IkUCH5?= =?Windows-1252?Q?6uLUeIXsvOBliNm2+QChUIRWv56C1Bur19oR8cezoxd4/L9zWweMOcd5?= =?Windows-1252?Q?CGZWomVNNYGzwnlSUG27IP/R5tHNi+iPIuUNvOS6fKG3gux8BbsH8TiU?= =?Windows-1252?Q?+MvwzvKS130XVFI6P71hHLMKaO0+zysv0EDHxAxtvnO3BHVsIjMPOYIG?= =?Windows-1252?Q?gdK8qaiK/5fBZSlECjS/5Z6P0L+IFdop2t6pJ0ov6wMEGY6SED6gika2?= =?Windows-1252?Q?khT5F/U2WtqdXygTFh+FbiiQg8Ge1VSXBYpYx+qdh36uZDq+E399krm8?= =?Windows-1252?Q?CBIR7fT01IQ6SuSD6IXDAPmSEoIseXgcy8sVXrlvtPDMspPMC8kFFeK6?= =?Windows-1252?Q?Ain/HmfQfJsVVuNEruXY1Zo7WV/ZhC9iEbUyITRoSgYe3yl/0FNEtEZj?= =?Windows-1252?Q?x41DtT0WpLOdZhGqMzE2PaOWmybgacJnsM6qXEkaXL7jmBnScqgikmIu?= =?Windows-1252?Q?O4GfDF6hKni8EXt8nYN10OH3GBXVBe/Gnm64SH8shB92xYvDqMRje2pq?= =?Windows-1252?Q?r5VcJpTWAVfw520Z7e/9egzUPoLd0J98yUrhYCan/2zJcOJk6F41jcaA?= =?Windows-1252?Q?bW8XwC241tcv3sKSqzVyiIHkP0St/IJ3m+s862vF8cmI8j2YZo9NPiR6?= =?Windows-1252?Q?GwqqERhGVf7OXaCF17v8eqKvuw1pd85IFfv+G1Zz7ueGMZusOMikERaR?= =?Windows-1252?Q?eayi9PuWxhcPoDolOB81wEXn0jZVbKEosdyoBQ/FCgRCeTq8MqZKTZ2S?= =?Windows-1252?Q?vbOYmtHzrjNIGtQXLmgrVExgmw2mN8OGOFOUeGl9ERTR8tG4MZxVtygw?= =?Windows-1252?Q?DkUzYQuVz8EeWMqg4fr2inEgkDBjmFfzyW3sNc/VW90gFyh4flNKzKxA?= =?Windows-1252?Q?exEmhOqoFOPrWKdyHe3kXt/g2gERdoJLblXkT2Y8fa9mVMUWjEjLxrnB?= =?Windows-1252?Q?k5kQgK3uTniEa8BMuv2CvgRo2YGDZN9fMICy2bVXE7xSYItfweFJ4hJn?= =?Windows-1252?Q?cymhA2FiZ2AHDeHdqXL3n12I2pCOZH8VMTT1FD9XoTRX58hP/uMA23aI?= =?Windows-1252?Q?MEsnzHssmtde2uYs4EJuMeTCUEV52Pcp45S+GZm+wP65D/igvSCqKqMz?= =?Windows-1252?Q?Yt7dWQYaRQUIwxtOkrXMeOumErn?= X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0204; 5:s0FOZlSZoYAM+/hgJdhnJJkjAEFvsGxAmW1P/Bjpegfuw7uTjeAnYFrMtOqos+tNKCGmkv7OoIei2UhSPXwUfI/qY/ud+snCf/VNr56If+3t31YgaGPbH+3NV/qovI+aOAgfuWVnjmX3AO9cE1TsZw==; 24:TkvRPx4HQ8BYMws5LtAJluoYuIIghMIgQcS/3tZA6gHfTMjFSftM/II1oMmjSR2gbQCwiKff9HMqFkMbU1zUmjy8mcFC1hJyq+h5J2fNm6s=; 20:aPNg7iXyr2Yw2ez3FyZUj1Q9O4SEtskx3efgeez6OuQlxuzRUyZPm9bCxAsRudI05VcshJgBl7XYukKzNolc5g== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: aist.go.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jul 2015 08:53:49.1286 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: OS2PR01MB0204 Archived-At: Subject: Re: [http-auth] Fwd: New Version Notification for draft-yusef-httpauth-srp-scheme-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, 20 Jul 2015 08:53:57 -0000 Dear HTTPAUTH WG, the following is my technical comments for the submitted draft. 1. The authentication exchange of the HTTP should be carefully reconsidered. It will usually start with unauthenticated request to the server, and the response can contain "realm", without any specific discovery mechanisms. 2. The final response for the successful authentication should use Authentication-Info header instead of WWW-Authenticate, whose spec is under clarification by Julian. It's also better that the normal response codes (200 or 401) is shown in the exchange examples for easier understanding. 3. Please clarify explicitly how the six-message exchange can be shorten on what cases. Especially, avoiding re-computation of "public keys" is critical for any effective use of public-key-based cryptography (including any known PAKE algorithms) on stateless HTTP. It will require introduction of something similar to (next-)nonce in Digest or "sid" in Mutual and SCRAM, along with replay-preventing mechanisms. It should be clarified how replay attacks can be prevented when public keys are reused. 4. There are distinct kinds of responses with different semantics but sharing the same "WWW-Authentication: SRP" header, and so kinds of requests sharing "Authorization: SRP". It should be clarified how each peer will distinguish those kinds of messages (e.g. existence or non-existence of client-pop field). It will be important for handling (or rejection) of malformed messages without any ambiguity (or possible cheating with it). On 2015/06/01 0:53, Rifaat Shekh-Yusef wrote: > Hi, > > Yaron and I have just submitted a draft that defines a new authentication > scheme based on the SRP protocol, to be used with the HTTP Authentication > Framework. > We would appreciate any thoughts, reviews, and feedback on this document. > > Regards, > Rifaat > > > > > ---------- Forwarded message ---------- > From: > Date: Sun, May 31, 2015 at 11:48 AM > Subject: New Version Notification for draft-yusef-httpauth-srp-scheme-00.txt > To: Rifaat Shekh-Yusef , Yaron Sheffer < > yaronf.ietf@gmail.com> > > > > A new version of I-D, draft-yusef-httpauth-srp-scheme-00.txt > has been successfully submitted by Rifaat Shekh-Yusef and posted to the > IETF repository. > > Name: draft-yusef-httpauth-srp-scheme > Revision: 00 > Title: HTTP Secure Remote Password (SRP) Authentication Scheme > Document date: 2015-05-31 > Group: Individual Submission > Pages: 11 > URL: > https://www.ietf.org/internet-drafts/draft-yusef-httpauth-srp-scheme-00.txt > Status: > https://datatracker.ietf.org/doc/draft-yusef-httpauth-srp-scheme/ > Htmlized: > https://tools.ietf.org/html/draft-yusef-httpauth-srp-scheme-00 > > > Abstract: > This document defines an HTTP Authentication Scheme that is based on > the Secure Remote Password (SRP) protocol. The SRP protocol is an > Augmented Password Authenticated Key Exchange (PAKE) protocol > suitable for authenticating users and exchanging keys over an > untrusted network. > > > > > 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. > > The IETF Secretariat > > > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > -- Yutaka OIWA, Ph.D. Planning Officer, Research Planning Office Department of Information Technology and Human Factors 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 Mon Jul 20 04:53:42 2015 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 033F11A21B9 for ; Mon, 20 Jul 2015 04:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 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, GB_ABOUTYOU=0.5, 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 NqVpO3VZ-avG for ; Mon, 20 Jul 2015 04:53:38 -0700 (PDT) Received: from mail-vn0-x22a.google.com (mail-vn0-x22a.google.com [IPv6:2607:f8b0:400c:c0f::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 569761A1B89 for ; Mon, 20 Jul 2015 04:53:38 -0700 (PDT) Received: by vnaa140 with SMTP id a140so21881218vna.2 for ; Mon, 20 Jul 2015 04:53:37 -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=xDQZA7mHtxx65LE6MNwuj7M9+yA+WGPgHPLPcYWUGR0=; b=kDvJ40jCtW/un+2pwIynOTq8l3++MK2hfm4ukGlmJssBNa7LjHdIlxaQS1u0vXbvQA IaAIkpdq57NeXknvnnxIkoaZ07OaMuzU/9M6B7K5iLPlwZ+BwZ/KQqDaAqRVw+i5cAtv PUkY529QG8wf3P/bTCFAY2IE8RrMlEpakkeKA4aH4UWnZKUQZxvhVH31En7MR1Veyy/k V45+qDWlu9nuBqwBFA3lHSMdzLYMW4rHolMkSVtQ1Y97acJyRBKY6snUBqa8hVx6O1Nw WdoBI/8Sx6Ak+FeEpu12nnX6FFjvJ0OrD9ertqbOJAhYNZz0MZEzEshffVDinCPVihT2 Azxg== MIME-Version: 1.0 X-Received: by 10.52.90.4 with SMTP id bs4mr36683453vdb.59.1437393217543; Mon, 20 Jul 2015 04:53:37 -0700 (PDT) Received: by 10.31.53.72 with HTTP; Mon, 20 Jul 2015 04:53:37 -0700 (PDT) In-Reply-To: <55ACB208.6000208@aist.go.jp> References: <20150531154835.3639.52041.idtracker@ietfa.amsl.com> <55ACB208.6000208@aist.go.jp> Date: Mon, 20 Jul 2015 13:53:37 +0200 Message-ID: From: Rifaat Shekh-Yusef To: Yutaka OIWA Content-Type: multipart/alternative; boundary=001a1136ac122263ad051b4d30f2 Archived-At: Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Fwd: New Version Notification for draft-yusef-httpauth-srp-scheme-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, 20 Jul 2015 11:53:41 -0000 --001a1136ac122263ad051b4d30f2 Content-Type: text/plain; charset=UTF-8 Hi Yutaka, Please, see my reply inline... Regards, Rifaat On Mon, Jul 20, 2015 at 10:32 AM, Yutaka OIWA wrote: > Dear Rifaat, > > I'm happy on seeing some interest on using strong PAKE-based > cryptography on HTTP authentication, but I also have several > questions/concerns about your current proposal. > I'll first express my general questions and suggestions, > followed by my technical reviews and suggestions in a separate email. > > > Could you tell us why do you think this proposal is needed? > Is there any specific request for this technology in this form, or > is it just a general motivation for PAKE to be used in HTTP? > > It is a general motivation to use PAKE-based solution not only for HTTP, but also for other protocols, e.g. SIP. > I have been designing Mutual auth as a general framework for > augmented PAKE-based HTTP authentication, and implemented > several mechanisms to let it working effectively. > Unfortunately, I am personally not that familiar with your work. In general, we would like to utilize the *existing *HTTP Framework and add support for SRP on top of that. SRP is a protocol that is already used by other RFCs and it has many implementations out there, and is royalty free. > For example, the session key caching and replay-preventing > nonce-counter is a key mechanism to avoid heavy public-key > cryptographic operations in every request-response pair. > > I am assuming that this is related to the subsequent requests utilizing the session keys. We left this out of this document because we think it is out of scope. Regards, Rifaat > If you have no specific reasons for implementing SRP in that specific form, > I recommend to try writing it as an additional authentication algorithm > for the Mutual scheme. It will avoid re-inventing many required wheels > for effective use of heavy PAKE mechanisms which your draft currently > lacks. > > # After finishing (significant portion of) my own work for Mutual auth, > # I could possibly be able to volunteer writing SRP-based auth algorithm > # for Mutual scheme, to find out whether it will work successfully or not. > > Also, I have to mention that we've submitted our drafts first > to httpbis WG in 2012 as a chairs' requirement for including > it as chartered discussion candidates. That's how the current > HTTPAUTH WG was formed with current candidates. > I'm little bit surprised to see this proposal on this time period. > If we've seen it long before, I could be working more on considering > your specific requirements merged into Mutual proposal. > # I also have asked several times for comments on the choice of > # PAKE variants for basic Mutual uses, without any strong > # suggestions for changing it from the current form. > > > Regards, > > Yutaka > > On 2015/06/01 0:53, Rifaat Shekh-Yusef wrote: > > Hi, > > > > Yaron and I have just submitted a draft that defines a new authentication > > scheme based on the SRP protocol, to be used with the HTTP Authentication > > Framework. > > We would appreciate any thoughts, reviews, and feedback on this document. > > > > Regards, > > Rifaat > > > > > > > > > > ---------- Forwarded message ---------- > > From: > > Date: Sun, May 31, 2015 at 11:48 AM > > Subject: New Version Notification for > draft-yusef-httpauth-srp-scheme-00.txt > > To: Rifaat Shekh-Yusef , Yaron Sheffer < > > yaronf.ietf@gmail.com> > > > > > > > > A new version of I-D, draft-yusef-httpauth-srp-scheme-00.txt > > has been successfully submitted by Rifaat Shekh-Yusef and posted to the > > IETF repository. > > > > Name: draft-yusef-httpauth-srp-scheme > > Revision: 00 > > Title: HTTP Secure Remote Password (SRP) Authentication Scheme > > Document date: 2015-05-31 > > Group: Individual Submission > > Pages: 11 > > URL: > > > https://www.ietf.org/internet-drafts/draft-yusef-httpauth-srp-scheme-00.txt > > Status: > > https://datatracker.ietf.org/doc/draft-yusef-httpauth-srp-scheme/ > > Htmlized: > > https://tools.ietf.org/html/draft-yusef-httpauth-srp-scheme-00 > > > > > > Abstract: > > This document defines an HTTP Authentication Scheme that is based on > > the Secure Remote Password (SRP) protocol. The SRP protocol is an > > Augmented Password Authenticated Key Exchange (PAKE) protocol > > suitable for authenticating users and exchanging keys over an > > untrusted network. > > > > > > > > > > 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. > > > > The IETF Secretariat > > > > > > > > _______________________________________________ > > http-auth mailing list > > http-auth@ietf.org > > https://www.ietf.org/mailman/listinfo/http-auth > > > > -- > Yutaka OIWA, Ph.D. Cyber Physical Architecture Research Group > Information Technology Research Institute > 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] > --001a1136ac122263ad051b4d30f2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Yutaka,

Please, see my reply inline.= ..

Regards,
=C2=A0Rifaat

<= /div>

On Mon, Jul = 20, 2015 at 10:32 AM, Yutaka OIWA <y.oiwa@aist.go.jp> wrote:=
Dear Rifaat,

I'm happy on seeing some interest on using strong PAKE-based
cryptography on HTTP authentication, but I also have several
questions/concerns about your current proposal.
I'll first express my general questions and suggestions,
followed by my technical reviews and suggestions in a separate email.


Could you tell us why do you think this proposal is needed?
Is there any specific request for this technology in this form, or
is it just a general motivation for PAKE to be used in HTTP?


It is a general motivation to use PAKE= -based solution not only for HTTP, but also for other protocols, e.g. SIP.<= /div>

=C2=A0
I have been designing Mutual auth as a general framework for
augmented PAKE-based HTTP authentication, and implemented
several mechanisms to let it working effectively.

=
Unfortunately, I am personally not that familiar with your work.=

In general, we would like to utilize the exist= ing HTTP Framework and add support for SRP on top of that.=C2=A0
<= div>SRP is a protocol that is already used by other RFCs and it has many im= plementations out there, and is royalty free.

=C2= =A0
For example, the session key caching and replay-preventing
nonce-counter is a key mechanism to avoid heavy public-key
cryptographic operations in every request-response pair.


I am assuming that this is related to = the subsequent requests utilizing the session keys.
We left this = out of this document because we think it is out of scope.


Regards,
=C2=A0Rifaat

=
=C2=A0
If you have no specific reasons for implementing SRP in that specific form,=
I recommend to try writing it as an additional authentication algorithm
for the Mutual scheme.=C2=A0 It will avoid re-inventing many required wheel= s
for effective use of heavy PAKE mechanisms which your draft currently lacks= .

# After finishing (significant portion of) my own work for Mutual auth,
# I could possibly be able to volunteer writing SRP-based auth algorithm # for Mutual scheme, to find out whether it will work successfully or not.<= br>
Also, I have to mention that we've submitted our drafts first
to httpbis WG in 2012 as a chairs' requirement for including
it as chartered discussion candidates.=C2=A0 That's how the current
HTTPAUTH WG was formed with current candidates.
I'm little bit surprised to see this proposal on this time period.
If we've seen it long before, I could be working more on considering your specific requirements merged into Mutual proposal.
# I also have asked several times for comments on the choice of
# PAKE variants for basic Mutual uses, without any strong
# suggestions for changing it from the current form.


Regards,

Yutaka

On 2015/06/01 0:53, Rifaat Shekh-Yusef wrote:
> Hi,
>
> Yaron and I have just submitted a draft that defines a new authenticat= ion
> scheme based on the SRP protocol, to be used with the HTTP Authenticat= ion
> Framework.
> We would appreciate any thoughts, reviews, and feedback on this docume= nt.
>
> Regards,
>=C2=A0 Rifaat
>
>
>
>
> ---------- Forwarded message ----------
> From: <internet-drafts@ietf.org>
> Date: Sun, May 31, 2015 at 11:48 AM
> Subject: New Version Notification for draft-yusef-httpauth-srp-scheme-= 00.txt
> To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>, Yaron Sheffer <
> yaronf.ietf@gmail.com>=
>
>
>
> A new version of I-D, draft-yusef-httpauth-srp-scheme-00.txt
> has been successfully submitted by Rifaat Shekh-Yusef and posted to th= e
> IETF repository.
>
> Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-yusef-httpauth-srp= -scheme
> Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
> Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 HTTP Secure Remote Password (= SRP) Authentication Scheme
> Document date:=C2=A0 2015-05-31
> Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
> Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 11
> URL:
> https://www.ietf.org= /internet-drafts/draft-yusef-httpauth-srp-scheme-00.txt
> Status:
> https://datat= racker.ietf.org/doc/draft-yusef-httpauth-srp-scheme/
> Htmlized:
> https://tools.ietf.org/html/draft= -yusef-httpauth-srp-scheme-00
>
>
> Abstract:
>=C2=A0 =C2=A0 This document defines an HTTP Authentication Scheme that = is based on
>=C2=A0 =C2=A0 the Secure Remote Password (SRP) protocol.=C2=A0 The SRP = protocol is an
>=C2=A0 =C2=A0 Augmented Password Authenticated Key Exchange (PAKE) prot= ocol
>=C2=A0 =C2=A0 suitable for authenticating users and exchanging keys ove= r an
>=C2=A0 =C2=A0 untrusted network.
>
>
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org= .
>
> The IETF Secretariat
>
>
>
> _______________________________________________
> http-auth mailing list
> http-auth@ietf.org
> https://www.ietf.org/mailman/listinfo/http-auth<= /a>
>

--
Yutaka OIWA, Ph.D.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Cy= ber Physical Architecture Research Group
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Information Technology Resear= ch Institute
=C2=A0 =C2=A0 National Institute of Advanced Industrial Science and Technol= ogy (AIST)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Mail addresses: <y.oiwa@aist.go= .jp>, <yutaka@oiwa.jp> OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D=C2=A0 3139 8677 9BD2 4405= 46B5]

--001a1136ac122263ad051b4d30f2-- From nobody Mon Jul 20 05:10:07 2015 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 CE2F81A7005 for ; Mon, 20 Jul 2015 05:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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, J_CHICKENPOX_45=0.6, 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 lSS_gNdEXBO6 for ; Mon, 20 Jul 2015 05:09:57 -0700 (PDT) Received: from mail-vn0-x22f.google.com (mail-vn0-x22f.google.com [IPv6:2607:f8b0:400c:c0f::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBCAE1A21B3 for ; Mon, 20 Jul 2015 05:09:51 -0700 (PDT) Received: by vnav141 with SMTP id v141so22037902vna.0 for ; Mon, 20 Jul 2015 05:09:51 -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=Cy/Dy1GDxEB6gGYv0kwJX+xIOwT2/fIlUEa6Nq4atM4=; b=Lou73FPsimoSOjOJp5ZR/Qck3+EG2xH3yxCGEtAN+FGNg23zEj4XOrN2Z/kuF2uAan bBoZnQbGzG2I6ubl/D5DQahe3yKpEya6zPiA4eTk5H3UmyCW48B2oE98+j+bw2kBNw21 wcDlKt45U+iIk80isql07fEb8psbc+XUAThm/iuEbZ1kZNVYw70e7CPUAZ30zsw2hm0z kjWZ9IKZrDfGI1EKdeGCXSYc0rYIh069zzIgRlQA4zrF6B1YkuJB5krohJXmMt3haiU4 95oT7VlNhPSky3FiqUD/Kp6slQXoJ3ND6/DcwuUMGnVieLoqCkqRGORHEslmZyESiV0J 5jwA== MIME-Version: 1.0 X-Received: by 10.52.17.2 with SMTP id k2mr204901vdd.15.1437394191039; Mon, 20 Jul 2015 05:09:51 -0700 (PDT) Received: by 10.31.53.72 with HTTP; Mon, 20 Jul 2015 05:09:50 -0700 (PDT) In-Reply-To: <55ACB70B.1070603@aist.go.jp> References: <20150531154835.3639.52041.idtracker@ietfa.amsl.com> <55ACB70B.1070603@aist.go.jp> Date: Mon, 20 Jul 2015 14:09:50 +0200 Message-ID: From: Rifaat Shekh-Yusef To: Yutaka OIWA Content-Type: multipart/alternative; boundary=001a11365fb028c14e051b4d6a10 Archived-At: Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Fwd: New Version Notification for draft-yusef-httpauth-srp-scheme-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, 20 Jul 2015 12:10:01 -0000 --001a11365fb028c14e051b4d6a10 Content-Type: text/plain; charset=UTF-8 Hi Yutaka, Thanks for your comments. Please, see my reply inline... Regards, Rifaat On Mon, Jul 20, 2015 at 10:53 AM, Yutaka OIWA wrote: > Dear HTTPAUTH WG, > > the following is my technical comments for the submitted draft. > > 1. The authentication exchange of the HTTP should be carefully > reconsidered. > It will usually start with unauthenticated request to the server, and > the response can contain "realm", without any specific discovery > mechanisms. > > That is the intention; if that was not clear then we will try to clarify it. Is the confusing part the fact that we called it "discovery"? > 2. The final response for the successful authentication should use > Authentication-Info header instead of WWW-Authenticate, whose > spec is under clarification by Julian. > Yes, and that is already specified in section 6. We will fix the flow diagram in section 2; it was a copy&paste error. > It's also better that the normal response codes (200 or 401) is > shown in the exchange examples for easier understanding. > > Agree. > 3. Please clarify explicitly how the six-message exchange can be shorten > on what cases. > Especially, avoiding re-computation of "public keys" is critical for > any effective use of public-key-based cryptography (including any > known PAKE algorithms) on stateless HTTP. > It will require introduction of something similar to (next-)nonce > in Digest or "sid" in Mutual and SCRAM, along with replay-preventing > mechanisms. It should be clarified how replay attacks can be prevented > when public keys are reused. > > Is this related to subsequent requests in the context of the same session? > 4. There are distinct kinds of responses with different semantics but > sharing the same "WWW-Authentication: SRP" header, and so kinds of > requests sharing "Authorization: SRP". > It should be clarified how each peer will distinguish those kinds of > messages (e.g. existence or non-existence of client-pop field). > It will be important for handling (or rejection) > of malformed messages without any ambiguity (or possible cheating with > it). > > For this, we expect the client to send the server-public-key it received from the server to allow the server the ability to distinguish between the various requests. Regards, Rifaat > > On 2015/06/01 0:53, Rifaat Shekh-Yusef wrote: > > Hi, > > > > Yaron and I have just submitted a draft that defines a new authentication > > scheme based on the SRP protocol, to be used with the HTTP Authentication > > Framework. > > We would appreciate any thoughts, reviews, and feedback on this document. > > > > Regards, > > Rifaat > > > > > > > > > > ---------- Forwarded message ---------- > > From: > > Date: Sun, May 31, 2015 at 11:48 AM > > Subject: New Version Notification for > draft-yusef-httpauth-srp-scheme-00.txt > > To: Rifaat Shekh-Yusef , Yaron Sheffer < > > yaronf.ietf@gmail.com> > > > > > > > > A new version of I-D, draft-yusef-httpauth-srp-scheme-00.txt > > has been successfully submitted by Rifaat Shekh-Yusef and posted to the > > IETF repository. > > > > Name: draft-yusef-httpauth-srp-scheme > > Revision: 00 > > Title: HTTP Secure Remote Password (SRP) Authentication Scheme > > Document date: 2015-05-31 > > Group: Individual Submission > > Pages: 11 > > URL: > > > https://www.ietf.org/internet-drafts/draft-yusef-httpauth-srp-scheme-00.txt > > Status: > > https://datatracker.ietf.org/doc/draft-yusef-httpauth-srp-scheme/ > > Htmlized: > > https://tools.ietf.org/html/draft-yusef-httpauth-srp-scheme-00 > > > > > > Abstract: > > This document defines an HTTP Authentication Scheme that is based on > > the Secure Remote Password (SRP) protocol. The SRP protocol is an > > Augmented Password Authenticated Key Exchange (PAKE) protocol > > suitable for authenticating users and exchanging keys over an > > untrusted network. > > > > > > > > > > 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. > > > > The IETF Secretariat > > > > > > > > _______________________________________________ > > http-auth mailing list > > http-auth@ietf.org > > https://www.ietf.org/mailman/listinfo/http-auth > > > > -- > Yutaka OIWA, Ph.D. Planning Officer, Research Planning Office > Department of Information Technology and Human Factors > 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] > --001a11365fb028c14e051b4d6a10 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Yutaka,

Thanks for your comments.
Please, see my reply inline...

Regards,
=C2=A0Rifaat


On Mon, Jul 20, 2015 at 10:53 AM, Yutaka OIWA <y.o= iwa@aist.go.jp> wrote:
Dear= HTTPAUTH WG,

the following is my technical comments for the submitted draft.

1. The authentication exchange of the HTTP should be carefully reconsidered= .
=C2=A0 =C2=A0It will usually start with unauthenticated request to the serv= er, and
=C2=A0 =C2=A0the response can contain "realm", without any specif= ic discovery mechanisms.


That is the intention; if that was not= clear then we will try to clarify it.
Is the confusing part the = fact that we called it "discovery"?

=C2= =A0
2. The final response for the successful authentication should use
=C2=A0 =C2=A0Authentication-Info header instead of WWW-Authenticate, whose<= br> =C2=A0 =C2=A0spec is under clarification by Julian.
Yes, and that is already specified in section 6.
We = will fix the flow diagram in section 2; it was a copy&paste error.

=C2=A0
=C2=A0 =C2=A0It's also better that the normal response codes (200 or 40= 1) is
=C2=A0 =C2=A0shown in the exchange examples for easier understanding.


Agree.


=C2=A0
3. Please clarify explicitly how the six-message exchange can be shorten =C2=A0 =C2=A0on what cases.
=C2=A0 =C2=A0Especially, avoiding re-computation of "public keys"= is critical for
=C2=A0 =C2=A0any effective use of public-key-based cryptography (including = any
=C2=A0 =C2=A0known PAKE algorithms) on stateless HTTP.
=C2=A0 =C2=A0It will require introduction of something similar to (next-)no= nce
=C2=A0 =C2=A0in Digest or "sid" in Mutual and SCRAM, along with r= eplay-preventing
=C2=A0 =C2=A0mechanisms.=C2=A0 It should be clarified how replay attacks ca= n be prevented
=C2=A0 =C2=A0when public keys are reused.


Is this related to subsequent requests= in the context of the same session?

=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> 4. There are distinct kinds of responses with different semantics but
=C2=A0 =C2=A0sharing the same "WWW-Authentication: SRP" header, a= nd so kinds of
=C2=A0 =C2=A0requests sharing "Authorization: SRP".
=C2=A0 =C2=A0It should be clarified how each peer will distinguish those ki= nds of
=C2=A0 =C2=A0messages (e.g. existence or non-existence of client-pop field)= .
=C2=A0 =C2=A0It will be important for handling (or rejection)
=C2=A0 =C2=A0of malformed messages without any ambiguity (or possible cheat= ing with it).


For this, we e= xpect the client to send the server-public-key it received from the server = to allow the server the ability to distinguish between the various requests= .


Regards,
=C2=A0Rifaat
=C2=A0

On 2015/06/01 0:53, Rifaat Shekh-Yusef wrote:
> Hi,
>
> Yaron and I have just submitted a draft that defines a new authenticat= ion
> scheme based on the SRP protocol, to be used with the HTTP Authenticat= ion
> Framework.
> We would appreciate any thoughts, reviews, and feedback on this docume= nt.
>
> Regards,
>=C2=A0 Rifaat
>
>
>
>
> ---------- Forwarded message ----------
> From: <internet-drafts@ietf.org>
> Date: Sun, May 31, 2015 at 11:48 AM
> Subject: New Version Notification for draft-yusef-httpauth-srp-scheme-= 00.txt
> To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>, Yaron Sheffer <
> yaronf.ietf@gmail.com>=
>
>
>
> A new version of I-D, draft-yusef-httpauth-srp-scheme-00.txt
> has been successfully submitted by Rifaat Shekh-Yusef and posted to th= e
> IETF repository.
>
> Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-yusef-httpauth-srp= -scheme
> Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
> Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 HTTP Secure Remote Password (= SRP) Authentication Scheme
> Document date:=C2=A0 2015-05-31
> Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
> Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 11
> URL:
> https://www.ietf.org= /internet-drafts/draft-yusef-httpauth-srp-scheme-00.txt
> Status:
> https://datat= racker.ietf.org/doc/draft-yusef-httpauth-srp-scheme/
> Htmlized:
> https://tools.ietf.org/html/draft= -yusef-httpauth-srp-scheme-00
>
>
> Abstract:
>=C2=A0 =C2=A0 This document defines an HTTP Authentication Scheme that = is based on
>=C2=A0 =C2=A0 the Secure Remote Password (SRP) protocol.=C2=A0 The SRP = protocol is an
>=C2=A0 =C2=A0 Augmented Password Authenticated Key Exchange (PAKE) prot= ocol
>=C2=A0 =C2=A0 suitable for authenticating users and exchanging keys ove= r an
>=C2=A0 =C2=A0 untrusted network.
>
>
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are availa= ble at tools.ietf.org.
>
> The IETF Secretariat
>
>
>
> _______________________________________________
> http-auth mailing list
> http-auth@ietf.org
> https://www.ietf.org/mailman/listinfo/http-auth<= /a>
>

--
Yutaka OIWA, Ph.D.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Planning Officer, Research Planning Office
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Department of Information Technology and Human Factors
=C2=A0 =C2=A0 National Institute of= Advanced Industrial Science and Technology (AIST)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Mail addresses: <y.oiwa@aist.go= .jp>, <yutaka@oiwa.jp> OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D=C2=A0 3139 8677 9BD2 4405= 46B5]

--001a11365fb028c14e051b4d6a10-- From nobody Mon Jul 20 05:22:38 2015 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 4EA931A702F for ; Mon, 20 Jul 2015 05:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_ABOUTYOU=0.5, RCVD_IN_DNSWL_NONE=-0.0001, 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 2I2lehZH1Rro for ; Mon, 20 Jul 2015 05:22:35 -0700 (PDT) Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-sg2apc01on0040.outbound.protection.outlook.com [104.47.125.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C9C21A700D for ; Mon, 20 Jul 2015 05:22:34 -0700 (PDT) Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none; Received: from [IPv6:2001:df8:f00:364:928:65f:455b:3c7c] (2001:df8:f00:364:928:65f:455b:3c7c) by KAWPR01MB0194.jpnprd01.prod.outlook.com (10.161.27.16) with Microsoft SMTP Server (TLS) id 15.1.213.14; Mon, 20 Jul 2015 12:22:24 +0000 Message-ID: <55ACE7F4.4060006@aist.go.jp> Date: Mon, 20 Jul 2015 21:22:12 +0900 From: Yutaka OIWA User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Rifaat Shekh-Yusef References: <20150531154835.3639.52041.idtracker@ietfa.amsl.com> <55ACB208.6000208@aist.go.jp> In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [2001:df8:f00:364:928:65f:455b:3c7c] X-ClientProxiedBy: SN1PR07CA0022.namprd07.prod.outlook.com (25.162.170.160) To KAWPR01MB0194.jpnprd01.prod.outlook.com (25.161.27.16) X-Microsoft-Exchange-Diagnostics: 1; KAWPR01MB0194; 2:/i5vfJAznP1jg0x1egE0V/hjr3zt0K8VtgZ9l4pd8TXKNTD1KLj/HvuGQ/2ROeeh; 3:0JI+1aH9u50jpmQiZlLeW+yJzhzcnS98ka4kCZ5IMH0q0V42Qyl89YiTZZHdRBb5Jxls1NNoYE70z7hPVBwNEWvIimS0RShUQjy38/BrHvW6TV78d7wA8cyOG0xoVJejPfNZOX2Jcj1vQstIJotJCA==; 25:18QPe3DlkkSNPQ68b8SV9d2oo0zg+sb4W3ET5FrQKn7hACoXdqeOvTyghlsc1fqA3L/vD8EYSGJXdesU39XKo+QJ/ew2kZVPP2z6Kw2LxaXaRxqhCaIUr3sU92k+yMM0Wsjaxzfkse6xrBmuH9xQab7xo5T77EXIjfud9uhE8bVs5aoUQuI0aKlRaq9kNeMako+fp07XGqTWkb1Xiky2v9nPExke6+nNVVkgk1b/IXjdrMhQ8TuE5MCYRDg8QHZo X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:KAWPR01MB0194; X-Microsoft-Exchange-Diagnostics: 1; KAWPR01MB0194; 20:/secZ4MbDkmY4IIIrYGGowaH04MxQIGlNRdJB6kJLWNWUXjnBmVLIjJuFS9FamRAFEWGGOxqi8Esr6vtSX7HFPWMrUxP2nyRZdewovhTkHm3gPd2nwA05MRhgK0zDyAN8mRYEjRBrnJmkcZm9TH+PBi/TpkYYR0Hy4MFIEApfoSUQHNQMEdfl/NHC6eeyHY4dNUf2bVRU3230zZEz4ddN+1fPEWoaRpQFu0k0XPtXh7Vax4/OZUuV5oE3+9NQxWWOM0nJuqdsDBRj6JbLblHE5eHyKy5RMfTZJcaD3tpj9j1tv3IyCuFkHCxtd1NBx8Def2hmuBPh/EZXZroeX0ZzvA8D6T82xyOADDysKzIWXWBjwMQTBsfaTPNz4ngZOjLgGQti31scHZgfl9bHHE9U+9aLEFr/UQQ+uOV7e43b/AD6eeYu/b5Ac+FKRrngWr/a2hLId9xQTDV8a21NXlCGkPJQCT4fip8gnStCIN7QpOLnSyti8fy+lDPEDl1Suy+FtpgsOrQZ20nKCVffa0awvXjniN1rxOGb/4fbSyQwS0RK1wagZxnQZnG+B79G9UmrO2IYzz748vxnGov+opHPN82mElDt1bCKaEYkGBLVJI=; 4:KobrEMGdxossjFXRCW8moi1VuwYCvV+P1VpVKIduvrdZQ/ja2VqMazeLbyEIBzivRdaOVEOv6HTB0U5U94YLtq7YgLog48E6gQ/gDX0nYDRGcCxX91EB0fFyBrYiQf6TYIMEc4XjZX31K6/fPrLpVYZh9zLhOFWxVvwZoSpZkYwNqOiSVLeUpDKohNeNL7QJqOS7vpPjCk7qWzZjD9CeRH7tFPFfTcsB0D9BmtdCd+hbWjeAwttJJQxtU1RhoxnHPZiLnKBJbJDrcM+niG0vMg== KAWPR01MB0194: X-MS-Exchange-Organization-RulesExecuted X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(5005006)(3002001); SRVR:KAWPR01MB0194; BCL:0; PCL:0; RULEID:; SRVR:KAWPR01MB0194; X-Forefront-PRVS: 0643BDA83C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6009001)(2473001)(479174004)(24454002)(377424004)(377454003)(50986999)(93886004)(86362001)(19580395003)(5001960100002)(50466002)(189998001)(36756003)(92566002)(59896002)(65806001)(74482002)(551544002)(83506001)(65956001)(42186005)(33656002)(15975445007)(47776003)(62966003)(122386002)(110136002)(87266999)(2950100001)(77096005)(46102003)(4001350100001)(19580405001)(77156002)(87976001)(40100003)(80316001)(230783001)(76176999)(54356999)(561944003)(23676002)(3826002); DIR:OUT; SFP:1101; SCL:1; SRVR:KAWPR01MB0194; H:[IPv6:2001:df8:f00:364:928:65f:455b:3c7c]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtLQVdQUjAxTUIwMTk0OzIzOkhiaUl5Ynp6eW01OHFubjhaNVVWUEdrZmYx?= =?utf-8?B?bkZGZmIwWUFoVjVodnJkOWRFb3h3a2NPZDVsUzJCZkpYTm9NbE9lNXUwemlT?= =?utf-8?B?cE9MZ0VZNmJCYkxwYjIrazNRNE5xUmJtaUc4N1NPMjBkMFhpL3M4dHpMZFF0?= =?utf-8?B?amFpelNUL2dIOHZtSU1tTzBYUWZJS0J2Z0F6VldQWWVaaDJzazQwYm5IWERK?= =?utf-8?B?MldUcG80cndZY3JEcGtTNEx2ems2T0E3TnpUb2hkenN6OWFWbWxyRVVIZWNM?= =?utf-8?B?YUYwQytKNkRBUlpHUlhrbjhFeFAxUEZENkE2WlRYd1RSSWdEcUQwaDdpLzNz?= =?utf-8?B?TktTdkY3V1hFREhiOHgvUkxlQjZ5dk9IUFJ4ZkxPeHR3WHp6YzNLOFB2a0c1?= =?utf-8?B?UStteThsT0MwUUNsYXcrRTM5K3dkR290STNHSXR2bStLaFBsQUNBbHpzaFR6?= =?utf-8?B?eGZ1NDZldDVPRGFXdTZLK1JjeFZNN0R2cGlTMWtWTGJFTmxqV3hET3krdkhv?= =?utf-8?B?U0w3OVhOSjlzOXBJYTdPejVhN3kwV1Y5TFVCMS9odllZOU9VbytZaHBCVysx?= =?utf-8?B?em9MVGtsZEU3VzlQK1RMSk1CWVh2amJNTlJ3RkVGcW9wai80SjBhS3k5NXpw?= =?utf-8?B?cmI3eXl2a0lFWGVNQk1lUnlPTnlZVWRqOUZLMFVMeWJrbHpxaytZWkxGcTlr?= =?utf-8?B?eUhhemp2eEFEdjNRY3FVSjE5VXovVy94QStwMU9YaXRlMkF1bVFiMmhSeXRz?= =?utf-8?B?ZEN6aGlCZXpqWE4yN3NET0Nrcnp6OXJIYU0zbHV5Y1Q1b09BSTZMd2RyZ28r?= =?utf-8?B?MDBrSFU5LzZwaDR0bmd3UER6V3EwS3puY1ZRMW83T0NDZVBXdGQ1RlZDVUkz?= =?utf-8?B?SzVCY2YvenFQR1Q4K0krbkpZd05zK0MwS3M4MFJ4RWN5blB1K3VOZHNJK0RK?= =?utf-8?B?QUM0dHdHbk4weVdKditwWmVFODhKQTB4K1RWNndqUjJDbVg1bnpmaExaR0Ey?= =?utf-8?B?OWRVT252WU5HODlVNmJaZVBsdzJ5dWNEY1F1RUhKdHZySW5keEphSzV5Ty93?= =?utf-8?B?QXRJZTBteWJqbkQ1YTBrWXdSK0sveWdxRWF5eU9XMWVoTGpINys3ZG9ySDZF?= =?utf-8?B?Ym5ETHZmMHAwSmw0cFpiajRTR1lmbjZ0TThVcjJUcnU0NGZmKzIrOHJJN0VE?= =?utf-8?B?S2F5UGh4VUNNTG5OUDNpbENpc3lDZzNXWEczTXU5NFhlRENtNmtOM3hjUmZY?= =?utf-8?B?eFVic2txRWVWL1J2ZjJIRE8rdlV0OHB1MStOa09uTnEvOXFLRHN6eXpwbUIz?= =?utf-8?B?SHFlNGNSZ3RVeWhndHp3UllMMnJaMndhWGZDSHRIcWp0RC9vQzc1eVNrLzFN?= =?utf-8?B?QkljekVYK0NFeGRyQURCWnMzZExzWUptM1lxdEYyWWFUZW9tbTNETXhTNm9n?= =?utf-8?B?YVhnYXNXbjhoYUgrdWtoYVRKQ1BEUUpBdW9XZHozcXdkT3RQUmJtbENnVzBV?= =?utf-8?Q?OqOq/BfoP0kd2gVk47+YGgeBLBrAgBekwBTOvOSWIGGFRH?= X-Microsoft-Exchange-Diagnostics: 1; KAWPR01MB0194; 5:46852u43IZu4l8Pz+gmSyS6uFOmT8R5yZ6H9qT34f73CZxeesp+8LYTbnoN9/EEG4FLK8LiXkxXr2exDQVE3372hCcuDSyHR2FTFPwOREI8QKID1NxeaQsbC+KNvmNg+j0tL8DhxEBHBmgcayRwfyQ==; 24:6DL9oGvrSxXuRPUyTUujuHbnuq58BEtDZmV962MuHktbqEjPt1SmmZQwC8sHHQmM1t/WUUzLXrkpPEsxBZrgll1WS/pIMpndBGQd7kS0+ig=; 20:AMyZHUsmg8A0KaLWG9lXlB6xZRKPBNiWnVdI+bMLFp2WLB0w2ilw0+lBG6HGbso48Ak4L3lKQogfpIqFsuRlng== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: aist.go.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jul 2015 12:22:24.5776 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: KAWPR01MB0194 Archived-At: Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Fwd: New Version Notification for draft-yusef-httpauth-srp-scheme-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, 20 Jul 2015 12:22:37 -0000 Thanks Rifaat, I'll go inline, too. On 2015/07/20 20:53, Rifaat Shekh-Yusef wrote: > Hi Yutaka, > > Please, see my reply inline... > > Regards, > Rifaat > > > On Mon, Jul 20, 2015 at 10:32 AM, Yutaka OIWA wrote: > >> Dear Rifaat, >> >> I'm happy on seeing some interest on using strong PAKE-based >> cryptography on HTTP authentication, but I also have several >> questions/concerns about your current proposal. >> I'll first express my general questions and suggestions, >> followed by my technical reviews and suggestions in a separate email. >> >> >> Could you tell us why do you think this proposal is needed? >> Is there any specific request for this technology in this form, or >> is it just a general motivation for PAKE to be used in HTTP? >> >> > It is a general motivation to use PAKE-based solution not only for HTTP, > but also for other protocols, e.g. SIP. Understood. >> I have been designing Mutual auth as a general framework for >> augmented PAKE-based HTTP authentication, and implemented >> several mechanisms to let it working effectively. >> > > Unfortunately, I am personally not that familiar with your work. > > In general, we would like to utilize the *existing *HTTP Framework and add > support for SRP on top of that. > SRP is a protocol that is already used by other RFCs and it has many > implementations out there, and is royalty free. What I'm doing is that I *do* use the existing HTTP Framework, and add generic support for PAKE on top of that (draft-ietf-httpauth-mutual). Then, I put some specific PAKE on top of it (draft-ietf-httpauth-mutual-algo). Please look at my work. >> For example, the session key caching and replay-preventing >> nonce-counter is a key mechanism to avoid heavy public-key >> cryptographic operations in every request-response pair. >> >> > I am assuming that this is related to the subsequent requests utilizing the > session keys. > We left this out of this document because we think it is out of scope. If your word "utilizing" means something outside of HTTP auth, it seems to be a wrong assumption. My assumption is simply that one authentication will generally serve much more than one document sequentially or in parallel. This is true for both Web and API-based non-Web (REST-like) accesses. As you know, the PAKE computation is quite heavy operation and number of it should be minimized as small as possible. A few hundreds of milliseconds for each resource is quite unacceptable. It's completely within the scope of HTTP authentication design, and is in align with the base design concept of HTTP/2.0. I think SIP might be an exception for this assumption, but it's quite a special case for HTTP. And, if you think generic HTTP authentication mechanism can be used for SIP as well, my proposal can go as well, quite easily. > Regards, > Rifaat > > > >> If you have no specific reasons for implementing SRP in that specific form, >> I recommend to try writing it as an additional authentication algorithm >> for the Mutual scheme. It will avoid re-inventing many required wheels >> for effective use of heavy PAKE mechanisms which your draft currently >> lacks. >> >> # After finishing (significant portion of) my own work for Mutual auth, >> # I could possibly be able to volunteer writing SRP-based auth algorithm >> # for Mutual scheme, to find out whether it will work successfully or not. >> >> Also, I have to mention that we've submitted our drafts first >> to httpbis WG in 2012 as a chairs' requirement for including >> it as chartered discussion candidates. That's how the current >> HTTPAUTH WG was formed with current candidates. >> I'm little bit surprised to see this proposal on this time period. >> If we've seen it long before, I could be working more on considering >> your specific requirements merged into Mutual proposal. >> # I also have asked several times for comments on the choice of >> # PAKE variants for basic Mutual uses, without any strong >> # suggestions for changing it from the current form. >> >> >> Regards, >> >> Yutaka >> >> On 2015/06/01 0:53, Rifaat Shekh-Yusef wrote: >>> Hi, >>> >>> Yaron and I have just submitted a draft that defines a new authentication >>> scheme based on the SRP protocol, to be used with the HTTP Authentication >>> Framework. >>> We would appreciate any thoughts, reviews, and feedback on this document. >>> >>> Regards, >>> Rifaat >>> >>> >>> >>> >>> ---------- Forwarded message ---------- >>> From: >>> Date: Sun, May 31, 2015 at 11:48 AM >>> Subject: New Version Notification for >> draft-yusef-httpauth-srp-scheme-00.txt >>> To: Rifaat Shekh-Yusef , Yaron Sheffer < >>> yaronf.ietf@gmail.com> >>> >>> >>> >>> A new version of I-D, draft-yusef-httpauth-srp-scheme-00.txt >>> has been successfully submitted by Rifaat Shekh-Yusef and posted to the >>> IETF repository. >>> >>> Name: draft-yusef-httpauth-srp-scheme >>> Revision: 00 >>> Title: HTTP Secure Remote Password (SRP) Authentication Scheme >>> Document date: 2015-05-31 >>> Group: Individual Submission >>> Pages: 11 >>> URL: >>> >> https://www.ietf.org/internet-drafts/draft-yusef-httpauth-srp-scheme-00.txt >>> Status: >>> https://datatracker.ietf.org/doc/draft-yusef-httpauth-srp-scheme/ >>> Htmlized: >>> https://tools.ietf.org/html/draft-yusef-httpauth-srp-scheme-00 >>> >>> >>> Abstract: >>> This document defines an HTTP Authentication Scheme that is based on >>> the Secure Remote Password (SRP) protocol. The SRP protocol is an >>> Augmented Password Authenticated Key Exchange (PAKE) protocol >>> suitable for authenticating users and exchanging keys over an >>> untrusted network. >>> >>> >>> >>> >>> 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. >>> >>> The IETF Secretariat >>> >>> >>> >>> _______________________________________________ >>> http-auth mailing list >>> http-auth@ietf.org >>> https://www.ietf.org/mailman/listinfo/http-auth >>> >> >> -- >> Yutaka OIWA, Ph.D. Cyber Physical Architecture Research Group >> Information Technology Research Institute >> National Institute of Advanced Industrial Science and Technology (AIST) >> Mail addresses: , >> >> OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 >> 46B5] >> > -- Yutaka OIWA, Ph.D. Cyber Physical Architecture Research Group Information Technology Research Institute 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 Mon Jul 20 05:44:23 2015 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 124A61A8738 for ; Mon, 20 Jul 2015 05:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_NONE=-0.0001, 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 mxecap0-myEy for ; Mon, 20 Jul 2015 05:44:20 -0700 (PDT) Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-hk2apc01on0047.outbound.protection.outlook.com [104.47.124.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EDBE1A8740 for ; Mon, 20 Jul 2015 05:44:19 -0700 (PDT) Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none; Received: from [IPv6:2001:df8:f00:364:928:65f:455b:3c7c] (2001:df8:f00:364:928:65f:455b:3c7c) by OS2PR01MB0202.jpnprd01.prod.outlook.com (10.161.78.140) with Microsoft SMTP Server (TLS) id 15.1.213.14; Mon, 20 Jul 2015 12:44:16 +0000 Message-ID: <55ACED0B.1070904@aist.go.jp> Date: Mon, 20 Jul 2015 21:43:55 +0900 From: Yutaka OIWA User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Rifaat Shekh-Yusef References: <20150531154835.3639.52041.idtracker@ietfa.amsl.com> <55ACB70B.1070603@aist.go.jp> In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [2001:df8:f00:364:928:65f:455b:3c7c] X-ClientProxiedBy: AM3PR06CA050.eurprd06.prod.outlook.com (10.141.192.168) To OS2PR01MB0202.jpnprd01.prod.outlook.com (25.161.78.140) X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0202; 2:pHqUM6lqD1O6zJpI7kFPERt4vuQZPX+LuzmnxC6NhyvmUmLXT4Rx2noscg6IEVey; 3:0FIgUx0p1tlh4dlF0atPAAGof2M7zHSNXICpQLuxn6PpxsD5wyY17Wd8pvWEOg+omnnG+b+xWJb3dbrCAxdt6LrrkJNYFI4u6vOR5dInk9pJ8MaXJVRR79v+y7GjCtychSCcJjHHp409ns1ENkju/g==; 25:0o6Ig4tzfzpsjlRFpXzUZOF6OlV+2D1rzMl0l/JF1epi5O7Xqr4f9AQUgdk1xm5IIMorGU0viLYIlr1uysMtwbbItKp156UrblQoOazJsWLkwmVIhOTYOovaPNP2pd7vVYZrzjZZ46ZUM4lB45HmhbUAM2LkbPAIZ5HtrpOoGmFskXTEiCwqJxOeqLZWAJw29VAH5zpLd+bkDHrewHL/6mYHqy5LiMP8GPuSBxnPlyQkJ3pUMVwMmBc/uGnsaJeFp9x7WEL3+0Dk5Act2R1q3g== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:OS2PR01MB0202; X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0202; 20:Q9+dXOQAp1gzLI3Xp14w4VOisVbEnmQwwzX3+aOAZYSIG4TNZD0LnyEmmjbPlwlnCtVLizbm7GUy1jINWt+BLW5rNO5aoKvNn6OiUTtFupgzY654VTa9hFlbx1e6bNn9vQpdby++TKW6qvi3Q+1FWIHgGYzv6w+WIgvdZz3mZIW3DhKj12Yra1DEvs2RldtjClClezEeozwGqhls47UHRPK9XsWaIveszrNLQDhPFWfxK1/sgnp2RlTcJQ3nj5HLDpflPJmlrUr5s4PNXNUd4ypabrJApv4x/RE/sJUAPJpnZUOswURgHxANTniOn1hiqEB5+vwIHlAo9QARKY3tB3h/5bPy/Ym2udzsgnDpxb+dmf2lCuU3DfYh2F68xFpSBNL04UmBi5LMJo3LyQ/lXHPp+KnYdsmgH/5nZtbwqTumh9658IBqO8waHeLcpVJuXTTg6yeI7aSf8x3NV32BYuk1AbbF6b3bMYUyWMnDoycMPJwZDHvTIBZZOKWY7/s6woz4sae3ldHbdMgCr0ZFWBTYb321HN7Z7k8Ix3KSCIrQHqq/tyH1X6bNtWjHIvfl7nVhN9HOdbrXKuCiBKIeNPa0WVXs+XPQennEUU/yCYI=; 4:/oebKX73OyMbVpfClwa5cYzcdS4c8xsqkdnWELFE3wcioJN1sCJn1h7lb3CsU46Re6Og8hWaLhe9p1I1Zv3oIaeJ8HY40851UCrQC7DYc3msVs/cI58CpWbXv0MwTXIw+ZlY8JsQtQOBMybWavNM8yrx+Eu+C5KkTXSgNcH9MopkmNzN40DD0Tesa1ilcQH2xwkWtLaLWrxwFQTaQEAY9COQlToz368yh9o0HQ6dlS/ZXcxUw+sH5N5XhyOWj1mpUOcjXQzc9vqzNDM9yBgPaQ== OS2PR01MB0202: X-MS-Exchange-Organization-RulesExecuted X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(5005006)(3002001); SRVR:OS2PR01MB0202; BCL:0; PCL:0; RULEID:; SRVR:OS2PR01MB0202; X-Forefront-PRVS: 0643BDA83C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6009001)(377454003)(2473001)(24454002)(479174004)(377424004)(65956001)(83506001)(33656002)(110136002)(5001960100002)(42186005)(4001350100001)(189998001)(87976001)(36756003)(77156002)(62966003)(80316001)(50986999)(92566002)(65806001)(47776003)(76176999)(59896002)(87266999)(122386002)(86362001)(74482002)(2950100001)(551544002)(50466002)(54356999)(19580405001)(93886004)(19580395003)(40100003)(77096005)(15975445007)(23676002)(230783001)(46102003)(3826002); DIR:OUT; SFP:1101; SCL:1; SRVR:OS2PR01MB0202; H:[IPv6:2001:df8:f00:364:928:65f:455b:3c7c]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtPUzJQUjAxTUIwMjAyOzIzOi9BNEhOWWRqZGxkdUcwV2E2V0hSOEt3NXE4?= =?utf-8?B?QVJRYmpMcXJMbEZic2xCcUZFeWYrVUY0Ui9HZVRvcURNT3JFUWF6NnVhVmdz?= =?utf-8?B?OHB4c1NtdDF5L3BxSkt0NjliY3p0Z09Nam1qOW1aMExoUmxLVTB3T0NyYS9j?= =?utf-8?B?VGRXNEZkbWxjaXczZVlybVVIVHJMbisyOVR1ZDRheEtNakxuZVUxVjdVcnJm?= =?utf-8?B?TUFkcGFjdEt4dTVjUFJDUHd1aDBuWmJMOXkyQWdQTkF0b3B0aVJjVVpXYzQy?= =?utf-8?B?MFFmRXlaWXdCaFRaVnJieEtTUzB3OTVXTHRkK1A0djBWMDk1S2FTNDk3ZzZP?= =?utf-8?B?bnU1VHYyUzBOL0dqcVE0UE5IY3VYckxwZFFnV3NCN2ZXdTVFei9RODROclJ6?= =?utf-8?B?S09mSWk1VkFLN05UZzJBV0Y1c3h6OWtOdko2K2k3a1g3M0xUbWtvY0ZTQzFp?= =?utf-8?B?WlRtTTd4Y3pLQnoyUW03RTl2bDc4S283dUhOdU5wUHA0eFRxUWpsRUtYZUh1?= =?utf-8?B?eGRXTlEwNUdoNWQ5cUxLUFhKMlMxcWl5WlpXMFlBQzN6WFJ6eGIyeUU4TW0v?= =?utf-8?B?NUovcUhkS1o1WFp5MmJCakNpRXVZbkpWeG50QmdBUUZnV1dyWFltQ00vQTRr?= =?utf-8?B?ZXhwNlVHK2hGanRjZWlvV0wrdHlPL3R5cTF3REh1L2hLQWRwZEFkSW1rM0x2?= =?utf-8?B?MzRqd3U2YVJFWW1LcW1SVUo1cXJReHVUYWNVNlBJMk8xRDdVcFhqQ1YzZHFN?= =?utf-8?B?K0tXNHNXa3loN3lxQjV5U0dndzlLa05aUzNuVDdKWVhKVEw5ZU5wME1hYmFx?= =?utf-8?B?R3ZnQkI1S01WZHRRN1hBcnZyWjRDdTIyUExKd29hSjFEbHliYTdqN1A1S0xX?= =?utf-8?B?VzhDbEVCR3IyYXNzcHlCektxSUFPLytEdG1rUUN1V2NDdjZITjZ6YmNlenlm?= =?utf-8?B?M0VXSDBMQUdBWFlHZkdtMitOWXhER1JXdVRzaDFZblkyamMvNmlNLzF3QlVz?= =?utf-8?B?NDJZSmZBMW5aS3dQUXY1VnRFNmVDa20vVVJ5V1Y1Mkl4bTJzcHdRMXcwRGM5?= =?utf-8?B?L1Foam5WSk1wWG43Q21uenZhWmswa3dRN2dVa2VoT0duMzM4cFBJdmJPdk9X?= =?utf-8?B?aXhvSjVrOTM2ZkhtUXJwWDNUVjFITHhTRjlBa0w1dzFNVGliYVowVnRIdFR3?= =?utf-8?B?a1A2Uno4Y1BWSTczTW9mUTUxT1V4bUtYTTJtT3hCK0xaMXZUbys2V1lvSUdo?= =?utf-8?B?ZEp1YUVEeXBvUGY4Sm8vNGNzZ3FNM0FqeVdHNFFRSHRuTkl5bHpZMVBOdnlh?= =?utf-8?B?WU9PeS83QUgrY3JKWHA2S21melI4Z0pxZ25XbEhLOWpqNG5UUUNJNC9GNk82?= =?utf-8?B?ZVdGZ25JdUxoMGdXanA2OGtYYy9rcGhlK2FUWUFBRzJtZ3IrdTBaWVQwNHpz?= =?utf-8?B?Um94NkRyaWdDME9FbTJFbzZDdGxOWWJWUW03ZzhLQlpWaCtjTFc5UWh6Q2Ix?= =?utf-8?Q?nWW0xOHJH0uK6kGz3r8NCWNI8=3D?= X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0202; 5:80EQMNuMmSVf4Mmn5CktfAzBOndrNBzA5/sN28XCYW86UoIi0YEjifNR4uN1mBtlOkACOGIiGift44zMGhteCNksHxQvSzoz1eMYPR8GSlqweICXwYrwRh8gIdSmj/R/Of1i+VqHsU4fHWNVtcsNnA==; 24:9ZKFqGcUDofXRNt2h5MV0dNTBuFvSy9PfuuMpZoXHv8PLcepp/R+Lj44QP0unjhulFA7a87C1hkGwunf5QQzSJ59dingYsROkzwEnfKsiTE=; 20:qDbzQv+O5b1oJqFyCCznt4tcGc0PdCjfYC/XpbTk4D64IPG0n6ylQGOqVMPNnrr5m3t8s/xNnbXlccldOM4czA== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: aist.go.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jul 2015 12:44:16.3701 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: OS2PR01MB0202 Archived-At: Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Fwd: New Version Notification for draft-yusef-httpauth-srp-scheme-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, 20 Jul 2015 12:44:22 -0000 Dear Rifaat, On 2015/07/20 21:09, Rifaat Shekh-Yusef wrote: > Hi Yutaka, > > Thanks for your comments. > Please, see my reply inline... > > Regards, > Rifaat > > > On Mon, Jul 20, 2015 at 10:53 AM, Yutaka OIWA wrote: > >> Dear HTTPAUTH WG, >> >> the following is my technical comments for the submitted draft. >> >> 1. The authentication exchange of the HTTP should be carefully >> reconsidered. >> It will usually start with unauthenticated request to the server, and >> the response can contain "realm", without any specific discovery >> mechanisms. >> >> > That is the intention; if that was not clear then we will try to clarify it. > Is the confusing part the fact that we called it "discovery"? I just could not understand why there is a request with empty "Authorization: SRP". That can simply be omitted. >> 2. The final response for the successful authentication should use >> Authentication-Info header instead of WWW-Authenticate, whose >> spec is under clarification by Julian. >> > > Yes, and that is already specified in section 6. > We will fix the flow diagram in section 2; it was a copy&paste error. I understand it. >> It's also better that the normal response codes (200 or 401) is >> shown in the exchange examples for easier understanding. >> >> > Agree. > > > > >> 3. Please clarify explicitly how the six-message exchange can be shorten >> on what cases. >> Especially, avoiding re-computation of "public keys" is critical for >> any effective use of public-key-based cryptography (including any >> known PAKE algorithms) on stateless HTTP. >> It will require introduction of something similar to (next-)nonce >> in Digest or "sid" in Mutual and SCRAM, along with replay-preventing >> mechanisms. It should be clarified how replay attacks can be prevented >> when public keys are reused. >> >> > Is this related to subsequent requests in the context of the same session? The term "session" is not defined in HTTP, but I think probably true. Related to the subsequent to-be-authenticated requests for the same realm. >> 4. There are distinct kinds of responses with different semantics but >> sharing the same "WWW-Authentication: SRP" header, and so kinds of >> requests sharing "Authorization: SRP". >> It should be clarified how each peer will distinguish those kinds of >> messages (e.g. existence or non-existence of client-pop field). >> It will be important for handling (or rejection) >> of malformed messages without any ambiguity (or possible cheating with >> it). >> >> > For this, we expect the client to send the server-public-key it received > from the server to allow the server the ability to distinguish between the > various requests. I guessed so. What happens if the server receives server-public-key and username but no client-pop, for example? Also, I found one mistake: Authentication-Info does not contain any scheme; it is implied by the scheme in the Authorization header received from the client. > Regards, > Rifaat > > >> >> On 2015/06/01 0:53, Rifaat Shekh-Yusef wrote: >>> Hi, >>> >>> Yaron and I have just submitted a draft that defines a new authentication >>> scheme based on the SRP protocol, to be used with the HTTP Authentication >>> Framework. >>> We would appreciate any thoughts, reviews, and feedback on this document. >>> >>> Regards, >>> Rifaat >>> >>> >>> >>> >>> ---------- Forwarded message ---------- >>> From: >>> Date: Sun, May 31, 2015 at 11:48 AM >>> Subject: New Version Notification for >> draft-yusef-httpauth-srp-scheme-00.txt >>> To: Rifaat Shekh-Yusef , Yaron Sheffer < >>> yaronf.ietf@gmail.com> >>> >>> >>> >>> A new version of I-D, draft-yusef-httpauth-srp-scheme-00.txt >>> has been successfully submitted by Rifaat Shekh-Yusef and posted to the >>> IETF repository. >>> >>> Name: draft-yusef-httpauth-srp-scheme >>> Revision: 00 >>> Title: HTTP Secure Remote Password (SRP) Authentication Scheme >>> Document date: 2015-05-31 >>> Group: Individual Submission >>> Pages: 11 >>> URL: >>> >> https://www.ietf.org/internet-drafts/draft-yusef-httpauth-srp-scheme-00.txt >>> Status: >>> https://datatracker.ietf.org/doc/draft-yusef-httpauth-srp-scheme/ >>> Htmlized: >>> https://tools.ietf.org/html/draft-yusef-httpauth-srp-scheme-00 >>> >>> >>> Abstract: >>> This document defines an HTTP Authentication Scheme that is based on >>> the Secure Remote Password (SRP) protocol. The SRP protocol is an >>> Augmented Password Authenticated Key Exchange (PAKE) protocol >>> suitable for authenticating users and exchanging keys over an >>> untrusted network. >>> >>> >>> >>> >>> 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. >>> >>> The IETF Secretariat >>> >>> >>> >>> _______________________________________________ >>> http-auth mailing list >>> http-auth@ietf.org >>> https://www.ietf.org/mailman/listinfo/http-auth >>> >> >> -- >> Yutaka OIWA, Ph.D. Planning Officer, Research Planning Office >> Department of Information Technology and Human Factors >> National Institute of Advanced Industrial Science and Technology (AIST) >> Mail addresses: , >> >> OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 >> 46B5] >> > -- Yutaka OIWA, Ph.D. Planning Officer, Research Planning Office Department of Information Technology and Human Factors 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 Mon Jul 20 07:28:00 2015 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 018881A88A7 for ; Mon, 20 Jul 2015 07:27:58 -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 XkJkcW_jLzIS for ; Mon, 20 Jul 2015 07:27:51 -0700 (PDT) Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-sg2apc01on0061.outbound.protection.outlook.com [104.47.125.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3E221A88D6 for ; Mon, 20 Jul 2015 07:27:50 -0700 (PDT) Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none; Received: from [IPv6:2001:df8:f00:364:928:65f:455b:3c7c] (2001:df8:f00:364:928:65f:455b:3c7c) by OS2PR01MB0201.jpnprd01.prod.outlook.com (10.161.78.14) with Microsoft SMTP Server (TLS) id 15.1.213.14; Mon, 20 Jul 2015 14:27:47 +0000 Message-ID: <55AD054A.2010806@aist.go.jp> Date: Mon, 20 Jul 2015 23:27:22 +0900 From: Yutaka OIWA User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "http-auth@ietf.org" Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Originating-IP: [2001:df8:f00:364:928:65f:455b:3c7c] X-ClientProxiedBy: BN1PR08CA0023.namprd08.prod.outlook.com (10.242.217.151) To OS2PR01MB0201.jpnprd01.prod.outlook.com (25.161.78.14) X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0201; 2:8FxmQjcyfb5x1VuCBb0UiLwnpCT6rKW3IUrE1Qk9dBiixCCe6BpPJVUgeaM5FJS8; 3:nEr53BcRbTgmao1S/E5joRVwn2zX22X3Tddtjxax620EUtBIC0ToWkTVzY+IHfOCK81gN5ZJ9XNSJty4wVRB+rzd3KqTJJoO3IVmkVSpncw49tcLC3TMe9MnkLTho6u4Fi9Kj5aJehRTX6oCayX13Q==; 25:NAmhZnAoeiFWj60EiscoWPPAuY7LVKNBbbPUSwm6MN9pEceFsZKiu5lSq7WTc9h25hYfp2l3OfLzcrNxkOCD4JyS8HRY0BJzaQxPx+80ByAUiydaoX6KMu6VSY3pD517ndEf+9Wg+v1g7NXkuDH17P34LjOf3ZDF5wHs1+ki5iH9RR1BWwtaEzuY3vagZIgaE2VJ7+Lyxq6n+Ts/429dht3DgTpHQHM+iOW4qhM/zM59spfJvm6piRbhZADgEmzuJ14mNQOETDRsZjSgZWMdKg== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:OS2PR01MB0201; X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0201; 20:58Di50FGRIWYRfQMoff+pXxafoYEVOXiAejkEdJkzzcqusX7mE0uw0VzZOXlx2tnwfvpdQ5JKA886qbMiiOgNeqQLPT6qmPkS+UrbBpbCeL807e1SSfJQA+zZ6Rdsn38W3ib4tV9AWJOWsfXTidZ01RDfD4WE9/IOdKVJ+RIBpmXVfAbAJ9qlLTFfTxfnMm7W2Pn+k6uQlEsrU2ABThGsiOaiUF0dyTu0q4xidcSH3+jprlQ8PVtugz7InP1+iz88YIifDIFVdhpLwHgjx1r1w5Pkg0n0/pUBG0zzVU95A+0l7HzyVwwYklBQTBnEltQtPxSNiFn3JNtg/IhMx1/u0JthjlZIXXfaj+KwI6Qe4RSoMkInnv3180pN3Sz4rfCdx0lIO1j6X5MgtZgunBCFg9ialBc/b0sIUq5omNLEEKmgeYwWau3FlAm7+FrO83BJIQgjwbb/FXbh5qaMCGK4qSzD0qo/XYwd3LUvxtKFxlugeAVHWTdUFGfhpdqTEu4bapgQChtfYtdvyY6dH96ZKkvBUQ7tqwVrvEnF9cLsreeHOtiQsFdlUSwy03Fh1EBrQwrU3YZjz1nKTl5GpRAtyDY3it/hxtgss6VfMprB1M=; 4:EAS/CHAWDi3/1Y5jXuFkg8jNWLZuptd8+C8GXdWJBkrX5WQofQw5l1YAy0M7q3CbFI5wvr+OTGr3xCQbWW1dAr0QBDMBt7hx42ciAf7QcexVSiAGwdyJEhHC+ExWGnAsUg4QK39quRsnGeB54L5N6Xlx90coZweodzb291Yqae2GB8R6mxkp7ytls3dndKGz2GbycVtJGrRZaKowDMHjXSdn0DKz1JdKbLNzsqh0TGtuun7bDyONS45SsqoW+JsTSZJrFcxiFtKgRSeDNUy9nA== OS2PR01MB0201: X-MS-Exchange-Organization-RulesExecuted X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(5005006)(3002001); SRVR:OS2PR01MB0201; BCL:0; PCL:0; RULEID:; SRVR:OS2PR01MB0201; X-Forefront-PRVS: 0643BDA83C X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6009001)(19580395003)(77096005)(33656002)(19580405001)(59896002)(86362001)(15975445007)(120846001)(47776003)(36756003)(65956001)(229853001)(80316001)(2351001)(65806001)(50466002)(87266999)(77156002)(189998001)(46102003)(83506001)(2501003)(42186005)(74482002)(92566002)(5001920100001)(107886002)(5001960100002)(4001350100001)(62966003)(110136002)(122386002)(40100003)(23736002)(50986999)(54356999)(87976001)(450100001)(3826002); DIR:OUT; SFP:1101; SCL:1; SRVR:OS2PR01MB0201; H:[IPv6:2001:df8:f00:364:928:65f:455b:3c7c]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?iso-2022-jp?B?MTtPUzJQUjAxTUIwMjAxOzIzOjI0WEVwNWM0VHZHWTZobWp2aDMxUDJv?= =?iso-2022-jp?B?cktVL2pCc3liR3JCUGluWUM5T3kxZ2R0d0R0KzA0dVVQMGhWU2VEWGM0?= =?iso-2022-jp?B?dUxncERncVdORHNqNmswNWdORlhhTGpHdkhzZXhzWmdjbGRKbDVEaHdY?= =?iso-2022-jp?B?d3czUEVWWkEzWDgwdmlqUGdDYW8rTHVKTkxxT3ZKMVZWblZzVS9mSkkr?= =?iso-2022-jp?B?c2dYazJaekdQN2ZXY2VQZ2xLRVRuUHd6TkhSck1ZN2praHk2T3hSbktH?= =?iso-2022-jp?B?N2ZkajZOVS9hZlI0c0VQT0Q3TVhiNFZuMkREWEI1aTNSeVo3bUNKVTNX?= =?iso-2022-jp?B?VDZTN0M3SWRTSXFjR1g3d1NwbUt1V20wOUErK05mTFRBVC9KU0NVQkxX?= =?iso-2022-jp?B?R1prSk04WHlMQXh4MWZkVTlZU2lrblJINER2clltYnZxWlplQkZ5YXd3?= =?iso-2022-jp?B?MmpvdUxrNlJCQ2ZTaGZSRUgxblFMNTl0bjIrZlgzbUEwNTRqTXZ5M28r?= =?iso-2022-jp?B?QXozdjQ2b0hXdGRNUUJwZzNORXcxL2ZtZ3Y2K0ppU2hDTFFhVTBoVHMx?= =?iso-2022-jp?B?SnBMSlRsVThtT01aL1BzMUI5SUloV1FjdWhSRThDR2hneldhSXRyRlFm?= =?iso-2022-jp?B?d09ONVlMMDVNSmUvUTVTSVRGZ3hCWEpqRkV3dit1MEdCNzVFQWg0OVdL?= =?iso-2022-jp?B?MnlxeldCZTh5WDZwYU1EbnlMQWxLOTgzelFxN0FYdUliL2RZSzREZDVy?= =?iso-2022-jp?B?R2ErZE00ZlRqR3NvMDdkbzJ4T21EcHNUbU5QSWc2d21PTU9wcmY3K3BB?= =?iso-2022-jp?B?cGlRRGx4NXBQUGEvaXVZN1JCTjdwVzRmWlJtRkNwVEJ2by9oaVVGL2lo?= =?iso-2022-jp?B?bWQwdnQ4VHFWRUJJc241b0ZITzFUUFVrZnNYVTl2T3ZFeFZyV1QzeVhn?= =?iso-2022-jp?B?ektpbHRjc28vNEpXNlJoWUdSKzk4Y21pUkZuczkwNUM5aXlrTjF3aG9J?= =?iso-2022-jp?B?UUNBQXl3Rm1Cc2RiSE16YUlyWVRkMkd6bGE3cS9BcnNLSnllVmZaaDN4?= =?iso-2022-jp?B?YmNHUERDYUoyVGk0bURXZFN1bEdyZ1d3MTRkTEJEUHdzeVpibDhOYk1C?= =?iso-2022-jp?B?Z3UwTUtrYTNONDJGaDBtQzVWVEtLdGFrblk3UFlRVk1DZUtFYSswZWFy?= =?iso-2022-jp?B?VWRab3ZFRmUwZlJlLzlhWXBtNjZkM2VjQmgxT1Fud2NlWjNYMFducTlT?= =?iso-2022-jp?B?aHNKOFYzRk1uZUVCUHdiUUs3cFhzTHZnZnEwQTVWb05sRnZiYXZGRmFa?= =?iso-2022-jp?B?YmY2b2hZSlNLcDlIaDBxYlVLK01UcVFzcW5WQ3ZuaVQ3dTZZeDVoOHRV?= =?iso-2022-jp?B?NzhUMXA4dnM4TERDY2ZEcVhCWlVWRWxqeUFwMm00eS9hNm0vR1JLNHBN?= =?iso-2022-jp?B?eFFCRTdkd29iY3BGUFpLemlIYVF2ZHJiWkZpR2JOYmFwUXpjNHIyODJO?= =?iso-2022-jp?B?Tkl3amhDaTdGZlVVbC9iMzNPRlEzWWczYzJEd3ZhSVBCa2FvPQ==?= X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0201; 5:TohNzITneIL0xYBqd83jCTxbPVRB6oHH9sgwaZtn5rcboLdqC2USAdQZiFDCpKoKY7ZMiqIJnevBUd4nMuF9i0uUzzJ8QvUlCIJLWa2Ksz8xCngWNnQklbOyI/FOmcSRKxlOX0bQExdI5iP0M53Cnw==; 24:oXv0qrDdEZEZJ8fDCxgzI3bh1LIaHjsF34dO3ZMbe1GU1eJH27DG+PPWW2PW9cUt7BIg423lC/5BsmQCI6m2JW8tbMgyT+y8WpTB7OAM8n8=; 20:H2rgkF8RM52bcX0i4hn+BkW3xYK4+z/hnoxGKff8qeDroKqTnFxEwnvESd4aEETom4IFBUGoq87hTy9L+jiRFA== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: aist.go.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jul 2015 14:27:47.0003 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: OS2PR01MB0201 Archived-At: Subject: [http-auth] [Mutual] Draft source XMLs 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, 20 Jul 2015 14:27:58 -0000 Dear HTTPAUTH WG people, I've published the source XML of the Mutual-related drafts at . You *don't need* to use these files to raise bug-fix, problems or update proposals. We still appreciate any mail- or talk-based comments. If it's convenient for you in some way, please use it and send a pull-request. Cheers, -- Yutaka OIWA, Ph.D. Cyber Physical Architecture Research Group Information Technology Research Institute 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 Thu Jul 23 01:08:01 2015 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 D43C41A872D for ; Thu, 23 Jul 2015 01:08:00 -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 W8PGYzI8Y6DU for ; Thu, 23 Jul 2015 01:07:56 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D8BA1A8A77 for ; Thu, 23 Jul 2015 01:07:56 -0700 (PDT) Received: by wicgb10 with SMTP id gb10so131174103wic.1 for ; Thu, 23 Jul 2015 01:07:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=mXVNto0k52HmSJh2H2tb7yz52/lBarGCrOyi3jwG1Bk=; b=bl4H+A8XCbbBIuR5w6iqELXt28mJxkctd/QBSjPmH5MVXhDQyukLo6GH3qu4j+2ESM 6v3muhffMUTTrWIZlvUbMR0IvuK0clGL64JDh+Ites3jYGkISx6LlX//tvJ+7/Ps960f FZFPIYY+fm5iwIRi8y7IASSq75G/GcYDozAcTL2V7tDphhBxnfuzp9noiwXqkX5Y+apg gh1EgVj8HB//Q1yPtW7Py9Eegzsk+e1DU4gzAtzVDqVX0B9RXaod+B0uKdfRvvFE3/8p 48MHrrv0W9NqdRBwzJXNvu3Qq4Q9ixzLh/XrfL7ODQcPTn6fUiOFgVCW29dO2kCnnsZ+ X9Sw== MIME-Version: 1.0 X-Received: by 10.180.79.10 with SMTP id f10mr49512209wix.1.1437638875013; Thu, 23 Jul 2015 01:07:55 -0700 (PDT) Received: by 10.28.31.194 with HTTP; Thu, 23 Jul 2015 01:07:54 -0700 (PDT) Date: Thu, 23 Jul 2015 04:07:54 -0400 Message-ID: From: Kathleen Moriarty To: "http-auth@ietf.org" Content-Type: multipart/alternative; boundary=f46d0442829875e8fb051b866221 Archived-At: Subject: [http-auth] Chair change 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, 23 Jul 2015 08:08:01 -0000 --f46d0442829875e8fb051b866221 Content-Type: text/plain; charset=UTF-8 First I'd like to thank Matt Lepinski for serving as co-chair to the httpauth working group. As Yoav already announced, Matt has to step down, but will hopefully be back at the IETF in the future. I'd also like to thank Rifaat Shekh-Yusef for stepping up as co-chair and look forward to continued productive results from httpsauth. Thank you all for your work contributing to the httpauth working group and widely implemented and deployed results. -- Best regards, Kathleen --f46d0442829875e8fb051b866221 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
First I'd like to thank Matt Lepinski for serving as c= o-chair to the httpauth working group.=C2=A0 As Yoav already announced, Mat= t has to step down, but will hopefully be back at the IETF in the future. = =C2=A0

I'd also like to thank Rifaat Shekh-Yusef for stepping up as co-chair and l= ook forward to continued productive results from httpsauth.

Thank you all for your work contribu= ting to the httpauth working group and widely implemented and deployed resu= lts.


--

Best regards,
Kath= leen
--f46d0442829875e8fb051b866221-- From nobody Sun Jul 26 04:48:13 2015 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 717781B2B77; Sun, 26 Jul 2015 04:48:11 -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 mB8r3yjAUvpI; Sun, 26 Jul 2015 04:48:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 309AB1A1AA8; Sun, 26 Jul 2015 04:48:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.1.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150726114810.1233.54578.idtracker@ietfa.amsl.com> Date: Sun, 26 Jul 2015 04:48:10 -0700 Archived-At: Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-scram-auth-07.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: Sun, 26 Jul 2015 11:48:11 -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-07.txt Pages : 18 Date : 2015-07-26 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 security concerns with HTTP Digest 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 HTTP 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: https://tools.ietf.org/html/draft-ietf-httpauth-scram-auth-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-scram-auth-07 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 Tue Jul 28 06:17:00 2015 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 1B6CC1A8AE9; Tue, 28 Jul 2015 06:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 po3g8-XpZ2gv; Tue, 28 Jul 2015 06:16:55 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D04651A1AA8; Tue, 28 Jul 2015 06:16:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3A86BBE5D; Tue, 28 Jul 2015 14:16:53 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h4x2PhF9_h6r; Tue, 28 Jul 2015 14:16:53 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0F721BE58; Tue, 28 Jul 2015 14:16:53 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1438089413; bh=aJZu9QA9R3M1WG1wi2Z/bKwdhl1fLp3EoiuxCwWaJEo=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To:From; b=z5tUjD1rBwsTAdfJ9TMCmOdFT0mO3+OORn2zCizwx7nFGJHB92j6KzfUF9joP3uV9 bmF+7hhKppcqespZpVpIGPzIMLa4NAHwWDEskBqHN9TX9n7p7APjJ4Nmg3rtX31JWt py7FbgNZ48xqk5X/ahbLeDJcPErphOigzPw7po48= Message-ID: <55B780C4.5020006@cs.tcd.ie> Date: Tue, 28 Jul 2015 14:16:52 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: "kitten@ietf.org" , "http-auth@ietf.org" References: <20150728131206.27668.27380.idtracker@ietfa.amsl.com> In-Reply-To: <20150728131206.27668.27380.idtracker@ietfa.amsl.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= X-Forwarded-Message-Id: <20150728131206.27668.27380.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Sparks Robert Subject: [http-auth] Fwd: Last Call: (SCRAM-SHA-256 and SCRAM-SHA-256-PLUS SASL Mechanisms) to Proposed Standard X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: IETF-Discussion List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 13:16:57 -0000 Hiya, We're re-doing the IETF last call for this due to the change of target from informational to PS. I hope it has addressed all other earlier comments, but please do say if not. Thanks, S. -------- Forwarded Message -------- Subject: Last Call: (SCRAM-SHA-256 and SCRAM-SHA-256-PLUS SASL Mechanisms) to Proposed Standard Date: Tue, 28 Jul 2015 06:12:06 -0700 From: The IESG Reply-To: ietf@ietf.org To: IETF-Announce The IESG has received a request from an individual submitter to consider the following document: - 'SCRAM-SHA-256 and SCRAM-SHA-256-PLUS SASL Mechanisms' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-08-25. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document registers the SASL mechanisms SCRAM-SHA-256 and SCRAM- SHA-256-PLUS. It also updates the SCRAM registration procedures of RFC 5802. The file can be obtained via https://datatracker.ietf.org/doc/draft-hansen-scram-sha256/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-hansen-scram-sha256/ballot/ No IPR declarations have been submitted directly on this I-D. This is a second IETF last call. The first time this was aiming for informational but as a result of that proposed standard was deemed necessary.