RFC 7250 raw public keys?

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

RFC 7250 raw public keys?

Felipe Gasper-2
Hello,

        Does OpenSSL support authentication via raw public keys? (RFC 7250) I can’t find anything to this effect on openssl.org.

        Thank you!

cheers,
-Felipe Gasper
Reply | Threaded
Open this post in threaded view
|

Re: RFC 7250 raw public keys?

Viktor Dukhovni
On Wed, Jul 08, 2020 at 12:48:38PM -0400, Felipe Gasper wrote:

> Does OpenSSL support authentication via raw public keys? (RFC 7250) I
> can’t find anything to this effect on openssl.org.

These are not presently supported.  However, you can use DANE-EE(3) TLSA
records to authenticate essentially empty leaf certificates:

    $ openssl req -new \
        -newkey ed25519 -nodes -keyout key.pem \
        -x509 -days 36500 -subj / -out cert.pem

The resulting certificate contains pretty much only a public key:

    $ openssl x509 -text -in cert.pem
    Certificate:
        Data:
            Version: 3 (0x2)
            Serial Number:
                03:ff:26:4b:48:53:95:3c:4e:db:5d:db:b8:e5:13:1c:a7:67:e0:49
            Signature Algorithm: ED25519
            Issuer:
            Validity
                Not Before: Jul  8 16:54:41 2020 GMT
                Not After : Jun 14 16:54:41 2120 GMT
            Subject:
            Subject Public Key Info:
                Public Key Algorithm: ED25519
                    ED25519 Public-Key:
                    pub:
                        ad:48:26:95:0f:70:c4:c6:8c:8b:da:9a:d1:3c:18:
                        ef:ec:60:b1:d9:d6:40:7a:5c:4f:6e:8e:36:a2:9e:
                        b0:c7
            X509v3 extensions:
                X509v3 Subject Key Identifier:
                    A1:47:10:54:37:97:45:C0:3D:5B:3A:F2:1A:3D:EE:9F:4A:46:7B:D2
                X509v3 Authority Key Identifier:
                    keyid:A1:47:10:54:37:97:45:C0:3D:5B:3A:F2:1A:3D:EE:9F:4A:46:7B:D2

                X509v3 Basic Constraints: critical
                    CA:TRUE
        Signature Algorithm: ED25519
             48:e7:e2:1a:a0:3b:00:42:7c:66:46:67:26:08:ed:df:f8:64:
             70:17:ff:72:8e:1d:42:8e:9b:99:e8:54:e5:e1:eb:97:fe:4e:
             dd:e6:89:b8:05:e5:b3:d8:da:a6:97:91:90:c5:54:56:0e:90:
             f5:b7:5a:54:c9:78:0b:b5:ed:03
    -----BEGIN CERTIFICATE-----
    MIIBFjCByaADAgECAhQD/yZLSFOVPE7bXdu45RMcp2fgSTAFBgMrZXAwADAgFw0y
    MDA3MDgxNjU0NDFaGA8yMTIwMDYxNDE2NTQ0MVowADAqMAUGAytlcAMhAK1IJpUP
    cMTGjIvamtE8GO/sYLHZ1kB6XE9ujjainrDHo1MwUTAdBgNVHQ4EFgQUoUcQVDeX
    RcA9WzryGj3un0pGe9IwHwYDVR0jBBgwFoAUoUcQVDeXRcA9WzryGj3un0pGe9Iw
    DwYDVR0TAQH/BAUwAwEB/zAFBgMrZXADQQBI5+IaoDsAQnxmRmcmCO3f+GRwF/9y
    jh1CjpuZ6FTl4euX/k7d5om4BeWz2Nqml5GQxVRWDpD1t1pUyXgLte0D
    -----END CERTIFICATE-----

And while it is larger than the bare key, the size penalty is not
prohibitive.

--
    Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: RFC 7250 raw public keys?

Felipe Gasper-2


> On Jul 8, 2020, at 12:59 PM, Viktor Dukhovni <[hidden email]> wrote:
>
> On Wed, Jul 08, 2020 at 12:48:38PM -0400, Felipe Gasper wrote:
>
>> Does OpenSSL support authentication via raw public keys? (RFC 7250) I
>> can’t find anything to this effect on openssl.org.
>
> These are not presently supported.  However, you can use DANE-EE(3) TLSA
> records to authenticate essentially empty leaf certificates:

That would also require changes to DNS, right?

