Hypothetical service questions - certs as credentials?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Hypothetical service questions - certs as credentials?

openssl-users
Hello.

I'm considering writing a server program (which provides mostly
hypothetical services, for the purpose of this discussion). The server
requires users to register an account on the server before use.  The
service would, I believe, simply bind usernames to one or more
user-provided public certificates.

Also, for the purposes of this discussion, I control both server and
client code.

I want to use TLS to handle authentication/encryption but am not sure if
it's feasible. Specifically - I don't want users to have passwords, it
must be public key authentication only (like SSH) with bilateral
authentication. This is a critical point - I would like the only realistic
way to compromise a user account to be actually stealing the private key
of that user and cracking the password on it (assuming a lack of other
software bugs and/or poor user interfaces allowing social engineering).

I'm not 100% certain how to implement this securely, however.  Would the
server cache a copy of each user's public certificate? I'm trying to work
out what guarantees TLS actually provides (on the strongest settings -
which both the client and server would enforce). I have a feeling that
I would store the username in one of the fields of the user's certificate
but am not absolutely sure.

Any input would be appreciated. I appreciate the question is a little
vague, hopefully I'll be able to expand on it after some responses. The
main reason I'm trying to get a better picture of this stuff is that I'm
no cryptographer and obviously any protocol I invented would no doubt be
subject to many cryptographic flaws...

xw
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Hypothetical service questions - certs as credentials?

JoelKatz

> I want to use TLS to handle authentication/encryption but am not sure if
> it's feasible. Specifically - I don't want users to have passwords, it
> must be public key authentication only (like SSH) with bilateral
> authentication. This is a critical point - I would like the only realistic
> way to compromise a user account to be actually stealing the private key
> of that user and cracking the password on it (assuming a lack of other
> software bugs and/or poor user interfaces allowing social engineering).

That's precisely what certificates and TLS is for.

> I'm not 100% certain how to implement this securely, however.  Would the
> server cache a copy of each user's public certificate?

Only if you need to for some reason. It usually makes more sense to have the
user supply his certificate, and this is what TLS is designed to do. For
side A to authenticate to side B, side A sends the certificate and then
proves that it possesses the private key corresponding to the public key in
the certificate.

> I'm trying to work
> out what guarantees TLS actually provides (on the strongest settings -
> which both the client and server would enforce). I have a feeling that
> I would store the username in one of the fields of the user's certificate
> but am not absolutely sure.

Exactly. You can store it in the common name field if you want.

> Any input would be appreciated. I appreciate the question is a little
> vague, hopefully I'll be able to expand on it after some responses. The
> main reason I'm trying to get a better picture of this stuff is that I'm
> no cryptographer and obviously any protocol I invented would no doubt be
> subject to many cryptographic flaws...

It sounds like straightforward TLS should do exactly what you want. On the
server side, make sure you request the client's certificate. Each side will
need to know how to verify the other side's certificate. On the client side,
it should be making sure the certificate is valid, for the server the client
wishes to reach, and signed by the correct CA (yours). On the server side,
it should be making sure the certificate is valid, signed by the correct CA,
and the server will need to extract the user name from the certificate.

You are lucky, this is completely standard usage.

DS


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Hypothetical service questions - certs as credentials?

openssl-users
On 2009-07-12 12:05:08, David Schwartz wrote:
>
> It sounds like straightforward TLS should do exactly what you want.

Thanks, that's a weight off my mind (and specification).

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Hypothetical service questions - certs as credentials?

Goetz Babin-Ebell
In reply to this post by openssl-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[hidden email] wrote:
| Hello.
Hello xw,

| I'm considering writing a server program (which provides mostly
| hypothetical services, for the purpose of this discussion). The server
| requires users to register an account on the server before use.  The
| service would, I believe, simply bind usernames to one or more
| user-provided public certificates.
|
| Also, for the purposes of this discussion, I control both server and
| client code.
Do you also control client certificate generation ?

With that you could configure the server to only accept client
certificates issued by your own CA and set the user name in the client
certificates subject name.

This way you would only have to store your CA certificate and the CRL
for all client certificates that became invalid on the server.


| I'm not 100% certain how to implement this securely, however.  Would the
| server cache a copy of each user's public certificate?
If you accept client certificates issued by foreign (not controlled by
you) CAs, you would have to find a way to map between certificate and user.
Here would be a mepping from issuer name / serial number of the client
cert sufficient...


Goetz

- --
DMCA: The greed of the few outweighs the freedom of the many
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFKWwk42iGqZUF3qPYRAmSDAJ4isbtXD7Ld1e4uUks4QK27OdsYRgCfYEAu
v42WPVuvwEy9NRrFGawBuzU=
=fU2t
-----END PGP SIGNATURE-----
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Hypothetical service questions - certs as credentials?

openssl-users
Hello.

