Subject: FYI: proposal for client authentication in TLS

From: Martin Thomson <[email-masked]>
Date: Sat, 8 Mar 2014 11:39:12 +0000

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.

--Martin

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 8 Mar 2014 14:43:48 +0200

> then this is necessary, so that the server knows to request a client

Some comments:
- Reference to RFC 5764 (which is some DTLS extension). Did you mean
  RFC 6347 (DTLS 1.2)?
- "[...]need to authenticate can initial renegotiation, [...]".
  That sounds odd, should it be "initial" or "initiate"?
- Under what circumstances server ignores the extension even if it
  is supported?

Some points:
- If the client has other active streams there, away might not be
  apropirate.
- The 401 www-authenticate header value might contain some information
  about acceptable client certificates (similarly to TLS 
  CertificateRequest), so the client can pick apropriate cerificate
  before initiating new connection.
- The proper client certificate might have been issued by the server
  or service provoder. Or even be self-signed[1].

[1] I haven't seen self-signed client certs for HTTPS, but I have
seen those for e.g. IRCS (Internet Relay Chat over TLS).

-Ilari

---

From: Martin Thomson <[email-masked]>
Date: Sat, 8 Mar 2014 14:13:45 +0000

> - Reference to RFC 5764 (which is some DTLS extension). Did you mean

Yes.  I got my numbers mixed up.

>   That sounds odd, should it be "initial" or "initiate"?

"initiate"

> - Under what circumstances server ignores the extension even if it

When it doesn't want to authenticate.  Maybe it's under DoS attack.
Who knows, that's their business.

> - If the client has other active streams there, away might not be

I don't know what you mean here.

>   before initiating new connection.

Yes.  That's probably "realm".  But the intent is not to define how a
client might select an appropriate certificate.  The
CertificateRequest contains some info too.

>   or service provoder. Or even be self-signed[1].

As above.

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 8 Mar 2014 17:04:37 +0200

> I don't know what you mean here.

Say, website A is open in another tab, and it is using resources from
website B (at worst a long download or websocket connection). And
website B wants client to authenticate with client cert...

In some cases, "clean" close might take days...

And I would prefer other random websites not to use connections to
other websites with extra ambient authority (nevermind that those requests
should be flaggged).

> CertificateRequest contains some info too.

I was thinking if the client could select the certificate before
connecting again...

This isn't the same as realm, but realm could be useful piece of
information for the client to act upon and display...

-Ilari

---

From: Martin Thomson <[email-masked]>
Date: Sat, 8 Mar 2014 15:45:23 +0000

