Subject: [TLS] Client certificate authentication and draft-ietf-tls-oob-pubkey

From: Paul Hoffman <[email-masked]>
Date: Wed, 4 Apr 2012 07:46:23 -0700

Greetings again. I am unclear how draft-ietf-tls-oob-pubkey deals with SPKIs for client authentication. If the client wants to signal that it is going to use SPKIs for both client and server authentication, does it include the extension twice with a different value for ClientOrServerExtension? Or something else?

Examples in the doc might be helpful here.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Thu, 5 Apr 2012 11:30:46 -0400 (EDT)

> Examples in the doc might be helpful here.

In an earlier draft, I addressed that with the client equivalent of SNI.
That identifier could then be used by the TLS server for an out-of-band
check on the client identity (eg via DNSSEC records or otherwise)

But the working group thought that was better left out here and addressed
seperately, as this draft moved from new TLS extensions to a new
cert_type.

I'm happy to write this up as a TLS extension draft, if the working
group thinks that would be a way to discuss this further.

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 5 Apr 2012 08:41:34 -0700

> group thinks that would be a way to discuss this further.

I think you misunderstand my question. If the client includes the *current* cert_type extension from RFC 6091 with a type of RawPublicKey, what does that mean exactly? RFC 6091 has section 3.5 that says that if the client gives a cert, it must be the same type that was given in the extension; your draft is silent on this. I think you need to say either "cert_type is for the server cert only, which is different than RFC 6091" or "cert_type applies to both server and client certs, just like RFC 6091".

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Tue, 10 Apr 2012 10:12:17 -0400 (EDT)

> I think you misunderstand my question. If the client includes the *current* cert_type extension from RFC 6091 with a type of RawPublicKey, what does that mean exactly? RFC 6091 has section 3.5 that…

When the TLS client contacts the server, it has some idea of who it is
contacting for the out of band authentication of the received raw public
key. The server has no such idea when it is contact out of the wild, and
if it just receives a SPKI without any identifier, then it cannot really
know what to do.

This is why I suggested the TLS extension equivalent for SNI for the
client.

So to answer your question, I don't think the current method specified
facilitates a server to identify a client by a cert of type SPKI, so it
makes no sense currently for the client to send such a cert_type. The
client will either have to send a full cert or reject the connection,
until we have a proper TLS extension to convey our identity to the server
so it can do an out-of-band check on a client cert of type SPKI.

Ideally, I would like to avoid this draft from dictating anything, so a
possible new draft for such a "client SNI" type TLS extension would not
have to update this document.

But as there is no way currently for the TLS client to convey its own
cert_type is different than then cert_type it requested of the server, I
guess we should stick with using the same cert_type symantics as in 6091.

That would mean that without a new TLS extension, that TLS servers sending
a certificate_request in response to receiveing a cert_type="RawPublicKey"
is likely to end in a failed TLS connection, because the server cannot
authenticate the client based on the received certificate of type RawPublicKey.

If people agree with this approach, I will add such clarifying text to
the draft.

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 10 Apr 2012 07:45:41 -0700

> if it just receives a SPKI without any identifier, then it cannot really

Sure it can. The same way that the client would have an internal list of DNS-to-SPKI associations, the server could have an internal list of ID-to-SPKI associations.

> This is why I suggested the TLS extension equivalent for SNI for the

Where is this suggested?

> so it can do an out-of-band check on a client cert of type SPKI.

If that is what you believe, it needs to be stated explicitly in the draft. I'll disagree with it, and let the WG choose.

> have to update this document.

True, but the current draft needs to say how it implements the RFC 6091 semantics. Leaving it silent will lead to misunderstanding.

> guess we should stick with using the same cert_type symantics as in 6091.

Why, yes, you should. :-)

> authenticate the client based on the received certificate of type RawPublicKey.

As above, I don't see why that is the case. A server can get client names and SPKIs out of band just as a client can.

> If people agree with this approach, I will add such clarifying text to

