From nobody Thu Aug 11 19:18:10 2016 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 DE54012B019 for ; Thu, 11 Aug 2016 19:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sONAA4x_Lr0I for ; Thu, 11 Aug 2016 19:18:07 -0700 (PDT) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D4C5127058 for ; Thu, 11 Aug 2016 19:18:07 -0700 (PDT) Received: by mail-ua0-x22a.google.com with SMTP id 74so22179894uau.0 for ; Thu, 11 Aug 2016 19:18:07 -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; bh=AvI/jJ4PrRp02JnUqFdyWU2kUDJUBNw661cnTVdPhCI=; b=VnspvhADqrOxhRIu6JYt06hgUawhHL8ibdgisyJQigtral9lsD9rmY1SvSyW9AlMNv xsLnvgLYbzDxghLxQmtOoEPw2pXLiroJ6VM6aHEIQ1bjxIePdxcXxmtsJVNvsRZKUv2y 99VT8C3VKepHcUMgJwqKPy7WQprc26FbOLiFHQCE99RSmsNlNDhlJz3HzqOByLsKMXOQ Pe2mBLGHEfJbgEhGM5ZCkapyPBhlnQrZSF/Twm+XgeztkQSTaMf3tKK5xBm38v4A6HO5 tYB0a4c3g8QUL3Le4HDbu6KcHzTxGfvFJ2jwCtZ7rj+I8jh26RbZDSoLUTKzWmmxRxlG N5Xw== 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; bh=AvI/jJ4PrRp02JnUqFdyWU2kUDJUBNw661cnTVdPhCI=; b=co6/gsJKhZwFzJMREoKO+h0+8zPqUHE02b2zly1Dx/lDLZAgUrWP3GNBOXrfyCoPoz Rafzt+3cCsRgBOnptYCvfBVS1Y4sMoKwdp+OHDXJa6VMwJVIRjAKriJQ+EAFiebrBthB RtiqjoMXzltSouHdfD8BhouKfbpcqC+HYr4OWwnkRNypyScQDejX8Pu+WqBkfmHymt5d q/pIVPu0pDo59F5ovSHMjlwBLRUavPN8Gg+PE+MTBcOBYwOmduipPDEzIQ3w4TZb1UYH /2fRfSB4+KaAiVLeFt5an2hvT0EkBsi2OpuLuTEjEenvXzBI7zgJlBQoC0OtOCOas/9D ThJg== X-Gm-Message-State: AEkooutOk4q1QD3grWozKYLgbIWe50kSHApg5iXu+mERK4jjvmuP+T46aSXTPeYtWnqjPSAtydlydW0Hldnjwg== X-Received: by 10.31.50.86 with SMTP id y83mr6430440vky.81.1470968286294; Thu, 11 Aug 2016 19:18:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.1.228 with HTTP; Thu, 11 Aug 2016 19:18:05 -0700 (PDT) From: Kathleen Moriarty Date: Thu, 11 Aug 2016 22:18:05 -0400 Message-ID: To: "http-auth@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [http-auth] AD review of draft-ietf-httpauth-mutual-08 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2016 02:18:09 -0000 Hello, Thank you for your work on draft-ietf-httpauth-mutual-08. I will try to get through my AD review of the accompanying draft tomorrow. I read through the draft and have the following questions. ----- Section 2.1, in the following text: o Authenticated key exchange messages: used by both peers to perform authentication and the sharing of a cryptographic secret. * req-KEX-C1 message: a message sent from the client. * 401-KEX-S1 message: a message sent from the server in response to a req-KEX-C1 message. 1. What does the response mean? Is there a pass/fail message in the response or is this just an ack that the message was received by the server to the client? Then in the following: * 200-VFY-S message: a client-authentication successful response used by the server, which also simultaneously asserts to the client that the server is authentic. 2. Maybe this will be clear as I read further through the draft, but that seems like a lot to assert at once. This note is a placeholder for me in case I do't feel like there is an adequate answer when I get deeper into the draft. ----- Second bullet on page 7: o At this point (5), both peers calculate a shared "session secret" using the exchanged values in the key exchange messages. Only when both the server and the client have used secret credentials generated from the same password will the session secret values match. This session secret will be used for access authentication of every individual normal after this point. 3. I think a word may be missing in the last sentence, can you rephrase it? I'm not able to parse it. ----- In another bullet on page 7: o If the authentication verification value from the client was correct, it means that the client definitely owns the credential based on the expected password (i.e., the client authentication succeeded). The server will respond with a successful message (200-VFY-S) (7). Contrary to the usual one-way authentication (e.g., HTTP Basic authentication or POP APOP authentication [RFC1939]), this message also contains a server-side authentication verification value. When the client's verification value is incorrect (e.g., because the user-supplied password was incorrect), the server will respond with the 401-INIT message (the same one as used in (2)) instead. 4. This last section should specify that the extensive-token indicating an authentication failure must be included. I would also recommend that this information be logged and have that stated in this draft. Since we are pushing for protocols to be encrypted, the use of sniffers to detect errors will continue to fall off and people will need to rely on logs more. I think it would be more helpful to have an accurate log that responds saying the authentication failed (user/password if you don't want to say which). Encouraging richer logs will be more helpful going forward. ----- In Section 7, just to make sure I am reading this correctly: The valid tokens for the validation parameter and corresponding values of vh are as follows: host: host-name validation: The value vh will be the ASCII string in the following format: "://:", where , , and are the URI components corresponding to the currently accessing resource. 5. By "currently accessing resource", you mean the source system, correct? It might be better to rephrase that so it is clear since this is important to developers. ----- 6. In Section 8, it is the reason parameter of the INIT that lets you know if t is 'valid', correct? Authentication-initializing messages with the Optional-WWW-Authenticate header are used only where the 401-INIT response is valid. It will not replace other 401-type messages such as 401-STALE and 401-KEX-S1. I think it would be helpful to explicitly state what is a valid response unless that is defined already and I missed it? I think it depends on the token or extensive token set in the reason parameter of the INIT message. ---- 7. In section 10.1, if you change "normal responses" to "normal response", it is easier to fix the grammar in the following sentences: This also holds true for the reception of "normal responses" (responses which do not contain Mutual authentication-related headers) from HTTP servers. change to: This also holds true for the reception of a "normal response" (responses which do not contain Mutual authentication-related headers) from HTTP servers. from: Any kinds of "normal responses" MUST only be accepted for the very first request in the sequence. Any "normal responses" returned for the second or later requests in the sequence SHALL be considered invalid. change to: Any kind of "normal response" MUST only be accepted for the very first request in the sequence. Any "normal response" returned for the second or later request in the sequence SHALL be considered invalid. ------ 8. Section 10.1, please consider rewording the following sentences to make it easier to read: o In the same principle, any responses which refer to or request changing to an authentication realm different from the client's request MUST only be accepted for the very first request in the sequence. Any kind of responses referring to different realms which are returned for the second or later requests in the sequence SHALL be considered invalid. ----- 9. In section 17.2, it might be helpful to include a reference to the TLS 1.2 BCP, RFC7525. The bullet might say something like, when TLS 1.2 is used, follow best practices in RFC7525. ----- 10. Section 17.3 is the first place I see a clear motivation for this protocol. It might help to have this stated in the introduction. Although the points about password attacks in section 17.2 leave me questioning how much of an improvement this really is. How much analysis was done on this new method? I know the drafts have been around for a while. I'd have to take another pass at the documents to dig deeper, but would like to know if this analysis was done. Can you make the statement that this is more secure? The motivation for HOBA was clear - getting rid of the use of passwords. Passwords are not sent in the clear, but this isn't stated in a motivation section. It just is part of the protocol and mentioned at the end of section 17.5. It might be helpful to include this in the introduction as well in a motivation paragraph. The abstract saying that, "server truly knows the user's encrypted password" isn't the same as saying that the password is encrypted on the wire and doesn't rely on transport encryption. ----- 11. Section 17.3. I'm not clear on this sentence in the last paragraph: Of course, in such cases, the user interfaces for asking passwords for this authentication shall be clearly identifiable against imitation by other insecure password input fields (such as forms). Common attacks of this nature would be to direct users to a form that isn't the real form. Is it the mutual authentication that helps here? If so, explain how. How is it clearly identifiable against imitation? -- Best regards, Kathleen From nobody Fri Aug 12 13:41:13 2016 Return-Path: X-Original-To: http-auth@ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A7DCA12D0A1; Fri, 12 Aug 2016 13:41:10 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <147103447064.13965.1874355638448058786.idtracker@ietfa.amsl.com> Date: Fri, 12 Aug 2016 13:41:10 -0700 Archived-At: Cc: http-auth@ietf.org, httpauth-chairs@ietf.org, draft-ietf-httpauth-extension@ietf.org Subject: [http-auth] Last Call: (HTTP Authentication Extensions for Interactive Clients) to Experimental RFC X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2016 20:41:11 -0000 The IESG has received a request from the Hypertext Transfer Protocol Authentication WG (httpauth) to consider the following document: - 'HTTP Authentication Extensions for Interactive Clients' as Experimental 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 2016-08-26. 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 specifies extensions for the HTTP authentication framework for interactive clients. Currently, fundamental features of HTTP-level authentication are insufficient for complex requirements of various Web-based applications. This forces these applications to implement their own authentication frameworks by means like HTML forms, which becomes one of the hurdles against introducing secure authentication mechanisms handled jointly by servers and user-agent. The extended framework fills gaps between Web application requirements and HTTP authentication provisions to solve the above problems, while maintaining compatibility with existing Web and non-Web uses of HTTP authentications. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-httpauth-extension/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-httpauth-extension/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Sun Aug 14 06:49:42 2016 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 B39C912D639 for ; Sun, 14 Aug 2016 06:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id reOKP1f9Uxk8 for ; Sun, 14 Aug 2016 06:49:39 -0700 (PDT) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89E4412D1DD for ; Sun, 14 Aug 2016 06:49:39 -0700 (PDT) Received: by mail-ua0-x232.google.com with SMTP id k90so42624155uak.1 for ; Sun, 14 Aug 2016 06:49:39 -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; bh=aluSqpiYbB7uEmASEtH5xMOB+hsFOoxE4HK/Y9Dxf0w=; b=Ryut0l+EmPw9AH7yfgxlb3gHPSkD+24aDmPIM5RCfRBbKH2ODqSJqYaOBR0elGYDej BoxuB8cCNJw2f6yAYiBTtgdbLR/WSVA3/t6EhLaY6Vy2NFCVFU7dVclMyTPpg0UFFqml Z1McfD781K/uAsLLo5XEOBh/1nZ+aMmDD0Qe+OfMX6f9nbkBp16+g4m9IIOGWO08MFnu EecsMqqy2lj4W2JqIEM08nG7p277od3X1Ny3rDxA/c6BgWAikej+TbK/YsG4HaNyNdp8 B6VzURlF1ypUej0L23AT1AXHZTBnHRhD/ngDd5HDA6FLEHANqGihHpt8grhD8QY9zqnZ ZeQQ== 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; bh=aluSqpiYbB7uEmASEtH5xMOB+hsFOoxE4HK/Y9Dxf0w=; b=LgvE1FP9+OwZgo4r4COJDkpTxV/sKkuA/Jbl1SOeKySFVujYTHxkxOxXRAI4XUWadP 5ugPHsOEm3Frg3243PQV9Uphd7ecWINg5a8rh2equpjT+7SpYY/Xob7FQij0uXd1wceW hl8lo5A/UFiLpSdpV7yM+jwzHpd+D5HkeBBvdLPiMghPKekzer5uIl0kvfZW2hGEHHir OiSdq4VOWLlYeyWNA9T75RV4wWdxQ5WYSPM2D1HeDfiSWGc5rqoRHTmTUByftuzPQ3A6 9ijGLoxaZUQqeZ07MXol6v3vvIX5W6lKkPmk/bv/oP/VKJrJ+JNNRSByjErGA5yYn6bA eVyA== X-Gm-Message-State: AEkoous0qz5iSnbAbjyS0ie7/v9m0F/V8Xgx33VUaE4zN84WOR0gyA787+9fT5UB93555rsNpzO+e515Rd+8nw== X-Received: by 10.159.53.1 with SMTP id o1mr1983182uao.15.1471182578634; Sun, 14 Aug 2016 06:49:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.1.228 with HTTP; Sun, 14 Aug 2016 06:49:38 -0700 (PDT) From: Kathleen Moriarty Date: Sun, 14 Aug 2016 09:49:38 -0400 Message-ID: To: "http-auth@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [http-auth] AD review of draft-ietf-httpauth-mutual-algo X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Aug 2016 13:49:41 -0000 Hello, I don't have any specific comments on this draft as I just reviewed the text and not the algorithms. The shepherd report says there was moderate review and this is experimental, so I'll put this into IETF last call with the core document, once I hear back from the authors on my comments of that draft. I'd like to hear back by early this week so the drafts can be put into IETF last call in tme to be on the telechat in a little over 2 weeks. Thanks. -- Best regards, Kathleen From nobody Tue Aug 16 19:45:45 2016 Return-Path: X-Original-To: http-auth@ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0787012D0AA; Tue, 16 Aug 2016 19:45:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147140193902.19855.15739307183373528390.idtracker@ietfa.amsl.com> Date: Tue, 16 Aug 2016 19:45:39 -0700 Archived-At: Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-mutual-09.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.17 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 02:45:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Hypertext Transfer Protocol Authentication of the IETF. Title : Mutual Authentication Protocol for HTTP Authors : Yutaka Oiwa Hajime Watanabe Hiromitsu Takagi Kaoru Maeda Tatsuya Hayashi Yuichi Ioku Filename : draft-ietf-httpauth-mutual-09.txt Pages : 57 Date : 2016-08-16 Abstract: This document specifies a mutual authentication scheme for the Hypertext Transfer Protocol (HTTP). This scheme provides true mutual authentication between an HTTP client and an HTTP server using password-based authentication. Unlike the Basic and Digest authentication schemes, the Mutual authentication scheme specified in this document assures the user that the server truly knows the user's encrypted password. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-mutual/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-httpauth-mutual-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-mutual-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 16 19:46:04 2016 Return-Path: X-Original-To: http-auth@ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9363412D613; Tue, 16 Aug 2016 19:45:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147140195959.19887.5823082639922197738.idtracker@ietfa.amsl.com> Date: Tue, 16 Aug 2016 19:45:59 -0700 Archived-At: Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-mutual-algo-06.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.17 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 02:45:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Hypertext Transfer Protocol Authentication of the IETF. Title : Mutual Authentication Protocol for HTTP: KAM3-based Cryptographic Algorithms Authors : Yutaka Oiwa Hajime Watanabe Hiromitsu Takagi Kaoru Maeda Tatsuya Hayashi Yuichi Ioku Filename : draft-ietf-httpauth-mutual-algo-06.txt Pages : 16 Date : 2016-08-16 Abstract: This document specifies cryptographic algorithms for use with the Mutual user authentication method for the Hyper-text Transport Protocol (HTTP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-mutual-algo/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-httpauth-mutual-algo-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-mutual-algo-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 16 19:46:17 2016 Return-Path: X-Original-To: http-auth@ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DEE6812D635; Tue, 16 Aug 2016 19:46:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147140197090.19913.4035796092550342940.idtracker@ietfa.amsl.com> Date: Tue, 16 Aug 2016 19:46:10 -0700 Archived-At: Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-extension-08.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.17 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 02:46:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Hypertext Transfer Protocol Authentication of the IETF. Title : HTTP Authentication Extensions for Interactive Clients Authors : Yutaka Oiwa Hajime Watanabe Hiromitsu Takagi Kaoru Maeda Tatsuya Hayashi Yuichi Ioku Filename : draft-ietf-httpauth-extension-08.txt Pages : 28 Date : 2016-08-16 Abstract: This document specifies extensions for the HTTP authentication framework for interactive clients. Currently, fundamental features of HTTP-level authentication are insufficient for complex requirements of various Web-based applications. This forces these applications to implement their own authentication frameworks by means like HTML forms, which becomes one of the hurdles against introducing secure authentication mechanisms handled jointly by servers and user-agent. The extended framework fills gaps between Web application requirements and HTTP authentication provisions to solve the above problems, while maintaining compatibility with existing Web and non-Web uses of HTTP authentications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-extension/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-httpauth-extension-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-extension-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Aug 29 14:06:01 2016 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 C3AB612D0BF for ; Mon, 29 Aug 2016 14:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9p3TqKsa48p for ; Mon, 29 Aug 2016 14:05:59 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8597012B032 for ; Mon, 29 Aug 2016 14:05:58 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id o80so4758386wme.1 for ; Mon, 29 Aug 2016 14:05:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:date:references:to:message-id:mime-version; bh=UlXmREDjPshBpXaj+Whd/UpaBKvGVmKWY3w1uQ3xH7w=; b=jYZXdecZwwAZpkWIAGcdn/OnujV4VIjOzq8Apdw8RMy4WxIAw7tHNKFFx26L+w5tCL RkN8j9S4DecQJT1A9Oy6y02jvtNVmiYhM4X5q6JxygC8znLyURtARf5s+vdwlW58N0vG lAoa7ON8UaQTU72AARIJ/Ai8qEu3wQTH2Dyl6TGBlZwSyAJ25ysCDxEAaIx0ol/V/Hjt rDuVyTyi/Q+FVmlnsEvC9SkKYUQnJDvVA8lE6QhCuVa7MdGag+uSkw0lHC1YcSJVPZ+f +4zTSLtlfust1DtINGWxzt+vyt2x7I3u6+WrTDk2jjxqDUGvOczFCdIMq8Cqnblj8DTz XxJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:date:references:to:message-id :mime-version; bh=UlXmREDjPshBpXaj+Whd/UpaBKvGVmKWY3w1uQ3xH7w=; b=RmjX8Ouy8DVR4GMjMI/5d02la6E8rNV/HNpplt3dumHtROjqzuWMH0ZMyhbGT3LbnT qDaYcmAN0SvrQkVxsPtqZ/NqLr0mQUlBHWZxYl+5sH1DoMz+ZK7fQqtkn4niFAOo1qZs lO7D8B8Juzk0b2vO4STThVVHcDQ1xA1eWpIkybJMGA+vwsfT06++Rr6KgKQWDUFEbv58 hL2JbVhEXyTbi6jrE2x2zkCGIxxlyV1PGv8sC/53MmoVTmkXju+oLFC4bV1+FBRRvKcC fPRb8vM3D1vEJHf4YnfNwAS2ivKqKhxUg5CqVnoXNLbf9SlRuGBAovpZwuVi0mnGCq/1 w+0A== X-Gm-Message-State: AE9vXwNnDkRViDVz82NcXPPTPe4tQzSlt9EKzymSHefzjxiR3EYSL3IKjptwNXXfcefHRQ== X-Received: by 10.28.100.70 with SMTP id y67mr13017526wmb.23.1472504756665; Mon, 29 Aug 2016 14:05:56 -0700 (PDT) Received: from [192.168.1.14] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id c16sm557621wme.4.2016.08.29.14.05.55 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 29 Aug 2016 14:05:55 -0700 (PDT) From: Yoav Nir Content-Type: multipart/alternative; boundary="Apple-Mail=_6E17B4C6-4538-4E3A-AC62-2F08EDA71D81" Date: Tue, 30 Aug 2016 00:05:58 +0300 References: <147250302871.19142.11825877398134368393.idtracker@ietfa.amsl.com> To: httpauth mailing list Message-Id: <55DDFC1D-BC3C-477B-8705-FF88CFA543F3@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [http-auth] Fwd: NomCom 2016-2017: Call for Nominations X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2016 21:06:00 -0000 --Apple-Mail=_6E17B4C6-4538-4E3A-AC62-2F08EDA71D81 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Please consider nominating yourselves or others. > Begin forwarded message: >=20 > From: NomCom Chair 2016 > Subject: NomCom 2016-2017: Call for Nominations > Date: 29 August 2016 at 11:37:08 PM GMT+3 > To: "Working Group Chairs" > Reply-To: ietf@ietf.org >=20 > Please forward on to your Working Groups -=20 >=20 > The 2016-17 Nominating Committee (Nomcom) is seeking nominations from > now until October 8, 2016. The open positions being considered by this > year's Nomcom can be found at the end of this email and also on this > year's Nomcom website: >=20 > https://datatracker.ietf.org/nomcom/2016/ >=20 > Nominations may be made by selecting the Nominate link at the top of > the Nomcom 2016 home page, or by visiting the following URL: >=20 > https://datatracker.ietf.org/nomcom/2016/nominate/ >=20 > {Note that nominations made using the web tool require an ietf.org > datatracker account. You can create a datatracker ietf.org account > if you don't have one already by visiting the following URL: > https://datatracker.ietf.org/accounts/create/ } >=20 > If you are unable to use the web form, nominations may instead be made > by email to nomcom-16@ietf.org. If using email, please include the = word > "Nominate" in the Subject and indicate in the email who is being > nominated, their email address (to confirm acceptance of the > nomination), and the position for which you are making the nomination. > If you are nominating someone other than yourself, please tell us if > we may tell the nominee that you were the one who made the nomination. > If you wish to nominate someone via email for more than one position, > please use separate emails to do so. >=20 > Self-nomination is welcome! >=20 > Willing nominees will be asked to fill out a questionnaire > specific to the position for which they are nominated. The = questionnaires > will be available on September 2, 2016 and have a submission deadline = of > October 13, 2016. >=20 > NomCom 2016-17 will follow the policy for "Open Disclosure of Willing > Nominees" described in BCP 10/RFC 7437. As stated in RFC 7437: "The > list of nominees willing to be considered for positions under review > in the current Nomcom cycle is not confidential". Willing nominees for > each position will be listed in a publicly accessible way - anyone > with a datatracker account may access the lists. Additionally, the > nomination form asks if we may share your own name with the > nominee. In all other ways, the confidentiality requirements of BCP10 > remain in effect. All feedback and all Nomcom deliberations will > remain confidential and will not be disclosed. >=20 > There is a field on the form you can mark in order to allow the Nomcom > to tell the nominee that you were the one who made the > nomination. This defaults to =E2=80=9Cno=E2=80=9D - so if you don't = mark the field > we won=E2=80=99t tell. >=20 > In order to ensure time to collect sufficient community feedback about > each of the willing nominees, nominations must be received by the > NomCom on or before October 8, 2016. >=20 > Please submit your nominations as early as possible for the sake of > your nominees. Note that nominations should not wait for management > permission, as it is easier to decline the nomination than put one in > late. >=20 > The Nomcom appoints individuals to fill the open slots on the IAOC, > the IAB, and the IESG. The list of people and posts whose terms end > with the March 2017 IETF meeting, and thus the positions for which > this Nomcom is responsible, follows: >=20 > IAOC >=20 > Lou Berger >=20 > IAB >=20 > Ralph Droms* > Russ Housley* > Robert Sparks > Andrew Sullivan > Dave Thaler* > Suzanne Woolf >=20 > IESG >=20 > Jari Arkko (GEN)* > Deborah Brungard (RTG) > Ben Campbell (ART) > Spencer Dawkins (TSV) > Stephen Farrell (SEC)* > Joel Jaeggli (OPS)* > Terry Manderson (INT) > Alvaro Retana (RTG) >=20 > *- have indicated that they do not intend to accept a > renomination. This information is always up to date on > https://datatracker.ietf.org/nomcom/2016/ >=20 > Please be resourceful in identifying possible candidates for these > positions, as developing our talent is a very crucial requirement for > the IETF, and also, please consider accepting a nomination. You'll > find extensive information about specific positions, developed by the > IAB, IESG, and IAOC, under individual tabs at: >=20 > https://datatracker.ietf.org/nomcom/2016/requirements/ >=20 > In addition to nominations, the Nomcom seeks community input on the > positions themselves. We need and welcome the community's views and > input on the jobs within each organization. If you have ideas on the > positions' responsibilities (more, less, different), please let us > know. >=20 > Please send suggestions and feedback about this to nomcom-16@ietf.org. >=20 > Thank you for your help in identifying qualified nominees! >=20 > Lucy Lynch > Nomcom Chair 2016-17 > nomcom-chair-2016@ietf.org > llynch@civil-tongue.net >=20 --Apple-Mail=_6E17B4C6-4538-4E3A-AC62-2F08EDA71D81 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi

