From y.oiwa@aist.go.jp Thu Oct 3 16:55:13 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9E1021F90A7 for ; Thu, 3 Oct 2013 16:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.75 X-Spam-Level: X-Spam-Status: No, score=-5.75 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] 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 qTWXxkgW8R2u for ; Thu, 3 Oct 2013 16:54:57 -0700 (PDT) Received: from na3sys010aog112.obsmtp.com (na3sys010aog112.obsmtp.com [74.125.245.92]) by ietfa.amsl.com (Postfix) with ESMTP id 0B82921E8085 for ; Thu, 3 Oct 2013 16:54:45 -0700 (PDT) Received: from mail-oa0-f47.google.com ([209.85.219.47]) (using TLSv1) by na3sys010aob112.postini.com ([74.125.244.12]) with SMTP ID DSNKUk4Dwzw//jiqGcJjOZlyhb8+i3UN1ZtF@postini.com; Thu, 03 Oct 2013 16:54:45 PDT Received: by mail-oa0-f47.google.com with SMTP id i1so3106885oag.20 for ; Thu, 03 Oct 2013 16:54:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:from:date:message-id:subject:to:content-type; bh=xsVr1M6X0CicLvFRzhVjcdxuLgETJEeNR44YGo6Osqc=; b=QNACZcl1fvWYVB/+vtHyueO8YrmlinoE+LCXu8e5+xtwaYDF24NWewFbE4zJjUHESq YPEvXdYscZYu56tvxZuRxlHrUFwrsy/9qF6OfBqRMDvup68WesQFOyFDtYGbghEAuRqf LX0jKN2g79p9CgmXBEZa0mBlLtrmStXfrMwpc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=xsVr1M6X0CicLvFRzhVjcdxuLgETJEeNR44YGo6Osqc=; b=lATgFC/Onb4WYU74AE5ShvQeKNBA3iNr/Se95vYL1jTFL5gU1QEORmKmCVoZGESpub 64IRwGlmNmIPo5tHBWxFmQ8ZE+jWDKQj+w5/sRaIxAyyOzB5D2ifqyWxp/9Eyz9bp7Su N83tGMLFXwkrtgjf6Njo6T38Ir9sFs0SuXbFejeVaPMcNHJNdKIKEHhKttNfnmDKSv79 Lhniax1d1L3Ypi2JYMODbSLcl1RUTHDHeCQgHMSkIfqaeGdTjC3/+gCLXcFWFzNoNEL5 4ixARraEYfp0fknFMqR+p2qONshEegWaXi5UVehHW9ICssltsQWVyVetXgIE1TLJFHPP v0Cg== X-Received: by 10.60.116.230 with SMTP id jz6mr17000290oeb.21.1380844483459; Thu, 03 Oct 2013 16:54:43 -0700 (PDT) X-Gm-Message-State: ALoCoQmN73sMCHYNNvXROVzfSHAiAt4BEV4g6icGm1up1FzoHJbBUTcBU4egiS6YLoxKQ5tOvdFptVebhdFwuDW/zmPI8wq2BorBL/ySPyT1XckdiIbT0hV393ILuaRGzuA6jsTNZOOx7Bvfg/UP1VTI6Z+j7z/VXA== X-Received: by 10.60.116.230 with SMTP id jz6mr17000265oeb.21.1380844483252; Thu, 03 Oct 2013 16:54:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.73.196 with HTTP; Thu, 3 Oct 2013 16:54:22 -0700 (PDT) From: Yutaka OIWA Date: Fri, 4 Oct 2013 08:54:22 +0900 Message-ID: To: "http-auth@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [http-auth] [Mutual] answers for FAQs (1) auth-domain and web-origin 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, 03 Oct 2013 23:55:13 -0000 Dear all reviewers and readers of http-auth, As an author of the Mutual drafts, I really thank all reviewers for useful comments. I quite appreciate these comments for further improvement of our drafts. I'm going to answer to each of these comments, but it seems that, before doing that, I need to make some answers for some "frequently asked questions". The first one is relation between our auth-domain and Web origin concept. Shortly answered, these two are quite different, if my understanding of "Web origin" correct (you mean as that in RFC 6454?) . Our auth-domain is instead quite similar to the Domain attribute of the Cookie mechanism (RFC 6265). The space established by the auth-domain and Cookie domain typically spans over multiple spaces established by Web origins. More precisely, auth-domain has three possible kinds of ranges (server-specific, host-specific, and domain-specific), and only the narrowest range is equivalent to a single Web origin. Intention of doing so is twofold: * Often Web services spans multiple sub-domains inside a single domain (typical examples are mail.google.com, drive.google.com, and so on), and domain-issued cookies is used as an authorization key. It is convenient to share a common password database for these use cases. * In these cases, it is quite easy to make an SSO-like behavior, provided that password information is well protected by protocol for accidental leakage. Digest authentication had somewhat similar concept (domain parameter allowed to contain fully-qualified URLs even within different web-origins). However, these are not implemented, and doing so may introduce quite unwanted security implications (leaking of password information which can directly be used for off-line dictionary attacks). We plugged these holes by restricting validity of credentials to specific limited Web spaces specified by the auth-domain parameter. The availability of SSO functionality in this mechanism is as same as those provided by a single cookie with "two-legged" implementation. Cookies are also used for three-legged, federated style of authentications and authorizations, such as OAuth, OpenID, SAML and many more. We currently do not have plan to provide any alternatives to these three-legged things (re-inventing the wheels), and we think our scheme should just provide a possible vehicle for initial user authentication for these existing schemes. -- 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 y.oiwa@aist.go.jp Thu Oct 3 16:55: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 4F38721E80A8 for ; Thu, 3 Oct 2013 16:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.75 X-Spam-Level: X-Spam-Status: No, score=-5.75 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] 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 oVpivqTv4-AI for ; Thu, 3 Oct 2013 16:55:33 -0700 (PDT) Received: from na3sys010aog104.obsmtp.com (na3sys010aog104.obsmtp.com [74.125.245.76]) by ietfa.amsl.com (Postfix) with ESMTP id ACC0421F8FDC for ; Thu, 3 Oct 2013 16:55:12 -0700 (PDT) Received: from mail-oa0-f51.google.com ([209.85.219.51]) (using TLSv1) by na3sys010aob104.postini.com ([74.125.244.12]) with SMTP ID DSNKUk4D1qcsr/zzmwqsg4riZq4JMZlSK6O/@postini.com; Thu, 03 Oct 2013 16:55:12 PDT Received: by mail-oa0-f51.google.com with SMTP id h16so3165880oag.10 for ; Thu, 03 Oct 2013 16:55:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:from:date:message-id:subject:to:content-type; bh=jQ77R3jVoIDdk3Jc0xomB/fuk5N2AXdAiEua2T5YJC4=; b=mc55v1oO2zv00lPKb1Ud2Qw+W7WrV9UNWhTM9DN9NZ+U2PaKBocC5M66j8MfIeUnJ6 b1jQI8fU/11XFEaBzPxM9FnEy9lpYgodmddbg5xpN620a9TYA96aO7oz+eDDcQKcipt6 ni4OhDzC6tn8+CBa2ov8cEgQ8G2UXDuhnL5Dg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=jQ77R3jVoIDdk3Jc0xomB/fuk5N2AXdAiEua2T5YJC4=; b=LWZDBwvVXrggMI5VNJEoO/IfZVk5f+ss8rnAUohL4yUmRVQzSizNO80qeZ/bDKMeCV QFFrS8Nsisu2x7bOhShALVbDwLjKhIyN0lXUPer6Gh75sPrhGtPCyyYTwK+RObP1uWbx ROMD7/DJuvICe3UGVvOqYr7tJB2l16V+MfQdAdvysyiRnsj7UVFalvkCUnWk5iOxZUeV bhRbhf0QLgFDgplLfv6przhyimrxieCiMJzEybLE2yB+MphlmBdg0evpvkh6SKP8cWqx BS4SREJ+yXQQr7eRTw8boQLDeaDwK/Co5nu4/JF8rERPFEibCRN8G6SKBS4HAUiBTrp5 v1yA== X-Gm-Message-State: ALoCoQld1URzMD/pP18q3F2BBPUWqdpQoUvv3Ou7C+6LHJPey2n21G/awm2J+TX/Z/y3o3b9J33hH4AE0jIqN+Rf6Zr+1FqEME23sRxLsUc2dr0ESALIy52REfxyPTLIN6wgqIZyE81izFOd18FYTkGdba0K15saFQ== X-Received: by 10.60.80.8 with SMTP id n8mr16518453oex.33.1380844502527; Thu, 03 Oct 2013 16:55:02 -0700 (PDT) X-Received: by 10.60.80.8 with SMTP id n8mr16518441oex.33.1380844502420; Thu, 03 Oct 2013 16:55:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.73.196 with HTTP; Thu, 3 Oct 2013 16:54:42 -0700 (PDT) From: Yutaka OIWA Date: Fri, 4 Oct 2013 08:54:42 +0900 Message-ID: To: "http-auth@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [http-auth] [Mutual] answers for FAQs (2) Methods for TLS channel bindings 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, 03 Oct 2013 23:55:46 -0000 Deal all, second commonly-asked questions to answer is about how the protocol bind itself with the underlying connection channels. Currently, a TLS channel binding mechanism has an RFC standard, and our scheme defined a separate mechanism in Section 7. We've listed this as an item for possible future consideration in Appendix A. I'll answer "why" doing so, and "what" I think we should do. * Why As the time of writing the first revision of our proposal, there was simply no such scheme defined as the standard. It was not a re-invented wheel, but acutually parallel-developed wheels. Of course, at that time there was no implementation support for the current standard, and things defined in the current standard (issued as an I-D which we noticed shortly after our design) really requires additional implementation code inside TLS libraries. We had no ways to implement that at that time. Our alternative design, on the contrary, was *able to be* implemented with existing TLS libraries at that time without modification. * What we should do I currently do not have enough information about the implementation status of the current standard mechanism. If you have any summary of that, I really appreciate it. That is the only reason that we're suspending technology migration. If we have enough support for that mechanism, I'm simply happy to migrate for the newer standard mechanism. * Why again (appendix: possible reasons for the design difference) Generally speaking, using a raw key as a binding material is often risky against information leakage. As a general vehicle for unrestricted applications, it seems infeasible to use it. I guess that is the reason why the current standard uses a TLS Finished message instead. However, if the implementation do not support the standard explicitly, the Finished message is a volatile thing which is generated on-demand during negotiation and then discarded (as it is not required anymore after that). After finished negotiation, we have absolutely no way for regenerating the Finished message for channel binding. That's why the current standard required explicit implementation support. On the contrary, the raw key is rather a permanent thing which is often kept until the TLS protocol really terminates. It was, and it is, available from the internal structure of many TLS libraries, or in some cases, even through debugging facilities implemented in the libraries. In our use cases, that raw key is always mixed and hashed with random numbers with larger entropy, so there is no direct risk for retrieving/guessing the raw key from eavesdropped traffics. That's why we chose this design in the past. -- 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 y.oiwa@aist.go.jp Thu Oct 3 16: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 B4DA321E8092 for ; Thu, 3 Oct 2013 16:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.75 X-Spam-Level: X-Spam-Status: No, score=-5.75 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] 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 n3Er8TvtbwDC for ; Thu, 3 Oct 2013 16:56:22 -0700 (PDT) Received: from na3sys010aog104.obsmtp.com (na3sys010aog104.obsmtp.com [74.125.245.76]) by ietfa.amsl.com (Postfix) with ESMTP id 4E62721E80A1 for ; Thu, 3 Oct 2013 16:55:58 -0700 (PDT) Received: from mail-oa0-f51.google.com ([209.85.219.51]) (using TLSv1) by na3sys010aob104.postini.com ([74.125.244.12]) with SMTP ID DSNKUk4EDgxsPORXMwKW/hd19aMyBkfXqaNp@postini.com; Thu, 03 Oct 2013 16:55:58 PDT Received: by mail-oa0-f51.google.com with SMTP id h16so3108535oag.24 for ; Thu, 03 Oct 2013 16:55:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:from:date:message-id:subject:to:content-type; bh=GU5Ke34yiF7cYXzKjsXXy374nFA0CpYdNxw73s04JYg=; b=mw2PdmqdgxBzZuMkYXYi76t6Yc4303iR9CuW3cNT+FSt4hdDoNV5SP+cHr45ygWVTy Bg3aDEfQ2G83MWbmthqjeFGfWeY4WwCy7xn21Sg6S6zs8JhHW3cshbTITC4x936i3ZQf mHhnYn1GwEHoLSuPYP9kARd346NoBJdOwhljU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=GU5Ke34yiF7cYXzKjsXXy374nFA0CpYdNxw73s04JYg=; b=IV2g1cXmpYIDTfknhHUiNcrvOvzJrFtJZbpoxI78gnUmXV12N89FA8sBLfQjY/l4el HmqE5tgZeNlMcF97D1dcyMk/IbSiY+oh1ZZu7Ox+XHt6Ad9n3iRNfWbh+FH+RmHLvy6D lpEr/IkY8goQtj7xLy0zGLbJfYusSJN5zZD8FmZSwgLLM5bp9yCmai0/RafTby13KoZb nhuHOxeQV+0rB1J/uiTj77pG6f7GAjI1pEMB6th5PVZ4NEvqvIYtQ/LOtNeNLr7e0XO1 ciWPNaS0q5PxJjSa255JFiqWsZmjxthV5BcplKrIeroqYGKu8XcdEVo6NAKYbv40LXiV oT0w== X-Gm-Message-State: ALoCoQk6W1BlwGvWPBfe0HvjEAjCSz784PI4CvdVmz39kTiGG/WbNAYebAQouyicM4uD1gdOvy9T0VafUgPvW7ceXVP7lnP1a0g/kUXpfESDiPPxrESAB+RzaWmQCnzu/tuLbL0RYazdKX0DVj38y7Ah35p3CYuVlQ== X-Received: by 10.60.63.116 with SMTP id f20mr16683428oes.29.1380844557900; Thu, 03 Oct 2013 16:55:57 -0700 (PDT) X-Received: by 10.60.63.116 with SMTP id f20mr16683413oes.29.1380844557784; Thu, 03 Oct 2013 16:55:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.73.196 with HTTP; Thu, 3 Oct 2013 16:55:37 -0700 (PDT) From: Yutaka OIWA Date: Fri, 4 Oct 2013 08:55:37 +0900 Message-ID: To: "http-auth@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [http-auth] [Mutual] answers for FAQs (3) list of pwd-hash and possible use for PBKDF2 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, 03 Oct 2013 23:56:39 -0000 Dear all, The third thing to answer is about pwd-hash list in Section 4.1. Our proposal have a pwd-hash parameter for additional hashing of passwords, and that have only choices from none, md5, digest-md5 and sha1. As reviewers guessed (and we also mentioned in Section 16.4), this facility is only for legacy migration of old password databases. We recommend, in Section 16.4, to use "none" setting as much as possible. We considered several PHP-based authentication implementation, as well as the existing Digest password database as migration targets. That's why we do not include SHA-256 and any other decent algorithms, simply because it is not used. Internally, we have another true layer of password hashing (with using user names as salts) in Section 11.2, function pi, which uses SHA-256 or SHA-512 (for schemes defined in -algo draft). If people think we do not need any support for such old-dated database, I'll simply drop the pwd-hash feature entirely. For this feature I do not have very strong opinion for keeping it. As a similar but independent topic, we consider introducing another into here. It seems to be a good idea to use PBKDF2 (RFC 2898) or similar functions for password hashing. It may greatly slow down the attack on the password database stolen from the server side. I need more opinions about (for or against) such computational (rather ad-hoc) hardening against off-line password cracking using server-leaked information. If doing so, I'll introduce it as a replacing "pi" function in Section 11.2, instead of as a choice for "ph" function in Section 4.1. However, we might be careful about that, in our scheme, the actual mechanism for hardening the attacks may slightly different from those expected by the design of those functions. In general use case, the leaked information is the output of PBKDF2, and the information which attackers want to acquire is the plain-text passwords. In our case, the leaked information is the PBKDF2 output further encrypted (hashed) with discrete-logarithm-based one-way function, and the attack target will be the output of PBKDF2, not the raw password. Of course, the most feasible way of such cracking is guessing the password, (the other is the exhaustive search on output space of PBKDF2 which is infeasible) so attackers will have to compute PBKDF2 so many times, as similar as the general use case scenario. -- 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 julian.reschke@gmx.de Sat Oct 5 02:01: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 3355421F9AFE for ; Sat, 5 Oct 2013 02:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.129 X-Spam-Level: X-Spam-Status: No, score=-103.129 tagged_above=-999 required=5 tests=[AWL=-2.490, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, 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 ptecqB1WNKgB for ; Sat, 5 Oct 2013 02:01:49 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 1FEFD21F9360 for ; Sat, 5 Oct 2013 02:01:42 -0700 (PDT) Received: from [192.168.2.117] ([93.217.102.233]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0M6730-1VlPze0Qh8-00y9o9 for ; Sat, 05 Oct 2013 11:01:36 +0200 Message-ID: <524FD569.9020103@gmx.de> Date: Sat, 05 Oct 2013 11:01:29 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Matthew Lepinski References: <523198DD.8010903@gmx.de> In-Reply-To: <523198DD.8010903@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:Bqd1XcugiaFE6zLIChkdwyv6FC9qO4UPQCNsC2gQieJrIJqIdIg ClfbgJzy3L+NRSSgsNg1ootQxvXUTVTc8JXJpjAvtDFT1HP+Fsf7F2ZgEeBWTw4EwAn8WwD jRV7wwZ9dGiDeIhad+hRHY4DmnlahCFSIDvIuf/nACHL5hXVPcDcblkCTHLEF/KluTiaw2R vgLk00zI7TNJPHpvOfWjg== Cc: http-auth@ietf.org Subject: Re: [http-auth] Unicode normalization, was: Draft Minutes Posted for IETF 87 HTTP-AUTH Session X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Oct 2013 09:01:53 -0000 On 2013-09-12 12:35, Julian Reschke wrote: > On 2013-08-21 21:22, Matthew Lepinski wrote: >> Draft minutes for the HTTP-AUTH session have been posted. >> >> They can be found at: >> http://www.ietf.org/proceedings/87/minutes/minutes-87-httpauth >> >> If you notice any omissions or other errors in the minutes, please let >> us know. >> ... > > OK, the minutes mention: > > "Unicode Normalization : Getting from what is typed in to Unicode code > points will require discussion" > > So how do we proceed from here? Any concrete proposals for what to say? It seems we don't know what to say then, right? How about: "Beware that differing Unicode normalization forms can cause interoperability problems. See [http://unicode.org/reports/tr15/]."? Best regards, Julian From msweet@apple.com Sat Oct 5 09:00: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 6527921F8F6D for ; Sat, 5 Oct 2013 09:00:26 -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 LkltGntE-6ti for ; Sat, 5 Oct 2013 09:00:18 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 9CBD321F8F9A for ; Sat, 5 Oct 2013 09:00:13 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII 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 <0MU700IOZDRDYJ12@mail-out.apple.com> for http-auth@ietf.org; Sat, 05 Oct 2013 09:00:07 -0700 (PDT) X-AuditID: 11807166-b7fe86d000004e30-b1-52503787bf4d Received: from koseret (koseret.apple.com [17.151.62.39]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay8.apple.com (Apple SCV relay) with SMTP id 8A.C4.20016.78730525; Sat, 05 Oct 2013 09:00:07 -0700 (PDT) Received: from [10.0.1.12] (208-96-65-222.eastlink.ca [208.96.65.222]) by koseret.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MU700EOTDS5ZK10@koseret.apple.com> for http-auth@ietf.org; Sat, 05 Oct 2013 09:00:07 -0700 (PDT) References: <523198DD.8010903@gmx.de> <524FD569.9020103@gmx.de> In-reply-to: <524FD569.9020103@gmx.de> Message-id: <7E9A8B3A-3C4D-4B86-A276-8CDD6F8EB47E@apple.com> X-Mailer: iPad Mail (11A465) From: Michael Sweet Date: Sat, 05 Oct 2013 12:00:04 -0400 To: Julian Reschke X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOLMWRmVeSWpSXmKPExsUiON1OXbfdPCDIoOU8v8WH/XOYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8eXab6aCJs6KjgnLWBoYd7F3MXJySAiYSOx8tpsNwhaTuHBv PZDNxSEk0MIkcX7iVXYIZz2TxMlXZ6GcDkaJpT82M4G08AqIS7w+OoURxOYUUJOY8u8hK4jN LKAlsX7ncSYIW1viybsLrBD1NhJrnz+EisdInHvXBXWGjETP7UPMIDYb0Jzfk/rA6oUFsiTe 9K8Fi7MIqEp0774HVi8CNP/2vb2MExgFZiE5YxaS1bOQrF7AyLyKUaAoNSex0kIvsaAgJ1Uv OT93EyMo+BoK03YwNi23OsQowMGoxMNrccYvSIg1say4MvcQowQHs5IIr8kP/yAh3pTEyqrU ovz4otKc1OJDjNIcLErivBqJPkFCAumJJanZqakFqUUwWSYOTqkGRpFUlZsKL1beSRfwv2Xr 7n4mLTBe9U/+zznLHk2w4rLPKt5tWaJetidwic0G+yDJmXdjteIaL/NVyBQaCEdEMZ4rO559 z3rhqn1rAwLDqn9qW67TS/c+aB117H9KyfHHX48t3cIpNO3k8WWHFi8PzJytfVYsQf+5nVGk tcCDvRb+avmNPVb3lViKMxINtZiLihMBggel8DoCAAA= Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Unicode normalization, was: Draft Minutes Posted for IETF 87 HTTP-AUTH Session X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Oct 2013 16:00:28 -0000 Reference RFC 5198 (network Unicode)? Sent from my iPad > On Oct 5, 2013, at 5:01 AM, Julian Reschke wrote: > >> On 2013-09-12 12:35, Julian Reschke wrote: >>> On 2013-08-21 21:22, Matthew Lepinski wrote: >>> Draft minutes for the HTTP-AUTH session have been posted. >>> >>> They can be found at: >>> http://www.ietf.org/proceedings/87/minutes/minutes-87-httpauth >>> >>> If you notice any omissions or other errors in the minutes, please let >>> us know. >>> ... >> >> OK, the minutes mention: >> >> "Unicode Normalization : Getting from what is typed in to Unicode code >> points will require discussion" >> >> So how do we proceed from here? Any concrete proposals for what to say? > > It seems we don't know what to say then, right? > > How about: "Beware that differing Unicode normalization forms can cause interoperability problems. See [http://unicode.org/reports/tr15/]."? > > > Best regards, Julian > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth From ynir@checkpoint.com Sat Oct 5 14:38: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 0E7C921F90FD for ; Sat, 5 Oct 2013 14:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 tagged_above=-999 required=5 tests=[AWL=0.399, 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 6dRMaryiHiIM for ; Sat, 5 Oct 2013 14:38:20 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 565A021F90CF for ; Sat, 5 Oct 2013 14:38:18 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r95LcHB4010674 for ; Sun, 6 Oct 2013 00:38:17 +0300 X-CheckPoint: {525086C9-6-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.92]) by DAG-EX10.ad.checkpoint.com ([169.254.3.173]) with mapi id 14.02.0347.000; Sun, 6 Oct 2013 00:38:15 +0300 From: Yoav Nir To: "http-auth@ietf.org" Thread-Topic: Virtual Interim on Tuesday Thread-Index: AQHOwhMysnX6rK9TRE+XGtFeC3Z+kg== Date: Sat, 5 Oct 2013 21:38:15 +0000 Message-ID: <1BABEDE6-B827-4923-8095-F0F6C479D3E8@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.138] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: multipart/alternative; boundary="_000_1BABEDE6B82749238095F0F6C479D3E8checkpointcom_" MIME-Version: 1.0 Subject: [http-auth] Virtual Interim on Tuesday 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, 05 Oct 2013 21:38:35 -0000 --_000_1BABEDE6B82749238095F0F6C479D3E8checkpointcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Reminder: The virtual interim meeting will be held on Tuesday, October 8th = at 1500 UTC. That's midnight Wednesday in Japan. Details of the call have b= een posted previously. So here's a few points to remember: * A virtual interim meeting is an IETF activity, so Note Well does appl= y * The call will be recorded. Minutes and a link to the audio file will = be posted to this list. * Participants are expected to have read the drafts in question as well= as the reviews already posted. There will not be a tutorial. We are going = to dive right in to the issues, so please be up to speed. * I have posted a few tracker issues based on the reviews. We may refer= to them during the meeting. See them here: http://trac.tools.ietf.org/wg/h= ttpauth/trac/query?status=3Dnew&component=3Dmutual * Hope to be talking to lots of you at the conf call. Matt & Yoav --_000_1BABEDE6B82749238095F0F6C479D3E8checkpointcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <5E7B143E89B5AC41B3B0460F8F533D38@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable Reminder: The virtual interim meeting will be held on = Tuesday, October 8th at 1500 UTC. That's midnight Wednesday in Japan. Detai= ls of the call have been posted previously.