Please add clarifying text regardless, and then we can discuss if we agree with it.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Tue, 10 Apr 2012 12:09:29 -0400 (EDT)

> Sure it can. The same way that the client would have an internal list of DNS-to-SPKI associations, the server could have an internal list of ID-to-SPKI associations.

True. It wouldn't be the best system, but you are right.

>> This is why I suggested the TLS extension equivalent for SNI for the

Oops. I checked draft-wouters-tls-oob-pubkey-00 and it was already
removed there after discussion with EKR in Quebec City.

> As above, I don't see why that is the case. A server can get client names and SPKIs out of band just as a client can.

Yes, it can, but not "as a client can", because the client knows which
identity it is going to contact, while the server does not know which
identity it is contacted by.

> Please add clarifying text regardless, and then we can discuss if we agree with it.

Will do.

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 10 Apr 2012 09:25:19 -0700

> True. It wouldn't be the best system, but you are right.

Many people contend that clients having OOB key associations for servers is not "the best system" either. I contend they are equivalent.

> identity it is contacted by.

Errr, this is true for all client authentication; there is no difference here.

--Paul Hoffman

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 10 Apr 2012 12:28:06 -0400

> identity it is contacted by.

If a server maintains (for example) a local keyring with identities
bound to keys, with a reasonable index on the keys, it should be able to
derive the identity from the raw public key directly.

is there some scenario where this scheme falls apart?

	--dkg

---

From: Paul Wouters <[email-masked]>
Date: Tue, 10 Apr 2012 14:07:11 -0400 (EDT)

> is there some scenario where this scheme falls apart?

Yes, Opportunistic Encryption. This is where the server accepts crypto
from any client that can authenticate, but for that it needs to have some
handle on the identity to perform work, such as a FQDN it can look up
in DNS(SEC) to get the public key authenticated

Paul

---

From: Paul Wouters <[email-masked]>
Date: Tue, 10 Apr 2012 14:10:40 -0400 (EDT)

> Many people contend that clients having OOB key associations for servers is not "the best system" either. I contend they are equivalent.

As I said in another post, it prevents opportunistic encryptio.

> Errr, this is true for all client authentication; there is no difference here.

But in other cases, the client can convey a handle leading to
authentication that can suggest a method of out of band lookup.
A raw public key tells the server nothing. Can it ask DNS? If so where?
Can it ask a CA? If so which?

A client name identification mechanism conveys not only a (to be
authenticated) name, but can also embed a suggestion for the
out of band method for the server to use.

Again, compare it to IPsec OE where the FQDN is used to lookup the
public IPSECKEY in DNS.

Paul

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 10 Apr 2012 14:23:46 -0400

> in DNS(SEC) to get the public key authenticated

In the opportunistic encryption case, the server must be willing to
accept any key as a client identifier, right?  In that case, the
application running within the TLS session could add the new key to the
data store and associate it with some internal account identifier.  No
DNS lookup needed, and you end up with the server-side equivalent of
TOFU (trust-on-first-use).

As you say, it might not be ideal, but it's not unreasonable.

	--dkg

---

From: Bill Frantz <[email-masked]>
Date: Tue, 10 Apr 2012 14:07:59 -0700

>so it can do an out-of-band check on a client cert of type SPKI.

SPKI certs are designed to allow authorization without 
identification, like car keys and house keys. If the server is 
using them in this way, there is no need to identify the client, 
since possession of the private key associated with the cert is 
enough to show authorization.

What the server should really be interested in is whether the 
requested action is authorized[1]. If it only has client 
identification, then it must go through a separate authorization 
step. Using identification instead of authorization is the path 
which allows confused deputies[2].

Cheers - Bill

[1] For example, see From ABAC to ZBAC: The Evolution of Access 
Control Models By Alan H. Karp, Harry Haury, and Michael H. 
Davis – ISSA member, San Diego, USA Chapter in <https://www.issa.org/Library/Journals/2010/April/ISSA%20Journal%20April%202010.pdf>.

[2] N. Hardy, “The Confused Deputy: (or why capabilities might 
have been invented),” ACM SIGOPS Operating Systems Review, 
vol. 22, #4 (1988).