Please = consider nominating yourselves or others.


Begin forwarded message:

From: = NomCom Chair 2016 <nomcom-chair-2016@ietf.org>
Subject: = NomCom 2016-2017: = Call for Nominations
Date: = 29 August 2016 at 11:37:08 PM = GMT+3
To: = "Working Group Chairs" <wgchairs@ietf.org>
Reply-To: = ietf@ietf.org

Please forward on to your = Working Groups -

The 2016-17 Nominating = Committee (Nomcom) is seeking nominations from
now until = October 8, 2016. The open positions being considered by this
year's Nomcom can be found at the end of this email and also = on this
year's Nomcom website:

https://datatracker.ietf.org/nomcom/2016/
Nominations may be made by selecting the Nominate link at = the top of
the Nomcom 2016 home page, or by visiting the = following URL:

https://datatracker.ietf.org/nomcom/2016/nominate/

 {Note that nominations made using the = web tool require an ietf.org
  datatracker = account. You can create a datatracker ietf.org account
=   if you don't have one already by visiting the following = URL:
=   https://datatracker.ietf.org/accounts/create/ }

If you are unable to use the web form, = nominations may instead be made
by email to = nomcom-16@ietf.org. If using email, please include the word
"Nominate" in the Subject and indicate in the email who is = being
nominated, their email address (to confirm = acceptance of the
nomination), and the position for which = you are making the nomination.
If you are nominating = someone other than yourself, please tell us if
we may tell = the nominee that you were the one who made the nomination.
If you wish to nominate someone via email for more than one = position,
please use separate emails to do so.

Self-nomination is welcome!

Willing nominees will be asked to fill out a questionnaire
specific to the position for which they are nominated. =  The questionnaires
will be available on September 2, = 2016 and have a submission deadline of
October 13, = 2016.

NomCom 2016-17 will follow the policy = for "Open Disclosure of Willing
Nominees" described in BCP = 10/RFC 7437.  As stated in RFC 7437: "The
list of = nominees willing to be considered for positions under review
in the current Nomcom cycle is not confidential". Willing = nominees for
each position will be listed in a publicly = accessible way - anyone
with a datatracker account may = access the lists.  Additionally, the
nomination form = asks if we may share your own name with the
nominee. In = all other ways, the confidentiality requirements of BCP10
remain in effect.  All feedback and all Nomcom = deliberations will
remain confidential and will not be = disclosed.

There is a field on the form you = can mark in order to allow the Nomcom
to tell the nominee = that you were the one who made the
nomination. This = defaults to =E2=80=9Cno=E2=80=9D - so if you don't mark the field
we won=E2=80=99t tell.

In order = to ensure time to collect sufficient community feedback about
each of the willing nominees, nominations must be received by = the
NomCom on or before October 8, 2016.

Please submit your nominations as early as possible for the = sake of
your nominees. Note that nominations should not = wait for management
permission, as it is easier to decline = the nomination than put one in
late.

The Nomcom appoints individuals to fill the open slots on the = IAOC,
the IAB, and the IESG. The list of people and posts = whose terms end
with the March 2017 IETF meeting, and thus = the positions for which
this Nomcom is responsible, = follows:

IAOC

=    Lou Berger

IAB

   Ralph Droms*
=    Russ Housley*
   Robert = Sparks
   Andrew Sullivan
=    Dave Thaler*
   Suzanne = Woolf

IESG

=    Jari Arkko (GEN)*
=    Deborah Brungard (RTG)
=    Ben Campbell (ART)
=    Spencer Dawkins (TSV)
=    Stephen Farrell (SEC)*
=    Joel Jaeggli (OPS)*
=    Terry Manderson (INT)
=    Alvaro Retana (RTG)

*- = have indicated that they do not intend to accept a
renomination. This information is always up to date on
https://datatracker.ietf.org/nomcom/2016/

Please be resourceful in identifying possible candidates for = these
positions, as developing our talent is a very = crucial requirement for
the IETF, and also, please = consider accepting a nomination.  You'll
find = extensive information about specific positions, developed by the
IAB, IESG, and IAOC, under individual tabs at:

=  https://datatracker.ietf.org/nomcom/2016/requirements/

In addition to nominations, the Nomcom seeks = community input on the
positions themselves.  We need = and welcome the community's views and
input on the jobs = within each organization. If you have ideas on the
positions' responsibilities (more, less, different), please = let us
know.

Please send = suggestions and feedback about this to nomcom-16@ietf.org.

Thank you for your help in identifying = qualified nominees!

Lucy Lynch
Nomcom Chair 2016-17
nomcom-chair-2016@ietf.org
llynch@civil-tongue.net


= --Apple-Mail=_6E17B4C6-4538-4E3A-AC62-2F08EDA71D81-- From nobody Wed Aug 31 08:35:20 2016 Return-Path: X-Original-To: http-auth@ietf.org Delivered-To: http-auth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D9A7A12D68F; Wed, 31 Aug 2016 08:35:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alexey Melnikov" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.31.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147265771884.13268.6076428520221464112.idtracker@ietfa.amsl.com> Date: Wed, 31 Aug 2016 08:35:18 -0700 Archived-At: Cc: http-auth@ietf.org, httpauth-chairs@ietf.org, draft-ietf-httpauth-extension@ietf.org Subject: [http-auth] Alexey Melnikov's No Objection on draft-ietf-httpauth-extension-08: (with COMMENT) X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.17 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 15:35:19 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-httpauth-extension-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-httpauth-extension/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In Section 2.2: bare-token = 1*(%x30-39 / %x41-5A / %x61-7A / "-" / "_") Did you intent to allow leading "-" (and possibly "_") above? As you are using "-." for private extensions, I think the ABNF is not right. I think you meant: lead-token-char = (%x30-39 / %x41-5A / %x61-7A / "_") bare-token = lead-token-char *(%x30-39 / %x41-5A / %x61-7A / "-" / "_") In Section 3, last paragraph: Support of this header is OPTIONAL; clients MAY also implement this extension only for some selected authentication schemes. New authentication schemes can make support of the optional authentication mandatory by its specification, though. I don't think this paragraph is needed, as this is granted, because support for any extension like specified in this document is optional. So I suggest deleting it. Section 3.1: I am still not convinced that Optional-WWW-Authenticate is needed, but the section provides a reasonable overview of the current situation. In Section 4: Support of this header is OPTIONAL, and clients MAY choose any subset of these parameters to be supported. The set of supported parameters MAY also be authentication scheme-dependent. However, some authentication schemes can require mandatory/recommended support for some or all of the features provided in this header. As above, I don't think this paragraph is needed. 4.4. No-auth parameter This parameter SHOULD NOT be used along with the location-when-unauthenticated parameter. Why is this only a SHOULD NOT (or to rephrase it: what are possible conditions for violating this)? If both were supplied, clients MAY choose which one is to be honored. I would rather you pick one behaviour in order to improve interoperability. In 4.5: When the user requests termination of an authentication period, and if the client currently displays a page supplied by a response with this parameter, the client will be redirected to the specified location by a new GET request (as if it received a 303 response). Is this value advisory? Should the client go to this page automatically or would the server redirect it? If the latter, why does this need to be told to the client? The log-out operation (e.g. erasing memories of user name, authentication credential and all related one-time credentials such as nonce or keys) SHOULD occur before processing a redirection. 4.6. Logout-timeout parameter The parameter "logout-timeout", when contained in a successfully- authenticated response, means that any authentication credentials and state related to the current protection space are to be discarded if a time specified in this header (in seconds) has passed since from the time this header was received. The value MUST be an integer. As a special case, the value 0 means that the client is requested to immediately log-out from the current authentication space and revert to an unauthenticated status. It sounds like this is not just a request, but the client will be logged out. If this is correct, then you should reword this, for example: As a special case, the value 0 means that the server is logging the client out immediately from the current authentication space and that the client is now returns to unauthenticated state.