On 2009-07-13 12:15:21, Goetz Babin-Ebell wrote:
> Do you also control client certificate generation ?
>
> With that you could configure the server to only accept client
> certificates issued by your own CA and set the user name in the client
> certificates subject name.
>
> This way you would only have to store your CA certificate and the CRL
> for all client certificates that became invalid on the server.

I believe I will be, but what are my options if I don't control
cert generation?

I think this is why I considered caching copies of client certs
first of all - I can't verify the identity of an untrusted cert
but I can at least check that the user presents the same cert
next time.

> If you accept client certificates issued by foreign (not controlled by
> you) CAs, you would have to find a way to map between certificate and user.
> Here would be a mepping from issuer name / serial number of the client
> cert sufficient...

Right, I'll keep that in mind.

xw
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Hypothetical service questions - certs as credentials?

Victor Duchovni
On Mon, Jul 13, 2009 at 06:01:02PM +0100, [hidden email] wrote:

> Hello.
>
> On 2009-07-13 12:15:21, Goetz Babin-Ebell wrote:
> > Do you also control client certificate generation ?
> >
> > With that you could configure the server to only accept client
> > certificates issued by your own CA and set the user name in the client
> > certificates subject name.
> >
> > This way you would only have to store your CA certificate and the CRL
> > for all client certificates that became invalid on the server.
>
> I believe I will be, but what are my options if I don't control
> cert generation?
>
> I think this is why I considered caching copies of client certs
> first of all - I can't verify the identity of an untrusted cert
> but I can at least check that the user presents the same cert
> next time.
>
> > If you accept client certificates issued by foreign (not controlled by
> > you) CAs, you would have to find a way to map between certificate and user.
> > Here would be a mepping from issuer name / serial number of the client
> > cert sufficient...
>
> Right, I'll keep that in mind.

I would use the public-key fingerprint, unless the trust chain is verified
from a fixed set of trusted issuers.

--
        Viktor.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Hypothetical service questions - certs as credentials?

openssl-users
Hello.

On 2009-07-13 14:59:48, Victor Duchovni wrote:
> > > If you accept client certificates issued by foreign (not controlled by
> > > you) CAs, you would have to find a way to map between certificate and user.
> > > Here would be a mepping from issuer name / serial number of the client
> > > cert sufficient...
> >
> > Right, I'll keep that in mind.
>
> I would use the public-key fingerprint, unless the trust chain is verified
> from a fixed set of trusted issuers.

Did you mean fingerprints instead of caching certs or instead of issuer/serial?

xw
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Hypothetical service questions - certs as credentials?

JoelKatz

> > I would use the public-key fingerprint, unless the trust chain
> > is verified
> > from a fixed set of trusted issuers.

> Did you mean fingerprints instead of caching certs or instead of
> issuer/serial?
>
> xw

Instead of anything else. Simply bind the username to the public-key
fingerprint. Essentially, treat it as a "hashed" password in the way you
store it. Wherever you store the usernames, also store the public key
fingerprints.

The only tricky part is you need to rig your server to accept a certificate
signed by any CA or self-signed or whatever. You don't need to do any other
validation of the certificate itself.

DS


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Hypothetical service questions - certs as credentials?

Michael S. Zick-4
On Mon July 13 2009, David Schwartz wrote:

>
> > > I would use the public-key fingerprint, unless the trust chain
> > > is verified
> > > from a fixed set of trusted issuers.
>
> > Did you mean fingerprints instead of caching certs or instead of
> > issuer/serial?
> >
> > xw
>
> Instead of anything else. Simply bind the username to the public-key
> fingerprint. Essentially, treat it as a "hashed" password in the way you
> store it. Wherever you store the usernames, also store the public key
> fingerprints.
>
> The only tricky part is you need to rig your server to accept a certificate
> signed by any CA or self-signed or whatever. You don't need to do any other
> validation of the certificate itself.
>

If you don't use some system of "third party identity verification" you are
no worse off than a username/password/working e-mail address sort of registration.
Your server is talking with whoever (or whatever) they claim to be.

If you authorize access additional times to the first, you are again
no worse off than a stored (hashed) username/password/working e-mail address system.
Your server is talking with someone (or something) they once thought they knew.

The only downside is you have to do a bunch of coding yourself.  ;)
Why not write into your spec: "Must access using OpenID only." and be (almost)
done with this part of the spec?

The code is short, sweet and widely available to incorporate OpenID into your server.
Here is one popular application that (can) use OpenID:
http://doc.tikiwiki.org/OpenID
Here is one of the providers of the authentication:
https://pip.verisignlabs.com/

The sign-up process for your users is simple (and no stronger verification of
identity) - this just assures you that you are talking with whoever they claim to be.
That provider can also issue your users "node locked" certificates.

This may be all you really need in your application - automated user sign-in.
And as a side benefit - your users can use their OpenID with any system that supports
it, not just yours.
Plus, of course, you don't have to write it or maintain it.

Mike
> DS
>
>
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> User Support Mailing List                    [hidden email]
> Automated List Manager                           [hidden email]
>
>


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]