Re: RFC 7250 raw public keys?
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.
Re: RFC 7250 raw public keys?
> On Jul 8, 2020, at 1:51 PM, Viktor Dukhovni > 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
Re: RFC 7250 raw public keys?
On Wed, Jul 08, 2020 at 01:31:04PM -0400, Felipe Gasper wrote: > > On Jul 8, 2020, at 12:59 PM, Viktor Dukhovni > > 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.
Re: RFC 7250 raw public keys?
> On Jul 8, 2020, at 12:59 PM, Viktor Dukhovni > 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
Re: RFC 7250 raw public keys?
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.
RFC 7250 raw public keys?
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
