Feedback on draft-thomson-httpbis-catch
Julian Reschke <julian.reschke@gmx.de> Tue, 11 March 2014 07:49 UTC
Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB21B1A024B for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 11 Mar 2014 00:49:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.449
X-Spam-Level:
X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MgmvKjgBvS2s for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 11 Mar 2014 00:49:19 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 05ED81A02A0 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 11 Mar 2014 00:49:17 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1WNHOr-00070D-Oq for ietf-http-wg-dist@listhub.w3.org; Tue, 11 Mar 2014 07:46:57 +0000
Resent-Date: Tue, 11 Mar 2014 07:46:57 +0000
Resent-Message-Id: <E1WNHOr-00070D-Oq@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <julian.reschke@gmx.de>) id 1WNHOf-0006ye-Im for ietf-http-wg@listhub.w3.org; Tue, 11 Mar 2014 07:46:45 +0000
Received: from mout.gmx.net ([212.227.15.18]) by lisa.w3.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from <julian.reschke@gmx.de>) id 1WNHOe-0000Uo-AC for ietf-http-wg@w3.org; Tue, 11 Mar 2014 07:46:45 +0000
Received: from [192.168.2.117] ([84.187.63.218]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0Lgql4-1Wz2470Vc6-00oCGD; Tue, 11 Mar 2014 08:46:17 +0100
Message-ID: <531EBF44.9080902@gmx.de>
Date: Tue, 11 Mar 2014 08:46:12 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
References: <CABkgnnU1RMHN8sGsRc_KSw3+EutZnrrb-N=WpzP5wuqQ-ECe7Q@mail.gmail.com> <CABkgnnWDu301rXkX2u-AhptkSEr9AJb3LGJ3wfvVbhD0Oy4H6g@mail.gmail.com>
In-Reply-To: <CABkgnnWDu301rXkX2u-AhptkSEr9AJb3LGJ3wfvVbhD0Oy4H6g@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:dY2ouExBlJHW1Jo8cFdR+Z9rkoDzcQYyiEL7ksuAmnnvgLgV0bO 7pVPl9/kaFX/MpPIfhHmaybUX1exlEpemXCa5UF3g428jd1DUoljkD946pEpwjDGnQCnrNq +VSFn+sFkFhOS9Yik2NiBrvYV3mot8d3kquZrxyCMkxWr2uYPxd9cP5GZL07l2HXTE1tdpW yM8SajY8ix953oJKz7QAQ==
Received-SPF: pass client-ip=212.227.15.18; envelope-from=julian.reschke@gmx.de; helo=mout.gmx.net
X-W3C-Hub-Spam-Status: No, score=-3.4
X-W3C-Hub-Spam-Report: AWL=-3.392, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1WNHOe-0000Uo-AC 80d33610ce4b5d06c75bb503452ccc0f
X-Original-To: ietf-http-wg@w3.org
Subject: Feedback on draft-thomson-httpbis-catch
Archived-At: <http://www.w3.org/mid/531EBF44.9080902@gmx.de>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/22616
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
On 2014-03-09 08:37, Martin Thomson wrote: > On 8 March 2014 11:39, Martin Thomson <martin.thomson@gmail.com> wrote: >> Pursuant to our discussion on TLS renegotiation, I've submitted part 1 >> of the solution I proposed as an internet draft. >> >> http://datatracker.ietf.org/doc/draft-thomson-tls-care/ >> >> If we agree to a mechanism whereby we augment the 401 status code with >> a "go away and make a new TLS connection with client authentication", >> then this is necessary, so that the server knows to request a client >> certificate. > > Now with part 2: > > http://datatracker.ietf.org/doc/draft-thomson-httpbis-catch/ LGTM, so what's below is mainly nitpicking: > Abstract > > This document defines an HTTP header field that can be added to a > response to indicate to a client that a response will only be > provided over a TLS connection, and only if the client has provided a > certificate on that connection. No, it doesn't define a header field, but a new auth scheme... > 1. Introduction > > > Client authentication in HTTP sometimes relies on certificate-based > authentication of clients in TLS. Some uses of client authentication TLS -> expand & reference on first use. > rely on Transport Layer Security (TLS) [RFC5246] renegotiation, > triggering renegotiation in response to a request for a particular > resource. > > HTTP/2 [I-D.ietf-httpbis-http2] forbids the use of renegotiation, > except for at the very beginning of a connection. This makes > addressing some client authentication use cases difficult. Not in the referenced version of the draft, right? > This document defines a new type of authentication scheme, > "ClientCertificate" for use in HTTP authentication challenges > [I-D.ietf-httpbis-p7-auth]. In combination with the 401 > (Unauthorized) status code, this indicates that the resource requires > client authentication at the TLS layer in order to access it. > > 1.1. Conventions and Terminology > > > At times, this document falls back on shorthands for establishing > interoperability requirements on implementations: the capitalized > words "MUST", "SHOULD" and "MAY". These terms are defined in > [RFC2119]. ID-Nits insists on the full list of keywords, even if you don't need them. > 2. Client Certificate Challenge > > > A new kind of authentication scheme (auth-scheme > [I-D.ietf-httpbis-p7-auth]) for the "WWW-Authenticate" and "Proxy- > Authenticate" header fields is defined with the name > "ClientCertificate". I don't think you need to introduce "auth-scheme". Just say "authentication scheme". > A challenge with this auth-scheme does not define the use of any "This authentication scheme does not define any parameters except 'realm'"...? > parameters other than "realm". Other parameters MAY be used to > provide a client with information it can use to select an appropriate > certificate. Unknown parameters MUST be ignored. Do we need to be more specific? Is there something that could be standardized here? > HTTP/2 [I-D.ietf-httpbis-http2] allows clients to use the same > connection for multiple origins [RFC6454]. Certificate-based client HTTPbis P7 uses "canonical root URI" (<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p7-auth-26.html#rfc.section.2.2>) - maybe we can avoid the RFC6454 reference here? > authentication as defined by this specification is bound to a single > origin. This could create issues whereby the security properties of > a connection could become confused. Clients MUST ensure that a > client-authenticated connection is only used for the origin for which > it was created. > > 4. IANA Considerations > > > IANA will [has] create[d] an entry in the HTTP Authentication Scheme > Registry with the following information: Just state the intent, the RFC Production Center will rewrite the sentence. > ClientCertificate > > RFCXXXX (this document) Just say "this document"; IANA knows what to do. > This scheme does not rely on the Authorization header field. > 5. Acknowledgements > > > Eric Rescorla helped identify the problem and formulate this > mechanism. Julian Reschke hasn't provided any contribution yet, but > he will. That is now incorrect :-) > [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., > Leach, P., Luotonen, A., and L. Stewart, "HTTP > Authentication: Basic and Digest Access Authentication", > RFC 2617, June 1999. Not used. > [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax > Specifications: ABNF", STD 68, RFC 5234, January 2008. Not used. Best regards, Julian
- FYI: proposal for client authentication in TLS Martin Thomson
- Re: FYI: proposal for client authentication in TLS Ilari Liusvaara
- Re: FYI: proposal for client authentication in TLS Martin Thomson
- Re: FYI: proposal for client authentication in TLS Ilari Liusvaara
- Re: FYI: proposal for client authentication in TLS Martin Thomson
- Re: FYI: proposal for client authentication in TLS henry.story@bblfish.net
- Re: FYI: proposal for client authentication in TLS Ilari Liusvaara
- Re: FYI: proposal for client authentication in TLS Martin Thomson
- Re: FYI: proposal for client authentication in TLS Martin Thomson
- Re: FYI: proposal for client authentication in TLS Julian Reschke
- Re: FYI: proposal for client authentication in TLS Martin Thomson
- Re: FYI: proposal for client authentication in TLS Julian Reschke
- Re: FYI: proposal for client authentication in TLS Martin Thomson
- Re: FYI: proposal for client authentication in TLS Julian Reschke
- Re: FYI: proposal for client authentication in TLS Yoav Nir
- Re: FYI: proposal for client authentication in TLS Julian Reschke
- Feedback on draft-thomson-httpbis-catch Julian Reschke
- Re: FYI: proposal for client authentication in TLS Yoav Nir
- Re: FYI: proposal for client authentication in TLS Julian Reschke
- Re: Feedback on draft-thomson-httpbis-catch Martin Thomson
- Re: FYI: proposal for client authentication in TLS Martin Thomson
- Re: Feedback on draft-thomson-httpbis-catch Julian Reschke
- Re: FYI: proposal for client authentication in TLS Yoav Nir
- Re: FYI: proposal for client authentication in TLS Yoav Nir
- Re: FYI: proposal for client authentication in TLS Martin Thomson
- Re: FYI: proposal for client authentication in TLS Michael Köller
- Re: FYI: proposal for client authentication in TLS Martin Thomson