> other websites with extra ambient authority (nevermind that those requests

Ahh, you have jumped to the conclusion regarding connection
coalescing, which is good.  I have text in the security considerations
of the next draft that covers this.  Connections with client
authentication should not be coalesced, to avoid this problem.

> I was thinking if the client could select the certificate before

As for certificate selection, I don't think that we need anything more
than what we already have.  Today, we have zero.  With this, we would
have realm, and extension parameters, which I don't think that we can
sensibly define anything for.

--Martin

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 8 Mar 2014 17:56:48 +0200

> sensibly define anything for.

IIRC, for certificate selection, TLS sends DNs of acceptable certificate
authorities. Of course, that won't help with self-signed client
certificate...

-Ilari

---

From: Martin Thomson <[email-masked]>
Date: Sat, 8 Mar 2014 15:58:33 +0000

> authorities. Of course, that won't help with self-signed client

True.  In cases where clients use self-signed certificates they have
a-priori knowledge, or something bound to the domain name or origin of
the server, that they use to select these certificates.

---

From: Martin Thomson <[email-masked]>
Date: Sun, 9 Mar 2014 07:37:20 +0000

> then this is necessary, so that the server knows to request a client

Now with part 2:

http://datatracker.ietf.org/doc/draft-thomson-httpbis-catch/

---

From: Julian Reschke <[email-masked]>
Date: Sun, 09 Mar 2014 20:00:26 +0100

> http://datatracker.ietf.org/doc/draft-thomson-httpbis-catch/

My feedback: That part has a funny sentence in the acknowledgments 
section which may need to be rephrased.

Best regards, Julian

---

From: Martin Thomson <[email-masked]>
Date: Mon, 10 Mar 2014 08:39:46 +0100

You mean to say that my ABNF isn't wrong?

---

From: Julian Reschke <[email-masked]>
Date: Mon, 10 Mar 2014 08:45:22 +0100

On 2014-03-10 08:39, Martin Thomson wrote:
> On Mar 9, 2014 8:00 PM, "Julian Reschke" <[email-masked]
> <mailto:[email-masked]>> wrote:

All the ABNF I saw looked right to me.

Best regards, Julian

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 10 Mar 2014 10:16:01 +0100

> http://datatracker.ietf.org/doc/draft-thomson-httpbis-catch/

I really like both of these.  I allready responded on the TLS mailing list
about draft-thomson-tls-care [1]. For draft-thomson-httbis-catch I would
like to suggest an improvement that would be essential for "self-signed"
or rather "unknown server signed" certificates, i.e., certificates signed
by some server that is not a CA. This allows for much more widespread
creation of client certificates, since they don't anymore need to be
verified by a few CAs, but instead allows the deployment of a web of
trust - a linked data web of trust to be precise. This allows one client
side certificate to be used to sign on to any web site.

A WebID is just an http(s) URL that refers to an Agent ( human, robot, 
organisation, ...) We have defined it in the spec "WebID 1.0" [2]. One
can then place a WebID in the Subject Alternative Name (SAN) field of an X509 
certificate as shown  in WebID Authentication over TLS [3] ( or even in the 
Issuer Alternative Name field (IAN)). The last spec relies on TLS as it is
currently, but would be redundant if draft-thomson-httpbis-catch went through.
(Until wide deployment of TLS1.3 which I suppose may take some time). 

Now I am not absolutely sure where this improvement I want to suggest, 
needs to be added: at the HTTP layer, or at the TLS layer. Currently TLS
allows a server to specify using the certificate_authorities list what
the list of Certificate Authorities the server accepts, so that the client
does not send Certificates that are not signed by one that is known to the server,
and which the server would then have to refuse.
But with WebID Authentication we don't need a CA, so it would be nice to be
able to specify that the server knows how to do WebID verification, ie part
5 and 6 of 
  http://www.w3.org/2005/Incubator/webid/spec/tls/#authentication-sequence
bB
If in TLS the server sends the empty certificate_authorities list. But that
is too wide, since that means the client can send ANY Certificate. The
server may not know what to do with most of them ( other than perhaps
identify the user indirectly by the public key, but that is only minimally
interesting - it does not allow one to build a web of trust ). 
 
My guess is that since this could evolve faster than the TLS layer, it may
be better if this were done in the HTTP header. So perhaps a header like

  WWW-Authenticate: ClientCertificate,SAN=WebID

would do. One could also imagine a 

  WWW-Authenticate: ClientCertificate,IAN=WebID

so that services with a lot of WebIDs could allow people to verify certificates
by verifying the issuer. A client seeing this would know that if the
server sent the empty certificate_authorities list, that it could filter its
available certificates by those that have the SAN or IAN fields filled in.

We have quite a few implementations of WebID on numerous servers, and in
pretty much every language, and we are finding it very useful. To get
a full overview of how this ties into a bigger picture including Web Access
Control, other authentication schemes, Linked Data Protocol,  etc... see our main 
intro page

  http://www.w3.org/2005/Incubator/webid/spec/

Hope this helps.

  Henry

[1] http://www.ietf.org/mail-archive/web/tls/current/msg11449.html
[2] http://www.w3.org/2005/Incubator/webid/spec/identity/
[3] http://www.w3.org/2005/Incubator/webid/spec/tls/

Social Web Architect
http://bblfish.net/

---

From: Martin Thomson <[email-masked]>
Date: Mon, 10 Mar 2014 10:39:05 +0100

On 10 March 2014 10:16, [email-masked] <[email-masked]> wrote:
> Currently TLS

My reading of the certificate_authorities text is that it can be
ignored, if " there is some external arrangement to the contrary" --
http://tools.ietf.org/html/rfc5246#section-7.4.4

>   WWW-Authenticate: ClientCertificate,SAN=WebID

This seems like a reasonable extension is exactly an "external
arrangement" as above.  That's certainly how I'd do it.

Given the time-critical nature of this work, I'm reluctant to add
anything extra in the current draft, but I don't see any reason that a
new specification couldn't define this sort of extension.  I have no
opinion about whether this needs to be defined here in the IETF, or
elsewhere, but I'm not aware of a rule that prevents either.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 10 Mar 2014 11:19:15 +0100

On 2014-03-10 10:16, [email-masked] wrote:
> ...

Note: it would be

   WWW-Authenticate: ClientCertificate IAN=WebID

(see grammar in 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p7-auth-26.html#access.authentication.framework>)

Best regards, Julian

---

From: Yoav Nir <[email-masked]>
Date: Tue, 11 Mar 2014 08:16:15 +0200

Hi, Martin

Thanks for writing these drafts. Three comments about this one:

1. I would prefer a special response code that says "go away and don't come
back without a certificate" rather than reusing 401, but that's just an
aesthetic issue, not substantive.

2. I'm wondering if the message sent to the client can be expanded enough
so that the browser sometimes does not need to pop up a certificate picker.
For example, suppose I use a certificate with DN "CN=ynir,OU=users" to log
in to my SSL-VPN portal. The portal has stored this information in my
browser via a cookie. If a string representation of this DN in sent in the
401 message, the browser can open the new connection without bothering the
user.

3. There is the issue of discovery. With current browsers (and TLS 1.0-1.2)
the server initiates a renegotiation. A new browser (with TLS 1.0-1.3)
would use this new mechanism. How does the server tell an old browser from
a new one?

Yoav

---

From: Julian Reschke <[email-masked]>
Date: Tue, 11 Mar 2014 08:10:02 +0100

On 2014-03-11 07:16, Yoav Nir wrote:
> 1. I would prefer a special response code that says "go away and don't
> come back without a certificate" rather than reusing 401, but that's
> just an aesthetic issue, not substantive.

Why?

It seems to me that 401 is totally applicable here.

> 2. I'm wondering if the message sent to the client can be expanded
> enough so that the browser sometimes does not need to pop up a
> certificate picker. For example, suppose I use a certificate with DN
> "CN=ynir,OU=users" to log in to my SSL-VPN portal. The portal has stored
> this information in my browser via a cookie. If a string representation
> of this DN in sent in the 401 message, the browser can open the new
> connection without bothering the user.

<http://tools.ietf.org/html/draft-thomson-httpbis-catch-00#section-2> 
already says:

    A challenge with this auth-scheme does not define the use of any
    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.

The question is whether the draft needs to be more specific.

> 3. There is the issue of discovery. With current browsers (and TLS
> 1.0-1.2) the server initiates a renegotiation. A new browser (with TLS
> 1.0-1.3) would use this new mechanism. How does the server tell an old
> browser from a new one?

In HTTP/2, we forbid renegotiation (I believe), that a UA that speaks 
HTTP/2 will know what to do. (But then, how does this work for 2.0<->1.1 
intermediation?)

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 11 Mar 2014 08:46:12 +0100

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'"...?

>    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

---

From: Yoav Nir <[email-masked]>
Date: Tue, 11 Mar 2014 09:52:01 +0200

> It seems to me that 401 is totally applicable here.

Only because it is not followed by the same request with an Authorization
header.

> The question is whether the draft needs to be more specific.

I think if we say that paramteres MAY provide a client with information, we
should say what such parameters could be.

> HTTP/2 will know what to do. (But then, how does this work for 2.0<->1.1

This creates a strange dependency between HTTP versions and TLS versions.

HTTP/2 forbids renegotiation and TLS 1.3 doesn't have it. OK for a new
server, new browser, and new TLS library.

HTTP/1 servers that need client authentication will have to downgrade to
TLS 1.2 so they can get renegotiation.
HTTP servers that support both HTTP versions will need to have convoluted
logic in the TLS stack that says that if the ALPN did not include http2
then the ServerHello has to cap the versions at TLS 1.2.

I'd much rather this new authentication scheme was HTTP version
independent.

Yoav

---

From: Julian Reschke <[email-masked]>
Date: Tue, 11 Mar 2014 08:57:37 +0100

On 2014-03-11 08:52, Yoav Nir wrote:
> HTTP servers that support both HTTP versions will need to have
> convoluted logic in the TLS stack that says that if the ALPN did not
> include http2 then the ServerHello has to cap the versions at TLS 1.2.
>

Well, the scheme itself *is* version independent. It's "just" harder to 
deploy with 1.1.

Is there an *alternative*, given the HTTP/2 constraints?

Best regards, Julian

---

From: Martin Thomson <[email-masked]>
Date: Tue, 11 Mar 2014 09:12:31 +0100

Thanks Julian,

https://github.com/martinthomson/drafts/commit/bbc206889f1946c6f4f020152bc0f0d4c956e328

> Not in the referenced version of the draft, right?

True, but there doesn't seem to be much point in pursuing this draft
if HTTP/2 doesn't make that statement :)

> Do we need to be more specific? Is there something that could be

I thought about that.  Maybe someone else can do the definition.  For
instance, see Henry's use case and my response there.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 11 Mar 2014 09:22:17 +0100

I think that Julian covered some of the points here.

> aesthetic issue, not substantive.

It seems like 401 is OK to me.

> 2. I'm wondering if the message sent to the client can be expanded enough so
> that the browser sometimes does not need to pop up a certificate picker. For
> example, suppose I use a certificate with DN "CN=ynir,OU=users" to log in to
> my SSL-VPN portal. The portal has stored this information in my browser via
> a cookie. If a string representation of this DN in sent in the 401 message,
> the browser can open the new connection without bothering the user.

I considered a number of options, but none seemed particularly useful.
 The CertificateRequest in TLS already has a set of DNs.

> the server initiates a renegotiation. A new browser (with TLS 1.0-1.3) would
> use this new mechanism. How does the server tell an old browser from a new
> one?

This can be very simple.  The server initiates renegotiation.  A
browser that doesn't support this feature will accept the
renegotiation and whatever happens today, happens.

A browser that supports this feature will reject the renegotiation (a
no_renegotiation alert in response to the hello request) and the
server can send its 401 response.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 11 Mar 2014 09:48:04 +0100

> if HTTP/2 doesn't make that statement :)

Yup - just clarifying...

> instance, see Henry's use case and my response there.

Sounds good.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 11 Mar 2014 11:07:47 +0200

On Tue, Mar 11, 2014 at 10:22 AM, Martin Thomson
<[email-masked]>wrote:

> enough so

Yes, but those DNs are for the CAs. I was thinking about something like
WWW-Authenticate: ClientCertificate RDN="CN=jsmith"

Thinking it over, though, this could have the undesired side-effect of
logging into other people's account when using a computer they had used
before (go to a business center in a hotel, and surf to "facebook.com" for
some fun)

> 1.0-1.2)
> would

Any browser coming out in the next 10 years will support renegotiation.
It's the new authentication method that you need to test for.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 11 Mar 2014 11:17:12 +0200

> Is there an *alternative*, given the HTTP/2 constraints?

I think the constraint belongs to HTTP/1, that doesn't have a way to
advertise new capability. It would be good if the client had a way to
signal to the server (either through TLS or through HTTP) that it
understands the ClientCertificate authentication method. In that case, the
server could choose whether to initiate renegotiation or to send this
WWW-Authenticate header based on that support.

Incidentally, this could also be an issue for any new authentication scheme
such as those discussed in httpauth, but for those there are no
alternatives - either you support them or you don't. Here there is an old
way of doing things.

An obvious alternative is to define some new header
"SupportedAuthenticationMethods" that the client would send. But adding
this kind of thing to every request is a waste.
I suppose servers could do the cringe-worthy thing of identifying
supporting browsers based on their UA strings.

But no, I don't see a good alternative.

Yoav

---

From: Martin Thomson <[email-masked]>
Date: Tue, 11 Mar 2014 10:26:19 +0100

On 11 March 2014 10:17, Yoav Nir <[email-masked]> wrote:
> I suppose servers could do the cringe-worthy thing of identifying supporting
> browsers based on their UA strings.

Sounds like a plan to me ;)

---

From: Michael Köller <[email-masked]>
Date: Tue, 25 Mar 2014 16:02:17 +0100

Hi Martin,

Julian asked me to also review your drafts. So I took the opportunity to dive a into the subject.
Here are the few things that caught my attention.

1) http://datatracker.ietf.org/doc/draft-thomson-tls-care/?include_text=1