---------------------------------------------------------------------------
Bill Frantz        |"Web security is like medicine - trying to 
do good for
408-356-8506       |an evolved body of kludges" - Mark Miller
www.pwpconsult.com |

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 10 Apr 2012 14:16:45 -0700

On Tue, Apr 10, 2012 at 2:07 PM, Bill Frantz <[email-masked]> wrote:
> SPKI certs are designed to allow authorization without identification, like
> car keys and house keys. If the server is using them in this way, there is
> no need to identify the client, since possession of the private key
> associated with the cert is enough to show authorization.
>
> What the server should really be interested in is whether the requested
> action is authorized[1]. If it only has client identification, then it must
> go through a separate authorization step. Using identification instead of
> authorization is the path which allows confused deputies[2].

In this case SPKI means "subject public key info", rather than RFC2693.

-Ekr

> Cheers - Bill
>
> [1] For example, see From ABAC to ZBAC: The Evolution of Access Control
> Models By Alan H. Karp, Harry Haury, and Michael H. Davis – ISSA member, San
> Diego, USA Chapter in
> <https://www.issa.org/Library/Journals/2010/April/ISSA%20Journal%20April%202010.pdf>.
>
> [2] N. Hardy, “The Confused Deputy: (or why capabilities might have been
> invented),” ACM SIGOPS Operating Systems Review, vol. 22, #4 (1988).
>
> Bill Frantz        |"Web security is like medicine - trying to do good for
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Martin Rex <[email-masked]>
Date: Tue, 10 Apr 2012 23:53:33 +0200 (MEST)

Daniel Kahn Gillmor wrote:
> Paul Wouters wrote:

Nope -- this is actually a pretty reasonable and common usage.

