From internet-drafts@ietf.org Mon Jul 1 07:03:19 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9024511E818B; Mon, 1 Jul 2013 07:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kn6uYsFhn+uk; Mon, 1 Jul 2013 07:03:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 23F6511E8135; Mon, 1 Jul 2013 07:03:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130701140319.24231.24693.idtracker@ietfa.amsl.com> Date: Mon, 01 Jul 2013 07:03:19 -0700 Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-mutual-00.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 14:03:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Hypertext Transfer Protocol Authenticatio= n Working Group of the IETF. Title : Mutual Authentication Protocol for HTTP Author(s) : Yutaka Oiwa Hajime Watanabe Hiromitsu Takagi Boku Kihara Tatsuya Hayashi Yuichi Ioku Filename : draft-ietf-httpauth-mutual-00.txt Pages : 53 Date : 2013-07-01 Abstract: This document specifies a mutual authentication method for the Hyper- text Transport 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. This prevents common phishing attacks: a phishing attacker controlling a fake website cannot convince a user that he authenticated to the genuine website. Furthermore, even when a user authenticates to an illegitimate server, the server cannot gain any information about the user's password. The Mutual authentication method is designed as an extension to the HTTP protocol, and is intended to replace the existing authentication methods used in HTTP (the Basic method, Digest method, and authentication using HTML forms). 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: http://tools.ietf.org/html/draft-ietf-httpauth-mutual-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Jul 1 07:04:46 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82F8311E818B; Mon, 1 Jul 2013 07:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBRMCsnqgvik; Mon, 1 Jul 2013 07:04:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA5C11E81AD; Mon, 1 Jul 2013 07:03:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130701140348.31047.76885.idtracker@ietfa.amsl.com> Date: Mon, 01 Jul 2013 07:03:48 -0700 Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-extension-00.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 14:04:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Hypertext Transfer Protocol Authenticatio= n Working Group of the IETF. Title : HTTP Authentication Extensions for Interactive Clients Author(s) : Yutaka Oiwa Hajime Watanabe Hiromitsu Takagi Boku Kihara Tatsuya Hayashi Yuichi Ioku Filename : draft-ietf-httpauth-extension-00.txt Pages : 23 Date : 2013-07-01 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: http://tools.ietf.org/html/draft-ietf-httpauth-extension-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Jul 1 07:07:53 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F1B511E81C3; Mon, 1 Jul 2013 07:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SMJEhlsMekIi; Mon, 1 Jul 2013 07:07:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6870C11E81BA; Mon, 1 Jul 2013 07:07:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130701140750.23488.20914.idtracker@ietfa.amsl.com> Date: Mon, 01 Jul 2013 07:07:50 -0700 Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-scram-auth-00.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 14:07:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Hypertext Transfer Protocol Authenticatio= n Working Group of the IETF. Title : Salted Challenge Response (SCRAM) HTTP Authentication Me= chanism Author(s) : Alexey Melnikov Filename : draft-ietf-httpauth-scram-auth-00.txt Pages : 18 Date : 2013-07-01 Abstract: The secure authentication mechanism most widely deployed and used by Internet application protocols is the transmission of clear-text passwords over a channel protected by Transport Layer Security (TLS). There are some significant security concerns with that mechanism, which could be addressed by the use of a challenge response authentication mechanism protected by TLS. Unfortunately, the HTTP Digest challenge response mechanism presently on the standards track failed widespread deployment, and have had success only in limited use. This specification describes a family of HTTP authentication mechanisms called the Salted Challenge Response Authentication Mechanism (SCRAM), which addresses the security concerns and meets the deployability requirements. When used in combination with TLS or an equivalent security layer, a mechanism from this family could improve the status-quo for application protocol authentication. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-scram-auth There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-httpauth-scram-auth-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From paul.hoffman@vpnc.org Mon Jul 1 07:16:32 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90E6911E81D1 for ; Mon, 1 Jul 2013 07:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fq5-kwh1yWQe for ; Mon, 1 Jul 2013 07:16:32 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 28D7B11E8170 for ; Mon, 1 Jul 2013 07:16:32 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-228.dsl.dynamic.sonic.net [50.1.98.228]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r61EGQmX066536 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 1 Jul 2013 07:16:27 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <51D11AD4.5050705@gmx.de> Date: Mon, 1 Jul 2013 07:16:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130630142838.31885.15315.idtracker@ietfa.amsl.com> <51D04326.5060600@gmx.de> <51D09F98.2070508@gmail.com> <51D1175C.3020007@it.aoyama.ac.jp> <51D11AD4.5050705@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1508) Cc: http-auth@ietf.org Subject: Re: [http-auth] Normalization forms in draft-ietf-httpauth-basicauth-enc X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 14:16:32 -0000 On Jun 30, 2013, at 10:59 PM, Julian Reschke = wrote: > So what if we mandated normalization to happen on the client? And they implemented it correctly every time? That would work great. Does the history of IDNA2003 and various protocols that mandate various = kinds of StringPrep give you the feeling that such a mandate will lead = to consistent results? --Paul Hoffman= From y.oiwa@aist.go.jp Mon Jul 1 19:52:58 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E06311E8397 for ; Mon, 1 Jul 2013 19:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQhpJxRlhxJ8 for ; Mon, 1 Jul 2013 19:52:53 -0700 (PDT) Received: from na3sys010aog103.obsmtp.com (na3sys010aog103.obsmtp.com [74.125.245.74]) by ietfa.amsl.com (Postfix) with ESMTP id 6929711E8304 for ; Mon, 1 Jul 2013 19:52:53 -0700 (PDT) Received: from mail-ve0-f169.google.com ([209.85.128.169]) (using TLSv1) by na3sys010aob103.postini.com ([74.125.244.12]) with SMTP ID DSNKUdJAgwbZjgzNSRInUfiFQRpACQ/5fFKy@postini.com; Mon, 01 Jul 2013 19:52:53 PDT Received: by mail-ve0-f169.google.com with SMTP id m1so4506653ves.0 for ; Mon, 01 Jul 2013 19:52:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=C5/zTi5ZlZhtOXfdVLgJuuBtqdCNdn/DLKl4zDqYhKQ=; b=ty2/3iyryf6ebJZ575rL8LqiiX4gk9QZ2SjHWtz+WkUwPCQVNtfdaRZbt5TyiAHU0d XWaRLuBZWmo3nRcGfng9uVX3v/+Kg1VC+D/cQ+F00p4++kkcEP+9/zYQ1GFDZPmzLSkb 7nKbPuPUbFW5MDBBxNW/h+G/CGeSHUM4E9QzU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=C5/zTi5ZlZhtOXfdVLgJuuBtqdCNdn/DLKl4zDqYhKQ=; b=EV6cIorOEFQd7wfh6AtjR5F1lgLjq2kSDXQ3JDLOQAWMuPkdUwd7skh89Xq+J/GjMU a5jddmelVUXYvTXHhIeHtRFA8cKeylP4M/QuMwRmSJDwUecFYfrtiGnzvYDdvYBKeZjh uRxgouD/bvu+Zj55VireS58tjLADBy9s03PLyaQb/IqGICUJCKEoh6RayG9faK4b+DXl 3v+K+eigkaWg6tKWyXgEvqUu6JHkz4EFKER8BtiNoYXj0P6pwRHenbpXudRzSXsjUciG RODJkygF6Tt3BATqzNzCiQJyJUpu1zCVK8sLnrPAlr2lKcIxqWXpaPw8eU0bnPFLIgH+ vMoA== X-Received: by 10.220.83.69 with SMTP id e5mr8016954vcl.53.1372733571324; Mon, 01 Jul 2013 19:52:51 -0700 (PDT) X-Received: by 10.220.83.69 with SMTP id e5mr8016951vcl.53.1372733571220; Mon, 01 Jul 2013 19:52:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.243.66 with HTTP; Mon, 1 Jul 2013 19:52:31 -0700 (PDT) In-Reply-To: <51D04326.5060600@gmx.de> References: <20130630142838.31885.15315.idtracker@ietfa.amsl.com> <51D04326.5060600@gmx.de> From: Yutaka OIWA Date: Tue, 2 Jul 2013 11:52:31 +0900 Message-ID: To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkRAANw0w2uF+nkE0vkUKSVLEBdC+Ipdr5xVmYZiPgRfsIwJ+KTAINJZ9qms1mWD4orSMolldOsI+yZsucKCPfng1QzCB6tt8Uehawt5hS7+ZGlqskbMxPX4P3rJH0QuMvLx2WqlcxnEHcDzeViMK8vOWALIg== Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-basicauth-enc-01.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 02:52:58 -0000 2013/6/30 Julian Reschke : > On 2013-06-30 16:28, internet-drafts@ietf.org wrote: > For now, there's one open issue left: we currently do not say anything about > Unicode normalization forms, but we probably should. +2 for considering normalization: it is almost a MUST for interactive (e.g. browser) use-cases. Just as an instance, default Unicode encoding of Japanese language differs between existing major implementations (composed (Win) or decomposed (Mac) for hiragana/katakana). This already has made a huge cumbersome on exchanged filenames. Without normalization, Japanese users will not be able to reliably use internationalized usernames in authentication. At the same time, as Paul suggested, it has a too much overhead for servers and non-interactive clients. It is very unlikely and unwise to be implemented on wget and curl, for example. Also, server-side normalization is not compatible with any other schemes which apply hashes and alike to usernames/passwords. I want to find a good phrase, which "effectively" means that normalization is a "to do" only for modern browsers but "ignorable" for all other clients, and "not to do" for all servers. One current solution is make it a SHOULD "to send normalized", without specifying how. Non-interactive clients may require configurations to prepare strings beforehand, or just require an ASCII subset, both of which is to be considered to meet the SHOULD requirement. However, I still want more elegant solutions. At the same time, PRECIS WG had a small mention on string preparation (which includes Unicode normalizations and more) on HTTP in Orlando, and I am currently preparing a straw-man. -- Yutaka OIWA, Ph.D. Leader, System Life-cycle Research Group Research Institute for Secure Systems (RISEC) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] From ynir@checkpoint.com Tue Jul 2 00:59:41 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7DB511E83D5 for ; Tue, 2 Jul 2013 00:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vKQB-Zt+C7mo for ; Tue, 2 Jul 2013 00:59:36 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 0B72021F99A1 for ; Tue, 2 Jul 2013 00:59:19 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r627xEPp005585; Tue, 2 Jul 2013 10:59:14 +0300 X-CheckPoint: {51D28852-6-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.48]) by IL-EX10.ad.checkpoint.com ([169.254.2.180]) with mapi id 14.02.0342.003; Tue, 2 Jul 2013 10:59:13 +0300 From: Yoav Nir To: Julian Reschke , "http-auth@ietf.org" Thread-Topic: [http-auth] Normalization forms in draft-ietf-httpauth-basicauth-enc Thread-Index: AQHOdh5ETg5sRT+nxkGECfC1vUWCXplPIdsAgACKwgCAASjzgA== Date: Tue, 2 Jul 2013 07:59:14 +0000 Message-ID: <42111C34-9B32-45B2-AC94-B18CE5CC081F@checkpoint.com> References: <20130630142838.31885.15315.idtracker@ietfa.amsl.com> <51D04326.5060600@gmx.de> <51D09F98.2070508@gmail.com> <51D1175C.3020007@it.aoyama.ac.jp> <51D11AD4.5050705@gmx.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.24.134] x-kse-antivirus-interceptor-info: protection disabled x-cpdlp: 11aad5f6f7c2a60a67b38f2027fa22419756f3cbd8 Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [http-auth] Normalization forms in draft-ietf-httpauth-basicauth-enc X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 07:59:41 -0000 Hi For those of us not so well versed in I18N issues, what do you mean by norm= alization?=20 Is it just consolidating look-alike code points, like the multiple hyphens = that exist in Unicode?=20 Does it also involve removing Arabic and Hebrew points? (I think Paul raise= d this one)=20 Does it involve removing diacritics? Does it involve splitting combined characters (like U+00E6 into 'a' and 'e'= )? Is there a standard we can point to and say "do this before comparing or ha= shing"? Thanks Yoav From julian.reschke@gmx.de Tue Jul 2 01:37:59 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8A4E11E8433 for ; Tue, 2 Jul 2013 01:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.08 X-Spam-Level: X-Spam-Status: No, score=-105.08 tagged_above=-999 required=5 tests=[AWL=-2.481, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGUr1YeGFY8N for ; Tue, 2 Jul 2013 01:37:55 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 7D28711E8417 for ; Tue, 2 Jul 2013 01:37:53 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.32]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0LtC3J-1UDq5j2PyF-012pYZ for ; Tue, 02 Jul 2013 10:37:52 +0200 Received: (qmail invoked by alias); 02 Jul 2013 08:37:52 -0000 Received: from p5DD9780B.dip0.t-ipconnect.de (EHLO [192.168.1.103]) [93.217.120.11] by mail.gmx.net (mp032) with SMTP; 02 Jul 2013 10:37:52 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+HtzVzv3CHH5tHA8UhNxkZzVkPOTvjIcAm9pK/Y7 JcAnFyeEsT/i74 Message-ID: <51D2915E.1060607@gmx.de> Date: Tue, 02 Jul 2013 10:37:50 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Yoav Nir References: <20130630142838.31885.15315.idtracker@ietfa.amsl.com> <51D04326.5060600@gmx.de> <51D09F98.2070508@gmail.com> <51D1175C.3020007@it.aoyama.ac.jp> <51D11AD4.5050705@gmx.de> <42111C34-9B32-45B2-AC94-B18CE5CC081F@checkpoint.com> In-Reply-To: <42111C34-9B32-45B2-AC94-B18CE5CC081F@checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Normalization forms in draft-ietf-httpauth-basicauth-enc X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 08:38:00 -0000 On 2013-07-02 09:59, Yoav Nir wrote: > Hi > > For those of us not so well versed in I18N issues, what do you mean by normalization? > > Is it just consolidating look-alike code points, like the multiple hyphens that exist in Unicode? > Does it also involve removing Arabic and Hebrew points? (I think Paul raised this one) > Does it involve removing diacritics? > Does it involve splitting combined characters (like U+00E6 into 'a' and 'e')? > Is there a standard we can point to and say "do this before comparing or hashing"? > > Thanks > > Yoav Dunno what the others think, but I was focusing on NFC vs NFD (), with a preference to recommend NFC. That being said, it might be interesting to test what those UAs that currently *do* use UTF-8 do. Best regards, Julian From duerst@it.aoyama.ac.jp Tue Jul 2 02:04:45 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1837721F991E for ; Tue, 2 Jul 2013 02:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.79 X-Spam-Level: X-Spam-Status: No, score=-102.79 tagged_above=-999 required=5 tests=[AWL=3.000, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMvTo1nvQYMH for ; Tue, 2 Jul 2013 02:04:39 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id C53CE21F992A for ; Tue, 2 Jul 2013 02:04:20 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r6293wOM019132; Tue, 2 Jul 2013 18:03:58 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 45c9_6606_54756c66_e2f6_11e2_bd1b_001e6722eec2; Tue, 02 Jul 2013 18:03:57 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id B2388BF4CD; Tue, 2 Jul 2013 18:02:23 +0900 (JST) Message-ID: <51D29766.8080803@it.aoyama.ac.jp> Date: Tue, 02 Jul 2013 18:03:34 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Yoav Nir References: <20130630142838.31885.15315.idtracker@ietfa.amsl.com> <51D04326.5060600@gmx.de> <51D09F98.2070508@gmail.com> <51D1175C.3020007@it.aoyama.ac.jp> <51D11AD4.5050705@gmx.de> <42111C34-9B32-45B2-AC94-B18CE5CC081F@checkpoint.com> In-Reply-To: <42111C34-9B32-45B2-AC94-B18CE5CC081F@checkpoint.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: Julian Reschke , "http-auth@ietf.org" Subject: Re: [http-auth] Normalization forms in draft-ietf-httpauth-basicauth-enc X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 09:04:45 -0000 On 2013/07/02 16:59, Yoav Nir wrote: > Hi > > For those of us not so well versed in I18N issues, what do you mean by = normalization? > > Is it just consolidating look-alike code points, like the multiple hyph= ens that exist in Unicode? > Does it also involve removing Arabic and Hebrew points? (I think Paul r= aised this one) > Does it involve removing diacritics? > Does it involve splitting combined characters (like U+00E6 into 'a' and= 'e')? > Is there a standard we can point to and say "do this before comparing o= r hashing"? In the narrow sense, it involves one of the four forms (NFC, NFKC, NFD,=20 NFKD) defined in UAX #15 (http://www.unicode.org/reports/tr15/). NFC/D=20 deal with precomposed/decomposed issues for accents, although not with=20 cases such as U+00E6, where the distinction between "ae" and "=C3=A6" sho= uld=20 be clearly visible. A Hebrew example would be U+FB1D, HEBREW LETTER YOD=20 WITH HIRIQ, which as an exception is decomposed both in NFC and NFD to=20 U+05D9 U+05B4 (usually, NFC is precomposed). The K variants also include other variant changes, sometimes some very=20 visible ones. For example, they take =EF=BC=91 (full-width) and =E2=91=A0= to 1. Here,=20 most hyphen variants are not included, although some are (e.g. U+207B,=20 subscript hyphen). Case folding/equivalence is separate from both of the above cases. Removing diacritics is also separate, because in many cases, that would=20 be besides the point. Paul has already mentioned stringprep, which is the base for nameprep=20 and saslprep (and maybe others that I'm not aware of). That work is=20 currently followed up by the work of the IETF precis WG. Regards, Martin. From derhoermi@gmx.net Tue Jul 2 02:58:35 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16E3D11E8452 for ; Tue, 2 Jul 2013 02:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Slu+RSMdiRpj for ; Tue, 2 Jul 2013 02:58:31 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id A7CAF11E8461 for ; Tue, 2 Jul 2013 02:58:30 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.4]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MfTEr-1UZypd3x6J-00P2gg for ; Tue, 02 Jul 2013 11:58:26 +0200 Received: (qmail invoked by alias); 02 Jul 2013 09:58:26 -0000 Received: from p5B2339F3.dip0.t-ipconnect.de (EHLO netb.Speedport_W_700V) [91.35.57.243] by mail.gmx.net (mp004) with SMTP; 02 Jul 2013 11:58:26 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1/MVY8cicLMZUfjsUMwD6KPSqLEtJus/u0UP+aZY7 xX3qhqPdfyxug/ From: Bjoern Hoehrmann To: Julian Reschke Date: Tue, 02 Jul 2013 11:58:20 +0200 Message-ID: References: <20130630142838.31885.15315.idtracker@ietfa.amsl.com> <51D04326.5060600@gmx.de> <51D09F98.2070508@gmail.com> <51D1175C.3020007@it.aoyama.ac.jp> <51D11AD4.5050705@gmx.de> In-Reply-To: <51D11AD4.5050705@gmx.de> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: http-auth@ietf.org, Paul Hoffman Subject: Re: [http-auth] Normalization forms in draft-ietf-httpauth-basicauth-enc X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 09:58:35 -0000 * Julian Reschke wrote: >So what if we mandated normalization to happen on the client? I see no benefit in the server receiving normalize("$user:$pass") over receiving "$user:$pass" given that the server can and probably has to do `normalize` on its own, e.g. during account creation or password change, especially considering that `normalize` may vary over time. I also note efforts like . -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From ynir@checkpoint.com Tue Jul 2 04:45:16 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9389D11E849C for ; Tue, 2 Jul 2013 04:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQ4HVDCIV0G2 for ; Tue, 2 Jul 2013 04:45:11 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 517D811E8485 for ; Tue, 2 Jul 2013 04:45:10 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r62Birlh024861; Tue, 2 Jul 2013 14:44:54 +0300 X-CheckPoint: {51D2BD35-29-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.48]) by IL-EX10.ad.checkpoint.com ([169.254.2.180]) with mapi id 14.02.0342.003; Tue, 2 Jul 2013 14:44:52 +0300 From: Yoav Nir To: Bjoern Hoehrmann Thread-Topic: [http-auth] Normalization forms in draft-ietf-httpauth-basicauth-enc Thread-Index: AQHOdh5ETg5sRT+nxkGECfC1vUWCXplPIdsAgAHU+gCAAB3FgA== Date: Tue, 2 Jul 2013 11:44:52 +0000 Message-ID: References: <20130630142838.31885.15315.idtracker@ietfa.amsl.com> <51D04326.5060600@gmx.de> <51D09F98.2070508@gmail.com> <51D1175C.3020007@it.aoyama.ac.jp> <51D11AD4.5050705@gmx.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.84] x-kse-antivirus-interceptor-info: protection disabled x-cpdlp: 11b245a9acf65625b2cedaa86296146d2e87e14a93 Content-Type: text/plain; charset="iso-8859-1" Content-ID: <7A088F8DF38D4C4E8592971142E423D9@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Julian Reschke , "" , Paul Hoffman Subject: Re: [http-auth] Normalization forms in draft-ietf-httpauth-basicauth-enc X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 11:45:16 -0000 On Jul 2, 2013, at 12:58 PM, Bjoern Hoehrmann wrote: > * Julian Reschke wrote: >> So what if we mandated normalization to happen on the client? >=20 > I see no benefit in the server receiving normalize("$user:$pass") over > receiving "$user:$pass" given that the server can and probably has to do > `normalize` on its own, e.g. during account creation or password change, > especially considering that `normalize` may vary over time. I also note > efforts like . I realize that this thread is specifically about basicauth. But this group = is also considering other authentication schemes (digest, mutual-auth, scra= m). In all of those, you won't get the password in the clear, so you can't = expect the server to perform the manipulations.=20 The group can decide to mandate one behavior (entirely server-side) for bas= icauth, and something else for others (like maybe negotiate the kind of nor= malization to perform). But I'd rather we use the same kind of processing f= or all methods unless there's a good reason to do so.=20 Yoav From msweet@apple.com Tue Jul 2 04:58:29 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC2E11E84A5 for ; Tue, 2 Jul 2013 04:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.084 X-Spam-Level: X-Spam-Status: No, score=-7.084 tagged_above=-999 required=5 tests=[AWL=3.514, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vm779uYbBOPH for ; Tue, 2 Jul 2013 04:58:23 -0700 (PDT) Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 2178911E849C for ; Tue, 2 Jul 2013 04:58:23 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_dMYX5fQM9IDK1M3A37mMeA)" Received: from relay8.apple.com ([17.128.113.102]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MPB0088658M36E0@mail-out.apple.com> for http-auth@ietf.org; Tue, 02 Jul 2013 04:58:20 -0700 (PDT) X-AuditID: 11807166-b7faa6d000003acb-52-51d2c05a4e94 Received: from [17.153.103.163] (Unknown_Domain [17.153.103.163]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay8.apple.com (Apple SCV relay) with SMTP id 48.57.15051.B50C2D15; Tue, 02 Jul 2013 04:58:20 -0700 (PDT) From: Michael Sweet Date: Tue, 02 Jul 2013 07:58:18 -0400 To: http-auth@ietf.org Message-id: X-Mailer: Apple Mail (2.1508) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMLMWRmVeSWpSXmKPExsUiODN9sW7MgUuBBtcPs1t82D+HyeLIt1gH Jo+tJ3+weSxZ8pMpgCmKyyYlNSezLLVI3y6BK6PzRydLwSPNijmnL7M3MJ5Q7mLk5JAQMJH4 1HWEEcIWk7hwbz1bFyMXh5BAP5PEy/svwBJsAmoSvyf1sYLYzAIJEnenrmHvYuTgYBFQkXjw KxIkLCxgJXH4xyI2EFsEaM6JKdfYQWxeARuJn1NbmCBsPYml/+YwgrRKCMhK7PydNIGRexaS obOQVEHEtSWWLXzNPAuog1lAR2LyQjRhCPvj+SNMCxjZVjEKFKXmJFZa6CUWFOSk6iXn525i BAVVQ2HaDsam5VaHGAU4GJV4eBXmXQwUYk0sK67MPcQowcGsJMLLvfFSoBBvSmJlVWpRfnxR aU5q8SFGaQ4WJXHeVGmglEB6YklqdmpqQWoRTJaJg1OqgfHU/yTufbGbotesvXVvfVlp1psT aic+hrlk374sv77w/4+PCy6n29zyaFdnPRpRuMTnEoOq1Xerln6epsul9pO3NoTKLP/a6Xdo xf+Z7EK+ORcu3djiwuLOcCTwRBjv6y1HHHSulwYttvVV0L9sq2fyQ2+OzJvGdyF7n9Ys8nZf lFCuYFaU916JpTgj0VCLuag4EQABDn9SJgIAAA== Subject: [http-auth] Comments on draft-ietf-httpauth-scram-auth-00.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 11:58:29 -0000 --Boundary_(ID_dMYX5fQM9IDK1M3A37mMeA) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT All, Some quick comments on draft-ietf-httpauth-scram-auth-00: - Section 3: Would it make sense to reference RFC 5198 (Network Unicode) instead of/in addition to RFC 3629 (UTF-8) for the username and password? Beyond that, do you want to say something about "control" characters - in my experience that has been a major issue for interoperability. - Section 4: - Given the vulnerabilities in SHA-1 and the requirements of the current HTTP Digest update draft (draft-ietf-httpauth-digest-update-02), would it make more sense to set the low bar at SHA2-256? - The uppercasing of the name makes sense for normalization, however the ABNF here and in RFC 2617 make the auth-scheme case-insensitive. - Section 5: - (Editorial) Don't think you need the parens around '(and "sid")'. - The example shows the use of the Authentication-Info header, however RFC 2617's definition of the header does not allow for extension and has a slightly different format (no leading auth-scheme). Since an update is being done to Digest, this might be a chance to formalize the syntax to allow for extensibility with a leading auth-scheme followed by 0 or more auth-param values. - You probably want to include a info-scram ABNF rule with the challenge-scram and credentials-scram rules - Section 5.1: I'm uncomfortable with including an attribute whose presence causes an error. Understanding you might want to extend things in the future, shouldn't those extensions define the attribute and its absence (when used with those extensions) cause an error? - Section 6: Shouldn't the challenge-scram, credentials-scram, and info-scram rules be included here? _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Boundary_(ID_dMYX5fQM9IDK1M3A37mMeA) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable

- Section 4:
  = - Given the vulnerabilities in SHA-1 and the requirements of the = current HTTP Digest update draft (draft-ietf-httpauth-digest-update-02), = would it make more sense to set the low bar at = SHA2-256?
  - The uppercasing of the name makes sense for = normalization, however the ABNF here and in RFC 2617 make the = auth-scheme case-insensitive.

- Section = 5:
  - (Editorial) Don't think you need the parens around = '(and "sid")'.
  - The example shows the use of the = Authentication-Info header, however RFC 2617's definition of the header = does not allow for extension and has a slightly different format (no = leading auth-scheme). Since an update is being done to Digest, this = might be a chance to formalize the syntax to allow for extensibility = with a leading auth-scheme followed by 0 or more auth-param = values.
  - You probably want to include a info-scram = ABNF rule with the challenge-scram and credentials-scram = rules

- Section 5.1: I'm uncomfortable with = including an attribute whose presence causes an error. Understanding you = might want to extend things in the future, shouldn't those extensions = define the attribute and its absence (when used with those extensions) = cause an error?

- Section 6: Shouldn't the = challenge-scram, credentials-scram, and info-scram rules be included = here?


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

= --Boundary_(ID_dMYX5fQM9IDK1M3A37mMeA)-- From msweet@apple.com Tue Jul 2 05:19:04 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26B9321F844E for ; Tue, 2 Jul 2013 05:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.586 X-Spam-Level: X-Spam-Status: No, score=-7.586 tagged_above=-999 required=5 tests=[AWL=3.012, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1-pbZjGtKy8 for ; Tue, 2 Jul 2013 05:18:51 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 0A31B11E849C for ; Tue, 2 Jul 2013 05:18:51 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_p3tpH9cB/dyMRWAj6WzWaw)" Received: from relay4.apple.com ([17.128.113.87]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MPB003NL67EX1Q0@mail-out.apple.com> for http-auth@ietf.org; Tue, 02 Jul 2013 05:18:50 -0700 (PDT) X-AuditID: 11807157-b7f706d0000006c6-4d-51d2c5296465 Received: from [17.153.103.163] (Unknown_Domain [17.153.103.163]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay4.apple.com (Apple SCV relay) with SMTP id 50.FE.01734.A25C2D15; Tue, 02 Jul 2013 05:18:50 -0700 (PDT) From: Michael Sweet Date: Tue, 02 Jul 2013 08:18:49 -0400 To: "http-auth@ietf.org" Message-id: <36709D3E-3F41-4545-915F-3FEF57F0218E@apple.com> X-Mailer: Apple Mail (2.1508) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCLMWRmVeSWpSXmKPExsUiODN9sa7W0UuBBnv/GVp82D+HyeLIt1gH Jo+tJ3+weSxZ8pMpgCmKyyYlNSezLLVI3y6BK+Pw+knMBWfUKz4fmsrSwPhPsYuRk0NCwETi 1MFNTBC2mMSFe+vZuhi5OIQE+pkk2hZ+ZwZJsAmoSfye1McKYjMLJEi8Xz0DzGYRUJH4/KkF zBYWMJW4tOwgmC0ioCsxeW4zI4jNK2Aj0fvpNROErSex9N8coDgH0DJZiZ2/kyYwcs9CMnUW kiqIuLbEsoWvmWcBdTAL6EhMXogmDGF/PH+EaQEj2ypGgaLUnMRKE73EgoKcVL3k/NxNjKCw aigM38H4b5nVIUYBDkYlHl6FeRcDhVgTy4orcw8xSnAwK4nwcm+8FCjEm5JYWZValB9fVJqT WnyIUZqDRUmcN1kaKCWQnliSmp2aWpBaBJNl4uCUamDM3aMptPruw+XG68JEl5xPECi1Mm9o Vz33rDwkYt07Xp0tvBOqLRe9ZhFwjQ/WrfVpWhDLE3BL5b9p+NMniuEMfE4rMi8d5AtM3fmu 8EKRipYe17Z1nDO/p7qd3lD6+Z6PUlfgzfORry6Xr8s7fvJinOOtmslSRtJq2feMfxXd0v9z ZmuNZZISS3FGoqEWc1FxIgAx8cBTJwIAAA== Subject: [http-auth] Commands on draft-ietf-httpauth-extension-00 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 12:19:04 -0000 --Boundary_(ID_p3tpH9cB/dyMRWAj6WzWaw) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT All, Some quick comments on draft-ietf-httpauth-extension-00: - Section 3: Maybe include an example of a POST request with an Expect: 100-continue header, with the 100 response including the Optional-WWW-Authenticate response? This will have some interesting applications for printing/IPP. I'm also interested to see how a Client "aborts" the current POST/PUT request and re-submits with an Authorization header - sending an empty message body might be applicable for a POST, depending on the situation, but an empty PUT might has unpleasant side-effects. Closing the connection before sending the message body might be a clearer/cleaner signal to the Server, but seems a bit heavy-handed... - Section 4: Any reason to not allow multiple challenges here, a la 2616's WWW-Authenticate header? - Section 4.5: What about a logout-timeout value that indicates that credentials are discarded after the web browser session is closed/quit? HTTP cookies have this capability and is used on a regular basis. This is still independent of whether the browser/system caches usernames and passwords, it just forces user interaction at the beginning of a new session... Longer term I'd actually like to see something like this made mandatory for HTTP/2.0 since that is what will be needed to convince many to switch away from cookie-based approaches. _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Boundary_(ID_p3tpH9cB/dyMRWAj6WzWaw) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable

- Section 4: Any reason to not = allow multiple challenges here, a la 2616's WWW-Authenticate = header?

- Section 4.5: What about a = logout-timeout value that indicates that credentials are discarded after = the web browser session is closed/quit? HTTP cookies have this = capability and is used on a regular basis. This is still independent of = whether the browser/system caches usernames and passwords, it just = forces user interaction at the beginning of a new = session...

Longer term I'd actually like to see = something like this made mandatory for HTTP/2.0 since that is what will = be needed to convince many to switch away from cookie-based = approaches.

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

= --Boundary_(ID_p3tpH9cB/dyMRWAj6WzWaw)-- From stpeter@stpeter.im Tue Jul 2 05:32:10 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6118921F9F16 for ; Tue, 2 Jul 2013 05:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGMqE7VBbZNW for ; Tue, 2 Jul 2013 05:32:06 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 39C6E21F9EC0 for ; Tue, 2 Jul 2013 05:32:06 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D34014134D; Tue, 2 Jul 2013 06:32:35 -0600 (MDT) Message-ID: <51D2C83B.6070509@stpeter.im> Date: Tue, 02 Jul 2013 06:31:55 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Bjoern Hoehrmann References: <20130630142838.31885.15315.idtracker@ietfa.amsl.com> <51D04326.5060600@gmx.de> <51D09F98.2070508@gmail.com> <51D1175C.3020007@it.aoyama.ac.jp> <51D11AD4.5050705@gmx.de> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Julian Reschke , http-auth@ietf.org, Paul Hoffman Subject: Re: [http-auth] Normalization forms in draft-ietf-httpauth-basicauth-enc X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 12:32:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/2/13 3:58 AM, Bjoern Hoehrmann wrote: > * Julian Reschke wrote: >> So what if we mandated normalization to happen on the client? > > I see no benefit in the server receiving normalize("$user:$pass") > over receiving "$user:$pass" given that the server can and probably > has to do `normalize` on its own, e.g. during account creation or > password change, especially considering that `normalize` may vary > over time. I also note efforts like > . See also the in-process revisions to SASLprep, which might be more appropriate for this group: http://datatracker.ietf.org/doc/draft-ietf-precis-saslprepbis/ In the XMPP community, we originally used stringprep and are now transitioning to PRECIS. Also, we were not clear on exactly who is responsible for normalization and string preparation. We're cleaning that up in 6122bis (see Section 3): https://datatracker.ietf.org/doc/draft-ietf-xmpp-6122bis/ Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJR0sg7AAoJEOoGpJErxa2pKJUP/iT0UwNlotidULF4mfcwiCWv qyp1Ta66+vh7pzs8spEIqvnzW3Hph/gxpBztShJUSfnVRFkbisOxXqwiKy1j606Y C9h5Cqq9NUNSPwE36b1GBi7pEREGtRDN1glZaP9kC7rWPVvtqMvkRqnU3DOH0oUY faSXM8MJH5Pc7q4EmiKDVQTtNwpORpsDg5/4gpQG7/H8nMqh/xBKgl8VvCEW1YxZ uZjPXCGlKhIIXqENFMEYRbIBaeTFy4EnEKKvvTpuskW3JM2NMQVmyucDnqkQPYmT jfs4z2fMOnCPRPQk32kmD4k2mgtdz/HEFz40GuA+r7nfOZwdenM3ewD7S1C0dUYN JKooJ5DxxBHKvkbEw9m+JA8D1c3dwDKjO55M6Y7xrBh+ku5orkuxd1VvDZziNMSX mbcf5ay+mR9TmKFWLYEsHs8LnWsQXE/Sara2YXY6//IBefdoPnKadI80o4bxfi8Q 1wGl5A5a+NGDT0zhUOe0rlOSHVMHXd8trdXTXb5aVY12iZUadnDgGHNHUbVF6Xow cWg/rfyKzScJoT6FEdTrHlIfQo1hmHtHXRRFDflno1dP2kwfCJnhcW3+QYYam1zI ngWt5K9csNy+J1CkxmxM1Wd71nbPVei0Nw/SLPy6FU8j5wmkrppk7y1iaKmrv31c wrQ0O0wTdPUTvPmsKET5 =qbEn -----END PGP SIGNATURE----- From msweet@apple.com Tue Jul 2 05:50:14 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE91921F9C74 for ; Tue, 2 Jul 2013 05:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.963 X-Spam-Level: X-Spam-Status: No, score=-7.963 tagged_above=-999 required=5 tests=[AWL=2.635, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBNy6ARx8MuB for ; Tue, 2 Jul 2013 05:50:08 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id CB87B21F8651 for ; Tue, 2 Jul 2013 05:50:05 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_gYsjVnZfm3M/20+bsjD0xQ)" Received: from relay2.apple.com ([17.128.113.67]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MPB002YT7MNB4P1@mail-out.apple.com> for http-auth@ietf.org; Tue, 02 Jul 2013 05:50:05 -0700 (PDT) X-AuditID: 11807143-b7f856d000000818-e0-51d2cc7cd065 Received: from [17.153.103.163] (Unknown_Domain [17.153.103.163]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay2.apple.com (Apple SCV relay) with SMTP id 48.01.02072.D7CC2D15; Tue, 02 Jul 2013 05:50:05 -0700 (PDT) From: Michael Sweet Date: Tue, 02 Jul 2013 08:50:04 -0400 To: "http-auth@ietf.org" Message-id: <8C2D1DA6-6274-4BD2-9E30-D7DF7433B1C3@apple.com> X-Mailer: Apple Mail (2.1508) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMLMWRmVeSWpSXmKPExsUiODN9sW7tmUuBBu+Xqll82D+HyeLIt1gH Jo+tJ3+weSxZ8pMpgCmKyyYlNSezLLVI3y6BK+PDupesBauVK9quHGVsYNwq18XIySEhYCIx ra+RGcIWk7hwbz1bFyMXh5BAP5PEj973rCAJNgE1id+T+sBsZoEEiY2/tjGC2CwCKhJL7u9j 72Lk4BAWMJJ4/pULJCwioCsxeW4zWAmvgI3E81dH2CFsPYml/+YwgpRLCMhK7PydNIGRexaS obOQVEHEtSWWLXzNPAuog1lAR2LyQjRhCPvj+SNMCxjZVjEKFKXmJFYa6SUWFOSk6iXn525i BAVVQ6HzDsZjy6wOMQpwMCrx8J6YfTFQiDWxrLgy9xCjBAezkggv98ZLgUK8KYmVValF+fFF pTmpxYcYpTlYlMR5k6SBUgLpiSWp2ampBalFMFkmDk6pBsaWmZ0nMwU0mBZv3sAltYO1dlrS yq/rLJTvFAetXW9eHjQh4duKu6vkd3VGlaxXrFvNueJA+Vc+p1pOvc0N5WFXFVx3VusnTvfI 9Nj1Ounmw8BD+vU+xZlFLj8ku1Yq3pY4K80z8dvsZ0wH7riy/9q3sa4478ObpW3STz3jvdfx tot/7lJKmaXEUpyRaKjFXFScCADKKiLfJgIAAA== Subject: [http-auth] Comments on draft-ietf-httpauth-mutual-00 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 12:50:14 -0000 --Boundary_(ID_gYsjVnZfm3M/20+bsjD0xQ) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT All, Some quick comments on draft-ietf-httpauth-mutual-00: - Section 2.2: The example shows the server returning an Authentication-Info header with an "auth-scheme 1#auth-param" format, but RFC 2617 doesn't define it that way; see my comments on the SCRAM draft. - Section 3: Is the SHALL for the Authentication-Info header appropriate here? Seems like it would be better to reference the subsection defining the header and let it state any conformance requirements. - Section 4.1: Again, SHALL seems wrong here (as does "noticed"). Maybe: Every 401-INIT or 401-STALE message is a valid HTTP 401-status (Authentication Required) message that MUST contain a single "WWW-Authenticate" header containing a "reason" parameter in the challenge. - I don't see a (re)definition of the Authorization, Authentication-Info, or WWW-Authenticate headers in this document. Traditionally such sections are included with an ABNF fragment and any conformance requirements to make things explicit for implementors. - The examples all focus on GET requests. What about POST, PUT, and Expect: 100-continue? These are all important for form submissions and layered protocols like SOAP and IPP... (particularly IPP - need a way to avoid re-sending gigabytes of print data...) _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Boundary_(ID_gYsjVnZfm3M/20+bsjD0xQ) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable

- Section 3: Is the SHALL for the = Authentication-Info header appropriate here? Seems like  it would = be better to reference the subsection defining the header and let it = state any conformance requirements.

- Section = 4.1: Again, SHALL seems wrong here (as does "noticed"). =  Maybe:

  Every 401-INIT or 401-STALE = message is a valid HTTP 401-status (Authentication Required) message = that MUST contain a single "WWW-Authenticate" header containing a = "reason" parameter in the challenge.

- I don't = see a (re)definition of the Authorization, Authentication-Info, or = WWW-Authenticate headers in this document. Traditionally such sections = are included with an ABNF fragment and any conformance requirements = to make things explicit for = implementors.

- The examples all focus on = GET requests.  What about POST, PUT, and Expect: 100-continue? = These are all important for form submissions and layered protocols like = SOAP and IPP... (particularly IPP - need a way to avoid re-sending = gigabytes of print data...)

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

= --Boundary_(ID_gYsjVnZfm3M/20+bsjD0xQ)-- From msweet@apple.com Tue Jul 2 05:54:42 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58B1C21F9BA6 for ; Tue, 2 Jul 2013 05:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.49 X-Spam-Level: X-Spam-Status: No, score=-8.49 tagged_above=-999 required=5 tests=[AWL=2.109, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7I68L4+DWTOM for ; Tue, 2 Jul 2013 05:54:37 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 2EADD21F9B89 for ; Tue, 2 Jul 2013 05:54:21 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay4.apple.com ([17.128.113.87]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MPB008447TK36H0@mail-out.apple.com> for http-auth@ietf.org; Tue, 02 Jul 2013 05:54:15 -0700 (PDT) X-AuditID: 11807157-b7f706d0000006c6-d8-51d2cd76c3b4 Received: from [17.153.103.163] (Unknown_Domain [17.153.103.163]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay4.apple.com (Apple SCV relay) with SMTP id 47.59.01734.77DC2D15; Tue, 02 Jul 2013 05:54:15 -0700 (PDT) From: Michael Sweet In-reply-to: <42111C34-9B32-45B2-AC94-B18CE5CC081F@checkpoint.com> Date: Tue, 02 Jul 2013 08:54:14 -0400 Message-id: <0E8B9A8C-4869-4DCC-9296-46B2EEE1370B@apple.com> References: <20130630142838.31885.15315.idtracker@ietfa.amsl.com> <51D04326.5060600@gmx.de> <51D09F98.2070508@gmail.com> <51D1175C.3020007@it.aoyama.ac.jp> <51D11AD4.5050705@gmx.de> <42111C34-9B32-45B2-AC94-B18CE5CC081F@checkpoint.com> To: Yoav Nir X-Mailer: Apple Mail (2.1508) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCLMWRmVeSWpSXmKPExsUiODN9sW752UuBBnfPa1t82D+HyWLzwzes Fke+xVq8ONXL5MDisfXkDzaPy7OvM3l8+BjnsWTJT6YAligum5TUnMyy1CJ9uwSujGNTljAX TGOv+Pl+L0sD43vWLkYODgkBE4kL7+K6GDmBTDGJC/fWs3UxcnEICfQzSaz4uoQZJCEsECjR eOMwE4jNK6AnsfTfHEYQm1lAS+LGv5dgcTYBNYnfk/pYQWxOASeJ7S8OgsVZBFQkDm35ywJR Hy5xdcUxKFtbYtnC18wQM20kXt68CLX4N5PEqbWtYINEBJQkflydCXWorMTO30kTGPlnITlj FpIzZiEZu4CReRWjQFFqTmKliV5iQUFOql5yfu4mRlBYNhSG72D8t8zqEKMAB6MSD6/CvIuB QqyJZcWVuYcYJTiYlUR4uTdeChTiTUmsrEotyo8vKs1JLT7EKM3BoiTOmywNlBJITyxJzU5N LUgtgskycXBKNTCu5TWxPKw5R8ptpc+L8ouKgvd3KCs5lLZnxvfOXNb3bvfrZqMZJb9MvfvF VHtrk+MY97a8mrvUzuxIvaedn/i5F7/4tF4/nJb025zHYf6lwwHaV3k+dhim/DwYlujUauHr eI9p3aYEKQbH/W+lbT6wfrpmHndMdvbpra9DlnisezTfvvnQqhlKLMUZiYZazEXFiQDHcWIe RwIAAA== Cc: Julian Reschke , "http-auth@ietf.org" Subject: Re: [http-auth] Normalization forms in draft-ietf-httpauth-basicauth-enc X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 12:54:42 -0000 RFC 5198? On 2013-07-02, at 3:59 AM, Yoav Nir wrote: > Hi > > For those of us not so well versed in I18N issues, what do you mean by normalization? > > Is it just consolidating look-alike code points, like the multiple hyphens that exist in Unicode? > Does it also involve removing Arabic and Hebrew points? (I think Paul raised this one) > Does it involve removing diacritics? > Does it involve splitting combined characters (like U+00E6 into 'a' and 'e')? > Is there a standard we can point to and say "do this before comparing or hashing"? > > Thanks > > Yoav > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair From stpeter@stpeter.im Tue Jul 2 06:18:26 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E54F921F9CDC for ; Tue, 2 Jul 2013 06:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTSPgrt5B-5O for ; Tue, 2 Jul 2013 06:18:22 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA6421F9CF5 for ; Tue, 2 Jul 2013 06:18:22 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9B82D4134D; Tue, 2 Jul 2013 07:18:56 -0600 (MDT) Message-ID: <51D2D317.1050405@stpeter.im> Date: Tue, 02 Jul 2013 07:18:15 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Yoav Nir References: <20130630142838.31885.15315.idtracker@ietfa.amsl.com> <51D04326.5060600@gmx.de> <51D09F98.2070508@gmail.com> <51D1175C.3020007@it.aoyama.ac.jp> <51D11AD4.5050705@gmx.de> <42111C34-9B32-45B2-AC94-B18CE5CC081F@checkpoint.com> In-Reply-To: <42111C34-9B32-45B2-AC94-B18CE5CC081F@checkpoint.com> X-Enigmail-Version: 1.5.1 X-Enigmail-Draft-Status: 513 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Julian Reschke , "http-auth@ietf.org" Subject: Re: [http-auth] Normalization forms in draft-ietf-httpauth-basicauth-enc X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 13:18:27 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/2/13 1:59 AM, Yoav Nir wrote: > Hi > > For those of us not so well versed in I18N issues, what do you mean > by normalization? Martin described it already. You might find it useful to look at the slides I put together for a two-hour tutorial on internationalization at an IETF meeting a few years ago: https://stpeter.im/files/i18n-into.pdf Perhaps I need to offer that tutorial again? Or maybe turn it into a small book? > Is it just consolidating look-alike code points, like the multiple > hyphens that exist in Unicode? There is no complete solution to the problem of confusable characters. Here is a fun example for you: https://stpeter.im/journal/1420.html However, normalization takes care of some (but not all) instances of code points that look alike. > Does it also involve removing Arabic and Hebrew points? (I think > Paul raised this one) There is no reason to *remove* characters from left-to-right scripts. However, allowing them means you need to deal with interesting bidi issues. > Does it involve removing diacritics? Not necessarily -- why can't my username be saintandré or whatever? And *removing* diacritics might be problematic, if it implies that 'é' would be transformed to 'e' (thus introducing the possibility of additional false positives). > Does it involve splitting combined characters (like U+00E6 into 'a' > and 'e')? Actually, there is no decomposition of U+00E6 æ into 'a' and 'e' in Unicode. This might be counter-intuitive, but it's true. > Is there a standard we can point to and say "do this before > comparing or hashing"? I'd suggest looking carefully at SASLprep (RFC 4013) and its proposed replacement: http://datatracker.ietf.org/doc/draft-ietf-precis-saslprepbis/ If you have feedback on the latter, please post to the precis@ietf.org list: https://www.ietf.org/mailman/listinfo/precis Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJR0tMXAAoJEOoGpJErxa2ptSwP/iKfNqKsVsw+e2C8BSfkHhgw HWrqWOkbIfvmQyOCssdsEuw6+cjZCtyDpGYKbQIP1WulxFlvjTT7DxEaEkVExuFk kHYVc16AL0HxBBfMZlGAgtHQDm0J0P4FQ1V0A5JFckh31ZnE2lgbcF1aQGwHm0CS 58IY+4bMdZP7DFoKPSSU7p7DGw7dpacY9GdMGNAnCopPFfFsuaP2WEA7Q8P+HcEk 0nK7/ucc72DcagpzAFfXQ7MQ5TaMy1echSmw2w7SmuSr3KmYOaDqiEj17azTEKlX lwsfGnZ06Exd6Q1qgLfwmXJjmaa0bU2NWKOtsAMVbcKpSMUa3838KEynSxd/j5fT +2+t8KKAVf8uKs5wC6IEFn3qGeORbD4/q3v+GhLve9hksmu7OaIhQ8/EqpkyomUP cD6SU3DfFas2PSAynOWqkkHPOFPGaGrVGwn/9bQrtsXtC5rrlMphLLKngzD4Jf68 GeyJXYZ4GCp8K6xNAeiA9Tu9PVS3Cpvo1tgq2/c+oxVTAZc3PWCp7oUOfYxzG0c0 oLv7/Fwfio8PP94rRjWgD/iP7+ZVzMplA7FSL0tkYUtnLL/9zohlFZYmLgcZcTiZ vIkuCSY0o7hh6p2VVPFEgxFm4M0Y1WxkZe1C8FKL+S7/PBF6Xi4eUCkqx66EdrDF vS/SGLuK5sl4t81vXXjH =sP1o -----END PGP SIGNATURE----- From stpeter@stpeter.im Tue Jul 2 06:21:40 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88E1121F9A04 for ; Tue, 2 Jul 2013 06:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.453 X-Spam-Level: X-Spam-Status: No, score=-102.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Nk5cY1ROKFc for ; Tue, 2 Jul 2013 06:21:36 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 5635321F9A4C for ; Tue, 2 Jul 2013 06:21:33 -0700 (PDT) Received: from sjc-vpn5-1046.cisco.com (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A48A34134D; Tue, 2 Jul 2013 07:22:05 -0600 (MDT) Message-ID: <51D2D3D3.20209@stpeter.im> Date: Tue, 02 Jul 2013 07:21:23 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Yoav Nir References: <20130630142838.31885.15315.idtracker@ietfa.amsl.com> <51D04326.5060600@gmx.de> <51D09F98.2070508@gmail.com> <51D1175C.3020007@it.aoyama.ac.jp> <51D11AD4.5050705@gmx.de> <42111C34-9B32-45B2-AC94-B18CE5CC081F@checkpoint.com> <51D2D317.1050405@stpeter.im> In-Reply-To: <51D2D317.1050405@stpeter.im> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Julian Reschke , "http-auth@ietf.org" Subject: Re: [http-auth] Normalization forms in draft-ietf-httpauth-basicauth-enc X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 13:21:40 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/2/13 7:18 AM, Peter Saint-Andre wrote: > You might find it useful to look at the slides I put together for > a two-hour tutorial on internationalization at an IETF meeting a > few years ago: > > https://stpeter.im/files/i18n-into.pdf Oops, that is: https://stpeter.im/files/i18n-intro.pdf Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJR0tPTAAoJEOoGpJErxa2pdv0QAJcKOVe1AMM+BKRV62FMEyUn vbW9iPZ8j9IuMoH0ut1a37h1bWNVbwSj4/joRg7znYKj1X9pSthqJpgeQDtMhr4r Sr+3R4GM5Me3jwhP2TEIncIz/6TwG3INROtqtUIMmSJcpbTCJdox57TYG0hDp34w 9mD68Z1j2X70SxpYvbyJ8giU73iIqiFtBWf1UztpfcD03k9Rth8/xyYkXrUqG16b QnWomXvYk9N62NX22XMSILY0uIQZGcRoQcVEwvxUxrKbjKJ/aasiGaG2UhqIaD/d OhT5GCTlq5d5hDNGQnvbI5tw5lFdalF4ABNNU5YkKqvn42EQTbwVqV4UzhFUMQ1X 0XfCcss3sh6XcLZMqSVq+9DPeN8nm9ziW5Ddmcq/nCnuUn+gP/eBtaMZrQ08sDA/ uzMEflI+3imC9uh8sJ9S0gdPNei+QMrRwX2gUzexEL+UEMYV6+XLvtgnom95EBsU zKkS9YFa8AiUtKpGGuUfNZAkGqzjh9tpE1jic433z2MWzdGm09Tn3v5N7yezFOfv oBx8CYJO3ooAsc2bp4Siil7PevzNIibzkn8Gr30RrlFm7rc5gxTVoHZtjfAYy3+G quIaPA8Ma1VMHCGsUb0QxBYxhCuJmi3wmNMQ+6vnTFbpgzUhpMaynDhekQwJYi+/ QmBpcoO858VeWzvuW6ep =C5k9 -----END PGP SIGNATURE----- From derhoermi@gmx.net Tue Jul 2 06:52:30 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8DC721F9E49 for ; Tue, 2 Jul 2013 06:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8DuC2fXbmMLL for ; Tue, 2 Jul 2013 06:52:18 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 11C0321F9E48 for ; Tue, 2 Jul 2013 06:52:18 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.32]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MQKg6-1UoTef04xI-00TjwH for ; Tue, 02 Jul 2013 15:52:17 +0200 Received: (qmail invoked by alias); 02 Jul 2013 13:52:16 -0000 Received: from p5B2339F3.dip0.t-ipconnect.de (EHLO netb.Speedport_W_700V) [91.35.57.243] by mail.gmx.net (mp032) with SMTP; 02 Jul 2013 15:52:16 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1/I/Gw+L8rIUNTbB/hObeH2cUEo4hJYuJistdHYVt tgwnl46BH+kj8L From: Bjoern Hoehrmann To: Yoav Nir Date: Tue, 02 Jul 2013 15:52:14 +0200 Message-ID: References: <20130630142838.31885.15315.idtracker@ietfa.amsl.com> <51D04326.5060600@gmx.de> <51D09F98.2070508@gmail.com> <51D1175C.3020007@it.aoyama.ac.jp> <51D11AD4.5050705@gmx.de> In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: Julian Reschke , "" , Paul Hoffman Subject: Re: [http-auth] Normalization forms in draft-ietf-httpauth-basicauth-enc X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 13:52:31 -0000 * Yoav Nir wrote: >The group can decide to mandate one behavior (entirely server-side) for >basicauth, and something else for others (like maybe negotiate the kind >of normalization to perform). But I'd rather we use the same kind of >processing for all methods unless there's a good reason to do so. The specification in question cannot really require server-side normali- sation. It is entirely up to the server whether to authorize a client to access its resources. The server might treat user names case-sensitively or might reject passwords that are not in NFC form or do whatever else it feels like. You cannot make a black box test that would demonstrate non-compliance to such a requirement. This would rather note that use of certain combinations of characters can result in unexpected failures and various forms of normalisation and tolerances can be used to mitigate. I think it would be out of scope of the document to do much more and it would very likely delay and complicate deployment without a clear gain. There is of course the option to make sure the draft defines that user agents must treat certain unrecognized values for the charset parameter or multiple `WWW-Authenticate` headers for the same Basic realm such that servers have an option to opt into client-side normalization later, if the group decides on some common options. So, WWW-Authenticate: Basic realm="example", charset="UTF-8/NFCv6+" or WWW-Authenticate: Basic realm="example", charset="UTF-8", x="precis" WWW-Authenticate: Basic realm="example", charset="UTF-8" for instance. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From ynir@checkpoint.com Tue Jul 2 07:02:41 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13D0D21F9ED1 for ; Tue, 2 Jul 2013 07:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0mEMu+1Qzm0c for ; Tue, 2 Jul 2013 07:02:36 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 376D721F9ECF for ; Tue, 2 Jul 2013 07:02:35 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r62E2VRA013453; Tue, 2 Jul 2013 17:02:31 +0300 X-CheckPoint: {51D2DD77-F-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.48]) by IL-EX10.ad.checkpoint.com ([169.254.2.180]) with mapi id 14.02.0342.003; Tue, 2 Jul 2013 17:02:31 +0300 From: Yoav Nir To: Peter Saint-Andre Thread-Topic: [http-auth] Normalization forms in draft-ietf-httpauth-basicauth-enc Thread-Index: AQHOdh5ETg5sRT+nxkGECfC1vUWCXplPIdsAgACKwgCAASjzgIAAWSCAgAAMYAA= Date: Tue, 2 Jul 2013 14:02:31 +0000 Message-ID: <58223FFB-2395-45BF-8C6A-AF307E16FCEB@checkpoint.com> References: <20130630142838.31885.15315.idtracker@ietfa.amsl.com> <51D04326.5060600@gmx.de> <51D09F98.2070508@gmail.com> <51D1175C.3020007@it.aoyama.ac.jp> <51D11AD4.5050705@gmx.de> <42111C34-9B32-45B2-AC94-B18CE5CC081F@checkpoint.com> <51D2D317.1050405@stpeter.im> In-Reply-To: <51D2D317.1050405@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.56] x-kse-antivirus-interceptor-info: protection disabled x-cpdlp: 11fcfebbcead9940747fa55f7ac5acb516923f2bc3 Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Julian Reschke , "http-auth@ietf.org" Subject: Re: [http-auth] Normalization forms in draft-ietf-httpauth-basicauth-enc X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 14:02:41 -0000 DQpPbiBKdWwgMiwgMjAxMywgYXQgNDoxOCBQTSwgUGV0ZXIgU2FpbnQtQW5kcmUgPHN0cGV0ZXJA c3RwZXRlci5pbT4gd3JvdGU6DQoNCj4gLS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0t LQ0KPiBIYXNoOiBTSEExDQo+IA0KPiBPbiA3LzIvMTMgMTo1OSBBTSwgWW9hdiBOaXIgd3JvdGU6 DQo+PiBIaQ0KPj4gDQo+PiBGb3IgdGhvc2Ugb2YgdXMgbm90IHNvIHdlbGwgdmVyc2VkIGluIEkx OE4gaXNzdWVzLCB3aGF0IGRvIHlvdSBtZWFuDQo+PiBieSBub3JtYWxpemF0aW9uPw0KPiANCj4g TWFydGluIGRlc2NyaWJlZCBpdCBhbHJlYWR5Lg0KPiANCj4gWW91IG1pZ2h0IGZpbmQgaXQgdXNl ZnVsIHRvIGxvb2sgYXQgdGhlIHNsaWRlcyBJIHB1dCB0b2dldGhlciBmb3IgYQ0KPiB0d28taG91 ciB0dXRvcmlhbCBvbiBpbnRlcm5hdGlvbmFsaXphdGlvbiBhdCBhbiBJRVRGIG1lZXRpbmcgYSBm ZXcNCj4geWVhcnMgYWdvOg0KPiANCj4gaHR0cHM6Ly9zdHBldGVyLmltL2ZpbGVzL2kxOG4taW50 by5wZGYNCj4gDQo+IFBlcmhhcHMgSSBuZWVkIHRvIG9mZmVyIHRoYXQgdHV0b3JpYWwgYWdhaW4/ IE9yIG1heWJlIHR1cm4gaXQgaW50byBhDQo+IHNtYWxsIGJvb2s/DQoNCkV4Y2VsbGVudCByZXNv dXJjZS4gWWVhaCwgeW91IHNob3VsZC4NCg0KPj4gSXMgaXQganVzdCBjb25zb2xpZGF0aW5nIGxv b2stYWxpa2UgY29kZSBwb2ludHMsIGxpa2UgdGhlIG11bHRpcGxlDQo+PiBoeXBoZW5zIHRoYXQg ZXhpc3QgaW4gVW5pY29kZT8NCj4gDQo+IFRoZXJlIGlzIG5vIGNvbXBsZXRlIHNvbHV0aW9uIHRv IHRoZSBwcm9ibGVtIG9mIGNvbmZ1c2FibGUgY2hhcmFjdGVycy4NCj4gSGVyZSBpcyBhIGZ1biBl eGFtcGxlIGZvciB5b3U6DQo+IA0KPiBodHRwczovL3N0cGV0ZXIuaW0vam91cm5hbC8xNDIwLmh0 bWwNCj4gDQo+IEhvd2V2ZXIsIG5vcm1hbGl6YXRpb24gdGFrZXMgY2FyZSBvZiBzb21lIChidXQg bm90IGFsbCkgaW5zdGFuY2VzIG9mDQo+IGNvZGUgcG9pbnRzIHRoYXQgbG9vayBhbGlrZS4NCg0K Rm9yIG91ciBwYXJ0aWN1bGFyIHVzZSBjYXNlIHdlIG5lZWQgdGhlIHJlc3VsdHMgb2Ygbm9ybWFs aXphdGlvbiB0byBiZSBiaXQtZm9yLWJpdCBlcXVhbCwgYW5kIHRvIGdldCB0aGUgc2FtZSByZXN1 bHQgd2hlbiB0eXBpbmcgdGhlIG5hbWUgb3IgcGFzc3dvcmQgaW4gZGlmZmVyZW50IGJyb3dzZXJz IG9uIFBDcywgTWFjcywgYWxsIExpbnV4IGRpc3Ryb3MsIGFuZCBhbGwgc21hcnRwaG9uZXMgYW5k IHRhYmxldHMuIEFzIG1lbnRpb25lZCBlYXJsaWVyIGluIHRoaXMgdGhyZWFkLCB0aGVzZSBhcmUg bm90IGFsd2F5cyBpZGVudGljYWwuDQoNCj4+IERvZXMgaXQgYWxzbyBpbnZvbHZlIHJlbW92aW5n IEFyYWJpYyBhbmQgSGVicmV3IHBvaW50cz8gKEkgdGhpbmsNCj4+IFBhdWwgcmFpc2VkIHRoaXMg b25lKQ0KPiANCj4gVGhlcmUgaXMgbm8gcmVhc29uIHRvICpyZW1vdmUqIGNoYXJhY3RlcnMgZnJv bSBsZWZ0LXRvLXJpZ2h0IHNjcmlwdHMuDQo+IEhvd2V2ZXIsIGFsbG93aW5nIHRoZW0gbWVhbnMg eW91IG5lZWQgdG8gZGVhbCB3aXRoIGludGVyZXN0aW5nIGJpZGkNCj4gaXNzdWVzLg0KDQpUaGVy ZSBpcy4gSW4gRnJlbmNoLCBBbmRyw6kgaXMgY29ycmVjdCB3aGlsZSBBbmRyZSBpcyBzaW1wbHkg d3JvbmcuIEluIEFyYWJpYyBhbmQgSGVicmV3LCB0aGUgZGlhY3JpdGljcyBhcmUgcmVhZGluZyBh aWRzIHRoYXQgd2VyZSBib2x0ZWQgb24gdG8gYW4gZXhpc3Rpbmcgc2NyaXB0LiBUaGUgdGV4dCBp cyBmaW5lIHdpdGggYW5kIHdpdGhvdXQgdGhlbSwgc28gSSBjb3VsZCB1c2UgZWl0aGVyINeZ15XX kNeRIG9yINeZ15XWudeQ1rjXkSBmb3IgbXkgbmFtZSwgYW5kIGJvdGggd291bGQgYmUgcGVyZmVj dGx5IGZpbmUgYW5kIGluIHNvbWUgc2Vuc2UgZXF1aXZhbGVudC4gSXQncyBzdGlsbCBmaW5lIHRv IGRlY2lkZSB0aGF0IHRoZXNlIGZvcm1zIGFyZSBub3QgZXF1aXZhbGVudCBmb3Igb3VyIHB1cnBv c2VzLCBzbyBpZiB5b3UgdXNlZCBwb2ludHMgZm9yIHlvdXIgdXNlcm5hbWUgd2hlbiB5b3UgY3Jl YXRlZCBpdCwgeW91J2xsIGhhdmUgdG8gdXNlIHBvaW50cyBmb3JldmVyLg0KDQo+PiBEb2VzIGl0 IGludm9sdmUgcmVtb3ZpbmcgZGlhY3JpdGljcz8NCj4gDQo+IE5vdCBuZWNlc3NhcmlseSAtLSB3 aHkgY2FuJ3QgbXkgdXNlcm5hbWUgYmUgc2FpbnRhbmRyw6kgb3Igd2hhdGV2ZXI/DQo+IEFuZCAq cmVtb3ZpbmcqIGRpYWNyaXRpY3MgbWlnaHQgYmUgcHJvYmxlbWF0aWMsIGlmIGl0IGltcGxpZXMg dGhhdCAnw6knDQo+IHdvdWxkIGJlIHRyYW5zZm9ybWVkIHRvICdlJyAodGh1cyBpbnRyb2R1Y2lu ZyB0aGUgcG9zc2liaWxpdHkgb2YNCj4gYWRkaXRpb25hbCBmYWxzZSBwb3NpdGl2ZXMpLg0KDQpJ dCBhbGwgZ29lcyBiYWNrIHRvIHRoZSBrZXlib2FyZCB0aGUgdXNlciB1c2VzIHRvIGlucHV0IHVz ZXJuYW1lIGFuZCBwYXNzd29yZC4gSSBoYXZlIG5vIGlkZWEgaG93IHRvIHR5cGUgdGhlIGV4YW1w bGUgYWJvdmUgb24gV2luZG93cyBvciBvbiBhbnkgcGhvbmUuIEkganVzdCBkb24ndCBrbm93IHRo ZSBrZXkgY29tYmluYXRpb25zICh5ZXMsIEkgY291bGQgZ29vZ2xlIGl0KS4gU28gaGF2aW5nIHlv dXIgdXNlcm5hbWUgYmUgc2FpbnRhbmRyw6kgY291bGQgbGVhdmUgeW91IHVuYWJsZSB0byBsb2cg aW4gZnJvbSBzb21lIHBsYXRmb3Jtcy4gVGhlIGNhc2UgY291bGQgYmUgbWFkZSB0aGF0IHdlIG5l ZWQgc3Ryb25nZXIgbm9ybWFsaXphdGlvbiB0aGFuIG90aGVyIHVzZSBjYXNlcy4NCg0KPj4gRG9l cyBpdCBpbnZvbHZlIHNwbGl0dGluZyBjb21iaW5lZCBjaGFyYWN0ZXJzIChsaWtlIFUrMDBFNiBp bnRvICdhJw0KPj4gYW5kICdlJyk/DQo+IA0KPiBBY3R1YWxseSwgdGhlcmUgaXMgbm8gZGVjb21w b3NpdGlvbiBvZiBVKzAwRTYgw6YgaW50byAnYScgYW5kICdlJyBpbg0KPiBVbmljb2RlLiBUaGlz IG1pZ2h0IGJlIGNvdW50ZXItaW50dWl0aXZlLCBidXQgaXQncyB0cnVlLg0KPiANCj4+IElzIHRo ZXJlIGEgc3RhbmRhcmQgd2UgY2FuIHBvaW50IHRvIGFuZCBzYXkgImRvIHRoaXMgYmVmb3JlDQo+ PiBjb21wYXJpbmcgb3IgaGFzaGluZyI/DQo+IA0KPiBJJ2Qgc3VnZ2VzdCBsb29raW5nIGNhcmVm dWxseSBhdCBTQVNMcHJlcCAoUkZDIDQwMTMpIGFuZCBpdHMgcHJvcG9zZWQNCj4gcmVwbGFjZW1l bnQ6DQo+IA0KPiBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcHJl Y2lzLXNhc2xwcmVwYmlzLw0KPiANCj4gSWYgeW91IGhhdmUgZmVlZGJhY2sgb24gdGhlIGxhdHRl ciwgcGxlYXNlIHBvc3QgdG8gdGhlIHByZWNpc0BpZXRmLm9yZw0KPiBsaXN0Og0KPiANCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wcmVjaXMNCj4gDQo+IFBldGVyDQoN Cg== From internet-drafts@ietf.org Thu Jul 4 07:28:37 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E341B21F9FDA; Thu, 4 Jul 2013 07:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.5 X-Spam-Level: X-Spam-Status: No, score=-102.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q52m7xURpPf9; Thu, 4 Jul 2013 07:28:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6836021F9FCE; Thu, 4 Jul 2013 07:28:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130704142837.12467.96214.idtracker@ietfa.amsl.com> Date: Thu, 04 Jul 2013 07:28:37 -0700 Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-digest-encoding-00.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 14:28:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Hypertext Transfer Protocol Authenticatio= n Working Group of the IETF. Title : An Encoding Mechanism for HTTP Digest Authentication Author(s) : Rifaat Shekh-Yusef Filename : draft-ietf-httpauth-digest-encoding-00.txt Pages : 5 Date : 2013-07-04 Abstract: RFC2617 does not define how to treat non-ASCII characters with the "Digest" scheme. This document defines an extension to the "Digest" scheme, and two possible mechanisms that would allow the client and server to negotiate the proper character encoding support. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest-encoding There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-httpauth-digest-encoding-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rifaat.ietf@gmail.com Thu Jul 4 07:42:53 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A934221F9F97 for ; Thu, 4 Jul 2013 07:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9SH1RhuqQXU for ; Thu, 4 Jul 2013 07:42:53 -0700 (PDT) Received: from mail-oa0-x235.google.com (mail-oa0-x235.google.com [IPv6:2607:f8b0:4003:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 007A421F9F83 for ; Thu, 4 Jul 2013 07:42:52 -0700 (PDT) Received: by mail-oa0-f53.google.com with SMTP id k14so2071842oag.12 for ; Thu, 04 Jul 2013 07:42:49 -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=XPfrSCCiaVWCLfcTX5+SNOgt+9t2do4nNgrhuMtipPE=; b=0RVPdZaDYVihcGodB3j13LOUUMjKe5QojHqZXy6Z4mB9gy3QHZ0mUXX1K77FjHP5Ke +F7JqDvHtpVuji+Cwm8HOhqfoPRyVMo/Eoe6lOf84lPptJX+La19vo7ZNg6d23mNOUww 7GcGPFWrqVY/Ut82I8j/4oGxgQHIFODt/+5iwVMZmzvFeCtyRXzWCYF6FBVhCadF3FfN 5gPJsClucKEO9nCmM+n/2+dPLfclETwsx7WQMyh9b18oO+A9GxlQQSfL7nWM7Vae8rl8 1kra9ZzqzenAdZmHp8XjHhx5KsUlMkUbOskWteIbLFgA0wsVQJGU9nyZTkh/gSdufMKK 5jkQ== MIME-Version: 1.0 X-Received: by 10.182.205.138 with SMTP id lg10mr6477955obc.6.1372948969400; Thu, 04 Jul 2013 07:42:49 -0700 (PDT) Received: by 10.182.22.4 with HTTP; Thu, 4 Jul 2013 07:42:49 -0700 (PDT) Date: Thu, 4 Jul 2013 10:42:49 -0400 Message-ID: From: Rifaat Shekh-Yusef To: http-auth@ietf.org Content-Type: multipart/alternative; boundary=001a11c290b89dae3904e0b097df Subject: [http-auth] Digest Encoding X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 14:42:53 -0000 --001a11c290b89dae3904e0b097df Content-Type: text/plain; charset=ISO-8859-1 All, Based on the discussion on the mailing list it seems that people wanted to discuss the encoding issue in a separate *experimental* draft. So, I have just submitted the following draft: https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest-encoding/ The draft defines a new parameter and two possible mechanisms. The parameter and one of the mechanisms are identical to what was defined in draft-ietf-httpauth-basicauth-enc. The second mechanism take advantage of the fact that with Digest the user agent has the ability to respond to the server with the encoding it supports, which is not possible with the Basic scheme. I would appreciate any feedback on this draft. Regards, Rifaat --001a11c290b89dae3904e0b097df Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
All,

Based on the discussion on t= he mailing list it seems that people wanted to discuss the encoding issue i= n a separate *experimental* draft. So, I have just submitted the following = draft:

The draft defines= a new parameter and two possible mechanisms. The parameter and one of the = mechanisms are identical to what was defined in=A0draft-ietf-httpauth-basic= auth-enc.
The second mechanism take advantage of the fact that with Digest= the user agent has the ability to respond to the server with the encoding = it supports, which is not possible with the Basic scheme.

I would appreciate any feedback on this draft.

Regards,
=A0Rifaat

--001a11c290b89dae3904e0b097df-- From derhoermi@gmx.net Thu Jul 4 07:49:44 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAC2921F9607 for ; Thu, 4 Jul 2013 07:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xWsch10NiSKa for ; Thu, 4 Jul 2013 07:49:40 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 3B3F921F96D5 for ; Thu, 4 Jul 2013 07:49:40 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.19]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MF6cH-1V1fYI1xkp-00GExX for ; Thu, 04 Jul 2013 16:49:37 +0200 Received: (qmail invoked by alias); 04 Jul 2013 14:49:36 -0000 Received: from p5B2311E4.dip0.t-ipconnect.de (EHLO netb.Speedport_W_700V) [91.35.17.228] by mail.gmx.net (mp019) with SMTP; 04 Jul 2013 16:49:36 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1/xdtVWX8nxcik0cEqsI8Umu3Cdg1xzM76+cTUpis F2FM5YhRvbxbmO From: Bjoern Hoehrmann To: Rifaat Shekh-Yusef Date: Thu, 04 Jul 2013 16:49:36 +0200 Message-ID: References: In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: http-auth@ietf.org Subject: Re: [http-auth] Digest Encoding X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 14:49:44 -0000 * Rifaat Shekh-Yusef wrote: >Based on the discussion on the mailing list it seems that people wanted to >discuss the encoding issue in a separate *experimental* draft. So, I have >just submitted the following draft: >https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest-encoding/ > >The draft defines a new parameter and two possible mechanisms. The >parameter and one of the mechanisms are identical to what was defined >in draft-ietf-httpauth-basicauth-enc. >The second mechanism take advantage of the fact that with Digest the user >agent has the ability to respond to the server with the encoding it >supports, which is not possible with the Basic scheme. Could you clarify what purpose this is intended to serve? There is no interest in supporting character encodings other than UTF-8. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From rifaat.ietf@gmail.com Thu Jul 4 08:30:16 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57AAD21F9EB6 for ; Thu, 4 Jul 2013 08:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tCqzN4iKYMUO for ; Thu, 4 Jul 2013 08:30:15 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id E84C821F9E60 for ; Thu, 4 Jul 2013 08:30:14 -0700 (PDT) Received: by mail-ob0-f175.google.com with SMTP id xn12so1794397obc.34 for ; Thu, 04 Jul 2013 08:30:14 -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=XnfjH5hkEw2JsHmRqiD0acz/eA1Pbv7rgeduZs0tP4Q=; b=dd8VYV8RzCbEJsmscPZdtxb4w1SVMWpsVwcD9UDeeDLEYY+NlhKX/ilwuA05Wo4z9H AY2NfS4zP8PO+luXNyHH1OEEExiuelvNM3un2ZTSz/ECMGmES5siO+9S1MrUSod17Vkc x9jM0XuQaHaHnfAyk84GooPqx5q658CLxVNH2xwZJMZKLqQhkNdQzUvmdvclHPgV7RNk fRItvIGQ3ubBsDiJtj7jAwRXDLITPw2QlwwV192tK76zB5CqMCzCHW/JM1P7D8fXuPO0 QeiuhNKtMdHSWqqBDGMTVLVug6zPYNeXdisZNQn1rGRo2eQMos5gt3MkHXuFDRA43yim ZI7w== MIME-Version: 1.0 X-Received: by 10.60.123.10 with SMTP id lw10mr6622762oeb.102.1372951814399; Thu, 04 Jul 2013 08:30:14 -0700 (PDT) Received: by 10.182.22.4 with HTTP; Thu, 4 Jul 2013 08:30:14 -0700 (PDT) In-Reply-To: References: Date: Thu, 4 Jul 2013 11:30:14 -0400 Message-ID: From: Rifaat Shekh-Yusef To: Bjoern Hoehrmann Content-Type: multipart/alternative; boundary=047d7b5d49ce30eca404e0b14163 Cc: http-auth@ietf.org Subject: Re: [http-auth] Digest Encoding X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 15:30:16 -0000 --047d7b5d49ce30eca404e0b14163 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The purpose of this draft is to address the encoding issue for the *Digest* scheme, as draft-ietf-httpauth-basicauth-enc addresses only the Basic scheme. The draft has two possible mechanisms, one of them is exactly what you are alluding to, which is to use UTF-8, similar to the Basic mechanism. The other approach is more involved and allows for more flexibility of supporting more than just UTF-8. I wanted to get feedback from the community if this is needed for the Digest mechanism; if that is not needed then we can definitely remove the second approach. Regards, Rifaat On Thu, Jul 4, 2013 at 10:49 AM, Bjoern Hoehrmann wrote= : > * Rifaat Shekh-Yusef wrote: > >Based on the discussion on the mailing list it seems that people wanted = to > >discuss the encoding issue in a separate *experimental* draft. So, I hav= e > >just submitted the following draft: > >https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest-encoding/ > > > >The draft defines a new parameter and two possible mechanisms. The > >parameter and one of the mechanisms are identical to what was defined > >in draft-ietf-httpauth-basicauth-enc. > >The second mechanism take advantage of the fact that with Digest the use= r > >agent has the ability to respond to the server with the encoding it > >supports, which is not possible with the Basic scheme. > > Could you clarify what purpose this is intended to serve? There is no > interest in supporting character encodings other than UTF-8. > -- > Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 http://bjoern.hoehr= mann.de > Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 =B7 http://www.bjoernsworld= .de > 25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev= .de/ > --047d7b5d49ce30eca404e0b14163 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The purpose of this draft is to address the encoding issue for the *Diges= t* scheme, as draft-ietf-httpauth-basicauth-enc addresses only the Basic scheme.
The draft has two possible mechanisms, one of them is exactly what you are = alluding to, which is to use UTF-8, similar to the Basic mechanism.

The other= approach is more involved and allows for more flexibility of supporting mo= re than just UTF-8. I wanted to get feedback from the community if this is = needed for the Digest mechanism; if that is not needed then we can definite= ly remove the second approach.

Regards,
=A0Rifaat


On Thu, Jul 4, 2013 at= 10:49 AM, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:
* Ri= faat Shekh-Yusef wrote:
>Based on the discussion on the mailing list it seems that people wanted= to
>discuss the encoding issue in a separate *experimental* draft. So, I ha= ve
>just submitted the following draft:
>https://datatracker.ietf.org/doc/draft-ietf-ht= tpauth-digest-encoding/
>
>The draft defines a new parameter and two possible mechanisms. The
>parameter and one of the mechanisms are identical to what was defined >in draft-ietf-httpauth-basicauth-enc.
>The second mechanism take advantage of the fact that with Digest the us= er
>agent has the ability to respond to the server with the encoding it
>supports, which is not possible with the Basic scheme.

Could you clarify what purpose this is intended to serve? There= is no
interest in supporting character encodings other than UTF-8.
--
Bj=F6rn H=F6hrmann =B7 mailto:bjoern= @hoehrmann.de =B7 http://bjoern.hoehrmann.de
Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 =B7 http://www.bjoernsworld.de
25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev.de/

--047d7b5d49ce30eca404e0b14163-- From julian.reschke@gmx.de Thu Jul 4 10:52:10 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5675221F9E9B for ; Thu, 4 Jul 2013 10:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.805 X-Spam-Level: X-Spam-Status: No, score=-104.805 tagged_above=-999 required=5 tests=[AWL=-2.206, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9xQSF8j5SvT for ; Thu, 4 Jul 2013 10:52:04 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 3BBC221F9E58 for ; Thu, 4 Jul 2013 10:52:04 -0700 (PDT) Received: from [192.168.2.117] ([93.217.116.145]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LzLJR-1U80g42Plx-014Sk8; Thu, 04 Jul 2013 19:52:02 +0200 Message-ID: <51D5B63D.6090208@gmx.de> Date: Thu, 04 Jul 2013 19:51:57 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Rifaat Shekh-Yusef References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:272jTSczR9kxxy5UARx822RZJ/vvp7Y4d0XpmgpYYyqk1GTZsfg /aozo2fp9KDioSyVOYCJ88AngXJHdIhFnwPQ50v8DIe9aCfORRWkqsNphz+rVaAi7FPj63s MxakRoVK1skffn4IF+tveilJmIs7WojQ1LAFZKT92Fdu+M37nefmtWTvKK9dndrR9wRYKya 6VeD1Bwn4zpMf9ENqMKHQ== Cc: http-auth@ietf.org, Bjoern Hoehrmann Subject: Re: [http-auth] Digest Encoding X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 17:52:10 -0000 On 2013-07-04 17:30, Rifaat Shekh-Yusef wrote: > The purpose of this draft is to address the encoding issue for the > *Digest* scheme, as draft-ietf-httpauth-basicauth-enc addresses only the > Basic scheme. > The draft has two possible mechanisms, one of them is exactly what you > are alluding to, which is to use UTF-8, similar to the Basic mechanism. > > The other approach is more involved and allows for more flexibility of > supporting more than just UTF-8. I wanted to get feedback from the > community if this is needed for the Digest mechanism; if that is not > needed then we can definitely remove the second approach. > > Regards, > Rifaat I would strongly suggest to avoid any complexity that isn't needed. Best regards, Julian From rifaat.ietf@gmail.com Thu Jul 4 12:20:06 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91ADB21F9C85 for ; Thu, 4 Jul 2013 12:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vO4K8OCA+pEe for ; Thu, 4 Jul 2013 12:20:05 -0700 (PDT) Received: from mail-oa0-x233.google.com (mail-oa0-x233.google.com [IPv6:2607:f8b0:4003:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 87C3421F9C50 for ; Thu, 4 Jul 2013 12:20:02 -0700 (PDT) Received: by mail-oa0-f51.google.com with SMTP id i4so2372700oah.10 for ; Thu, 04 Jul 2013 12:20:02 -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=m9n0/sycBRyqImQn5lGQdFe/HJQ9G06ldvjnHO86Tyg=; b=aZ3yPpHyE7cpM5o4AalLhrDLFwHFeDM0qBnQPd0PcScBfjwvp40nThisxCdUGFbPzp Qzio7g+ufHWrQW/g/KwUIEYpkewparKpeftGgtYFJRW7UvOEeSx/CDsgkp+8E3grfMOR tuE9nszmOrsCdO1UqJoBDnjUH00wCb2402WQRbx/Bkg8ID/Pilp7/fke/lwFs9+uMO8G 6OOOnBv0TMoNA1EGXxoSx5uWnFlxS4QUE4y1A+jpUyQcZfENqOF0NGjHJLIc1rVwzA8P QYXOiOe1wD1Su++AWE8hT7URWqBLVkfpM0BTSRHaIMfaTF2tVk1FUgGRMaDP/kQ8vp/m /39A== MIME-Version: 1.0 X-Received: by 10.182.66.46 with SMTP id c14mr7704239obt.33.1372965602012; Thu, 04 Jul 2013 12:20:02 -0700 (PDT) Received: by 10.182.22.4 with HTTP; Thu, 4 Jul 2013 12:20:01 -0700 (PDT) In-Reply-To: <51D5B63D.6090208@gmx.de> References: <51D5B63D.6090208@gmx.de> Date: Thu, 4 Jul 2013 15:20:01 -0400 Message-ID: From: Rifaat Shekh-Yusef To: Julian Reschke Content-Type: multipart/alternative; boundary=e89a8fb200e6ff31a004e0b47617 Cc: http-auth@ietf.org, Bjoern Hoehrmann Subject: Re: [http-auth] Digest Encoding X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 19:20:06 -0000 --e89a8fb200e6ff31a004e0b47617 Content-Type: text/plain; charset=ISO-8859-1 Hi Julian, There are two main differences between the Server Indicated Encoding mechanism and the Negotiated Encoding mechanism: 1. The Negotiated Encoding mechanism does not specify any required encoding in the current version of the draft; we could change that and specify UTF-8 as the default encoding. 2. The Negotiated Encoding mechanism asks the browser to provide an indication back to the server. That indication from the browser would allow the server to decline the request immediately without any further processing if the client does not support the encoding indicated by the server. Existing servers will not get the indication because the browser is expected to send it only if it received the parameter from the server. What is the complexity you see with this? Regards, Rifaat On Thu, Jul 4, 2013 at 1:51 PM, Julian Reschke wrote: > On 2013-07-04 17:30, Rifaat Shekh-Yusef wrote: > >> The purpose of this draft is to address the encoding issue for the >> *Digest* scheme, as draft-ietf-httpauth-basicauth-**enc addresses only >> the >> Basic scheme. >> The draft has two possible mechanisms, one of them is exactly what you >> are alluding to, which is to use UTF-8, similar to the Basic mechanism. >> >> The other approach is more involved and allows for more flexibility of >> supporting more than just UTF-8. I wanted to get feedback from the >> community if this is needed for the Digest mechanism; if that is not >> needed then we can definitely remove the second approach. >> >> Regards, >> Rifaat >> > > I would strongly suggest to avoid any complexity that isn't needed. > > Best regards, Julian > --e89a8fb200e6ff31a004e0b47617 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Julian,

There are = two main differences between the Server Indicated Encoding mechanism and th= e Negotiated Encoding mechanism:
1. The Negotiated Encoding mechani= sm does not specify any required encoding in the current version of the dra= ft; we could change that and specify UTF-8 as the default encoding.
2. The=A0Negotiated Encoding mechanism asks the browser to provide an = indication back to the server. That indication from the browser would allow= the server to decline the request=A0immediately=A0without any further=A0pr= ocessing if the client does not support the encoding indicated by the serve= r. Existing servers will not get the indication because the browser is expe= cted to send it only if it received the parameter from the server.

What is the complexity=A0you see with this?
=

Regards,
=A0Rifaat





On Thu, Jul 4, 2013 at 1:51 PM, Julian R= eschke <julian.reschke@gmx.de> wrote:
On 2013-07-04 17:30, Rifaat Shekh-Yusef wrote:
The purpose of this draft is to address the encoding issue for the
*Digest* scheme, as draft-ietf-httpauth-basicauth-enc addresses only= the
Basic scheme.
The draft has two possible mechanisms, one of them is exactly what you
are alluding to, which is to use UTF-8, similar to the Basic mechanism.

The other approach is more involved and allows for more flexibility of
supporting more than just UTF-8. I wanted to get feedback from the
community if this is needed for the Digest mechanism; if that is not
needed then we can definitely remove the second approach.

Regards,
=A0 Rifaat

I would strongly suggest to avoid any complexity that isn't needed.

Best regards, Julian

--e89a8fb200e6ff31a004e0b47617-- From julian.reschke@gmx.de Thu Jul 4 13:42:08 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 542AA11E81C9 for ; Thu, 4 Jul 2013 13:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.584 X-Spam-Level: X-Spam-Status: No, score=-104.584 tagged_above=-999 required=5 tests=[AWL=-1.985, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eb8jLnPG37pA for ; Thu, 4 Jul 2013 13:42:02 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4150411E8196 for ; Thu, 4 Jul 2013 13:42:02 -0700 (PDT) Received: from [192.168.2.117] ([93.217.104.226]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LxPuE-1UAztu15rO-016v3Z; Thu, 04 Jul 2013 22:41:57 +0200 Message-ID: <51D5DE12.4020300@gmx.de> Date: Thu, 04 Jul 2013 22:41:54 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Rifaat Shekh-Yusef References: <51D5B63D.6090208@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:+1rkgNMc2jtAu7NKke6zeJCTJDDqGz/Rz6WM3wJfJhbhPgva8ln yfZu4ddvm0DXkZvkaf5q/cXSgZ1E6G5gwWzYVuUiTE/GNlif6XMaRa3Om36JnX1gIZqAH8U /g7E5wiLE1K6q81Ow9MWqbRwAVhG5yDFN/y/wK0gUp8XZXcWUybPHz6wYEPtGH+e/FkI0vq toGuDy8hphST16hLYGDCg== Cc: http-auth@ietf.org, Bjoern Hoehrmann Subject: Re: [http-auth] Digest Encoding X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 20:42:08 -0000 On 2013-07-04 21:20, Rifaat Shekh-Yusef wrote: > Hi Julian, > > There are two main differences between the Server Indicated Encoding > mechanism and the Negotiated Encoding mechanism: > 1. The Negotiated Encoding mechanism does not specify any required > encoding in the current version of the draft; we could change that and > specify UTF-8 as the default encoding. You can't make it the default unless it's the default already, or all UAs are willing to switch. > 2. The Negotiated Encoding mechanism asks the browser to provide an > indication back to the server. That indication from the browser would > allow the server to decline the request immediately without any > further processing if the client does not support the encoding indicated > by the server. Existing servers will not get the indication because the > browser is expected to send it only if it received the parameter from > the server. > > What is the complexity you see with this? Having the indication -> good. Allowing anything except UTF-8 -> not needed. Best regards, Julian From paul.hoffman@vpnc.org Thu Jul 4 19:11:56 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8125511E80D9 for ; Thu, 4 Jul 2013 19:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vO+2-iLxOrt4 for ; Thu, 4 Jul 2013 19:11:55 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 2858221F9E08 for ; Thu, 4 Jul 2013 19:11:55 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-228.dsl.dynamic.sonic.net [50.1.98.228]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r652Bpat026636 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 4 Jul 2013 19:11:53 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <51D5DE12.4020300@gmx.de> Date: Thu, 4 Jul 2013 19:11:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51D5B63D.6090208@gmx.de> <51D5DE12.4020300@gmx.de> To: "http-auth@ietf.org" X-Mailer: Apple Mail (2.1508) Subject: Re: [http-auth] Digest Encoding X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 02:11:56 -0000 On Jul 4, 2013, at 1:41 PM, Julian Reschke = wrote: > Having the indication -> good. Allowing anything except UTF-8 -> not = needed. +1 --Paul Hoffman= From duerst@it.aoyama.ac.jp Thu Jul 4 21:44:45 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 503AC21F93E5 for ; Thu, 4 Jul 2013 21:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.59 X-Spam-Level: X-Spam-Status: No, score=-103.59 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id URujeXXSP1yy for ; Thu, 4 Jul 2013 21:44:40 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 75BD821F99E3 for ; Thu, 4 Jul 2013 21:44:39 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r654iSKM023071; Fri, 5 Jul 2013 13:44:28 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 048f_f706_933585ce_e52d_11e2_8d14_001e6722eec2; Fri, 05 Jul 2013 13:44:27 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id ACAFBBFC2B; Fri, 5 Jul 2013 13:42:50 +0900 (JST) Message-ID: <51D64F19.7020907@it.aoyama.ac.jp> Date: Fri, 05 Jul 2013 13:44:09 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Rifaat Shekh-Yusef References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: http-auth@ietf.org, Bjoern Hoehrmann Subject: Re: [http-auth] Digest Encoding X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 04:44:45 -0000 I agree with Bj=C3=B6rn. Please make it UTF-8 only, and save everybody so= me=20 pain. In this day and age, that's the only reasonable solution. Regards, Martin. On 2013/07/05 0:30, Rifaat Shekh-Yusef wrote: > The purpose of this draft is to address the encoding issue for the *Dig= est* > scheme, as draft-ietf-httpauth-basicauth-enc addresses only the Basic > scheme. > The draft has two possible mechanisms, one of them is exactly what you = are > alluding to, which is to use UTF-8, similar to the Basic mechanism. > > The other approach is more involved and allows for more flexibility of > supporting more than just UTF-8. I wanted to get feedback from the > community if this is needed for the Digest mechanism; if that is not ne= eded > then we can definitely remove the second approach. > > Regards, > Rifaat > > > On Thu, Jul 4, 2013 at 10:49 AM, Bjoern Hoehrmann w= rote: > >> * Rifaat Shekh-Yusef wrote: >>> Based on the discussion on the mailing list it seems that people want= ed to >>> discuss the encoding issue in a separate *experimental* draft. So, I = have >>> just submitted the following draft: >>> https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest-encoding/ >>> >>> The draft defines a new parameter and two possible mechanisms. The >>> parameter and one of the mechanisms are identical to what was defined >>> in draft-ietf-httpauth-basicauth-enc. >>> The second mechanism take advantage of the fact that with Digest the = user >>> agent has the ability to respond to the server with the encoding it >>> supports, which is not possible with the Basic scheme. >> >> Could you clarify what purpose this is intended to serve? There is no >> interest in supporting character encodings other than UTF-8. >> -- >> Bj=C3=B6rn H=C3=B6hrmann =C2=B7 mailto:bjoern@hoehrmann.de =C2=B7 http= ://bjoern.hoehrmann.de >> Am Badedeich 7 =C2=B7 Telefon: +49(0)160/4415681 =C2=B7 http://www.bjo= ernsworld.de >> 25899 Dageb=C3=BCll =C2=B7 PGP Pub. KeyID: 0xA4357E78 =C2=B7 http://ww= w.websitedev.de/ >> > > > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth From stpeter@stpeter.im Fri Jul 5 05:03:50 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9306711E82B4 for ; Fri, 5 Jul 2013 05:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uF9zBZUU6ko9 for ; Fri, 5 Jul 2013 05:03:46 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 52A6E11E82B1 for ; Fri, 5 Jul 2013 05:03:46 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 86C9D41384; Fri, 5 Jul 2013 06:04:35 -0600 (MDT) Message-ID: <51D6B620.6070602@stpeter.im> Date: Fri, 05 Jul 2013 06:03:44 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= References: <51D64F19.7020907@it.aoyama.ac.jp> In-Reply-To: <51D64F19.7020907@it.aoyama.ac.jp> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: http-auth@ietf.org, Bjoern Hoehrmann Subject: Re: [http-auth] Digest Encoding X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 12:03:50 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/4/13 10:44 PM, "Martin J. Dürst" wrote: > I agree with Björn. Please make it UTF-8 only, and save everybody > some pain. In this day and age, that's the only reasonable > solution. +1 Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJR1rYgAAoJEOoGpJErxa2pGoQP/22I33drVYj6FNhvt0S8GW0w n9dN1viiYkhB3KSs0/H5dUH+wajXi5jkJDBNxdBysnhs3LWZk8RpZxuHHABA7Aip TRYLL9OJYAp2GHpat80mMSJ205WCYbSe3GzIC5g7l1Hu8lAOhzvQ+xm9VRQ0EG4S GHtwc5a+W7Qpc24lA9QzEfQHKIuqAUgPs8NxSeuXv3L8l7j+fWDdVwzj+oKx2nI+ 3zKQTkxgpVB7h13yvlAkh2n14Iz0bAJVSdoMedZMTLhFjcN/BbrMNNXleA9KPOma hYd7N1JWVbDUSbxDARNMa4b3HB3m3cB57lJ8ShU2o+ookzCwIIDEYvqxIiTDv0L+ aEcvZjXnuR1J/H2PP9zujrQ3QHPwIQPiJGrudeIRyoC8y1UnEMZIb1NT9AX/JeNh pBTloA06SjTi8mahPT8zvulIvmf1jQInORdPuCHbmZKFjX4TyQntMEl/zOLN3Qof lZrhlEG0c75bnK8w0nB1kyCmOiPJPwDE///97cS7M8gyztpm/732WK1DvZBSUky3 5v01M7BWJBK5gneTXq7e6KgeowTsn4gTlRl0It6dzOwNwbPxD12rA617Ft1s6/+h SC+l3mZZ5gBhk1Bf9UthUYRT7vgL/rlRIzPGZK2jCqxGnd7fhWn3jNtDIm7uqTXN fP+3nkCPPu8ZZtIyC+nv =1lyE -----END PGP SIGNATURE----- From internet-drafts@ietf.org Fri Jul 5 06:09:54 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CFDD11E82CC; Fri, 5 Jul 2013 06:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.511 X-Spam-Level: X-Spam-Status: No, score=-102.511 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13fB5-fF8i6F; Fri, 5 Jul 2013 06:09:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ECC2211E82C3; Fri, 5 Jul 2013 06:09:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130705130953.13877.16120.idtracker@ietfa.amsl.com> Date: Fri, 05 Jul 2013 06:09:53 -0700 Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-digest-encoding-01.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 13:09:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Hypertext Transfer Protocol Authenticatio= n Working Group of the IETF. Title : An Encoding Mechanism for HTTP Digest Authentication Author(s) : Rifaat Shekh-Yusef Filename : draft-ietf-httpauth-digest-encoding-01.txt Pages : 5 Date : 2013-07-05 Abstract: RFC2617 does not define how to treat non-ASCII characters with the "Digest" scheme. This document defines an extension to the "Digest" scheme, and a mechanism that would allow the client and server to negotiate the proper character encoding support. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest-encoding There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-httpauth-digest-encoding-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-httpauth-digest-encoding-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rifaat.ietf@gmail.com Fri Jul 5 06:12:30 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E87011E82DE for ; Fri, 5 Jul 2013 06:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZK-iHtFNelr for ; Fri, 5 Jul 2013 06:12:29 -0700 (PDT) Received: from mail-oa0-x22b.google.com (mail-oa0-x22b.google.com [IPv6:2607:f8b0:4003:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 04C6A11E82C4 for ; Fri, 5 Jul 2013 06:12:28 -0700 (PDT) Received: by mail-oa0-f43.google.com with SMTP id i7so3296026oag.2 for ; Fri, 05 Jul 2013 06:12:28 -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=oWBi1I8MDua6hdExTVWh3oY4GMSdB6pHDEgfryMqpQo=; b=T9dphwoyFsJZVsR27YGklfG5HNMMstigwH7xe7wbbvMOD5F+RaI1SAyEMDAslcYIsr wEyhumGjva1ZNQuYgxucLw4/mh6feobPKRuDZvQKoRgOlKyKWe9zrMus7RQ7T/YlQS8O CPVxiEFJxryC2oV76TCVvCydizGcuZHTqhjpQfXpePXK/+UP0DxdeVLtBldo6ZzsNiJC QF+VBRZA7riSKdWqxGbjRZE4SwuwuLIUU8ifAI2ChSHfJJ8WTSfcjhxaRMP06rPuqJXO WZfTzq9KhlmTVW7aK89LqyhpMnZMnk5hn/8z0TMj1SsDF4TrHjoQTqF67xZq6zWt5rob 9q6Q== MIME-Version: 1.0 X-Received: by 10.60.123.10 with SMTP id lw10mr10868801oeb.102.1373029948470; Fri, 05 Jul 2013 06:12:28 -0700 (PDT) Received: by 10.182.22.4 with HTTP; Fri, 5 Jul 2013 06:12:28 -0700 (PDT) In-Reply-To: <51D6B620.6070602@stpeter.im> References: <51D64F19.7020907@it.aoyama.ac.jp> <51D6B620.6070602@stpeter.im> Date: Fri, 5 Jul 2013 09:12:28 -0400 Message-ID: From: Rifaat Shekh-Yusef To: Peter Saint-Andre Content-Type: multipart/alternative; boundary=047d7b5d49ce583b1504e0c372f2 Cc: http-auth@ietf.org, Bjoern Hoehrmann Subject: Re: [http-auth] Digest Encoding X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 13:12:30 -0000 --047d7b5d49ce583b1504e0c372f2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thank you all for your feedback. I have just submitted a new version of the draft that hopefully addresses all the comments I received so far. http://www.ietf.org/id/draft-ietf-httpauth-digest-encoding-01.txt Please, take a look and let me know if you have any more comments. Regards, Rifaat On Fri, Jul 5, 2013 at 8:03 AM, Peter Saint-Andre wrote= : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 7/4/13 10:44 PM, "Martin J. D=FCrst" wrote: > > I agree with Bj=F6rn. Please make it UTF-8 only, and save everybody > > some pain. In this day and age, that's the only reasonable > > solution. > > +1 > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.19 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJR1rYgAAoJEOoGpJErxa2pGoQP/22I33drVYj6FNhvt0S8GW0w > n9dN1viiYkhB3KSs0/H5dUH+wajXi5jkJDBNxdBysnhs3LWZk8RpZxuHHABA7Aip > TRYLL9OJYAp2GHpat80mMSJ205WCYbSe3GzIC5g7l1Hu8lAOhzvQ+xm9VRQ0EG4S > GHtwc5a+W7Qpc24lA9QzEfQHKIuqAUgPs8NxSeuXv3L8l7j+fWDdVwzj+oKx2nI+ > 3zKQTkxgpVB7h13yvlAkh2n14Iz0bAJVSdoMedZMTLhFjcN/BbrMNNXleA9KPOma > hYd7N1JWVbDUSbxDARNMa4b3HB3m3cB57lJ8ShU2o+ookzCwIIDEYvqxIiTDv0L+ > aEcvZjXnuR1J/H2PP9zujrQ3QHPwIQPiJGrudeIRyoC8y1UnEMZIb1NT9AX/JeNh > pBTloA06SjTi8mahPT8zvulIvmf1jQInORdPuCHbmZKFjX4TyQntMEl/zOLN3Qof > lZrhlEG0c75bnK8w0nB1kyCmOiPJPwDE///97cS7M8gyztpm/732WK1DvZBSUky3 > 5v01M7BWJBK5gneTXq7e6KgeowTsn4gTlRl0It6dzOwNwbPxD12rA617Ft1s6/+h > SC+l3mZZ5gBhk1Bf9UthUYRT7vgL/rlRIzPGZK2jCqxGnd7fhWn3jNtDIm7uqTXN > fP+3nkCPPu8ZZtIyC+nv > =3D1lyE > -----END PGP SIGNATURE----- > --047d7b5d49ce583b1504e0c372f2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thank you all for your feedback.
I have just sub= mitted a new version of the draft that hopefully addresses all the comments= I received so far.

Please, take a look and let me know i= f you have any more comments.

Regards,=
=A0Rifaat



On Fri, Jul 5, 2013 at 8:03 AM, Peter Sa= int-Andre <stpeter@stpeter.im> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 7/4/13 10:44 PM, "Martin J. D=FCrst" wrote:
> I agree with Bj=F6rn. Please make it UTF-8 only, and save everybody > some pain. In this day and age, that's the only reasonable
> solution.

+1

Peter

- --
Peter Saint-Andre
https://stpeter.im/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http:= //gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJR1rYgAAoJEOoGpJErxa2pGoQP/22I33drVYj6FNhvt0S8GW0w
n9dN1viiYkhB3KSs0/H5dUH+wajXi5jkJDBNxdBysnhs3LWZk8RpZxuHHABA7Aip
TRYLL9OJYAp2GHpat80mMSJ205WCYbSe3GzIC5g7l1Hu8lAOhzvQ+xm9VRQ0EG4S
GHtwc5a+W7Qpc24lA9QzEfQHKIuqAUgPs8NxSeuXv3L8l7j+fWDdVwzj+oKx2nI+
3zKQTkxgpVB7h13yvlAkh2n14Iz0bAJVSdoMedZMTLhFjcN/BbrMNNXleA9KPOma
hYd7N1JWVbDUSbxDARNMa4b3HB3m3cB57lJ8ShU2o+ookzCwIIDEYvqxIiTDv0L+
aEcvZjXnuR1J/H2PP9zujrQ3QHPwIQPiJGrudeIRyoC8y1UnEMZIb1NT9AX/JeNh
pBTloA06SjTi8mahPT8zvulIvmf1jQInORdPuCHbmZKFjX4TyQntMEl/zOLN3Qof
lZrhlEG0c75bnK8w0nB1kyCmOiPJPwDE///97cS7M8gyztpm/732WK1DvZBSUky3
5v01M7BWJBK5gneTXq7e6KgeowTsn4gTlRl0It6dzOwNwbPxD12rA617Ft1s6/+h
SC+l3mZZ5gBhk1Bf9UthUYRT7vgL/rlRIzPGZK2jCqxGnd7fhWn3jNtDIm7uqTXN
fP+3nkCPPu8ZZtIyC+nv
=3D1lyE
-----END PGP SIGNATURE-----

--047d7b5d49ce583b1504e0c372f2-- From rifaat.ietf@gmail.com Fri Jul 5 07:17:24 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A94F11E82FD for ; Fri, 5 Jul 2013 07:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ed-h2DUFdLWU for ; Fri, 5 Jul 2013 07:17:23 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id BBA8C11E82F6 for ; Fri, 5 Jul 2013 07:17:23 -0700 (PDT) Received: by mail-ob0-f169.google.com with SMTP id up14so2950141obb.0 for ; Fri, 05 Jul 2013 07:17:21 -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=axiKy+xnZnt4G7j1FXE/QONIiPi6CYdVVxQqHRqVaLc=; b=RXX39qyKGKlNbb+5+J0Krv8KpNUxEpzoV99kAOm496EPT//b2PQTknO67rWqsNS0xT OijF4LEpPlTRDb/e3Odu2QryeQiJ38UG1wq0BXNCeqXS8NgLk42gzulYjoPCUmorQa/V nqQr/2ggC9s4XcZdBqUIDV0bORHsZdeAxy6vtFtMl6vb/+pDfXXHYC2ddgVUWcF5d4EU M0CSNwE/KjnpQXBiewasyAyDiG7NwYxjveieWoX/E4DU4dg8nh+gy8LBXPA2acWtbt39 iWUiLT/nqDg0iHI4AlkEb97arSgRgtV/PENPxu6H6DQCO3i8K2Z+mqUnNdXFiBLldyOi 483g== MIME-Version: 1.0 X-Received: by 10.182.81.202 with SMTP id c10mr11332648oby.27.1373033841200; Fri, 05 Jul 2013 07:17:21 -0700 (PDT) Received: by 10.182.22.4 with HTTP; Fri, 5 Jul 2013 07:17:21 -0700 (PDT) Date: Fri, 5 Jul 2013 10:17:21 -0400 Message-ID: From: Rifaat Shekh-Yusef To: http-auth@ietf.org Content-Type: multipart/alternative; boundary=047d7b2e47f45e944e04e0c45ad7 Subject: Re: [http-auth] Digest Update - 02 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 14:17:24 -0000 --047d7b2e47f45e944e04e0c45ad7 Content-Type: text/plain; charset=ISO-8859-1 I did not see any comment around this version of the draft. Are people satisfied with version 2? Regards, Rifaat ** ** > > *From:* http-auth-bounces@ietf.org [mailto:http-auth-bounces@ietf.org] *On > Behalf Of *Shekh-Yusef, Rifaat (Rifaat) > *Sent:* Sunday, June 30, 2013 6:44 AM > *To:* http-auth@ietf.org > *Subject:* [http-auth] Digest Update - 02**** > > ** ** > > We have just submitted a new version of the Digest Update draft:**** > > http://www.ietf.org/id/draft-ietf-httpauth-digest-update-02.txt**** > > ** ** > > ** ** > > The new draft has the following changes:**** > > > > **** > > 1. Changed the list of algorithms, as follows: SHA2-256 (default), > SHA3-256 (backup), and MD5 (for backward compatibility), based on the > discussion on the mailing list.**** > > > > **** > > 2. New text in the limitation section based on the discussion on the > mailing list with feedback from Yaron Sheffer and Stephen Farrell.**** > > > > **** > > 3. New section (section 2) around syntax convention.**** > > > > **** > > > > **** > > We would appreciate your feedback on the new draft.**** > > > > **** > > Thanks,**** > > Rifaat**** > > > Sent from my iPhone**** > --047d7b2e47f45e944e04e0c45ad7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I did not see any comment around this version of the draft= . Are people=A0satisfied=A0with version 2?
Regards,
=A0Rifaat

=A0<= /p>

From: http-auth-bounces@= ietf.org [mailto:http-auth-bounces@ietf.org] On Behalf Of Shekh-Yusef, Rifaat (Rifaat)
Sent: Sunday, June 30, 2013 6:44 AM
To: http-aut= h@ietf.org
Subject: [http-auth] Digest Update - 02

=A0

We have just submitted a new version of the Digest= =A0Update draft:

=A0

=A0

The new draft has the following changes:



1. Changed the list of algorithms, as follows: SHA2-= 256 (default), SHA3-256 (backup), and MD5 (for backward compatibility), bas= ed on the discussion on the mailing list.



2. New text in the limitation section based on the d= iscussion on the mailing list with feedback from Yaron Sheffer and Stephen = Farrell.



3. New section (section 2) around syntax convention.=





We would appreciate your feedback on the new draft.<= u>



Thanks,

=A0Rifaat


Sent from my iPhone


--047d7b2e47f45e944e04e0c45ad7-- From paul.hoffman@vpnc.org Fri Jul 5 08:13:07 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65B0B11E82C9 for ; Fri, 5 Jul 2013 08:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hkCLfWgpdvcz for ; Fri, 5 Jul 2013 08:13:07 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id E516911E82BC for ; Fri, 5 Jul 2013 08:13:06 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-228.dsl.dynamic.sonic.net [50.1.98.228]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r65FD4Ls054216 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 5 Jul 2013 08:13:05 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <1B87C63A-5E7A-4FEB-B995-B736E229CEE7@vpnc.org> Date: Fri, 5 Jul 2013 08:13:06 -0700 To: "http-auth@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [http-auth] draft-ietf-httpauth-digest-update and SHA-3 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 15:13:07 -0000 Greetings again. draft-ietf-httpauth-digest-update has a code point for = SHA-3, but there is no reference for it. There is a good reason for = that: there is none yet. NIST has said that they don't know what parameters and so on they will = want people to use for SHA-3. Having a parameter for SHA-3 in this = document is incredibly premature. When NIST figures out what they want, = the IETF can figure out whether we want it too and update the registries = of the appropriate protocols. Please remove any mention of SHA-3 from this document. --Paul Hoffman= From stpeter@stpeter.im Fri Jul 5 08:46:16 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77BF011E8303 for ; Fri, 5 Jul 2013 08:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id juenHAGKfOSV for ; Fri, 5 Jul 2013 08:46:12 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1602111E813D for ; Fri, 5 Jul 2013 08:46:12 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D785D41384; Fri, 5 Jul 2013 09:47:01 -0600 (MDT) Message-ID: <51D6EA44.60709@stpeter.im> Date: Fri, 05 Jul 2013 09:46:12 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Rifaat Shekh-Yusef References: <51D64F19.7020907@it.aoyama.ac.jp> <51D6B620.6070602@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: http-auth@ietf.org, Bjoern Hoehrmann Subject: Re: [http-auth] Digest Encoding X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 15:46:16 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/5/13 7:12 AM, Rifaat Shekh-Yusef wrote: > Thank you all for your feedback. I have just submitted a new > version of the draft that hopefully addresses all the comments I > received so far. I suggest a bit more care in defining the scope. OLD RFC2617 does not define how to treat non-ASCII characters with the "Digest" scheme. This document defines an extension to the "Digest" scheme, and a mechanism that would allow the client and server to negotiate the proper character encoding support. NEW RFC2617 does not define how to treat Unicode characters [UNICODE] outside the ASCII range [RFC20] with the "Digest" scheme. This document defines an extension to the "Digest" scheme, and a mechanism that enables the client and server to negotiate their support for the UTF-8 [RFC3629] character encoding scheme. I'd also cite RFC 6365 in the Terminology section, such as: Several terms used in this document are defined in [RFC6365] and [UNICODE]. Then you'd need to add references to RFC 20, RFC 3629, RFC 6365, and the Unicode specification. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJR1upEAAoJEOoGpJErxa2pPqsP/iX4Cw5vqoK0BHXwzPP4pyvk b9P0FAtgJbfvfmzyX095BlDy9U+oloJiBIP9pthTdbldU7FR5U23SLSZMZ1mPR0H PElMn8uB4/KUSzCXnb9o26u3IcQvbHhY4T+My0ejJmNg6oF/bQZHIYBmLfp0tnT8 G47gDasM6di1wRRb6NaS8HxjTyS1JuSB7hT26NbQmOgSfP5N7hQ2PyK0EPcjjGjp JbzMmB3WzeqoZ4esxD7RSswu0yUJ/A/H43yukxt7Ddtgrc9GtX/cv488UQD2l1Gc UOOnD4L74DIJEUtVPNvbr0Awpw8VXJpsX7w3sDOEVW/6bfJait6DLWnwpH/U4yFY WiUxz2NtwmOYmvGa4uR7iEA1+NhCS7LfPR/yoYQcdzoVVgPZ8UzvwaFOpmbnAq7D WLdmAWykm715yH6nPW0+bwQ0qBeTeaygk/AVgHzFrznw1w+fsB56wYrR2iN4Kvp2 2asKHoCcfAvfrOXqZSe1QddGKdqnajXIvdh0wAWNTKHMvTxUEjnpEr+ftFF+llj9 RdRtLC0RTYivf+gxa3tML6Loothac1Q5l1XJswMKi/uhnI3Qg3LIG4sJSdXz4veo Qyvk9SslgLgf8xGiUvUZGLjG3BB2GDnAJrCTXNAVA4fPTiDqTsKSGBZ7Yv8EMdl2 JYfQGvW0Jb7SXWIv+aEt =ODrA -----END PGP SIGNATURE----- From rifaat.ietf@gmail.com Fri Jul 5 10:11:59 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 242CC21F9DE2 for ; Fri, 5 Jul 2013 10:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZuZsOEuZ3YQ for ; Fri, 5 Jul 2013 10:11:58 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 92C1121F9CED for ; Fri, 5 Jul 2013 10:11:58 -0700 (PDT) Received: by mail-ob0-f177.google.com with SMTP id ta17so3112766obb.8 for ; Fri, 05 Jul 2013 10:11:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pz1mg2RsSFmBaLNRO/vcVoGrE4r4uCtgaAlwz0zixRc=; b=EhKV761696LJyUWkkrPpU8QaDCCfvqYBEdrDgzPgkWDHzgl3Q888N3zBpz9HcICPeT bj7k3rm8Md6XonhEET8RB6VUROg+3SG5oEj4xo+i5cRpLiO3YIo0R5NUSVanL9Kwqj6e 0/KDpNBnFDFvtT4V0WxC5jErOEDEX5+09sdvPM7L5JlTGpJynAj7WnXY+iHddcaVvjdJ 4SoewAhLp17sNFgShDZgd2aYvZN8edmowxmzubCXTC/E02K/JD/JeLDEBbi/5x5JcwnX bMj7nEuoaV0/otniDCvXqPfSmYrc0hJ+Qywv6aoxys342Dgbz/a0fIqR7/qV1DQ8tN42 VNLA== MIME-Version: 1.0 X-Received: by 10.60.161.136 with SMTP id xs8mr12029521oeb.77.1373044315502; Fri, 05 Jul 2013 10:11:55 -0700 (PDT) Received: by 10.182.22.4 with HTTP; Fri, 5 Jul 2013 10:11:55 -0700 (PDT) In-Reply-To: <1B87C63A-5E7A-4FEB-B995-B736E229CEE7@vpnc.org> References: <1B87C63A-5E7A-4FEB-B995-B736E229CEE7@vpnc.org> Date: Fri, 5 Jul 2013 13:11:55 -0400 Message-ID: From: Rifaat Shekh-Yusef To: Paul Hoffman Content-Type: multipart/alternative; boundary=089e01183a18afbc6904e0c6ca86 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] draft-ietf-httpauth-digest-update and SHA-3 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 17:11:59 -0000 --089e01183a18afbc6904e0c6ca86 Content-Type: text/plain; charset=ISO-8859-1 I thought we had that discussion already when we discussed Algorithm Agility. Take a look at the following email from Yoav around NIST's plan for SHA3: http://www.ietf.org/mail-archive/web/http-auth/current/msg01374.html Regards, Rifaat On Fri, Jul 5, 2013 at 11:13 AM, Paul Hoffman wrote: > Greetings again. draft-ietf-httpauth-digest-update has a code point for > SHA-3, but there is no reference for it. There is a good reason for that: > there is none yet. > > NIST has said that they don't know what parameters and so on they will > want people to use for SHA-3. Having a parameter for SHA-3 in this document > is incredibly premature. When NIST figures out what they want, the IETF can > figure out whether we want it too and update the registries of the > appropriate protocols. > > Please remove any mention of SHA-3 from this document. > > --Paul Hoffman > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > --089e01183a18afbc6904e0c6ca86 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I thought we had that discussion already when we discussed Algorithm Agil= ity.
Take = a look at the following email from Yoav around NIST's plan for SHA3:

Regards,
=A0Rifaat


On Fri, Jul 5, 2013 at 11:13 AM, Paul Ho= ffman <paul.hoffman@vpnc.org> wrote:
Greetings again. draft-ietf-httpauth-digest-update has a code point for SHA= -3, but there is no reference for it. There is a good reason for that: ther= e is none yet.

NIST has said that they don't know what parameters and so on they will = want people to use for SHA-3. Having a parameter for SHA-3 in this document= is incredibly premature. When NIST figures out what they want, the IETF ca= n figure out whether we want it too and update the registries of the approp= riate protocols.

Please remove any mention of SHA-3 from this document.

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

--089e01183a18afbc6904e0c6ca86-- From rifaat.ietf@gmail.com Fri Jul 5 10:14:27 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63F6421F9A49 for ; Fri, 5 Jul 2013 10:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ao9b1iGFUf2C for ; Fri, 5 Jul 2013 10:14:26 -0700 (PDT) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 122C221F9A57 for ; Fri, 5 Jul 2013 10:14:26 -0700 (PDT) Received: by mail-ob0-f181.google.com with SMTP id 16so3077565obc.26 for ; Fri, 05 Jul 2013 10:14:25 -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=gQ0woFM/InB+ssaf1TsJdHqgjKnc6yISuRt7Nk7XvOY=; b=kr9lXfKRUupXPZDnXh7voX4gty34/mednlV6Mj9GPlsRdldAfNM27x8MTzndEQV0LZ HKF2tOS+qexj0o+J8u0JZ64AhKDbSmZRj7otiIymbK7g9PktAUvNXgjsBQRWo44Mh/cw ehwGBVxQNnFsakZIxh4dKUljHstIRKJuMctHyUhqAC+ajtnDdLvyu4DshHI4diX5y/Fc f47eq+R9qAz6RsqBX3u1UcN39VzS9k/uz3U21pqMyScP1GvwNgB9V2kUHlRJJv7mxty+ kfKkFPswcb1GCkdFizvg3nb1+//+RmW68cVAzTE8WLJ4iadVMmAscNftFVUh6qXWHWpd 4a1w== MIME-Version: 1.0 X-Received: by 10.182.61.46 with SMTP id m14mr12151354obr.58.1373044465599; Fri, 05 Jul 2013 10:14:25 -0700 (PDT) Received: by 10.182.22.4 with HTTP; Fri, 5 Jul 2013 10:14:25 -0700 (PDT) In-Reply-To: <51D6EA44.60709@stpeter.im> References: <51D64F19.7020907@it.aoyama.ac.jp> <51D6B620.6070602@stpeter.im> <51D6EA44.60709@stpeter.im> Date: Fri, 5 Jul 2013 13:14:25 -0400 Message-ID: From: Rifaat Shekh-Yusef To: Peter Saint-Andre Content-Type: multipart/alternative; boundary=e89a8fb1ede2a209c604e0c6d330 Cc: "http-auth@ietf.org" , Bjoern Hoehrmann Subject: Re: [http-auth] Digest Encoding X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 17:14:27 -0000 --e89a8fb1ede2a209c604e0c6d330 Content-Type: text/plain; charset=ISO-8859-1 Thanks Peter, I like your proposed changes and will incorporate them in the next version of the draft. Regards, Rifaat On Fri, Jul 5, 2013 at 11:46 AM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 7/5/13 7:12 AM, Rifaat Shekh-Yusef wrote: > > Thank you all for your feedback. I have just submitted a new > > version of the draft that hopefully addresses all the comments I > > received so far. > > I suggest a bit more care in defining the scope. > > OLD > > RFC2617 does not define how to treat non-ASCII characters with the > "Digest" scheme. This document defines an extension to the "Digest" > scheme, and a mechanism that would allow the client and server to > negotiate the proper character encoding support. > > NEW > > RFC2617 does not define how to treat Unicode characters [UNICODE] > outside the ASCII range [RFC20] with the "Digest" scheme. This > document defines an extension to the "Digest" scheme, and a > mechanism that enables the client and server to negotiate their > support for the UTF-8 [RFC3629] character encoding scheme. > > I'd also cite RFC 6365 in the Terminology section, such as: > > Several terms used in this document are defined in [RFC6365] and > [UNICODE]. > > Then you'd need to add references to RFC 20, RFC 3629, RFC 6365, and > the Unicode specification. > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.19 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJR1upEAAoJEOoGpJErxa2pPqsP/iX4Cw5vqoK0BHXwzPP4pyvk > b9P0FAtgJbfvfmzyX095BlDy9U+oloJiBIP9pthTdbldU7FR5U23SLSZMZ1mPR0H > PElMn8uB4/KUSzCXnb9o26u3IcQvbHhY4T+My0ejJmNg6oF/bQZHIYBmLfp0tnT8 > G47gDasM6di1wRRb6NaS8HxjTyS1JuSB7hT26NbQmOgSfP5N7hQ2PyK0EPcjjGjp > JbzMmB3WzeqoZ4esxD7RSswu0yUJ/A/H43yukxt7Ddtgrc9GtX/cv488UQD2l1Gc > UOOnD4L74DIJEUtVPNvbr0Awpw8VXJpsX7w3sDOEVW/6bfJait6DLWnwpH/U4yFY > WiUxz2NtwmOYmvGa4uR7iEA1+NhCS7LfPR/yoYQcdzoVVgPZ8UzvwaFOpmbnAq7D > WLdmAWykm715yH6nPW0+bwQ0qBeTeaygk/AVgHzFrznw1w+fsB56wYrR2iN4Kvp2 > 2asKHoCcfAvfrOXqZSe1QddGKdqnajXIvdh0wAWNTKHMvTxUEjnpEr+ftFF+llj9 > RdRtLC0RTYivf+gxa3tML6Loothac1Q5l1XJswMKi/uhnI3Qg3LIG4sJSdXz4veo > Qyvk9SslgLgf8xGiUvUZGLjG3BB2GDnAJrCTXNAVA4fPTiDqTsKSGBZ7Yv8EMdl2 > JYfQGvW0Jb7SXWIv+aEt > =ODrA > -----END PGP SIGNATURE----- > --e89a8fb1ede2a209c604e0c6d330 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks Peter,

I like your propose= d changes and will incorporate them in the next version of the draft.
=

Regards,
=A0Rifaat


On Fri, Jul 5= , 2013 at 11:46 AM, Peter Saint-Andre <stpeter@stpeter.im> = wrote:
-----BEGIN PGP SIGNED MESS= AGE-----
Hash: SHA1

On 7/5/13 7:12 AM, Rifaat Shekh-Yusef wrote:
> Thank you all for your feedback. I have just submitted a new
> version of the draft that hopefully addresses all the comments I
> received so far.

I suggest a bit more care in defining the scope.

OLD

=A0 =A0RFC2617 does not define how to treat non-ASCII characters with the =A0 =A0"Digest" scheme. This document defines an extension to the= "Digest"
=A0 =A0scheme, and a mechanism that would allow the client and server to =A0 =A0negotiate the proper character encoding support.

NEW

=A0 =A0RFC2617 does not define how to treat Unicode characters [UNICODE] =A0 =A0outside the ASCII range [RFC20] with the "Digest" scheme. = =A0This
=A0 =A0document defines an extension to the "Digest" scheme, and = a
=A0 =A0mechanism that enables the client and server to negotiate their
=A0 =A0support for the UTF-8 [RFC3629] character encoding scheme.

I'd also cite RFC 6365 in the Terminology section, such as:

=A0 =A0Several terms used in this document are defined in [RFC6365] and
=A0 =A0[UNICODE].

Then you'd need to add references to RFC 20, RFC 3629, RFC 6365, and the Unicode specification.

Peter

- --
Peter Saint-Andre
https://stpeter.im/ -----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http:= //gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJR1upEAAoJEOoGpJErxa2pPqsP/iX4Cw5vqoK0BHXwzPP4pyvk
b9P0FAtgJbfvfmzyX095BlDy9U+oloJiBIP9pthTdbldU7FR5U23SLSZMZ1mPR0H
PElMn8uB4/KUSzCXnb9o26u3IcQvbHhY4T+My0ejJmNg6oF/bQZHIYBmLfp0tnT8
G47gDasM6di1wRRb6NaS8HxjTyS1JuSB7hT26NbQmOgSfP5N7hQ2PyK0EPcjjGjp
JbzMmB3WzeqoZ4esxD7RSswu0yUJ/A/H43yukxt7Ddtgrc9GtX/cv488UQD2l1Gc
UOOnD4L74DIJEUtVPNvbr0Awpw8VXJpsX7w3sDOEVW/6bfJait6DLWnwpH/U4yFY
WiUxz2NtwmOYmvGa4uR7iEA1+NhCS7LfPR/yoYQcdzoVVgPZ8UzvwaFOpmbnAq7D
WLdmAWykm715yH6nPW0+bwQ0qBeTeaygk/AVgHzFrznw1w+fsB56wYrR2iN4Kvp2
2asKHoCcfAvfrOXqZSe1QddGKdqnajXIvdh0wAWNTKHMvTxUEjnpEr+ftFF+llj9
RdRtLC0RTYivf+gxa3tML6Loothac1Q5l1XJswMKi/uhnI3Qg3LIG4sJSdXz4veo
Qyvk9SslgLgf8xGiUvUZGLjG3BB2GDnAJrCTXNAVA4fPTiDqTsKSGBZ7Yv8EMdl2
JYfQGvW0Jb7SXWIv+aEt
=3DODrA
-----END PGP SIGNATURE-----

--e89a8fb1ede2a209c604e0c6d330-- From paul.hoffman@vpnc.org Fri Jul 5 10:34:20 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0428921F9B66 for ; Fri, 5 Jul 2013 10:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lH3fNSlURYqg for ; Fri, 5 Jul 2013 10:34:19 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8CB21F9B57 for ; Fri, 5 Jul 2013 10:34:19 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-228.dsl.dynamic.sonic.net [50.1.98.228]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r65HYGb2059481 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 5 Jul 2013 10:34:16 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: Date: Fri, 5 Jul 2013 10:34:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1B87C63A-5E7A-4FEB-B995-B736E229CEE7@vpnc.org> To: Rifaat Shekh-Yusef X-Mailer: Apple Mail (2.1508) Cc: "http-auth@ietf.org" Subject: Re: [http-auth] draft-ietf-httpauth-digest-update and SHA-3 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 17:34:20 -0000 On Jul 5, 2013, at 10:11 AM, Rifaat Shekh-Yusef = wrote: > I thought we had that discussion already when we discussed Algorithm = Agility. > Take a look at the following email from Yoav around NIST's plan for = SHA3: > http://www.ietf.org/mail-archive/web/http-auth/current/msg01374.html Yoav said "may", and he meant "may". That also means "may not", or "may = take years to get this right". Yoav appears optimistic in his message; I = was at the same meeting and came away very pessimistic. There are many = ways that NIST can get this wrong by having too many options, just as = they are doing with SHA-2 ("we didn't really mean SHA-384, we meant = truncated SHA-512; err, maybe both; you figure it out"). It is inappropriate for a standards-track document to refer to a = cryptographic algorithm without a precise definition of that algorithm = as it will be used in the protocol. This draft is missing that, and thus = should remove any discussion of SHA-3 until you can have it. --Paul Hoffman= From yaronf.ietf@gmail.com Fri Jul 5 12:38:12 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E570721F9F37 for ; Fri, 5 Jul 2013 12:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SkR4azoR3LzW for ; Fri, 5 Jul 2013 12:38:12 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id BECC821F9F36 for ; Fri, 5 Jul 2013 12:38:11 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id ey16so8528446wid.3 for ; Fri, 05 Jul 2013 12:38:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=30xiGQ866tr2CxI1dDelRqH8fv8VXwelPOsennlOs0U=; b=r1R702TV2lA7vS7DzofsY36RcQe7Y0rYG7uOU6Dg5aWzKT9eSVzwoIypHHy0/OdSyA Dibr7PHEgjciO3xGGQNxzvhImO1y7AWt6cLO+oadzftx06+pkPc2LLCpieJutEL5bKGY 3pIsH0Ihr4nJ25bJ1txnp+kGtLHkRiJMUf/wPKn7IncNstxuUohbyqG5oracqRcIjfbT VfCvPxVwZp6OFplnXoRDOef4iBH/s9y7j14kZGofbpBWIaMAEITTfMhpKO1TMi1knxyB d32l62m3z9kRDNGc0dHCfHKO21pnF7+wMNi//8DwdmQP9OS3Gvq7IEcbz4GPCZidCpPn WP5A== X-Received: by 10.180.77.74 with SMTP id q10mr23936599wiw.28.1373053090885; Fri, 05 Jul 2013 12:38:10 -0700 (PDT) Received: from [10.0.0.7] (bzq-79-179-100-192.red.bezeqint.net. [79.179.100.192]) by mx.google.com with ESMTPSA id dv12sm11389333wic.3.2013.07.05.12.38.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Jul 2013 12:38:10 -0700 (PDT) Message-ID: <51D7209F.5090600@gmail.com> Date: Fri, 05 Jul 2013 22:38:07 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Paul Hoffman References: <1B87C63A-5E7A-4FEB-B995-B736E229CEE7@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "http-auth@ietf.org" Subject: Re: [http-auth] draft-ietf-httpauth-digest-update and SHA-3 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 19:38:13 -0000 I would suggest to drop all occurrences of "SHA3-256", because it is not well defined today. And to add in Sec. 3.4: "a future version of this document might add SHA3 as a backup algorithm, once its definition has been finalized and published." You can give this link as an informative reference: http://csrc.nist.gov/groups/ST/hash/index.html And by the way, there is in fact a timeline for FIPS standardization at this link: http://csrc.nist.gov/groups/ST/hash/sha-3/timeline_fips.html - which appears to be quite recent. Thanks, Yaron On 2013-07-05 20:34, Paul Hoffman wrote: > On Jul 5, 2013, at 10:11 AM, Rifaat Shekh-Yusef wrote: > >> I thought we had that discussion already when we discussed Algorithm Agility. >> Take a look at the following email from Yoav around NIST's plan for SHA3: >> http://www.ietf.org/mail-archive/web/http-auth/current/msg01374.html > > Yoav said "may", and he meant "may". That also means "may not", or "may take years to get this right". Yoav appears optimistic in his message; I was at the same meeting and came away very pessimistic. There are many ways that NIST can get this wrong by having too many options, just as they are doing with SHA-2 ("we didn't really mean SHA-384, we meant truncated SHA-512; err, maybe both; you figure it out"). > > It is inappropriate for a standards-track document to refer to a cryptographic algorithm without a precise definition of that algorithm as it will be used in the protocol. This draft is missing that, and thus should remove any discussion of SHA-3 until you can have it. > > --Paul Hoffman > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > From paul.hoffman@vpnc.org Fri Jul 5 13:14:21 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE25221F97C7 for ; Fri, 5 Jul 2013 13:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ceScfxYwSSGO for ; Fri, 5 Jul 2013 13:14:21 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 4E47D21F9655 for ; Fri, 5 Jul 2013 13:14:21 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-228.dsl.dynamic.sonic.net [50.1.98.228]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r65KEHEw064400 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 5 Jul 2013 13:14:18 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <51D7209F.5090600@gmail.com> Date: Fri, 5 Jul 2013 13:14:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1B87C63A-5E7A-4FEB-B995-B736E229CEE7@vpnc.org> <51D7209F.5090600@gmail.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.1508) Cc: "http-auth@ietf.org" Subject: Re: [http-auth] draft-ietf-httpauth-digest-update and SHA-3 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 20:14:22 -0000 On Jul 5, 2013, at 12:38 PM, Yaron Sheffer = wrote: > I would suggest to drop all occurrences of "SHA3-256", because it is = not well defined today. And to add in Sec. 3.4: "a future version of = this document might add SHA3 as a backup algorithm, once its definition = has been finalized and published." +1=20 > You can give this link as an informative reference: = http://csrc.nist.gov/groups/ST/hash/index.html -1 because NIST has a nasty habit of breaking URLs. It is sufficient to = have the above sentence without a reference. --Paul Hoffman= From ynir@checkpoint.com Fri Jul 5 13:27:04 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F31A21F9F61 for ; Fri, 5 Jul 2013 13:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.572 X-Spam-Level: X-Spam-Status: No, score=-10.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ET9us556oS7Q for ; Fri, 5 Jul 2013 13:26:59 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 5E69721F9F45 for ; Fri, 5 Jul 2013 13:26:59 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r65KQt5r008972; Fri, 5 Jul 2013 23:26:55 +0300 X-CheckPoint: {51D72C0F-11-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.48]) by IL-EX10.ad.checkpoint.com ([169.254.2.26]) with mapi id 14.02.0342.003; Fri, 5 Jul 2013 23:26:55 +0300 From: Yoav Nir To: Yaron Sheffer Thread-Topic: [http-auth] draft-ietf-httpauth-digest-update and SHA-3 Thread-Index: AQHOeZItOyP0ZMM/I0qnJaYgM96yh5lWIBCAgAAGPoCAACKbgIAADaEA Date: Fri, 5 Jul 2013 20:26:54 +0000 Message-ID: <6F2D0290-5A81-4121-A768-F81BC67DD122@checkpoint.com> References: <1B87C63A-5E7A-4FEB-B995-B736E229CEE7@vpnc.org> <51D7209F.5090600@gmail.com> In-Reply-To: <51D7209F.5090600@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.33] x-kse-antivirus-interceptor-info: protection disabled x-cpdlp: 11a5a6beb4ba9602f9080b01366105b9141624eb37 Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "http-auth@ietf.org" , Paul Hoffman Subject: Re: [http-auth] draft-ietf-httpauth-digest-update and SHA-3 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 20:27:04 -0000 By the timeline in there, we should have a document to point to some time i= n Q3. I don't see a problem with this. Or are we ready for last call alread= y? Mandating just SHA2-256 and having SHA3-256 as backup was first suggested i= n http://www.ietf.org/mail-archive/web/http-auth/current/msg01347.html and = nobody seemed to object at the time. Yoav On Jul 5, 2013, at 10:38 PM, Yaron Sheffer wrote: > I would suggest to drop all occurrences of "SHA3-256", because it is not = well defined today. And to add in Sec. 3.4: "a future version of this docum= ent might add SHA3 as a backup algorithm, once its definition has been fina= lized and published." >=20 > You can give this link as an informative reference: http://csrc.nist.gov/= groups/ST/hash/index.html >=20 > And by the way, there is in fact a timeline for FIPS standardization at t= his link: http://csrc.nist.gov/groups/ST/hash/sha-3/timeline_fips.html - wh= ich appears to be quite recent. >=20 > Thanks, > Yaron >=20 >=20 > On 2013-07-05 20:34, Paul Hoffman wrote: >> On Jul 5, 2013, at 10:11 AM, Rifaat Shekh-Yusef = wrote: >>=20 >>> I thought we had that discussion already when we discussed Algorithm Ag= ility. >>> Take a look at the following email from Yoav around NIST's plan for SHA= 3: >>> http://www.ietf.org/mail-archive/web/http-auth/current/msg01374.html >>=20 >> Yoav said "may", and he meant "may". That also means "may not", or "may = take years to get this right". Yoav appears optimistic in his message; I wa= s at the same meeting and came away very pessimistic. There are many ways t= hat NIST can get this wrong by having too many options, just as they are do= ing with SHA-2 ("we didn't really mean SHA-384, we meant truncated SHA-512;= err, maybe both; you figure it out"). >>=20 >> It is inappropriate for a standards-track document to refer to a cryptog= raphic algorithm without a precise definition of that algorithm as it will = be used in the protocol. This draft is missing that, and thus should remove= any discussion of SHA-3 until you can have it. >>=20 >> --Paul Hoffman >> _______________________________________________ >> http-auth mailing list >> http-auth@ietf.org >> https://www.ietf.org/mailman/listinfo/http-auth >>=20 > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth >=20 > Email secured by Check Point From paul.hoffman@vpnc.org Fri Jul 5 13:41:19 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C2B121F9EAF for ; Fri, 5 Jul 2013 13:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RiMHKaTF0MtG for ; Fri, 5 Jul 2013 13:41:18 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id B189221F9E05 for ; Fri, 5 Jul 2013 13:41:18 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-228.dsl.dynamic.sonic.net [50.1.98.228]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r65Kf95t064943 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 5 Jul 2013 13:41:10 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <6F2D0290-5A81-4121-A768-F81BC67DD122@checkpoint.com> Date: Fri, 5 Jul 2013 13:41:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8DAC41AB-A1F8-4F85-ACAA-C77CDEEC7596@vpnc.org> References: <1B87C63A-5E7A-4FEB-B995-B736E229CEE7@vpnc.org> <51D7209F.5090600@gmail.com> <6F2D0290-5A81-4121-A768-F81BC67DD122@checkpoint.com> To: Yoav Nir X-Mailer: Apple Mail (2.1508) Cc: http-auth@ietf.org Subject: Re: [http-auth] draft-ietf-httpauth-digest-update and SHA-3 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 20:41:19 -0000 On Jul 5, 2013, at 1:26 PM, Yoav Nir wrote: > By the timeline in there, we should have a document to point to some = time in Q3. Just because they publish some preliminary document, maybe it is not = such a good idea to encase that in HTTP servers that are rarely = upgraded. NIST's mandate of coming up with something secure for US = government use sometimes does not align all that well with the IETF's = mandate of long-term stability. > Mandating just SHA2-256 and having SHA3-256 as backup was first = suggested in = http://www.ietf.org/mail-archive/web/http-auth/current/msg01347.html and = nobody seemed to object at the time. = http://www.ietf.org/mail-archive/web/http-auth/current/threads.html#01347 I objected, and I believe Manu did as well (although Stephen disagreed = that is what Manu said). --Paul Hoffman= From yaronf.ietf@gmail.com Fri Jul 5 14:00:03 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32B3221F9DE1 for ; Fri, 5 Jul 2013 14:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EcsgHe7Kg5hD for ; Fri, 5 Jul 2013 14:00:02 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id CDA1C21F9DE9 for ; Fri, 5 Jul 2013 14:00:01 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id hq4so2477061wib.2 for ; Fri, 05 Jul 2013 14:00:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=BtQG4oGXRHjeqFMiVhs+yWlbvtwQH9QirbyJvdXqnxU=; b=kHtK3HSizrfq6vOTcWr6eWK0RLhaM7HkTgC4GTyGUmlVFlIUnInuwZZx/5gYYWlLRW M5W5t2tNiDhJ+IXzL3EZmD1F8L/kMB9GzTAfyvUfEnfYFZUt8Ix/D8RaJBnDlx7cgueW hne6ERitgCLa2t4nLD083PSUkdorS/AFKm3DyHbddGcyHae2Q5JVMwG2G9S18S9XFpJG CruwoLw/CGAqDThJVNdW3uVWLgiqZZoZ1814xbv28MpANNNLQc7totprFlDP0bHzJFw2 BoP1punhLJCBgVTkAdbqfcERPfol8tgVtng39l3KHZ7ADy3FMsJYhUrP4s76JfhF6sn/ 23Hg== X-Received: by 10.180.85.6 with SMTP id d6mr24131296wiz.47.1373058000880; Fri, 05 Jul 2013 14:00:00 -0700 (PDT) Received: from [10.0.0.7] (bzq-79-179-100-192.red.bezeqint.net. [79.179.100.192]) by mx.google.com with ESMTPSA id w4sm11640654wia.9.2013.07.05.13.59.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Jul 2013 14:00:00 -0700 (PDT) Message-ID: <51D733CE.1090009@gmail.com> Date: Fri, 05 Jul 2013 23:59:58 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Yoav Nir References: <1B87C63A-5E7A-4FEB-B995-B736E229CEE7@vpnc.org> <51D7209F.5090600@gmail.com> <6F2D0290-5A81-4121-A768-F81BC67DD122@checkpoint.com> In-Reply-To: <6F2D0290-5A81-4121-A768-F81BC67DD122@checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "http-auth@ietf.org" , Paul Hoffman Subject: Re: [http-auth] draft-ietf-httpauth-digest-update and SHA-3 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 21:00:03 -0000 The way I read the timeline, 2Q 2014 is when we will have a document "to point to". So although in principle I agree that having two different algorithms is a good thing (two, one primary and another for backup, not "a bag of algorithms"), in this case I wouldn't hold the document while waiting for SHA-3. We are gaining I18N after all, which is very important. Thanks, Yaron PS: to further support Paul's argument, let me point out that current implementations of PHP still have a "Rijndael-256" cipher, which is *not* AES-256. On 2013-07-05 23:26, Yoav Nir wrote: > By the timeline in there, we should have a document to point to some time in Q3. I don't see a problem with this. Or are we ready for last call already? > > Mandating just SHA2-256 and having SHA3-256 as backup was first suggested in http://www.ietf.org/mail-archive/web/http-auth/current/msg01347.html and nobody seemed to object at the time. > > Yoav > > On Jul 5, 2013, at 10:38 PM, Yaron Sheffer wrote: > >> I would suggest to drop all occurrences of "SHA3-256", because it is not well defined today. And to add in Sec. 3.4: "a future version of this document might add SHA3 as a backup algorithm, once its definition has been finalized and published." >> >> You can give this link as an informative reference: http://csrc.nist.gov/groups/ST/hash/index.html >> >> And by the way, there is in fact a timeline for FIPS standardization at this link: http://csrc.nist.gov/groups/ST/hash/sha-3/timeline_fips.html - which appears to be quite recent. >> >> Thanks, >> Yaron >> >> >> On 2013-07-05 20:34, Paul Hoffman wrote: >>> On Jul 5, 2013, at 10:11 AM, Rifaat Shekh-Yusef wrote: >>> >>>> I thought we had that discussion already when we discussed Algorithm Agility. >>>> Take a look at the following email from Yoav around NIST's plan for SHA3: >>>> http://www.ietf.org/mail-archive/web/http-auth/current/msg01374.html >>> >>> Yoav said "may", and he meant "may". That also means "may not", or "may take years to get this right". Yoav appears optimistic in his message; I was at the same meeting and came away very pessimistic. There are many ways that NIST can get this wrong by having too many options, just as they are doing with SHA-2 ("we didn't really mean SHA-384, we meant truncated SHA-512; err, maybe both; you figure it out"). >>> >>> It is inappropriate for a standards-track document to refer to a cryptographic algorithm without a precise definition of that algorithm as it will be used in the protocol. This draft is missing that, and thus should remove any discussion of SHA-3 until you can have it. >>> >>> --Paul Hoffman >>> _______________________________________________ >>> http-auth mailing list >>> http-auth@ietf.org >>> https://www.ietf.org/mailman/listinfo/http-auth >>> >> _______________________________________________ >> http-auth mailing list >> http-auth@ietf.org >> https://www.ietf.org/mailman/listinfo/http-auth >> >> Email secured by Check Point > From rifaat.ietf@gmail.com Fri Jul 5 16:10:00 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EB9B21F962D for ; Fri, 5 Jul 2013 16:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U1MKg8d-0l50 for ; Fri, 5 Jul 2013 16:09:59 -0700 (PDT) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 0109B21F9DE3 for ; Fri, 5 Jul 2013 16:09:51 -0700 (PDT) Received: by mail-ob0-f173.google.com with SMTP id wc20so3436293obb.18 for ; Fri, 05 Jul 2013 16: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=m+WFPrD1qfa4lc0CZ0TqnaY3whTS0YEyrW+JESyEotU=; b=tDdPg7qK/0fA3/UxLXDCLTyce9ONxZHLTdLCYer0v8Jk35VEF8ZYY9dTOqGD+16Pi9 k993y2A7EJI3fZqbM8S6oqrDcaQZX56BD5RvOpRZiI70mFuFLMHGhngbLpdK6+321+wx I5whM+s4hTm5cyGHHWYub0zQLu22cqIY9ZYvFhXepWquSemK9Tu4n+spoBKiC63oHfHr BmR3nBipPiYDopk22LgtDT6bM9daeYz44nP/AuRVILyEnyJa8RVrNjPvrh06KAXwpUWd 5d4IIqFTCDziFYPnvOkywycEo2AeGqgDaNxH1d1Gioc7/pAz2PObi64USU32fTj/ivQP HOiA== MIME-Version: 1.0 X-Received: by 10.60.103.115 with SMTP id fv19mr13125674oeb.74.1373065791346; Fri, 05 Jul 2013 16:09:51 -0700 (PDT) Received: by 10.182.22.4 with HTTP; Fri, 5 Jul 2013 16:09:51 -0700 (PDT) In-Reply-To: <51D733CE.1090009@gmail.com> References: <1B87C63A-5E7A-4FEB-B995-B736E229CEE7@vpnc.org> <51D7209F.5090600@gmail.com> <6F2D0290-5A81-4121-A768-F81BC67DD122@checkpoint.com> <51D733CE.1090009@gmail.com> Date: Fri, 5 Jul 2013 19:09:51 -0400 Message-ID: From: Rifaat Shekh-Yusef To: Yaron Sheffer Content-Type: multipart/alternative; boundary=089e0116024ebf1c4504e0cbcaf6 Cc: "http-auth@ietf.org" , Paul Hoffman Subject: Re: [http-auth] draft-ietf-httpauth-digest-update and SHA-3 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 23:10:00 -0000 --089e0116024ebf1c4504e0cbcaf6 Content-Type: text/plain; charset=UTF-8 I am fine with Yaron's proposal of mentioning SHA-3 as a possible future addition as a back up algorithm. Any objection to that idea? Regards, Rifaat On Fri, Jul 5, 2013 at 4:59 PM, Yaron Sheffer wrote: > The way I read the timeline, 2Q 2014 is when we will have a document "to > point to". > > So although in principle I agree that having two different algorithms is a > good thing (two, one primary and another for backup, not "a bag of > algorithms"), in this case I wouldn't hold the document while waiting for > SHA-3. We are gaining I18N after all, which is very important. > > Thanks, > Yaron > > PS: to further support Paul's argument, let me point out that current > implementations of PHP still have a "Rijndael-256" cipher, which is *not* > AES-256. > > > On 2013-07-05 23:26, Yoav Nir wrote: > >> By the timeline in there, we should have a document to point to some time >> in Q3. I don't see a problem with this. Or are we ready for last call >> already? >> >> Mandating just SHA2-256 and having SHA3-256 as backup was first suggested >> in http://www.ietf.org/mail-**archive/web/http-auth/current/** >> msg01347.htmland nobody seemed to object at the time. >> >> Yoav >> >> On Jul 5, 2013, at 10:38 PM, Yaron Sheffer wrote: >> >> I would suggest to drop all occurrences of "SHA3-256", because it is not >>> well defined today. And to add in Sec. 3.4: "a future version of this >>> document might add SHA3 as a backup algorithm, once its definition has been >>> finalized and published." >>> >>> You can give this link as an informative reference: >>> http://csrc.nist.gov/groups/**ST/hash/index.html >>> >>> And by the way, there is in fact a timeline for FIPS standardization at >>> this link: http://csrc.nist.gov/groups/**ST/hash/sha-3/timeline_fips.** >>> html - >>> which appears to be quite recent. >>> >>> Thanks, >>> Yaron >>> >>> >>> On 2013-07-05 20:34, Paul Hoffman wrote: >>> >>>> On Jul 5, 2013, at 10:11 AM, Rifaat Shekh-Yusef >>>> wrote: >>>> >>>> I thought we had that discussion already when we discussed Algorithm >>>>> Agility. >>>>> Take a look at the following email from Yoav around NIST's plan for >>>>> SHA3: >>>>> http://www.ietf.org/mail-**archive/web/http-auth/current/** >>>>> msg01374.html >>>>> >>>> >>>> Yoav said "may", and he meant "may". That also means "may not", or "may >>>> take years to get this right". Yoav appears optimistic in his message; I >>>> was at the same meeting and came away very pessimistic. There are many ways >>>> that NIST can get this wrong by having too many options, just as they are >>>> doing with SHA-2 ("we didn't really mean SHA-384, we meant truncated >>>> SHA-512; err, maybe both; you figure it out"). >>>> >>>> It is inappropriate for a standards-track document to refer to a >>>> cryptographic algorithm without a precise definition of that algorithm as >>>> it will be used in the protocol. This draft is missing that, and thus >>>> should remove any discussion of SHA-3 until you can have it. >>>> >>>> --Paul Hoffman >>>> ______________________________**_________________ >>>> http-auth mailing list >>>> http-auth@ietf.org >>>> https://www.ietf.org/mailman/**listinfo/http-auth >>>> >>>> ______________________________**_________________ >>> http-auth mailing list >>> http-auth@ietf.org >>> https://www.ietf.org/mailman/**listinfo/http-auth >>> >>> Email secured by Check Point >>> >> >> ______________________________**_________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/**listinfo/http-auth > --089e0116024ebf1c4504e0cbcaf6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am fine with Yaron's proposal of mentioni= ng SHA-3 as a possible future addition as a back up algorithm. Any objectio= n to that idea?

Regards,
=C2=A0Rifaat



<= div class=3D"gmail_quote">On Fri, Jul 5, 2013 at 4:59 PM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
The way I read the timeline, 2Q 2014 is when= we will have a document "to point to".

So although in principle I agree that having two different algorithms is a = good thing (two, one primary and another for backup, not "a bag of alg= orithms"), in this case I wouldn't hold the document while waiting= for SHA-3. We are gaining I18N after all, which is very important.

Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yaron

PS: to further support Paul's argument, let me point out that current i= mplementations of PHP still have a "Rijndael-256" cipher, which i= s *not* AES-256.


On 2013-07-05 23:26, Yoav Nir wrote:
By the timeline in there, we should have a document to point to some time i= n Q3. I don't see a problem with this. Or are we ready for last call al= ready?

Mandating just SHA2-256 and having SHA3-256 as backup was first suggested i= n http://www.ietf.org/mail-archive/web/http-= auth/current/msg01347.html and nobody seemed to object at the ti= me.

Yoav

On Jul 5, 2013, at 10:38 PM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

I would suggest to drop all occurrences of "SHA3-256", because it= is not well defined today. And to add in Sec. 3.4: "a future version = of this document might add SHA3 as a backup algorithm, once its definition = has been finalized and published."

You can give this link as an informative reference: http://csrc.nist.gov/= groups/ST/hash/index.html

And by the way, there is in fact a timeline for FIPS standardization at thi= s link: http://csrc.nist.gov/groups/ST/hash/sha-3/ti= meline_fips.html - which appears to be quite recent.

Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yaron


On 2013-07-05 20:34, Paul Hoffman wrote:
On Jul 5, 2013, at 10:11 AM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
I thought we had that discussion already when we discussed Algorithm Agilit= y.
Take a look at the following email from Yoav around NIST's plan for SHA= 3:
http://www.ietf.org/mail-archive/web/http-au= th/current/msg01374.html

Yoav said "may", and he meant "may". That also means &q= uot;may not", or "may take years to get this right". Yoav ap= pears optimistic in his message; I was at the same meeting and came away ve= ry pessimistic. There are many ways that NIST can get this wrong by having = too many options, just as they are doing with SHA-2 ("we didn't re= ally mean SHA-384, we meant truncated SHA-512; err, maybe both; you figure = it out").

It is inappropriate for a standards-track document to refer to a cryptograp= hic algorithm without a precise definition of that algorithm as it will be = used in the protocol. This draft is missing that, and thus should remove an= y discussion of SHA-3 until you can have it.

--Paul Hoffman
_______________________________________________
http-auth mailing list
http-auth@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/http-auth

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

Email secured by Check Point

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

--089e0116024ebf1c4504e0cbcaf6-- From ynir@checkpoint.com Fri Jul 5 20:53:36 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50B6A11E8152 for ; Fri, 5 Jul 2013 20:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.74 X-Spam-Level: X-Spam-Status: No, score=-9.74 tagged_above=-999 required=5 tests=[AWL=-0.808, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZSLza7tUSVo for ; Fri, 5 Jul 2013 20:53:31 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 12F0B11E814D for ; Fri, 5 Jul 2013 20:53:30 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r663r78M032563; Sat, 6 Jul 2013 06:53:07 +0300 X-CheckPoint: {51D794A3-0-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.48]) by IL-EX10.ad.checkpoint.com ([169.254.2.26]) with mapi id 14.02.0342.003; Sat, 6 Jul 2013 06:53:06 +0300 From: Yoav Nir To: Rifaat Shekh-Yusef Thread-Topic: [http-auth] draft-ietf-httpauth-digest-update and SHA-3 Thread-Index: AQHOeZItOyP0ZMM/I0qnJaYgM96yh5lWIBCAgAAGPoCAACKbgIAADaEAgAAJPgCAACRKgIAATyMA Date: Sat, 6 Jul 2013 03:53:06 +0000 Message-ID: References: <1B87C63A-5E7A-4FEB-B995-B736E229CEE7@vpnc.org> <51D7209F.5090600@gmail.com> <6F2D0290-5A81-4121-A768-F81BC67DD122@checkpoint.com> <51D733CE.1090009@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.24.153] x-kse-antivirus-interceptor-info: protection disabled x-cpdlp: 11cc9d23b4e33a14d339fb0d355ad5be6279f9b206 Content-Type: multipart/alternative; boundary="_000_F01978FEE181490588D88DC800BC280Echeckpointcom_" MIME-Version: 1.0 Cc: "http-auth@ietf.org" , Paul Hoffman Subject: Re: [http-auth] draft-ietf-httpauth-digest-update and SHA-3 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 03:53:36 -0000 --_000_F01978FEE181490588D88DC800BC280Echeckpointcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Only that then we're left with no backup algorithm. (hopefully by now MD5 d= oesn't count) On Jul 6, 2013, at 2:09 AM, Rifaat Shekh-Yusef > wrote: I am fine with Yaron's proposal of mentioning SHA-3 as a possible future ad= dition as a back up algorithm. Any objection to that idea? Regards, Rifaat On Fri, Jul 5, 2013 at 4:59 PM, Yaron Sheffer > wrote: The way I read the timeline, 2Q 2014 is when we will have a document "to po= int to". So although in principle I agree that having two different algorithms is a = good thing (two, one primary and another for backup, not "a bag of algorith= ms"), in this case I wouldn't hold the document while waiting for SHA-3. We= are gaining I18N after all, which is very important. Thanks, Yaron PS: to further support Paul's argument, let me point out that current imple= mentations of PHP still have a "Rijndael-256" cipher, which is *not* AES-25= 6. On 2013-07-05 23:26, Yoav Nir wrote: By the timeline in there, we should have a document to point to some time i= n Q3. I don't see a problem with this. Or are we ready for last call alread= y? Mandating just SHA2-256 and having SHA3-256 as backup was first suggested i= n http://www.ietf.org/mail-archive/web/http-auth/current/msg01347.html and = nobody seemed to object at the time. Yoav On Jul 5, 2013, at 10:38 PM, Yaron Sheffer > wrote: I would suggest to drop all occurrences of "SHA3-256", because it is not we= ll defined today. And to add in Sec. 3.4: "a future version of this documen= t might add SHA3 as a backup algorithm, once its definition has been finali= zed and published." You can give this link as an informative reference: http://csrc.nist.gov/gr= oups/ST/hash/index.html And by the way, there is in fact a timeline for FIPS standardization at thi= s link: http://csrc.nist.gov/groups/ST/hash/sha-3/timeline_fips.html - whic= h appears to be quite recent. Thanks, Yaron On 2013-07-05 20:34, Paul Hoffman wrote: On Jul 5, 2013, at 10:11 AM, Rifaat Shekh-Yusef > wrote: I thought we had that discussion already when we discussed Algorithm Agilit= y. Take a look at the following email from Yoav around NIST's plan for SHA3: http://www.ietf.org/mail-archive/web/http-auth/current/msg01374.html Yoav said "may", and he meant "may". That also means "may not", or "may tak= e years to get this right". Yoav appears optimistic in his message; I was a= t the same meeting and came away very pessimistic. There are many ways that= NIST can get this wrong by having too many options, just as they are doing= with SHA-2 ("we didn't really mean SHA-384, we meant truncated SHA-512; er= r, maybe both; you figure it out"). It is inappropriate for a standards-track document to refer to a cryptograp= hic algorithm without a precise definition of that algorithm as it will be = used in the protocol. This draft is missing that, and thus should remove an= y discussion of SHA-3 until you can have it. --Paul Hoffman _______________________________________________ http-auth mailing list http-auth@ietf.org https://www.ietf.org/mailman/listinfo/http-auth _______________________________________________ http-auth mailing list http-auth@ietf.org https://www.ietf.org/mailman/listinfo/http-auth Email secured by Check Point _______________________________________________ http-auth mailing list http-auth@ietf.org https://www.ietf.org/mailman/listinfo/http-auth Email secured by Check Point --_000_F01978FEE181490588D88DC800BC280Echeckpointcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Only that then we're left with no backup algorithm. (hopefully by now MD5 d= oesn't count)

On Jul 6, 2013, at 2:09 AM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
 wrote:

I am fine with Yaron's proposal of mentioning SHA-3 as a po= ssible future addition as a back up algorithm. Any objection to that idea?<= br>

Regards,
 Rifaat



On Fri, Jul 5, 2013 at 4:59 PM, Yaron Sheffer <yaronf.ietf@= gmail.com> wrote:
The way I read the timeline, 2Q 2014 is when we will have a document "= to point to".

So although in principle I agree that having two different algorithms is a = good thing (two, one primary and another for backup, not "a bag of alg= orithms"), in this case I wouldn't hold the document while waiting for= SHA-3. We are gaining I18N after all, which is very important.

Thanks,
        Yaron

PS: to further support Paul's argument, let me point out that current imple= mentations of PHP still have a "Rijndael-256" cipher, which is *n= ot* AES-256.


On 2013-07-05 23:26, Yoav Nir wrote:
By the timeline in there, we should have a document to point to some time i= n Q3. I don't see a problem with this. Or are we ready for last call alread= y?

Mandating just SHA2-256 and having SHA3-256 as backup was first suggested i= n http://www.ietf.org/mail-archive/web/http-auth/current/msg013= 47.html and nobody seemed to object at the time.

Yoav

On Jul 5, 2013, at 10:38 PM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

I would suggest to drop all occurrences of "SHA3-256", because it= is not well defined today. And to add in Sec. 3.4: "a future version = of this document might add SHA3 as a backup algorithm, once its definition = has been finalized and published."

You can give this link as an informative reference: http://csrc.nist.gov/groups/ST/hash/index.html

And by the way, there is in fact a timeline for FIPS standardization at thi= s link: http://csrc.nist.gov/groups/ST/hash/sha-3/timeline_fips.html<= /a> - which appears to be quite recent.

Thanks,
        Yaron


On 2013-07-05 20:34, Paul Hoffman wrote:
On Jul 5, 2013, at 10:11 AM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
I thought we had that discussion already when we discussed Algorithm Agilit= y.
Take a look at the following email from Yoav around NIST's plan for SHA3: http://www.ietf.org/mail-archive/web/http-au= th/current/msg01374.html

Yoav said "may", and he meant "may". That also means &q= uot;may not", or "may take years to get this right". Yoav ap= pears optimistic in his message; I was at the same meeting and came away ve= ry pessimistic. There are many ways that NIST can get this wrong by having too many options, just as they are doing with SHA-2 ("we didn't reall= y mean SHA-384, we meant truncated SHA-512; err, maybe both; you figure it = out").

It is inappropriate for a standards-track document to refer to a cryptograp= hic algorithm without a precise definition of that algorithm as it will be = used in the protocol. This draft is missing that, and thus should remove an= y discussion of SHA-3 until you can have it.

--Paul Hoffman
_______________________________________________
http-auth mailing list
http-auth@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/http-auth

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

Email secured by Check Point

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



Email secured by Check Point


--_000_F01978FEE181490588D88DC800BC280Echeckpointcom_-- From duerst@it.aoyama.ac.jp Fri Jul 5 21:29:06 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58C8311E815E for ; Fri, 5 Jul 2013 21:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.623 X-Spam-Level: X-Spam-Status: No, score=-103.623 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p3zQlZsI0e75 for ; Fri, 5 Jul 2013 21:28:56 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 16D1511E80F0 for ; Fri, 5 Jul 2013 21:28:55 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r664SX8C004914; Sat, 6 Jul 2013 13:28:33 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 048f_0d9f_847ab582_e5f4_11e2_8d14_001e6722eec2; Sat, 06 Jul 2013 13:28:33 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id AEF83BF510; Sat, 6 Jul 2013 13:26:54 +0900 (JST) Message-ID: <51D79CDD.7020201@it.aoyama.ac.jp> Date: Sat, 06 Jul 2013 13:28:13 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Yoav Nir References: <1B87C63A-5E7A-4FEB-B995-B736E229CEE7@vpnc.org> <51D7209F.5090600@gmail.com> <6F2D0290-5A81-4121-A768-F81BC67DD122@checkpoint.com> <51D733CE.1090009@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "http-auth@ietf.org" , Paul Hoffman Subject: Re: [http-auth] draft-ietf-httpauth-digest-update and SHA-3 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 04:29:06 -0000 On 2013/07/06 12:53, Yoav Nir wrote: > Only that then we're left with no backup algorithm. (hopefully by now MD5 doesn't count) Just saying that SHA-3 is a backup algorithm without knowing the necessary details means that this is essentially the same as no backup algorithm. Regards, Martin. > On Jul 6, 2013, at 2:09 AM, Rifaat Shekh-Yusef> > wrote: > > I am fine with Yaron's proposal of mentioning SHA-3 as a possible future addition as a back up algorithm. Any objection to that idea? > > Regards, > Rifaat > > > > On Fri, Jul 5, 2013 at 4:59 PM, Yaron Sheffer> wrote: > The way I read the timeline, 2Q 2014 is when we will have a document "to point to". > > So although in principle I agree that having two different algorithms is a good thing (two, one primary and another for backup, not "a bag of algorithms"), in this case I wouldn't hold the document while waiting for SHA-3. We are gaining I18N after all, which is very important. > > Thanks, > Yaron > > PS: to further support Paul's argument, let me point out that current implementations of PHP still have a "Rijndael-256" cipher, which is *not* AES-256. From rifaat.ietf@gmail.com Sat Jul 6 03:12:47 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56B2721F9C28 for ; Sat, 6 Jul 2013 03:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[AWL=-0.101, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Go708aaosgSg for ; Sat, 6 Jul 2013 03:12:46 -0700 (PDT) Received: from mail-oa0-x22d.google.com (mail-oa0-x22d.google.com [IPv6:2607:f8b0:4003:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 58D8821F9C29 for ; Sat, 6 Jul 2013 03:12:44 -0700 (PDT) Received: by mail-oa0-f45.google.com with SMTP id j1so4371634oag.4 for ; Sat, 06 Jul 2013 03:12:43 -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=6DM0HG5lm8bDZAJkpUXpJiNqaF6OpLtTwSdZ3DhuqiY=; b=ybxS3f9MdvOnlFzXu90jbj6F1VAd42bFbG0BYL9Uw64rLocU/pSsD56Ofw8XwSe6Sb 7KyJfe6EMo8trCgf0jYreGbf1RhPyPh27mKVAS9Wr5AmIHVOIMULyNkDZDKltvNVDAvZ u+7HaM8Kg7v+6UR9xxaI5pzSNHNkr3ozi0BbeShRlC1OCWcfhG8GaMwqA2mgomuyp6Kd x1LWLkp+d396zCVxFoyPjjT4amMv1fmHPt2sF1YdVqlAxTL3zapauE4QT8PEX9kGnPkA 5LGtSd+HrGQnaoaPv4aeVEgHXRwcbCtmUv8j1/1TJaPYsK9LojzwLCUDCwoEinsop2IW Hj9Q== MIME-Version: 1.0 X-Received: by 10.182.213.10 with SMTP id no10mr14492597obc.76.1373105563849; Sat, 06 Jul 2013 03:12:43 -0700 (PDT) Received: by 10.182.22.4 with HTTP; Sat, 6 Jul 2013 03:12:43 -0700 (PDT) In-Reply-To: <51D79CDD.7020201@it.aoyama.ac.jp> References: <1B87C63A-5E7A-4FEB-B995-B736E229CEE7@vpnc.org> <51D7209F.5090600@gmail.com> <6F2D0290-5A81-4121-A768-F81BC67DD122@checkpoint.com> <51D733CE.1090009@gmail.com> <51D79CDD.7020201@it.aoyama.ac.jp> Date: Sat, 6 Jul 2013 06:12:43 -0400 Message-ID: From: Rifaat Shekh-Yusef To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= Content-Type: multipart/alternative; boundary=001a11c2deaa5f5a8b04e0d50d7e Cc: "http-auth@ietf.org" , Paul Hoffman Subject: Re: [http-auth] draft-ietf-httpauth-digest-update and SHA-3 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 10:12:47 -0000 --001a11c2deaa5f5a8b04e0d50d7e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable How about choosing a variant of SHA2 as a backup with some text around the intention to replace it with SHA3 when that is ready? Regards, Rifaat On Sat, Jul 6, 2013 at 12:28 AM, "Martin J. D=C3=BCrst" wrote: > On 2013/07/06 12:53, Yoav Nir wrote: > >> Only that then we're left with no backup algorithm. (hopefully by now MD= 5 >> doesn't count) >> > > Just saying that SHA-3 is a backup algorithm without knowing the necessar= y > details means that this is essentially the same as no backup algorithm. > > Regards, Martin. > > On Jul 6, 2013, at 2:09 AM, Rifaat Shekh-Yusef >> >> >> >> wrote: >> >> I am fine with Yaron's proposal of mentioning SHA-3 as a possible future >> addition as a back up algorithm. Any objection to that idea? >> >> Regards, >> Rifaat >> >> >> >> On Fri, Jul 5, 2013 at 4:59 PM, Yaron Sheffer> mailto:yaronf.ietf@gmail.com>> wrote: >> >> The way I read the timeline, 2Q 2014 is when we will have a document "to >> point to". >> >> So although in principle I agree that having two different algorithms is >> a good thing (two, one primary and another for backup, not "a bag of >> algorithms"), in this case I wouldn't hold the document while waiting fo= r >> SHA-3. We are gaining I18N after all, which is very important. >> >> Thanks, >> Yaron >> >> PS: to further support Paul's argument, let me point out that current >> implementations of PHP still have a "Rijndael-256" cipher, which is *not= * >> AES-256. >> > --001a11c2deaa5f5a8b04e0d50d7e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
How about choosing a variant of SHA2 as a backup with some= text around the intention to replace it with SHA3 when that is ready?
<= div style>
Regards,
=C2=A0Rifaat
<= div style>


On Sat, Jul 6, 2013 at 12:28 AM, "Martin J. D=C3=BCrst" <duerst@it.aoyama.ac.jp> wrote:
On 2013/07/06 12:53, Yoav = Nir wrote:
Only that then we're left with no backup algorithm. (hopefully by now M= D5 doesn't count)

Just saying that SHA-3 is a backup algorithm without knowing the necessary = details means that this is essentially the same as no backup algorithm.

Regards, =C2=A0 =C2=A0Martin.

On Jul 6, 2013, at 2:09 AM, Rifaat Shekh-Yusef<rifaat.ietf@gmail.com<mailt= o:rifaat.ietf@gm= ail.com>>

=C2=A0 wrote:

I am fine with Yaron's proposal of mentioning SHA-3 as a possible futur= e addition as a back up algorithm. Any objection to that idea?

Regards,
=C2=A0 Rifaat



On Fri, Jul 5, 2013 at 4:59 PM, Yaron Sheffer<yaronf.ietf@gmail.com<mailto= :yaronf.ietf@gma= il.com>> =C2=A0wrote:

The way I read the timeline, 2Q 2014 is when we will have a document "= to point to".

So although in principle I agree that having two different algorithms is a = good thing (two, one primary and another for backup, not "a bag of alg= orithms"), in this case I wouldn't hold the document while waiting= for SHA-3. We are gaining I18N after all, which is very important.

Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Yaron

PS: to further support Paul's argument, let me point out that current i= mplementations of PHP still have a "Rijndael-256" cipher, which i= s *not* AES-256.

--001a11c2deaa5f5a8b04e0d50d7e-- From yaronf.ietf@gmail.com Sat Jul 6 04:23:12 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD7A21F9AED for ; Sat, 6 Jul 2013 04:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wuqpKhBWJty8 for ; Sat, 6 Jul 2013 04:23:11 -0700 (PDT) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 8BCFD21F9ADD for ; Sat, 6 Jul 2013 04:23:11 -0700 (PDT) Received: by mail-wg0-f53.google.com with SMTP id y10so2568958wgg.8 for ; Sat, 06 Jul 2013 04:23:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=kYYNjgFqeUAdnlIo4hd6OEgzhiPSyFgaoSpFnRjyVRY=; b=t9J97iteoySBmT5gyp9DM5vg1SsRubjRmy7auIzg0Wl8XoCpPs3ropK9QEkQgWjKki WR6tf+llKhw3VDjO8abdD0sjZqHqNrM1bTkY/Ae7eCdgpzPsqLayZ42Q0U/yOYmMOTVz LVL9bN3F5VmEc5uj95crTGIgCoFgK49EKjx21YpjAbnzoSAB49A37yobMoMsTjo6DSOr eV+4AgUnw1kbj/eX94Vff1r1riO9mfYR65Ba+VRT9tILQ9a3VKEtbxt2PqTux01julQc 3OEBAATz4++YIcqcPoB06V6PRzhK/a8MU+/Qf7mxoq/SU6XX0N8IdVPysfJJTL9T1lN0 pX0A== X-Received: by 10.180.73.68 with SMTP id j4mr9246538wiv.10.1373109790726; Sat, 06 Jul 2013 04:23:10 -0700 (PDT) Received: from [10.0.0.7] (bzq-79-179-100-192.red.bezeqint.net. [79.179.100.192]) by mx.google.com with ESMTPSA id z6sm13788892wiv.11.2013.07.06.04.23.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 06 Jul 2013 04:23:10 -0700 (PDT) Message-ID: <51D7FE1C.90100@gmail.com> Date: Sat, 06 Jul 2013 14:23:08 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Rifaat Shekh-Yusef References: <1B87C63A-5E7A-4FEB-B995-B736E229CEE7@vpnc.org> <51D7209F.5090600@gmail.com> <6F2D0290-5A81-4121-A768-F81BC67DD122@checkpoint.com> <51D733CE.1090009@gmail.com> <51D79CDD.7020201@it.aoyama.ac.jp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "http-auth@ietf.org" , Paul Hoffman Subject: Re: [http-auth] draft-ietf-httpauth-digest-update and SHA-3 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 11:23:12 -0000 Hi Rifaat, I don't think this is a good idea. The point of a backup algorithm is to have something that's dissimilar enough so that if algorithm A is broken, algorithm B is unlikely to be weakened as well. So let's do only SHA2-256 for the time being, plus the infrastructure for future agility, and add SHA-3 when it is in a usable shape. Thanks, Yaron On 2013-07-06 13:12, Rifaat Shekh-Yusef wrote: > How about choosing a variant of SHA2 as a backup with some text around > the intention to replace it with SHA3 when that is ready? > > Regards, > Rifaat > > > > On Sat, Jul 6, 2013 at 12:28 AM, "Martin J. Dürst" > > wrote: > > On 2013/07/06 12:53, Yoav Nir wrote: > > Only that then we're left with no backup algorithm. (hopefully > by now MD5 doesn't count) > > > Just saying that SHA-3 is a backup algorithm without knowing the > necessary details means that this is essentially the same as no > backup algorithm. > > Regards, Martin. > > On Jul 6, 2013, at 2:09 AM, Rifaat > Shekh-Yusef >> > > wrote: > > I am fine with Yaron's proposal of mentioning SHA-3 as a > possible future addition as a back up algorithm. Any objection > to that idea? > > Regards, > Rifaat > > > > On Fri, Jul 5, 2013 at 4:59 PM, Yaron > Sheffer <__mailto:yaronf.ietf@gmail.com > >> wrote: > > The way I read the timeline, 2Q 2014 is when we will have a > document "to point to". > > So although in principle I agree that having two different > algorithms is a good thing (two, one primary and another for > backup, not "a bag of algorithms"), in this case I wouldn't hold > the document while waiting for SHA-3. We are gaining I18N after > all, which is very important. > > Thanks, > Yaron > > PS: to further support Paul's argument, let me point out that > current implementations of PHP still have a "Rijndael-256" > cipher, which is *not* AES-256. > > > > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > From paul.hoffman@vpnc.org Sat Jul 6 08:03:46 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7813C21F9C13 for ; Sat, 6 Jul 2013 08:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMVZeK5y1ofJ for ; Sat, 6 Jul 2013 08:03:46 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5456321F9C00 for ; Sat, 6 Jul 2013 08:03:45 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-228.dsl.dynamic.sonic.net [50.1.98.228]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r66F3a1T096840 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 6 Jul 2013 08:03:37 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <51D79CDD.7020201@it.aoyama.ac.jp> Date: Sat, 6 Jul 2013 08:03:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <73CDEB14-35F4-412F-A110-042626473BF6@vpnc.org> References: <1B87C63A-5E7A-4FEB-B995-B736E229CEE7@vpnc.org> <51D7209F.5090600@gmail.com> <6F2D0290-5A81-4121-A768-F81BC67DD122@checkpoint.com> <51D733CE.1090009@gmail.com> <51D79CDD.7020201@it.aoyama.ac.jp> To: "http-auth@ietf.org" X-Mailer: Apple Mail (2.1508) Subject: Re: [http-auth] draft-ietf-httpauth-digest-update and SHA-3 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 15:03:46 -0000 On Jul 5, 2013, at 9:28 PM, Martin J. D=FCrst = wrote: > On 2013/07/06 12:53, Yoav Nir wrote: >> Only that then we're left with no backup algorithm. (hopefully by now = MD5 doesn't count) >=20 > Just saying that SHA-3 is a backup algorithm without knowing the = necessary details means that this is essentially the same as no backup = algorithm. It's actually worse because some implementer will guess what is = "obviously" meant by the unreferenced string in the RFC, but will be = wrong. At that point, the string "SHA3" becomes useless for = interoperability, and the update RFC will have to use a string like = "SHA3-2014" or something horrid like that. A reasonable backup hash algorithm is SHA2-512. If the WG likes this, = the string names for the mandatory algorithms should be "SHA2-256" and = "SHA2-256-sess", and the backups "SHA2-512" and "SHA2-512-sess". --Paul Hoffman= From paul.hoffman@vpnc.org Sat Jul 6 08:06:05 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B47E21F9BD8 for ; Sat, 6 Jul 2013 08:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3EUWd+dwJ2Pd for ; Sat, 6 Jul 2013 08:06:04 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 282F921F9703 for ; Sat, 6 Jul 2013 08:05:46 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-228.dsl.dynamic.sonic.net [50.1.98.228]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r66F5h1w096918 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 6 Jul 2013 08:05:44 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <51D7FE1C.90100@gmail.com> Date: Sat, 6 Jul 2013 08:05:44 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <48F6B5C6-F228-44BB-904D-7D81524B7534@vpnc.org> References: <1B87C63A-5E7A-4FEB-B995-B736E229CEE7@vpnc.org> <51D7209F.5090600@gmail.com> <6F2D0290-5A81-4121-A768-F81BC67DD122@checkpoint.com> <51D733CE.1090009@gmail.com> <51D79CDD.7020201@it.aoyama.ac.jp> <51D7FE1C.90100@gmail.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.1508) Cc: http-auth@ietf.org Subject: Re: [http-auth] draft-ietf-httpauth-digest-update and SHA-3 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 15:06:05 -0000 On Jul 6, 2013, at 4:23 AM, Yaron Sheffer wrote: > I don't think this is a good idea. The point of a backup algorithm is = to have something that's dissimilar enough so that if algorithm A is = broken, algorithm B is unlikely to be weakened as well. >=20 > So let's do only SHA2-256 for the time being, plus the infrastructure = for future agility, and add SHA-3 when it is in a usable shape. If both SHA2-256 and SHA2-512 have significant problems, the world will = be happy to update to SHA3-whatever in all protocols. --Paul Hoffman= From ynir@checkpoint.com Sat Jul 6 08:19:23 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7C2C21F89D8 for ; Sat, 6 Jul 2013 08:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.523 X-Spam-Level: X-Spam-Status: No, score=-10.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zDZ6RXffg9vZ for ; Sat, 6 Jul 2013 08:19:18 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 9921021F862B for ; Sat, 6 Jul 2013 08:19:17 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r66FIijT028766; Sat, 6 Jul 2013 18:18:50 +0300 X-CheckPoint: {51D83554-7-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.48]) by IL-EX10.ad.checkpoint.com ([169.254.2.26]) with mapi id 14.02.0342.003; Sat, 6 Jul 2013 18:18:43 +0300 From: Yoav Nir To: Paul Hoffman Thread-Topic: [http-auth] draft-ietf-httpauth-digest-update and SHA-3 Thread-Index: AQHOeZItOyP0ZMM/I0qnJaYgM96yh5lWIBCAgAAGPoCAACKbgIAADaEAgAAJPgCAACRKgIAATyMAgAAJ0ICAALGHgIAABDcA Date: Sat, 6 Jul 2013 15:18:43 +0000 Message-ID: <2622773E-5D8C-40A9-8EB2-AA769EF5BEF1@checkpoint.com> References: <1B87C63A-5E7A-4FEB-B995-B736E229CEE7@vpnc.org> <51D7209F.5090600@gmail.com> <6F2D0290-5A81-4121-A768-F81BC67DD122@checkpoint.com> <51D733CE.1090009@gmail.com> <51D79CDD.7020201@it.aoyama.ac.jp> <73CDEB14-35F4-412F-A110-042626473BF6@vpnc.org> In-Reply-To: <73CDEB14-35F4-412F-A110-042626473BF6@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.24.21] x-kse-antivirus-interceptor-info: protection disabled x-cpdlp: 1159223fc16040668fa2adbd2d7ecbf4a2050aa690 Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] draft-ietf-httpauth-digest-update and SHA-3 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 15:19:24 -0000 On Jul 6, 2013, at 6:03 PM, Paul Hoffman wrote: > On Jul 5, 2013, at 9:28 PM, Martin J. D=FCrst wr= ote: >=20 >> On 2013/07/06 12:53, Yoav Nir wrote: >>> Only that then we're left with no backup algorithm. (hopefully by now M= D5 doesn't count) >>=20 >> Just saying that SHA-3 is a backup algorithm without knowing the necessa= ry details means that this is essentially the same as no backup algorithm. >=20 > It's actually worse because some implementer will guess what is "obviousl= y" meant by the unreferenced string in the RFC, but will be wrong. At that = point, the string "SHA3" becomes useless for interoperability, and the upda= te RFC will have to use a string like "SHA3-2014" or something horrid like = that. >=20 > A reasonable backup hash algorithm is SHA2-512. If the WG likes this, the= string names for the mandatory algorithms should be "SHA2-256" and "SHA2-2= 56-sess", and the backups "SHA2-512" and "SHA2-512-sess". OK, but if we're going down this path, I'd suggest we use SHA2-512/256 inst= ead of straight SHA2-512. Both are well defined, and SHA2-512/256 has short= er output. We might want a shorter string as well, though, or we'll lose al= l that we gain in a shorter hash to a longer name. Also, what's "-sess"? Yoav From paul.hoffman@vpnc.org Sat Jul 6 08:35:09 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C141621F9B7F for ; Sat, 6 Jul 2013 08:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXciolSnAWP5 for ; Sat, 6 Jul 2013 08:35:09 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5E93B21F9B5F for ; Sat, 6 Jul 2013 08:35:09 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-228.dsl.dynamic.sonic.net [50.1.98.228]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r66FYxSV098145 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 6 Jul 2013 08:35:00 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <2622773E-5D8C-40A9-8EB2-AA769EF5BEF1@checkpoint.com> Date: Sat, 6 Jul 2013 08:34:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <17ED77E7-FBC7-4980-B79B-B2A61D0AD85B@vpnc.org> References: <1B87C63A-5E7A-4FEB-B995-B736E229CEE7@vpnc.org> <51D7209F.5090600@gmail.com> <6F2D0290-5A81-4121-A768-F81BC67DD122@checkpoint.com> <51D733CE.1090009@gmail.com> <51D79CDD.7020201@it.aoyama.ac.jp> <73CDEB14-35F4-412F-A110-042626473BF6@vpnc.org> <2622773E-5D8C-40A9-8EB2-AA769EF5BEF1@checkpoint.com> To: Yoav Nir X-Mailer: Apple Mail (2.1508) Cc: "http-auth@ietf.org" Subject: Re: [http-auth] draft-ietf-httpauth-digest-update and SHA-3 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 15:35:10 -0000 On Jul 6, 2013, at 8:18 AM, Yoav Nir wrote: > OK, but if we're going down this path, I'd suggest we use SHA2-512/256 = instead of straight SHA2-512. Both are well defined, and SHA2-512/256 = has shorter output. That sounds fine as well. > We might want a shorter string as well, though, or we'll lose all that = we gain in a shorter hash to a longer name. We could shorten the names to "A", "B", "C" and so on if length is a = concern. > Also, what's "-sess"? See Section 3.2.1 of the current draft. --Paul Hoffman= From ilari.liusvaara@elisanet.fi Sat Jul 6 09:06:02 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8082F21F9B53 for ; Sat, 6 Jul 2013 09:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-4.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-i3KO9BIACG for ; Sat, 6 Jul 2013 09:05:56 -0700 (PDT) Received: from emh01.mail.saunalahti.fi (emh01.mail.saunalahti.fi [62.142.5.107]) by ietfa.amsl.com (Postfix) with ESMTP id A93A521F9B30 for ; Sat, 6 Jul 2013 09:05:55 -0700 (PDT) Received: from saunalahti-vams (vs3-11.mail.saunalahti.fi [62.142.5.95]) by emh01.mail.saunalahti.fi (Postfix) with SMTP id 6427A90002 for ; Sat, 6 Jul 2013 19:05:53 +0300 (EEST) Received: from emh02.mail.saunalahti.fi ([62.142.5.108]) by vs3-11.mail.saunalahti.fi ([62.142.5.95]) with SMTP (gateway) id A02C9461DC3; Sat, 06 Jul 2013 19:05:53 +0300 Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh02.mail.saunalahti.fi (Postfix) with ESMTP id 509398181F for ; Sat, 6 Jul 2013 19:05:53 +0300 (EEST) Date: Sat, 6 Jul 2013 19:05:53 +0300 From: Ilari Liusvaara To: http-auth@ietf.org Message-ID: <20130706160552.GA1875@LK-Perkele-VII> References: <20130701140319.24231.24693.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20130701140319.24231.24693.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Ilari Liusvaara X-Antivirus: VAMS Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-mutual-00.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 16:06:02 -0000 On Mon, Jul 01, 2013 at 07:03:19AM -0700, internet-drafts@ietf.org wrote: > > Title : Mutual Authentication Protocol for HTTP > Filename : draft-ietf-httpauth-mutual-00.txt 1) "All character strings outside ASCII character sets MUST be encoded using the UTF-8 encoding [RFC3629] for the ISO 10646-1 character set [ISO.10646-1.1993], without any leading BOM characters." The reference to ASCII seems unnecressary, since UTF-8 is true super- set of ASCII. 2) "Both peers are RECOMMENDED to reject any invalid UTF-8 sequences that might cause decoding ambiguities (e.g., containing <"> in the second or later byte of the UTF-8 encoded characters)." Why not reject all invalid UTF-8 sequences, at least: - Leading/Continuation not matching what is expected. - Overlong encodings. - Surrogates. 3) "For requests, the parameters "kc*" (where * stands for any decimal integers), and "vks" are mutually exclusive and any challenge MUST NOT contain two or more parameters among them. They MUST NOT contain any "ks*" and "vks" parameters." The first "vks" should be "vkc"? 4) " Every 401-INIT or 401-STALE message SHALL be a valid HTTP 401-status (Authentication Required) message containing one (and only one: hereafter not explicitly noticed) "WWW-Authenticate" header containing a "reason" parameter in the challenge." Only one? Makes sense in 401-STALE, but not necressarily in first 401 response (server may support number of schemes). Or is this something unrelated? 5) " version: (mandatory extensive-token) should be the token "-wg-draft00" in this specification." Put RFC editor note after this? Note that this also appears in some other places. 6) "pwd-hash: (non-mandatory extensive-token) specifies the hash algorithm (hereafter referred to by ph) used for additionally hashing the password. The valid tokens are * none: ph(p) = p" This seems somewhat dangerous, since hash functions return numbers, but this one doesn't, defintion problems can arise. 7) "path: (non-mandatory, string) specifies which path in the "URI space the same authentication is expected to be applied." How is matching supposed to be done? Component-by-component prefix match? 8) "auth-domain: [...] If the value is omitted, it is assumed to be the "single-port" type domain in Section 5." There is no "single-port" in section 5. "Single-Server"? 9) "Single-host type: The "host" part of the requested URI. This is the default value." Eh, isn't the default "single-port", which definitely doesn't sound like "single-host"? 10) "tls-key: TLS shared-key validation: The value v will be the octet string of the shared master secret negotiated in the underlying TLS (or SSL) connection." Master secret? Does some TLS binding specification specify binding to be done like that? I found some RFC regarding TLS channel bindings, the per-connection binding is to finished message, not to master secret. 11) "The function octet(c) generates a single octet string whose code value is equal to c." Took me few readings to correctly parse that. 12) "pi = H(VS(algorithm) | VS(auth-domain) | VS(realm) | VS(username) | VS(ph(password)))." VS() takes an octet string. What does it mean to apply it to an integer (since apparently ph() can be integer-valued)? 13) "One way to mitigate such attacks are that servers MAY have a number and a time limits for unverified pending key exchange requests (in the "wa received" status)." wa received? Should this be Key Exchanging? 14) Authors list That might draw some discussion (6 authors)... -Ilari From rifaat.ietf@gmail.com Sat Jul 6 09:39:36 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1789021F997E for ; Sat, 6 Jul 2013 09:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7H7DpZF5SkjG for ; Sat, 6 Jul 2013 09:39:35 -0700 (PDT) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id B1F5C21F9968 for ; Sat, 6 Jul 2013 09:39:34 -0700 (PDT) Received: by mail-ob0-f170.google.com with SMTP id ef5so4067557obb.29 for ; Sat, 06 Jul 2013 09:39:34 -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=3RAsTtx5yfm9iPFd9clEI/oIqmi6hV1SG4fLwYklt28=; b=FTCd2VfEOfrEG+3QpPV/tfzpJorozmsOPlO92EFaQw0jIjZ1U7jVtgnxllXO+piNLl 79EvLqAiAkMd2rrmzdz4k+1EM1FzgDOw5XlnqB4qV6wmDRD95a7L4OboNTprCbNcp9Is RSYPg5XFnaaLrUzPXuDceSn4UclE5pN2OXVyZOc7ebEP0GSjsG2HRcG6MX0c/0f5IqwO 23rwy3l+1fQfB8+hy5z5ySLtv5fzmM5Fm3i6jnTb4UT+Dl6mwEE1j6ullnZlzggR5JFb rBKytVvQSoQ9HsfU1Ml2o1Om88jVQHFRpfKGNiH1vuGOzCE4xk8vfS3PV0rE+lPSpFxp ctOg== MIME-Version: 1.0 X-Received: by 10.182.213.10 with SMTP id no10mr15228937obc.76.1373128773242; Sat, 06 Jul 2013 09:39:33 -0700 (PDT) Received: by 10.182.22.4 with HTTP; Sat, 6 Jul 2013 09:39:33 -0700 (PDT) In-Reply-To: <17ED77E7-FBC7-4980-B79B-B2A61D0AD85B@vpnc.org> References: <1B87C63A-5E7A-4FEB-B995-B736E229CEE7@vpnc.org> <51D7209F.5090600@gmail.com> <6F2D0290-5A81-4121-A768-F81BC67DD122@checkpoint.com> <51D733CE.1090009@gmail.com> <51D79CDD.7020201@it.aoyama.ac.jp> <73CDEB14-35F4-412F-A110-042626473BF6@vpnc.org> <2622773E-5D8C-40A9-8EB2-AA769EF5BEF1@checkpoint.com> <17ED77E7-FBC7-4980-B79B-B2A61D0AD85B@vpnc.org> Date: Sat, 6 Jul 2013 12:39:33 -0400 Message-ID: From: Rifaat Shekh-Yusef To: Paul Hoffman Content-Type: multipart/alternative; boundary=001a11c2deaac297b804e0da7452 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] draft-ietf-httpauth-digest-update and SHA-3 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 16:39:36 -0000 --001a11c2deaac297b804e0da7452 Content-Type: text/plain; charset=ISO-8859-1 Ok, so SHA2-512/256 as a backup algorithm with some text around that possibly being replaced by SHA3 in the future. Any objection to this? Regards, Rifaat On Sat, Jul 6, 2013 at 11:34 AM, Paul Hoffman wrote: > On Jul 6, 2013, at 8:18 AM, Yoav Nir wrote: > > > OK, but if we're going down this path, I'd suggest we use SHA2-512/256 > instead of straight SHA2-512. Both are well defined, and SHA2-512/256 has > shorter output. > > That sounds fine as well. > > > We might want a shorter string as well, though, or we'll lose all that > we gain in a shorter hash to a longer name. > > We could shorten the names to "A", "B", "C" and so on if length is a > concern. > > > Also, what's "-sess"? > > See Section 3.2.1 of the current draft. > > --Paul Hoffman > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > --001a11c2deaac297b804e0da7452 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Ok, so SHA2-512/256 as a backup algorithm with some text a= round that possibly being replaced by SHA3 in the future. Any objection to = this?

Regards,
=A0Rifaat



On Sat, Jul 6, 2013 at 11:34 AM, Paul Hoffman <paul.hoffman@vpnc.or= g> wrote:
On Jul 6, 2013, at 8:18 AM= , Yoav Nir <ynir@checkpoint.com> wrote:

> OK, but if we're going down this path, I'd suggest we use SHA2= -512/256 instead of straight SHA2-512. Both are well defined, and SHA2-512/= 256 has shorter output.

That sounds fine as well.

> We might want a shorter string as well, though, or we'll lose all = that we gain in a shorter hash to a longer name.

We could shorten the names to "A", "B", "C&q= uot; and so on if length is a concern.

> Also, what's "-sess"?

See Section 3.2.1 of the current draft.

--Paul Hoffman
_____________________= __________________________
http-auth mailing list
http-auth@ietf.org
https://www.ietf.org/mailman/listinfo/http-auth

--001a11c2deaac297b804e0da7452-- From yaronf.ietf@gmail.com Sat Jul 6 09:52:54 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA8921F9C4E for ; Sat, 6 Jul 2013 09:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.478 X-Spam-Level: X-Spam-Status: No, score=-102.478 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0en+aTnuQD1w for ; Sat, 6 Jul 2013 09:52:53 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 9ACC721F9BF0 for ; Sat, 6 Jul 2013 09:52:53 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id m6so7961733wiv.14 for ; Sat, 06 Jul 2013 09:52:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=vQW3WTke5iCDbN91cnctl7lQgHi4knywG7Ap3h/35S0=; b=X6xpJgfG33dTHtHPNjwQ/rxrLJQ2UgHYS23pPl5npvMQ9tONLsvBB2yJPaemMMe+ec CuZf4z5meAiVhQ1aiSvBKPz/wD+3ZY9UjMhKjFkOQWHMbj8SBab1h5QH6UPGiRuCvNFW WKxxRxU+55tiybWz2voODSTv9X+u3xBTy7NCscJduLgELQirgHaub/bNbyb3JCwoUC/z K58rUNr7vQU9JsbZquK3M5Gw5c79uMn6akl0HgwB7aj0npI+dVs4QI4yW7O00TjGQact Klx1G6/Ip+8q9GnTPRHsueu4nwtTV0zJEtoiC7qP0cOJexlHjTBm7BswgTZ9OABJURGp WvGg== X-Received: by 10.194.9.101 with SMTP id y5mr8517691wja.86.1373129571620; Sat, 06 Jul 2013 09:52:51 -0700 (PDT) Received: from [10.0.0.7] (bzq-79-179-100-192.red.bezeqint.net. [79.179.100.192]) by mx.google.com with ESMTPSA id r8sm33278869wiz.5.2013.07.06.09.52.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 06 Jul 2013 09:52:51 -0700 (PDT) Message-ID: <51D84B5F.2070802@gmail.com> Date: Sat, 06 Jul 2013 19:52:47 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Rifaat Shekh-Yusef References: <1B87C63A-5E7A-4FEB-B995-B736E229CEE7@vpnc.org> <51D7209F.5090600@gmail.com> <6F2D0290-5A81-4121-A768-F81BC67DD122@checkpoint.com> <51D733CE.1090009@gmail.com> <51D79CDD.7020201@it.aoyama.ac.jp> <73CDEB14-35F4-412F-A110-042626473BF6@vpnc.org> <2622773E-5D8C-40A9-8EB2-AA769EF5BEF1@checkpoint.com> <17ED77E7-FBC7-4980-B79B-B2A61D0AD85B@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "http-auth@ietf.org" , Paul Hoffman Subject: Re: [http-auth] draft-ietf-httpauth-digest-update and SHA-3 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 16:52:55 -0000 I think we're spending too much time on this one, but since you're asking... As far as I know (and if there's any cryptographer in the house, please correct me), SHA2-512 and SHA2-256 are based on the same building blocks. So if something bad happens to SHA2-256, we'd better migrate away to another primitive. In other words, I think adding SHA2-512 (truncated or not) would be a waste of time. We'd better just hold our horses and add SHA3 as a backup algorithm in the future. Thanks, Yaron On 2013-07-06 19:39, Rifaat Shekh-Yusef wrote: > Ok, so SHA2-512/256 as a backup algorithm with some text around that > possibly being replaced by SHA3 in the future. Any objection to this? > > Regards, > Rifaat > > > > On Sat, Jul 6, 2013 at 11:34 AM, Paul Hoffman > wrote: > > On Jul 6, 2013, at 8:18 AM, Yoav Nir > wrote: > > > OK, but if we're going down this path, I'd suggest we use > SHA2-512/256 instead of straight SHA2-512. Both are well defined, > and SHA2-512/256 has shorter output. > > That sounds fine as well. > > > We might want a shorter string as well, though, or we'll lose all > that we gain in a shorter hash to a longer name. > > We could shorten the names to "A", "B", "C" and so on if length is a > concern. > > > Also, what's "-sess"? > > See Section 3.2.1 of the current draft. > > --Paul Hoffman > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > > > > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > From paul.hoffman@vpnc.org Sat Jul 6 10:09:24 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99C4A21F8793 for ; Sat, 6 Jul 2013 10:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zk2m0cLPIJlC for ; Sat, 6 Jul 2013 10:09:24 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD1421F8201 for ; Sat, 6 Jul 2013 10:09:23 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-228.dsl.dynamic.sonic.net [50.1.98.228]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r66H9IDI000600 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 6 Jul 2013 10:09:18 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <51D84B5F.2070802@gmail.com> Date: Sat, 6 Jul 2013 10:09:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1B87C63A-5E7A-4FEB-B995-B736E229CEE7@vpnc.org> <51D7209F.5090600@gmail.com> <6F2D0290-5A81-4121-A768-F81BC67DD122@checkpoint.com> <51D733CE.1090009@gmail.com> <51D79CDD.7020201@it.aoyama.ac.jp> <73CDEB14-35F4-412F-A110-042626473BF6@vpnc.org> <2622773E-5D8C-40A9-8EB2-AA769EF5BEF1@checkpoint.com> <17ED77E7-FBC7-4980-B79B-B2A61D0AD85B@vpnc.org> <51D84B5F.2070802@gmail.com> To: "http-auth@ietf.org" X-Mailer: Apple Mail (2.1508) Subject: Re: [http-auth] draft-ietf-httpauth-digest-update and SHA-3 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 17:09:24 -0000 On Jul 6, 2013, at 9:52 AM, Yaron Sheffer wrote: > I think we're spending too much time on this one, but since you're = asking... >=20 > As far as I know (and if there's any cryptographer in the house, = please correct me), SHA2-512 and SHA2-256 are based on the same building = blocks. So if something bad happens to SHA2-256, we'd better migrate = away to another primitive. In other words, I think adding SHA2-512 = (truncated or not) would be a waste of time. This is uncreative thinking. The "something bad" could be related to the = key table for SHA-256, at which point the backup would be fully useful. = The "something bad" could also be more severe, but completely = ameliorated by the extra bits in the mix-and-mash. > We'd better just hold our horses and add SHA3 as a backup algorithm in = the future. I'm fine with either approach (backup is SHA-512-truncated, or no = backup) IN the latter case, the initial RFC needs to signal that there = is an expectation that there will be additional algorithms specified in = the future so that an implementer knows that they should handle = unexpected strings for the hash function, and hopefully make their = hash-handling code flexible. --Paul Hoffman= From rifaat.ietf@gmail.com Sat Jul 6 10:20:00 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C284321F9CA2 for ; Sat, 6 Jul 2013 10:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mb2ya+irIL7b for ; Sat, 6 Jul 2013 10:20:00 -0700 (PDT) Received: from mail-oa0-x235.google.com (mail-oa0-x235.google.com [IPv6:2607:f8b0:4003:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 739D721F9C99 for ; Sat, 6 Jul 2013 10:19:59 -0700 (PDT) Received: by mail-oa0-f53.google.com with SMTP id k14so4743582oag.12 for ; Sat, 06 Jul 2013 10:19:59 -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=lRPdnaH+lpupSWsmS7+YRUGTucEfWCM/x1iLz6Dsg1U=; b=MwF5Z/Q4bhuOwYM8Kd+UaGZE9Fyb4aAtJZXDec0g214Gn1LuTzZLHGlKvQnVFBi+1W FLCDjAR80qLpmn6Ouh3hlxygx43WKFYcKOCcB83SK3FBw/MzyCJd3aE2I7Ly63aOHauG jrwP1UuZPs3cGxtMRs/vP3Frigh9Oji2fgfmsaWYdgPakW5fPSIh0AJ3osIuX0yfIcBK 8uoTUCwYEgB2nJmwe/vycqJrxT+dBQHyTyPOB65UNqarqJSR7xoRo3gtuJU1ccwCHq50 xTN5BZBVRcZEA0mq+vISFn1ZV7IbkVYGCgIbUPd2O2GHyzpL2B0rCSUXVcVoLZmcnVDC 3ukg== MIME-Version: 1.0 X-Received: by 10.182.81.202 with SMTP id c10mr15722297oby.27.1373131198968; Sat, 06 Jul 2013 10:19:58 -0700 (PDT) Received: by 10.182.22.4 with HTTP; Sat, 6 Jul 2013 10:19:58 -0700 (PDT) In-Reply-To: References: <1B87C63A-5E7A-4FEB-B995-B736E229CEE7@vpnc.org> <51D7209F.5090600@gmail.com> <6F2D0290-5A81-4121-A768-F81BC67DD122@checkpoint.com> <51D733CE.1090009@gmail.com> <51D79CDD.7020201@it.aoyama.ac.jp> <73CDEB14-35F4-412F-A110-042626473BF6@vpnc.org> <2622773E-5D8C-40A9-8EB2-AA769EF5BEF1@checkpoint.com> <17ED77E7-FBC7-4980-B79B-B2A61D0AD85B@vpnc.org> <51D84B5F.2070802@gmail.com> Date: Sat, 6 Jul 2013 13:19:58 -0400 Message-ID: From: Rifaat Shekh-Yusef To: Paul Hoffman Content-Type: multipart/alternative; boundary=047d7b2e47f4583c1504e0db05c7 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] draft-ietf-httpauth-digest-update and SHA-3 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 17:20:00 -0000 --047d7b2e47f4583c1504e0db05c7 Content-Type: text/plain; charset=ISO-8859-1 Yeah, I agree with Paul, and I am leaning towards adding SHA2-512/256 as a backup algorithm and mentioning SHA3 as possible future replacement. Regards, Rifaat On Sat, Jul 6, 2013 at 1:09 PM, Paul Hoffman wrote: > On Jul 6, 2013, at 9:52 AM, Yaron Sheffer wrote: > > > I think we're spending too much time on this one, but since you're > asking... > > > > As far as I know (and if there's any cryptographer in the house, please > correct me), SHA2-512 and SHA2-256 are based on the same building blocks. > So if something bad happens to SHA2-256, we'd better migrate away to > another primitive. In other words, I think adding SHA2-512 (truncated or > not) would be a waste of time. > > This is uncreative thinking. The "something bad" could be related to the > key table for SHA-256, at which point the backup would be fully useful. The > "something bad" could also be more severe, but completely ameliorated by > the extra bits in the mix-and-mash. > > > We'd better just hold our horses and add SHA3 as a backup algorithm in > the future. > > I'm fine with either approach (backup is SHA-512-truncated, or no backup) > IN the latter case, the initial RFC needs to signal that there is an > expectation that there will be additional algorithms specified in the > future so that an implementer knows that they should handle unexpected > strings for the hash function, and hopefully make their hash-handling code > flexible. > > --Paul Hoffman > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > --047d7b2e47f4583c1504e0db05c7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Yeah, I agree with Paul, and I am leaning towards adding S= HA2-512/256 as a backup algorithm and mentioning SHA3 as possible future re= placement.

Regards,
=A0Rifaat



On Sat, Jul 6, 2013 at 1:09 PM, Paul Hoffman <paul.hoffm= an@vpnc.org> wrote:
On Jul 6, 2013, at 9:52 AM= , Yaron Sheffer <yaronf.ietf@gm= ail.com> wrote:

> I think we're spending too much time on this one, but since you= 9;re asking...
>
> As far as I know (and if there's any cryptographer in the house, p= lease correct me), SHA2-512 and SHA2-256 are based on the same building blo= cks. So if something bad happens to SHA2-256, we'd better migrate away = to another primitive. In other words, I think adding SHA2-512 (truncated or= not) would be a waste of time.

This is uncreative thinking. The "something bad" could be r= elated to the key table for SHA-256, at which point the backup would be ful= ly useful. The "something bad" could also be more severe, but com= pletely ameliorated by the extra bits in the mix-and-mash.

> We'd better just hold our horses and add SHA3 as a backup algorith= m in the future.

I'm fine with either approach (backup is SHA-512-truncated, or no= backup) IN the latter case, the initial RFC needs to signal that there is = an expectation that there will be additional algorithms specified in the fu= ture so that an implementer knows that they should handle unexpected string= s for the hash function, and hopefully make their hash-handling code flexib= le.

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

--047d7b2e47f4583c1504e0db05c7-- From internet-drafts@ietf.org Sun Jul 7 06:12:42 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEC0C21F9EF8; Sun, 7 Jul 2013 06:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.51 X-Spam-Level: X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5+bBsiRQtis; Sun, 7 Jul 2013 06:12:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7179D21F9EC9; Sun, 7 Jul 2013 06:12:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130707131242.3676.40484.idtracker@ietfa.amsl.com> Date: Sun, 07 Jul 2013 06:12:42 -0700 Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-digest-update-03.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 13:12:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Hypertext Transfer Protocol Authenticatio= n Working Group of the IETF. Title : HTTP Digest Update Author(s) : Rifaat Shekh-Yusef David Ahrens Filename : draft-ietf-httpauth-digest-update-03.txt Pages : 10 Date : 2013-07-07 Abstract: This documents specifies extensions to the HTTP Digest Authentication mechanism to add support for new digest algorithms to the HTTP Digest Access Authentication scheme. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest-update There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-httpauth-digest-update-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-httpauth-digest-update-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Sun Jul 7 06:14:37 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4493021F8F4F; Sun, 7 Jul 2013 06:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.511 X-Spam-Level: X-Spam-Status: No, score=-102.511 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xiwATu22Q5-3; Sun, 7 Jul 2013 06:14:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DE00521F8EC2; Sun, 7 Jul 2013 06:14:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130707131436.31874.47327.idtracker@ietfa.amsl.com> Date: Sun, 07 Jul 2013 06:14:36 -0700 Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-digest-encoding-02.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 13:14:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Hypertext Transfer Protocol Authenticatio= n Working Group of the IETF. Title : An Encoding Mechanism for HTTP Digest Authentication Author(s) : Rifaat Shekh-Yusef Filename : draft-ietf-httpauth-digest-encoding-02.txt Pages : 6 Date : 2013-07-07 Abstract: RFC2617 does not define how to treat Unicode characters [UNICODE] outside the ASCII range [RFC20] with the "Digest" scheme. This document defines an extension to the "Digest" scheme, and a mechanism that enables the client and server to negotiate their support for the UTF-8 [RFC3629] character encoding scheme. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest-encoding There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-httpauth-digest-encoding-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-httpauth-digest-encoding-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rifaat.ietf@gmail.com Sun Jul 7 06:16:54 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13C6D21F9EFD for ; Sun, 7 Jul 2013 06:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2VLkdNkIGy7 for ; Sun, 7 Jul 2013 06:16:53 -0700 (PDT) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id D6ECB21F8FAF for ; Sun, 7 Jul 2013 06:16:52 -0700 (PDT) Received: by mail-ob0-f179.google.com with SMTP id xk17so4538646obc.10 for ; Sun, 07 Jul 2013 06:16: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=Zxr7Lk+GECEYV1Gi1OiBPyVMBS9yswB3019P00Uiej8=; b=aigKFLI1dNdU4Kerxelsc8Uuak3G/O7nxfKXefMs5g8/iXQlBslxUs8ShukfotK37i fqeo33wvZKaas2lupOk9YeBJHv4Sa4ljvpXwCRG5hAGZbVeXR0roGLgyKw1ZdasJ2zxU +LIP3VOQtVCtDL7On7Q7puCc1/jDm/d5suTusK6DKvMAZE2qazvOTlX7mMe01LBhWjsK VqeeWeXoHXzMZGmUyf1Vgopk2zxVGC/0JEJXW7fXLWoQZgMjtN07+E7UGsWZwEIAfbyO f/bL1EhZgUZmGeD4w14o4JzTDeuDgk7YoUxFphArkNsHxkl+5cURGP2ydLGLXe0aGlAN a+ZA== MIME-Version: 1.0 X-Received: by 10.60.123.10 with SMTP id lw10mr17433730oeb.102.1373203010988; Sun, 07 Jul 2013 06:16:50 -0700 (PDT) Received: by 10.182.22.4 with HTTP; Sun, 7 Jul 2013 06:16:50 -0700 (PDT) In-Reply-To: References: <51D64F19.7020907@it.aoyama.ac.jp> <51D6B620.6070602@stpeter.im> <51D6EA44.60709@stpeter.im> Date: Sun, 7 Jul 2013 09:16:50 -0400 Message-ID: From: Rifaat Shekh-Yusef To: Peter Saint-Andre Content-Type: multipart/alternative; boundary=047d7b5d49ceacafc504e0ebbd93 Cc: "http-auth@ietf.org" , Bjoern Hoehrmann Subject: Re: [http-auth] Digest Encoding X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 13:16:54 -0000 --047d7b5d49ceacafc504e0ebbd93 Content-Type: text/plain; charset=ISO-8859-1 I have just submitted a new version that incorporates the feedback I got so far, and added an acknowledgments section. https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest-encoding/ Please, let me know if you have any further comments. Regards, Rifaat On Fri, Jul 5, 2013 at 1:14 PM, Rifaat Shekh-Yusef wrote: > Thanks Peter, > > I like your proposed changes and will incorporate them in the next version > of the draft. > > Regards, > Rifaat > > > On Fri, Jul 5, 2013 at 11:46 AM, Peter Saint-Andre wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 7/5/13 7:12 AM, Rifaat Shekh-Yusef wrote: >> > Thank you all for your feedback. I have just submitted a new >> > version of the draft that hopefully addresses all the comments I >> > received so far. >> >> I suggest a bit more care in defining the scope. >> >> OLD >> >> RFC2617 does not define how to treat non-ASCII characters with the >> "Digest" scheme. This document defines an extension to the "Digest" >> scheme, and a mechanism that would allow the client and server to >> negotiate the proper character encoding support. >> >> NEW >> >> RFC2617 does not define how to treat Unicode characters [UNICODE] >> outside the ASCII range [RFC20] with the "Digest" scheme. This >> document defines an extension to the "Digest" scheme, and a >> mechanism that enables the client and server to negotiate their >> support for the UTF-8 [RFC3629] character encoding scheme. >> >> I'd also cite RFC 6365 in the Terminology section, such as: >> >> Several terms used in this document are defined in [RFC6365] and >> [UNICODE]. >> >> Then you'd need to add references to RFC 20, RFC 3629, RFC 6365, and >> the Unicode specification. >> >> Peter >> >> - -- >> Peter Saint-Andre >> https://stpeter.im/ >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG/MacGPG2 v2.0.19 (Darwin) >> Comment: GPGTools - http://gpgtools.org >> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >> >> iQIcBAEBAgAGBQJR1upEAAoJEOoGpJErxa2pPqsP/iX4Cw5vqoK0BHXwzPP4pyvk >> b9P0FAtgJbfvfmzyX095BlDy9U+oloJiBIP9pthTdbldU7FR5U23SLSZMZ1mPR0H >> PElMn8uB4/KUSzCXnb9o26u3IcQvbHhY4T+My0ejJmNg6oF/bQZHIYBmLfp0tnT8 >> G47gDasM6di1wRRb6NaS8HxjTyS1JuSB7hT26NbQmOgSfP5N7hQ2PyK0EPcjjGjp >> JbzMmB3WzeqoZ4esxD7RSswu0yUJ/A/H43yukxt7Ddtgrc9GtX/cv488UQD2l1Gc >> UOOnD4L74DIJEUtVPNvbr0Awpw8VXJpsX7w3sDOEVW/6bfJait6DLWnwpH/U4yFY >> WiUxz2NtwmOYmvGa4uR7iEA1+NhCS7LfPR/yoYQcdzoVVgPZ8UzvwaFOpmbnAq7D >> WLdmAWykm715yH6nPW0+bwQ0qBeTeaygk/AVgHzFrznw1w+fsB56wYrR2iN4Kvp2 >> 2asKHoCcfAvfrOXqZSe1QddGKdqnajXIvdh0wAWNTKHMvTxUEjnpEr+ftFF+llj9 >> RdRtLC0RTYivf+gxa3tML6Loothac1Q5l1XJswMKi/uhnI3Qg3LIG4sJSdXz4veo >> Qyvk9SslgLgf8xGiUvUZGLjG3BB2GDnAJrCTXNAVA4fPTiDqTsKSGBZ7Yv8EMdl2 >> JYfQGvW0Jb7SXWIv+aEt >> =ODrA >> -----END PGP SIGNATURE----- >> > > --047d7b5d49ceacafc504e0ebbd93 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have just submitted a new version that incorporates the = feedback I got so far, and added an acknowledgments section.

Please, let me know if you have any further= comments.

Regards,
= =A0Rifaat


On Fri, Jul 5, 2013 at 1:14 PM, Rifaat Shekh-Yus= ef <rifaat.ietf@gmail.com> wrote:
Thanks Peter,

I like your proposed chan= ges and will incorporate them in the next version of the draft.
<= br>
Regards,
=A0Rifaat


On Fri, Jul 5= , 2013 at 11:46 AM, Peter Saint-Andre <stpeter@stpeter.im> = wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 7/5/13 7:12 AM, Rifaat Shekh-Yusef wrote:
> Thank you all for your feedback. I have just submitted a new
> version of the draft that hopefully addresses all the comments I
> received so far.

I suggest a bit more care in defining the scope.

OLD

=A0 =A0RFC2617 does not define how to treat non-ASCII characters with the =A0 =A0"Digest" scheme. This document defines an extension to the= "Digest"
=A0 =A0scheme, and a mechanism that would allow the client and server to =A0 =A0negotiate the proper character encoding support.

NEW

=A0 =A0RFC2617 does not define how to treat Unicode characters [UNICODE] =A0 =A0outside the ASCII range [RFC20] with the "Digest" scheme. = =A0This
=A0 =A0document defines an extension to the "Digest" scheme, and = a
=A0 =A0mechanism that enables the client and server to negotiate their
=A0 =A0support for the UTF-8 [RFC3629] character encoding scheme.

I'd also cite RFC 6365 in the Terminology section, such as:

=A0 =A0Several terms used in this document are defined in [RFC6365] and
=A0 =A0[UNICODE].

Then you'd need to add references to RFC 20, RFC 3629, RFC 6365, and the Unicode specification.

Peter

- --
Peter Saint-Andre
https://stpeter.im/ -----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http:= //gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJR1upEAAoJEOoGpJErxa2pPqsP/iX4Cw5vqoK0BHXwzPP4pyvk
b9P0FAtgJbfvfmzyX095BlDy9U+oloJiBIP9pthTdbldU7FR5U23SLSZMZ1mPR0H
PElMn8uB4/KUSzCXnb9o26u3IcQvbHhY4T+My0ejJmNg6oF/bQZHIYBmLfp0tnT8
G47gDasM6di1wRRb6NaS8HxjTyS1JuSB7hT26NbQmOgSfP5N7hQ2PyK0EPcjjGjp
JbzMmB3WzeqoZ4esxD7RSswu0yUJ/A/H43yukxt7Ddtgrc9GtX/cv488UQD2l1Gc
UOOnD4L74DIJEUtVPNvbr0Awpw8VXJpsX7w3sDOEVW/6bfJait6DLWnwpH/U4yFY
WiUxz2NtwmOYmvGa4uR7iEA1+NhCS7LfPR/yoYQcdzoVVgPZ8UzvwaFOpmbnAq7D
WLdmAWykm715yH6nPW0+bwQ0qBeTeaygk/AVgHzFrznw1w+fsB56wYrR2iN4Kvp2
2asKHoCcfAvfrOXqZSe1QddGKdqnajXIvdh0wAWNTKHMvTxUEjnpEr+ftFF+llj9
RdRtLC0RTYivf+gxa3tML6Loothac1Q5l1XJswMKi/uhnI3Qg3LIG4sJSdXz4veo
Qyvk9SslgLgf8xGiUvUZGLjG3BB2GDnAJrCTXNAVA4fPTiDqTsKSGBZ7Yv8EMdl2
JYfQGvW0Jb7SXWIv+aEt
=3DODrA
-----END PGP SIGNATURE-----


--047d7b5d49ceacafc504e0ebbd93-- From rifaat.ietf@gmail.com Sun Jul 7 06:24:14 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 648B721F9F0A for ; Sun, 7 Jul 2013 06:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7HqWhUUjrMk for ; Sun, 7 Jul 2013 06:24:13 -0700 (PDT) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id A13F721F9F06 for ; Sun, 7 Jul 2013 06:24:13 -0700 (PDT) Received: by mail-ob0-f170.google.com with SMTP id ef5so4598717obb.29 for ; Sun, 07 Jul 2013 06:24:13 -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=HZLaZIrGKVUq3AdXf9rfzVNHHfeWr9OgRSYVdOGDieg=; b=GcPpGwLNAxhl3s6zu4ZL5D5lvdx4z0q3RwErAN+RaWy/u0QmvWYiYR97isbsnMxFEZ 9Nb4VUatUFDeVtrd2epPkAwauh5Rm/p4zKo+tzS0QxOZTMpAr3k70tpHGucICq3ar/gA awpkVce1aStLRn2K1+FW7BxoeCtNYDnBkBBDlJxW4QiAnior6sBh18cgNcPTV8Yqq7LW p6Jl8+k42FgbhubdHwNu4YwGtxS+cXL9+N2q4HNPUDLYT9i2TzebAqW0Hk17QmsLDp0z DIKlBPu+49MCwm4gpux9myEtwINmjMiEGF9efRRES3V9IJW5VD3Rc3NKKjr9JTK0J4Mg RtXA== MIME-Version: 1.0 X-Received: by 10.182.241.138 with SMTP id wi10mr16904268obc.48.1373203452870; Sun, 07 Jul 2013 06:24:12 -0700 (PDT) Received: by 10.182.22.4 with HTTP; Sun, 7 Jul 2013 06:24:12 -0700 (PDT) In-Reply-To: References: <1B87C63A-5E7A-4FEB-B995-B736E229CEE7@vpnc.org> <51D7209F.5090600@gmail.com> <6F2D0290-5A81-4121-A768-F81BC67DD122@checkpoint.com> <51D733CE.1090009@gmail.com> <51D79CDD.7020201@it.aoyama.ac.jp> <73CDEB14-35F4-412F-A110-042626473BF6@vpnc.org> <2622773E-5D8C-40A9-8EB2-AA769EF5BEF1@checkpoint.com> <17ED77E7-FBC7-4980-B79B-B2A61D0AD85B@vpnc.org> <51D84B5F.2070802@gmail.com> Date: Sun, 7 Jul 2013 09:24:12 -0400 Message-ID: From: Rifaat Shekh-Yusef To: Paul Hoffman Content-Type: multipart/alternative; boundary=089e01634d6203456004e0ebd80c Cc: "http-auth@ietf.org" Subject: Re: [http-auth] draft-ietf-httpauth-digest-update and SHA-3 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 13:24:14 -0000 --089e01634d6203456004e0ebd80c Content-Type: text/plain; charset=ISO-8859-1 I have just submitted a new version of the draft that removes SHA3 as a back algorithm and uses SHA2-512/256 instead. The draft also mentions that a future version might add SHA3 as a backup algorithm. https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest-update/ Please, review the new draft and let me know if you have any further comments. Regards, Rifaat On Sat, Jul 6, 2013 at 1:19 PM, Rifaat Shekh-Yusef wrote: > Yeah, I agree with Paul, and I am leaning towards adding SHA2-512/256 as a > backup algorithm and mentioning SHA3 as possible future replacement. > > Regards, > Rifaat > > > > On Sat, Jul 6, 2013 at 1:09 PM, Paul Hoffman wrote: > >> On Jul 6, 2013, at 9:52 AM, Yaron Sheffer wrote: >> >> > I think we're spending too much time on this one, but since you're >> asking... >> > >> > As far as I know (and if there's any cryptographer in the house, please >> correct me), SHA2-512 and SHA2-256 are based on the same building blocks. >> So if something bad happens to SHA2-256, we'd better migrate away to >> another primitive. In other words, I think adding SHA2-512 (truncated or >> not) would be a waste of time. >> >> This is uncreative thinking. The "something bad" could be related to the >> key table for SHA-256, at which point the backup would be fully useful. The >> "something bad" could also be more severe, but completely ameliorated by >> the extra bits in the mix-and-mash. >> >> > We'd better just hold our horses and add SHA3 as a backup algorithm in >> the future. >> >> I'm fine with either approach (backup is SHA-512-truncated, or no backup) >> IN the latter case, the initial RFC needs to signal that there is an >> expectation that there will be additional algorithms specified in the >> future so that an implementer knows that they should handle unexpected >> strings for the hash function, and hopefully make their hash-handling code >> flexible. >> >> --Paul Hoffman >> _______________________________________________ >> http-auth mailing list >> http-auth@ietf.org >> https://www.ietf.org/mailman/listinfo/http-auth >> > > --089e01634d6203456004e0ebd80c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have just submitted a new version of the draft that remo= ves SHA3 as a back algorithm and uses SHA2-512/256=A0instead. The draft als= o mentions that a future version might add SHA3 as a backup algorithm.






On Sat,= Jul 6, 2013 at 1:19 PM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
Yeah, I agree with Paul, an= d I am leaning towards adding SHA2-512/256 as a backup algorithm and mentio= ning SHA3 as possible future replacement.

Regards,
=A0Rifaat



On Sat, Jul 6, 2013 at 1:09= PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
On Jul 6, 2013, at 9:52 AM, Yaron Sheff= er <yaronf.ie= tf@gmail.com> wrote:

> I think we're spending too much time on this one, but since you= 9;re asking...
>
> As far as I know (and if there's any cryptographer in the house, p= lease correct me), SHA2-512 and SHA2-256 are based on the same building blo= cks. So if something bad happens to SHA2-256, we'd better migrate away = to another primitive. In other words, I think adding SHA2-512 (truncated or= not) would be a waste of time.

This is uncreative thinking. The "something bad" could be r= elated to the key table for SHA-256, at which point the backup would be ful= ly useful. The "something bad" could also be more severe, but com= pletely ameliorated by the extra bits in the mix-and-mash.

> We'd better just hold our horses and add SHA3 as a backup algorith= m in the future.

I'm fine with either approach (backup is SHA-512-truncated, or no= backup) IN the latter case, the initial RFC needs to signal that there is = an expectation that there will be additional algorithms specified in the fu= ture so that an implementer knows that they should handle unexpected string= s for the hash function, and hopefully make their hash-handling code flexib= le.

--Paul Hoffman
_______________________________________________
http-auth mailing list
http-auth@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/http-auth


--089e01634d6203456004e0ebd80c-- From paul.hoffman@vpnc.org Sun Jul 7 07:44:12 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51C2C21F9F62 for ; Sun, 7 Jul 2013 07:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6PHwHGxnhzZ for ; Sun, 7 Jul 2013 07:44:12 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id BF96C21F9F41 for ; Sun, 7 Jul 2013 07:44:11 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-228.dsl.dynamic.sonic.net [50.1.98.228]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r67Ei768031715 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 7 Jul 2013 07:44:09 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: Date: Sun, 7 Jul 2013 07:44:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3E34AC26-A4E7-496C-BB59-2E2493367956@vpnc.org> References: <1B87C63A-5E7A-4FEB-B995-B736E229CEE7@vpnc.org> <51D7209F.5090600@gmail.com> <6F2D0290-5A81-4121-A768-F81BC67DD122@checkpoint.com> <51D733CE.1090009@gmail.com> <51D79CDD.7020201@it.aoyama.ac.jp> <73CDEB14-35F4-412F-A110-042626473BF6@vpnc.org> <2622773E-5D8C-40A9-8EB2-AA769EF5BEF1@checkpoint.com> <17ED77E7-FBC7-4980-B79B-B2A61D0AD85B@vpnc.org> <51D84B5F.2070802@gmail.com> To: "http-auth@ietf.org" X-Mailer: Apple Mail (2.1508) Subject: Re: [http-auth] draft-ietf-httpauth-digest-update and SHA-3 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 14:44:12 -0000 On Jul 7, 2013, at 6:24 AM, Rifaat Shekh-Yusef = wrote: > I have just submitted a new version of the draft that removes SHA3 as = a back algorithm and uses SHA2-512/256 instead. The draft also mentions = that a future version might add SHA3 as a backup algorithm. > https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest-update/ >=20 > Please, review the new draft and let me know if you have any further = comments. This looks very good. We need a reference for SHA-512-256, but I think I = remember that NIST already has one. --Paul Hoffman= From yaronf.ietf@gmail.com Sun Jul 7 07:51:17 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A790B21F9F45 for ; Sun, 7 Jul 2013 07:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.836 X-Spam-Level: X-Spam-Status: No, score=-101.836 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_RECV_BEZEQINT_B=0.763, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x40u1igLnE99 for ; Sun, 7 Jul 2013 07:51:17 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 07A1A21F99F6 for ; Sun, 7 Jul 2013 07:51:16 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id z11so8281034wgg.1 for ; Sun, 07 Jul 2013 07:51:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=NI6/bw2UeRecwZU51/sDvb3KCbhV7fUK4sBuB/RXEiI=; b=JFk+5Z6ipZ/UyNFgG1lrgoX1HQZvIrwsfPqBEbAgNcCg5U8wD8SMOTnzLXYwb7ygV/ gYorM5pF9YE5ueF1uqlme1lihlHYYTQzMCNNCPyBxygHMjhLGv6fx9EugBkWYyUoTfMc uTHEK1iRREQ1VTZADbP9ektbp3jhF65kpNWTK6SfhSKM+L4AWLLoy16xk9Rnjh6XfhJ6 ZNCW4XW6E6QM1MdC7cGg6oOqmfU4z/oQK6a3b/ZwAeJ5OjI2YmF6wfIMlW2tqyAVzz2l ysirsmrEqG3Y50QXNcugnpzDPTur+YWk4LIeh+LvArmLWHhtZB8MngnT0ygPDz0N25ur ov6g== X-Received: by 10.180.108.50 with SMTP id hh18mr26943580wib.39.1373208676111; Sun, 07 Jul 2013 07:51:16 -0700 (PDT) Received: from [10.0.0.15] (bzq-218-191-220.red.bezeqint.net. [81.218.191.220]) by mx.google.com with ESMTPSA id eu1sm50023942wib.8.2013.07.07.07.51.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 07 Jul 2013 07:51:14 -0700 (PDT) Message-ID: <51D98060.8070907@gmail.com> Date: Sun, 07 Jul 2013 17:51:12 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Paul Hoffman References: <1B87C63A-5E7A-4FEB-B995-B736E229CEE7@vpnc.org> <51D7209F.5090600@gmail.com> <6F2D0290-5A81-4121-A768-F81BC67DD122@checkpoint.com> <51D733CE.1090009@gmail.com> <51D79CDD.7020201@it.aoyama.ac.jp> <73CDEB14-35F4-412F-A110-042626473BF6@vpnc.org> <2622773E-5D8C-40A9-8EB2-AA769EF5BEF1@checkpoint.com> <17ED77E7-FBC7-4980-B79B-B2A61D0AD85B@vpnc.org> <51D84B5F.2070802@gmail.com> <3E34AC26-A4E7-496C-BB59-2E2493367956@vpnc.org> In-Reply-To: <3E34AC26-A4E7-496C-BB59-2E2493367956@vpnc.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "http-auth@ietf.org" Subject: Re: [http-auth] draft-ietf-httpauth-digest-update and SHA-3 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 14:51:17 -0000 Hi, The draft mistakenly cites FIPS 186, rather than FIPS 180, for SHA2. The correct notation is "SHA-512/256". And most worryingly, reading Sec. 5.3.6 of the FIPS pub, I wonder if common implementations of SHA2 support this algorithm, which is *not* the naive truncation that I expected it to be. Thanks, Yaron On 2013-07-07 17:44, Paul Hoffman wrote: > On Jul 7, 2013, at 6:24 AM, Rifaat Shekh-Yusef wrote: > >> I have just submitted a new version of the draft that removes SHA3 as a back algorithm and uses SHA2-512/256 instead. The draft also mentions that a future version might add SHA3 as a backup algorithm. >> https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest-update/ >> >> Please, review the new draft and let me know if you have any further comments. > > This looks very good. We need a reference for SHA-512-256, but I think I remember that NIST already has one. > > --Paul Hoffman > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > From paul.hoffman@vpnc.org Sun Jul 7 08:30:00 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 545D821F9F51 for ; Sun, 7 Jul 2013 08:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IBV46aLC+0Ya for ; Sun, 7 Jul 2013 08:29:59 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id D2A5F21F9F4D for ; Sun, 7 Jul 2013 08:29:59 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-228.dsl.dynamic.sonic.net [50.1.98.228]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r67FTuP6032793 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 7 Jul 2013 08:29:58 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <51D98060.8070907@gmail.com> Date: Sun, 7 Jul 2013 08:29:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <802D0671-970F-4235-96D0-926E8F345CA8@vpnc.org> References: <1B87C63A-5E7A-4FEB-B995-B736E229CEE7@vpnc.org> <51D7209F.5090600@gmail.com> <6F2D0290-5A81-4121-A768-F81BC67DD122@checkpoint.com> <51D733CE.1090009@gmail.com> <51D79CDD.7020201@it.aoyama.ac.jp> <73CDEB14-35F4-412F-A110-042626473BF6@vpnc.org> <2622773E-5D8C-40A9-8EB2-AA769EF5BEF1@checkpoint.com> <17ED77E7-FBC7-4980-B79B-B2A61D0AD85B@vpnc.org> <51D84B5F.2070802@gmail.com> <3E34AC26-A4E7-496C-BB59-2E2493367956@vpnc.org> <51D98060.8070907@gmail.com> To: "http-auth@ietf.org" X-Mailer: Apple Mail (2.1508) Subject: Re: [http-auth] draft-ietf-httpauth-digest-update and SHA-3 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 15:30:00 -0000 On Jul 7, 2013, at 7:51 AM, Yaron Sheffer wrote: > The draft mistakenly cites FIPS 186, rather than FIPS 180, for SHA2. Good catch. > The correct notation is "SHA-512/256". Yes, I noticed that, but wasn't sure we wanted a "/" in our algorithm = names. > And most worryingly, reading Sec. 5.3.6 of the FIPS pub, I wonder if = common implementations of SHA2 support this algorithm, which is *not* = the naive truncation that I expected it to be. Then we should call it out. There is also a draft, = draft-dang-turner-sha-512-224-256, that covers the same material, and = that draft might get on RFC track before this one, given that it is = uncontentious. --Paul Hoffman= From ynir@checkpoint.com Sun Jul 7 08:56:39 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9ADD21F9F00 for ; Sun, 7 Jul 2013 08:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.532 X-Spam-Level: X-Spam-Status: No, score=-10.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9l4-BP9vHeB for ; Sun, 7 Jul 2013 08:56:35 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id B131121F9C4A for ; Sun, 7 Jul 2013 08:56:34 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r67FuUJ8012877; Sun, 7 Jul 2013 18:56:30 +0300 X-CheckPoint: {51D98FAE-15-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.48]) by IL-EX10.ad.checkpoint.com ([169.254.2.91]) with mapi id 14.02.0342.003; Sun, 7 Jul 2013 18:56:30 +0300 From: Yoav Nir To: Yaron Sheffer Thread-Topic: [http-auth] draft-ietf-httpauth-digest-update and SHA-3 Thread-Index: AQHOeZItOyP0ZMM/I0qnJaYgM96yh5lWIBCAgAAGPoCAACKbgIAADaEAgAAJPgCAACRKgIAATyMAgAAJ0ICAALGHgIAABDcAgAAEjYCAABIKgIAAA7KAgAAEnYCAAAL8AIABUHUAgAAWVgCAAAH5AIAAEX+A Date: Sun, 7 Jul 2013 15:56:31 +0000 Message-ID: <372113A7-E037-4BC8-887E-1298F2B0E431@checkpoint.com> References: <1B87C63A-5E7A-4FEB-B995-B736E229CEE7@vpnc.org> <51D7209F.5090600@gmail.com> <6F2D0290-5A81-4121-A768-F81BC67DD122@checkpoint.com> <51D733CE.1090009@gmail.com> <51D79CDD.7020201@it.aoyama.ac.jp> <73CDEB14-35F4-412F-A110-042626473BF6@vpnc.org> <2622773E-5D8C-40A9-8EB2-AA769EF5BEF1@checkpoint.com> <17ED77E7-FBC7-4980-B79B-B2A61D0AD85B@vpnc.org> <51D84B5F.2070802@gmail.com> <3E34AC26-A4E7-496C-BB59-2E2493367956@vpnc.org> <51D98060.8070907@gmail.com> In-Reply-To: <51D98060.8070907@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.21] x-kse-antivirus-interceptor-info: protection disabled x-cpdlp: 11c34ee130b07dfcc49a889640e43703ea3b962073 Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "http-auth@ietf.org" , Paul Hoffman Subject: Re: [http-auth] draft-ietf-httpauth-digest-update and SHA-3 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 15:56:40 -0000 [with implementer hat on] My implementation has it, although this makes little difference as it's not= a public library. OIDs are already defined for this algorithm (2.16.840.1.101.3.4.2.6 and 1.2= .840.113549.1.1.16) but I'm not aware of anyone issuing certificates with i= t. We could define a simple truncation of SHA2-512 ourselves, but I guess ther= e was some method behind defining it a little differently. Anyone know? Yoav On Jul 7, 2013, at 5:51 PM, Yaron Sheffer wrote: > Hi, >=20 > The draft mistakenly cites FIPS 186, rather than FIPS 180, for SHA2. >=20 > The correct notation is "SHA-512/256". >=20 > And most worryingly, reading Sec. 5.3.6 of the FIPS pub, I wonder if comm= on implementations of SHA2 support this algorithm, which is *not* the naive= truncation that I expected it to be. >=20 > Thanks, > Yaron >=20 > On 2013-07-07 17:44, Paul Hoffman wrote: >> On Jul 7, 2013, at 6:24 AM, Rifaat Shekh-Yusef w= rote: >>=20 >>> I have just submitted a new version of the draft that removes SHA3 as a= back algorithm and uses SHA2-512/256 instead. The draft also mentions that= a future version might add SHA3 as a backup algorithm. >>> https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest-update/ >>>=20 >>> Please, review the new draft and let me know if you have any further co= mments. >>=20 >> This looks very good. We need a reference for SHA-512-256, but I think I= remember that NIST already has one. >>=20 >> --Paul Hoffman From ynir@checkpoint.com Sun Jul 7 08:56:41 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2EAA21F9C4A for ; Sun, 7 Jul 2013 08:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.532 X-Spam-Level: X-Spam-Status: No, score=-10.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B33qXh2+GLwx for ; Sun, 7 Jul 2013 08:56:41 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5D821F9C45 for ; Sun, 7 Jul 2013 08:56:40 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r67FucsW012890; Sun, 7 Jul 2013 18:56:38 +0300 X-CheckPoint: {51D98FB6-7-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.48]) by IL-EX10.ad.checkpoint.com ([169.254.2.91]) with mapi id 14.02.0342.003; Sun, 7 Jul 2013 18:56:38 +0300 From: Yoav Nir To: Yaron Sheffer Thread-Topic: [http-auth] draft-ietf-httpauth-digest-update and SHA-3 Thread-Index: AQHOeZItOyP0ZMM/I0qnJaYgM96yh5lWIBCAgAAGPoCAACKbgIAADaEAgAAJPgCAACRKgIAATyMAgAAJ0ICAALGHgIAABDcAgAAEjYCAABIKgIAAA7KAgAAEnYCAAAL8AIABUHUAgAAWVgCAAAH5AIAAEjoA Date: Sun, 7 Jul 2013 15:56:38 +0000 Message-ID: <1B452FCD-0754-4D3A-8636-644839D34352@checkpoint.com> References: <1B87C63A-5E7A-4FEB-B995-B736E229CEE7@vpnc.org> <51D7209F.5090600@gmail.com> <6F2D0290-5A81-4121-A768-F81BC67DD122@checkpoint.com> <51D733CE.1090009@gmail.com> <51D79CDD.7020201@it.aoyama.ac.jp> <73CDEB14-35F4-412F-A110-042626473BF6@vpnc.org> <2622773E-5D8C-40A9-8EB2-AA769EF5BEF1@checkpoint.com> <17ED77E7-FBC7-4980-B79B-B2A61D0AD85B@vpnc.org> <51D84B5F.2070802@gmail.com> <3E34AC26-A4E7-496C-BB59-2E2493367956@vpnc.org> <51D98060.8070907@gmail.com> In-Reply-To: <51D98060.8070907@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.21] x-kse-antivirus-interceptor-info: protection disabled x-cpdlp: 11771bba13a08822c09565875c5d611a7ab8212118 Content-Type: text/plain; charset="us-ascii" Content-ID: <74B1FD4489EFF04FB2AEE56634456E78@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "http-auth@ietf.org" , Paul Hoffman Subject: Re: [http-auth] draft-ietf-httpauth-digest-update and SHA-3 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 15:56:41 -0000 [with implementer hat on] My implementation has it, although this makes little difference as it's not= a public library. OIDs are already defined for this algorithm (2.16.840.1.101.3.4.2.6 and 1.2= .840.113549.1.1.16) but I'm not aware of anyone issuing certificates with i= t. We could define a simple truncation of SHA2-512 ourselves, but I guess ther= e was some method behind defining it a little differently. Anyone know? Yoav On Jul 7, 2013, at 5:51 PM, Yaron Sheffer wrote: > Hi, >=20 > The draft mistakenly cites FIPS 186, rather than FIPS 180, for SHA2. >=20 > The correct notation is "SHA-512/256". >=20 > And most worryingly, reading Sec. 5.3.6 of the FIPS pub, I wonder if comm= on implementations of SHA2 support this algorithm, which is *not* the naive= truncation that I expected it to be. >=20 > Thanks, > Yaron >=20 > On 2013-07-07 17:44, Paul Hoffman wrote: >> On Jul 7, 2013, at 6:24 AM, Rifaat Shekh-Yusef w= rote: >>=20 >>> I have just submitted a new version of the draft that removes SHA3 as a= back algorithm and uses SHA2-512/256 instead. The draft also mentions that= a future version might add SHA3 as a backup algorithm. >>> https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest-update/ >>>=20 >>> Please, review the new draft and let me know if you have any further co= mments. >>=20 >> This looks very good. We need a reference for SHA-512-256, but I think I= remember that NIST already has one. >>=20 >> --Paul Hoffman From ynir@checkpoint.com Sun Jul 7 08:56:48 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E44221F9F89 for ; Sun, 7 Jul 2013 08:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.532 X-Spam-Level: X-Spam-Status: No, score=-10.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xqf-loU+us7A for ; Sun, 7 Jul 2013 08:56:48 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 9B01421F9C45 for ; Sun, 7 Jul 2013 08:56:47 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r67FujVi012901; Sun, 7 Jul 2013 18:56:45 +0300 X-CheckPoint: {51D98FBD-2-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.48]) by IL-EX10.ad.checkpoint.com ([169.254.2.91]) with mapi id 14.02.0342.003; Sun, 7 Jul 2013 18:56:44 +0300 From: Yoav Nir To: Yaron Sheffer Thread-Topic: [http-auth] draft-ietf-httpauth-digest-update and SHA-3 Thread-Index: AQHOeZItOyP0ZMM/I0qnJaYgM96yh5lWIBCAgAAGPoCAACKbgIAADaEAgAAJPgCAACRKgIAATyMAgAAJ0ICAALGHgIAABDcAgAAEjYCAABIKgIAAA7KAgAAEnYCAAAL8AIABUHUAgAAWVgCAAAH5AIAAEkeA Date: Sun, 7 Jul 2013 15:56:44 +0000 Message-ID: References: <1B87C63A-5E7A-4FEB-B995-B736E229CEE7@vpnc.org> <51D7209F.5090600@gmail.com> <6F2D0290-5A81-4121-A768-F81BC67DD122@checkpoint.com> <51D733CE.1090009@gmail.com> <51D79CDD.7020201@it.aoyama.ac.jp> <73CDEB14-35F4-412F-A110-042626473BF6@vpnc.org> <2622773E-5D8C-40A9-8EB2-AA769EF5BEF1@checkpoint.com> <17ED77E7-FBC7-4980-B79B-B2A61D0AD85B@vpnc.org> <51D84B5F.2070802@gmail.com> <3E34AC26-A4E7-496C-BB59-2E2493367956@vpnc.org> <51D98060.8070907@gmail.com> In-Reply-To: <51D98060.8070907@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.21] x-kse-antivirus-interceptor-info: protection disabled x-cpdlp: 119a484e4558ad4e9c2c7dad45b3ec02190734fd00 Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "http-auth@ietf.org" , Paul Hoffman Subject: Re: [http-auth] draft-ietf-httpauth-digest-update and SHA-3 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 15:56:48 -0000 [with implementer hat on] My implementation has it, although this makes little difference as it's not= a public library. OIDs are already defined for this algorithm (2.16.840.1.101.3.4.2.6 and 1.2= .840.113549.1.1.16) but I'm not aware of anyone issuing certificates with i= t. We could define a simple truncation of SHA2-512 ourselves, but I guess ther= e was some method behind defining it a little differently. Anyone know? Yoav On Jul 7, 2013, at 5:51 PM, Yaron Sheffer wrote: > Hi, >=20 > The draft mistakenly cites FIPS 186, rather than FIPS 180, for SHA2. >=20 > The correct notation is "SHA-512/256". >=20 > And most worryingly, reading Sec. 5.3.6 of the FIPS pub, I wonder if comm= on implementations of SHA2 support this algorithm, which is *not* the naive= truncation that I expected it to be. >=20 > Thanks, > Yaron >=20 > On 2013-07-07 17:44, Paul Hoffman wrote: >> On Jul 7, 2013, at 6:24 AM, Rifaat Shekh-Yusef w= rote: >>=20 >>> I have just submitted a new version of the draft that removes SHA3 as a= back algorithm and uses SHA2-512/256 instead. The draft also mentions that= a future version might add SHA3 as a backup algorithm. >>> https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest-update/ >>>=20 >>> Please, review the new draft and let me know if you have any further co= mments. >>=20 >> This looks very good. We need a reference for SHA-512-256, but I think I= remember that NIST already has one. >>=20 >> --Paul Hoffman From ynir@checkpoint.com Sun Jul 7 09:14:58 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E29221F8ECB for ; Sun, 7 Jul 2013 09:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.535 X-Spam-Level: X-Spam-Status: No, score=-10.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZiAz9NV2YQ35 for ; Sun, 7 Jul 2013 09:14:53 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 4379021F8B8B for ; Sun, 7 Jul 2013 09:14:53 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r67GEqLI018135 for ; Sun, 7 Jul 2013 19:14:52 +0300 X-CheckPoint: {51D993FC-0-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.48]) by IL-EX10.ad.checkpoint.com ([169.254.2.91]) with mapi id 14.02.0342.003; Sun, 7 Jul 2013 19:14:51 +0300 From: Yoav Nir To: "http-auth@ietf.org" Thread-Topic: [http-auth] draft-ietf-httpauth-digest-update and SHA-3 Thread-Index: AQHOeZItOyP0ZMM/I0qnJaYgM96yh5lWIBCAgAAGPoCAACKbgIAADaEAgAAJPgCAACRKgIAATyMAgAAJ0ICAALGHgIAABDcAgAAEjYCAABIKgIAAA7KAgAAEnYCAAAL8AIABUHUAgAAWVgCAAAH5AIAAEkeAgAAFFQA= Date: Sun, 7 Jul 2013 16:14:51 +0000 Message-ID: References: <1B87C63A-5E7A-4FEB-B995-B736E229CEE7@vpnc.org> <51D7209F.5090600@gmail.com> <6F2D0290-5A81-4121-A768-F81BC67DD122@checkpoint.com> <51D733CE.1090009@gmail.com> <51D79CDD.7020201@it.aoyama.ac.jp> <73CDEB14-35F4-412F-A110-042626473BF6@vpnc.org> <2622773E-5D8C-40A9-8EB2-AA769EF5BEF1@checkpoint.com> <17ED77E7-FBC7-4980-B79B-B2A61D0AD85B@vpnc.org> <51D84B5F.2070802@gmail.com> <3E34AC26-A4E7-496C-BB59-2E2493367956@vpnc.org> <51D98060.8070907@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.21] x-kse-antivirus-interceptor-info: protection disabled x-cpdlp: 11437bf8b95adfa2cb8ec09a4259b05fd990bf708a Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [http-auth] draft-ietf-httpauth-digest-update and SHA-3 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 16:14:58 -0000 Aargh. What I tell you three times is true? Sorry about that. Yoav On Jul 7, 2013, at 6:56 PM, Yoav Nir wrote: > [with implementer hat on] >=20 > My implementation has it, although this makes little difference as it's n= ot a public library. >=20 > OIDs are already defined for this algorithm (2.16.840.1.101.3.4.2.6 and 1= .2.840.113549.1.1.16) but I'm not aware of anyone issuing certificates with= it. >=20 > We could define a simple truncation of SHA2-512 ourselves, but I guess th= ere was some method behind defining it a little differently. Anyone know? >=20 > Yoav >=20 > On Jul 7, 2013, at 5:51 PM, Yaron Sheffer wrote: >=20 >> Hi, >>=20 >> The draft mistakenly cites FIPS 186, rather than FIPS 180, for SHA2. >>=20 >> The correct notation is "SHA-512/256". >>=20 >> And most worryingly, reading Sec. 5.3.6 of the FIPS pub, I wonder if com= mon implementations of SHA2 support this algorithm, which is *not* the naiv= e truncation that I expected it to be. >>=20 >> Thanks, >> Yaron >>=20 >> On 2013-07-07 17:44, Paul Hoffman wrote: >>> On Jul 7, 2013, at 6:24 AM, Rifaat Shekh-Yusef = wrote: >>>=20 >>>> I have just submitted a new version of the draft that removes SHA3 as = a back algorithm and uses SHA2-512/256 instead. The draft also mentions tha= t a future version might add SHA3 as a backup algorithm. >>>> https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest-update/ >>>>=20 >>>> Please, review the new draft and let me know if you have any further c= omments. >>>=20 >>> This looks very good. We need a reference for SHA-512-256, but I think = I remember that NIST already has one. >>>=20 >>> --Paul Hoffman >=20 > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth From yaronf.ietf@gmail.com Sun Jul 7 09:32:20 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9F4221F9F8F for ; Sun, 7 Jul 2013 09:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHAEt6rioMdM for ; Sun, 7 Jul 2013 09:32:20 -0700 (PDT) Received: from mail-ea0-x22d.google.com (mail-ea0-x22d.google.com [IPv6:2a00:1450:4013:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id DD73A21F9F62 for ; Sun, 7 Jul 2013 09:32:19 -0700 (PDT) Received: by mail-ea0-f173.google.com with SMTP id g15so2444709eak.18 for ; Sun, 07 Jul 2013 09:32:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=SqVQ6YrCTRURruY5Gc7Y5NyD4bBCLaj9zs9EoSl7plo=; b=O7MHD4v0tN1Zjzr1A32Epu0Z8/ANtrJFZABUwZjKEJqgM1p3xoT1JsWnldheuYrP8m jQfwvlvEHOwuUy91zq624lRtrE3wbH6464v+l9lLqOppPRhn7nQkJO8YlGRIChhVh83J bPsIikLblCPpyXdcwTq3Z9DpmU81pyXFdXEKvaxK+acF5wTQRS7WKqPw0EHVJE1N9qTu ynkajFAWiJWE/Gh4tsteRRIHpVPtQMsiARxqrG49Xu8ursgvZxW8QWLy0MTCTXYI4KC1 YaAV2id0yaIqkX1gS0+TKG/osEYphDQ4ZX6XRTdZZPFx5xWJm0BMc7TwRVRYhDA3iJTQ 9VFw== X-Received: by 10.15.26.199 with SMTP id n47mr21238931eeu.88.1373214737841; Sun, 07 Jul 2013 09:32:17 -0700 (PDT) Received: from [10.100.102.16] (93-172-160-171.bb.netvision.net.il. [93.172.160.171]) by mx.google.com with ESMTPSA id l42sm34274181eeo.14.2013.07.07.09.32.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 07 Jul 2013 09:32:17 -0700 (PDT) Message-ID: <51D9980E.3060206@gmail.com> Date: Sun, 07 Jul 2013 19:32:14 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Paul Hoffman References: <1B87C63A-5E7A-4FEB-B995-B736E229CEE7@vpnc.org> <51D7209F.5090600@gmail.com> <6F2D0290-5A81-4121-A768-F81BC67DD122@checkpoint.com> <51D733CE.1090009@gmail.com> <51D79CDD.7020201@it.aoyama.ac.jp> <73CDEB14-35F4-412F-A110-042626473BF6@vpnc.org> <2622773E-5D8C-40A9-8EB2-AA769EF5BEF1@checkpoint.com> <17ED77E7-FBC7-4980-B79B-B2A61D0AD85B@vpnc.org> <51D84B5F.2070802@gmail.com> <3E34AC26-A4E7-496C-BB59-2E2493367956@vpnc.org> <51D98060.8070907@gmail.com> <802D0671-970F-4235-96D0-926E8F345CA8@vpnc.org> In-Reply-To: <802D0671-970F-4235-96D0-926E8F345CA8@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "http-auth@ietf.org" Subject: Re: [http-auth] draft-ietf-httpauth-digest-update and SHA-3 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 16:32:20 -0000 Re: notation, I meant that this is the official name of the algorithm, and should be used in the running text. I'm not saying it should go verbatim into the HTTP header. Thanks, Yaron On 2013-07-07 18:29, Paul Hoffman wrote: > On Jul 7, 2013, at 7:51 AM, Yaron Sheffer wrote: > >> The draft mistakenly cites FIPS 186, rather than FIPS 180, for SHA2. > > Good catch. > >> The correct notation is "SHA-512/256". > > Yes, I noticed that, but wasn't sure we wanted a "/" in our algorithm names. > >> And most worryingly, reading Sec. 5.3.6 of the FIPS pub, I wonder if common implementations of SHA2 support this algorithm, which is *not* the naive truncation that I expected it to be. > > Then we should call it out. There is also a draft, draft-dang-turner-sha-512-224-256, that covers the same material, and that draft might get on RFC track before this one, given that it is uncontentious. > > --Paul Hoffman > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > From ilari.liusvaara@elisanet.fi Sun Jul 7 10:11:36 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDE0921F9F1E; Sun, 7 Jul 2013 10:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M19UcaNug8PH; Sun, 7 Jul 2013 10:11:29 -0700 (PDT) Received: from emh01.mail.saunalahti.fi (emh01.mail.saunalahti.fi [62.142.5.107]) by ietfa.amsl.com (Postfix) with ESMTP id 5732521F8E98; Sun, 7 Jul 2013 10:11:13 -0700 (PDT) Received: from saunalahti-vams (vs3-11.mail.saunalahti.fi [62.142.5.95]) by emh01.mail.saunalahti.fi (Postfix) with SMTP id 3192A9003F; Sun, 7 Jul 2013 20:11:11 +0300 (EEST) Received: from emh04.mail.saunalahti.fi ([62.142.5.110]) by vs3-11.mail.saunalahti.fi ([62.142.5.95]) with SMTP (gateway) id A0230330843; Sun, 07 Jul 2013 20:11:11 +0300 Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id A22B41A25D3; Sun, 7 Jul 2013 20:11:10 +0300 (EEST) Date: Sun, 7 Jul 2013 20:11:10 +0300 From: Ilari Liusvaara To: http-auth@ietf.org Message-ID: <20130707171110.GA16813@LK-Perkele-VII> References: <20130707131242.3676.40484.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20130707131242.3676.40484.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Ilari Liusvaara X-Antivirus: VAMS Cc: http-auth@ietf.org, i-d-announce@ietf.org Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-update-03.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 17:11:36 -0000 On Sun, Jul 07, 2013 at 06:12:42AM -0700, internet-drafts@ietf.org wrote: > > Filename : draft-ietf-httpauth-digest-update-03.txt One of the examples in section 3.5 contains: algorithm="SHA2" This should presumably be: algorithm="SHA2-256" ? -Ilari From rifaat.ietf@gmail.com Sun Jul 7 16:00:03 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29EF411E814B for ; Sun, 7 Jul 2013 16:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.721 X-Spam-Level: X-Spam-Status: No, score=-1.721 tagged_above=-999 required=5 tests=[AWL=-0.788, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6RCq4ajastF for ; Sun, 7 Jul 2013 16:00:02 -0700 (PDT) Received: from mail-oa0-x235.google.com (mail-oa0-x235.google.com [IPv6:2607:f8b0:4003:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 1691521F8FAF for ; Sun, 7 Jul 2013 16:00:01 -0700 (PDT) Received: by mail-oa0-f53.google.com with SMTP id k14so5585124oag.12 for ; Sun, 07 Jul 2013 16:00:00 -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=+9+cv/IfHFCtuPUhe76dw026QxT6HSOmlmd92IcdaRc=; b=wlg6EEQkiVDaYM7oM9v3Kz1cX2bmBBSnmCCKJCjRWq2eBCJmQrBYklITRYZwub9rcD DpLuTVidLznZpvkcLXk5srPPcrJI/RRQErxbEMBO7TAspDeS7LcCuQAw/ZARGtxTU7vr rrYOS1eLKmN1jfrtKexJ8ayuHeVovY6it59aqHXE12HdJCMuyytIs8jicCe5SEBpN+h7 VcbfFMfqstEgWjThXBi1i0MgrN4KN5/21HCRecH/uPB0HwJihyctfkTDTtBJmWKAgJb8 4rXgbV05ttJyywTNQqHdOoF3gjsdIpm0TjmsfWG+yupFaeHpMHADl663myveSK9ZGfRX uQqQ== MIME-Version: 1.0 X-Received: by 10.60.161.136 with SMTP id xs8mr18421166oeb.77.1373238000439; Sun, 07 Jul 2013 16:00:00 -0700 (PDT) Received: by 10.182.22.4 with HTTP; Sun, 7 Jul 2013 16:00:00 -0700 (PDT) In-Reply-To: <51D9980E.3060206@gmail.com> References: <1B87C63A-5E7A-4FEB-B995-B736E229CEE7@vpnc.org> <51D7209F.5090600@gmail.com> <6F2D0290-5A81-4121-A768-F81BC67DD122@checkpoint.com> <51D733CE.1090009@gmail.com> <51D79CDD.7020201@it.aoyama.ac.jp> <73CDEB14-35F4-412F-A110-042626473BF6@vpnc.org> <2622773E-5D8C-40A9-8EB2-AA769EF5BEF1@checkpoint.com> <17ED77E7-FBC7-4980-B79B-B2A61D0AD85B@vpnc.org> <51D84B5F.2070802@gmail.com> <3E34AC26-A4E7-496C-BB59-2E2493367956@vpnc.org> <51D98060.8070907@gmail.com> <802D0671-970F-4235-96D0-926E8F345CA8@vpnc.org> <51D9980E.3060206@gmail.com> Date: Sun, 7 Jul 2013 19:00:00 -0400 Message-ID: From: Rifaat Shekh-Yusef To: Yaron Sheffer Content-Type: multipart/alternative; boundary=089e01183a183558b504e0f3e379 Cc: "http-auth@ietf.org" , Paul Hoffman Subject: Re: [http-auth] draft-ietf-httpauth-digest-update and SHA-3 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 23:00:03 -0000 --089e01183a183558b504e0f3e379 Content-Type: text/plain; charset=ISO-8859-1 Thanks, I will fix the errors, add references, and add some text around the possible lack of implementations for the SHA2-512/256 algorithm. Regards, Rifaat On Sun, Jul 7, 2013 at 12:32 PM, Yaron Sheffer wrote: > Re: notation, I meant that this is the official name of the algorithm, and > should be used in the running text. I'm not saying it should go verbatim > into the HTTP header. > > Thanks, > Yaron > > > On 2013-07-07 18:29, Paul Hoffman wrote: > >> On Jul 7, 2013, at 7:51 AM, Yaron Sheffer wrote: >> >> The draft mistakenly cites FIPS 186, rather than FIPS 180, for SHA2. >>> >> >> Good catch. >> >> The correct notation is "SHA-512/256". >>> >> >> Yes, I noticed that, but wasn't sure we wanted a "/" in our algorithm >> names. >> >> And most worryingly, reading Sec. 5.3.6 of the FIPS pub, I wonder if >>> common implementations of SHA2 support this algorithm, which is *not* the >>> naive truncation that I expected it to be. >>> >> >> Then we should call it out. There is also a draft, >> draft-dang-turner-sha-512-224-**256, that covers the same material, and >> that draft might get on RFC track before this one, given that it is >> uncontentious. >> >> --Paul Hoffman >> ______________________________**_________________ >> http-auth mailing list >> http-auth@ietf.org >> https://www.ietf.org/mailman/**listinfo/http-auth >> >> ______________________________**_________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/**listinfo/http-auth > --089e01183a183558b504e0f3e379 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks, I will fix the errors, add references, and add som= e text around the possible lack of implementations for the=A0SHA2-512/256 algorithm.

Re= gards,
=A0Rifaat

=


On Sun, Jul 7, 2013 at 12:32 PM, Yaron Sheffer <= yaronf.ietf@gmai= l.com> wrote:
Re: notation, I meant that this is the offic= ial name of the algorithm, and should be used in the running text. I'm = not saying it should go verbatim into the HTTP header.

Thanks,
=A0 =A0 =A0 =A0 Yaron


On 2013-07-07 18:29, Paul Hoffman wrote:
On Jul 7, 2013, at 7:51 AM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

The draft mistakenly cites FIPS 186, rather than FIPS 180, for SHA2.

Good catch.

The correct notation is "SHA-512/256".

Yes, I noticed that, but wasn't sure we wanted a "/" in our a= lgorithm names.

And most worryingly, reading Sec. 5.3.6 of the FIPS pub, I wonder if common= implementations of SHA2 support this algorithm, which is *not* the naive t= runcation that I expected it to be.

Then we should call it out. There is also a draft, draft-dang-turner-sha-51= 2-224-256, that covers the same material, and that draft might get o= n RFC track before this one, given that it is uncontentious.

--Paul Hoffman
_______________________________________________
http-auth mailing list
http-auth@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/http-auth

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

--089e01183a183558b504e0f3e379-- From rifaat.ietf@gmail.com Sun Jul 7 16:02:11 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE6D11E814C; Sun, 7 Jul 2013 16:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQcAtfHqXQZ7; Sun, 7 Jul 2013 16:02:10 -0700 (PDT) Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 14E8011E8155; Sun, 7 Jul 2013 16:02:03 -0700 (PDT) Received: by mail-oa0-f41.google.com with SMTP id n10so5590779oag.14 for ; Sun, 07 Jul 2013 16:02:02 -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=v9yW30/Uk7ZjhDYi0g7iQu47g9bOejKxIPHWfTEeMuU=; b=hBb3Q4eLK+gVDYGVw8vukjTPlReeQs/0hVQCOnLYu6LmaXgkRlq2fFnmcm2/Xx9i2q N3G6wC6ZsIsD3OVM4VYUsVulAUd6RTsq7dojmKflNcsLhJdgxAUisiTDEKO87Dmdv3xO meaWEP97fGdJlrbQFG9yYkjGAwFFwSrgUk3ja0Zd3C0rIBgB1HD/NP4JWbCzylJgNTCi 9gZx3C1mtkmer9OBvQMIFJ7iPiTvBhXLjyMfOGQcraT4o9RsvY8F8p4PWw6P2SLO4DxH P4e1Q9wFaROwVyIst3CMAyRq8GdI3GGTVQvewJHaoWED37MduU6qv3QYGIZE6LW6Oy7s laTA== MIME-Version: 1.0 X-Received: by 10.182.39.168 with SMTP id q8mr18450192obk.72.1373238122551; Sun, 07 Jul 2013 16:02:02 -0700 (PDT) Received: by 10.182.22.4 with HTTP; Sun, 7 Jul 2013 16:02:02 -0700 (PDT) In-Reply-To: <20130707171110.GA16813@LK-Perkele-VII> References: <20130707131242.3676.40484.idtracker@ietfa.amsl.com> <20130707171110.GA16813@LK-Perkele-VII> Date: Sun, 7 Jul 2013 19:02:02 -0400 Message-ID: From: Rifaat Shekh-Yusef To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a11c3059e7ca01404e0f3ea00 Cc: "http-auth@ietf.org" , i-d-announce@ietf.org Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-update-03.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 23:02:11 -0000 --001a11c3059e7ca01404e0f3ea00 Content-Type: text/plain; charset=ISO-8859-1 Thanks Ilari, yes, it should be SHA2-256. will fix it. Regards, Rifaat On Sun, Jul 7, 2013 at 1:11 PM, Ilari Liusvaara wrote: > On Sun, Jul 07, 2013 at 06:12:42AM -0700, internet-drafts@ietf.org wrote: > > > > Filename : draft-ietf-httpauth-digest-update-03.txt > > One of the examples in section 3.5 contains: > > algorithm="SHA2" > > This should presumably be: > > algorithm="SHA2-256" > > ? > > -Ilari > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > --001a11c3059e7ca01404e0f3ea00 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks Ilari, yes, it should be SHA2-256. will fix it.
Regards,
=A0Rifaat


On Sun, Jul 7, 2013 at 1:11 PM, Ilari Liusvaara <ilari.liusvaar= a@elisanet.fi> wrote:
On Sun, Jul 07, 2013 at 06:12:42AM -0700, internet-drafts@ietf.org wrot= e:
>
> =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-httpauth-digest-updat= e-03.txt

One of the examples in section 3.5 contains:

algorithm=3D"SHA2"

This should presumably be:

algorithm=3D"SHA2-256"

?

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

--001a11c3059e7ca01404e0f3ea00-- From internet-drafts@ietf.org Sat Jul 13 07:39:49 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3CB021F9D28; Sat, 13 Jul 2013 07:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hXhNaTmEGD47; Sat, 13 Jul 2013 07:39:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 46D4921F9C8F; Sat, 13 Jul 2013 07:39:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130713143948.13453.39592.idtracker@ietfa.amsl.com> Date: Sat, 13 Jul 2013 07:39:48 -0700 Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-digest-update-04.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 14:39:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Hypertext Transfer Protocol Authenticatio= n Working Group of the IETF. Title : HTTP Digest Update Author(s) : Rifaat Shekh-Yusef David Ahrens Filename : draft-ietf-httpauth-digest-update-04.txt Pages : 10 Date : 2013-07-13 Abstract: This documents specifies extensions to the HTTP Digest Authentication mechanism to add support for new digest algorithms to the HTTP Digest Access Authentication scheme. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest-update There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-httpauth-digest-update-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-httpauth-digest-update-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rifaat.ietf@gmail.com Sat Jul 13 07:47:32 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B43821F9E0C for ; Sat, 13 Jul 2013 07:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UjoGhBhHyFhJ for ; Sat, 13 Jul 2013 07:47:31 -0700 (PDT) Received: from mail-ea0-x235.google.com (mail-ea0-x235.google.com [IPv6:2a00:1450:4013:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 7428921F9DF0 for ; Sat, 13 Jul 2013 07:47:31 -0700 (PDT) Received: by mail-ea0-f181.google.com with SMTP id a15so7007880eae.12 for ; Sat, 13 Jul 2013 07:47:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=fMbMoenBnbnq6RI+IkT8+QBR/z9XZHaQPpv+yebKiIY=; b=zwNdeqtkIgO5GyueYlJsUfyr22o6gQxP6EdDnN8zBPG6l56UxJ40it0wlOKrhPJfdt XGsKGJ3dTsQVnEHwElMX83LncZKfcRESn4ybTi0A4eyYKPSke3MenH88e2nPNlsRQeN6 lfpxEYHRLpM1OEcGr1EV6O1X02XB4zHwOb2Tk96YsYNh6vas4sMRRH3XFWQDYr+3Bp2E KIwmLHRipuzINLgQUSxyHcGbLbIiv2yD6vQmxlA2D5ukyxJhL0fRlCy95QxZh+pFil5U 9i2dCUgJ3ksPLETi9Csq/dhdDX0y9jOwf5YeSUuXXIn5fqHHw20JDry7ptcB5YYxBPHn RQtg== MIME-Version: 1.0 X-Received: by 10.14.213.135 with SMTP id a7mr50924792eep.152.1373726850603; Sat, 13 Jul 2013 07:47:30 -0700 (PDT) Received: by 10.15.110.137 with HTTP; Sat, 13 Jul 2013 07:47:30 -0700 (PDT) In-Reply-To: <20130713143948.13453.39592.idtracker@ietfa.amsl.com> References: <20130713143948.13453.39592.idtracker@ietfa.amsl.com> Date: Sat, 13 Jul 2013 10:47:30 -0400 Message-ID: From: Rifaat Shekh-Yusef To: "http-auth@ietf.org" Content-Type: multipart/alternative; boundary=047d7b621c72f30a1704e165b4b1 Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-update-04.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 14:47:32 -0000 --047d7b621c72f30a1704e165b4b1 Content-Type: text/plain; charset=ISO-8859-1 Hi, I have just submitted version 4 that fixed a reference to a FIPS document, added a reference to SHA2-512/256, corrected the algorithm in the example, and added a note in section 3.4 around the level of support for the SHA2-512/256 algorithm. I would appreciate any feedback on this version of the draft. Regards, Rifaat On Sat, Jul 13, 2013 at 10:39 AM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Hypertext Transfer Protocol > Authentication Working Group of the IETF. > > Title : HTTP Digest Update > Author(s) : Rifaat Shekh-Yusef > David Ahrens > Filename : draft-ietf-httpauth-digest-update-04.txt > Pages : 10 > Date : 2013-07-13 > > Abstract: > This documents specifies extensions to the HTTP Digest Authentication > mechanism to add support for new digest algorithms to the HTTP Digest > Access Authentication scheme. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest-update > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-httpauth-digest-update-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-digest-update-04 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > --047d7b621c72f30a1704e165b4b1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I have just submitted version 4 tha= t fixed a reference to a FIPS document, added a reference to SHA2-512/256, = corrected the algorithm in the example, and added a note in section=A03.4 around the level of su= pport for the SHA2-512/256 algorithm.
I would appreciate any feedback on this version of the draft.

Regards,
=A0Rifaat


On Sat, Jul 13, 2013 at 10:39 A= M, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0This draft is a work item of the Hypertext Transfer Protocol Authenticat= ion Working Group of the IETF.

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : HTTP Digest Update
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Rifaat Shekh-Yusef
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 David Ahrens
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-httpauth-digest-update= -04.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 10
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-07-13

Abstract:
=A0 =A0This documents specifies extensions to the HTTP Digest Authenticatio= n
=A0 =A0mechanism to add support for new digest algorithms to the HTTP Diges= t
=A0 =A0Access Authentication scheme.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-httpauth-= digest-update

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-httpauth-digest-up= date-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ht= tpauth-digest-update-04


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

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

--047d7b621c72f30a1704e165b4b1-- From yaronf.ietf@gmail.com Sat Jul 13 12:31:22 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B98F821F8EDF for ; Sat, 13 Jul 2013 12:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id krZotss7yTIj for ; Sat, 13 Jul 2013 12:31:22 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id CF3E421F8ECE for ; Sat, 13 Jul 2013 12:31:21 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id c10so1697729wiw.13 for ; Sat, 13 Jul 2013 12:31:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=2EqJhhZrrpiE0znagUycYe6Ij5CQNFo8LnmS45PZDaw=; b=DQJ8fAErVYY/lisIkR41ealFifg2N5P0Z5GRsqClBxLBAwZtHMtooZOXTbspY1M3uA efbfhbqgGYNYnHMJGn0cDAUQCfm7Sz5tvfK9YB+9zJX4c2CjpkYpqx82cS8jxFggTzt4 6mxOZ10n0dxgBRQ60ztj8v3vmIJQvnjov/RTTThYjGW7G3JjJgY21sPJawK170nLGBYz WBqVBagZGTG3uuQewaeneXoqSACZWwtWUuFkZYg5q78dNmShyE6HKpFlaCbD01QHBWpw tNQtUXWXM6HqDIDn5fRAAj+8hcx7bZybP08cdgPTU0sJiTXSACriZPbm5lKuex9unqpS qJ3g== X-Received: by 10.194.174.38 with SMTP id bp6mr28156784wjc.83.1373743875122; Sat, 13 Jul 2013 12:31:15 -0700 (PDT) Received: from [10.0.0.7] (bzq-79-176-209-118.red.bezeqint.net. [79.176.209.118]) by mx.google.com with ESMTPSA id fd3sm10558728wic.10.2013.07.13.12.31.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 13 Jul 2013 12:31:14 -0700 (PDT) Message-ID: <51E1AAFE.4080909@gmail.com> Date: Sat, 13 Jul 2013 22:31:10 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Rifaat Shekh-Yusef References: <20130713143948.13453.39592.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-update-04.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 19:31:22 -0000 Hi Rifaat, thanks for the update! "NOTE: There is some concern around the support for the SHA2-512/256 algorithm in the common implementation of SHA2." I have looked at OpenSSL (the code tree) and GnuTLS (documentation), and unless I'm missing something, neither of them implements SHA2-512/256. If this is indeed the case, then this algorithm is not a good choice. Thanks, Yaron On 2013-07-13 17:47, Rifaat Shekh-Yusef wrote: > Hi, > > I have just submitted version 4 that fixed a reference to a FIPS > document, added a reference to SHA2-512/256, corrected the algorithm in > the example, and added a note in section 3.4 around the level of support > for the SHA2-512/256 algorithm. > I would appreciate any feedback on this version of the draft. > > Regards, > Rifaat > > > On Sat, Jul 13, 2013 at 10:39 AM, > wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Hypertext Transfer Protocol > Authentication Working Group of the IETF. > > Title : HTTP Digest Update > Author(s) : Rifaat Shekh-Yusef > David Ahrens > Filename : draft-ietf-httpauth-digest-update-04.txt > Pages : 10 > Date : 2013-07-13 > > Abstract: > This documents specifies extensions to the HTTP Digest > Authentication > mechanism to add support for new digest algorithms to the HTTP > Digest > Access Authentication scheme. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest-update > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-httpauth-digest-update-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-digest-update-04 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > > > > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > From rifaat.ietf@gmail.com Sat Jul 13 18:53:57 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B56D21F9C88 for ; Sat, 13 Jul 2013 18:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.766, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBgp7G5uYVjO for ; Sat, 13 Jul 2013 18:53:56 -0700 (PDT) Received: from mail-qe0-x234.google.com (mail-qe0-x234.google.com [IPv6:2607:f8b0:400d:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 1E6E721F9C68 for ; Sat, 13 Jul 2013 18:53:56 -0700 (PDT) Received: by mail-qe0-f52.google.com with SMTP id i11so5778377qej.25 for ; Sat, 13 Jul 2013 18:53:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Y1UdhXVT9xLU3wj8IWJ9yWebw83f/ytHX7qR+eSsyUU=; b=sAMSi9Psvyolxb8DLiwDQVcMCCsqxWUvWq9GHdJrKdi2Q+GhMdxjWX6Xruh4VTwoxC mvDnvtYtQIqzsbK/g7V4dGfWAXTN6EdQPG1oSKB78zGPPtXM985MdDAyCTkYp+rXS+UM u3zPweQcRBQHqhhhqqs+Xp6xw5WUuMvFwv+AiiZn8PCtjXGpUoOsAXuVlqQqqaOhoJne o8zj7OC3OR4E9A5PqZUQuyD4WGjvlQ8R2+72BybopFKno4LILGQFNQGckoZSqJ8HhFSK 7Z1vvpIzipMh/1H2SIT8FnUJXuGj3kS5paCO4NU6lsoBCrbkxT4fblMCNos2jNrRu7UZ qtbQ== MIME-Version: 1.0 X-Received: by 10.224.52.1 with SMTP id f1mr146227qag.77.1373766835507; Sat, 13 Jul 2013 18:53:55 -0700 (PDT) Received: by 10.49.39.201 with HTTP; Sat, 13 Jul 2013 18:53:55 -0700 (PDT) In-Reply-To: <51E1AAFE.4080909@gmail.com> References: <20130713143948.13453.39592.idtracker@ietfa.amsl.com> <51E1AAFE.4080909@gmail.com> Date: Sat, 13 Jul 2013 21:53:55 -0400 Message-ID: From: Rifaat Shekh-Yusef To: Yaron Sheffer Content-Type: multipart/alternative; boundary=001a11c2aa783c185b04e16f0403 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-update-04.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 01:53:57 -0000 --001a11c2aa783c185b04e16f0403 Content-Type: text/plain; charset=ISO-8859-1 Thanks for looking into this Yaron, All, Should we then use SHA2-512 instead? Regards, Rifaat On Sat, Jul 13, 2013 at 3:31 PM, Yaron Sheffer wrote: > Hi Rifaat, > > thanks for the update! > > "NOTE: There is some concern around the support for the SHA2-512/256 > algorithm in the common implementation of SHA2." > > I have looked at OpenSSL (the code tree) and GnuTLS (documentation), and > unless I'm missing something, neither of them implements SHA2-512/256. If > this is indeed the case, then this algorithm is not a good choice. > > Thanks, > Yaron > > > On 2013-07-13 17:47, Rifaat Shekh-Yusef wrote: > >> Hi, >> >> I have just submitted version 4 that fixed a reference to a FIPS >> document, added a reference to SHA2-512/256, corrected the algorithm in >> the example, and added a note in section 3.4 around the level of support >> for the SHA2-512/256 algorithm. >> I would appreciate any feedback on this version of the draft. >> >> Regards, >> Rifaat >> >> >> On Sat, Jul 13, 2013 at 10:39 AM, > >> wrote: >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Hypertext Transfer Protocol >> Authentication Working Group of the IETF. >> >> Title : HTTP Digest Update >> Author(s) : Rifaat Shekh-Yusef >> David Ahrens >> Filename : draft-ietf-httpauth-digest-**update-04.txt >> Pages : 10 >> Date : 2013-07-13 >> >> Abstract: >> This documents specifies extensions to the HTTP Digest >> Authentication >> mechanism to add support for new digest algorithms to the HTTP >> Digest >> Access Authentication scheme. >> >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/**doc/draft-ietf-httpauth-** >> digest-update >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/**draft-ietf-httpauth-digest-**update-04 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?**url2=draft-ietf-httpauth-** >> digest-update-04 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-**drafts/ >> >> ______________________________**_________________ >> http-auth mailing list >> http-auth@ietf.org >> https://www.ietf.org/mailman/**listinfo/http-auth >> >> >> >> >> >> ______________________________**_________________ >> http-auth mailing list >> http-auth@ietf.org >> https://www.ietf.org/mailman/**listinfo/http-auth >> >> --001a11c2aa783c185b04e16f0403 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks for looking into this Yaron,

All,

Should we then use SHA2-512 inste= ad?

Regards,
=A0Rifaat






On Sat, Jul 13,= 2013 at 3:31 PM, Yaron Sheffer <yaronf.ietf@gmail.com> = wrote:
Hi Rifaat,

thanks for the update!

"NOTE: There is some concern around the support for the SHA2-512/256 a= lgorithm in the common implementation of SHA2."

I have looked at OpenSSL (the code tree) and GnuTLS (documentation), and un= less I'm missing something, neither of them implements SHA2-512/256. If= this is indeed the case, then this algorithm is not a good choice.

Thanks,
=A0 =A0 =A0 =A0 Yaron


On 2013-07-13 17:47, Rifaat Shekh-Yusef wrote:
Hi,

I have just submitted version 4 that fixed a reference to a FIPS
document, added a reference to SHA2-512/256, corrected the algorithm in
the example, and added a note in section 3.4 around the level of support for the SHA2-512/256 algorithm.
I would appreciate any feedback on this version of the draft.

Regards,
=A0 Rifaat


On Sat, Jul 13, 2013 at 10:39 AM, <internet-drafts@ietf.org
<mailto:in= ternet-drafts@ietf.org>> wrote:


=A0 =A0 A New Internet-Draft is available from the on-line Internet-Drafts<= br> =A0 =A0 directories.
=A0 =A0 =A0 This draft is a work item of the Hypertext Transfer Protocol =A0 =A0 Authentication Working Group of the IETF.

=A0 =A0 =A0 =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : HTTP Digest Update =A0 =A0 =A0 =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Rifaat Shekh-Yusef
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0David Ahrens=
=A0 =A0 =A0 =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-httpauth-di= gest-update-04.txt
=A0 =A0 =A0 =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 10
=A0 =A0 =A0 =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-07-13

=A0 =A0 Abstract:
=A0 =A0 =A0 =A0 This documents specifies extensions to the HTTP Digest
=A0 =A0 Authentication
=A0 =A0 =A0 =A0 mechanism to add support for new digest algorithms to the H= TTP
=A0 =A0 Digest
=A0 =A0 =A0 =A0 Access Authentication scheme.



=A0 =A0 The IETF datatracker status page for this draft is:
=A0 =A0 https://datatracker.ietf.org/doc/draft= -ietf-httpauth-digest-update

=A0 =A0 There's also a htmlized version available at:
=A0 =A0 http://tools.ietf.org/html/draft-ietf-htt= pauth-digest-update-04

=A0 =A0 A diff from the previous version is available at:
=A0 =A0 http://www.ietf.org/rfcdiff?url2= =3Ddraft-ietf-httpauth-digest-update-04


=A0 =A0 Internet-Drafts are also available by anonymous FTP at:
=A0 =A0 f= tp://ftp.ietf.org/internet-drafts/

=A0 =A0 _______________________________________________
=A0 =A0 http-auth mailing list
=A0 =A0 http-auth@i= etf.org <mailto:http-auth@ietf.org>
=A0 =A0 https://www.ietf.org/mailman/listinfo/http-auth





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


--001a11c2aa783c185b04e16f0403-- From ynir@checkpoint.com Mon Jul 15 07:21:41 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A84421E80AD for ; Mon, 15 Jul 2013 07:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.516 X-Spam-Level: X-Spam-Status: No, score=-10.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cshc-q7S1SkV for ; Mon, 15 Jul 2013 07:21:31 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id B0E6121E8097 for ; Mon, 15 Jul 2013 07:21:22 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r6FELLf4006723 for ; Mon, 15 Jul 2013 17:21:21 +0300 X-CheckPoint: {51E40561-18-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.48]) by IL-EX10.ad.checkpoint.com ([169.254.2.91]) with mapi id 14.02.0342.003; Mon, 15 Jul 2013 17:21:21 +0300 From: Yoav Nir To: "http-auth@ietf.org" Thread-Topic: HTTP-Auth meeting in Berlin Thread-Index: AQHOgWaTRAxP780d/0SlS5YRJiImtw== Date: Mon, 15 Jul 2013 14:21:21 +0000 Message-ID: <1A065528-D927-4FDF-B9EE-FE5FDA5436B4@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [91.90.139.159] x-kse-antivirus-interceptor-info: protection disabled x-cpdlp: 11994947903e5424cc9405d3e807d12e3a4282534f Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [http-auth] HTTP-Auth meeting in Berlin X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 14:21:41 -0000 Hi all The HTTP-Auth working group will meet on Wednesday, July 31st, at 13:00, fo= r two hours in the Postdam 2 room. An audio stream will be available at http://ietf87streaming.dnsalias.net/ie= tf/ietf875.m3u A jabber room will be available at xmpp:httpauth@jabber.ietf.org?join If anyone would like to volunteer to take minutes or to channel the jabber = room, please contact Matt or me directly. Thanks in advance. We haven't finalized the agenda, but we intend to spend about half the time= on the Basic and Digest drafts, and the rest on the new schemes. If you ha= ve any other items you would like to raise, please contact Matt and me ASAP= . Looking forward to seeing you all in just over two weeks. Matt and Yoav From internet-drafts@ietf.org Mon Jul 15 14:04:55 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2886121E8194; Mon, 15 Jul 2013 14:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sIH3jiALQ0Z8; Mon, 15 Jul 2013 14:04:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A106A21E818C; Mon, 15 Jul 2013 14:04:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130715210454.4387.51895.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 14:04:54 -0700 Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-hoba-01.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 21:04:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Hypertext Transfer Protocol Authenticatio= n Working Group of the IETF. Title : HTTP Origin-Bound Authentication (HOBA) Author(s) : Stephen Farrell Paul Hoffman Michael Thomas Filename : draft-ietf-httpauth-hoba-01.txt Pages : 26 Date : 2013-07-15 Abstract: HTTP Origin-Bound Authentication (HOBA) is a design for an HTTP authentication method with credentials that are not vulnerable to phishing attacks, and that does not require a server-side password database. The design can also be used in Javascript-based authentication embedded in HTML. HOBA is an alternative to HTTP authentication schemes that require passwords with all the negative attributes that come with password-based systems. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-httpauth-hoba-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-httpauth-hoba-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From stephen.farrell@cs.tcd.ie Mon Jul 15 14:10:41 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2944711E819A for ; Mon, 15 Jul 2013 14:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bpBSnzs0-45Q for ; Mon, 15 Jul 2013 14:10:36 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 64E8611E8122 for ; Mon, 15 Jul 2013 14:10:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D4737BE88 for ; Mon, 15 Jul 2013 22:10:12 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFmdm9iscBiY for ; Mon, 15 Jul 2013 22:10:07 +0100 (IST) Received: from [10.87.48.9] (unknown [86.41.50.56]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 08CA4BE7D for ; Mon, 15 Jul 2013 22:10:07 +0100 (IST) Message-ID: <51E4652E.2090301@cs.tcd.ie> Date: Mon, 15 Jul 2013 22:10:06 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: http-auth@ietf.org References: <20130715210454.4387.51895.idtracker@ietfa.amsl.com> In-Reply-To: <20130715210454.4387.51895.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-hoba-01.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 21:10:41 -0000 Just a few minor updates here mostly based on implementation work we've been doing. One of us'll be happy to present the changes and open issues in Berlin. Optimistically, I'd say we're shooting for a WGLC for -02 ish since that implementation seems to indicate that this all just works as expected (or better IMO:-) S. On 07/15/2013 10:04 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Hypertext Transfer Protocol Authentication Working Group of the IETF. > > Title : HTTP Origin-Bound Authentication (HOBA) > Author(s) : Stephen Farrell > Paul Hoffman > Michael Thomas > Filename : draft-ietf-httpauth-hoba-01.txt > Pages : 26 > Date : 2013-07-15 > > Abstract: > HTTP Origin-Bound Authentication (HOBA) is a design for an HTTP > authentication method with credentials that are not vulnerable to > phishing attacks, and that does not require a server-side password > database. The design can also be used in Javascript-based > authentication embedded in HTML. HOBA is an alternative to HTTP > authentication schemes that require passwords with all the negative > attributes that come with password-based systems. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-httpauth-hoba-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-hoba-01 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > > From msweet@apple.com Tue Jul 16 07:35:20 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77D0D11E80ED for ; Tue, 16 Jul 2013 07:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.982 X-Spam-Level: X-Spam-Status: No, score=-8.982 tagged_above=-999 required=5 tests=[AWL=1.617, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DzADX9yVGV-l for ; Tue, 16 Jul 2013 07:35:13 -0700 (PDT) Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id EE07A11E80DC for ; Tue, 16 Jul 2013 07:35:13 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay2.apple.com ([17.128.113.67]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MQ100A3X9U3QZ50@mail-out.apple.com> for http-auth@ietf.org; Tue, 16 Jul 2013 07:34:57 -0700 (PDT) X-AuditID: 11807143-b7fe56d000007efd-a4-51e55a0eeb8a Received: from [17.153.63.207] (Unknown_Domain [17.153.63.207]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay2.apple.com (Apple SCV relay) with SMTP id 27.00.32509.01A55E15; Tue, 16 Jul 2013 07:34:57 -0700 (PDT) From: Michael Sweet In-reply-to: <51E4652E.2090301@cs.tcd.ie> Date: Tue, 16 Jul 2013 10:34:54 -0400 Message-id: References: <20130715210454.4387.51895.idtracker@ietfa.amsl.com> <51E4652E.2090301@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1784.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDLMWRmVeSWpSXmKPExsUiONP+vK5g1NNAgyttchYf9s9hsjjyLdZi +t5r7A7MHltP/mDzWNt9lc1jyZKfTAHMUVw2Kak5mWWpRfp2CVwZR7feZCx4KloxdfJj9gbG LYJdjJwcEgImEusf9jFC2GISF+6tZ+ti5OIQEuhlknjY8oYFJCEsYCCxdfIbNhCbF8hefvga K4jNLKAlcePfSyYQm01ATeL3pD6wOKeApsSmhi9gcRYBVYlN7w8zQdSLSXQ8vMQGYWtLLFv4 mhlipo3E3EOfwWqEBGIlPqzaCBYXEdCX2Lv5HDvEcfISnQ2vWScw8s9CcsYsJGfMQjJ2ASPz KkaBotScxEojvcSCgpxUveT83E2MoDBsKHTewXhsmdUhRgEORiUe3glhTwOFWBPLiitzDzFK cDArifBOCQQK8aYkVlalFuXHF5XmpBYfYpTmYFES540ofxAoJJCeWJKanZpakFoEk2Xi4JRq YJz2vLdAvMjz5fxSd0Pxfawt79KMw6f5LMv0+f7l5/nmyTpidzdOb36x6Oskg5Y/h+Sasjmi 0wyjRZbVrZt+RujavfopglsWlBp5f3pzjfX6qg5TjmJlkXBTuz9tH1ybDc88t2wufencF76c WXyiDWfIJ6FKmTdy6b/eqTSF5byQbr606rlGpRJLcUaioRZzUXEiAMWbomg/AgAA Cc: http-auth@ietf.org Subject: [http-auth] Comments on draft-ietf-httpauth-hoba-01 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 14:35:20 -0000 All, Some (mostly editorial) comments on draft-ietf-httpauth-hoba-01: - Can we drop the "with all the negative attributes that come with password-based systems" from the end of the abstract? I don't think it adds anything to the description and might turn some people off from reading the rest of the (otherwise excellent) document. - Section 1 - I don't think we need "If deployment of HOBA reduces the number of password entries in databases by any appreciable amount, then it would be worthwhile." - Reword: "As an HTTP authentication scheme, it WORKS in the current HTTP 1.0 and HTTP 1.1 authentication framework.", and don't talk about HTTP/2.0 unless there is something definitive to say. - Typo: "... using the same credentials that are USED by ..." - "The HTTP /Authentication/ specification [RFC2617] ..." - the HTTP spec doesn't define Basic and Digest, the separate Auth spec does... - The last sentence "Even though few large web sites" is a bit confusing; maybe something like "While few large web sites use Basic or Digest authentication, they still use authentication schemes based on server-side usernames and passwords." - Section 3 - Can we add something here as a reminder that HOBA might be one of several listed (comma-delimited) mechanisms in the WWW-Authenticate header? - In a similar vein, I would love to see some more discussion of implementation/fallback strategies. Right now I see a lot of potential uses for this authentication scheme, but I could not deploy it widely/exclusively (e.g. for CUPS and in printers) until HOBA support was in all of the major browsers and print clients. - Section 4.2: - Status 403 is "Forbidden". Status 401 is "Unauthorized". Which is intended here? - Section 6.1 - Here I think we need more discussion of what the UA and server do. From reading this section it sounds like the UA would redirect to the well-known URL to perform registration, but I don't see how the UA knows that registration was successful and the original request can be retried. - In 4.x and 5.x you mention some possible ways the server can verify a user's identity (for which I might also include PIN verification on a printer), but you don't say anything about that here. - Section 12.1 - Add reference to RFC 2616, which defines HTTP and the auth headers - Move RFC 2617 here, which defines the general format of auth headers - Section 12.2 - Remove RFC 2617 (now in 12.1) - Add references to httpbis drafts made throughout document - Add references to example code/implementations? _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair From stephen.farrell@cs.tcd.ie Tue Jul 16 11:53:51 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D533821E8054 for ; Tue, 16 Jul 2013 11:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ySNUuxXhXdMw for ; Tue, 16 Jul 2013 11:53:31 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id C905621F99A8 for ; Tue, 16 Jul 2013 11:53:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 83885BE64; Tue, 16 Jul 2013 19:53:07 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5CN9OIqMs9VV; Tue, 16 Jul 2013 19:53:05 +0100 (IST) Received: from [10.87.48.9] (unknown [86.46.19.29]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5F11BBE38; Tue, 16 Jul 2013 19:53:05 +0100 (IST) Message-ID: <51E59686.70501@cs.tcd.ie> Date: Tue, 16 Jul 2013 19:52:54 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Michael Sweet References: <20130715210454.4387.51895.idtracker@ietfa.amsl.com> <51E4652E.2090301@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: http-auth@ietf.org Subject: Re: [http-auth] Comments on draft-ietf-httpauth-hoba-01 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 18:53:51 -0000 Hi Michael, Thanks for the review. Comments below. I've put a version at [1] with the changes indicated below in case that helps. Note that I've not confirmed that with Paul and Mike, so we might need to revert some changes if I;ve messed up:-) On 07/16/2013 03:34 PM, Michael Sweet wrote: > All, > > Some (mostly editorial) comments on draft-ietf-httpauth-hoba-01: > > - Can we drop the "with all the negative attributes that come with password-based systems" from the end of the abstract? I don't think it adds anything to the description and might turn some people off from reading the rest of the (otherwise excellent) document. Fair enough. I guess we can assume that readers know all the many downsides of passwords, but yeah that probably doesn't belong there. > - Section 1 > - I don't think we need "If deployment of HOBA reduces the number of password entries in databases by any appreciable amount, then it would be worthwhile." I've rephrased that to: "Deployment of HOBA can reduce the number of, or eliminate password entries in databases, with potentially significant security benefits." > - Reword: "As an HTTP authentication scheme, it WORKS in the current HTTP 1.0 and HTTP 1.1 authentication framework.", and don't talk about HTTP/2.0 unless there is something definitive to say. > - Typo: "... using the same credentials that are USED by ..." > - "The HTTP /Authentication/ specification [RFC2617] ..." - the HTTP spec doesn't define Basic and Digest, the separate Auth spec does... > - The last sentence "Even though few large web sites" is a bit confusing; maybe something like "While few large web sites use Basic or Digest authentication, they still use authentication schemes based on server-side usernames and passwords." Yeah that was clunky text;-) I've tried to fix it along the lines you suggest. See what ya think. > > - Section 3 > - Can we add something here as a reminder that HOBA might be one of several listed (comma-delimited) mechanisms in the WWW-Authenticate header? Good point. Added: "Note that the HOBA auth-scheme might not be the only one that the server includes in a WWW-Authenticate." > - In a similar vein, I would love to see some more discussion of implementation/fallback strategies. Right now I see a lot of potential uses for this authentication scheme, but I could not deploy it widely/exclusively (e.g. for CUPS and in printers) until HOBA support was in all of the major browsers and print clients. I guess that's non editorial:-) To date we've not seen browser interest but I do hope that might change in future. If it helps, you can implement HOBA-HTTP in JS also (my code does that) and even though that's low assurance (as it depends on localStorage until we get webcrypto) and is a bit clunky, ('cause it needs XHR) I hope it'll provide a way to use this without having to get all (or any) browsers on board. I'll be able to say more on that after I get my code released, so would suggest we come back to this as we build some experience. Sound ok? > - Section 4.2: > - Status 403 is "Forbidden". Status 401 is "Unauthorized". Which is intended here? Sorry - should be 403 Forbidden there I guess. Good catch. > > - Section 6.1 > - Here I think we need more discussion of what the UA and server do. From reading this section it sounds like the UA would redirect to the well-known URL to perform registration, but I don't see how the UA knows that registration was successful and the original request can be retried. What I've done is have the register kick off a signup process that's application driven and then next time the browser sees a HOBA 401 for that origin, it just tries HOBA. (If someone's interested in playing with that before I get the code released, just drop me a note. I hoped to have the code released before Berlin but time seems to be catching up with me;-) But I've not really done much of a signup process (I more-or-less just take any good looking public key and return 200 OK). I guess there could be issues if the user abandons the signup half way through though. Maybe we need a /.well-known/hoba/regconfirm or something - do you think having that signal the end of register work ok? > - In 4.x and 5.x you mention some possible ways the server can verify a user's identity (for which I might also include PIN verification on a printer), but you don't say anything about that here. Fair point. I'm gonna leave that for now though - we've planned to figure out (but haven't yet) how to merge the HOBA-JS stuff with the rest. So this sounds like a bit of text that we should look at then. Sound ok? > - Section 12.1 > - Add reference to RFC 2616, which defines HTTP and the auth headers > - Move RFC 2617 here, which defines the general format of auth headers > > - Section 12.2 > - Remove RFC 2617 (now in 12.1) > - Add references to httpbis drafts made throughout document Done. > - Add references to example code/implementations? Will be added to section 10 as per draft-sheffer-running-code as we go. (I figured there was no point in details until my code was released;-) Thanks again, S. [1] http://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-02-pre.txt > > _________________________________________________________ > Michael Sweet, Senior Printing System Engineer, PWG Chair > > > From msweet@apple.com Wed Jul 17 05:34:21 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2905D21F9F00 for ; Wed, 17 Jul 2013 05:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.028 X-Spam-Level: X-Spam-Status: No, score=-9.028 tagged_above=-999 required=5 tests=[AWL=1.571, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8czP0iEL03Or for ; Wed, 17 Jul 2013 05:34:14 -0700 (PDT) Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id B67A521F9FD1 for ; Wed, 17 Jul 2013 05:34:14 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay5.apple.com ([17.128.113.88]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MQ2009N0YW9Z3P0@mail-out.apple.com> for http-auth@ietf.org; Wed, 17 Jul 2013 05:33:46 -0700 (PDT) X-AuditID: 11807158-b7f4d6d0000074f5-c5-51e68f298544 Received: from [17.153.44.207] (Unknown_Domain [17.153.44.207]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id B3.2E.29941.92F86E15; Wed, 17 Jul 2013 05:33:46 -0700 (PDT) From: Michael Sweet In-reply-to: <51E59686.70501@cs.tcd.ie> Date: Wed, 17 Jul 2013 08:33:46 -0400 Message-id: References: <20130715210454.4387.51895.idtracker@ietfa.amsl.com> <51E4652E.2090301@cs.tcd.ie> <51E59686.70501@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1508) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDLMWRmVeSWpSXmKPExsUiOFPnvK5W/7NAg8YZUhYf9s9hsjjyLdZi +t5r7A7MHltP/mDzWNt9lc1jyZKfTAHMUVw2Kak5mWWpRfp2CVwZEzf3MRVsU6lonniJsYHx s3QXIyeHhICJxJd515ggbDGJC/fWs3UxcnEICfQySfyd+ZsVJCEMVLTj4HR2EJtXQE9i6b85 jCA2s4COxM6td9hAbDYBNYnfk/rA6jkF1CV2z1gOFmcRUJW4/eoVVL2YRMfDS2wQtrbEsoWv mSFm2kicmrGGGWLxSkaJKb+2gi0TEdCX2Lv5HJDNAXSdrMTO30kTGPlnITljFpIzZiEZu4CR eRWjQFFqTmKlqV5iQUFOql5yfu4mRlAYNhRG7GD8v8zqEKMAB6MSD++EsKeBQqyJZcWVuYcY JTiYlUR4rzU/CxTiTUmsrEotyo8vKs1JLT7EKM3BoiTOG1n+IFBIID2xJDU7NbUgtQgmy8TB KdXAeCri/d1bU+QUZ5my7vk+Nd1ONXbh2jfnH51w27SrYOeOJZNdeM2ObDZ8XHk2wkUlw7/g h3HrtCUdFlL5jcHLdlnrnNkqfn2O95c7jh68OV/mGzE992Sc7/33St76f6arLlYIfrvitOvY jGNJ34R0vi69Mufwzpa1bRfsrpt437t556nR9xf+jOlKLMUZiYZazEXFiQDME5lgPwIAAA== Cc: http-auth@ietf.org Subject: Re: [http-auth] Comments on draft-ietf-httpauth-hoba-01 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 12:34:21 -0000 Stephen, I like the changes you've made. Some responses inline below... On 2013-07-16, at 2:52 PM, Stephen Farrell wrote: > ... >> - In a similar vein, I would love to see some more discussion of implementation/fallback strategies. Right now I see a lot of potential uses for this authentication scheme, but I could not deploy it widely/exclusively (e.g. for CUPS and in printers) until HOBA support was in all of the major browsers and print clients. > > I guess that's non editorial:-) To date we've not seen browser > interest but I do hope that might change in future. If it helps, > you can implement HOBA-HTTP in JS also (my code does that) and > even though that's low assurance (as it depends on localStorage > until we get webcrypto) and is a bit clunky, ('cause it needs > XHR) I hope it'll provide a way to use this without having to > get all (or any) browsers on board. I'll be able to say more on > that after I get my code released, so would suggest we come > back to this as we build some experience. Sound ok? Sure, sounds like a plan. >> ... >> - Section 6.1 >> - Here I think we need more discussion of what the UA and server do. From reading this section it sounds like the UA would redirect to the well-known URL to perform registration, but I don't see how the UA knows that registration was successful and the original request can be retried. > > What I've done is have the register kick off a signup process > that's application driven and then next time the browser sees > a HOBA 401 for that origin, it just tries HOBA. (If someone's > interested in playing with that before I get the code released, > just drop me a note. I hoped to have the code released before > Berlin but time seems to be catching up with me;-) > > But I've not really done much of a signup process (I more-or-less > just take any good looking public key and return 200 OK). I guess > there could be issues if the user abandons the signup half way > through though. Maybe we need a /.well-known/hoba/regconfirm or > something - do you think having that signal the end of register > work ok? I'm thinking you might instead want to add a HTTP response header ("HOBA-Registration: state"?) to any registration pages. The sequence for a confirmation form might look like the following: POST /.well-known/hoba/registration HTTP/1.1 ... initial form data ... HTTP/1.1 200 OK ... HOBA-Registration: in-progress ... Web form asking for more information, PIN, etc. POST /.well-known/hoba/registration HTTP/1.1 ... subsequent form data ... HTTP/1.1 200 OK ... HOBA-Registration: complete ... "Success" page For a failed registration the sequence might look like: POST /.well-known/hoba/registration HTTP/1.1 ... initial form data ... HTTP/1.1 200 OK ... HOBA-Registration: in-progress ... Web form asking for more information, PIN, etc. POST /.well-known/hoba/registration HTTP/1.1 ... subsequent form data ... HTTP/1.1 200 OK ... HOBA-Registration: failed reason="Some reason" ... "Failure" page Obviously there could be multiple web forms shown or none at all (initial response to POST is HOBA-Registration complete or failed). The new response header would allow a common UA to participate without requiring site-specific Javascript or other hacks, and HTTP-based service applications can display an embedded web page viewer to display the registration page(s). I'd avoid returning a different status code (e.g. 401 or 403) for these since UAs don't always show the web content attached to such responses. (I also thought about defining standard verification fields that could be requested, but I think that is overkill and would limit the possible uses of HOBA) >> - In 4.x and 5.x you mention some possible ways the server can verify a user's identity (for which I might also include PIN verification on a printer), but you don't say anything about that here. > > Fair point. I'm gonna leave that for now though - we've planned > to figure out (but haven't yet) how to merge the HOBA-JS stuff > with the rest. So this sounds like a bit of text that we should > look at then. Sound ok? OK, I'll keep an eye out for changes... _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair From julian.reschke@gmx.de Wed Jul 17 05:56:50 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 992AC21F999E for ; Wed, 17 Jul 2013 05:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-4.300, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oqFpL3xDcn7s for ; Wed, 17 Jul 2013 05:56:44 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 8DFB121F99C2 for ; Wed, 17 Jul 2013 05:56:44 -0700 (PDT) Received: from [192.168.1.104] ([217.91.35.233]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LgI0W-1UKcIe02dw-00ndNs; Wed, 17 Jul 2013 14:56:40 +0200 Message-ID: <51E69487.8030103@gmx.de> Date: Wed, 17 Jul 2013 14:56:39 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Stephen Farrell References: <20130715210454.4387.51895.idtracker@ietfa.amsl.com> <51E4652E.2090301@cs.tcd.ie> <51E59686.70501@cs.tcd.ie> In-Reply-To: <51E59686.70501@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:cEBJ56xiSMtKgb7cmSwGxXHHcBSQ+DMlr45FBKIwf+kXy5qumE+ Wc7sK+FzK2fizvyDKCzPpXdKpdPuO9irVkTcxxJy9BVsag4b70Se6YthB1OPvhL7x26D8H/ yJ8BaN8KB5uqrob9GBPXdOkteBt8c/Gl4fQbbkkNGToSmSS9fXTXCq+8Qc6lkQDD2chMoZL Zq1AdTgtFhyLnoMHiM/yA== Cc: http-auth@ietf.org Subject: Re: [http-auth] Comments on draft-ietf-httpauth-hoba-01 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 12:56:50 -0000 On 2013-07-16 20:52, Stephen Farrell wrote: > > Hi Michael, > > Thanks for the review. Comments below. > > I've put a version at [1] with the changes indicated below in > case that helps. Note that I've not confirmed that with Paul > and Mike, so we might need to revert some changes if I;ve > messed up:-) > > On 07/16/2013 03:34 PM, Michael Sweet wrote: >> All, >> >> Some (mostly editorial) comments on draft-ietf-httpauth-hoba-01: >> >> - Can we drop the "with all the negative attributes that come with password-based systems" from the end of the abstract? I don't think it adds anything to the description and might turn some people off from reading the rest of the (otherwise excellent) document. > > Fair enough. I guess we can assume that readers know all the > many downsides of passwords, but yeah that probably doesn't > belong there. > >> - Section 1 >> - I don't think we need "If deployment of HOBA reduces the number of password entries in databases by any appreciable amount, then it would be worthwhile." > > I've rephrased that to: > > "Deployment of HOBA can reduce the number > of, or eliminate password entries in databases, with potentially > significant security benefits." > >> - Reword: "As an HTTP authentication scheme, it WORKS in the current HTTP 1.0 and HTTP 1.1 authentication framework.", and don't talk about HTTP/2.0 unless there is something definitive to say. >> - Typo: "... using the same credentials that are USED by ..." >> - "The HTTP /Authentication/ specification [RFC2617] ..." - the HTTP spec doesn't define Basic and Digest, the separate Auth spec does... >> - The last sentence "Even though few large web sites" is a bit confusing; maybe something like "While few large web sites use Basic or Digest authentication, they still use authentication schemes based on server-side usernames and passwords." > > Yeah that was clunky text;-) I've tried to fix it along the lines > you suggest. See what ya think. > ... draft-httpbis-p7 obsoletes the authentication framework bits from RFC 2617, so you really should have a normative reference to httpbis-p7 here. Best regards, Julian From msweet@apple.com Wed Jul 17 05:59:36 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E05721F99A4 for ; Wed, 17 Jul 2013 05:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.071 X-Spam-Level: X-Spam-Status: No, score=-9.071 tagged_above=-999 required=5 tests=[AWL=1.528, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ut4+1I8MbXsh for ; Wed, 17 Jul 2013 05:59:29 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id ED96621F99A0 for ; Wed, 17 Jul 2013 05:59:29 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay3.apple.com ([17.128.113.83]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MQ300A4T031B0U1@mail-out.apple.com> for http-auth@ietf.org; Wed, 17 Jul 2013 05:59:26 -0700 (PDT) X-AuditID: 11807153-b7fed6d0000060fa-ac-51e6952adeec Received: from [17.153.63.207] (Unknown_Domain [17.153.63.207]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay3.apple.com (Apple SCV relay) with SMTP id EE.22.24826.C2596E15; Wed, 17 Jul 2013 05:59:26 -0700 (PDT) From: Michael Sweet In-reply-to: <51E69487.8030103@gmx.de> Date: Wed, 17 Jul 2013 08:59:21 -0400 Message-id: References: <20130715210454.4387.51895.idtracker@ietfa.amsl.com> <51E4652E.2090301@cs.tcd.ie> <51E59686.70501@cs.tcd.ie> <51E69487.8030103@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1784.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUiONP+vK7e1GeBBjebOC0+7J/DZLH54RtW iyPfYi2m773G7sDisfXkDzaPtd1X2Tw+fIzzWLLkJ1MASxSXTUpqTmZZapG+XQJXxqqTW9kK frBUrF3UydrA2MLSxcjJISFgIjFtzRo2CFtM4sK99UA2F4eQQC+TxKJd+5lAEsICDhKvniwE s3kFDCSWH77GCmIzC+hI7Nx6B6yZTUBN4vekPrA4J5C9//Eb9i5GDg4WAVWJ/7OyIcpdJbZ+ WMwCYWtLLFv4mhlipI3EwrYfTBB7DzNKLL/VDzZTREBL4va9vYwQx8lLdDa8Zp3AyD8LyRmz kJwxC8ncBYzMqxgFilJzEiuN9RILCnJS9ZLzczcxggKzoTB4B+OfZVaHGAU4GJV4eF9EPA0U Yk0sK67MPcQowcGsJMJ7rflZoBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXHeiPIHgUIC6Yklqdmp qQWpRTBZJg5OqQZG7oXz57Nw5DfUqM2syG5f82x/oKBpyEXT8x1RhfV3/VZJJpls/7/k18Yp zxcprH63zDCx7VBLemt/gtKTz4FWVWf+cUYmiKwOTXqlbv9fNJdH6dTcpP1cz+WPKP9aITXr UEaVca7VbuEjDp5L/l7f8MXe5nbx/nb7tw9nXXGq8S1+Ojfr7mwnJZbijERDLeai4kQA2iYM v0gCAAA= Cc: http-auth@ietf.org Subject: Re: [http-auth] Comments on draft-ietf-httpauth-hoba-01 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 12:59:36 -0000 Julian, On Jul 17, 2013, at 8:56 AM, Julian Reschke wrote: > ... > draft-httpbis-p7 obsoletes the authentication framework bits from RFC 2617, so you really should have a normative reference to httpbis-p7 here. I guess that depends on the timeline for that spec; you can't make a normative reference to a draft, so doing that would hold up HOBA. OTOH, normatively referencing RFC 2617 will point people in the right direction when httpbis-p7 is published. _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair From julian.reschke@gmx.de Wed Jul 17 06:03:52 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A57B021F9C46 for ; Wed, 17 Jul 2013 06:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.985 X-Spam-Level: X-Spam-Status: No, score=-105.985 tagged_above=-999 required=5 tests=[AWL=-3.386, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jr0qgGnX61hI for ; Wed, 17 Jul 2013 06:03:46 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 934CF21F99C0 for ; Wed, 17 Jul 2013 06:03:46 -0700 (PDT) Received: from [192.168.1.104] ([217.91.35.233]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0M1W5x-1UB3pU25Jh-00tRZv; Wed, 17 Jul 2013 15:03:34 +0200 Message-ID: <51E69624.1070605@gmx.de> Date: Wed, 17 Jul 2013 15:03:32 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Michael Sweet References: <20130715210454.4387.51895.idtracker@ietfa.amsl.com> <51E4652E.2090301@cs.tcd.ie> <51E59686.70501@cs.tcd.ie> <51E69487.8030103@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:arkiPBGO/KkTnk6QffZDfBVFYdqtJB1BTrMSwaqgVqTGmVa0dpv KH4k0hBFN14uHS0iEGZhuw2sQDD2uoSt6L5osKRZ97rHZaeBa4wRL3rZR2C4V8JEZu+BQYQ FHIncd3YIUkKLnWHMu0XfT6r0TnEFM9eqaZ5ACYDD/mOYzFY4rS4CyxYiWqOwm5kFIgb+MJ wvBLpu/awY6LGQFqSdt7g== Cc: http-auth@ietf.org Subject: Re: [http-auth] Comments on draft-ietf-httpauth-hoba-01 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 13:03:52 -0000 On 2013-07-17 14:59, Michael Sweet wrote: > Julian, > > On Jul 17, 2013, at 8:56 AM, Julian Reschke wrote: >> ... >> draft-httpbis-p7 obsoletes the authentication framework bits from RFC 2617, so you really should have a normative reference to httpbis-p7 here. > > > I guess that depends on the timeline for that spec; you can't make a normative reference to a draft, so doing that would hold up HOBA. OTOH, normatively referencing RFC 2617 will point people in the right direction when httpbis-p7 is published. draft-httpbis-p7 is past WGLC, so in theory (yes, yes) it ought to be finished soon. In any case, the newly defined scheme needs to conform to everything what httpbis-p7 says (I believe it does, but I haven't checked lately). Best regards, Julian From stephen.farrell@cs.tcd.ie Wed Jul 17 06:45:37 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59EDE21F9EEB for ; Wed, 17 Jul 2013 06:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.389 X-Spam-Level: X-Spam-Status: No, score=-101.389 tagged_above=-999 required=5 tests=[AWL=-1.090, BAYES_00=-2.599, MANGLED_EMAIL=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6VbQmzBsCZS for ; Wed, 17 Jul 2013 06:45:32 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF6621F9E5C for ; Wed, 17 Jul 2013 06:45:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 08E72BEB6; Wed, 17 Jul 2013 14:45:09 +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 kLKRP7ms4FVa; Wed, 17 Jul 2013 14:45:08 +0100 (IST) Received: from [IPv6:2001:770:10:203:588a:ac19:318b:469b] (unknown [IPv6:2001:770:10:203:588a:ac19:318b:469b]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D72B9BE8A; Wed, 17 Jul 2013 14:45:08 +0100 (IST) Message-ID: <51E69FE4.7070506@cs.tcd.ie> Date: Wed, 17 Jul 2013 14:45:08 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Julian Reschke References: <20130715210454.4387.51895.idtracker@ietfa.amsl.com> <51E4652E.2090301@cs.tcd.ie> <51E59686.70501@cs.tcd.ie> <51E69487.8030103@gmx.de> <51E69624.1070605@gmx.de> In-Reply-To: <51E69624.1070605@gmx.de> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: http-auth@ietf.org Subject: Re: [http-auth] Comments on draft-ietf-httpauth-hoba-01 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 13:45:37 -0000 Hiya, On 07/17/2013 02:03 PM, Julian Reschke wrote: > On 2013-07-17 14:59, Michael Sweet wrote: >> Julian, >> >> On Jul 17, 2013, at 8:56 AM, Julian Reschke >> wrote: >>> ... >>> draft-httpbis-p7 obsoletes the authentication framework bits from RFC >>> 2617, so you really should have a normative reference to httpbis-p7 >>> here. >> >> >> I guess that depends on the timeline for that spec; you can't make a >> normative reference to a draft, so doing that would hold up HOBA. >> OTOH, normatively referencing RFC 2617 will point people in the right >> direction when httpbis-p7 is published. > > draft-httpbis-p7 is past WGLC, so in theory (yes, yes) it ought to be > finished soon. Fair 'nuff. OTOH, I thought the same for what turned into RFC6920:-) 6920 was much less related to p7 than hoba so it is more of a deal here. > In any case, the newly defined scheme needs to conform to everything > what httpbis-p7 says (I believe it does, but I haven't checked lately). I agree that we need to conform with that and also think we do (and if not we'll fix). I'd say for now let's see how the land lies when hoba gets to WGLC and beyond and then make sure that we have the right normative/informative refs. To be fair, it would be a totally reasonable IETF LC comment to say that hoba ought have draft-httpbis-p7 as a normative ref. It might be reasonable to weasel-word around that if everyone figured that'd stick hoba in the RFC editor queue for ever, but I hope that won't be the case. Anyway, I guess the same will apply for all the httpauth drafts so the httpauth wg will probably want to handle this the same for 'em all. So the first wg draft out the door will be the one that sorts this out probably. S. > > Best regards, Julian > > > From stephen.farrell@cs.tcd.ie Wed Jul 17 06:49:58 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C87921F9FE4 for ; Wed, 17 Jul 2013 06:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.357 X-Spam-Level: X-Spam-Status: No, score=-102.357 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bs3sxM7F0VLw for ; Wed, 17 Jul 2013 06:49:53 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id F346921F9AB3 for ; Wed, 17 Jul 2013 06:49:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5F002BEB6; Wed, 17 Jul 2013 14:49:31 +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 ZEIeJ+PX0WEj; Wed, 17 Jul 2013 14:49:31 +0100 (IST) Received: from [IPv6:2001:770:10:203:588a:ac19:318b:469b] (unknown [IPv6:2001:770:10:203:588a:ac19:318b:469b]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3B5C4BEE3; Wed, 17 Jul 2013 14:49:31 +0100 (IST) Message-ID: <51E6A0EA.7010203@cs.tcd.ie> Date: Wed, 17 Jul 2013 14:49:30 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Michael Sweet References: <20130715210454.4387.51895.idtracker@ietfa.amsl.com> <51E4652E.2090301@cs.tcd.ie> <51E59686.70501@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: http-auth@ietf.org Subject: Re: [http-auth] Comments on draft-ietf-httpauth-hoba-01 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 13:49:58 -0000 On 07/17/2013 01:33 PM, Michael Sweet wrote: > Stephen, > > I like the changes you've made. Some responses inline below... Great. On the registration thing I need to think about it a bit but what you suggest certainly doesn't sound crazy. So I'll get back to you on it when I've thought about coding it up. Anyone else got an opinion? (Nico - does your scheme have the same or similar issues?) S. > > > On 2013-07-16, at 2:52 PM, Stephen Farrell wrote: >> ... >>> - In a similar vein, I would love to see some more discussion of implementation/fallback strategies. Right now I see a lot of potential uses for this authentication scheme, but I could not deploy it widely/exclusively (e.g. for CUPS and in printers) until HOBA support was in all of the major browsers and print clients. >> >> I guess that's non editorial:-) To date we've not seen browser >> interest but I do hope that might change in future. If it helps, >> you can implement HOBA-HTTP in JS also (my code does that) and >> even though that's low assurance (as it depends on localStorage >> until we get webcrypto) and is a bit clunky, ('cause it needs >> XHR) I hope it'll provide a way to use this without having to >> get all (or any) browsers on board. I'll be able to say more on >> that after I get my code released, so would suggest we come >> back to this as we build some experience. Sound ok? > > Sure, sounds like a plan. > >>> ... >>> - Section 6.1 >>> - Here I think we need more discussion of what the UA and server do. From reading this section it sounds like the UA would redirect to the well-known URL to perform registration, but I don't see how the UA knows that registration was successful and the original request can be retried. >> >> What I've done is have the register kick off a signup process >> that's application driven and then next time the browser sees >> a HOBA 401 for that origin, it just tries HOBA. (If someone's >> interested in playing with that before I get the code released, >> just drop me a note. I hoped to have the code released before >> Berlin but time seems to be catching up with me;-) >> >> But I've not really done much of a signup process (I more-or-less >> just take any good looking public key and return 200 OK). I guess >> there could be issues if the user abandons the signup half way >> through though. Maybe we need a /.well-known/hoba/regconfirm or >> something - do you think having that signal the end of register >> work ok? > > I'm thinking you might instead want to add a HTTP response header ("HOBA-Registration: state"?) to any registration pages. The sequence for a confirmation form might look like the following: > > POST /.well-known/hoba/registration HTTP/1.1 > ... initial form data ... > > HTTP/1.1 200 OK > ... > HOBA-Registration: in-progress > ... > Web form asking for more information, PIN, etc. > > POST /.well-known/hoba/registration HTTP/1.1 > ... subsequent form data ... > > HTTP/1.1 200 OK > ... > HOBA-Registration: complete > ... > "Success" page > > > For a failed registration the sequence might look like: > > POST /.well-known/hoba/registration HTTP/1.1 > ... initial form data ... > > HTTP/1.1 200 OK > ... > HOBA-Registration: in-progress > ... > Web form asking for more information, PIN, etc. > > POST /.well-known/hoba/registration HTTP/1.1 > ... subsequent form data ... > > HTTP/1.1 200 OK > ... > HOBA-Registration: failed reason="Some reason" > ... > "Failure" page > > > Obviously there could be multiple web forms shown or none at all (initial response to POST is HOBA-Registration complete or failed). The new response header would allow a common UA to participate without requiring site-specific Javascript or other hacks, and HTTP-based service applications can display an embedded web page viewer to display the registration page(s). > > I'd avoid returning a different status code (e.g. 401 or 403) for these since UAs don't always show the web content attached to such responses. > > (I also thought about defining standard verification fields that could be requested, but I think that is overkill and would limit the possible uses of HOBA) > >>> - In 4.x and 5.x you mention some possible ways the server can verify a user's identity (for which I might also include PIN verification on a printer), but you don't say anything about that here. >> >> Fair point. I'm gonna leave that for now though - we've planned >> to figure out (but haven't yet) how to merge the HOBA-JS stuff >> with the rest. So this sounds like a bit of text that we should >> look at then. Sound ok? > > OK, I'll keep an eye out for changes... > > _________________________________________________________ > Michael Sweet, Senior Printing System Engineer, PWG Chair > > > From ynir@checkpoint.com Wed Jul 17 13:19:21 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15C0F11E80DC for ; Wed, 17 Jul 2013 13:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.562 X-Spam-Level: X-Spam-Status: No, score=-10.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZTuo6Rdwe7p for ; Wed, 17 Jul 2013 13:19:16 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 9B35F11E80AE for ; Wed, 17 Jul 2013 13:19:11 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r6HKJAUK026953 for ; Wed, 17 Jul 2013 23:19:10 +0300 X-CheckPoint: {51E6FC3E-0-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.48]) by IL-EX10.ad.checkpoint.com ([169.254.2.91]) with mapi id 14.02.0342.003; Wed, 17 Jul 2013 23:19:09 +0300 From: Yoav Nir To: "http-auth@ietf.org" Thread-Topic: Draft Agenda for Berlin Thread-Index: AQHOgyrkUU8Q1gMEikqnE3A+y479hA== Date: Wed, 17 Jul 2013 20:19:09 +0000 Message-ID: <36A66E35-C62E-44CA-8A76-E289C1B21FCA@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.46] x-kse-antivirus-interceptor-info: protection disabled x-cpdlp: 1150ce2b2154cdf9a08c1d381a2910027ccd5efb5b Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [http-auth] Draft Agenda for Berlin X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 20:19:21 -0000 Hi all I've uploaded the draft agenda for the Berlin meeting. If you have any comm= ents or corrections, please contact Matt and me either on- or off-list. See you all in just under two weeks. Yoav http://www.ietf.org/proceedings/87/agenda/agenda-87-httpauth HTTP-Auth Agenda, IETF 87 Wednesday, July 31, 2013 1300-1500 @ Potsdam 2 Audio stream: http://ietf87streaming.dnsalias.net/ietf/ietf875.m3u Jabber room: xmpp:httpauth@jabber.ietf.org?join =20 All the drafts in Kindle and epub format: http://tools.ietf.org/ebook/i-d.httpauth.mobi http://tools.ietf.org/ebook/i-d.httpauth.epub - Agenda Bashing + Blue Sheets + Note Well 5 min - Basic update and open issues (Julian) 15 min - Digest update and open issues (Rifaat) 25 min - Experimental drafts evaluation criteria (chairs) 15 min - HOBA 20 min - MutualAuth 20 min - SCRAM 10 min - open mic Whatever's left= From stephen.farrell@cs.tcd.ie Wed Jul 17 13:31:05 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4B321F9C2E for ; Wed, 17 Jul 2013 13:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id siKRl6OH0MSE for ; Wed, 17 Jul 2013 13:30:59 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4642621F9A1C for ; Wed, 17 Jul 2013 13:30:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 927C9BE9F for ; Wed, 17 Jul 2013 21:30:34 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nd3ayrEcLZDR for ; Wed, 17 Jul 2013 21:30:33 +0100 (IST) Received: from [10.87.48.9] (unknown [86.45.52.27]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D0418BE50 for ; Wed, 17 Jul 2013 21:30:33 +0100 (IST) Message-ID: <51E6FEDF.2030003@cs.tcd.ie> Date: Wed, 17 Jul 2013 21:30:23 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: http-auth@ietf.org References: <36A66E35-C62E-44CA-8A76-E289C1B21FCA@checkpoint.com> In-Reply-To: <36A66E35-C62E-44CA-8A76-E289C1B21FCA@checkpoint.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [http-auth] Draft Agenda for Berlin X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 20:31:05 -0000 Hi Yoav, Matt, Agenda looks good. One question though: On 07/17/2013 09:19 PM, Yoav Nir wrote: > - Experimental drafts evaluation criteria (chairs) 15 min Can you say a bit about what this agenda topic is meant to cover? I guess it could be entirely innocuous (e.g. if you asked for ideas as to what criteria the wg want to use at WGLC time for these) or quite controversial (e.g. if you were to insist that only schemes beginning with the letter H could progress:-). So maybe giving the list a heads up about what you'd like to cover there would be good, just in case we should chat about it on the list in advance. Ta, S. From ynir@checkpoint.com Wed Jul 17 14:10:24 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90D2021E804D for ; Wed, 17 Jul 2013 14:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.563 X-Spam-Level: X-Spam-Status: No, score=-10.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nC8CEs2EUHV6 for ; Wed, 17 Jul 2013 14:10:18 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7EB21F9E89 for ; Wed, 17 Jul 2013 14:10:18 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r6HLAFMr005820; Thu, 18 Jul 2013 00:10:15 +0300 X-CheckPoint: {51E70837-0-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.48]) by IL-EX10.ad.checkpoint.com ([169.254.2.91]) with mapi id 14.02.0342.003; Thu, 18 Jul 2013 00:10:14 +0300 From: Yoav Nir To: "http-auth@ietf.org" , Stephen Farrell Thread-Topic: Evaluation Criteria (was: [http-auth] Draft Agenda for Berlin) Thread-Index: AQHOgzIHv6XivhbXIke1rIgvMh1+Fg== Date: Wed, 17 Jul 2013 21:10:14 +0000 Message-ID: <06054FD8-CF57-4BB0-B638-F1F50FC20A78@checkpoint.com> References: <36A66E35-C62E-44CA-8A76-E289C1B21FCA@checkpoint.com> <51E6FEDF.2030003@cs.tcd.ie> In-Reply-To: <51E6FEDF.2030003@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.46] x-kse-antivirus-interceptor-info: protection disabled x-cpdlp: 11c2a8ea07b35c1ab81d9b1df67dd41cc31ba8a533 Content-Type: text/plain; charset="us-ascii" Content-ID: <7F2403D862ECB246B91263638217FFAE@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [http-auth] Evaluation Criteria (was: Draft Agenda for Berlin) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 21:10:24 -0000 On Jul 17, 2013, at 11:30 PM, Stephen Farrell w= rote: >=20 > Hi Yoav, Matt, >=20 > Agenda looks good. One question though: >=20 > On 07/17/2013 09:19 PM, Yoav Nir wrote: >> - Experimental drafts evaluation criteria (chairs) 15 min >=20 > Can you say a bit about what this agenda topic is meant to > cover? Hi=20 Since we are aiming for Experimental with all of these documents, rather th= an "experimental" as consolation prize, we though we would have a short dis= cussion about what kind of things reviewers should most look for in them. T= hat does not mean that we don't welcome other review comments such as about= algorithm agility and I18N (just examples), some of these issues may be le= ft for a time when we want to rewrite one or more of these as standards-tra= ck. I think it's a good idea to start this discussion now. So as a starting poi= nt, how about these: * Security (obviously - look for vulnerabilities or bad practices) * Implementation pitfalls - anything that will make implementing this unnec= essarily difficult * unstated assumptions or requirements - some examples: * if the method requires a file with cleartext passwords on the web ser= ver, that's fine or not, but it should be stated.=20 * If the method requires TLS, that should be stated.=20 * If the web server needs access to the TLS state (for extractor, or da= ta from a user certificate), that should be stated. * If either or both sides need a good random source, that should be sta= ted. * If implementing this requires some UI elements in the client, that sh= ould be stated. * Interaction with infrastructure - can this work with AAA protocols? Can y= ou use this for OpenID/WebID/OAuth ? * Performance - does this proposal have extraordinary resource (CPU/memory/= bandwidth) requirements? Per authentication? Per logged-in user? Per defin= ed user? This is by no means a closed list, and we'd be very happy to get feedback a= nd updates to this list. Yoav From stephen.farrell@cs.tcd.ie Wed Jul 17 14:22:20 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 328AC21F9D90 for ; Wed, 17 Jul 2013 14:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.849 X-Spam-Level: X-Spam-Status: No, score=-102.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1Ho6wdI2ztH for ; Wed, 17 Jul 2013 14:22:14 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3FB21F9C28 for ; Wed, 17 Jul 2013 14:22:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6F523BEA1; Wed, 17 Jul 2013 22:21:45 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 956CJhnIaw8h; Wed, 17 Jul 2013 22:21:44 +0100 (IST) Received: from [10.87.48.9] (unknown [86.45.52.27]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 871F7BE47; Wed, 17 Jul 2013 22:21:44 +0100 (IST) Message-ID: <51E70ADE.408@cs.tcd.ie> Date: Wed, 17 Jul 2013 22:21:34 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Yoav Nir References: <36A66E35-C62E-44CA-8A76-E289C1B21FCA@checkpoint.com> <51E6FEDF.2030003@cs.tcd.ie> <06054FD8-CF57-4BB0-B638-F1F50FC20A78@checkpoint.com> In-Reply-To: <06054FD8-CF57-4BB0-B638-F1F50FC20A78@checkpoint.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Evaluation Criteria X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 21:22:20 -0000 On 07/17/2013 10:10 PM, Yoav Nir wrote: > > On Jul 17, 2013, at 11:30 PM, Stephen Farrell > wrote: > >> >> Hi Yoav, Matt, >> >> Agenda looks good. One question though: >> >> On 07/17/2013 09:19 PM, Yoav Nir wrote: >>> - Experimental drafts evaluation criteria (chairs) 15 >>> min >> >> Can you say a bit about what this agenda topic is meant to cover? > > Hi > > Since we are aiming for Experimental with all of these documents, > rather than "experimental" as consolation prize, we though we would > have a short discussion about what kind of things reviewers should > most look for in them. That seems reasonable. I'd also note that the charter tells us to be short-lived though, so there's a balance to be achieved between thorough/shoddy and short-lived/endless:-) > That does not mean that we don't welcome other > review comments such as about algorithm agility and I18N (just > examples), some of these issues may be left for a time when we want > to rewrite one or more of these as standards-track. > > I think it's a good idea to start this discussion now. So as a > starting point, how about these: > > * Security (obviously - look for vulnerabilities or bad practices) > > * Implementation pitfalls - anything that will make implementing this > unnecessarily difficult > > * unstated assumptions or requirements - some examples: * if the > method requires a file with cleartext passwords on the web server, > that's fine or not, but it should be stated. * If the method requires > TLS, that should be stated. * If the web server needs access to the > TLS state (for extractor, or data from a user certificate), that > should be stated. * If either or both sides need a good random > source, that should be stated. * If implementing this requires some > UI elements in the client, that should be stated. > > * Interaction with infrastructure - can this work with AAA protocols? > Can you use this for OpenID/WebID/OAuth ? > > * Performance - does this proposal have extraordinary resource > (CPU/memory/bandwidth) requirements? Per authentication? Per > logged-in user? Per defined user > > This is by no means a closed list, and we'd be very happy to get > feedback and updates to this list. * Vulnerable to password-verifier DB theft... or not? :-) If the above are used as ways to prompt better review that sounds like a fine idea. If someone wanted to insist on some form of checklist that drafts have to include, or a set of criteria that they each have to meet then I don't think that would have been such a good plan. Cheers, S. > > Yoav > > > From ynir@checkpoint.com Wed Jul 17 14:43:45 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 194C221F9FBD for ; Wed, 17 Jul 2013 14:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.564 X-Spam-Level: X-Spam-Status: No, score=-10.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEhDbU6C2fAB for ; Wed, 17 Jul 2013 14:43:39 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id D76F221F9F5E for ; Wed, 17 Jul 2013 14:43:38 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r6HLhZ3D012111; Thu, 18 Jul 2013 00:43:35 +0300 X-CheckPoint: {51E71007-10-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.48]) by IL-EX10.ad.checkpoint.com ([169.254.2.91]) with mapi id 14.02.0342.003; Thu, 18 Jul 2013 00:43:34 +0300 From: Yoav Nir To: Stephen Farrell Thread-Topic: Evaluation Criteria Thread-Index: AQHOgzOsPgmnOVj3SUWlKbLepGorM5lpNKyA Date: Wed, 17 Jul 2013 21:43:34 +0000 Message-ID: <5484C651-7532-4DFE-B7FE-49C5685B612E@checkpoint.com> References: <36A66E35-C62E-44CA-8A76-E289C1B21FCA@checkpoint.com> <51E6FEDF.2030003@cs.tcd.ie> <06054FD8-CF57-4BB0-B638-F1F50FC20A78@checkpoint.com> <51E70ADE.408@cs.tcd.ie> In-Reply-To: <51E70ADE.408@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.46] x-kse-antivirus-interceptor-info: protection disabled x-cpdlp: 11c1b6d827358f45a83246a6f0d08d14433a751ce7 Content-Type: text/plain; charset="iso-8859-1" Content-ID: <3F03E87969AA9148892853FE7FCB0BA6@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Evaluation Criteria X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 21:43:45 -0000 On Jul 18, 2013, at 12:21 AM, Stephen Farrell w= rote: >> I think it's a good idea to start this discussion now. So as a >> starting point, how about these: >>=20 >> * Security (obviously - look for vulnerabilities or bad practices) >>=20 >> * Implementation pitfalls - anything that will make implementing this >> unnecessarily difficult >>=20 >> * unstated assumptions or requirements - some examples: * if the >> method requires a file with cleartext passwords on the web server, >> that's fine or not, but it should be stated. * If the method requires >> TLS, that should be stated. * If the web server needs access to the >> TLS state (for extractor, or data from a user certificate), that >> should be stated. * If either or both sides need a good random >> source, that should be stated. * If implementing this requires some >> UI elements in the client, that should be stated. >>=20 >> * Interaction with infrastructure - can this work with AAA protocols? >> Can you use this for OpenID/WebID/OAuth ? >>=20 >> * Performance - does this proposal have extraordinary resource >> (CPU/memory/bandwidth) requirements? Per authentication? Per >> logged-in user? Per defined user >>=20 >> This is by no means a closed list, and we'd be very happy to get >> feedback and updates to this list. >=20 > * Vulnerable to password-verifier DB theft... or not? :-) I hope this falls under security, no? > If the above are used as ways to prompt better review that > sounds like a fine idea. To be clear, there is no check list. I don't think we should advance a clea= rly broken method. But if a method is practical and secure only under a set= of conditions, it can advance as long as it states such conditions. And to answer another question that I got in private email: these criteria = apply to the experimental drafts: HOBA, Mutual, Scram, and RestAuth. Our c= harter calls for standards=3Dtrack for the Basic and Digest documents, plus= the protocols (before the update) have over 20 years of deployment experie= nce, so they will be evaluated just like any other IETF draft. Yoav From duerst@it.aoyama.ac.jp Wed Jul 17 18:32:54 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7CDD21F8E1F for ; Wed, 17 Jul 2013 18:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.923 X-Spam-Level: X-Spam-Status: No, score=-103.923 tagged_above=-999 required=5 tests=[AWL=1.867, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CHObz1DOcVFe for ; Wed, 17 Jul 2013 18:32:47 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 2275621F8AD5 for ; Wed, 17 Jul 2013 18:32:43 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r6I1WPq8020892; Thu, 18 Jul 2013 10:32:26 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 0f06_7353_e6ad60ca_ef49_11e2_9e32_001e6722eec2; Thu, 18 Jul 2013 10:32:25 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id D69E0BF4DD; Thu, 18 Jul 2013 10:30:34 +0900 (JST) Message-ID: <51E74597.9090203@it.aoyama.ac.jp> Date: Thu, 18 Jul 2013 10:32:07 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Stephen Farrell References: <36A66E35-C62E-44CA-8A76-E289C1B21FCA@checkpoint.com> <51E6FEDF.2030003@cs.tcd.ie> In-Reply-To: <51E6FEDF.2030003@cs.tcd.ie> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: http-auth@ietf.org Subject: Re: [http-auth] Draft Agenda for Berlin X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 01:32:54 -0000 On 2013/07/18 5:30, Stephen Farrell wrote: > On 07/17/2013 09:19 PM, Yoav Nir wrote: >> - Experimental drafts evaluation criteria (chairs) 15 min > I guess it could be entirely innocuous (e.g. if you asked for > ideas as to what criteria the wg want to use at WGLC time > for these) or quite controversial (e.g. if you were to insist > that only schemes beginning with the letter H could > progress:-). Well, the schemes not starting with the letter H could just rename themselves :-). It's all about HTTP, so smuggling in the letter H shouldn't be too difficult. Regards, Martin. From yaronf.ietf@gmail.com Sat Jul 20 09:33:37 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1930C21F9017 for ; Sat, 20 Jul 2013 09:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-qi6GXAODU6 for ; Sat, 20 Jul 2013 09:33:36 -0700 (PDT) Received: from mail-ea0-x22a.google.com (mail-ea0-x22a.google.com [IPv6:2a00:1450:4013:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8B221F8E1F for ; Sat, 20 Jul 2013 09:33:35 -0700 (PDT) Received: by mail-ea0-f170.google.com with SMTP id h10so3047761eaj.1 for ; Sat, 20 Jul 2013 09:33:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=kpBCjAqEqqLgJUZUGf+3kMliVmEqz4bGh3MrB514PZc=; b=z9/fd2dtaEz1iUwxTeHYOgeXCikycJiOXXe+2bFA10D10NvBla5e1AqU2Go+avAPmB kvAZ2qFdJW45B2mWBhI//OyuZxd08og5p4TtKW8IFfVrPIu/1y+EXJ8eNtJmoftN1sy2 JVfGvvxbS7K/p7p/ituBONzE1jb19cIQy1arq4u82AWtrhkz4UTQKfuZHDzz9iXCsufj Xnds2fVy8+F2/FkslcWa8zCuuiR0XsIf4cJ7zQWz67NyJrqFJTjTt4faliWyeY5OzsSx F8zSB1IthD0V3ltpuJCJsL+c2DzhSswKXQvIV+oRDBuBnOBx4AVM9ilRqXOlIbUpqmc+ 2nGw== X-Received: by 10.15.110.10 with SMTP id cg10mr20914306eeb.57.1374338015143; Sat, 20 Jul 2013 09:33:35 -0700 (PDT) Received: from [10.0.0.5] (bzq-79-182-218-184.red.bezeqint.net. [79.182.218.184]) by mx.google.com with ESMTPSA id i2sm36467195eeu.4.2013.07.20.09.33.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 20 Jul 2013 09:33:34 -0700 (PDT) Message-ID: <51EABBDB.2090401@gmail.com> Date: Sat, 20 Jul 2013 19:33:31 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: "HTTP Auth WG" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [http-auth] Why update Digest Auth? X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2013 16:33:37 -0000 Sorry for questioning the group's charter, but this keeps bugging me: I'm assuming this WG will publish two Standards Track RFCs, updating Basic and Digest Auth. And a pile of Experimental RFCs with all sorts of lovely state-of-the-art crypto. Enterprises will require vendors to implement the updated Basic and Digest, and in a few years' time we will end up with the worlds' browsers and Web servers supporting Basic and Digest Auth with I18N and (for Digest) crypto agility. Almost nobody will implement the other drafts. In addition, the websec WG will hopefully work on "session continuation", which will extend the authentication to the whole session in a better way than cookies, and will provide channel binding. Assuming much of the Internet's traffic will remain unencrypted for years, this will be "good enough" security for this traffic. But, it won't work with Digest (because it is not "key generating", to borrow an EAP term). Now my question: we are telling implementors to upgrade Digest to gain I18N (and the algorithm agility, which in this case is mostly security theater, because when using short passwords we remain vulnerable to a dictionary attack anyway). Why not tell them *instead* to move to Digest-v2, which is dictionary attack resistant? Digest-v2 could be based on EKE or SRP, or maybe on draft-oiwa-http-mutualauth, and will support session continuation. Seems to me this would be a much better use of our time, as well as implementors' energy. Thanks, Yaron From hotz@jpl.nasa.gov Sun Jul 21 16:33:19 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5F3C21F9AFE for ; Sun, 21 Jul 2013 16:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id viEYJJ6hMrfN for ; Sun, 21 Jul 2013 16:33:15 -0700 (PDT) Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.106]) by ietfa.amsl.com (Postfix) with ESMTP id 2F4C421F9B58 for ; Sun, 21 Jul 2013 16:33:15 -0700 (PDT) Received: from laphotz.jpl.nasa.gov (laphotz.jpl.nasa.gov [128.149.133.44]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r6LNXBDG013832 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Sun, 21 Jul 2013 16:33:12 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: "Henry B. Hotz" In-Reply-To: <51EABBDB.2090401@gmail.com> Date: Sun, 21 Jul 2013 16:33:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51EABBDB.2090401@gmail.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.1508) X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: HTTP Auth WG Subject: Re: [http-auth] Why update Digest Auth? X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jul 2013 23:33:20 -0000 I won't claim to know the future, or even everything about the present, = but I agree with the goal of getting a "digest-v2" with the properties = you suggest. If this group can reach consensus on such a thing fast = enough to leverage some of the resources that might otherwise go to less = ambitious updates to digest, I'm all for it. Is that a realistic possibility? On Jul 20, 2013, at 9:33 AM, Yaron Sheffer = wrote: > Sorry for questioning the group's charter, but this keeps bugging me: >=20 > I'm assuming this WG will publish two Standards Track RFCs, updating = Basic and Digest Auth. And a pile of Experimental RFCs with all sorts of = lovely state-of-the-art crypto. >=20 > Enterprises will require vendors to implement the updated Basic and = Digest, and in a few years' time we will end up with the worlds' = browsers and Web servers supporting Basic and Digest Auth with I18N and = (for Digest) crypto agility. Almost nobody will implement the other = drafts. >=20 > In addition, the websec WG will hopefully work on "session = continuation", which will extend the authentication to the whole session = in a better way than cookies, and will provide channel binding. Assuming = much of the Internet's traffic will remain unencrypted for years, this = will be "good enough" security for this traffic. But, it won't work with = Digest (because it is not "key generating", to borrow an EAP term). >=20 > Now my question: we are telling implementors to upgrade Digest to gain = I18N (and the algorithm agility, which in this case is mostly security = theater, because when using short passwords we remain vulnerable to a = dictionary attack anyway). Why not tell them *instead* to move to = Digest-v2, which is dictionary attack resistant? Digest-v2 could be = based on EKE or SRP, or maybe on draft-oiwa-http-mutualauth, and will = support session continuation. >=20 > Seems to me this would be a much better use of our time, as well as = implementors' energy. >=20 > Thanks, > Yaron > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From stephen.farrell@cs.tcd.ie Sun Jul 21 17:15:36 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E86821F999C for ; Sun, 21 Jul 2013 17:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.799 X-Spam-Level: X-Spam-Status: No, score=-102.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jeEDWj7aXa7N for ; Sun, 21 Jul 2013 17:15:21 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 37AF521F8FF3 for ; Sun, 21 Jul 2013 17:15:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9EC04BE50; Mon, 22 Jul 2013 01:14:56 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rrxc8pALE0Sj; Mon, 22 Jul 2013 01:14:55 +0100 (IST) Received: from [10.87.48.9] (unknown [86.45.49.168]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 060BABE4D; Mon, 22 Jul 2013 01:14:54 +0100 (IST) Message-ID: <51EC7974.4020606@cs.tcd.ie> Date: Mon, 22 Jul 2013 01:14:44 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Yaron Sheffer References: <51EABBDB.2090401@gmail.com> In-Reply-To: <51EABBDB.2090401@gmail.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: HTTP Auth WG Subject: Re: [http-auth] Why update Digest Auth? X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 00:15:37 -0000 Hiya, On 07/20/2013 05:33 PM, Yaron Sheffer wrote: > Sorry for questioning the group's charter, but this keeps bugging me: I'd rather we do stuff as promised personally and not re-open the charter. In saying that, I am assuming we finish what we promised promptly (i.e. within months, not years). > I'm assuming this WG will publish two Standards Track RFCs, updating > Basic and Digest Auth. And a pile of Experimental RFCs with all sorts of > lovely state-of-the-art crypto. > > Enterprises will require vendors to implement the updated Basic and > Digest, and in a few years' time we will end up with the worlds' > browsers and Web servers supporting Basic and Digest Auth with I18N and > (for Digest) crypto agility. Fair point about vendors and their customers. OTOH, RFC 1149 has also reportedly been requested of vendors, so customer RFQ silliness isn't really a good metric for what an IETF WG ought do. > Almost nobody will implement the other drafts. That's a nicely confident prediction. Care to bet a beer? (If so, quantify it fairly somehow and I'll take that bet.) I hope you're wrong, at least wrt HOBA, but in any case, we ought not base any decisions on you prediction above, or any equivalent prediction. > In addition, the websec WG will hopefully work on "session > continuation", which will extend the authentication to the whole session > in a better way than cookies, and will provide channel binding. Assuming > much of the Internet's traffic will remain unencrypted for years, this > will be "good enough" security for this traffic. But, it won't work with > Digest (because it is not "key generating", to borrow an EAP term). > > Now my question: we are telling implementors to upgrade Digest to gain > I18N (and the algorithm agility, which in this case is mostly security > theater, because when using short passwords we remain vulnerable to a > dictionary attack anyway). Why not tell them *instead* to move to > Digest-v2, which is dictionary attack resistant? Digest-v2 could be > based on EKE or SRP, or maybe on draft-oiwa-http-mutualauth, and will > support session continuation. > > Seems to me this would be a much better use of our time, as well as > implementors' energy. Not to me. You can already and should already run over TLS, at which point any advantage of ZKPP gets lost in the noise since phishing and password verifier DB leakage are entirely unaffected by the elegant ZKPP bit fiddling. (That is a shame, since the crypto really is quite elegant, but its nonetheless true.) So I'm still of the opinion that minimal modernising of the existing schemes plus some experiments is right here and we should not pointlessly anoint any of the experiments with standards-track status until after we've seen that they are useful in reality. Having said that, if we decided to abandon work on Digest I'd not object. S. > > Thanks, > Yaron > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > > From ynir@checkpoint.com Mon Jul 22 02:25:42 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A610E21F9E6E for ; Mon, 22 Jul 2013 02:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.557 X-Spam-Level: X-Spam-Status: No, score=-10.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fFq4LvIY7s9A for ; Mon, 22 Jul 2013 02:25:34 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id E57F011E8109 for ; Mon, 22 Jul 2013 02:17:24 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r6M9GuB3005010; Mon, 22 Jul 2013 12:16:56 +0300 X-CheckPoint: {51ECF888-1E-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.48]) by IL-EX10.ad.checkpoint.com ([169.254.2.91]) with mapi id 14.02.0342.003; Mon, 22 Jul 2013 12:16:56 +0300 From: Yoav Nir To: Yaron Sheffer , HTTP Auth WG Thread-Topic: [http-auth] Why update Digest Auth? Thread-Index: AQHOhWbnTRKd/bWOG0ubR0Cbu4hLSJlwa0vg Date: Mon, 22 Jul 2013 09:16:56 +0000 Message-ID: <4613980CFC78314ABFD7F85CC302772111A9EE0E@DAG-EX10.ad.checkpoint.com> References: <51EABBDB.2090401@gmail.com> In-Reply-To: <51EABBDB.2090401@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [91.90.139.27] x-kse-antivirus-interceptor-info: protection disabled x-cpdlp: 1119a33acaa4650251d6ca97824121e5e2436bdda9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [http-auth] Why update Digest Auth? X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 09:25:42 -0000 I'm not totally opposed, but if we replace Digest with some ZKPP, it's not = Digest any more.=20 Two of our experimental drafts are "better digests" - MutualAuth and SCRAM.= MutualAuth is mature, has implementations, and I don't see why it shouldn'= t be ready to progress almost as fast as Digest. Do you think that enterprises would require "Digest" rather than "MutualAut= h" or "SCRAM" just because it's called "Digest"? Hopefully these new methods will also support international user names and = passwords (because specifying a user authentication method is 2013 that doe= s not support non-English names is even sillier than specifying one that re= lies on MD5 for security). Then it's up to the enterprises to decide what t= hey want to require vendors to implement. Yoav -----Original Message----- From: http-auth-bounces@ietf.org [mailto:http-auth-bounces@ietf.org] On Beh= alf Of Yaron Sheffer Sent: Saturday, July 20, 2013 7:34 PM To: HTTP Auth WG Subject: [http-auth] Why update Digest Auth? Sorry for questioning the group's charter, but this keeps bugging me: I'm assuming this WG will publish two Standards Track RFCs, updating Basic = and Digest Auth. And a pile of Experimental RFCs with all sorts of lovely s= tate-of-the-art crypto. Enterprises will require vendors to implement the updated Basic and Digest,= and in a few years' time we will end up with the worlds'=20 browsers and Web servers supporting Basic and Digest Auth with I18N and (fo= r Digest) crypto agility. Almost nobody will implement the other drafts. In addition, the websec WG will hopefully work on "session continuation", w= hich will extend the authentication to the whole session in a better way th= an cookies, and will provide channel binding. Assuming much of the Internet= 's traffic will remain unencrypted for years, this will be "good enough" se= curity for this traffic. But, it won't work with Digest (because it is not = "key generating", to borrow an EAP term). Now my question: we are telling implementors to upgrade Digest to gain I18N= (and the algorithm agility, which in this case is mostly security theater,= because when using short passwords we remain vulnerable to a dictionary at= tack anyway). Why not tell them *instead* to move to Digest-v2, which is di= ctionary attack resistant? Digest-v2 could be based on EKE or SRP, or maybe= on draft-oiwa-http-mutualauth, and will support session continuation. Seems to me this would be a much better use of our time, as well as impleme= ntors' energy. Thanks, Yaron From rifaat.ietf@gmail.com Mon Jul 22 03:55:49 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0B1B21F999B for ; Mon, 22 Jul 2013 03:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.813 X-Spam-Level: X-Spam-Status: No, score=-1.813 tagged_above=-999 required=5 tests=[AWL=-0.610, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zFCFqTp-jiqs for ; Mon, 22 Jul 2013 03:55:10 -0700 (PDT) Received: from mail-ee0-x22c.google.com (mail-ee0-x22c.google.com [IPv6:2a00:1450:4013:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB2621E8086 for ; Mon, 22 Jul 2013 03:51:28 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id c13so3761788eek.31 for ; Mon, 22 Jul 2013 03:51:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=uMqOfrHBN9MySKr0IjG2W8RGmjQGc1PcuJ28hYpt+QU=; b=jWigywJwifqYH500vWwZKStFWP5Gsh6Smtk8+Yu2n/bURWUafXTXEYFOAZPs4rS1fN NQScQx0aM4r8TI872ZuWConlxy5ziPF37XmN/IQM4fre24zgOkwYl4khTWSkzNZTK4Pm htm69wtvziy5qfHoRNetkGUi+rwsOWQdO9hYFgXZm2FvsijGgreP1Q9uRwn1xfDL6upN MoV5khBYERlbfyx2AdfERSUdWDzfkKDNtsttzBnqzGlq4NOIodY1YTT0cWmsdZKyEdpO WbG8wq7PoiO3sJz4cEyU2AvQpHRA6N/Oysevv30PyoEjrCMI8c7fiMkEmhZ9Lq9xau+y L3XQ== X-Received: by 10.15.43.11 with SMTP id w11mr27185855eev.27.1374490279755; Mon, 22 Jul 2013 03:51:19 -0700 (PDT) Received: from [192.168.1.15] (93-173-50-241.bb.netvision.net.il. [93.173.50.241]) by mx.google.com with ESMTPSA id i2sm49887671eeu.4.2013.07.22.03.51.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Jul 2013 03:51:18 -0700 (PDT) References: <51EABBDB.2090401@gmail.com> <4613980CFC78314ABFD7F85CC302772111A9EE0E@DAG-EX10.ad.checkpoint.com> Mime-Version: 1.0 (1.0) In-Reply-To: <4613980CFC78314ABFD7F85CC302772111A9EE0E@DAG-EX10.ad.checkpoint.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10B329) From: Rifaat Shekh-Yusef Date: Mon, 22 Jul 2013 13:51:07 +0300 To: Yoav Nir Cc: HTTP Auth WG Subject: Re: [http-auth] Why update Digest Auth? X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 10:55:49 -0000 I do not like the idea of canceling the Digest work for the following reason= s: 1. Digest is used with SIP protocol, and I am not sure the widely used Diges= t mechanism in SIP networks will be replaced with any if the new proposals. 2. This was already discussed during the discussion on the charter, and it s= eems a bit late to reopen that right now. 3. I think that the adopters of the new mechanisms should be motivated by th= e merit of the new mechanisms, not by us not updating Digest. 4. Some of the adopters of Digest might be satisfied with the Digest as it f= ulfills their need, and might not be interested in a "better" solution for t= heir network. To address the timeline point that Stephen has raised, I think that the agil= ity work should be done fairly soon as I do not see any major challenges at t= his stage. =20 Regards, Rifaat Sent from my iPhone On 2013-07-22, at 12:16 PM, Yoav Nir wrote: > I'm not totally opposed, but if we replace Digest with some ZKPP, it's not= Digest any more.=20 >=20 > Two of our experimental drafts are "better digests" - MutualAuth and SCRAM= . MutualAuth is mature, has implementations, and I don't see why it shouldn'= t be ready to progress almost as fast as Digest. >=20 > Do you think that enterprises would require "Digest" rather than "MutualAu= th" or "SCRAM" just because it's called "Digest"? >=20 > Hopefully these new methods will also support international user names and= passwords (because specifying a user authentication method is 2013 that doe= s not support non-English names is even sillier than specifying one that rel= ies on MD5 for security). Then it's up to the enterprises to decide what the= y want to require vendors to implement. >=20 > Yoav >=20 > -----Original Message----- > From: http-auth-bounces@ietf.org [mailto:http-auth-bounces@ietf.org] On Be= half Of Yaron Sheffer > Sent: Saturday, July 20, 2013 7:34 PM > To: HTTP Auth WG > Subject: [http-auth] Why update Digest Auth? >=20 > Sorry for questioning the group's charter, but this keeps bugging me: >=20 > I'm assuming this WG will publish two Standards Track RFCs, updating Basic= and Digest Auth. And a pile of Experimental RFCs with all sorts of lovely s= tate-of-the-art crypto. >=20 > Enterprises will require vendors to implement the updated Basic and Digest= , and in a few years' time we will end up with the worlds'=20 > browsers and Web servers supporting Basic and Digest Auth with I18N and (f= or Digest) crypto agility. Almost nobody will implement the other drafts. >=20 > In addition, the websec WG will hopefully work on "session continuation", w= hich will extend the authentication to the whole session in a better way tha= n cookies, and will provide channel binding. Assuming much of the Internet's= traffic will remain unencrypted for years, this will be "good enough" secur= ity for this traffic. But, it won't work with Digest (because it is not "key= generating", to borrow an EAP term). >=20 > Now my question: we are telling implementors to upgrade Digest to gain I18= N (and the algorithm agility, which in this case is mostly security theater,= because when using short passwords we remain vulnerable to a dictionary att= ack anyway). Why not tell them *instead* to move to Digest-v2, which is dict= ionary attack resistant? Digest-v2 could be based on EKE or SRP, or maybe on= draft-oiwa-http-mutualauth, and will support session continuation. >=20 > Seems to me this would be a much better use of our time, as well as implem= entors' energy. >=20 > Thanks, > Yaron >=20 > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth From paul.hoffman@vpnc.org Mon Jul 22 07:50:59 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0713C11E80AE for ; Mon, 22 Jul 2013 07:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RdH4Uj0VyrEF for ; Mon, 22 Jul 2013 07:50:53 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 531AF21E80C2 for ; Mon, 22 Jul 2013 07:49:38 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-228.dsl.dynamic.sonic.net [50.1.98.228]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r6MEnNwe069469 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 22 Jul 2013 07:49:24 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-228.dsl.dynamic.sonic.net [50.1.98.228] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <4613980CFC78314ABFD7F85CC302772111A9EE0E@DAG-EX10.ad.checkpoint.com> Date: Mon, 22 Jul 2013 07:49:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51EABBDB.2090401@gmail.com> <4613980CFC78314ABFD7F85CC302772111A9EE0E@DAG-EX10.ad.checkpoint.com> To: Yoav Nir X-Mailer: Apple Mail (2.1508) Cc: HTTP Auth WG Subject: Re: [http-auth] Why update Digest Auth? X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 14:50:59 -0000 On Jul 22, 2013, at 2:16 AM, Yoav Nir wrote: > I'm not totally opposed, but if we replace Digest with some ZKPP, it's = not Digest any more.=20 +1 > Do you think that enterprises would require "Digest" rather than = "MutualAuth" or "SCRAM" just because it's called "Digest"? As Rifaat points out, some *protocols* require Digest. Some will = continue to do so even after there is a standards-track "better than = Digest while still using dictionary-guessable passwords" mechanism, some = might change to the new mechanism. > Hopefully these new methods will also support international user names = and passwords (because specifying a user authentication method is 2013 = that does not support non-English names is even sillier than specifying = one that relies on MD5 for security). Then it's up to the enterprises to = decide what they want to require vendors to implement. If the WG is going to come to agreement on how to do i18n for usernames = and passwords, it makes sense to wind that into today's Digest instead = of forcing protocols that use Digest to either be stuck with bad i18n or = have to change crypto models. --Paul Hoffman= From yaronf.ietf@gmail.com Mon Jul 22 13:44:37 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CECC311E811B for ; Mon, 22 Jul 2013 13:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K9+I8dO239B5 for ; Mon, 22 Jul 2013 13:44:37 -0700 (PDT) Received: from mail-ea0-x235.google.com (mail-ea0-x235.google.com [IPv6:2a00:1450:4013:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 0682E11E80D3 for ; Mon, 22 Jul 2013 13:44:33 -0700 (PDT) Received: by mail-ea0-f181.google.com with SMTP id a15so4103781eae.26 for ; Mon, 22 Jul 2013 13:44:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=KjqliNxuih2SAN3KzOvv2YY1J8x2ElI0DIXv+ZnE3X4=; b=xdONIdJqX/9/wsbI8NnvyxZmqoOE2boopk+uhTxUqMRx0B136BtR1oqN5Oy1Y7mWYC oCyv1qyLXduGNOyVGIIB0YZZRDhzA7QSCLsSutZRgkBsKsy1osj2KYARkI59OqPceDXp 5IjELio9pM6xMD1aLn2USCmIpNcx0gJg5Czlwoc91nnl5bM+7aGflYY8ByCj2EBYFK5/ k/6Eq9OAw0yxMjf4dbQ1H8VUVSriZ3BKotHl1uohQO6bGZ1FU5xg32AECVee+cb8QNcN HHF+coZbr6i63XbQdT45vhrjTqO1Zh+o5NBvhxuvJvKBa4ZqNAU2dk5D3nIdSP5Wz0Kx vsTA== X-Received: by 10.15.21.199 with SMTP id d47mr29067977eeu.36.1374525873088; Mon, 22 Jul 2013 13:44:33 -0700 (PDT) Received: from [10.0.0.5] (bzq-79-181-185-54.red.bezeqint.net. [79.181.185.54]) by mx.google.com with ESMTPSA id r54sm53600309eev.8.2013.07.22.13.44.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Jul 2013 13:44:32 -0700 (PDT) Message-ID: <51ED99AE.3000403@gmail.com> Date: Mon, 22 Jul 2013 23:44:30 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Stephen Farrell References: <51EABBDB.2090401@gmail.com> <51EC7974.4020606@cs.tcd.ie> In-Reply-To: <51EC7974.4020606@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: HTTP Auth WG Subject: Re: [http-auth] Why update Digest Auth? X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 20:44:38 -0000 On 2013-07-22 03:14, Stephen Farrell wrote: [Speculation and counter-speculation removed. As a policy, I never bet a beer with an Irishman :-) ] >> >> Now my question: we are telling implementors to upgrade Digest to gain >> I18N (and the algorithm agility, which in this case is mostly security >> theater, because when using short passwords we remain vulnerable to a >> dictionary attack anyway). Why not tell them *instead* to move to >> Digest-v2, which is dictionary attack resistant? Digest-v2 could be >> based on EKE or SRP, or maybe on draft-oiwa-http-mutualauth, and will >> support session continuation. >> >> Seems to me this would be a much better use of our time, as well as >> implementors' energy. > > Not to me. You can already and should already run over TLS, at which > point any advantage of ZKPP gets lost in the noise since phishing and > password verifier DB leakage are entirely unaffected by the elegant > ZKPP bit fiddling. (That is a shame, since the crypto really is quite > elegant, but its nonetheless true.) Everybody running on TLS today uses Basic, and I'd be surprised if we started seeing Digest on TLS. OTOH on insecure transport, ZKPP has a strong advantage, despite the database stealing vulnerability. IMHO assuming that non-TLS use will simply go away is way too optimistic. > > So I'm still of the opinion that minimal modernising of the existing > schemes plus some experiments is right here and we should not > pointlessly anoint any of the experiments with standards-track > status until after we've seen that they are useful in reality. > > Having said that, if we decided to abandon work on Digest I'd not > object. > > S. > >> >> Thanks, >> Yaron >> _______________________________________________ >> http-auth mailing list >> http-auth@ietf.org >> https://www.ietf.org/mailman/listinfo/http-auth >> >> From yaronf.ietf@gmail.com Mon Jul 22 13:51:48 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABA0611E80DF for ; Mon, 22 Jul 2013 13:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TDLTgoy9Sdfz for ; Mon, 22 Jul 2013 13:51:48 -0700 (PDT) Received: from mail-ee0-x233.google.com (mail-ee0-x233.google.com [IPv6:2a00:1450:4013:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id CDFEF11E80D3 for ; Mon, 22 Jul 2013 13:51:47 -0700 (PDT) Received: by mail-ee0-f51.google.com with SMTP id e52so4055029eek.24 for ; Mon, 22 Jul 2013 13:51:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=bhYF8FRFt1QLmSmwyHA6z53m49GC7j4SGKcg8QT8LTA=; b=agM8kfA1OUzivdzK532EIM/iusS+Q4KraL0EHc2YpfVqZyt9fJAtjfDBI86SQGlTGm vATFhWAyI4OfUzYnT6A4B4YRMjDDNcTYOEuTeqpk71gzvfltmrivHMV+4dyZiwSADwr0 4LBVe4W1gz7So6p30AMF3j6Efoq8dDvRFv1y4Pih8Jjh71qZiagkbBr19sYXSNSZaF/7 M2M7jI+fl83Djc83NEOptWRhfJ7MBWaoHS23Q23HgkDseWp0i406YoixCww12LEOIOGz i3IgEdFmCaKXvjgOS8RYLvC24Yeg8yFQaHnR90MVH2qmP96/vLTqqR2r4gtj0k43YTHr KXaQ== X-Received: by 10.14.4.70 with SMTP id 46mr28926384eei.42.1374526306878; Mon, 22 Jul 2013 13:51:46 -0700 (PDT) Received: from [10.0.0.5] (bzq-79-183-199-41.red.bezeqint.net. [79.183.199.41]) by mx.google.com with ESMTPSA id m1sm53573344eex.17.2013.07.22.13.51.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Jul 2013 13:51:46 -0700 (PDT) Message-ID: <51ED9B60.40907@gmail.com> Date: Mon, 22 Jul 2013 23:51:44 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Yoav Nir References: <51EABBDB.2090401@gmail.com> <4613980CFC78314ABFD7F85CC302772111A9EE0E@DAG-EX10.ad.checkpoint.com> In-Reply-To: <4613980CFC78314ABFD7F85CC302772111A9EE0E@DAG-EX10.ad.checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: HTTP Auth WG Subject: Re: [http-auth] Why update Digest Auth? X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 20:51:48 -0000 Hi Yoav, I agree if it's a ZKPP, it's not Digest any more. I just say, it's a better use of everybody's time. And it's not about the name, it's about which one we put on the standards track. Re: Mutual Auth, our charter says it is going to be Experimental. So no matter if it's published early, it will have a much lower chance of being implemented. By the way, Mutual Auth appears to be serious on I18N, as it should be. Thanks, Yaron On 2013-07-22 12:16, Yoav Nir wrote: > I'm not totally opposed, but if we replace Digest with some ZKPP, it's not Digest any more. > > Two of our experimental drafts are "better digests" - MutualAuth and SCRAM. MutualAuth is mature, has implementations, and I don't see why it shouldn't be ready to progress almost as fast as Digest. > > Do you think that enterprises would require "Digest" rather than "MutualAuth" or "SCRAM" just because it's called "Digest"? > > Hopefully these new methods will also support international user names and passwords (because specifying a user authentication method is 2013 that does not support non-English names is even sillier than specifying one that relies on MD5 for security). Then it's up to the enterprises to decide what they want to require vendors to implement. > > Yoav > > -----Original Message----- > From: http-auth-bounces@ietf.org [mailto:http-auth-bounces@ietf.org] On Behalf Of Yaron Sheffer > Sent: Saturday, July 20, 2013 7:34 PM > To: HTTP Auth WG > Subject: [http-auth] Why update Digest Auth? > > Sorry for questioning the group's charter, but this keeps bugging me: > > I'm assuming this WG will publish two Standards Track RFCs, updating Basic and Digest Auth. And a pile of Experimental RFCs with all sorts of lovely state-of-the-art crypto. > > Enterprises will require vendors to implement the updated Basic and Digest, and in a few years' time we will end up with the worlds' > browsers and Web servers supporting Basic and Digest Auth with I18N and (for Digest) crypto agility. Almost nobody will implement the other drafts. > > In addition, the websec WG will hopefully work on "session continuation", which will extend the authentication to the whole session in a better way than cookies, and will provide channel binding. Assuming much of the Internet's traffic will remain unencrypted for years, this will be "good enough" security for this traffic. But, it won't work with Digest (because it is not "key generating", to borrow an EAP term). > > Now my question: we are telling implementors to upgrade Digest to gain I18N (and the algorithm agility, which in this case is mostly security theater, because when using short passwords we remain vulnerable to a dictionary attack anyway). Why not tell them *instead* to move to Digest-v2, which is dictionary attack resistant? Digest-v2 could be based on EKE or SRP, or maybe on draft-oiwa-http-mutualauth, and will support session continuation. > > Seems to me this would be a much better use of our time, as well as implementors' energy. > > Thanks, > Yaron > From yaronf.ietf@gmail.com Mon Jul 22 14:28:17 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD90511E8123 for ; Mon, 22 Jul 2013 14:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DcrI8GqZEyJ for ; Mon, 22 Jul 2013 14:28:17 -0700 (PDT) Received: from mail-ea0-x22e.google.com (mail-ea0-x22e.google.com [IPv6:2a00:1450:4013:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id B74A511E80FC for ; Mon, 22 Jul 2013 14:28:16 -0700 (PDT) Received: by mail-ea0-f174.google.com with SMTP id o10so4077976eaj.5 for ; Mon, 22 Jul 2013 14:28:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=f6NvJqA8RA2c24QmdCHQ6+3H/y5m18ga2zlsRDxeVkk=; b=tuJfSko+6a8oQ+EcY8CAnSVqAXhigH7XwZXmxDWu95ioJamwfepLyFGvLVm5KrWo07 8IBF29pXTGyFJplWtaqjpdWoW3Dp8gWOyog6pR0KX35P1LvaYDdszhvLUbyK1wuUxwQ7 yffH8NsvNCO2Y8aEmiBb4eGoAL44Z+MbOJWxPcHkMVS2h7eGdbWsvHnWYFZax7FgVanu NNdLEmsQf1hwcI4VctlHcD0gMGV9BE/XkJQsUrHVVXjScwPZrMaHoenh4i6oEUrtSHvp exj1E4MD1j7V1Z+9B+wA35q21lBz5bOJa8jHevDzFTDCpMcoZN2MqMnX5sj5P5mN5XAu esAw== X-Received: by 10.14.149.141 with SMTP id x13mr29619979eej.77.1374528494577; Mon, 22 Jul 2013 14:28:14 -0700 (PDT) Received: from [10.0.0.5] (bzq-79-183-199-41.red.bezeqint.net. [79.183.199.41]) by mx.google.com with ESMTPSA id o5sm53891687eef.5.2013.07.22.14.28.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Jul 2013 14:28:13 -0700 (PDT) Message-ID: <51EDA3EB.7080108@gmail.com> Date: Tue, 23 Jul 2013 00:28:11 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Rifaat Shekh-Yusef References: <51EABBDB.2090401@gmail.com> <4613980CFC78314ABFD7F85CC302772111A9EE0E@DAG-EX10.ad.checkpoint.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: HTTP Auth WG Subject: Re: [http-auth] Why update Digest Auth? X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 21:28:18 -0000 Hi Rifaat, responding only to the first of your objections: I am really worried if Digest (presumably not over TLS) is the standard authentication method in SIP. A few questions: - Do people normally use it with a human-memorable password? If they do, then the dictionary attack vulnerability is IMO much more serious than continuing to use MD5, and would remain serious after we upgrade Digest. - On the other hand, if people use Digest with computer-generated authentication strings, then I18N is probably unnecessary. - Looking at RFC 3665, it seems to me SIP Register can accommodate a two round-trip authentication method, just as well as HTTP can. Thanks, Yaron On 2013-07-22 13:51, Rifaat Shekh-Yusef wrote: > I do not like the idea of canceling the Digest work for the following reasons: > > 1. Digest is used with SIP protocol, and I am not sure the widely used Digest mechanism in SIP networks will be replaced with any if the new proposals. > > 2. This was already discussed during the discussion on the charter, and it seems a bit late to reopen that right now. > > 3. I think that the adopters of the new mechanisms should be motivated by the merit of the new mechanisms, not by us not updating Digest. > > 4. Some of the adopters of Digest might be satisfied with the Digest as it fulfills their need, and might not be interested in a "better" solution for their network. > > To address the timeline point that Stephen has raised, I think that the agility work should be done fairly soon as I do not see any major challenges at this stage. > > Regards, > Rifaat > > Sent from my iPhone > > On 2013-07-22, at 12:16 PM, Yoav Nir wrote: > >> I'm not totally opposed, but if we replace Digest with some ZKPP, it's not Digest any more. >> >> Two of our experimental drafts are "better digests" - MutualAuth and SCRAM. MutualAuth is mature, has implementations, and I don't see why it shouldn't be ready to progress almost as fast as Digest. >> >> Do you think that enterprises would require "Digest" rather than "MutualAuth" or "SCRAM" just because it's called "Digest"? >> >> Hopefully these new methods will also support international user names and passwords (because specifying a user authentication method is 2013 that does not support non-English names is even sillier than specifying one that relies on MD5 for security). Then it's up to the enterprises to decide what they want to require vendors to implement. >> >> Yoav >> >> -----Original Message----- >> From: http-auth-bounces@ietf.org [mailto:http-auth-bounces@ietf.org] On Behalf Of Yaron Sheffer >> Sent: Saturday, July 20, 2013 7:34 PM >> To: HTTP Auth WG >> Subject: [http-auth] Why update Digest Auth? >> >> Sorry for questioning the group's charter, but this keeps bugging me: >> >> I'm assuming this WG will publish two Standards Track RFCs, updating Basic and Digest Auth. And a pile of Experimental RFCs with all sorts of lovely state-of-the-art crypto. >> >> Enterprises will require vendors to implement the updated Basic and Digest, and in a few years' time we will end up with the worlds' >> browsers and Web servers supporting Basic and Digest Auth with I18N and (for Digest) crypto agility. Almost nobody will implement the other drafts. >> >> In addition, the websec WG will hopefully work on "session continuation", which will extend the authentication to the whole session in a better way than cookies, and will provide channel binding. Assuming much of the Internet's traffic will remain unencrypted for years, this will be "good enough" security for this traffic. But, it won't work with Digest (because it is not "key generating", to borrow an EAP term). >> >> Now my question: we are telling implementors to upgrade Digest to gain I18N (and the algorithm agility, which in this case is mostly security theater, because when using short passwords we remain vulnerable to a dictionary attack anyway). Why not tell them *instead* to move to Digest-v2, which is dictionary attack resistant? Digest-v2 could be based on EKE or SRP, or maybe on draft-oiwa-http-mutualauth, and will support session continuation. >> >> Seems to me this would be a much better use of our time, as well as implementors' energy. >> >> Thanks, >> Yaron >> >> _______________________________________________ >> http-auth mailing list >> http-auth@ietf.org >> https://www.ietf.org/mailman/listinfo/http-auth From rifaat.ietf@gmail.com Mon Jul 22 23:44:10 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A24811E8103 for ; Mon, 22 Jul 2013 23:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.933 X-Spam-Level: X-Spam-Status: No, score=-0.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8nOzmYJRrteY for ; Mon, 22 Jul 2013 23:44:09 -0700 (PDT) Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 2C11511E80D1 for ; Mon, 22 Jul 2013 23:44:08 -0700 (PDT) Received: by mail-qa0-f53.google.com with SMTP id hu14so1072311qab.12 for ; Mon, 22 Jul 2013 23:44:02 -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=mC/nU+UXuiv6f5J4iXgJ+t6M7IOs/E/y0XNs8npoQXA=; b=TzJY8HS4s0e1XaTycPePKPdfxZSMqPT8XmIbM7qBdWBYMwdEeBnx+uS/TwQT7OmKQL 28iraWiKuKbz4cRL00NkOPQo5kPTRxTNbLSV5MHwoOoAE0ij0l2ihy2Y8Vz1yi46WyZ3 7uY6yzmFPzM+IFcLPSkKey3mOxdaodgIPlUTPHiLaVM+erbKHNRYTNB5Bau3awL8WBO1 s3Poe+a2bsL2WK8p1HAGwjsV2on13iCxasrRKv66nzKbau4NmUui53IN/t5fW9czzhWY AN/LEWXGOaBy7Ik0HSHDpWdYRWEODM20BgDXr+CBZVPMZRrDDTSOaTOcTHhn9w/uP+Ey pcHg== MIME-Version: 1.0 X-Received: by 10.224.182.79 with SMTP id cb15mr38284288qab.48.1374561842202; Mon, 22 Jul 2013 23:44:02 -0700 (PDT) Received: by 10.49.39.201 with HTTP; Mon, 22 Jul 2013 23:44:02 -0700 (PDT) In-Reply-To: <51EDA3EB.7080108@gmail.com> References: <51EABBDB.2090401@gmail.com> <4613980CFC78314ABFD7F85CC302772111A9EE0E@DAG-EX10.ad.checkpoint.com> <51EDA3EB.7080108@gmail.com> Date: Tue, 23 Jul 2013 02:44:02 -0400 Message-ID: From: Rifaat Shekh-Yusef To: Yaron Sheffer Content-Type: multipart/alternative; boundary=20cf303b4291538df304e2281edb Cc: HTTP Auth WG Subject: Re: [http-auth] Why update Digest Auth? X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 06:44:10 -0000 --20cf303b4291538df304e2281edb Content-Type: text/plain; charset=ISO-8859-1 Hi Yaron, SIP is deployed over UDP, TCP, and TLS. Both types of deployments, human-memorable & machine-generated passwords, are widely used. Regards, Rifaat On Mon, Jul 22, 2013 at 5:28 PM, Yaron Sheffer wrote: > Hi Rifaat, > > responding only to the first of your objections: > > I am really worried if Digest (presumably not over TLS) is the standard > authentication method in SIP. A few questions: > > - Do people normally use it with a human-memorable password? If they do, > then the dictionary attack vulnerability is IMO much more serious than > continuing to use MD5, and would remain serious after we upgrade Digest. > > - On the other hand, if people use Digest with computer-generated > authentication strings, then I18N is probably unnecessary. > > - Looking at RFC 3665, it seems to me SIP Register can accommodate a two > round-trip authentication method, just as well as HTTP can. > > Thanks, > Yaron > > > On 2013-07-22 13:51, Rifaat Shekh-Yusef wrote: > >> I do not like the idea of canceling the Digest work for the following >> reasons: >> >> 1. Digest is used with SIP protocol, and I am not sure the widely used >> Digest mechanism in SIP networks will be replaced with any if the new >> proposals. >> >> 2. This was already discussed during the discussion on the charter, and >> it seems a bit late to reopen that right now. >> >> 3. I think that the adopters of the new mechanisms should be motivated by >> the merit of the new mechanisms, not by us not updating Digest. >> >> 4. Some of the adopters of Digest might be satisfied with the Digest as >> it fulfills their need, and might not be interested in a "better" solution >> for their network. >> >> To address the timeline point that Stephen has raised, I think that the >> agility work should be done fairly soon as I do not see any major >> challenges at this stage. >> >> Regards, >> Rifaat >> >> Sent from my iPhone >> >> On 2013-07-22, at 12:16 PM, Yoav Nir wrote: >> >> I'm not totally opposed, but if we replace Digest with some ZKPP, it's >>> not Digest any more. >>> >>> Two of our experimental drafts are "better digests" - MutualAuth and >>> SCRAM. MutualAuth is mature, has implementations, and I don't see why it >>> shouldn't be ready to progress almost as fast as Digest. >>> >>> Do you think that enterprises would require "Digest" rather than >>> "MutualAuth" or "SCRAM" just because it's called "Digest"? >>> >>> Hopefully these new methods will also support international user names >>> and passwords (because specifying a user authentication method is 2013 that >>> does not support non-English names is even sillier than specifying one that >>> relies on MD5 for security). Then it's up to the enterprises to decide what >>> they want to require vendors to implement. >>> >>> Yoav >>> >>> -----Original Message----- >>> From: http-auth-bounces@ietf.org [mailto:http-auth-bounces@**ietf.org] >>> On Behalf Of Yaron Sheffer >>> Sent: Saturday, July 20, 2013 7:34 PM >>> To: HTTP Auth WG >>> Subject: [http-auth] Why update Digest Auth? >>> >>> Sorry for questioning the group's charter, but this keeps bugging me: >>> >>> I'm assuming this WG will publish two Standards Track RFCs, updating >>> Basic and Digest Auth. And a pile of Experimental RFCs with all sorts of >>> lovely state-of-the-art crypto. >>> >>> Enterprises will require vendors to implement the updated Basic and >>> Digest, and in a few years' time we will end up with the worlds' >>> browsers and Web servers supporting Basic and Digest Auth with I18N and >>> (for Digest) crypto agility. Almost nobody will implement the other drafts. >>> >>> In addition, the websec WG will hopefully work on "session >>> continuation", which will extend the authentication to the whole session in >>> a better way than cookies, and will provide channel binding. Assuming much >>> of the Internet's traffic will remain unencrypted for years, this will be >>> "good enough" security for this traffic. But, it won't work with Digest >>> (because it is not "key generating", to borrow an EAP term). >>> >>> Now my question: we are telling implementors to upgrade Digest to gain >>> I18N (and the algorithm agility, which in this case is mostly security >>> theater, because when using short passwords we remain vulnerable to a >>> dictionary attack anyway). Why not tell them *instead* to move to >>> Digest-v2, which is dictionary attack resistant? Digest-v2 could be based >>> on EKE or SRP, or maybe on draft-oiwa-http-mutualauth, and will support >>> session continuation. >>> >>> Seems to me this would be a much better use of our time, as well as >>> implementors' energy. >>> >>> Thanks, >>> Yaron >>> >>> ______________________________**_________________ >>> http-auth mailing list >>> http-auth@ietf.org >>> https://www.ietf.org/mailman/**listinfo/http-auth >>> >> --20cf303b4291538df304e2281edb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Yaron,

SIP is deployed over UDP, TCP= , and TLS.
Both types of deployments, human-memorable & machi= ne-generated passwords, are widely used.

Regards,<= br>
=A0Rifaat

<= br>
On Mon, Jul 22, 2013 at 5:28 PM, Yaron Sh= effer <yaronf.ietf@gmail.com> wrote:
Hi Rifaat,

responding only to the first of your objections:

I am really worried if Digest (presumably not over TLS) is the standard aut= hentication method in SIP. A few questions:

- Do people normally use it with a human-memorable password? If they do, th= en the dictionary attack vulnerability is IMO much more serious than contin= uing to use MD5, and would remain serious after we upgrade Digest.

- On the other hand, if people use Digest with computer-generated authentic= ation strings, then I18N is probably unnecessary.

- Looking at RFC 3665, it seems to me SIP Register can accommodate a two ro= und-trip authentication method, just as well as HTTP can.

Thanks,
=A0 =A0 =A0 =A0 Yaron


On 2013-07-22 13:51, Rifaat Shekh-Yusef wrote:
I do not like the idea of canceling the Digest work for the following reaso= ns:

1. Digest is used with SIP protocol, and I am not sure the widely used Dige= st mechanism in SIP networks will be replaced with any if the new proposals= .

2. This was already discussed during the discussion on the charter, and it = seems a bit late to reopen that right now.

3. I think that the adopters of the new mechanisms should be motivated by t= he merit of the new mechanisms, not by us not updating Digest.

4. Some of the adopters of Digest might be satisfied with the Digest as it = fulfills their need, and might not be interested in a "better" so= lution for their network.

To address the timeline point that Stephen has raised, I think that the agi= lity work should be done fairly soon as I do not see any major challenges a= t this stage.

Regards,
=A0 Rifaat

Sent from my iPhone

On 2013-07-22, at 12:16 PM, Yoav Nir <ynir@checkpoint.com> wrote:

I'm not totally opposed, but if we replace Digest with some ZKPP, it= 9;s not Digest any more.

Two of our experimental drafts are "better digests" - MutualAuth = and SCRAM. MutualAuth is mature, has implementations, and I don't see w= hy it shouldn't be ready to progress almost as fast as Digest.

Do you think that enterprises would require "Digest" rather than = "MutualAuth" or "SCRAM" just because it's called &q= uot;Digest"?

Hopefully these new methods will also support international user names and = passwords (because specifying a user authentication method is 2013 that doe= s not support non-English names is even sillier than specifying one that re= lies on MD5 for security). Then it's up to the enterprises to decide wh= at they want to require vendors to implement.

Yoav

-----Original Message-----
From: http-= auth-bounces@ietf.org [mailto:http-auth-bounces@ietf.org] On Behalf Of = Yaron Sheffer
Sent: Saturday, July 20, 2013 7:34 PM
To: HTTP Auth WG
Subject: [http-auth] Why update Digest Auth?

Sorry for questioning the group's charter, but this keeps bugging me:
I'm assuming this WG will publish two Standards Track RFCs, updating Ba= sic and Digest Auth. And a pile of Experimental RFCs with all sorts of love= ly state-of-the-art crypto.

Enterprises will require vendors to implement the updated Basic and Digest,= and in a few years' time we will end up with the worlds'
browsers and Web servers supporting Basic and Digest Auth with I18N and (fo= r Digest) crypto agility. Almost nobody will implement the other drafts.
In addition, the websec WG will hopefully work on "session continuatio= n", which will extend the authentication to the whole session in a bet= ter way than cookies, and will provide channel binding. Assuming much of th= e Internet's traffic will remain unencrypted for years, this will be &q= uot;good enough" security for this traffic. But, it won't work wit= h Digest (because it is not "key generating", to borrow an EAP te= rm).

Now my question: we are telling implementors to upgrade Digest to gain I18N= (and the algorithm agility, which in this case is mostly security theater,= because when using short passwords we remain vulnerable to a dictionary at= tack anyway). Why not tell them *instead* to move to Digest-v2, which is di= ctionary attack resistant? Digest-v2 could be based on EKE or SRP, or maybe= on draft-oiwa-http-mutualauth, and will support session continuation.

Seems to me this would be a much better use of our time, as well as impleme= ntors' energy.

Thanks,
=A0 =A0 =A0Yaron

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

--20cf303b4291538df304e2281edb-- From yaronf.ietf@gmail.com Thu Jul 25 23:25:33 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 540E511E80DC for ; Thu, 25 Jul 2013 23:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dl3Y9SNFUFTJ for ; Thu, 25 Jul 2013 23:25:33 -0700 (PDT) Received: from mail-ee0-x235.google.com (mail-ee0-x235.google.com [IPv6:2a00:1450:4013:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id DB69C11E80C5 for ; Thu, 25 Jul 2013 23:25:32 -0700 (PDT) Received: by mail-ee0-f53.google.com with SMTP id e53so1371607eek.12 for ; Thu, 25 Jul 2013 23:25:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=bXM4QJQyDmllTAwDiBVTvkKZFuQIx4xw+f84602Fr2Y=; b=jVZT8CpT2sw+9aiUw+fKu8XNDGA8JpfabDxfZ3M3nS16as0z3KwIPNOaQy7nNhOOfV JvqIYdAr/myha+UaQyQjC3B28nL1TTBPoNdVZvg57JqsUWHGaMmNj9sO6bFNtT4qqyJx Jfz0+/hgYmj1Bdg3MWA1XaZhazkIpWnv7ZAdLeAzN7Cycmt9+ae0ljiLh4Jz9heKLHJH s9CxQ96uteDZVJe8PR43CF4QiB20U2l0ud703ltjK2KxDkAzCmJx3lXabZtoVjka8K74 wQfUhBFAt7z7r+OPIO5epzpvUFC/Vn1vpCIJGsSgFacjT8dje8XiGTzNRCMsUEqStMdr 2Avg== X-Received: by 10.15.32.194 with SMTP id a42mr46321677eev.43.1374819930759; Thu, 25 Jul 2013 23:25:30 -0700 (PDT) Received: from [192.168.2.103] (dslb-094-222-009-225.pools.arcor-ip.net. [94.222.9.225]) by mx.google.com with ESMTPSA id n42sm78736155eeh.15.2013.07.25.23.25.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Jul 2013 23:25:30 -0700 (PDT) Message-ID: <51F21654.1050205@gmail.com> Date: Fri, 26 Jul 2013 08:25:24 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: "http-auth@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [http-auth] Comments on draft-ietf-httpauth-hoba-01 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 06:25:33 -0000 Thank you for publishing this protocol. I enjoyed especially the implementation hints, and the protocol parts (registration etc.) that go beyond plain authentication. - You mention that the credentials are not susceptible to phishing . But the protocol doesn't do mutual authentication. So the *user* is in fact susceptible, but of course the attacker will not be able to steal the user's credentials. - TBS string: I suggest that this string should have separators between scheme, hostname and port. Otherwise you different URLs will map into the same signature. - 3: " to prevent replay attacks from passive observers" - sounds strange to me. I thought replay attacks were always active. - General comment: in between memorizable passwords and public keys, there are (per-server) crypto-strength PSK. HOBA could be built around long PSKs with little change, and it's not clear which would have been better. Public keys are probably more secure during the registration phase. But PSK provide mutual authentication which I think adds significant security. - 5.5: please also add a nonce based method. Time sync is easy nowadays. The replay cache is a hassle and people might decide to skip it. - 5.6: the example is not validly URL encoded, because of the "@" character. - Similarly when you say that a string is base64 encoded, it should be encoded with a URL-safe variant of base64, or the resulting base64 should be URL encoded. - In general, the examples hint at consumer use cases (get an SMS and you're in). I would like to also see enterprise cases, where e.g. an admin must approve your registration. - Privacy: an easy way around it is to allow the client to change its CPK whenever it feels like it. - 8.1: the second part of the last paragraph is in general incorrect. An attacker will get access to all of your local storage, which very likely will have your keys for *all* of the services you are using. So with respect to this attack vector, there is no difference from using passwords. Regards, Yaron From stephen.farrell@cs.tcd.ie Fri Jul 26 05:35:52 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B83C221F90C3 for ; Fri, 26 Jul 2013 05:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YiNJhChgPdwQ for ; Fri, 26 Jul 2013 05:35:48 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id C5ADB21F9371 for ; Fri, 26 Jul 2013 05:35:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id CCFEBBE68; Fri, 26 Jul 2013 13:35:12 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6wjIlmSRELeu; Fri, 26 Jul 2013 13:35:06 +0100 (IST) Received: from [160.45.233.17] (e9-11.conference.fu-berlin.de [160.45.233.17]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B1DE0BE60; Fri, 26 Jul 2013 13:35:06 +0100 (IST) Message-ID: <51F26CFA.1040108@cs.tcd.ie> Date: Fri, 26 Jul 2013 13:35:06 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Yaron Sheffer References: <51F21654.1050205@gmail.com> In-Reply-To: <51F21654.1050205@gmail.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Comments on draft-ietf-httpauth-hoba-01 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 12:35:52 -0000 Hi Yaron, Thanks for the review. On 07/26/2013 07:25 AM, Yaron Sheffer wrote: > Thank you for publishing this protocol. I enjoyed especially the > implementation hints, and the protocol parts (registration etc.) that go > beyond plain authentication. > > - You mention that the credentials are not susceptible to phishing . But > the protocol doesn't do mutual authentication. So the *user* is in fact > susceptible, but of course the attacker will not be able to steal the > user's credentials. Well, I guess it depends what you call phishing I suppose, but what we meant was that there's no way a user will ever be tricked into typing a HOBA private key. But you are right that we need more on the security considerations of HOBA for sure (text welcome!). > - TBS string: I suggest that this string should have separators between > scheme, hostname and port. Otherwise you different URLs will map into > the same signature. Paul and Mike asked me that too and I didn't have a good answer. That's just what I did in my code and even I couldn't remember why:-) So I suspect either I'll re-discover a reason why or else we'll add back the syntactic sugar. I don't see that different origins could be confused though, got an example? > - 3: " to prevent replay attacks from passive observers" - sounds > strange to me. I thought replay attacks were always active. Fair point. > - General comment: in between memorizable passwords and public keys, > there are (per-server) crypto-strength PSK. HOBA could be built around > long PSKs with little change, and it's not clear which would have been > better. Public keys are probably more secure during the registration > phase. But PSK provide mutual authentication which I think adds > significant security. IMO a PSK like beast would be sufficiently different that it ought be a different HTTP auth scheme. > - 5.5: please also add a nonce based method. Time sync is easy nowadays. > The replay cache is a hassle and people might decide to skip it. Reasonable point. As I said before we need to do a serious merger of the hoba-js and hoba-http text. > - 5.6: the example is not validly URL encoded, because of the "@" > character. Ack. > - Similarly when you say that a string is base64 encoded, it should be > encoded with a URL-safe variant of base64, or the resulting base64 > should be URL encoded. Ack. > - In general, the examples hint at consumer use cases (get an SMS and > you're in). I would like to also see enterprise cases, where e.g. an > admin must approve your registration. Text suggestions welcome I guess. OTOH, it might be better to keep away from enterprise related text since that always gets way too complicated. > - Privacy: an easy way around it is to allow the client to change its > CPK whenever it feels like it. Yep. Been thinking about that a bit. Given that you'd maybe need a newWithOld signature or something though it might not be that good for privacy, and it might be more complex than we want to take on for an experimental RFC. So not sure on that one. > - 8.1: the second part of the last paragraph is in general incorrect. An > attacker will get access to all of your local storage, which very likely > will have your keys for *all* of the services you are using. So with > respect to this attack vector, there is no difference from using passwords. Well, depends on the attacker model. I agree we need more text but there are attackers who'd still be constrained by the same origin policy and those'd only get the key for one origin. But yes, there are attackers who'd get all of localStorage and we need to say something about that. Cheers, S. PS: When we get around to shooting out a -02 I'll circle back and try say what we did related to the above, but feel free to offer text in the meantime, if you've time. And I guess we'll discuss this a bit in Berlin too. > > Regards, > Yaron > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > > From msweet@apple.com Fri Jul 26 06:43:43 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABFB921F8793 for ; Fri, 26 Jul 2013 06:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.414 X-Spam-Level: X-Spam-Status: No, score=-6.414 tagged_above=-999 required=5 tests=[AWL=4.185, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Dytp9KEIS1N for ; Fri, 26 Jul 2013 06:43:37 -0700 (PDT) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 51AA321F944C for ; Fri, 26 Jul 2013 06:43:37 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay4.apple.com ([17.128.113.87]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MQJ00ATKQ40GGF0@mail-out.apple.com> for http-auth@ietf.org; Fri, 26 Jul 2013 06:43:28 -0700 (PDT) X-AuditID: 11807157-b7f1a6d000003e11-9f-51f27cfdf074 Received: from [17.153.39.124] (Unknown_Domain [17.153.39.124]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay4.apple.com (Apple SCV relay) with SMTP id B5.A4.15889.EFC72F15; Fri, 26 Jul 2013 06:43:27 -0700 (PDT) From: Michael Sweet In-reply-to: <51F26CFA.1040108@cs.tcd.ie> Date: Fri, 26 Jul 2013 09:43:24 -0400 Message-id: <91023DDE-902C-4029-9AF4-E01CCF9A00D1@apple.com> References: <51F21654.1050205@gmail.com> <51F26CFA.1040108@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1786.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrILMWRmVeSWpSXmKPExsUiOFO9Rvd/zadAgw+/zS0+7J/DZHHkW6zF 9L3X2C1W3Z/B7sDisfXkDzaPtd1X2Tx2zrrL7rFkyU+mAJYoLpuU1JzMstQifbsEroyLnavZ C97xVFw7L97AuJSri5GTQ0LAROLpiTPMELaYxIV769m6GLk4hAR6mSTO9fSzgCSEBRwkXj1Z yNTFyMHBK2AgMeMgB0iYWUBL4sa/l0wgNpuAmsTvSX2sICWcApoSR7frg4RZBFQljs24xghR HiLx6vlsdghbW2LZwtdga3kFbCSuvD0G1iokUCfxs8MVJCwioC+xd/M5dojL5CVWPLrGNoGR fxbCDbOQ3DALydAFjMyrGAWKUnMSK030EgsKclL1kvNzNzGCArKhMHwH479lVocYBTgYlXh4 FZw+BgqxJpYVV+YeYpTgYFYS4b3u/SlQiDclsbIqtSg/vqg0J7X4EKM0B4uSOK9n5odAIYH0 xJLU7NTUgtQimCwTB6dUA6NRz7aSGMslW35aPFZY6xuWaBRvy8B6Mvbgwx2hC19EKr6+PiHt /u/8OY0fPi5Uuct0jXmGl5jlnO/Bz/oWTY7NqX43S+uOtMP+CVYhl7tFBOInyn5Zonvrj+g8 qcDdf2yurtStrZ3BsuPhUxGDpjvq3OqmF+/kCS0/yCj9Km0Rg134uQSlayZKLMUZiYZazEXF iQAksY+CRAIAAA== Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Comments on draft-ietf-httpauth-hoba-01 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 13:43:43 -0000 Stephen, On Jul 26, 2013, at 8:35 AM, Stephen Farrell wrote: > ... >> - In general, the examples hint at consumer use cases (get an SMS and >> you're in). I would like to also see enterprise cases, where e.g. an >> admin must approve your registration. > > Text suggestions welcome I guess. OTOH, it might be better to keep > away from enterprise related text since that always gets way too > complicated. I think it is enough to give examples of what the registration page might do or ask for and to define a low-level interface that supports multi-step registration. We don't need to do an exhaustive design of an enterprise registration scheme, we just need to allow for a (somewhat) long-lived registration process. And FWIW, I think even an enterprise use case where an admin approves the registration would still want a PIN or something as a final confirmation of the client's (user's) identity. >> - Privacy: an easy way around it is to allow the client to change its >> CPK whenever it feels like it. > > Yep. Been thinking about that a bit. Given that you'd maybe need a > newWithOld signature or something though it might not be that good > for privacy, and it might be more complex than we want to take on > for an experimental RFC. So not sure on that one. >From the perspective of changing the CPK, seems like associate-start (to get the new CPK) and logout (to retire the old CPK) gets us there in the current draft. _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair From mike@mtcc.com Fri Jul 26 08:13:57 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F312B21F96A8 for ; Fri, 26 Jul 2013 08:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ut41nMd4nXcs for ; Fri, 26 Jul 2013 08:13:51 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id DC71D21F9970 for ; Fri, 26 Jul 2013 08:13:51 -0700 (PDT) Received: from michael-thomass-macbook.local (aric.mtcc.com [50.0.18.225] (may be forged)) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r6QFDmW1018239 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 26 Jul 2013 08:13:49 -0700 Message-ID: <51F29227.8080205@mtcc.com> Date: Fri, 26 Jul 2013 08:13:43 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: http-auth@ietf.org References: <51F21654.1050205@gmail.com> In-Reply-To: <51F21654.1050205@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1941; t=1374851630; x=1375715630; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[http-auth]=20Comments=20on=20draft-iet f-httpauth-hoba-01 |Sender:=20 |To:=20http-auth@ietf.org |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=u1HGdo8wkhw4LCORL3/cBHj9KvchrQCbCmXVHkZLHZs=; b=jZCkarKsWMYGuymDwaXqiMUIe7W5FB826J5s9Jjxxrilt1hs/ormVsjO3J VnX+dmTA3toYepZTiamVdTSKLezn8NQdgxKX6Xkh25RBh4i7q/hfxOOiOWoD cBe/IGldX2Y1GiB/nz2iZUNbDN1SbEsT2bC/6i81BlWI8hl/M5u3c=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Subject: Re: [http-auth] Comments on draft-ietf-httpauth-hoba-01 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 15:13:57 -0000 On 7/25/13 11:25 PM, Yaron Sheffer wrote: > - General comment: in between memorizable passwords and public keys, there are (per-server) crypto-strength PSK. HOBA could be built around long > PSKs with little change, and it's not clear which would have been better. Public keys are probably more secure during the registration phase. But > PSK provide mutual authentication which I think adds significant security. In fact for one of us (me), auto-generated psk's on the client side was the route that led to the general HOBA idea. What became apparent is that even though there was far less risk of the password sharing problem, the server was still carrying passwords in some form or another, and so it would still be at risk for attacks to get them (hashed or otherwise). I think that the larger win is not to get rid of passwords, per se, but to get rid of passwords (or psk's) on servers so that isn't a reason to target them specifically. True enough, random and site-different psk's get you most of the way, but it seems like just taking it to its logical conclusion of the server only having public information for credentials is a win too. As far as mutual auth, TLS is still our friend in many, many ways. > - 8.1: the second part of the last paragraph is in general incorrect. An attacker will get access to all of your local storage, which very likely > will have your keys for *all* of the services you are using. So with respect to this attack vector, there is no difference from using passwords. While I'm not convinced it's quite this dire, what we've concluded is that webcrypto is definitely the route we want to go when it makes its way into browsers. I wrote this: http://rip-van-webble.blogspot.com/2012/06/localstorage-secuity.html going over the attacks on localstorage that I could think of. Feel free to pick it apart because it obviously has implications far beyond HOBA :) Mike From mike@mtcc.com Fri Jul 26 08:23:38 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E88511E80FA for ; Fri, 26 Jul 2013 08:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3lGltdVQMdHo for ; Fri, 26 Jul 2013 08:23:33 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id A6DFC11E80F6 for ; Fri, 26 Jul 2013 08:23:28 -0700 (PDT) Received: from michael-thomass-macbook.local (aric.mtcc.com [50.0.18.225] (may be forged)) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r6QFNRvD021373 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 26 Jul 2013 08:23:27 -0700 Message-ID: <51F2946A.1060401@mtcc.com> Date: Fri, 26 Jul 2013 08:23:22 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: http-auth@ietf.org References: <51F21654.1050205@gmail.com> <51F26CFA.1040108@cs.tcd.ie> <91023DDE-902C-4029-9AF4-E01CCF9A00D1@apple.com> In-Reply-To: <91023DDE-902C-4029-9AF4-E01CCF9A00D1@apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1631; t=1374852207; x=1375716207; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[http-auth]=20Comments=20on=20draft-iet f-httpauth-hoba-01 |Sender:=20 |To:=20http-auth@ietf.org |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=dHiGtkXUkgYXGvN5rN+43oQjY7x+5zmscyiDANcndjY=; b=Ycr9mALYptpni5MfvQMjd9evMXVQZ5+7S4+VXOT1C0fypB16OtT1CcFFjG LyCm/1YkqAK+6Wsr4hBjLZjlUJFEEbXDWuTRrEf8tuUeG4HQwJuBfVkZwvxN GnNhjAQotlygIeAENjzGrQBvsx0gXLZYt9dOHmBThfZdZeT6VuVoM=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Subject: Re: [http-auth] Comments on draft-ietf-httpauth-hoba-01 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 15:23:38 -0000 On 7/26/13 6:43 AM, Michael Sweet wrote: > Stephen, > > On Jul 26, 2013, at 8:35 AM, Stephen Farrell wrote: >> ... >>> - In general, the examples hint at consumer use cases (get an SMS and >>> you're in). I would like to also see enterprise cases, where e.g. an >>> admin must approve your registration. >> Text suggestions welcome I guess. OTOH, it might be better to keep >> away from enterprise related text since that always gets way too >> complicated. > I think it is enough to give examples of what the registration page might do or ask for and to define a low-level interface that supports multi-step registration. We don't need to do an exhaustive design of an enterprise registration scheme, we just need to allow for a (somewhat) long-lived registration process. > > And FWIW, I think even an enterprise use case where an admin approves the registration would still want a PIN or something as a final confirmation of the client's (user's) identity. Right, this is why this is all non-normative text. In some use cases, the (re)enrollment may be extremely fussy, difficult and potentially manual. It's all the standard risk/useability tradeoff for which we're not really providing anything new. As far enterprise-y enrollment, maybe the right thing is to move this all into a non-normative appendix with several use cases clearly listed as examples? My intention with the hoba-js section was more to show how a particular use case could be achieved (ie, a standard consumer-y oriented web site which stores relatively uninteresting data from the hacker POV). Mike From mike@mtcc.com Fri Jul 26 10:19:55 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 469DD21F9AA2 for ; Fri, 26 Jul 2013 10:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gxtb1yHc9aQK for ; Fri, 26 Jul 2013 10:19:50 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 3603621F9A80 for ; Fri, 26 Jul 2013 10:19:50 -0700 (PDT) Received: from michael-thomass-macbook.local (aric.mtcc.com [50.0.18.225] (may be forged)) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r6QHJmbZ027681 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 26 Jul 2013 10:19:49 -0700 Message-ID: <51F2AFAF.4070706@mtcc.com> Date: Fri, 26 Jul 2013 10:19:43 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: http-auth@ietf.org References: <20130715210454.4387.51895.idtracker@ietfa.amsl.com> <51E4652E.2090301@cs.tcd.ie> <51E59686.70501@cs.tcd.ie> In-Reply-To: <51E59686.70501@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4754; t=1374859189; x=1375723189; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[http-auth]=20Comments=20on=20draft-iet f-httpauth-hoba-01 |Sender:=20 |To:=20http-auth@ietf.org |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=Mh+7+wkcDr3G+XhOkooHxs79NsaVl+87D3LTRWQ1y3c=; b=rj6YIYMO0mhJTGBMYpFQGFRgaD/aBdJjEreEjZ3xdqJctQntBXSxsc6nJB ubLGQ014lEqE95T8yuu1pSCVHbq5jVA8vQqVSnbN2wUsm3CU5tZY+qZe+R0H 88uHB2Jk53+d83UB0ySMQGByTur2klVSeo/rRYLNsD99FQWKmYNK8=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Subject: Re: [http-auth] Comments on draft-ietf-httpauth-hoba-01 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 17:19:55 -0000 On 7/16/13 11:52 AM, Stephen Farrell wrote: > Hi Michael, > > Thanks for the review. Comments below. > > I've put a version at [1] with the changes indicated below in > case that helps. Note that I've not confirmed that with Paul > and Mike, so we might need to revert some changes if I;ve > messed up:-) > > On 07/16/2013 03:34 PM, Michael Sweet wrote: >> All, >> >> Some (mostly editorial) comments on draft-ietf-httpauth-hoba-01: >> >> - Can we drop the "with all the negative attributes that come with password-based systems" from the end of the abstract? I don't think it adds anything to the description and might turn some people off from reading the rest of the (otherwise excellent) document. > Fair enough. I guess we can assume that readers know all the > many downsides of passwords, but yeah that probably doesn't > belong there. > >> - Section 1 >> - I don't think we need "If deployment of HOBA reduces the number of password entries in databases by any appreciable amount, then it would be worthwhile." > I've rephrased that to: > > "Deployment of HOBA can reduce the number > of, or eliminate password entries in databases, with potentially > significant security benefits." > >> - Reword: "As an HTTP authentication scheme, it WORKS in the current HTTP 1.0 and HTTP 1.1 authentication framework.", and don't talk about HTTP/2.0 unless there is something definitive to say. >> - Typo: "... using the same credentials that are USED by ..." >> - "The HTTP /Authentication/ specification [RFC2617] ..." - the HTTP spec doesn't define Basic and Digest, the separate Auth spec does... >> - The last sentence "Even though few large web sites" is a bit confusing; maybe something like "While few large web sites use Basic or Digest authentication, they still use authentication schemes based on server-side usernames and passwords." > Yeah that was clunky text;-) I've tried to fix it along the lines > you suggest. See what ya think. > >> - Section 3 >> - Can we add something here as a reminder that HOBA might be one of several listed (comma-delimited) mechanisms in the WWW-Authenticate header? > Good point. Added: > > "Note that the HOBA auth-scheme might not be the > only one that the server includes in a WWW-Authenticate." > >> - In a similar vein, I would love to see some more discussion of implementation/fallback strategies. Right now I see a lot of potential uses for this authentication scheme, but I could not deploy it widely/exclusively (e.g. for CUPS and in printers) until HOBA support was in all of the major browsers and print clients. > I guess that's non editorial:-) To date we've not seen browser > interest but I do hope that might change in future. If it helps, > you can implement HOBA-HTTP in JS also (my code does that) and > even though that's low assurance (as it depends on localStorage > until we get webcrypto) and is a bit clunky, ('cause it needs > XHR) I hope it'll provide a way to use this without having to > get all (or any) browsers on board. I'll be able to say more on > that after I get my code released, so would suggest we come > back to this as we build some experience. Sound ok? > >> - Section 4.2: >> - Status 403 is "Forbidden". Status 401 is "Unauthorized". Which is intended here? > Sorry - should be 403 Forbidden there I guess. Good catch. > >> - Section 6.1 >> - Here I think we need more discussion of what the UA and server do. From reading this section it sounds like the UA would redirect to the well-known URL to perform registration, but I don't see how the UA knows that registration was successful and the original request can be retried. > What I've done is have the register kick off a signup process > that's application driven and then next time the browser sees > a HOBA 401 for that origin, it just tries HOBA. (If someone's > interested in playing with that before I get the code released, > just drop me a note. I hoped to have the code released before > Berlin but time seems to be catching up with me;-) > > But I've not really done much of a signup process (I more-or-less > just take any good looking public key and return 200 OK). I guess > there could be issues if the user abandons the signup half way > through though. Maybe we need a /.well-known/hoba/regconfirm or > something - do you think having that signal the end of register > work ok? > Here's a question I have: can you combine 401 with Location: to achieve the effect you want? Or perhaps the server could do a Location: first which in turn does the 401 if needed? In general, I'd prefer not to have hard wired url's unless there truly isn't any other alternative. Mike From yaronf.ietf@gmail.com Sun Jul 28 00:50:10 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB0121F9D92 for ; Sun, 28 Jul 2013 00:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.595 X-Spam-Level: X-Spam-Status: No, score=-102.595 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eO+Z-JxEt056 for ; Sun, 28 Jul 2013 00:50:09 -0700 (PDT) Received: from mail-ee0-x235.google.com (mail-ee0-x235.google.com [IPv6:2a00:1450:4013:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 811A421F964C for ; Sun, 28 Jul 2013 00:50:08 -0700 (PDT) Received: by mail-ee0-f53.google.com with SMTP id b15so125211eek.26 for ; Sun, 28 Jul 2013 00:50:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=osbGrkyODSDF+qmA+R0pf6+5SpJYZS2INTB9RGlgo0A=; b=oRJWDT5x/76+0h7fvhtlESVghcjrxtn9Lm7BFlQnQXEG0hDlLSgarreSA4Y4Fo9v7F K0xWfdzWEEDGzxJmzwohtrpOWxlrd6dO5p7TK0Z7qvd1n+RCkDw8bu7L8InZmeqoyrbw IIGJ05OqXbebqnoh5e7pQefBLIRqYcVS56Yn+wwZTlqEX9kI1C/bMg0g8g8yL9Qc0PT7 f9DTDs3mq3Tx+oA+gOfNH/dug4W2ZNr7oqEds3hcWqWhUtpsGgk7rIOn0wwi4Kc8sMn7 9HXOKULe+5YYaXaoD7xu1d+cvj+qwdOhpgEklQYQdFsOTChrOCGbWIy7Iy1XHcb0qiRW ID0Q== X-Received: by 10.14.184.4 with SMTP id r4mr54348302eem.100.1374997807592; Sun, 28 Jul 2013 00:50:07 -0700 (PDT) Received: from [192.168.2.103] (dslb-094-222-009-225.pools.arcor-ip.net. [94.222.9.225]) by mx.google.com with ESMTPSA id c3sm93339652eev.3.2013.07.28.00.50.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 28 Jul 2013 00:50:07 -0700 (PDT) Message-ID: <51F4CD2E.1020201@gmail.com> Date: Sun, 28 Jul 2013 09:50:06 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Stephen Farrell References: <51F21654.1050205@gmail.com> <51F26CFA.1040108@cs.tcd.ie> In-Reply-To: <51F26CFA.1040108@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Comments on draft-ietf-httpauth-hoba-01 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 07:50:10 -0000 Hi Stephen, please see below. Thanks, Yaron On 2013-07-26 14:35, Stephen Farrell wrote: > > Hi Yaron, > > Thanks for the review. > > On 07/26/2013 07:25 AM, Yaron Sheffer wrote: >> Thank you for publishing this protocol. I enjoyed especially the >> implementation hints, and the protocol parts (registration etc.) that go >> beyond plain authentication. >> >> - You mention that the credentials are not susceptible to phishing . But >> the protocol doesn't do mutual authentication. So the *user* is in fact >> susceptible, but of course the attacker will not be able to steal the >> user's credentials. > > Well, I guess it depends what you call phishing I suppose, but what > we meant was that there's no way a user will ever be tricked into > typing a HOBA private key. But you are right that we need more on > the security considerations of HOBA for sure (text welcome!). > I believe the Ultimate Reference (wikipedia, what else) supports my definition. Anyway, how about: 8.2 Server Authentication HOBA is responsible for authenticating the web service client. This cannot present attacks by malicious hosts masquerading as the original server. Although such attackers will not be able to obtain the user's credentials, they may obtain other sensitive information. Therefore, HOBA MUST be used with strong server authentication. >> - TBS string: I suggest that this string should have separators between >> scheme, hostname and port. Otherwise you different URLs will map into >> the same signature. > > Paul and Mike asked me that too and I didn't have a good answer. > That's just what I did in my code and even I couldn't remember > why:-) > > So I suspect either I'll re-discover a reason why or else we'll > add back the syntactic sugar. > > I don't see that different origins could be confused though, got > an example? I suppose an easy one would be https://lot.org vs. http://slot.org. > >> - 3: " to prevent replay attacks from passive observers" - sounds >> strange to me. I thought replay attacks were always active. > > Fair point. > >> - General comment: in between memorizable passwords and public keys, >> there are (per-server) crypto-strength PSK. HOBA could be built around >> long PSKs with little change, and it's not clear which would have been >> better. Public keys are probably more secure during the registration >> phase. But PSK provide mutual authentication which I think adds >> significant security. > > IMO a PSK like beast would be sufficiently different that it ought > be a different HTTP auth scheme. > >> - 5.5: please also add a nonce based method. Time sync is easy nowadays. >> The replay cache is a hassle and people might decide to skip it. > > Reasonable point. As I said before we need to do a serious merger > of the hoba-js and hoba-http text. > >> - 5.6: the example is not validly URL encoded, because of the "@" >> character. > > Ack. > >> - Similarly when you say that a string is base64 encoded, it should be >> encoded with a URL-safe variant of base64, or the resulting base64 >> should be URL encoded. > > Ack. > >> - In general, the examples hint at consumer use cases (get an SMS and >> you're in). I would like to also see enterprise cases, where e.g. an >> admin must approve your registration. > > Text suggestions welcome I guess. OTOH, it might be better to keep > away from enterprise related text since that always gets way too > complicated. > >> - Privacy: an easy way around it is to allow the client to change its >> CPK whenever it feels like it. > > Yep. Been thinking about that a bit. Given that you'd maybe need a > newWithOld signature or something though it might not be that good > for privacy, and it might be more complex than we want to take on > for an experimental RFC. So not sure on that one. > >> - 8.1: the second part of the last paragraph is in general incorrect. An >> attacker will get access to all of your local storage, which very likely >> will have your keys for *all* of the services you are using. So with >> respect to this attack vector, there is no difference from using passwords. > > Well, depends on the attacker model. I agree we need more text but > there are attackers who'd still be constrained by the same origin > policy and those'd only get the key for one origin. But yes, there > are attackers who'd get all of localStorage and we need to say > something about that. I agree but please clarify the text in 8.1. > > Cheers, > S. > > PS: When we get around to shooting out a -02 I'll circle back and > try say what we did related to the above, but feel free to offer > text in the meantime, if you've time. And I guess we'll discuss this > a bit in Berlin too. > >> >> Regards, >> Yaron >> _______________________________________________ >> http-auth mailing list >> http-auth@ietf.org >> https://www.ietf.org/mailman/listinfo/http-auth >> >> From stephen.farrell@cs.tcd.ie Sun Jul 28 01:59:31 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60F8521F9D4C for ; Sun, 28 Jul 2013 01:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YSgz5cxcjTNN for ; Sun, 28 Jul 2013 01:59:27 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id D88B921F9D31 for ; Sun, 28 Jul 2013 01:59:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4FDA9BE4C; Sun, 28 Jul 2013 09:58:55 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBbLi4n2B6zL; Sun, 28 Jul 2013 09:58:53 +0100 (IST) Received: from [130.129.19.66] (dhcp-1342.meeting.ietf.org [130.129.19.66]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B2D92BE47; Sun, 28 Jul 2013 09:58:53 +0100 (IST) Message-ID: <51F4DD4E.3050807@cs.tcd.ie> Date: Sun, 28 Jul 2013 09:58:54 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Yaron Sheffer References: <51F21654.1050205@gmail.com> <51F26CFA.1040108@cs.tcd.ie> <51F4CD2E.1020201@gmail.com> In-Reply-To: <51F4CD2E.1020201@gmail.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Comments on draft-ietf-httpauth-hoba-01 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 08:59:31 -0000 Hi Yaron, On 07/28/2013 08:50 AM, Yaron Sheffer wrote: > Hi Stephen, > > please see below. > > Thanks, > Yaron > > On 2013-07-26 14:35, Stephen Farrell wrote: >> >> Hi Yaron, >> >> Thanks for the review. >> >> On 07/26/2013 07:25 AM, Yaron Sheffer wrote: >>> Thank you for publishing this protocol. I enjoyed especially the >>> implementation hints, and the protocol parts (registration etc.) that go >>> beyond plain authentication. >>> >>> - You mention that the credentials are not susceptible to phishing . But >>> the protocol doesn't do mutual authentication. So the *user* is in fact >>> susceptible, but of course the attacker will not be able to steal the >>> user's credentials. >> >> Well, I guess it depends what you call phishing I suppose, but what >> we meant was that there's no way a user will ever be tricked into >> typing a HOBA private key. But you are right that we need more on >> the security considerations of HOBA for sure (text welcome!). >> > I believe the Ultimate Reference (wikipedia, what else) supports my > definition. Anyway, how about: > > 8.2 Server Authentication > > HOBA is responsible for authenticating the web service client. This > cannot present attacks by malicious hosts masquerading as the original > server. Although such attackers will not be able to obtain the user's > credentials, they may obtain other sensitive information. Therefore, > HOBA MUST be used with strong server authentication. I like that basically though I think s/MUST/SHOULD/ would be better. I would however like the "MUST" if all httpauth documents incl Basic go for "MUST run over TLS" which I'd be fine with. Maybe that'd be a good topic for this week? > >>> - TBS string: I suggest that this string should have separators between >>> scheme, hostname and port. Otherwise you different URLs will map into >>> the same signature. >> >> Paul and Mike asked me that too and I didn't have a good answer. >> That's just what I did in my code and even I couldn't remember >> why:-) >> >> So I suspect either I'll re-discover a reason why or else we'll >> add back the syntactic sugar. >> >> I don't see that different origins could be confused though, got >> an example? > > I suppose an easy one would be https://lot.org vs. http://slot.org. Ouch. Yep, that's a straight "gotcha" :-) Will make that change. >>> - 3: " to prevent replay attacks from passive observers" - sounds >>> strange to me. I thought replay attacks were always active. >> >> Fair point. >> >>> - General comment: in between memorizable passwords and public keys, >>> there are (per-server) crypto-strength PSK. HOBA could be built around >>> long PSKs with little change, and it's not clear which would have been >>> better. Public keys are probably more secure during the registration >>> phase. But PSK provide mutual authentication which I think adds >>> significant security. >> >> IMO a PSK like beast would be sufficiently different that it ought >> be a different HTTP auth scheme. >> >>> - 5.5: please also add a nonce based method. Time sync is easy nowadays. >>> The replay cache is a hassle and people might decide to skip it. >> >> Reasonable point. As I said before we need to do a serious merger >> of the hoba-js and hoba-http text. >> >>> - 5.6: the example is not validly URL encoded, because of the "@" >>> character. >> >> Ack. >> >>> - Similarly when you say that a string is base64 encoded, it should be >>> encoded with a URL-safe variant of base64, or the resulting base64 >>> should be URL encoded. >> >> Ack. >> >>> - In general, the examples hint at consumer use cases (get an SMS and >>> you're in). I would like to also see enterprise cases, where e.g. an >>> admin must approve your registration. >> >> Text suggestions welcome I guess. OTOH, it might be better to keep >> away from enterprise related text since that always gets way too >> complicated. >> >>> - Privacy: an easy way around it is to allow the client to change its >>> CPK whenever it feels like it. >> >> Yep. Been thinking about that a bit. Given that you'd maybe need a >> newWithOld signature or something though it might not be that good >> for privacy, and it might be more complex than we want to take on >> for an experimental RFC. So not sure on that one. >> >>> - 8.1: the second part of the last paragraph is in general incorrect. An >>> attacker will get access to all of your local storage, which very likely >>> will have your keys for *all* of the services you are using. So with >>> respect to this attack vector, there is no difference from using >>> passwords. >> >> Well, depends on the attacker model. I agree we need more text but >> there are attackers who'd still be constrained by the same origin >> policy and those'd only get the key for one origin. But yes, there >> are attackers who'd get all of localStorage and we need to say >> something about that. > > I agree but please clarify the text in 8.1. Will do, S. > >> >> Cheers, >> S. >> >> PS: When we get around to shooting out a -02 I'll circle back and >> try say what we did related to the above, but feel free to offer >> text in the meantime, if you've time. And I guess we'll discuss this >> a bit in Berlin too. >> >>> >>> Regards, >>> Yaron >>> _______________________________________________ >>> http-auth mailing list >>> http-auth@ietf.org >>> https://www.ietf.org/mailman/listinfo/http-auth >>> >>> > > From mike@mtcc.com Sun Jul 28 12:10:42 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57CD721F9E5E for ; Sun, 28 Jul 2013 12:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-OmA+L305Fu for ; Sun, 28 Jul 2013 12:10:35 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 97CB621F9E6D for ; Sun, 28 Jul 2013 12:10:18 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r6SJA5FU004759 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 28 Jul 2013 12:10:06 -0700 Message-ID: <51F56C8D.3020706@mtcc.com> Date: Sun, 28 Jul 2013 12:10:05 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Yaron Sheffer References: <51F21654.1050205@gmail.com> <51F26CFA.1040108@cs.tcd.ie> <51F4CD2E.1020201@gmail.com> In-Reply-To: <51F4CD2E.1020201@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=732; t=1375038607; x=1375902607; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[http-auth]=20Comments=20on=20draft-iet f-httpauth-hoba-01 |Sender:=20 |To:=20Yaron=20Sheffer=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=xAOqS6WJ5EoMWoK6ZIw0HW7v+CgYTrlx6QByT3O2ZjY=; b=mgb/Ea1JEPpooQl8NqxYFAeFiUgqbaEfwxIwPUjwRxmVd7RRZuHw4LqpHu Coqktf3T+sJRZFPOPLsnTHycVVlY7XxXsErCpG7+rekjAiISrJQLAcU43Rjb P3otmUdWwMShITJn8EIogyM9kN5BqyeLUlDyTEz79z+hQ/+9S9M8Y=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Comments on draft-ietf-httpauth-hoba-01 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 19:10:42 -0000 On 07/28/2013 12:50 AM, Yaron Sheffer wrote: > > 8.2 Server Authentication > > HOBA is responsible for authenticating the web service client. This cannot present attacks by malicious hosts masquerading as the original server. Although such attackers will not be able to obtain the user's credentials, they may obtain other sensitive information. Therefore, HOBA MUST be used with strong server authentication. TLS is of course goodness, but I'm not sure whether there's anything intrinsic to HOBA that makes the situation worse. If there isn't is there really a reason to place a requirement that is just as applicable to password based auth? If there is, can you outline the attack and how it is unique to HOBA? Mike From mike@mtcc.com Sun Jul 28 12:22:03 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB48321F9C77 for ; Sun, 28 Jul 2013 12:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwWv4WfLxM-S for ; Sun, 28 Jul 2013 12:21:59 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 7A12C21F90FD for ; Sun, 28 Jul 2013 12:21:59 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r6SJLtkA008794 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 28 Jul 2013 12:21:55 -0700 Message-ID: <51F56F53.7030409@mtcc.com> Date: Sun, 28 Jul 2013 12:21:55 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Stephen Farrell References: <51F21654.1050205@gmail.com> <51F26CFA.1040108@cs.tcd.ie> <51F4CD2E.1020201@gmail.com> <51F4DD4E.3050807@cs.tcd.ie> In-Reply-To: <51F4DD4E.3050807@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=914; t=1375039315; x=1375903315; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[http-auth]=20Comments=20on=20draft-iet f-httpauth-hoba-01 |Sender:=20 |To:=20Stephen=20Farrell=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=R2PEuiU6zLz1nShmZPM50nYr/ectel1+6fr4AInhp2A=; b=meU2428V4qyk03v7zZUfGfVReOZqewYJYKrV5dxNrWmL0dj983XAKGA3wE 5/I+3vxo+PWp4VA5VnGdEI2b6OHuUIpbO6kST7pFTzXDQxGJmjRbFga0armj rAvf0cWcMUIbrooMmAQ17xM9x2Lx53AcE2RdeaRnmsCkTxGnm8fKo=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Comments on draft-ietf-httpauth-hoba-01 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 19:22:04 -0000 On 07/28/2013 01:58 AM, Stephen Farrell wrote: > > 8.2 Server Authentication > > HOBA is responsible for authenticating the web service client. This > cannot present attacks by malicious hosts masquerading as the original > server. Although such attackers will not be able to obtain the user's > credentials, they may obtain other sensitive information. Therefore, > HOBA MUST be used with strong server authentication. > I like that basically though I think s/MUST/SHOULD/ would be better. > > I would however like the "MUST" if all httpauth documents incl Basic > go for "MUST run over TLS" which I'd be fine with. Maybe that'd be > a good topic for this week? > The problem is that it's mostly an empty gesture: most credentials are carried in HTTP POST's completely outside of standardization's reach. If we really wanted to make a difference, we should deprecate the http scheme. Mike From ynir@checkpoint.com Sun Jul 28 13:57:32 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5CF21F9E45 for ; Sun, 28 Jul 2013 13:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.549 X-Spam-Level: X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJqPv7kiD3Qv for ; Sun, 28 Jul 2013 13:57:25 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0C221F9E39 for ; Sun, 28 Jul 2013 13:57:21 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r6SKvFPX025262; Sun, 28 Jul 2013 23:57:20 +0300 X-CheckPoint: {51F585AB-4-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.90]) by IL-EX10.ad.checkpoint.com ([169.254.2.105]) with mapi id 14.02.0342.003; Sun, 28 Jul 2013 23:57:15 +0300 From: Yoav Nir To: Michael Thomas Thread-Topic: [http-auth] Comments on draft-ietf-httpauth-hoba-01 Thread-Index: AQHOicj0xSk2Nc+2d0quG/ga6qlMRJl2xAQAgALERQCAABM5AIAArhKAgAAaoIA= Date: Sun, 28 Jul 2013 20:57:14 +0000 Message-ID: <9F974D65-D59F-4700-9C41-0D469D83E5AD@checkpoint.com> References: <51F21654.1050205@gmail.com> <51F26CFA.1040108@cs.tcd.ie> <51F4CD2E.1020201@gmail.com> <51F4DD4E.3050807@cs.tcd.ie> <51F56F53.7030409@mtcc.com> In-Reply-To: <51F56F53.7030409@mtcc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.25] x-kse-antivirus-interceptor-info: protection disabled x-cpdlp: 11b182bea9fcd4b329891b9f6014bed2bc0839ff27 Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Comments on draft-ietf-httpauth-hoba-01 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 20:57:32 -0000 On Jul 28, 2013, at 9:21 PM, Michael Thomas wrote: > On 07/28/2013 01:58 AM, Stephen Farrell wrote: >>=20 >> 8.2 Server Authentication >>=20 >> HOBA is responsible for authenticating the web service client. This >> cannot present attacks by malicious hosts masquerading as the original >> server. Although such attackers will not be able to obtain the user's >> credentials, they may obtain other sensitive information. Therefore, >> HOBA MUST be used with strong server authentication. >> I like that basically though I think s/MUST/SHOULD/ would be better. >>=20 >> I would however like the "MUST" if all httpauth documents incl Basic >> go for "MUST run over TLS" which I'd be fine with. Maybe that'd be >> a good topic for this week? >>=20 >=20 > The problem is that it's mostly an empty gesture: most credentials > are carried in HTTP POST's completely outside of standardization's > reach. If we really wanted to make a difference, we should deprecate > the http scheme. Hi It's fine for a particular draft to list issues with using the protocol ove= r a non-secure transport. It's even fine to say that a particular method MU= ST NOT be used on the Internet unless a secure transport is used.=20 However, deprecating HTTP is really, really outside the scope of this worki= ng group. I don't think any working group in any area could make such a sta= tement in an RFC without the IESG and probably the IAB weighing in. This wa= s considered ([1]) by the httpbis working group (which is a far more fittin= g home for such a discussion), and by IETF 84 it was clear ([2]) that there= was no consensus to make such a recommendation, even for HTTP/2.0. Before starting this working group, we all knew that credentials are carrie= d in POSTs, although I believe that they're mostly POSTs over HTTPS, os I d= on't see how deprecating HTTP (assuming the IETF has enough hubris to try d= ictating this to the world) would make a difference.=20 Yoav [1] http://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep/0251.html (= section 2.2, and then a lot of other mailing list posts for the next few we= eks). [2] http://www.ietf.org/proceedings/84/minutes/minutes-84-httpbis (look fo= r the string "mandatory TLS")= From mike@mtcc.com Sun Jul 28 14:08:12 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0C8D21F994C for ; Sun, 28 Jul 2013 14:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eM8z17ycRtH1 for ; Sun, 28 Jul 2013 14:08:06 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id CD22821F8EDF for ; Sun, 28 Jul 2013 14:08:05 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id r6SL7u56011644 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 28 Jul 2013 14:07:56 -0700 Message-ID: <51F5882C.5090205@mtcc.com> Date: Sun, 28 Jul 2013 14:07:56 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Yoav Nir References: <51F21654.1050205@gmail.com> <51F26CFA.1040108@cs.tcd.ie> <51F4CD2E.1020201@gmail.com> <51F4DD4E.3050807@cs.tcd.ie> <51F56F53.7030409@mtcc.com> <9F974D65-D59F-4700-9C41-0D469D83E5AD@checkpoint.com> In-Reply-To: <9F974D65-D59F-4700-9C41-0D469D83E5AD@checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2425; t=1375045676; x=1375909676; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[http-auth]=20Comments=20on=20draft-iet f-httpauth-hoba-01 |Sender:=20 |To:=20Yoav=20Nir=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=Z9e0mD+XUfts/qv0OIlRnu3hoo5M5ozfziUBoWyYB3M=; b=r5qLF5IXmURkc2bl6HymSAfwyyEvbnA7TX0N+/pRn7XIIiVDlw04MwgAqw 9t4npugId9F16GOnpc+5n1oG54BbMdBKk4hhEUU6LiwiP8Mhcg6CF3bbD2p+ 2DOxoJRS0fjgfSPvT5L4RJhgWsr1oETC2ZyPRRIEeTAtPPZRNGgj0=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Comments on draft-ietf-httpauth-hoba-01 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 21:08:12 -0000 On 07/28/2013 01:57 PM, Yoav Nir wrote: > On Jul 28, 2013, at 9:21 PM, Michael Thomas wrote: > >> On 07/28/2013 01:58 AM, Stephen Farrell wrote: >>> 8.2 Server Authentication >>> >>> HOBA is responsible for authenticating the web service client. This >>> cannot present attacks by malicious hosts masquerading as the original >>> server. Although such attackers will not be able to obtain the user's >>> credentials, they may obtain other sensitive information. Therefore, >>> HOBA MUST be used with strong server authentication. >>> I like that basically though I think s/MUST/SHOULD/ would be better. >>> >>> I would however like the "MUST" if all httpauth documents incl Basic >>> go for "MUST run over TLS" which I'd be fine with. Maybe that'd be >>> a good topic for this week? >>> >> The problem is that it's mostly an empty gesture: most credentials >> are carried in HTTP POST's completely outside of standardization's >> reach. If we really wanted to make a difference, we should deprecate >> the http scheme. > > Hi > > > > It's fine for a particular draft to list issues with using the protocol over a non-secure transport. It's even fine to say that a particular method MUST NOT be used on the Internet unless a secure transport is used. > > However, deprecating HTTP is really, really outside the scope of this working group. I don't think any working group in any area could make such a statement in an RFC without the IESG and probably the IAB weighing in. This was considered ([1]) by the httpbis working group (which is a far more fitting home for such a discussion), and by IETF 84 it was clear ([2]) that there was no consensus to make such a recommendation, even for HTTP/2.0. > > Before starting this working group, we all knew that credentials are carried in POSTs, although I believe that they're mostly POSTs over HTTPS, os I don't see how deprecating HTTP (assuming the IETF has enough hubris to try dictating this to the world) would make a difference. > > > That's rather my point though. The http scheme is the root of the problem here, not HOBA. At least as far as I can tell. We shouldn't be writing in MUST's for new protocols to use https just because we know that http has a lot of brokenness. It suggests that there *are* problems beyond the usual http ones, which is the wrong message. Mike