What I’m looking for is a way to authenticate a user over TLS in essentially the same manner that SSH’s handshake uses, where a signature of a shared secret validates the public key, which is on a preconfigured allowlist. I could do it post-handshake by using RFC 5705 key material exports as the shared secret--this usage seems to exemplify the intent of that extension--but TLS raw public keys seem a bit closer to “prior art”.

Anyhow, thank you!

-FG
Reply | Threaded
Open this post in threaded view
|

Re: RFC 7250 raw public keys?

Viktor Dukhovni
On Wed, Jul 08, 2020 at 01:31:04PM -0400, Felipe Gasper wrote:

> > On Jul 8, 2020, at 12:59 PM, Viktor Dukhovni <[hidden email]> wrote:
> >
> > On Wed, Jul 08, 2020 at 12:48:38PM -0400, Felipe Gasper wrote:
> >
> >> Does OpenSSL support authentication via raw public keys? (RFC 7250) I
> >> can’t find anything to this effect on openssl.org.
> >
> > These are not presently supported.  However, you can use DANE-EE(3) TLSA
> > records to authenticate essentially empty leaf certificates:
>
> That would also require changes to DNS, right?

Sure, but DANE-EE(3) is just one way to authenticate a stand-alone
self-signed certificate.  Indeed OpenSSL does not do the DNS lookups,
you can store the matching digest anywhere and retrieve it in whatever
way makes sense for your application.  You can even compute it on the
fly from a copy of the expected certificate.

Postfix (in which I'm the maintainer of the TLS stack), creates
synthetic DANE TLSA records as the way that it matches certificates
by pre-configured "fingerprint" values.

That said, you also don't need to use DANE authentication, you can
implement your own certificate verification callbacks, ...

My point was primarily that a bit of space overhead side, a minimal
X.509 certificate is in most cases equivalent to a bare public key,
but has broader API support.

> What I’m looking for is a way to authenticate a user over TLS in
> essentially the same manner that SSH’s handshake uses, where a
> signature of a shared secret validates the public key, which is on a
> preconfigured allowlist. I could do it post-handshake by using RFC
> 5705 key material exports as the shared secret--this usage seems to
> exemplify the intent of that extension--but TLS raw public keys seem a
> bit closer to “prior art”.

Indeed DANE is only a good fit for authenticating servers, for
authenticating clients, you just want to compute a public key
fingerprint and do a database lookup.

This is also supported in Postfix, just don't authenticate
the client cert at all (no PKI), grab the key digest and
use it directly for access control.

--
    Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: RFC 7250 raw public keys?

Felipe Gasper-2


> On Jul 8, 2020, at 1:51 PM, Viktor Dukhovni <[hidden email]> wrote:
>
> On Wed, Jul 08, 2020 at 01:31:04PM -0400, Felipe Gasper wrote:
>
>> What I’m looking for is a way to authenticate a user over TLS in
>> essentially the same manner that SSH’s handshake uses, where a
>> signature of a shared secret validates the public key, which is on a
>> preconfigured allowlist. I could do it post-handshake by using RFC
>> 5705 key material exports as the shared secret--this usage seems to
>> exemplify the intent of that extension--but TLS raw public keys seem a
>> bit closer to “prior art”.
>
> Indeed DANE is only a good fit for authenticating servers, for
> authenticating clients, you just want to compute a public key
> fingerprint and do a database lookup.
>
> This is also supported in Postfix, just don't authenticate
> the client cert at all (no PKI), grab the key digest and
> use it directly for access control.

Wouldn’t there need to be a shared secret, though, or some other way for the server to have some influence on the randomness of what the client’s private key signs? (I don’t know TLS well enough to comment on whether that happens in an ordinary TLS handshake, but I assume it does?)

-F
Reply | Threaded
Open this post in threaded view
|

Re: RFC 7250 raw public keys?

Viktor Dukhovni
On Wed, Jul 08, 2020 at 02:24:47PM -0400, Felipe Gasper wrote:

> > This is also supported in Postfix, just don't authenticate
> > the client cert at all (no PKI), grab the key digest and
> > use it directly for access control.
>
> Wouldn’t there need to be a shared secret, though, or some other way
> for the server to have some influence on the randomness of what the
> client’s private key signs? (I don’t know TLS well enough to comment
> on whether that happens in an ordinary TLS handshake, but I assume it
> does?)

TLS takes care of that:

    https://tools.ietf.org/html/rfc5246#section-7.4.8
    https://tools.ietf.org/html/rfc8446#section-4.4.3

In particular, the client and server random values are included, as well
as any ephemeral public values in DH or ECDH key exchange.

--
    Viktor.