If you've ever used SSH with public key authentication, it is based
_purely_ on the public key.  The "name" that appears behind the key
in your authorized_keys file is just to facilitate for human beings
to tell the keys apart, SSHD itself does *not* care about the name
behind the key! (you can change the name in authorized_keys to differ
from what the ssh client has in his id_rsa.pub file and
authentication will continue to succeed -- as long as the public
key matches.

-Martin

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 11 Apr 2012 09:38:52 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul
> Wouters
> Sent: Tuesday, April 10, 2012 9:09 AM
> To: Paul Hoffman
> Cc: [email-masked]
> Subject: Re: [TLS] Client certificate authentication and
draft-ietf-tls-oob-
> pubkey
> >> When the TLS client contacts the server, it has some idea of who it
> >> is contacting for the out of band authentication of the received raw
> >> public key. The server has no such idea when it is contact out of the
> >> wild, and if it just receives a SPKI without any identifier, then it
> >> cannot really know what to do.
> >
> > Sure it can. The same way that the client would have an internal list of
DNS-
> to-SPKI associations, the server could have an internal list of ID-to-SPKI
> associations.
> 

If this is really what you want to do, then I would suggest that the
document be expanded so that there exists the possibility to include an
identifier and/or a public key in the certificate form defined by the oob
document.

Jim

> 
> > True, but the current draft needs to say how it implements the RFC 6091
> semantics. Leaving it silent will lead to misunderstanding.
> >
> >> cert_type is different than then cert_type it requested of the
> >> server, I guess we should stick with using the same cert_type symantics
as
> in 6091.
> >> That would mean that without a new TLS extension, that TLS servers
> >> sending a certificate_request in response to receiveing a
> cert_type="RawPublicKey"
> >> is likely to end in a failed TLS connection, because the server
> >> cannot authenticate the client based on the received certificate of
type
> RawPublicKey.
> >
> > As above, I don't see why that is the case. A server can get client
names
> and SPKIs out of band just as a client can.
> 
identity
> it is going to contact, while the server does not know which identity it
is
> contacted by.
> 
> > Please add clarifying text regardless, and then we can discuss if we
agree
> with it.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 11 Apr 2012 14:10:16 -0400 (EDT)

> identifier and/or a public key in the certificate form defined by the oob

Personall, I strongly prefer not adding more fields to the bare key certificate
type, as those people who want to cover client authentication can use
full PKIX certs already, and TLS client authentication in the wild seems
to be extremely rare. The only two cases I knew are CAcert and Fedora
(and for the latter it does not even add security, as I need to identify
with another factor anyway (yubikey))

Is there an actual use case where bare keys would be preferable over
full PKIX, that also include client auth not based on burned in keys
covered by server side SPKI lookups?

Paul

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 11 Apr 2012 11:51:01 -0700

> From: Paul Wouters [mailto:[email-masked]]
> Sent: Wednesday, April 11, 2012 11:10 AM
> To: Jim Schaad
> Cc: [email-masked]
> Subject: RE: [TLS] Client certificate authentication and
draft-ietf-tls-oob-
> > document be expanded so that there exists the possibility to include
> > an identifier and/or a public key in the certificate form defined by
> > the oob document.
> 
> type, as those people who want to cover client authentication can use full
> PKIX certs already, and TLS client authentication in the wild seems to be
> extremely rare. The only two cases I knew are CAcert and Fedora (and for
> the latter it does not even add security, as I need to identify with
another
> factor anyway (yubikey))
> 
> Is there an actual use case where bare keys would be preferable over full
> PKIX, that also include client auth not based on burned in keys covered by
> server side SPKI lookups?

Please put me onto the very confused list.

In your response to Paul yesterday, you stated that you wanted a TLS
extension which did SNI for the client, this is what I was suggesting you
put into your structure.

I was under the impression that you were arguing that looking up the SPKI at
the server was not going to work and that therefore something else was
needed.

Now you seem to be stating that certificates should be what is used for
client authentication.

None of this is clear from the current document.  And only the case of
looking up SPKI would seem to be even possible from the current document.
If you state that the certificate structure that is going to be used is the
OOB certificate structure then it is going to be the one used by both the
client and the server.  If you sometimes change this it will make for a very
confused server.  This means that whatever types of information you need to
identify the client to the server for authentication needs to be in this
structure definition. 

If you look at what was done in RFC 6091 - they 

1) were very explicit about what the client certificate was and
2) defined a special case for sending an empty PGP certificate slot when the
client did not have one available.

Jim

---

From: Martin Rex <[email-masked]>
Date: Wed, 11 Apr 2012 23:25:19 +0200 (MEST)

Paul Wouters wrote:
>Jim Schaad wrote:
> Personall, I strongly prefer not adding more fields to the bare key
> certificate type,

That's OK and I don't see a need for that.

>
> as those people who want to cover client authentication can use
> to be extremely rare.

I really dislike this answer.   What is wrong with plain public keys?
It works just fine with SSH.  You complained so badly about not wanting
to parse X.509 in your client, that I am somewhat appalled to see you
suggesting X.509 for client authentication. 

In our company we've been using SSL client certs for all Intranet systems
to which many of our employees need access (Portal, Wikis, Employee
self-services scenarios) since 1999, and we've even managed to use
it occasionally for stuff that was outsourced (over the internet),
because it is so much easier (and more secure) to configure SSL client
certs on a WebServer than to newly assign 50.000 passwords each time.

If you look around, in many places people can create user accounts
with arbitrarily chosen user names, so it really does not matter
what name you tag to the key (to make it easier distinguishable
for humans), if you tag the keys _at_all_.  If you look at the proposal
for "Origin-Bound Certificates", they also come with *NO* name
that identifies the user, so the concept of recognizing a peer by
its public key is really _not_ unusal.

>
> The only two cases I knew are CAcert and Fedora

Why SPKI lookups?
Just have the server map public keys into authorizations,

-Martin

---

From: Joe Salowey <[email-masked]>
Date: Wed, 18 Apr 2012 13:42:07 -0700

Hi Paul,

Can you submit an updated draft with the clarification that support for client auth is only through SPKI lookups?  Then we can take the draft to WGLC.  

Thanks,

Joe