The TLS spec [1] reads: "In general, the specification of each extension type needs to describe the effect of the extension both during full handshake and session resumption."
Currently I find no text about this. It seems clear that the new extension only applies to initial session handshakes. However, I think this should be stated explicitly.

2) http://datatracker.ietf.org/doc/draft-thomson-httpbis-catch/?include_text=1

> Abstract
> 
>    This document defines an HTTP authentication scheme that can be added to a
Perhaps the two responses should be qualified as "error response" and "successful response"? 

>    [...] 
>    [I-D.ietf-httpbis-p7-auth].
Two places where I'd rather trim the text a bit. Replace "type/kind of authentication scheme" by "authentication scheme".
 
>    [...]
>    parameters other than "realm".
The HTTP spec [2] describes the realm parameter in terms of resources: A client may reuse an authorization that was previously cached as successful for this resource.
It remains unclear, what the semantics of the realm parameter should be in context of this new authentication scheme. Even more so, since the client is expected to turn to the lower TLS protocol level, where resources have no meaning.
How do clients interact with servers using more than one protection space?
A realm (i.e. a protection space) is coupled to the server's host name. So taken to TLS this means that the SNI extension becomes mandatory?

Best regards,
Michael

[1] http://tools.ietf.org/html/rfc5246#section-7.4.1.4
[2] http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-26#section-2.2

---

From: Martin Thomson <[email-masked]>
Date: Tue, 25 Mar 2014 11:19:46 -0700

Thanks Michael,

This is a great help.  Apologies for the rough state of the drafts,
they were done in a screaming hurry during the HTTP/2 design team
session.

> Currently I find no text about this. It seems clear that the new extension only applies to initial session handshakes. However, I think this should be stated explicitly.

Yeah, this applies to initial and renegotiation handshakes.  It can't
apply to resumption.  I have noted this.

> A realm (i.e. a protection space) is coupled to the server's host name. So taken to TLS this means that the SNI extension becomes mandatory?

The idea here is that you create a new connection for every protection
space.  SNI shouldn't be necessary, at least to the extent that it
isn't already needed, of course.

That needs more expansion, I'm sure.

I've made some edits, see:
https://github.com/martinthomson/drafts/commit/ffdb77053e0ca897943ae455e605351fda0ae1cb