So here's a few points to remember:
  • A virtual interim meeting is an IETF activity, so = Note Well does apply
  • The call will be r= ecorded. Minutes and a link to the audio file will be posted to this list.<= /font>
  • Participants are expected to have read = the drafts in question as well as the reviews already posted. There will not be a tutorial. We are going to dive right in t= o the issues, so please be up to speed.
  • I have posted a few tracker issues based on the reviews. We may refer to t= hem during the meeting. See them here: h= ttp://trac.tools.ietf.org/wg/httpauth/trac/query?status=3Dnew&component= =3Dmutual
  • Hope to be talking to lots of you at the conf call.
Matt & Yoav



--_000_1BABEDE6B82749238095F0F6C479D3E8checkpointcom_-- From y.oiwa@aist.go.jp Mon Oct 7 02:43: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 D317F21E81E7 for ; Mon, 7 Oct 2013 02:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.864 X-Spam-Level: X-Spam-Status: No, score=-5.864 tagged_above=-999 required=5 tests=[AWL=0.114, 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 4Vd-66x0o9CU for ; Mon, 7 Oct 2013 02:42:59 -0700 (PDT) Received: from na3sys010aog106.obsmtp.com (na3sys010aog106.obsmtp.com [74.125.245.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3C53621E81E4 for ; Mon, 7 Oct 2013 02:42:56 -0700 (PDT) Received: from mail-ve0-f174.google.com ([209.85.128.174]) (using TLSv1) by na3sys010aob106.postini.com ([74.125.244.12]) with SMTP ID DSNKUlKCH2a7/mdy8c3Ky9Mkcobm3QNJUpqa@postini.com; Mon, 07 Oct 2013 02:42:56 PDT Received: by mail-ve0-f174.google.com with SMTP id jy13so3483882veb.19 for ; Mon, 07 Oct 2013 02:42:55 -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=8zEqb7WgFhU7vZrg2JrCpAAZZt6iqnbkMXNAKLhUr8U=; b=Z11CiN2pDW3/OvdVh5LF63qESuMBtcoJNGYrAEgI/n2AHas0fwtPvuIr1pPueoFl3Z gboF8bxD2MshHsm/Ti1nDsf7L0+OlRCGQFOjDthcnlLcvkwHlPq16h7wVm7v12m8sxXD b7bmlfeUMBFS7SNM7bvlKyPBTVf90gDmnnmCY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=8zEqb7WgFhU7vZrg2JrCpAAZZt6iqnbkMXNAKLhUr8U=; b=Dc4BAaZE9xEPsN7inhAiZya7G0D4DI4ouyQlgcTm1uCUD50lbpEoe2V3+Uwdj19shu Hjsa5FMceUTHCvEQ7FBSBYTzj6uPuk9DK4/p2IeFnpm4Le+R5F53yAseTq+yzfCE5a1A 0WkMRcBRS1Qw22F3qX6DGeZWPVhGjgau7a73O+jZrCIi5qONRXROS8AEHVI7PCuM2IFa KQarRd94Z7prfSlT/AKTr8HsrFrcCtQ4yVh2bC8TSxETssGoUyWH8SPC4klQBhPG8wyT kRokcwXIf6r2ikgGa3yl6xPgtR8GRRwX/a25ceRcegrUSclifKmGwtTXlq0zSg6bhLZf RvUQ== X-Gm-Message-State: ALoCoQl1bxZA6lzTVH2SzuJjuLzEnb6F236R6nYoxHJxXUuopRIxYf5KtfKe6aTbDAroz0D2C5WZIe5ZBdIEk/N32zvsUXDcMR1Hufw6c7bbXJ7JuiwFlnEvGyKbhyakXiepI5V+75S0XlrzC+srnlZz2c/kgXp2kQ== X-Received: by 10.58.73.202 with SMTP id n10mr25782725vev.7.1381138975196; Mon, 07 Oct 2013 02:42:55 -0700 (PDT) X-Received: by 10.58.73.202 with SMTP id n10mr25782720vev.7.1381138975093; Mon, 07 Oct 2013 02:42:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.144.144 with HTTP; Mon, 7 Oct 2013 02:42:34 -0700 (PDT) In-Reply-To: <20130829164259.GA13460@LK-Perkele-VII> References: <20130829164259.GA13460@LK-Perkele-VII> From: Yutaka OIWA Date: Mon, 7 Oct 2013 18:42:34 +0900 Message-ID: To: Ilari Liusvaara Content-Type: text/plain; charset=ISO-8859-1 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Review of MutalAuth X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 09:43:06 -0000 Deal Ilari, Thank you very much for the detailed review. Here is the answers to your questions. 2013/8/30 Ilari Liusvaara : > Main mutualauth spec: > >> implementations for user authentication using HTML Forms and Web >> browser rendering engines. However, that method has many potential >> security weaknesses as same as the HTTP Basic authentication as it >> uses plaintext. Considering server-impersonations and existence of > I can't parse this... I can see it asserts that there is substantial > overlap of vulernabilties between forms and HTTP Basic (true). > > But, does it assert one has all the vulernabilies of the other > (superset), the same vulernabilties (equivalence) or just substantial > overlap? We do not have strong intention on asserting any subset-relation between two technologies here. In simple protocol-level-only discussion, HTML form authentication may have all vulnerabilities of Basic auth, but there are also some Web-level mitigations (such as personalized sign-in seal) which can only be done with HTML form authentication. >> still relying on the HTTPS for the integrity and secrecy of the HTTP >> payload. This protocol ensures users the integrity and secrecy of > Perhaps s/secrecy/confidentiality/g ? Thanks. Its clearer. >> All character strings outside ASCII character sets MUST be encoded >> using the UTF-8 encoding [RFC3629] for the ISO 10646-1 character set >> [ISO.10646-1.1993], without any leading BOM characters. Both peers > Why mention of ASCII? It is strict subset of UTF-8 anyway. I see. I noted "outside ASCII character sets" because there is currently a confusion around non-ASCII character encoding in HTML but not around ASCII characters. But you're correct: "outside ASCII character sets" is just technically redundant. >> base64-fixed-number = 1*( ALPHA / DIGIT / >> "-" / "." / "_" / "~" / "+" / "/" ) *"=" > > Err, mixing multiple Base64 variants? And what are "~" and "." > (couldn't find in linked RFC)? The only reason is that it is equivalent to "token68" syntax in httpbis-p7 (which had an original name b64token), whose parser may already be included in HTTP implementations. Solution is either to reduce it to strict base64, or to refer token68 in httpbis-p7, whichever seems appropriate. >> o For requests, the parameters "kc*" (where * stands for any decimal >> integers), and "vks" are mutually exclusive and any challenge >> MUST NOT contain two or more parameters among them. They MUST NOT >> contain any "ks*" and "vks" parameters. > The first "vks" is supposed to be "vkc"? You're correct. I'll fix it. >> version: (mandatory extensive-token) should be the token "-wg- >> draft00" in this specification. The behavior is >> undefined when other values are specified. > Add some note for RFC editor to replace the value (for the final RFC)? I'll do it. >> auth-domain: (non-mandatory string) specifies the authentication >> domain, the set of hosts for which the authentication >> credentials are valid. It MUST be one of the strings >> described in Section 5. If the value is omitted, it >> is assumed to be the "single-port" type domain in >> Section 5. > There is no "single-port" type in section 5. You mean single-server type? Yes. It was renamed in section 5 to single-server type. >> pwd-hash: (non-mandatory extensive-token) specifies the hash >> algorithm (hereafter referred to by ph) used for >> additionally hashing the password. The valid tokens >> are >> >> * none: ph(p) = p >> >> * md5: ph(p) = MD5(p) >> >> * digest-md5: ph(p) = MD5(username | ":" | realm | >> ":" | p), the same value as MD5(A1) for "MD5" >> algorithm in [RFC2617]. >> >> * sha1: ph(p) = SHA1(p) > None produces a octet string, whereas others produce integers. > Perhaps add some OCTETS() into right places. Thank you. I'll review again for all relevant things around hash co-domains. I remember I changed some definitions around hash co-domains in the past, and there seems to be inconsistencies remaining to be fixed. >> In the above specifications, every "scheme", "host", and "domain" >> MUST be in lower-case, and any internationalized domain names beyond >> the ASCII character set SHALL be represented in the way they are sent >> in the underlying HTTP protocol, represented in lower-case >> characters; i.e. these SHALL be in the form of the LDH labels in IDNA >> [RFC5890]. All "port"s MUST be in the shortest, unsigned, decimal >> number notation. Not obeying these requirements will cause failure >> of valid authentication attempts. > > What about when dealing with DNS-SD? That uses native UTF-8 on the wire > instead of Punycode. I have no idea how HTTP host names are represented Interesting indication here, and it seems to be an HTTP issue. I think that encoding Host: part in an IDN-way in HTTP is at least "de-facto" standard now, but do anyone know where it is defined? RFC 3986 defines percent-encoding of UTF-8 characters in the host part for uniform representation "independent of the underlying name resolution technology" but it also recommends to generate IDNA-encoded URIs. >> tls-key: TLS shared-key validation: The value v will be the >> octet string of the shared master secret negotiated in >> the underlying TLS (or SSL) connection. > > Any reason to deviate from tls-unique of RFC 5929 (Standards Track), which > uses latest finished message instead? I answered it separately as "an answer to FAQ". >> pi = H(VS(algorithm) | VS(auth-domain) | VS(realm) | VS(username) | >> VS(ph(password))). > > VS(ph(password))) is ill-defined if pwd-hash is not none, as it then > tries to apply VS to an integer. Output of ph will be an octet string (as I'll fix the issue above). >> existing sessions regardless of these statuses. One way to mitigate >> such attacks are that servers MAY have a number and a time limits for >> unverified pending key exchange requests (in the "wa received" >> status). > > "wa received"??? Correctly, it's "key exchanging" (I renamed this in the past, too.) Thank you, I'll fix it. > Auth extension: > >> The value of this parameter MUST be a string that contains an >> absolute URL location. If a given URL is not absolute, the clients >> MAY consider it a relative URL from the current location. > > Err... X MUST be Y, but if X is not Y... Is it better if I write "Senders MUST must send X as Y. Recipients MUST consider X as Z if it isn't Y"?. >> When the user requests to terminate an authentication period, if the >> client supports this parameter but the server response does not >> contain this parameter, the client's RECOMMENDED behavior is as >> follows: if the request corresponding to the current content was >> idempotent (e.g. GET), reload the page without the authentication >> credential. If the request was non-idempotent (e.g. POST), keep the >> current content as-is and simply forget the authentication status. >> The client SHOULD NOT replay a non-idempotent request without the >> user's explicit approval. > Should it replay PUT or DELETE (or LINK/UNLINK)? Those methods are > idempotent. Oh, interesting point, too. If there are any "interactive clients" which sends PUT/DELETE interactively, these should be excluded. Do you know better term other than just saying it a "GET" or "idempotent"? (note: XMLHTTP and WebDAV are not "interactive" in the scope of this document.) >> 7. IANA Considerations > > Optional-WWW-Authenticate registration? We may need it before the finalization. > Mutualauth algo: > > Is there a security analysis of (this version of) KAM3? In practicular, > considering various mathematical attacks and establishing a lower bound > on difficulty (e.g. Attack X is at least as hard as CDH on the group and > so on)? -- 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 y.oiwa@aist.go.jp Mon Oct 7 02:54: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 E503921E81E5 for ; Mon, 7 Oct 2013 02:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.892 X-Spam-Level: X-Spam-Status: No, score=-5.892 tagged_above=-999 required=5 tests=[AWL=0.085, 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 OJovrIhH1yQ4 for ; Mon, 7 Oct 2013 02:54:24 -0700 (PDT) Received: from na3sys010aog106.obsmtp.com (na3sys010aog106.obsmtp.com [74.125.245.80]) by ietfa.amsl.com (Postfix) with ESMTP id C350B21E81CD for ; Mon, 7 Oct 2013 02:54:21 -0700 (PDT) Received: from mail-vc0-f181.google.com ([209.85.220.181]) (using TLSv1) by na3sys010aob106.postini.com ([74.125.244.12]) with SMTP ID DSNKUlKEzbZ8zPwWodf99j4gTgs4bBfQDgaP@postini.com; Mon, 07 Oct 2013 02:54:21 PDT Received: by mail-vc0-f181.google.com with SMTP id hz10so2735145vcb.40 for ; Mon, 07 Oct 2013 02:54:20 -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=UGVJTHdWlDdVhSBka1lRCYuZA+RrZQRRFmQs9Yq1Yi8=; b=qv82JA0iZVIlo/+IgZ6Brawo8+WrQCXE1Fr4WshVT9qo3ZgDED5nYjw4RltImJsu19 8vrTvHm8msgGmgJCwEjqZscCUA0oHslMK2B64fyOYDaf80snWCVD+53tBpGVUDl4SfKv gt36/Cp5wfN5lo3YXzlQUMYzK6O1RhmGVh3sE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=UGVJTHdWlDdVhSBka1lRCYuZA+RrZQRRFmQs9Yq1Yi8=; b=bj6Rz0A3WSPvDre8eSGJBKzC+w2oZTQGMbGfq+4X5Yfu3ta3fMRjriF2OCEBGYAiyE fvFzwf2r4yz489V3Fso+wopshgCEMfPKRkoUJrki15YW885trt3qMD7xlvF6yT9fpWMc 5HVLE22aPI6IHwWQBsumRuBFCwaQVyM9QZq4dYPxOYDVfB3J4QpYFejegx8wEYyr4LSJ jLfzQISdiLYDIZZGG3BY5ooTU2f0nFf985W5OEmqubEOCjZPeFyIvBMwbTTgRN3a8cKl RTgN3yuc7yhUpJo4IINvRy+J/xOWLLUPtd4c1Og49nRXASfZ0snxS66mJjNpN4IMkqx0 N5mw== X-Gm-Message-State: ALoCoQlaxTxlGRLw7u+elXO7LVYDqOGDfjqltekCaz0C7FrTxEBJaaeRkKqewjDz+KuUFNp2LJZZOZt97zi17JIspFLu9hniNWCGr9gnC+tU0WZIXKjgnREYniVwL8wQiJlwN8eRxeztFutsfwHF8sNXuNMDhLauJg== X-Received: by 10.52.118.73 with SMTP id kk9mr21501408vdb.13.1381139660907; Mon, 07 Oct 2013 02:54:20 -0700 (PDT) X-Received: by 10.52.118.73 with SMTP id kk9mr21501397vdb.13.1381139660744; Mon, 07 Oct 2013 02:54:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.144.144 with HTTP; Mon, 7 Oct 2013 02:54:00 -0700 (PDT) In-Reply-To: <522353DF.4010702@cs.tcd.ie> References: <522353DF.4010702@cs.tcd.ie> From: Yutaka OIWA Date: Mon, 7 Oct 2013 18:54:00 +0900 Message-ID: To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] review of (most of) mutualauth X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 09:54:35 -0000 Dear Stephen, Really thank you for very detailed review. It seems quite helpful to me. 2013/9/1 Stephen Farrell : > (1) The IPR declaration on the earlier non-WG drafts > should be updated for this draft and/or the > "replaced-by" information needs to be updated. It is not > enough to include a section within the draft since that > may not be noticed at IETF LC time. And FWIW, I'd > personally guess that the existence of the IPR will be a > negative in terms of the probability that this gets > wider adoption. Thank you, I'll check the IPR status again. > (2) draft-oiwa-httpauth-mutual-algo needs to be at least > a normative ref and a wg draft as well. That draft > should get as much review as this one, however that's > done, since the whole thing depends on the security of > that draft. Its not possible to evaluate the security of > this draft without reviewing that one. (Which I've not > yet done since I'm not sure of its current status.) My personal plan is to ask this to be WG draft too, I'll ask it for WG. Another, alternative option is to merge two drafts. > (3) The draft has far too much sales-pitch and that > needs to be fixed. I fully understand why that text is > there and including it was appropriate when this draft > was facing a lonely uphill battle to become an RFC. But > that's no longer the case - now we have a WG all such > text ought be removed I wouldn't be surprised if this > takes more than one iteration to fix as there is a lot > of sales-pitch text. I note some but not all of these > in the detailed comments below. I completely agree that we do not need it anymore. I will greatly simplify the Section 1. > (4) The claim that this "prevents" phishing is not > justifiable - one can still mount phishing attacks on > any password based scheme, regardless of the protocol > used to transmit the password-derived authenticator. > (Including "common" in "prevents common phishing > attacks" does not make this ok.) > > (5) Following up from (4), it doesn't matter if the user > can detect the phish after the password has been > compromised - that's too late. I'd like to have a separation discussion here on (4) and (5), but I think it's better to have this discussion on another places, either as a technical report or a companion, not normative-intended (informational?) I-Ds. I understand that my claim for phishing protection has several assumptions including UIs and server operations, which I've failed to be well discussed within this document in the protocol specification style. > (6) I don't think "Mutual" is a good name for this HTTP > auth scheme - "mutual" describes a property of many > potential schemes and isn't really specific enough. > Note: This is a minor point, easily outweighed by any > substantive deployment and/or multiple implementations > (but not by one implementation). OK. One of my intention was that the core part of this document can become a common platform for implementing potential similar schemes which require two-way key sharing, with sharing large part of the implementation. > (7) I don't get how the HTTP server maintains state > between requests 3 and 6 in Figure 1. How does that > work? It seems counter to normal HTTP to me at least, > but then I don't know much about HTTP. Short answer is that it's the parameter "sid" in messages (4) and (6). It is somewhat similar to nonces in the Digest. In Digest, the nonce parameter serves both as the session management identifier and as the cryptographic parameter. In Mutual, these two functionalities have separated to two separate fields. More detailed specs are in the later sections of the draft. > (8) I would worry that attackers could exploit the > potential for playing about between messages 3 and 6 in > Figure 1. Do we have any papers or other reason to think > they cannot? Only the possibilities to play around, as far as I know, is to send many (3) requests to fill the server's session tables. This attack is common to all two-round trip (or more) authentications including the existing Digest scheme. (Of course, this is mentioned in the security consideration section.) > (9) 4.1: the choices for pwd-hash are outdated - do we > really want md5 and sha1 as choices in new protocols? > The comment applies even if these are not security > criticial - the only acceptable reason to have those IMO > would be to meet some legacy interop requirement which I > don't believe applies here. > (10) Defining an "authenticaion realm" concept that is > not the same as the standard web-origin seems like a > mistake. In particular, the wildcard concept, if it > differs from web-origin is a bad plan and if its the > same, then why not just use what exists already? Please refer to my answers to the common questions which was sepalately post. I summarized the answers to the above two questions. > (11) 5.1 talks about "path" parameters but those were > not mentioned in the earlier text in section 5. I don't > know how to intepret that. (I also find 5.1 quite > unclear.) For comment inside (...), I'll simply try to rewrite it more clearly. The path parameter mentioned is that in Section 4. > (12) Section 7 should really use TLS channel binding and > not re-invent that. In any case, code implementing this > might not have visibility inside the TLS library and so > should not require such layering violations. This is also a question which was raised from many peoples. I sent my answer separately, too. > (13) 7: Why just the server cert and not the entire cert > path? What about TLS raw public keys? What about DANE? Given that TLS negotiation is succeeded correctly, and that server certificate is verified in some way outside HTTP layer (regardless of the way of verification), what we need to be verified is just the public key (corresponding to a single secret key). We may need some mention for TLS raw public key used with draft-ietf-tls-oob-pubkey (referring corresponding TLS channel binding scheme). For DANE, I think we do not need any additional measure as far as TLSA in RFC6698 is used. I continue to answers to some of > nits/minor comments: as follows: > - abstract: getting the HTTP acronym correct here would > be good. (s/Transport/Transfer/) Could be this is due to > the same error having being made in the WG charter > earlier. Oops. Skipping many comments on introductions which I largely agree on, > - 1.2, I'd say its unwise to define new 2119-like terms, > so I'd drop the definition and uses of encouraged and > advised. I really have a problem here. Is there a good stylistic example of saying "something is better to do" without saying it a strong "SHOULD" requirement as in IETF document, but not "MAY" which is too weak as plain English. # I saw in the other place than IETF, # where normative SHALL and non-normative SHOULD # is considered differently. # My intention is like "SHOULD" in such conventions. > - 4.1, the "reason" responses seem a bit verbose - why > do you need to provide so much detail here and why isn't > HTTP status sufficient? HTTP status is not sufficient here for most of these (most of them are not distinguishable as HTTP statuses, but degenerating to 401 responses). I'd provided these for possible benefit for user-friendly clients. As just a simple protocol, significant ones are "stale" and others. > - 4.2 (and elsewhere), multiple version fields seems > like a bad plan As far as it is under changing draft status, including versions in all messages are ugly but required. Recipient servers will first look the scheme "Mutual", and then the "version" parameter, and then do the jobs. If we decide that future incompatible revision of this protocol should be named "Mutual2" (or something distinguishable in the scheme parameter), we may drop this parameter in the final version of this experimental document. My current proposal is to replace it to "1" in the final publication. > - 5: "SHOULD NOT automatically reuse" seems odd - when > would it be ok to do that? If never, then s/SHOULD NOT/ > MUST NOT/ would be right. MUST NOT may be appropriate in most cases. A very small reason to specify this as "SHOULD NOT" is for simple command-line-style clients which only receive user name and password without knowing which realm to apply to. > - 6: sessions being local to a "server" seems like an > odd thing to say - why can't servers load balance? If > this were to gain traction, that'd have to be changed. Hmm, the "server" here means the thing which seems to be a single server from the client side, as described as "(defined by scheme, host and port)". It is equivalent to the same "web-origin" as in RFC 6454. We may seek for a better replacement term here. What this phrase exactly means is somewhat like the following scenario: 1) The user accesses "https://login.example.com/" and authenticate with realm="R", path="/", auth-realm="*.example.com". A new shared-key session (only for key management) is created and a session ID "sid" is assigned. 2) The user accesses "https://login.example.com/welcome.html". The session established in 1) may be active, so the client may try using shared key associated with the session (short-cut method in Figure 2 (B-1).) 3) The user accesses "https://portal.example.com/". In this case, as this request points to the different origin, the client cannot use the same session as one in 1), and sends an unauthenticated request. However, if the portal server respond with 401 response with realm="R", path="/", auth-realm="*.example.com"., the credentials provided from the user in 1) is valid for this server and the client can automatically authenticate to this new server. -- 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 y.oiwa@aist.go.jp Mon Oct 7 03:11: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 9693D21E81DA for ; Mon, 7 Oct 2013 03:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.609 X-Spam-Level: X-Spam-Status: No, score=-5.609 tagged_above=-999 required=5 tests=[AWL=-0.232, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_56=0.6, 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 2jM0O3JUlV4a for ; Mon, 7 Oct 2013 03:11:05 -0700 (PDT) Received: from na3sys010aog112.obsmtp.com (na3sys010aog112.obsmtp.com [74.125.245.92]) by ietfa.amsl.com (Postfix) with ESMTP id E438621E81EF for ; Mon, 7 Oct 2013 03:11:03 -0700 (PDT) Received: from mail-ve0-f182.google.com ([209.85.128.182]) (using TLSv1) by na3sys010aob112.postini.com ([74.125.244.12]) with SMTP ID DSNKUlKItzKeQ3RTbObU78keGmWe/rbEnDkw@postini.com; Mon, 07 Oct 2013 03:11:03 PDT Received: by mail-ve0-f182.google.com with SMTP id oy12so3702368veb.13 for ; Mon, 07 Oct 2013 03:11:02 -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:content-transfer-encoding; bh=U+8K+WsahmyyixWX5GlRranB7BpynUyd0VxQBBRXBQA=; b=OmVnJmTbZcghqsT4RLpNQR8S8FYxE4fjuPS0HfmPqW+xvIrHIh9rtkBPnaPjgGEVae elKN15xilJtxxYmose13+aitDNMX31C2P7A1BrZjL8BGUQlQ2xgCBrPoB3hDCgbQUp+K XNpHxEwjalP3ysaL8pgEmiVQ8rqNSdF2eXmVo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=U+8K+WsahmyyixWX5GlRranB7BpynUyd0VxQBBRXBQA=; b=e8Rm4v3PnqAw55o3PmTBI3xZKTsGiGlAIQbVmIzSKSWBFG5iqrG+1upbTHmwuIB7BB WitMo/CPGxe4k7UO2ptRBApQn2lExtAZ7BzzNhGRMnz4WbeYYRQiNdYyWNzidGANo4o5 6lwjZT3kCQMZBJ5Vjok67cxgYvHQEKXNPYii34qFi6A6WxBZYQp1FdvZbbL84WO6+9a5 9wlK2hmZogp91ovXRuFnSvBoCxi6bSlIgTHjX7c10VmeellRtw7G26oBhcaGfEnQXtcf 21GaI9C0zhVXulH6JEaPg/4jc2ltyd1AoEakb/KpVXD8hxsHgzteMvDzfVdlNwgkawAX 8Reg== X-Gm-Message-State: ALoCoQkgXWiimrEjF/2v8rfWs9PQ7szy0ieMO2Nwscupi9BEAV6XAgfxoozZwlztLWNnDPbJpIlS+p5yjuHc3mxrqRk/3zgcpViIXaEC4/fxmdVwBcd5nrlIPouDrxFad/AHZOoqeRgldMrwnD1RoopyXjwy9R1vVA== X-Received: by 10.58.208.130 with SMTP id me2mr26020586vec.13.1381140662922; Mon, 07 Oct 2013 03:11:02 -0700 (PDT) X-Received: by 10.58.208.130 with SMTP id me2mr26020580vec.13.1381140662823; Mon, 07 Oct 2013 03:11:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.144.144 with HTTP; Mon, 7 Oct 2013 03:10:42 -0700 (PDT) In-Reply-To: <5246B784.1080801@gmail.com> References: <5246B784.1080801@gmail.com> From: Yutaka OIWA Date: Mon, 7 Oct 2013 19:10:42 +0900 Message-ID: To: Yaron Sheffer Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "" Subject: Re: [http-auth] Review of Mutual 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, 07 Oct 2013 10:11:11 -0000 Thank you Yaron, we really appreciate your review comments, which seems really insightful fo= r us to improving the drafts. 2013/9/28 Yaron Sheffer : > draft-ietf-httpauth-mutual-00 > =95 1.2: Treating the domain of hash functions as numbers (rather than oc= tet > strings) is very uncommon and confusing. I'm sorry there is some confusion (mistaken inconsistency in ph). I'd like to rewrite it to more consistent notation. One of my past reasons to using such convention is now not significant in the current drafts, so I will take the octet-string convention now. > =95 2.2: POP APOP - please add a reference Agreed. > =95 Server responds with 401 in case of password mismatch: is it within t= he > same session, or a new one? Response is (technically speaking) within the same session, however, it is impossible to use that session any more. A new request with new password will generate a new session. (as specified in Section 10, >> if the received vkc is incorrect, [...] >> If the session is in the "key exchanging" state, >> it SHOULD be changed to the "rejected" state; ) > =95 "This case should not happen" - but it might happen if there's a MITM > attacker. "[...] should not happen between a correctly-implemented server and a clien= t"... we may need to append it with "without any interventions (such as MITM attacks)". > =95 2.3: the server seldom knows whether the sid value is stale or a new = one > being tried by an attacker. Why not send a simple 401-INIT instead? As details specified in Section 10, in such cases, servers will simply send 401-STALE responses. You're correct that servers cannot know whether it is stale or being attacked, and it's OK to send 401-STALE in both cases. Distinction between 401-INIT and 401-STALE is important for correct behavior of the "valid" clients. > =95 Can the server send a hint to the client regarding the expected lifet= ime > of the sid? It's a good idea. > =95 This document appears to define a new "session continuation" mechanis= m, in > addition to mere authentication. My idea is much like nonces in Digest and a part of authentication mechanis= m. It is just a cache of shared keys for short-cut fast re-authentication. We hide this "session continuation"-like mechanism to the internal of authentication protocol, so that any servers and clients can simply discard any cached sessions, can introduce any arbitrary limits on session durations (which is sometimes critical for security management), regardless= of how long Web applications intend to retain user authentication sessions. Having two layers here is intentional design choise which has reasons. > =95 2.3: The 3 round trip case could be shortened if we allowed the clien= t to > piggyback a KEX-C1 on top of the VFY-C. If there's no way for the client = to > guess in advance if the session secret is stale, this optimization may be > valuable. Good point, but as generating KEX-C1 is time-consuming, I personally prefer sending a hint for time-based session durations, as you suggested ab= ove. > =95 3, last paragraph: how is the client expected to handle multiple > challenges? Are they each associated with a separate session? An so on. For multiple challenges contained in 401 responses (it happens for 401-INIT= ), clients can choose any of that for authentication trial. After that, a single session is bound to a single realm (i.e. single challe= nge). > =95 Why allow uppercase in hex digits, and then recommend not to use it? It's mostly my personal preference that sending messages should be canonifi= ed as much as possible, and recipients should be liberal as much as security is kept. For this specific case, it is not a strong requirement for security, so we may loosen it to any-case. > =95 And why allow so many characters in base64, instead of alpha+digits, = "+" > and "/"? It shares the grammer of "token68" in httpbis-p7, which was named "b64token= " when I wrote it. Possible fixes are to make it strict or to refer token68, which is appropriate? > =95 The version field should have an IANA registry. Recipients must rejec= t > unknown versions (and any other fields). Yes. > =95 pwd-hash: unclear (yet?) what this is for. Why not also support PBKDF= 2? It is only for (possible) legacy-migration of password databases, and if not required, we may omit it. Please refer my previous post named as answers to FAQs for more details. > =95 4.2: please specify that the 4 reflected parameters are mandatory. Technically, "algorithm", "auth-domain" and "realm" are defining the scope of each authentication scope (called authentication realms in Sec 5). We may rethink of algorithm and validation, however. > =95 4.3: the square of the max number of sessions is never going to be >8= 0 > bits, because of physical limitations (number of atoms in the universe > etc.). Good point :-) Each session roughly takes about 2^9 bytes of storage at least (two 2048-bit keys), and the world's largest storage is around a few hundled petabytes, around 2^59 according to Google search result. This means at extreme the number will not exceed 2^100, and most likely not beyond 2^80. Quite interesting :-) One point here is that we need to include all sessions which is generated, thought to be active in the client but cleared from the server storage into this number. Even in this case, 2^80 seems to be safe :-) However, at the same time, I do not to want to have the number 2^80 "walk alone" (as we say in Japanese) without background reasons. The number should always be associated with supporting reasons. How do you think? > =95 4.3: do we really have to support the RFC 2617 "domain" construction > (here, the "path" parameter)? Is it being used by implementations? "SHOULD" may be a bit too strong, but I strongly recommend to implement this for better performance using complex HTTP authentication from now on. > =95 5: aren't we reinventing the wheel here? How does this discussion rel= ate > to web origins (RFC 6454)? No. It's much like a domain parameter in the Cookie, which creates a set of multiple RFC6454-web origins. I also posted a separate answer for this, please let me refer it. > =95 6: the discussion of nonces sounds like it it always the client that > generates a nonce, and the server verifies it. But shouldn't we support t= he > other direction, too? Do you mean about HTTP/2.0 server push? :-) If HTTP/2.0 really goes to support server push of authenticated contents, we may extend the specification to support that. > =95 6, last paragraph: it is unclear how the protocol is supposed to work= if > everybody is using the value 2**32-1 for all messages, which is how I > understand the last sentence. Why not simply re-establish the session whe= n > the value overflows? What I mean is, if a some server sends a message containing 2^80 as a maximal allowed nonce, the client MUST NOT treat it as 0 (as 2^80 mod 2^32)= , but rather, client may freely treat it as one of 2^64-1, 2^63-1, 2^32-1, 2^31-1 or 10000 or 9999 or any other possible values which make sense. > =95 7: "tls-cert": this is the *server* certificate, right? I.e. neither = a > client cert nor a CA cert. It's server cert. > =95 7: why not use RFC 5705 to bind to the TLS session? Please refer my sepalately summarized answer for this, too. > =95 7: why do we disallow anonymous TLS (e.g. Anonymous DH) for Web brows= ers? > Actually Mutual Auth is a great solution when combined with ADH and chann= el > binding. Yes, but we need more complex requirement for secure handling of POST reque= sts. > =95 8: what do you mean by "non modal"? Oops, some editing error here (lacking reference for the other draft). It's a keyword value defined in the Auth-extension draft. > =95 8: the value of non-mandatory auth is not clear to me. I suggest to o= mit > it here and just give a pointer to the extension document. Yes, I mostly agree. A small nits exists around here, so I will rethink of this within the context about the extension document. (We have some situation where 401 and WWW-Authenticate should always be sent, instead of the extended Optional-WWW-Authentication.) > =95 9: in Step 14, please mention explicitly that a missing VK_s is fatal= . Thank you, I'll do it. > =95 9: I suggest to remove the "should display" paragraph and not recomme= nd UI > behavior. This can quickly deteriorate into an endless discussion about > "mixed" states (main page is authenticated but CSS is not). OK. I have a security model here (why mixed document is OK in this specific case), but I agree this is not the right place to fully discuss it. I'm thinking of an alternative way. > =95 9: for the 5xx exception, you should warn about displaying/using the > response body. > =95 Fig. 5: this is missing the arrow from Step 14 into "unauthenticated" > state. Thank you. > =95 10: IMHO management of invalid ("fake") session is an implementation > detail, and out of scope of this document. Hmm, however, disregarding this case seems to be critical vulnerability in the security community... If there is more simple way to write it, I'll seek for it. > =95 13: what is "m. m."? !? seems to be a typo, sorry. > =95 16.1: please clarify the explanation why a valid SSL certificate is > required for security of this protocol. I think this question is orthogon= al > to cross-site scripting. Simple answer to this is, this protocol can protect some existing origin sc= ope (authenticating a single content inside a protected domain will ensure that the whole content is (in some way) trustful), however, if there is a mixed-content between Mutual-protected and non-authenticated contents in the unauthenticated TLS server, Mutual itself cannot establish a secure scope. > =95 16.3, last bullet: salting the password with the user name is much be= tter > than plain hashing of the password. Yes. In this text, J(pi) and pi (and ph when the hash is digest-md5) are salted with the user name. > =95 16: the security considerations should mention that the protocol is s= till > vulnerable to active password guessing attacks, and so authentication > attempts should be rate limited. Thank you. > draft-oiwa-httpauth-mutual-algo-00 > =95 Appendix A: there are good reasons to use already existing MODP group= s. > Can we do that? Parameters in Appendix A (Informative) is just copies of existing groups in RFC3526. We repeated this just because the original specification does not contain the value of r (mathematically derived from q and g). The value of r is a divisor of (q-1), and it is better to be as large as possible. The possible largest value is (q-1)/2, but not all possible prime q will have this value as r. If we want to use more other MODP groups, we may simply define a new algorithm name with a new parameter, with having respective value of r to be calculated. > =95 I think the document should define one method as "mandatory to implem= ent". OK. I prefer dl2048 in this case. > draft-ietf-httpauth-extension-00 > > =95 3: "The server is NOT RECOMMENDED to include" -> "It is NOT RECOMMEND= ED > for the server to include" (this is purely grammar, but it repeats many t= ime > throughout the documents.) Thnak you. > =95 4: Authentication-Control - this header should be associated with a > particular session rather than with an authentication scheme. I agree, and under RFC2617, we need (at least) to add "realm" here. > =95 4.2: If the parameter MUST be absolute, I don't understand why the > following sentence discusses what happens if it isn't absolute. Maybe I should rewrite to "servers MUST send ..." and "clients SHOULD treat ...". > =95 5: "A user interface which allows users to log out" implies something= in > the browser's chrome. Instead we should assume (and work on?) a JavaScrip= t > API to drive authentication. It's also interesting, I think. > =95 8: Any authentication token must be bound to an identity, and can als= o be > bound to a duration. So I don't understand why we only define a client-lo= cal > timeout feature, instead or requiring that any implementation of mutual a= uth > should include a timeout feature that's usable by both client and server. My design is: Servers can initiate logout by sending "Logout-timeout=3D0". Clients can always make a logout by simply forgetting a credential (and the Location-when-logout parameter is for better application-level UI behavior in this case). Only the case to be handled explicitly is about the termination of client-side stored session after that these peer have no communication for the idle time. (clearing server-side cache is not enough in HTTP authentication, because clients will simply re-authenticate itself to the server (think of Basic auth behavior).) More precise control can also be achieving by using Cookies or some other new session continuation mechanism with complex control on server side (implemented in all possible Web resources), and "Logout-timeou= t=3D0" parameter in this extension is also useful in this case for clearing client-side session from the server side. --=20 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 julian.reschke@gmx.de Mon Oct 7 05:38:25 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D34421E81E4 for ; Mon, 7 Oct 2013 05:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.639 X-Spam-Level: X-Spam-Status: No, score=-100.639 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, 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 uYbTKfgIqvEu for ; Mon, 7 Oct 2013 05:38:17 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 60E9321E81E9 for ; Mon, 7 Oct 2013 05:37:59 -0700 (PDT) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MaIPo-1VDp511zUO-00JtCo for ; Mon, 07 Oct 2013 14:37:55 +0200 Message-ID: <5252AB18.7090209@gmx.de> Date: Mon, 07 Oct 2013 14:37:44 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Michael Sweet References: <523198DD.8010903@gmx.de> <524FD569.9020103@gmx.de> <7E9A8B3A-3C4D-4B86-A276-8CDD6F8EB47E@apple.com> In-Reply-To: <7E9A8B3A-3C4D-4B86-A276-8CDD6F8EB47E@apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:/nQmhGEebR0E5aTJisQJd4LGjpVOgQvO2yYpIgMP8ysqpGjBdxb G4v1bm/D0RcdeecBTzJpN4MhgsNN8oDlD2zk23dlkxmgkFUwSBFgqMNLnfpHFOKYlMy3gJm Q/kiHup4155SjZMz9s4zcxoKyxkEGCCNeBiK9M/HV9fmHWbbR2S23skzeyTYYKankXP4rcU +aphpGYvNfY1RmoVTn29Q== Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Unicode normalization, was: Draft Minutes Posted for IETF 87 HTTP-AUTH Session X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 12:38:25 -0000 On 2013-10-05 18:00, Michael Sweet wrote: > Reference RFC 5198 (network Unicode)? > ... As "further reading", not actually resolving the issue, right? Best regards, Julian From internet-drafts@ietf.org Mon Oct 7 14:43: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 F0F4E11E817B; Mon, 7 Oct 2013 14:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.037, 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 laamJEmvoQOj; Mon, 7 Oct 2013 14:43:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7870C11E8171; Mon, 7 Oct 2013 14:43:51 -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.80.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131007214351.14968.61116.idtracker@ietfa.amsl.com> Date: Mon, 07 Oct 2013 14:43:51 -0700 Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-digest-00.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 21:43: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 Digest Access Authentication Author(s) : Rifaat Shekh-Yusef David Ahrens Filename : draft-ietf-httpauth-digest-00.txt Pages : 28 Date : 2013-10-07 Abstract: HTTP provides a simple challenge-response authentication mechanism that may be used by a server to challenge a client request and by a client to provide authentication information. This document defines the HTTP Digest Authentication scheme that may be used with the authentication mechanism. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-httpauth-digest-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rifaat.ietf@gmail.com Mon Oct 7 15:13: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 D2F7521E81BB for ; Mon, 7 Oct 2013 15:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 YUWxIcUFRb7P for ; Mon, 7 Oct 2013 15:13:55 -0700 (PDT) Received: from mail-qe0-x229.google.com (mail-qe0-x229.google.com [IPv6:2607:f8b0:400d:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id E536121E80C8 for ; Mon, 7 Oct 2013 15:13:54 -0700 (PDT) Received: by mail-qe0-f41.google.com with SMTP id 1so6002284qee.14 for ; Mon, 07 Oct 2013 15:13:54 -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=09oNG2Uzv8ZPAoT8+Roh0rJrb1h15ptSjtumoQ8Og3M=; b=CpLUlpin+wSSNLc0EYrJEsHJ0fS8de5wZNCTwO+pFnlwfhQQEgEgDeCx7T1sD5izZy F1+M0thP5sIj/1Hmdu7nfFEXT9GjHfDXUJU4seCGowKh6yiGuIocMm1P7/VK6/GGK7dU PY0epfFlOK2aadZL4pbRRl5WtvS8PT8EvRK1RSl1bAH8atKPXGaRsDZ/jqvXrErFQGD7 jTismQZyyRx9C+8qbiRiie3PPDmSWH+8mpnDkNjElJiAI9nxAO4ynONKnrvyXXUYQK/p /J+3Ccq0rDTcrlbFgbntJWRV6+RQOqym46A8K8MVvOf0Hn+oVOcnG/J8GL8o+6H2Qjv4 SBQA== MIME-Version: 1.0 X-Received: by 10.224.73.200 with SMTP id r8mr40227624qaj.72.1381184034299; Mon, 07 Oct 2013 15:13:54 -0700 (PDT) Received: by 10.49.16.105 with HTTP; Mon, 7 Oct 2013 15:13:54 -0700 (PDT) In-Reply-To: <20131007214351.14968.61116.idtracker@ietfa.amsl.com> References: <20131007214351.14968.61116.idtracker@ietfa.amsl.com> Date: Mon, 7 Oct 2013 18:13:54 -0400 Message-ID: From: Rifaat Shekh-Yusef To: "http-auth@ietf.org" Content-Type: multipart/alternative; boundary=001a11c3e420bbe63904e82df780 Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-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, 07 Oct 2013 22:13:55 -0000 --001a11c3e420bbe63904e82df780 Content-Type: text/plain; charset=ISO-8859-1 Hi, We have submitted an initial version for the HTTP Digest draft that would obsolete RFC2617. We have included most of the digest text from RFC2617, with the following changes: 1. Added Algorithm Agility support 2. Added I18N section 3. Included most of the Security Consideration text "as is" for now, with some new text based on the discussion we had during the work on the Digest Update draft. 4. Did not add the Sample Implementation section, as it is probably not needed by now. Please, take a look and let us know what you think. Regards, Rifaat On Mon, Oct 7, 2013 at 5:43 PM, 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 Access Authentication > Author(s) : Rifaat Shekh-Yusef > David Ahrens > Filename : draft-ietf-httpauth-digest-00.txt > Pages : 28 > Date : 2013-10-07 > > Abstract: > HTTP provides a simple challenge-response authentication mechanism > that may be used by a server to challenge a client request and by a > client to provide authentication information. This document defines > the HTTP Digest Authentication scheme that may be used with the > authentication mechanism. > > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-httpauth-digest-00 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > --001a11c3e420bbe63904e82df780 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

=
We have su= bmitted an initial version for the HTTP Digest draft that would obsolete RF= C2617.
We have included= most of the digest text from RFC2617, with the following changes:
1. Added Algorithm = Agility support
2. Added I18N se= ction
3. In= cluded most of the Security Consideration text "as is" for now, w= ith some new text based on the discussion we had during the work on the Dig= est Update draft.
4. Did not add t= he Sample Implementation section, as it is probably not needed by now.

Please, take a look and let us know what you think.

Regards,
=A0Rifaat


On Mon, Oct 7, 2013 at 5:43 PM, <internet-drafts@ietf.org<= /a>> 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 Access Authenticati= on
=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-00.txt=
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 28
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-10-07

Abstract:
=A0 =A0HTTP provides a simple challenge-response authentication mechanism =A0 =A0that may be used by a server to challenge a client request and by a<= br> =A0 =A0client to provide authentication information. This document defines<= br> =A0 =A0the HTTP Digest Authentication scheme that may be used with the
=A0 =A0authentication mechanism.




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

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

Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

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

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

--001a11c3e420bbe63904e82df780-- From ilari.liusvaara@elisanet.fi Mon Oct 7 23:15: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 8B65521E8145 for ; Mon, 7 Oct 2013 23:15:46 -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 GmNUC5HIqcGy for ; Mon, 7 Oct 2013 23:15:40 -0700 (PDT) Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) by ietfa.amsl.com (Postfix) with ESMTP id 9CAAF21E814A for ; Mon, 7 Oct 2013 23:15:39 -0700 (PDT) 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 0FE411A2661; Tue, 8 Oct 2013 09:15:37 +0300 (EEST) Date: Tue, 8 Oct 2013 09:15:37 +0300 From: Ilari Liusvaara To: Rifaat Shekh-Yusef Message-ID: <20131008061537.GA20723@LK-Perkele-VII> References: <20131007214351.14968.61116.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Ilari Liusvaara Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-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, 08 Oct 2013 06:15:46 -0000 On Mon, Oct 07, 2013 at 06:13:54PM -0400, Rifaat Shekh-Yusef wrote: > > We have submitted an initial version for the HTTP Digest draft that would > obsolete RFC2617. > > Please, take a look and let us know what you think. Section 3.4.2: A1 > 'If the "algorithm" directive's value is "MD5-sess", "SHA2-256", or > "SHA2-512-256", then[...]' Should this be: > 'If the "algorithm" directive's value is "MD5-sess", "SHA2-256-sess", or > "SHA2-512-256-sess", then[...]' ? -Ilari From rifaat.ietf@gmail.com Tue Oct 8 05:30: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 E8B1921E81DF for ; Tue, 8 Oct 2013 05:30:50 -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 4lDCYvy5xNMj for ; Tue, 8 Oct 2013 05:30:50 -0700 (PDT) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 6AEC821E81DE for ; Tue, 8 Oct 2013 05:30:50 -0700 (PDT) Received: by mail-qc0-f171.google.com with SMTP id x19so5953571qcw.30 for ; Tue, 08 Oct 2013 05:30:49 -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=trZOeAm4rSHegWtwhi8j7dBKrSAF11ASmglLnZizpE8=; b=UnyCwWD+UkV8KoP2dwmUAKf6YZbb6k4jEh+LOIgkx12gysbtAzfhiCPXZ3UVpt3be5 3wYszm1Fjobk8AS+6l2nE8x90XILThxt4KucXUxXbpoB30YUpjfBhpkbCZ/MydacEAar jrxw0UNsM46qvnOE+Tfto3xAkMZFC+MwZ1ASKu9/MXfhw77JIUrDPscI3XLlouiDZ9Bz Vx22E2eC6DTGpHchVGVYIFfyisi/QHb2QggN8az5UhPKEXYmhwx7sh1bKvoCfTEnxEkQ c+rOZ0nolCpNlYdbvrnpfKPdKAZ9ImaO030/R8Fs2qMhu2ZAxUinwRltc/cUvwRbE/Hx fcqA== MIME-Version: 1.0 X-Received: by 10.224.76.10 with SMTP id a10mr3389388qak.9.1381235449739; Tue, 08 Oct 2013 05:30:49 -0700 (PDT) Received: by 10.49.16.105 with HTTP; Tue, 8 Oct 2013 05:30:49 -0700 (PDT) In-Reply-To: <20131008061537.GA20723@LK-Perkele-VII> References: <20131007214351.14968.61116.idtracker@ietfa.amsl.com> <20131008061537.GA20723@LK-Perkele-VII> Date: Tue, 8 Oct 2013 08:30:49 -0400 Message-ID: From: Rifaat Shekh-Yusef To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a11c305a4553eda04e839f05a Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-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, 08 Oct 2013 12:30:51 -0000 --001a11c305a4553eda04e839f05a Content-Type: text/plain; charset=ISO-8859-1 Good catch Ilari, thanks. I will fix that. Regards, Rifaat On Tue, Oct 8, 2013 at 2:15 AM, Ilari Liusvaara wrote: > On Mon, Oct 07, 2013 at 06:13:54PM -0400, Rifaat Shekh-Yusef wrote: > > > > We have submitted an initial version for the HTTP Digest draft that would > > obsolete RFC2617. > > > > Please, take a look and let us know what you think. > > Section 3.4.2: A1 > > > 'If the "algorithm" directive's value is "MD5-sess", "SHA2-256", or > > "SHA2-512-256", then[...]' > > Should this be: > > > 'If the "algorithm" directive's value is "MD5-sess", "SHA2-256-sess", or > > "SHA2-512-256-sess", then[...]' > > ? > > -Ilari > --001a11c305a4553eda04e839f05a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Good catch Ilari, thanks. I will fix that.

<= div>Regards,
=A0Rifaat



On Tue, Oct 8, 2013 at 2:15 A= M, Ilari Liusvaara <ilari.liusvaara@elisanet.fi> w= rote:
On Mon, Oct 07, 2013 at 06= :13:54PM -0400, Rifaat Shekh-Yusef wrote:
>
> We have submitted an initial version for the HTTP Digest draft that wo= uld
> obsolete RFC2617.
>
> Please, take a look and let us know what you t= hink.

Section 3.4.2: A1

> 'If the "algorithm" directive's value is "MD5-s= ess", "SHA2-256", or
> "SHA2-512-256", then[...]'

Should this be:

> 'If the "algorithm" directive's value is "MD5-s= ess", "SHA2-256-sess", or
> "SHA2-512-256-sess", then[...]'

?

-Ilari

--001a11c305a4553eda04e839f05a-- From ynir@checkpoint.com Tue Oct 8 07:58: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 1107E21E80A7 for ; Tue, 8 Oct 2013 07:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.332 X-Spam-Level: X-Spam-Status: No, score=-10.332 tagged_above=-999 required=5 tests=[AWL=0.266, 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 xcW-mB3072Hw for ; Tue, 8 Oct 2013 07:58:00 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id E2F7221E8186 for ; Tue, 8 Oct 2013 07:57:27 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r98EvPhs018370 for ; Tue, 8 Oct 2013 17:57:25 +0300 X-CheckPoint: {52541D55-0-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.92]) by DAG-EX10.ad.checkpoint.com ([169.254.3.173]) with mapi id 14.02.0347.000; Tue, 8 Oct 2013 17:57:22 +0300 From: Yoav Nir To: "http-auth@ietf.org" Thread-Topic: Conference Call Details for the October 8th Virtual Interim Meeting Thread-Index: AQHOvc17IaogMgWuF0C2RMU/GqXGVg== Date: Tue, 8 Oct 2013 14:57:21 +0000 Message-ID: <47D29321-C2EB-4E1E-B16B-9D8AFA7F6BE5@checkpoint.com> References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.225] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: multipart/alternative; boundary="_000_47D29321C2EB4E1EB16B9D8AFA7F6BE5checkpointcom_" MIME-Version: 1.0 Subject: [http-auth] Fwd: Conference Call Details for the October 8th Virtual Interim Meeting 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, 08 Oct 2013 14:58:10 -0000 --_000_47D29321C2EB4E1EB16B9D8AFA7F6BE5checkpointcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Reminder. The call starts in 5 minutes Begin forwarded message: ---------- Forwarded message ---------- From: "Yoav Nir" via FreeConferenceCall com > Date: Mon, Sep 30, 2013 at 2:00 PM Subject: Conference Call Details for the October 8th Virtual Interim Meetin= g You are invited to a conference hosted by FreeConferenceCall.com Conference Invite Details Instructions From: ynir@checkpoint.com Subject: Conference Call Details for the October 8th Virtual Interim Meeti= ng Date & time: 08-October-2013 15:00 (GMT+00:00) Duration: 1.5 hr. Notes: Hi. These are the details of the conference call. Local numbers are availab= le in most countries. Our agenda is to discuss the MutualAuth draft. Simila= r to face-to-face meetings, Note Well applies, and the call will be recorde= d. Talk to you all in 8 days. Yoav [http://www.freeconferencecall.com/DID/invite_english.jpg] Free Conference Call Conference Dial-in Number: +972 (0) 76-599-0060 Participant Access Code: 295245# When prompted enter the access code that has been assigned, followed by the= # key. Once connected to the conference, you will be able to talk and have= access to the touch tone commands listed below. Participant Feature Keys [http://www.freeconferencecall.com/partner/images/fcc_be_star.gif] [ht= tp://www.freeconferencecall.com/partner/images/fcc_be_3.gif] Exit -= exit the call [http://www.freeconferencecall.com/partner/images/fcc_be_star.gif] [ht= tp://www.freeconferencecall.com/partner/images/fcc_be_4.gif] Instru= ctions - conference instructions [http://www.freeconferencecall.com/partner/images/fcc_be_star.gif] [ht= tp://www.freeconferencecall.com/partner/images/fcc_be_6.gif] Mute/U= nmute - caller controlled muting Email secured by Check Point --_000_47D29321C2EB4E1EB16B9D8AFA7F6BE5checkpointcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable Reminder. The call starts in 5 minutes

Begin forwarded message:

---------- Forwarded message ----------
From: "Yoav Nir" via FreeConference= Call com <services@freeconfere= ncecall.com>
Date: Mon, Sep 30, 2013 at 2:00 PM
Subject: Conference Call Details for the October 8th Virtual Interim Meetin= g



You are invited to a confer= ence hosted by FreeConferenceCall.com
Conference Invite Details
 
Instructions
From: ynir= @checkpoint.com

Subject:  Conference Call Details for the October 8th Virt= ual Interim Meeting
Date & time:  08-October-2013 15:00 (GMT+00:00) Duration:  1.5 hr.

Notes: 
Hi. These are the details of the conference call. Local numbers are availab= le in most countries. Our agenda is to discuss the MutualAuth draft. Simila= r to face-to-face meetings, Note Well applies, and the call will be recorde= d. Talk to you all in 8 days. Yoav

 
Free Conference Call
 Conference Dial-in Number: +972 (0) 76-599= -0060
 Participant Access Code: 295245#

When prompted enter the access code that has been assigned, followed by the= # key. Once connected to the conference, you will be able to talk and have= access to the touch tone commands listed below.


Participant Feature Keys
3D"" 3D"" Exit - exit the call
3D"" 3D"" Instructions - conference instructions
3D"" 3D"" Mute/Unmute - caller controlled muting






Email secured by Check Point


--_000_47D29321C2EB4E1EB16B9D8AFA7F6BE5checkpointcom_-- From y.oiwa@aist.go.jp Tue Oct 8 07:58: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 2E08621E81EE for ; Tue, 8 Oct 2013 07:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.757 X-Spam-Level: X-Spam-Status: No, score=-5.757 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] 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 iotIlQVdtSIZ for ; Tue, 8 Oct 2013 07:58:24 -0700 (PDT) Received: from na3sys010aog110.obsmtp.com (na3sys010aog110.obsmtp.com [74.125.245.88]) by ietfa.amsl.com (Postfix) with ESMTP id 0F2FB21E81A2 for ; Tue, 8 Oct 2013 07:57:58 -0700 (PDT) Received: from mail-vb0-f45.google.com ([209.85.212.45]) (using TLSv1) by na3sys010aob110.postini.com ([74.125.244.12]) with SMTP ID DSNKUlQddVt3opVN1g6kpuXSDwRNQnYShBVG@postini.com; Tue, 08 Oct 2013 07:57:58 PDT Received: by mail-vb0-f45.google.com with SMTP id e15so4173651vbg.4 for ; Tue, 08 Oct 2013 07:57:56 -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 :content-type; bh=KOcmC2Gjy3mSxl1Ze3wG76wpF+LKbiRkBJ5o0/fMwQs=; b=GlUcG2SM1SLd35PtXKuJx0vmLdstNBnSS6JAzSQMAUxKZ+khWizzrwUblc4WaExtaU h+dcyac0toj9bkoUmbVoDhYRW6Qn5U8KZn8YrslCzotPg2z4M/hSUpmia1LbxEqgrlFs nuHBpWzFdwptRmwZkCBDWx3g7ZLGVNgBPsVZ8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=KOcmC2Gjy3mSxl1Ze3wG76wpF+LKbiRkBJ5o0/fMwQs=; b=FaK88YH3Vpt6BDO5DZBurOmrJhn7RXZ6gdezv+vLS2R6TouFEGFnw0vYkpIIZIR0Ik lyZHHLkv7K+vivvclK4Xo2Cvr9qrP6TkltZ/+9q5Wwm8DNFL+/6f2GX306MeXG0cxbw8 l9U63b4cFhukQhfesR/pbz9Gd9SKoPKDkrGSpD8gn+hfAMhXU8l0km35xGvR4MzTgyH3 Ic0TycTd5NpxP9wo3qGD+EIeu5U2xHPHTygny2EDDq1ClNxB3dvt58YSIQwYWxf2tw5p 27k3M3VVYutl1suS32OjZI6Y1dBRiDCzHxv9ys3ygBwe4Qrvlcya+WmXEughvW9IIm/k TToA== X-Gm-Message-State: ALoCoQnt+h01DwooTePv+GFjwURpqC3aVYZRvDzR8ZvKP0H5QLScBpx9kl4TnRrzQ/vrOloh0ZCZBSA0hT7hynn3M6IW2Y68vbahpiaG5LCk4kKHVy8TpGzxVW+FMx3vnpvfiYiNSSZLWmqFGu51WdMb2WN+ZxlWOQ== X-Received: by 10.52.229.4 with SMTP id sm4mr482423vdc.50.1381244276961; Tue, 08 Oct 2013 07:57:56 -0700 (PDT) X-Received: by 10.52.229.4 with SMTP id sm4mr482416vdc.50.1381244276858; Tue, 08 Oct 2013 07:57:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.144.144 with HTTP; Tue, 8 Oct 2013 07:57:36 -0700 (PDT) In-Reply-To: References: From: Yutaka OIWA Date: Tue, 8 Oct 2013 23:57:36 +0900 Message-ID: To: "http-auth@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [http-auth] [Mutual] answers for FAQs (2) Methods for TLS channel bindings 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, 08 Oct 2013 14:58:31 -0000 An additional note to the my previous answer: (1) main discussion around here seems to be something around our tls-key and RFC-5929 "tls-unique" binding. However, currently I also consider dropping tls-key binding completely. (It's only significant for use with anonymous D-H exchanges.) Alternatively, I expect we mainly use tls-cert verification. It uses a server certificate as a binding key, This correspond to RFC-5929 "tls-server-end-point" binding. The difference between these two are quite minor. Regarding running code, both can be implemented at this moment. Without library support, our one is easier to implement. With explicit library support, RFC 5929 is easier. We have a small interest to discuss the "correct" design on the cryptographic context, but, in short, after having a talk to clarify security strength differences and having a consensus on having such changes (possibly weaking security in some cases), adopting tls-server-end-point is quite acceptable for us. (Only "weaking" difference is that RFC-5929 will use SHA-256 instead of SHA-512 when certificates are signed with MD5, SHA-1 and SHA-256, and our Mutual key exchange will go on with stronger SHA-512 hash. On the contrary, if Mutual key exchange uses SHA-256 and certificate has SHA-512 signature, RFC-5929 will use stronger SHA-512 while ours use SHA-256.) (2) Assuming that we go to implement tls-key regardless of above (1) discussion, Quickly searching around Internet and looking for changelogs, we currently see only several proposed patches for tls-unique binding. We're really appreciating information about already-adopted implementation of RFC 5929 (especially for "tls-unique"). We really need either implemented or implementable algorithms, but, as repeating my previous words, once it's widely implemented we're happy to use it. Or, do we have strong motivation and power to promote its implementations? 2013/10/4 Yutaka OIWA : > Deal all, > > second commonly-asked questions to answer is about how the protocol > bind itself with the underlying connection channels. > Currently, a TLS channel binding mechanism has an RFC standard, > and our scheme defined a separate mechanism in Section 7. > We've listed this as an item for possible future consideration in > Appendix A. I'll answer "why" doing so, and "what" I think we should do. > > * Why > > As the time of writing the first revision of our proposal, there was simply > no such scheme defined as the standard. It was not a re-invented wheel, > but acutually parallel-developed wheels. > > Of course, at that time there was no implementation support for the > current standard, > and things defined in the current standard (issued as an I-D which we noticed > shortly after our design) really requires additional implementation > code inside TLS libraries. > We had no ways to implement that at that time. > Our alternative design, on the contrary, was *able to be* implemented with > existing TLS libraries at that time without modification. > > * What we should do > > I currently do not have enough information about the implementation status of > the current standard mechanism. If you have any summary of that, I > really appreciate it. > That is the only reason that we're suspending technology migration. > If we have enough support for that mechanism, I'm simply happy to migrate for > the newer standard mechanism. > > > * Why again (appendix: possible reasons for the design difference) > > Generally speaking, using a raw key as a binding material is often risky against > information leakage. As a general vehicle for unrestricted applications, > it seems infeasible to use it. I guess that is the reason why the > current standard > uses a TLS Finished message instead. However, if the implementation > do not support the standard explicitly, the Finished message is a > volatile thing which is generated on-demand during negotiation and then > discarded (as it is not required anymore after that). After finished > negotiation, > we have absolutely no way for regenerating the Finished message for > channel binding. That's why the current standard required explicit > implementation support. > > On the contrary, the raw key is rather a permanent thing which is often > kept until the TLS protocol really terminates. It was, and it is, > available from the internal structure of many TLS libraries, or in some cases, > even through debugging facilities implemented in the libraries. > In our use cases, that raw key is always mixed and hashed with > random numbers with larger entropy, so there is no direct risk for > retrieving/guessing the raw key from eavesdropped traffics. > That's why we chose this design in the past. > > -- > 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] -- 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 stephen.farrell@cs.tcd.ie Tue Oct 8 08:02: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 85EA321E8186 for ; Tue, 8 Oct 2013 08:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UR9+27xh11Ng for ; Tue, 8 Oct 2013 08:02:43 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id C9FC821E81A2 for ; Tue, 8 Oct 2013 08:02:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C91ECBDCA; Tue, 8 Oct 2013 16:02: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 GPzK6V+ik+WC; Tue, 8 Oct 2013 16:02:31 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B9AFABE62; Tue, 8 Oct 2013 16:02:26 +0100 (IST) Message-ID: <52541E82.30001@cs.tcd.ie> Date: Tue, 08 Oct 2013 16:02:26 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Yoav Nir , "http-auth@ietf.org" References: <47D29321-C2EB-4E1E-B16B-9D8AFA7F6BE5@checkpoint.com> In-Reply-To: <47D29321-C2EB-4E1E-B16B-9D8AFA7F6BE5@checkpoint.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [http-auth] Fwd: Conference Call Details for the October 8th Virtual Interim Meeting 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, 08 Oct 2013 15:02:49 -0000 I'm also in the httpauth@jabber.ietf.org jabber room btw, might be handy to use that. S On 10/08/2013 03:57 PM, Yoav Nir wrote: > Reminder. The call starts in 5 minutes > > Begin forwarded message: > > ---------- Forwarded message ---------- > From: "Yoav Nir" via FreeConferenceCall com > > Date: Mon, Sep 30, 2013 at 2:00 PM > Subject: Conference Call Details for the October 8th Virtual Interim Meeting > > > > You are invited to a conference hosted by FreeConferenceCall.com > > > Conference Invite Details > > Instructions > > From: ynir@checkpoint.com > > Subject: Conference Call Details for the October 8th Virtual Interim Meeting > Date & time: 08-October-2013 15:00 (GMT+00:00) > Duration: 1.5 hr. > > Notes: > Hi. These are the details of the conference call. Local numbers are available in most countries. Our agenda is to discuss the MutualAuth draft. Similar to face-to-face meetings, Note Well applies, and the call will be recorded. Talk to you all in 8 days. Yoav > > [http://www.freeconferencecall.com/DID/invite_english.jpg] > > Free Conference Call > Conference Dial-in Number: +972 (0) 76-599-0060 > Participant Access Code: 295245# > > When prompted enter the access code that has been assigned, followed by the # key. Once connected to the conference, you will be able to talk and have access to the touch tone commands listed below. > > > > Participant Feature Keys > [http://www.freeconferencecall.com/partner/images/fcc_be_star.gif] [http://www.freeconferencecall.com/partner/images/fcc_be_3.gif] Exit - exit the call > [http://www.freeconferencecall.com/partner/images/fcc_be_star.gif] [http://www.freeconferencecall.com/partner/images/fcc_be_4.gif] Instructions - conference instructions > [http://www.freeconferencecall.com/partner/images/fcc_be_star.gif] [http://www.freeconferencecall.com/partner/images/fcc_be_6.gif] Mute/Unmute - caller controlled muting > > > > > > > > Email secured by Check Point > > > > > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > From y.oiwa@aist.go.jp Tue Oct 8 08:05: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 A859121E81EE for ; Tue, 8 Oct 2013 08:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.869 X-Spam-Level: X-Spam-Status: No, score=-5.869 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 ar23sfa1VibF for ; Tue, 8 Oct 2013 08:05:47 -0700 (PDT) Received: from na3sys010aog103.obsmtp.com (na3sys010aog103.obsmtp.com [74.125.245.74]) by ietfa.amsl.com (Postfix) with ESMTP id B606921E8201 for ; Tue, 8 Oct 2013 08:05:40 -0700 (PDT) Received: from mail-vb0-f54.google.com ([209.85.212.54]) (using TLSv1) by na3sys010aob103.postini.com ([74.125.244.12]) with SMTP ID DSNKUlQfRCgjfZCUQY2+EsUw944D2ECM5DDo@postini.com; Tue, 08 Oct 2013 08:05:40 PDT Received: by mail-vb0-f54.google.com with SMTP id q14so4435471vbe.13 for ; Tue, 08 Oct 2013 08:05:39 -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=cyHB5pgQtr2GGTRyg7a6QFIrMrdLpZmmsASo6MCu0i4=; b=En40vYydojs6IydXtfClaXPpdLhKVN7tiZ8lOh4bw+bqaEkMSOR5FksYC14MWd8KLj NGhAgRH3sh7Z1HY9DRiEACcfk4/1uKp8Dw2d2f0HAnOzgJ0k0SEZrZxIZ3lqaZka2pJG yJ6PSJ9I3UKVnFxMA37ZlUw6cbqDax9pNL8ag= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=cyHB5pgQtr2GGTRyg7a6QFIrMrdLpZmmsASo6MCu0i4=; b=mSMhkTPgkar79ikR9QLuoJkaXoCMLeigh7Z0I41fcvdgtH6tqhrEFvtvzxcIxkgVXd tLFVwrsgbr52wuzrYMMN6NH5t5TfqdJRvoOi1J0ggBZe34E1R2NuQIe7tribyxs5pC4U LDv5rSVImxCEcIl1QcALzKQ103oUHS0p7faDpNusyFeHl2x+tVQnYUMjWkYfQUgOcSIL rdxnxhdQthJTKvk4gFI1LEoIiG0pPSDj5p8XbSdC9yNq0tiiB5iLz9xM6Em/0yZfz5Pw 0u1f5fctTxEPoZbEfpuiST9nAVz7EOMBnotZvEp/vrPS6XBLeWNWBz0UksxpghDfFsn6 iXRg== X-Gm-Message-State: ALoCoQmSYwJGrVgUOW8g7IMRZmbn/4dU24SEi8ngodytXj5x4cbrTwmCm9QhaaP6Z8NC0btRSBwuGF5CDa+lhHWbrDp+D4O9vT2zL9WeWk3CKb/kpKrrbVSzb5BebamI1Ur1345ZzCQQjtqGoTMDfWBrxG0DYlS2hQ== X-Received: by 10.52.233.2 with SMTP id ts2mr831880vdc.44.1381244739833; Tue, 08 Oct 2013 08:05:39 -0700 (PDT) X-Received: by 10.52.233.2 with SMTP id ts2mr831873vdc.44.1381244739704; Tue, 08 Oct 2013 08:05:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.144.144 with HTTP; Tue, 8 Oct 2013 08:05:19 -0700 (PDT) In-Reply-To: <47D29321-C2EB-4E1E-B16B-9D8AFA7F6BE5@checkpoint.com> References: <47D29321-C2EB-4E1E-B16B-9D8AFA7F6BE5@checkpoint.com> From: Yutaka OIWA Date: Wed, 9 Oct 2013 00:05:19 +0900 Message-ID: To: Yoav Nir Content-Type: multipart/alternative; boundary=089e0111bbe40eecdb04e83c1a2a Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Fwd: Conference Call Details for the October 8th Virtual Interim Meeting 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, 08 Oct 2013 15:05:53 -0000 --089e0111bbe40eecdb04e83c1a2a Content-Type: text/plain; charset=ISO-8859-1 I'm connected to conference call but my voice seems not reached. I'm trying to connect to jabber. 2013/10/8 Yoav Nir > Reminder. The call starts in 5 minutes > > Begin forwarded message: > > > ---------- Forwarded message ---------- > From: "Yoav Nir" via FreeConferenceCall com < > services@freeconferencecall.com> > Date: Mon, Sep 30, 2013 at 2:00 PM > Subject: Conference Call Details for the October 8th Virtual Interim > Meeting > > > > You are invited to a conference hosted by FreeConferenceCall.com > > Conference Invite Details Instructions > *From: ynir@checkpoint.com* > > *Subject: * Conference Call Details for the October 8th Virtual Interim > Meeting > *Date & time: * 08-October-2013 15:00 (GMT+00:00) > *Duration: * 1.5 hr. > > *Notes: * > Hi. These are the details of the conference call. Local numbers are > available in most countries. Our agenda is to discuss the MutualAuth draft. > Similar to face-to-face meetings, Note Well applies, and the call will be > recorded. Talk to you all in 8 days. Yoav > > > *Free Conference Call* > Conference Dial-in Number: +972 (0) 76-599-0060 > Participant Access Code: 295245# > > When prompted enter the access code that has been assigned, followed by > the # key. Once connected to the conference, you will be able to talk and > have access to the touch tone commands listed below. > > > Participant Feature Keys Exit - exit the call Instructions - > conference instructions Mute/Unmute - caller controlled muting > > > > > > Email secured by Check Point > > > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > > -- Yutaka OIWA, Ph.D. Leader, System Life-cycle Research Group Research Institute for Secure Systems (RISEC) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] --089e0111bbe40eecdb04e83c1a2a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I'm connected to conference call but my voice seems no= t reached.
I'm trying to connect to jabber.


2013/10/8 Yoav Nir <ynir@= checkpoint.com>
Reminder. The call starts in 5 minutes

Begin forwarded message:

---------- Forwarded message -= ---------
From: "Yoav Nir" via FreeConference= Call com <se= rvices@freeconferencecall.com>
Date: Mon, Sep 30, 2013 at 2:00 PM
Subject: Conference Call Details for the October 8th Virtual Interim Meetin= g



You are invited to a confer= ence hosted by FreeConferenceC= all.com
Conference Invite Details
=A0
Instructions
From:=A0ynir@ch= eckpoint.com

Subject:=A0=A0Conference Call Details for the October 8th Virtual In= terim Meeting
Date & time:=A0=A008-October-2013 15:00 = (GMT+00:00)
Duration:=A0=A01.5 hr.

Notes:=A0
Hi. These are the details of the conference call. Local numbers are availab= le in most countries. Our agenda is to discuss the MutualAuth draft. Simila= r to face-to-face meetings, Note Well applies, and the call will be recorde= d. Talk to you all in 8 days. Yoav

=A0
Free Conference Call
=A0Conference Dial-in Number:=A0+972 (0) 76-599-0060
=A0Participant Access Code:=A0295245#

When prompted enter the access code that has been assigned, followed by the= # key. Once connected to the conference, you will be able to talk and have= access to the touch tone commands listed below.


Participant Feature Keys
3D"" 3D"" Exit - exit the call
3D"" 3D"" Instructions - conference instructions
3D"" 3D"" Mute/Unmute - caller controlled muting






Email secured by Check Point



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




--
Yutaka OIWA, Ph.D. = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Leader, System Life-cycle Research Group=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Research In= stitute for Secure Systems (RISEC)
=A0 =A0 =A0National Institute of Adva= nced Industrial Science and Technology (AIST)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Mail addresses: <y.oiwa@aist.go.jp>, = <yutaka@oiwa.jp&= gt;
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D =A03139 8677 9BD2 = 4405 46B5]
--089e0111bbe40eecdb04e83c1a2a-- From mlepinski.ietf@gmail.com Tue Oct 8 08:06: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 7483821E80AC for ; Tue, 8 Oct 2013 08:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Qq1LXiQ3T6Wo for ; Tue, 8 Oct 2013 08:06:39 -0700 (PDT) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 8363821E80A6 for ; Tue, 8 Oct 2013 08:06:38 -0700 (PDT) Received: by mail-qc0-f176.google.com with SMTP id t7so5980542qcv.21 for ; Tue, 08 Oct 2013 08:06:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wo8wnHsSu5zdihQ/4WTxI3gj2El0BVO6kmDGFfJjrmU=; b=HJNfSqtQ/wL3c21Vsg0xraPYcV6cNIV4D6NvwfR+SwQ9DVsdPD7h8TIvFqP9pxsjKe 0SjMMJmqrySCLzp2bOp5mXHss1CfObRWG9MHdMZnoy1jOdjjAPbsKY92t3QbyMfULh7/ vmX77pABytqbYrv3iPale2Y5sUAHODacVL7mViLyyR6yWkvJjGgvf5mKdseTFchTx0Ms g9aaOmgycs3SOCe62wh9kk94ugqFObP7fqUXe3fkTTfovjo07XepmNsLD+6puqz+x2Zm zJk6Jc5kh568I4SySDgYXN6daD7p7kM9HEptdBU6u9x3wsdQ3sX4BtwL8yUMGoFGWbuR 8Q+A== MIME-Version: 1.0 X-Received: by 10.49.59.115 with SMTP id y19mr2907031qeq.8.1381244797550; Tue, 08 Oct 2013 08:06:37 -0700 (PDT) Received: by 10.49.81.9 with HTTP; Tue, 8 Oct 2013 08:06:37 -0700 (PDT) In-Reply-To: <52541E82.30001@cs.tcd.ie> References: <47D29321-C2EB-4E1E-B16B-9D8AFA7F6BE5@checkpoint.com> <52541E82.30001@cs.tcd.ie> Date: Tue, 8 Oct 2013 11:06:37 -0400 Message-ID: From: Matthew Lepinski To: Stephen Farrell Content-Type: multipart/alternative; boundary=047d7b6221ea8185c204e83c1d3b Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Fwd: Conference Call Details for the October 8th Virtual Interim Meeting 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, 08 Oct 2013 15:06:40 -0000 --047d7b6221ea8185c204e83c1d3b Content-Type: text/plain; charset=ISO-8859-1 I also want to encourage anyone interested in this meeting to join the Jabber room. httpauth at jabber.ietf.org On Tue, Oct 8, 2013 at 11:02 AM, Stephen Farrell wrote: > > I'm also in the httpauth@jabber.ietf.org jabber room btw, might be handy > to use that. > > S > > On 10/08/2013 03:57 PM, Yoav Nir wrote: > > Reminder. The call starts in 5 minutes > > > > Begin forwarded message: > > > > ---------- Forwarded message ---------- > > From: "Yoav Nir" via FreeConferenceCall com < > services@freeconferencecall.com> > > Date: Mon, Sep 30, 2013 at 2:00 PM > > Subject: Conference Call Details for the October 8th Virtual Interim > Meeting > > > > > > > > You are invited to a conference hosted by FreeConferenceCall.com< > http://FreeConferenceCall.com> > > > > > > Conference Invite Details > > > > Instructions > > > > From: ynir@checkpoint.com > > > > Subject: Conference Call Details for the October 8th Virtual Interim > Meeting > > Date & time: 08-October-2013 15:00 (GMT+00:00) > > Duration: 1.5 hr. > > > > Notes: > > Hi. These are the details of the conference call. Local numbers are > available in most countries. Our agenda is to discuss the MutualAuth draft. > Similar to face-to-face meetings, Note Well applies, and the call will be > recorded. Talk to you all in 8 days. Yoav > > > > [http://www.freeconferencecall.com/DID/invite_english.jpg]< > http://www.freeconferencecall.com/fcci/internationalnumbers.aspx?lang=IL&altlang=EN&phonenumber=+972%20(0)%2076-599-0060 > > > > > > Free Conference Call > > Conference Dial-in Number: +972 (0) 76-599-0060 > > > Participant Access Code: 295245# > > > > When prompted enter the access code that has been assigned, followed by > the # key. Once connected to the conference, you will be able to talk and > have access to the touch tone commands listed below. > > > > > > > > Participant Feature Keys > > [http://www.freeconferencecall.com/partner/images/fcc_be_star.gif] > [http://www.freeconferencecall.com/partner/images/fcc_be_3.gif] > Exit - exit the call > > [http://www.freeconferencecall.com/partner/images/fcc_be_star.gif] > [http://www.freeconferencecall.com/partner/images/fcc_be_4.gif] > Instructions - conference instructions > > [http://www.freeconferencecall.com/partner/images/fcc_be_star.gif] > [http://www.freeconferencecall.com/partner/images/fcc_be_6.gif] > Mute/Unmute - caller controlled muting > > > > > > > > > > > > > > > > Email secured by Check Point > > > > > > > > > > > > _______________________________________________ > > 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 > --047d7b6221ea8185c204e83c1d3b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I also want to encourage anyone interested in this meeting= to join the Jabber room.
httpauth at jabber.ietf.org



