Feedback on draft-thomson-httpbis-catch

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

Received on Tuesday, 11 March 2014 07:46:45 UTC