On Tue, Oct 8, 2013 at 11:02 AM, Stephen= Farrell <stephen.farrell@cs.tcd.ie> wrote:

I'm also in the httpauth@ja= bber.ietf.org jabber room btw, might be handy
to use that.

S

On 10/08/2013 03:57 PM, Yoav Nir wrote:
> Reminder. The call starts in 5 minutes
>
> Begin forwarded message:
>
> ---------- Forwarded message ----------
> From: "Yoav Nir" via FreeConferenceC= all com <services@fre= econferencecall.com<mailto:services@freeconferencecall.com>>
> Date: Mon, Sep 30, 2013 at 2:00 PM
> Subject: Conference Call Details for the October 8th Virtual Interim M= eeting
>
>
>
> You are invited to a conference hosted by FreeConferenceCall.com= <http://Free= ConferenceCall.com>
>
>
> Conference Invite Details
>
> Instructions
>
> From: ynir@checkpoint.com&l= t;mailto:ynir@checkpoint.com>=
>
> Subject: =A0Conference Call Details for the October 8th Virtual Interi= m Meeting
> Date & time: =A008-October-2013 15:00 (GMT+00:00)
> Duration: =A01.5 hr.
>
> Notes:
> Hi. These are the details of the conference call. Local numbers are av= ailable in most countries. Our agenda is to discuss the MutualAuth draft. S= imilar to face-to-face meetings, Note Well applies, and the call will be re= corded. Talk to you all in 8 days. Yoav
>
> [http://www.freeconferencecall.com/DID/invite_englis= h.jpg]<http://www.freeconferencecall.com/fcci/interna= tionalnumbers.aspx?lang=3DIL&altlang=3DEN&phonenumber=3D+972%20(0)%= 2076-599-0060>
>
> Free Conference Call
> =A0Conference Dial-in Number: +972 (0) 76-599-0060<tel:%2B972%20%28= 0%29%2076-599-0060>
> =A0Participant Access Code: 295245#
>
> When prompted enter the access code that has been assigned, followed b= y the # key. Once connected to the conference, you will be able to talk and= have access to the touch tone commands listed below.
>
>
>
> Participant Feature Keys
> [http://www.freeconferencecall.com/partner/i= mages/fcc_be_star.gif] =A0 =A0 =A0[http://www.freeconf= erencecall.com/partner/images/fcc_be_3.gif] =A0 =A0 =A0 =A0 Exit - exit= the call
> [http://www.freeconferencecall.com/partner/images/= fcc_be_star.gif] =A0 =A0 =A0[http://www.freeconference= call.com/partner/images/fcc_be_4.gif] =A0 =A0 =A0 =A0 Instructions - co= nference instructions
> [http://www.freeconferencecall.com/partner/images/= fcc_be_star.gif] =A0 =A0 =A0[http://www.freeconference= call.com/partner/images/fcc_be_6.gif] =A0 =A0 =A0 =A0 Mute/Unmute - cal= ler controlled muting
>
>
>
>
>
>
>
> Email secured by Check Point
>
>
>
>
>
> ________________________= _______________________
> 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

--047d7b6221ea8185c204e83c1d3b-- From stephen.farrell@cs.tcd.ie Tue Oct 8 08:16:01 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D927E21E81A2 for ; Tue, 8 Oct 2013 08:16:01 -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 4EsMkaWVIujO for ; Tue, 8 Oct 2013 08:15:57 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id DDCCF21E80A5 for ; Tue, 8 Oct 2013 08:15:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 37A80BE58; Tue, 8 Oct 2013 16:15:41 +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 o8wqNQIb0YLp; Tue, 8 Oct 2013 16:15:41 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0AF69BE4D; Tue, 8 Oct 2013 16:15:41 +0100 (IST) Message-ID: <5254219C.5040803@cs.tcd.ie> Date: Tue, 08 Oct 2013 16:15:40 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Yutaka OIWA , Yoav Nir References: <47D29321-C2EB-4E1E-B16B-9D8AFA7F6BE5@checkpoint.com> In-Reply-To: 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] Fwd: Conference Call Details for the October 8th Virtual Interim Meeting 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, 08 Oct 2013 15:16:02 -0000 If you don't get into the jabber room, then you can sort-of follow along from the archive:-) [1] You need to keep hitting refresh but better than nothing S. [1] http://www.ietf.org/jabber/logs/httpauth/2013-10-08.html On 10/08/2013 04:05 PM, Yutaka OIWA wrote: > I'm connected to conference call but my voice seems not reached. > I'm trying to connect to jabber. > > > 2013/10/8 Yoav Nir > >> Reminder. The call starts in 5 minutes >> >> Begin forwarded message: >> >> >> ---------- Forwarded message ---------- >> From: "Yoav Nir" via FreeConferenceCall com < >> services@freeconferencecall.com> >> Date: Mon, Sep 30, 2013 at 2:00 PM >> Subject: Conference Call Details for the October 8th Virtual Interim >> Meeting >> >> >> >> You are invited to a conference hosted by FreeConferenceCall.com >> >> Conference Invite Details Instructions >> *From: ynir@checkpoint.com* >> >> *Subject: * Conference Call Details for the October 8th Virtual Interim >> Meeting >> *Date & time: * 08-October-2013 15:00 (GMT+00:00) >> *Duration: * 1.5 hr. >> >> *Notes: * >> Hi. These are the details of the conference call. Local numbers are >> available in most countries. Our agenda is to discuss the MutualAuth draft. >> Similar to face-to-face meetings, Note Well applies, and the call will be >> recorded. Talk to you all in 8 days. Yoav >> >> >> *Free Conference Call* >> Conference Dial-in Number: +972 (0) 76-599-0060 >> Participant Access Code: 295245# >> >> When prompted enter the access code that has been assigned, followed by >> the # key. Once connected to the conference, you will be able to talk and >> have access to the touch tone commands listed below. >> >> >> Participant Feature Keys Exit - exit the call Instructions - >> conference instructions Mute/Unmute - caller controlled muting >> >> >> >> >> >> Email secured by Check Point >> >> >> >> _______________________________________________ >> 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 y.oiwa@aist.go.jp Tue Oct 8 11:25: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 BBC5A21E8278 for ; Tue, 8 Oct 2013 11:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.883 X-Spam-Level: X-Spam-Status: No, score=-5.883 tagged_above=-999 required=5 tests=[AWL=0.094, 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 pKGo1J+qZayj for ; Tue, 8 Oct 2013 11:25:42 -0700 (PDT) Received: from na3sys010aog102.obsmtp.com (na3sys010aog102.obsmtp.com [74.125.245.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7F39521E8271 for ; Tue, 8 Oct 2013 11:25:42 -0700 (PDT) Received: from mail-vb0-f48.google.com ([209.85.212.48]) (using TLSv1) by na3sys010aob102.postini.com ([74.125.244.12]) with SMTP ID DSNKUlROJcNpCxDq5B5px8nRQr/dOVZE8rfq@postini.com; Tue, 08 Oct 2013 11:25:42 PDT Received: by mail-vb0-f48.google.com with SMTP id w16so4367081vbf.21 for ; Tue, 08 Oct 2013 11:25:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:from:date:message-id:subject:to:content-type; bh=odaXGmoSDfbaSEg4xRVq/IyAG2/X39J7mi9DosvBzdg=; b=hplAReT7huD6PwvQy6Srj/o8Z5LvtJeLGV94FUzLlggggHsGyTvEHlVK/CZI39jkuP DkqBhSjabHReoxdGxam6WMBThRtv4fWlEWdmblzoT0cOrh3hFgUWvLFCMbidvRjXP7Wx ju6PrAbSAnchKXL8x1U11zUPR94TI1Afs0gHE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=odaXGmoSDfbaSEg4xRVq/IyAG2/X39J7mi9DosvBzdg=; b=I17oGdiMoPYcz2fPCz7HOwK5K25ztIjkxBigqb1bx9zOQ3sdmiKY3WcpllIMtQ07lO VU7Z8wvRnaTaXY/xXeVwvM56j8qJ052v3a7gGRvKFt9NjKpZDdhwX5/oT5hHZlrdPY7B SoxanSTsulnhHP2of3PeBvh+32cLdsQCDIwiYAAJO7bCNYxd8K+5pjxrjr/v30Q8ZEBZ q7ZJWO9It4B+ZpoBbnww/RTAMfutz7kHWYWNXNmCw5kZtwkTnv3v807m1KifZmCVu38f IWlEKBbhK60FsnB12zY1HXQnSBxOZNghzLJDQl+B62S+RvbcOZOvrbXGDOeMgk5+3Tyo mxwg== X-Gm-Message-State: ALoCoQmg8+N1p4AIfOfB0z4ME09XlzhSR4prZuf8eS+lHFG/6j62DB/2riESFlKpv8afZU75bp+0g2Oqa3cGx5m+E9xuw6W9vCnnVfagebak/wttw4UI9bnWwnHJPPaJRInW3CER0Ksh8TqOWF1MdAzwTnpkP9upYw== X-Received: by 10.220.10.194 with SMTP id q2mr2053629vcq.2.1381256741325; Tue, 08 Oct 2013 11:25:41 -0700 (PDT) X-Received: by 10.220.10.194 with SMTP id q2mr2053593vcq.2.1381256740685; Tue, 08 Oct 2013 11:25:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.144.144 with HTTP; Tue, 8 Oct 2013 11:25:20 -0700 (PDT) From: Yutaka OIWA Date: Wed, 9 Oct 2013 03:25:20 +0900 Message-ID: To: "http-auth@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [http-auth] [Asking for technical suggestions] re: changing TLS channel binding mechanisms 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, 08 Oct 2013 18:25:47 -0000 Dear all, thank you for good suggestions and discussions on the interim meeting. After having the discussion, my minds are going to make changes regarding TLS channel binding mechanisms. Two topics exist: (1) Regarding tls-key mechanism, I'm going to replace it with RFC 5929 "tls-unique" mechanism. This mechanism is rather "experimental" (even within experimental I-D) in real use cases, so I'm convinced that it's a good thing to go forward with promoting new channel-binding standard, encouraging changes to underlying TLS implementations, even if current implementations do not support it. I do not see any security issue about this change. If you have any comment about security implication of this change on the bad side, please let me know. (2) Regarding tls-cert mechanism, I also consider replacing it with RFC 5929 "tls-server-end-point" mechanism. It's a little bit more difficult to implement RFC way than our way without library support, but it's still implementable, so I'm OK regarding implementation issue. I'm basically happy with using standard mechanism as far as it is OK. However, I want to confirm whether it is OK or not, regarding security. I have one thing which I'm not completely certain with, so I am asking for a clue. These two constructions are quite similar, both using hash of the body of the server certificate as a binding key, but choices of hash functions differs as following: * My tls-cert proposal uses hash function which is used within PAKE key exchanges within Mutual HTTP authentication. As its strength is the same as the security strength which Mutual itself assures, the construction is straightforward. And that's why we constructed in this way, before having RFC 5929 as a standard. * The tls-server-end-point standard uses the hash function which is used by the CA to sign the certificate. However, if it were MD5 or SHA-1, SHA-256 is used instead. Under this setting, if people uses stronger 4096-bit Mutual authentication with SHA-512, and underlying TLS uses a certificate still signed with 256-bit hash functions, the RFC standard will generate a 256-bit binding key, weaker than my current proposal. This is the difference I am not completely sure it's OK. My question is, in short, is it acceptable to use 256-bit binding key in this case? More precisely, if the certificate's signature is only 256 bit, can we say that we only have 256-bit-hash-equivalent security anyway in TLS, and it is not very worthful to generate 512 bit binding keys? (This logic may lead to a contradiction, however, because it implies that having a 256-bit binding key is worthless when cert is signed with 128-bit MD5, meaning RFC 5929 construction being odd.) Answers may be: (a) It's OK, no security issue here. a 512-bit binding key is worthless with this case. (b) Strictly speaking a 512-bit key is preferable, but a 256-bit key is mostly OK in this case. (c) A 512-bit key is preferable, a 256-bit key is certainly weaker, but the difference is not "significant" to make a deviation from current standards. (d) A 256-bit key is no-go in this case. We should not use the standard. (e) other than any of above. I will personally explain the situation face-to-face in Vancouver if you are kindly going to make a suggestion but the above description is not enough for decisions. I will also invetigate this issue further by myself, and post again to this ML if I found more. If you have a clear intuition on answer (a) or (b), please let me know. Again, I'm happier on answers (a)-(b) than having answer (d). (C) is mostly unhappy, as we need to make a security decision in WG. But my current guess is something around case (c). Especially in case (c), I want to have a strong WG consensus before making this change, not only from my personal intention to do so. # P.S. Regarding that RFC 5929 hardcoded the 256-bit security strength of hashes, # I guess why they did, I guess I'm understanding that they needed to do so, # but I am still seeing it as technically "odd". Thanks, -- 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 Wed Oct 9 09:18:01 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6A2011E8192 for ; Wed, 9 Oct 2013 09:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.37 X-Spam-Level: X-Spam-Status: No, score=-10.37 tagged_above=-999 required=5 tests=[AWL=0.229, 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 qcBGhA+cH4dE for ; Wed, 9 Oct 2013 09:17:57 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id BBE6211E80F6 for ; Wed, 9 Oct 2013 09:17:56 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r99GHlQd007663 for ; Wed, 9 Oct 2013 19:17:47 +0300 X-CheckPoint: {525581AB-2-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.92]) by DAG-EX10.ad.checkpoint.com ([169.254.3.173]) with mapi id 14.02.0347.000; Wed, 9 Oct 2013 19:17:42 +0300 From: Yoav Nir To: "http-auth@ietf.org" Thread-Topic: Yesterday's interim meeting Thread-Index: AQHOxQsU/qQjsiYfCUCEHYL7PuIuFQ== Date: Wed, 9 Oct 2013 16:17:41 +0000 Message-ID: <07BF2255-02F1-42C4-9B26-A153447A1EC8@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.130] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: <34421AE3D2203244BCBD2F7E588C6C5D@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [http-auth] Yesterday's interim meeting 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, 09 Oct 2013 16:18:02 -0000 Hi. The meeting yesterday was very effective. Thanks to all who attended. The minutes will be up soon. For now, you can find the audio recording in = our Wiki: http://tools.ietf.org/wg/httpauth/trac/wiki Yoav From ynir@checkpoint.com Fri Oct 11 13:27: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 6705E21E8151 for ; Fri, 11 Oct 2013 13:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.368 X-Spam-Level: X-Spam-Status: No, score=-10.368 tagged_above=-999 required=5 tests=[AWL=0.231, 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 j9D2rF-8KqBK for ; Fri, 11 Oct 2013 13:27:03 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 646EF21E8158 for ; Fri, 11 Oct 2013 13:26:35 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r9BKQYTT003750 for ; Fri, 11 Oct 2013 23:26:34 +0300 X-CheckPoint: {52585EFA-3-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.92]) by DAG-EX10.ad.checkpoint.com ([169.254.3.173]) with mapi id 14.02.0347.000; Fri, 11 Oct 2013 23:26:28 +0300 From: Yoav Nir To: "http-auth@ietf.org" Thread-Topic: Next on the agenda... Thread-Index: AQHOxsApHB3XmZ6L20SdQ+njA8kGHA== Date: Fri, 11 Oct 2013 20:26:27 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.24.12] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [http-auth] Next on the agenda... 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, 11 Oct 2013 20:27:10 -0000 Hi all The virtual interim meeting was excellent, and we have made good progress o= n mutualAuth.=20 For the meeting in Vancouver (less than a month away), we intend to discuss= two of the other proposals: * HOBA * REST-Auth. Please send reviews to the list soon, as we'd like to have some discussion = on the list prior to the discussion in the room. Thanks Matt & Yoav From internet-drafts@ietf.org Fri Oct 18 04:48: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 8624D11E81E9; Fri, 18 Oct 2013 04:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.044, 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 Q7y8f4SjF0d5; Fri, 18 Oct 2013 04:48:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 21DFE21F9DB8; Fri, 18 Oct 2013 04:48:56 -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.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131018114856.2349.20266.idtracker@ietfa.amsl.com> Date: Fri, 18 Oct 2013 04:48:56 -0700 Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-scram-auth-01.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 11:48:56 -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-01.txt Pages : 18 Date : 2013-10-18 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-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-httpauth-scram-auth-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Fri Oct 18 18:30:28 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 422F421F9D15; Fri, 18 Oct 2013 18:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.041, 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 OisIMwEPNegH; Fri, 18 Oct 2013 18:30:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C941C21F9CEA; Fri, 18 Oct 2013 18:30:27 -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.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131019013027.23279.94382.idtracker@ietfa.amsl.com> Date: Fri, 18 Oct 2013 18:30:27 -0700 Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-hoba-02.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2013 01:30:28 -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-02.txt Pages : 21 Date : 2013-10-18 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 any 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. 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-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-httpauth-hoba-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Oct 21 09:44: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 A494411E85EE; Mon, 21 Oct 2013 09:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, 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 J5hfQI-+Tovi; Mon, 21 Oct 2013 09:44:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 504BA11E85D7; Mon, 21 Oct 2013 09:44:25 -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.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021164425.32534.2938.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 09:44:25 -0700 Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-mutual-01.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 16:44:41 -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 Tatsuya Hayashi Yuichi Ioku Filename : draft-ietf-httpauth-mutual-01.txt Pages : 49 Date : 2013-10-21 Abstract: This document specifies a mutual authentication method for the Hyper- text Transfer Protocol (HTTP). This method provides a true mutual authentication between an HTTP client and an HTTP server using password-based authentication. Unlike the Basic and Digest authentication methods, the Mutual authentication method specified in this document assures the user that the server truly knows the user's encrypted password. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-mutual There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-httpauth-mutual-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-httpauth-mutual-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Oct 21 09:44: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 25E9E11E822F; Mon, 21 Oct 2013 09:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, 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 fqZBS4DZQx1A; Mon, 21 Oct 2013 09:44:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2745B11E85E1; Mon, 21 Oct 2013 09:44:35 -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.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021164435.32495.17232.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 09:44:35 -0700 Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-extension-01.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 16:44: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 Authentication Extensions for Interactive Clients Author(s) : Yutaka Oiwa Hajime Watanabe Hiromitsu Takagi Tatsuya Hayashi Yuichi Ioku Filename : draft-ietf-httpauth-extension-01.txt Pages : 22 Date : 2013-10-21 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-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-httpauth-extension-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From y.oiwa@aist.go.jp Tue Oct 22 04:34: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 CB33721F9EF2 for ; Tue, 22 Oct 2013 04:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.902 X-Spam-Level: X-Spam-Status: No, score=-5.902 tagged_above=-999 required=5 tests=[AWL=0.076, 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 16LRa7CAVnaD for ; Tue, 22 Oct 2013 04:33:55 -0700 (PDT) Received: from na3sys010aog107.obsmtp.com (na3sys010aog107.obsmtp.com [74.125.245.82]) by ietfa.amsl.com (Postfix) with ESMTP id 9DCF011E818C for ; Tue, 22 Oct 2013 04:33:43 -0700 (PDT) Received: from mail-vb0-f45.google.com ([209.85.212.45]) (using TLSv1) by na3sys010aob107.postini.com ([74.125.244.12]) with SMTP ID DSNKUmZil1ELp7TZfLc3DmMd+JLhMsTYj0c/@postini.com; Tue, 22 Oct 2013 04:33:50 PDT Received: by mail-vb0-f45.google.com with SMTP id e15so5060174vbg.32 for ; Tue, 22 Oct 2013 04:33:43 -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 :content-type; bh=K9grlYeCrJXVXF6v+QAArWPqnUs+VathSZ3I6yrHkCc=; b=DIVqjQHyjLo/aVAgKPqLTqwaEoEq33GNDOwoMGbUc22OaCY7Rh0HSuo8zQq406/VhS xc5t2SRRUuYvZNPibvAq5IYUaD5YdjOAFgnm3Go87Q1oiQUCa+7kv+W7Mt84XpPLHNpy t80vUwKo03+vo+Xw6VHPvb1TFVdzprWWQNOks= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=K9grlYeCrJXVXF6v+QAArWPqnUs+VathSZ3I6yrHkCc=; b=I68WkFzfygGQnnWRWIKhpom6sJRYdeYFSzX7KKQ0rAclcFZ31A9DB85sUzBgjttqKh JRoi+MSUgnh8y98DM9VCeiRGa2bQI2iBYYTLpDkw0dwGZKusCICSfD7Ws6285xh+U6Ex KeAa4uUD7JvqjeMWfqusDcoJqGV8bZGfGXtyfLpxL7sUEhtum1AyuZ/eM1OButgjOoLU aJNcfFoBjdq3sG7EUCcs2typiioB9Aj8mVTi7IHu/0R5yxKvLUZnTl9sC5HFN9SGXBI6 KqYl5tmef5j0UGeJyU7ExjBkw/1Kx21W0mgqODsro/Uz1odBQR5GCFxSpVLQq2PWqu8O TwBA== X-Gm-Message-State: ALoCoQlSh1Ju8/0VuLDNImvft3h2FX4V3NowPeGPyGkh3tcgRw99Gc/ZPqR9hwA+BiSB0j7xDsor/yp9A/zGdqlj+xZIrNhx1W1XGSsiJTMzmWX4tsVJ/iwGoZaDkLeL7+I3bh7ZR9WhQ/AwodKgth9yHhsRUVFKOw== X-Received: by 10.52.105.195 with SMTP id go3mr3824932vdb.24.1382441623167; Tue, 22 Oct 2013 04:33:43 -0700 (PDT) X-Received: by 10.52.105.195 with SMTP id go3mr3824928vdb.24.1382441623018; Tue, 22 Oct 2013 04:33:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.77.34 with HTTP; Tue, 22 Oct 2013 04:33:22 -0700 (PDT) In-Reply-To: <20131021164425.32534.2938.idtracker@ietfa.amsl.com> References: <20131021164425.32534.2938.idtracker@ietfa.amsl.com> From: Yutaka OIWA Date: Tue, 22 Oct 2013 20:33:22 +0900 Message-ID: To: "http-auth@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-mutual-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, 22 Oct 2013 11:34:02 -0000 Dear httpauth WG people, Thank you again for valuable feedback in the interim meeting. I have quickly applied improvements for some of discussed issues. (Possibly) most important changes are: * change on channel binding (host verification) mechanisms. * dropping UI requirements, replaced with non-normative, general security discussion in the security consideration sections. I'd like to make more comprehensive changes including style and text improvements as a -02 draft. For a while on -01 draft, I'd like to have feedback on several changes I made. Change diffs are available at: http://tools.ietf.org/rfcdiff?url2=draft-ietf-httpauth-mutual-01.txt Some more issues are awaiting either my effort or WG discussions. Sorry for making you waiting. Thanks a lot, Yutaka 2013/10/22 : > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Hypertext Transfer Protocol Authentication Working Group of the IETF. > > Title : Mutual Authentication Protocol for HTTP > Author(s) : Yutaka Oiwa > Hajime Watanabe > Hiromitsu Takagi > Tatsuya Hayashi > Yuichi Ioku > Filename : draft-ietf-httpauth-mutual-01.txt > Pages : 49 > Date : 2013-10-21 > > Abstract: > This document specifies a mutual authentication method for the Hyper- > text Transfer Protocol (HTTP). This method provides a true mutual > authentication between an HTTP client and an HTTP server using > password-based authentication. Unlike the Basic and Digest > authentication methods, the Mutual authentication method specified in > this document assures the user that the server truly knows the user's > encrypted password. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-httpauth-mutual > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-httpauth-mutual-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-mutual-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth -- Yutaka OIWA, Ph.D. Leader, System Life-cycle Research Group Research Institute for Secure Systems (RISEC) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] From ynir@checkpoint.com Sat Oct 26 12:47: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 24E7911E81B9 for ; Sat, 26 Oct 2013 12:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.467 X-Spam-Level: X-Spam-Status: No, score=-10.467 tagged_above=-999 required=5 tests=[AWL=0.132, 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 l2afKp1ZGKHT for ; Sat, 26 Oct 2013 12:47:45 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 1757A21F9E39 for ; Sat, 26 Oct 2013 12:47:44 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r9QJlZEX006345 for ; Sat, 26 Oct 2013 22:47:40 +0300 X-CheckPoint: {526C1B8B-0-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.106]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Sat, 26 Oct 2013 22:47:18 +0300 From: Yoav Nir To: "http-auth@ietf.org" Thread-Topic: Last Call: (Initial Hypertext Transfer Protocol (HTTP) AuthenticationScheme Registrations) to Informational RFC Thread-Index: AQHO0WEKJiuNZ1ugCkOnXGKq3rar5Q== Date: Sat, 26 Oct 2013 19:47:15 +0000 Message-ID: <5E80AB5E-C57A-4A18-A569-D1A9C6A87622@checkpoint.com> References: <012601ced160$93102ee0$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.6] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="iso-8859-1" Content-ID: <2370A005C2329C47BE90D28B85506067@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [http-auth] Fwd: Last Call: (Initial Hypertext Transfer Protocol (HTTP) AuthenticationScheme Registrations) to Informational RFC 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, 26 Oct 2013 19:47:50 -0000 Hi Thought this might be of interest to our working group. Yoav Begin forwarded message: The IESG has received a request from the Hypertext Transfer Protocol Bis WG (httpbis) to consider the following document: - 'Initial Hypertext Transfer Protocol (HTTP) Authentication Scheme Registrations' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-11-04. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document registers Hypertext Transfer Protocol (HTTP) authentication schemes which have been defined in standards-track RFCs before the IANA HTTP Authentication Scheme Registry was established. Note that this document is part of a set, which should be reviewed together: * draft-ietf-httpbis-p1-messaging * draft-ietf-httpbis-p2-semantics * draft-ietf-httpbis-p4-conditional * draft-ietf-httpbis-p5-range * draft-ietf-httpbis-p6-cache * draft-ietf-httpbis-p7-auth * draft-ietf-httpbis-method-registrations * draft-ietf-httpbis-authscheme-registrations The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-httpbis-authscheme-registrati ons/ Once IESG evaluation begins, IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-httpbis-authscheme-registrati ons/ballot/ No IPR declarations have been submitted directly on this I-D. From julian.reschke@gmx.de Sat Oct 26 17:12: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 6C87821F9E95 for ; Sat, 26 Oct 2013 17:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.987 X-Spam-Level: X-Spam-Status: No, score=-102.987 tagged_above=-999 required=5 tests=[AWL=-0.387, 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 I91kmjRP5U5p for ; Sat, 26 Oct 2013 17:12:43 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id CC75821F9E94 for ; Sat, 26 Oct 2013 17:12:42 -0700 (PDT) Received: from [192.168.2.117] ([93.217.96.252]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0M8mCe-1VO9fp1TBM-00CDqk for ; Sun, 27 Oct 2013 02:12:41 +0200 Message-ID: <526C5A7C.5040008@gmx.de> Date: Sun, 27 Oct 2013 02:12:44 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Yoav Nir , "http-auth@ietf.org" References: <012601ced160$93102ee0$4001a8c0@gateway.2wire.net> <5E80AB5E-C57A-4A18-A569-D1A9C6A87622@checkpoint.com> In-Reply-To: <5E80AB5E-C57A-4A18-A569-D1A9C6A87622@checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:0o2tFz8P8yTqBB7ea0nZ3O9I6O0r4ejAeWdX43420E8MTPUivPD S4J3ft+JAtmXU2ZuHLMtPoDwoVSCGUtPXqYhcbU26LHfLnccQLVV1vDvbq3hSzGTBHNNFrF WFuBHPZGpbFrZGAn5xTa7jjeH4y881iNBZ9POwnyFCKRgPSUElyfXphRdWmCew7NqF876cu eVqhrzsi0grlU7ef0YAyg== Subject: Re: [http-auth] Fwd: Last Call: (Initial Hypertext Transfer Protocol (HTTP) AuthenticationScheme Registrations) to Informational RFC 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, 27 Oct 2013 00:12:48 -0000 On 2013-10-26 21:47, Yoav Nir wrote: > Hi > > Thought this might be of interest to our working group. > > Yoav > ... Right. But the one *really* important is (in LC as well). Best regards, Julian From mlepinski.ietf@gmail.com Sun Oct 27 20:16: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 8040C11E82FA for ; Sun, 27 Oct 2013 20:16:05 -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 XFJkFOge0RuR for ; Sun, 27 Oct 2013 20:16:04 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 71DF911E82F5 for ; Sun, 27 Oct 2013 20:16:04 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id u56so6051251wes.33 for ; Sun, 27 Oct 2013 20:16:03 -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=YU+LaEZqknhqbsIE970Ytrhbq0V3zebChdTE3KWRtTo=; b=vYbI3C7t3WCEXxZdBHNVFLTsyASl6zM6KuRanlsKrVN4lHuKEFd7slZ+xdjHnJuwJn X83uhq9ATzxtYAtE9FqBxBBAGndgIxuCr7xtmogaXVZxPyUsbCV41q+SkLJz5cJogWJJ 4J6ZJxbFIXlODI5grIUB4vBvwMbu5hw5J6qwKJ0j/uHhryzOe3GoqNsZ0PuxXKcMang2 g9jVsDa99Wt192I5sSY2nED7/+xSnM9h1ex7STU8Jugrp1rDNFBhE5regMvkyEHaAb9V 77yZMXfEqgCKpigu5mpbtUTkF3WygsW0yvQgoYIMO5brHPHQBEPP7dUAjv4KRE0ZExCS cOig== MIME-Version: 1.0 X-Received: by 10.180.189.49 with SMTP id gf17mr7039848wic.23.1382930163219; Sun, 27 Oct 2013 20:16:03 -0700 (PDT) Received: by 10.216.82.134 with HTTP; Sun, 27 Oct 2013 20:16:03 -0700 (PDT) Date: Sun, 27 Oct 2013 23:16:03 -0400 Message-ID: From: Matthew Lepinski To: "http-auth@ietf.org" Content-Type: multipart/mixed; boundary=001a11c33fd020c14d04e9c48525 Subject: [http-auth] Minutes for October 8 Interim Meeting 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, 28 Oct 2013 03:16:05 -0000 --001a11c33fd020c14d04e9c48525 Content-Type: multipart/alternative; boundary=001a11c33fd020c14804e9c48523 --001a11c33fd020c14804e9c48523 Content-Type: text/plain; charset=ISO-8859-1 I am having some trouble getting this uploaded to the Proceedings site (hopefully they will appear there soon). However, here is a set of minutes for the October 8th Interim meeting. Please let us know if there are any errors. Thanks, - Yoav and Matt --001a11c33fd020c14804e9c48523 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I am having some trouble getting this uploaded to the Proc= eedings site (hopefully they will appear there soon).=A0

However, here is a set of minutes for the October 8th Interim meeting. Ple= ase let us know if there are any errors.

Thanks,
- Yoav and Matt
--001a11c33fd020c14804e9c48523-- --001a11c33fd020c14d04e9c48525 Content-Type: text/plain; charset=US-ASCII; name="HttpAuth - Interim Minutes - Oct 8.txt" Content-Disposition: attachment; filename="HttpAuth - Interim Minutes - Oct 8.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hnb4w5oh0 SFRUUC1BVVRIIFZpcnR1YWwgSW50ZXJpbSBNZWV0aW5nDQpUdWVzZGF5LCBPY3RvYmVyIDguIDE1 OjAwIC0gMTY6MzAgVVRDDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0K DQpQcmVzZW50IGF0IHRoZSBpbnRlcmltIG1lZXRpbmcgd2VyZToNCllvYXYgTmlyDQpNYXR0IExl cGluc2tpDQpZdXRha2EgT2l3YQ0KU3RlcGhlbiBGYXJyZWxsDQpDYXJzdGVuIEJvcm1hbm4NCk5p Y28gV2lsbGlhbXMNCg0KVGhlIHB1cnBvc2Ugb2YgdGhlIGludGVyaW0gbWVldGluZyB3YXMgdG8g cmVzb2x2ZSBvcGVuIGlzc3VlcyBpbiB0aGUgZG9jdW1lbnQ6IA0KZHJhZnQtaWV0Zi1odHRwYXV0 aC1tdXR1YWwtMDANCg0KVGhlIGZvbGxvd2luZyBvcGVuIGlzc3VlcyB3ZXJlIGRpc2N1c3NlZCBh dCB0aGUgbWVldGluZzoNCihTZWU6IGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL2h0dHBh dXRoL3RyYWMvcXVlcnk/c3RhdHVzPW5ldyZjb21wb25lbnQ9bXV0dWFsKQ0KIzI6IFVzZSBvZiBU TFMgQ2hhbm5lbCBCaW5kaW5nIGZvciB0bHMta2V5DQojMzogQSBmZXcgaXNzdWVzIHdpdGggcHdk LWhhc2gNCiM0OiBTb21lIGlzc3VlcyB3aXRoIEF1dGhlbnRpY2F0aW9uIFJlYWxtDQojNTogSXMg U1RBTEUgbmVlZGVkPw0KIzY6IElzc3VlcyBpbiBTZWN0aW9uIDYNCiM3OiBXaGF0IGlzIHRoZSB2 YWx1ZSBvZiBub24tbWFuZGF0b3J5IGF1dGg/DQojODogU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMg SXNzdWVzDQojOTogU2ltcGxpZmllZCBwcm90b2NvbCBkZXNjcmlwdGlvbiAiY3J5cHRvIHBhcGVy Ii1zdHlsZQ0KDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0KVGhl IGZvbGxvd2luZyBhY3Rpb24gaXRlbXMgcmVzdWx0ZWQgZnJvbSB0aGUgbWVldGluZzoNCg0KSVNT VUUgIzQ6IA0KVGhlIGF1dGhvcnMgd2lsbCBwcm9kdWNlIHRleHQgZXhwbGFpbmluZyB0aGUgaXNz dWUgYW5kLCBpbiBwYXJ0aWN1bGFyLCB3aHkgdGhleSBjaG9zZSBub3QgdG8gcmUtdXNlIHdlYiBv cmlnaW4gKFJGQyA2NDU0KS4gVGhlIGF1dGhvcnMgd2lsbCBzZW5kIHRoaXMgZXhwbGFuYXRvcnkg dGV4dCB0byB0aGUgbWFpbGluZyBsaXN0LiANCg0KSVNTVUUgIzI6IFRoZSBhdXRob3JzIGFyZSBo ZXNpdGFudCB0byB1c2UgdGhlIG1lY2hhbmlzbSBpbiBSRkMgNTkyOSBiZWNhdXNlIHRoZXkgYXJl IGNvbmNlcm5lZCBhYm91dCB0aGUgYWRvcHRpb24gc3RhdHVzIG9mIFJGQyA1OTI5IGFuZCBkb24n dCB3YW50IGEgZGVwZW5kZW5jeSBvbiBSRkMgNTkyOSB0byBoaW5kZXIgaW1wbGVtZW50YXRpb24g b2YgdGhlIG11dGFsLWF1dGggbWVjaGFuaXNtLiBTZXZlcmFsIHdvcmtpbmcgZ3JvdXAgcGFydGlj aXBhbnRzIGZlZWwgcXVpdGUgc3Ryb25nbHkgdGhhdCBSRkMgNTkyOSBpcyB0aGUgZnV0dXJlLCBh bmQgdGhhdCBIVFRQQVVUSCBpcyB3ZWxsLXNlcnZlZCB0byB1c2UgdGhlIGFscmVhZHktc3RhbmRh cmRpemVkIGNoYW5uZWwgYmluZGluZyBtZWNoYW5pc20uDQoNClRoZSBhdXRob3JzIHdpbGwgc2Vu ZCBhIG1lc3NhZ2UgdG8gdGhlIGxpc3QgYW5kIHByb3Bvc2UgYSB3YXkgZm9yd2FyZCBvbiB0aGlz IGlzc3VlLiANCg0KSVNTVUUgIzM6IFRoZSBhdXRob3JzIGV4cGxhaW5lZCB0aGF0IHRoaXMgZmVh dHVyZSBpcyBwcmVzZW50IGZvciBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IHdpdGggZXhpc3Rpbmcg cGFzc3dvcmQgZGF0YWJhc2VzLiBUaGVyZSB3ZXJlIG11bHRpcGxlIG9waW5pb25zIG9uIHRoZSBj YWxsIHJlZ2FyZGluZyB3aGV0aGVyIHRoaXMgYmFja3dhcmQgY29tcGF0aWJpbGl0eSBpcyBpbXBv cnRhbnQuIChUaGF0IGlzLCBhcmUgZW50aXRpZXMgdGhhdCBoYXZlIGxhcmdlIGxlZ2FjeSBwYXNz d29yZCBkYXRhYmFzZXMgbGlrZWx5IHRvIG1pZ3JhdGUgdG8gTXV0dWFsLUF1dGggaWYgdGhpcyBi YWNrd2FyZCBjb21wYXRpYmlsaXR5IGlzIHByb3ZpZGVkPykNCg0KVGhlIGNoYWlycyB3aWxsIHN0 YXJ0IGEgZGlzY3Vzc2lvbiBvbiB0aGUgbGlzdCB0byB0cnkgdG8gZ2V0IGlucHV0IGZyb20gYSB3 aWRlciBzZXQgb2YgcGVvcGxlIHJlZ2FyZGluZyB3aGV0aGVyIHRoZSBQV0QtaGFzaCBmZWF0dXJl IGlzIHVzZWZ1bC4gVGhlIGF1dGhvcnMgaW5kaWNhdGVkIHRoZXkgYXJlIHdpbGxpbmcgdG8gcmVt b3ZlIHRoaXMgZmVhdHVyZSBpZiBpdCB0dXJucyBvdXQgdGhhdCB0aGUgY29tbXVuaXR5IGRvZXMg bm90IHRoaW5rIGl0IGlzIHVzZWZ1bC4NCg0KSVNTVUUgIzU6IFRoZSBuZXh0IHZlcnNpb24gb2Yg dGhlIE11dHVhbC1BdXRoIGRyYWZ0IHdpbGwgaW5jb3Jwb3JhdGUgdGhlIGlkZWEgb2YgaG93IGxv bmcgdGhlIHNlcnZlciBzaG91bGQga2VlcCBzZXNzaW9uIGluZm9ybWF0aW9uDQoNCklTU1VFICM2 OiBUaGUgYXV0aG9ycyBleHBsYWluZWQgdGhhdCB0aGlzIGlzIG5vdCBhbiBpc3N1ZSB0aGF0IG5l ZWRzIHRvIGJlIHJlc29sdmVkLiBUaGF0IGlzLCB0aGUgbm9uY2UgaW4gbXV0dWFsLWF1dGggcGxh eXMgdGhlIHJvbGUgb2YgdGhlIGNsaWVudCBub25jZSBpbiB0aGUgZGlnZXN0IHNjaGVtZSBhbmQg dGhlcmVmb3JlIGl0IGlzIGNvcnJlY3QgdGhhdCBpdCBiZSBnZW5lcmF0ZWQgYnkgdGhlIGNsaWVu dC4NCg0KSVNTVUUgIzc6IFRoZSBhdXRob3JzIHdpbGwgbW92ZSBub24tbWFuZGF0b3J5IGF1dGgg aW50byB0aGUgb3B0aW9uYWwgZHJhZnQuDQoNCklTU1VFICM4OiBUaGVyZSBzZWVtcyB0byBiZSBh IG5lZWQgZm9yIGNvbW1vbiB0ZXh0IChpbiB0aGUgSFRUUC1BVVRIIHdvcmtpbmcgZ3JvdXApIGZv ciBhbGwgcGFzc3dvcmQtdXNpbmcgZHJhZnRzIHRvIHB1dCBpbnRvIFNlY3VyaXR5IENvbnNpZGVy YXRpb25zLiBUaGUgYXV0aG9ycyB0aGF0IGhhdmUgSFRUUC1BVVRIIGRyYWZ0cyB0aGF0IHVzZSBw YXNzd29yZHMgd2lsbCBjby1vcmRpbmF0ZSB0byBwcm9kdWNlIGFwcHJvcHJpYXRlIGNvbnNpZGVy YXRpb25zIHRleHQuDQoNClRoZXJlIHdhcyBhIHJlcXVlc3QgZm9yIHRoZSBhdXRob3JzIHRvIGFk ZCBhIHJlZmVyZW5jZSB0byBvdXRzaWRlIChub24tSUVURikgZG9jdW1lbnRzIHRoYXQgZGlzY3Vz cyB0aGUgc2VjdXJpdHkgYW5hbHlzaXMgb2YgdGhlIE11dHVhbCBBdXRoIHByb3RvY29sLiANCg0K VGhlIGNoYWlycyB3aWxsIGRpc2N1c3Mgd2l0aCB0aGUgYXV0aG9ycyBvZmYtbGluZSB3aGV0aGVy IGl0IGlzIGFwcHJvcHJpYXRlIHRvIGxvb3AgaW4gdGhlIENGUkcgZm9yIGRpc2N1c3Npb24gb2Yg dGhlIHNlY3VyaXR5IG9mIHRoZSBNdXR1YWwgQXV0aCBwcm90b2NvbC4NCg0KSVNTVUUgIzk6IEEg cmVxdWVzdCB3YXMgbWFkZSBmb3IgYSBzaW1wbGlmaWVkIGRlc2NyaXB0aW9uIG9mIHRoZSBlbnRp cmUgbWVjaGFuaXNtLiAoVGhhdCBpcywgb24gdGhlIGxldmVsIG9mICJBbGljZSBzZW5kcyB0aGlz IHRvIEJvYiBhbmQgdGhlbiBCb2IgcmVwbGllcyB3aXRoIHN1Y2ggYW5kIHN1Y2giLikgVGhlIGF1 dGhvcnMgd2lsbCBzZWUgaWYgdGhleSBjYW4gY29tZSB1cCB3aXRoIHNvbWV0aGluZyBhcHByb3By aWF0ZS4NCg0KDQoNCg== --001a11c33fd020c14d04e9c48525-- From y.oiwa@aist.go.jp Mon Oct 28 05:30: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 2572811E8228 for ; Mon, 28 Oct 2013 05:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.73 X-Spam-Level: X-Spam-Status: No, score=-0.73 tagged_above=-999 required=5 tests=[AWL=-5.110, BAYES_00=-2.599, FB_SMALL_PEN=10.357, 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 dz5DQoHzPYd6 for ; Mon, 28 Oct 2013 05:30:27 -0700 (PDT) Received: from na3sys010aog108.obsmtp.com (na3sys010aog108.obsmtp.com [74.125.245.84]) by ietfa.amsl.com (Postfix) with ESMTP id F014D11E8186 for ; Mon, 28 Oct 2013 05:30:25 -0700 (PDT) Received: from mail-vc0-f175.google.com ([209.85.220.175]) (using TLSv1) by na3sys010aob108.postini.com ([74.125.244.12]) with SMTP ID DSNKUm5Y4f2933EOBH28azsE7VrflA5prRIc@postini.com; Mon, 28 Oct 2013 05:30:26 PDT Received: by mail-vc0-f175.google.com with SMTP id ht10so2012889vcb.20 for ; Mon, 28 Oct 2013 05:30:25 -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=eS3vO1d+Bb/deMC9Fbov8lQzTue2/yfNlcX4ko8PaXc=; b=rO+2Q017oiw2RTX6kOktkQrcO3t4VOR1KLzOW4LCvzR/pB8iRTsKRnH8WVLwRuYI5K +bD7zXVBhNuSTezHnYtL2ogmgyBHGZ1ka7qEZzQRoecIVgc93ucm1V0ta6KTjWjJkWX+ Yy9/KONjvPmD322y5VJjDuyYmk1G7nkGW3fKc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=eS3vO1d+Bb/deMC9Fbov8lQzTue2/yfNlcX4ko8PaXc=; b=Ob2aVCTDGm31OzNJ/EmZpfMMe5mePe2xgQk74dNFTXDqoip56+lStE3WvaD+MA2Bc0 dIYGnvSEh5kZL0Tq7x9o2zg2P0fiLNertekWVmmzr1dc280fK4b2hM4VrKpOVQD6huY6 gLpNwuibX38kU+HZaxNpDC69I1kOPXYq9Y9SbXarOoaScyNJUX+9kIJbaNUvhUx67tiz TFGlKUtYXQGtxtrXoneWX6i2IO2+Ozo1LG0vE180dcg/wf/sQjUBTHly+J1mf7+ZCBGF +4anTJrLnTZPXWZSx+Ip9a0LP9gGt7Zv5Gwn5J8YbD4Mrrzeb+chZ+5zouCUdIRjWuLA SwMA== X-Gm-Message-State: ALoCoQmltsG6oF4ZKkEAdLsuXWsSE3MQRTuVSYMWAxF1gwXzJelGKAjW1lrzoodgC1bDKbAjnFBilSqK82U6vl//DTa5Xtep2rnYAg44+w8E8PUaD0CJgz0bJQEWDNPJWggNVI5pLg3uw6DLb6RLx6xgwYZdjF5hvA== X-Received: by 10.58.136.231 with SMTP id qd7mr13181181veb.1.1382963425202; Mon, 28 Oct 2013 05:30:25 -0700 (PDT) X-Received: by 10.58.136.231 with SMTP id qd7mr13181174veb.1.1382963425079; Mon, 28 Oct 2013 05:30:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.77.34 with HTTP; Mon, 28 Oct 2013 05:30:05 -0700 (PDT) In-Reply-To: References: From: Yutaka OIWA Date: Mon, 28 Oct 2013 21:30:05 +0900 Message-ID: To: Matthew Lepinski Content-Type: text/plain; charset=ISO-8859-1 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Minutes for October 8 Interim Meeting 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, 28 Oct 2013 12:30:33 -0000 Dear Matthew, thank you very much for taking the minutes! As an author of the draft, I found no significant issues there. There are several issues waiting my responses, for which I will send more detailed text there. Here is a quick response for some of these issues: > ISSUE #2: The authors are hesitant to use the mechanism in RFC 5929 > because they are concerned about the adoption status of RFC 5929 and > don't want a dependency on RFC 5929 to hinder implementation of the > mutal-auth mechanism. Several working group participants feel quite > strongly that RFC 5929 is the future, and that HTTPAUTH is well-served > to use the already-standardized channel binding mechanism. At this moment, "The authors were hesitant" became more appropriate :-) At the end of the discussion, I was finally convinced to the WG participants' idea mostly. I already posted -01 draft which has incorporated proposed changes. The discussion within the interim meeting gave me several good suggestive information to me, which removed most of my concern for running-code principle regarding it. Shortly, I am satisfied for being sure that, if we just implement it, it's enough, and people will not likely to call it unimplementable. So I have currently no more strong concern on adopting RFC 5929. Thank you very much for good suggestions. # There is one small pending issue there, for which I had already written # separately for deciding final adoption. > ISSUE #5: The next version of the Mutual-Auth draft will incorporate > the idea of how long the server should keep session information One correction from my side: there was already a feature which seems mostly equivalent to the requested one (time field). So I did not added any new feature for the -01 draft. If my understanding for the requested feature was wrong, please let me know and I will fix it. -- 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 lef.mutualauth@gmail.com Tue Oct 29 03:29: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 4EC1B11E822A for ; Tue, 29 Oct 2013 03:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 4nJlmH7UBCdI for ; Tue, 29 Oct 2013 03:29:16 -0700 (PDT) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 539AB11E822C for ; Tue, 29 Oct 2013 03:29:16 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id t61so8049325wes.13 for ; Tue, 29 Oct 2013 03:29:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=VfULYS71Zf2AeQu1QOgASjRg9Nw0hnleyXDhF4WahjI=; b=lNYDXaELW13x6+TconUxiimLP3tmoI4+h3TmqHpQt7322XLFytoUxzoVo4NPe6DgGZ 1VgAs8/v4o26P5xIoyuM73mHobj6bZ4JLz/yjwk60722nxmQd45hPzRteCaVWVjIb1Te QS/IYXXjpIRc9016zww/V6lg9QiYxRqEqaN5hbo/Zds/2aPiBw/jdJ5RsEA328QGnCty VAE5Un+MljduCFvliWWa7MBmsOrleX7r/e8gDkrDng9TqYJhxOjtZkLM8UwbwaUlx8SW 70e2mH8zcBW1sr1UzptBULBHjccCZmiYPZS7M/KSQAgCPiP7+nXuKszPiAwPw3ucEZTb pW2Q== X-Received: by 10.194.19.5 with SMTP id a5mr5836992wje.48.1383042555515; Tue, 29 Oct 2013 03:29:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.250.105 with HTTP; Tue, 29 Oct 2013 03:28:55 -0700 (PDT) From: "HAYASHI, Tatsuya" Date: Tue, 29 Oct 2013 19:28:55 +0900 Message-ID: To: Yutaka OIWA Content-Type: text/plain; charset=ISO-8859-1 Cc: Julian Reschke , Mark Nottingham , "" Subject: [http-auth] FYI: MutualAuth impl for Chromium (Re: Anyone on mailing list working for browser vendor [was Re: charter rev -03]) 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, 29 Oct 2013 10:29:17 -0000 Hi everyone, We was able to first prototype implementation MutualAuth for Chromium. source code release is coming soon. Thanks, On Thu, Feb 7, 2013 at 11:19 AM, Yutaka OIWA wrote: > 2013/2/6 Yoav Nir : >>> On 06/02/2013, at 2:54 AM, Julian Reschke wrote: >>> OTOH, two major browsers are Open Source projects; has anyone committed to keeping patches for them up-to-date, at least? >> >> AFAIK, out of the proposals that we've heard in Atlanta, only one (mutualAuth) has been implemented in a browser, and that was a patch over Firefox 3.5 (current version is 18) > > The FF implementation is available on > . > We're currently implementing the protocol also on Chromium source codes. > > -- > Yutaka OIWA, Ph.D. Leader, Software Reliability Research Group > Research Institute for Secure Systems (RISEC) > National Institute of Advanced Industrial Science and Technology (AIST) > Mail addresses: , > OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth -- HAYASHI, Tatsuya Lepidum Co. Ltd. From ynir@checkpoint.com Wed Oct 30 13:43: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 8CDD711E81AD for ; Wed, 30 Oct 2013 13:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.486 X-Spam-Level: X-Spam-Status: No, score=-10.486 tagged_above=-999 required=5 tests=[AWL=0.113, 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 MqfGBjcCAfW6 for ; Wed, 30 Oct 2013 13:42:57 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 041DD11E8191 for ; Wed, 30 Oct 2013 13:42:55 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r9UKgrVR025930 for ; Wed, 30 Oct 2013 22:42:53 +0200 X-CheckPoint: {52716E43-0-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.106]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Wed, 30 Oct 2013 22:42:53 +0200 From: Yoav Nir To: "http-auth@ietf.org" Thread-Topic: Agenda for Vancouver Thread-Index: AQHO1bCbaHxQuzXHnkOugrlOscTSDA== Date: Wed, 30 Oct 2013 20:42:53 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.118] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: <0A99B9843DE6F044861789EF37BB2B86@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [http-auth] Agenda for Vancouver 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, 30 Oct 2013 20:43:02 -0000 Hi I've just posted the agenda for the Vancouver meeting: http://www.ietf.org/proceedings/88/agenda/agenda-88-httpauth For your convenience, the entire text is below.=20 Please use the week or so that we have until the session to read and send r= eviews of the HOBA and RestAuth documents to the list Matt & Yoav The HTTP-Auth Working Group will meet in Vancouver. Time: Friday, November 8, at 9:00 AM local time (1700 UTC) Location: "Georgia B" The plan: 09:00 - Agenda bashing + blue sheets 09:05 - Report on virtual interim meeting (chairs) 09:10 - Status of non-duscussed drafts (scram, digest, basic, mutual-auth) 09:20 - HOBA (Stephen/Paul) 09:50 - RestAuth (Nico) 10:20 - Commonalities (Stephen) 10:50 - Open Mic See you all there.