Authenticating clients based on CA/CN-match

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

Authenticating clients based on CA/CN-match

martin f krafft-2
Hello,

As far as I can tell, postfix can authenticate its clients using
certificates in two ways:

  check_ccert_access (also permit_tls_clientcerts), which
  authorizes clients based on the cert fingerprint;

  permit_tls_all_clientcerts, which authorizes clients if they
  present a cert signed by a specific CA;

We've been using the former for years, requiring us to manually
deploy the new fingerprints every two years. But we've now migrated
to Letsencrypt, and doing so every two months won't work anymore.
Furthermore, we can't just trust all certs issued by Letsencrypt,
nor is it feasible to introduce a custom CA just for this purpose.

So we can now either automate the deployment of fingerprints,
surely, but I was also wondering if it weren't possible to add the
following functionality to postfix:

Either extend check_ccert_access or introduce a new access map,
which takes the CN from the client cert and maps it to a CA
identifier. E.g.

  .example.org  /etc/ssl/certs/DST_Root_CA_X3.pem

meaning that if a client presents a certificate who's CN is
a subdomain of example.org, and the certificate trust chain is
complete up until the certificate provided in
/etc/ssl/certs/DST_Root_CA_X3.pem, then grant access.

This would allow users to easily grant access to all hosts in their
subdomain, even if the certs are issued by a common CA such as
Letsencrypt. The match on the cert CN should be sufficient to guard
against abuse.

What do you think?

--
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
"god is a comedian playing to an audience too afraid to laugh."
                                                         -- voltaire
 
spamtraps: [hidden email]

digital_signature_gpg.asc (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Authenticating clients based on CA/CN-match

Wietse Venema
I suggest that we keep it simple:

1) Use smtpd_tls_CA_file to trust ONLY the letsencrypt CA.

2) Use a new check_certname_access feature to reject out-of-doman
   names. Postfix should not make 'allow' decisions based on name
   information in a certificate with an untrusted CA.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Authenticating clients based on CA/CN-match

martin f krafft-2
also sprach Wietse Venema <[hidden email]> [2017-09-17 16:34 +0200]:
> 1) Use smtpd_tls_CA_file to trust ONLY the letsencrypt CA.

Right, especially since I could set this only for the smtpd handling
submissions and need not impose this setting on regular port 25 SMTP
connections.

I suppose it would get difficult if there was more than one issuing
CA, but that's probably a rare case, if at all.

> 2) Use a new check_certname_access feature to reject out-of-doman
>    names. Postfix should not make 'allow' decisions based on name
>    information in a certificate with an untrusted CA.

Why do you consider the CA untrusted? Isn't that the whole point of
the smtpd_tls_CA_file setting? Am I not making the statement "I
trust the certificates issued by this CA to have reliable CNs" by
specifying smtpd_tls_CA_file in our scenario?

If Postfix couldn't issue "allow" based on check_certname_access,
then the logic would have to be:

  check_certname_access (reject if !.example.org)
  permit

which IMHO is backwards and not any more secure than

  check_certname_access (permit if .example.org)
  reject

… unless you had something else in mind to issue that "permit" in
the first example?

--
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
it is better to remain silent and be thought a fool
than to open one's mouth and remove all doubt.
 
spamtraps: [hidden email]

digital_signature_gpg.asc (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Authenticating clients based on CA/CN-match

Wietse Venema
martin f krafft:

> also sprach Wietse Venema <[hidden email]> [2017-09-17 16:34 +0200]:
> > 1) Use smtpd_tls_CA_file to trust ONLY the letsencrypt CA.
>
> Right, especially since I could set this only for the smtpd handling
> submissions and need not impose this setting on regular port 25 SMTP
> connections.
>
> I suppose it would get difficult if there was more than one issuing
> CA, but that's probably a rare case, if at all.
>
> > 2) Use a new check_certname_access feature to reject out-of-doman
> >    names. Postfix should not make 'allow' decisions based on name
> >    information in a certificate with an untrusted CA.

Any CA that is not in smtpd_tls_CA_file. I see no harm in allowing
'reject' decisions based on the name in a certificate from an unknown
CA.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Authenticating clients based on CA/CN-match

martin f krafft-2
also sprach Wietse Venema <[hidden email]> [2017-09-17 17:26 +0200]:
> > > 2) Use a new check_certname_access feature to reject out-of-doman
> > >    names. Postfix should not make 'allow' decisions based on name
> > >    information in a certificate with an untrusted CA.
>
> Any CA that is not in smtpd_tls_CA_file. I see no harm in allowing
> 'reject' decisions based on the name in a certificate from an unknown
> CA.

If a client connects to the submission port and presents
a certificate that is not from a trusted CA, then
check_certname_access obviously can't make an authoritative
decision, and the client will most likely end up in some "reject"
later on in the restriction list. I.e. I think in that case,
check_certname_access should always return DUNNO.

If a client connects and presents a certificate from a CA listed in
smtpd_tls_CA_file, then I don't see a reason why the new
check_certname_access shouldn't be able to cast an "OK" and thereby
permit accepting/relaying of the message.

I hope we're not talking past each other.

--
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
remember, half the people are below average.
 
spamtraps: [hidden email]

digital_signature_gpg.asc (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Authenticating clients based on CA/CN-match

Viktor Dukhovni

> On Sep 17, 2017, at 11:41 AM, martin f krafft <[hidden email]> wrote:
>
> If a client connects and presents a certificate from a CA listed in
> smtpd_tls_CA_file, then I don't see a reason why the new
> check_certname_access shouldn't be able to cast an "OK" and thereby
> permit accepting/relaying of the message.

Can you explain your use-case in a bit more detail?  What sort of
SMTP clients are these, that they authenticate using TLS client
certificates not issued by a CA you control and you're then
providing submission access to said clients based on their domain
as found in the certificate CN?

Keep in mind that DNS names stored as the CommonName of the
certificate subject DN is a deprecated representation of the
client identity.  Though most CAs have not yet stopped putting
nonempty subject DNs in certificates, the right place for
certificate names is the subjectAlternativeName extension,
which bears zero or more DNS names and perhaps names of other
types too.

Indeed one is supposed to *ignore* the certificate CN when
subject alternative names are present:

    https://tools.ietf.org/html/rfc6125#section-2.3

and should the client's DNS name exceed 64 bytes, it can only
be represented as a  DNS-ID in the SAN, because the subject
DN CommonName is limited to that length.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: Authenticating clients based on CA/CN-match

martin f krafft-2
also sprach Viktor Dukhovni <[hidden email]> [2017-09-17 18:09 +0200]:
> Can you explain your use-case in a bit more detail? What sort of
> SMTP clients are these, that they authenticate using TLS client
> certificates not issued by a CA you control and you're then
> providing submission access to said clients based on their domain
> as found in the certificate CN?

I have three distinct use-cases, but they're all more or less the
same, involving 107 hosts altogether spread across the globe in
untrusted networks, often with weird firewalling or other policies.
There are several hundreds of users making use of cron and other
things that basically require sendmail on each host. To keep our
sanity, we currently have it such that all hosts forward their mail
to a smarthost via the submission port, TLS-secured, and
authenticated with the TLS cert fingerprint (using
check_ccert_access).

Our recent move to Letsencrypt means that the hosts now get new
client certificates every 2–3 months. At the moment, this means we
have to update the check_ccert_access map on the smarthost once
almost every day with new fingerprint.

Of course one could automate this, or switch to password
authentication, but in thinking about this, I was wondering:

Given that we trust Letsencrypt (for benefit of doubt) —

Given that LE's challenge-response means that only we can issue
certs that contain example.org in the CN or SubjectAltNames list —

Why do I have to give postfix the fingerprints. Wouldn't it be just
as safe and a lot easier to say "certs matching¹ .example.org issued
by LE" and be done with it.

Does that make it a bit clearer?

¹) see discussion on canonical identity and SubjAltNames lists below

> Keep in mind that DNS names stored as the CommonName of the
> certificate subject DN is a deprecated representation of the
> client identity.

Interesting, I didn't know that. I'll do some research.

> Though most CAs have not yet stopped putting nonempty subject DNs
> in certificates, the right place for certificate names is the
> subjectAlternativeName extension, which bears zero or more DNS
> names and perhaps names of other types too.

So there exists no longer a canonical name/identity of
a certificate? I am well aware of SubjectAltNames, but I am unsure
they're ordered, or whether there even exists such a convention
that e.g. the first one is the primary name.

In the present technical approach I'm proposing, the lack of
a canonical identity would mean that postfix would actually have to
check every single one of the SubjectAltNames against an access map,
which may cause problems depending on the length of this list,² and
may well render this approach meaningless.

²) I've seen certs with dozens, maybe even >100 SubjAltNames…

Obviously, one solution would be to create an intermediary CA that
we control. However, I think that's just asking for trouble. For
one, trust chains longer than 2 expose some nasty bugs in most
server and client implementations, and second, Letsencrypt doesn't
support that anyway I don't think, and we don't want to go back to
the X.509 Mafia.

--
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
"of course the music is a great difficulty.
 you see, if one plays good music, people don't listen,
 and if one plays bad music people don't talk."
                                                      -- oscar wilde
 
spamtraps: [hidden email]

digital_signature_gpg.asc (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Authenticating clients based on CA/CN-match

Viktor Dukhovni

> On Sep 17, 2017, at 3:29 PM, martin f krafft <[hidden email]> wrote:
>
> also sprach Viktor Dukhovni <[hidden email]> [2017-09-17 18:09 +0200]:
>> Can you explain your use-case in a bit more detail? What sort of
>> SMTP clients are these, that they authenticate using TLS client
>> certificates not issued by a CA you control and you're then
>> providing submission access to said clients based on their domain
>> as found in the certificate CN?
>
> I have three distinct use-cases, but they're all more or less the
> same, involving 107 hosts altogether spread across the globe in
> untrusted networks, often with weird firewalling or other policies.
> There are several hundreds of users making use of cron and other
> things that basically require sendmail on each host. To keep our
> sanity, we currently have it such that all hosts forward their mail
> to a smarthost via the submission port, TLS-secured, and
> authenticated with the TLS cert fingerprint (using
> check_ccert_access).

I think you're saying your organization places machines you (collectively)
build on other people's networks, but the machines need to send call
home to send email, which is sometimes outbound to other domains?

> Our recent move to Letsencrypt means that the hosts now get new
> client certificates every 2–3 months.

You don't have to the same key/cert across the board, the client
certificate for submission does not need to be (and perhaps should
not be) the one that's issued by Let's Encrypt (LE).

Are you using LE to obtain certificates that are trusted by other
parties, or using LE because "certbot", ... make it easy to automate
renewal?

How does one of these far-flug clients get an LE certificate in your
domain in the first place?

> Given that we trust Letsencrypt (for benefit of doubt) —

I am trying to understand why you want to delegate relay control
decisions for your domain to LE.

> Given that LE's challenge-response means that only we can issue
> certs that contain example.org in the CN or SubjectAltNames list —

Can you explain a bit more detail here?

> Why do I have to give postfix the fingerprints. Wouldn't it be just
> as safe and a lot easier to say "certs matching¹ .example.org issued
> by LE" and be done with it.

Well, it isn't typically "just as safe", the LE enrollment process
is often vulnerable to on-path or BGP-route forgery MiTM attacks
between the CA and the domain for which the certificates are being
issued.

What I am trying to understand is the circumstances that lead you
to use LE for issuing submission client certificates...

>> Though most CAs have not yet stopped putting nonempty subject DNs
>> in certificates, the right place for certificate names is the
>> subjectAlternativeName extension, which bears zero or more DNS
>> names and perhaps names of other types too.
>
> So there exists no longer a canonical name/identity of
> a certificate?

The canonical identity is the issuer DN + serial number.
The subject DN can be an empty RDN sequence.  Mind you,
at the moment all the LE certificates I've seen have
a nonempty CN as the sole component of the subject DN,
and this may not change for a long time, but it is not
guaranteed indefinitely...

> I am well aware of SubjectAltNames, but I am unsure
> they're ordered, or whether there even exists such a convention
> that e.g. the first one is the primary name.

There is no meaningful ordering of SANs.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: Authenticating clients based on CA/CN-match

Wietse Venema
In reply to this post by martin f krafft-2
I wonder, if this is used for 'internal' email traffic, why bother
with certificates that require frequent renewal? If the organization
is that large, I would expect that all external email is handled
by relay hosts on the perimeter, instead of allowing direct mail
from random 'internal' hosts.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Authenticating clients based on CA/CN-match

martin f krafft-2
In reply to this post by Viktor Dukhovni
also sprach Viktor Dukhovni <[hidden email]> [2017-09-17 21:49 +0200]:
> I think you're saying your organization places machines you
> (collectively) build on other people's networks, but the machines
> need to send call home to send email, which is sometimes outbound
> to other domains?

I'll go with that.

> You don't have to the same key/cert across the board, the client
> certificate for submission does not need to be (and perhaps should
> not be) the one that's issued by Let's Encrypt (LE).

True. We could create a CA for this purpose, but tbh, we've done
this in the past and — given that 2 of the 3 organisations I'm
dealing with are non-profit and hence resource-limited, managing all
aspects of a CA was always just too hard.

> Are you using LE to obtain certificates that are trusted by other
> parties, or using LE because "certbot", ... make it easy to
> automate renewal?

A little bit of that, and a little bit of "it's just easier that
way".

> How does one of these far-flug clients get an LE certificate in
> your domain in the first place?

We control the DNS infrastructure centrally in all cases (using
DNSSEC, of course), and so we issue them centrally. They are
currently deployed over SSH tunnels to the hosts.

> > Given that we trust Letsencrypt (for benefit of doubt) —
>
> I am trying to understand why you want to delegate relay control
> decisions for your domain to LE.

It's a valid question, for sure. But I wouldn't say we delegate
relay control decisions to LE per se. Of course they'd become part
of the equation and could abuse it, but that'd be the end of their
story, too.

I'm intending to make relay control decisions based on information
LE has authenticated.

And yes, I wouldn't do this with high security requirements, but
an SMTP smarthost just doesn't fall into that domain for me,
especially not if constantly monitored.

> > Given that LE's challenge-response means that only we can issue
> > certs that contain example.org in the CN or SubjectAltNames list —
>
> Can you explain a bit more detail here?

In order to obtain an LE certificate with foo.example.org in CN/SAN,
I have to regularly prove that I control foo.example.org towards LE.
That's their trust model. It's similar to CACert's, except it's
automated and there's a trust path to the existing set of CA certs
as distributed by e.g. Mozilla.

> > Why do I have to give postfix the fingerprints. Wouldn't it be just
> > as safe and a lot easier to say "certs matching¹ .example.org issued
> > by LE" and be done with it.
>
> Well, it isn't typically "just as safe", the LE enrollment process
> is often vulnerable to on-path or BGP-route forgery MiTM attacks
> between the CA and the domain for which the certificates are being
> issued.

DNSSEC does address this somewhat. Nevertheless, in my
security-vs-cost calculation, getting relay access to a smarthost is
not worth the price it'd cost to infiltrate the enrollment process
as you say.

Apart, the current way by which Postfix uses cert fingerprints is
just as vulnerable to those kinds of attacks, no?

> > So there exists no longer a canonical name/identity of
> > a certificate?
>
> The canonical identity is the issuer DN + serial number.
> The subject DN can be an empty RDN sequence.  Mind you,
> at the moment all the LE certificates I've seen have
> a nonempty CN as the sole component of the subject DN,
> and this may not change for a long time, but it is not
> guaranteed indefinitely...

Indeed. The problem with including the serial number means that the
ID of the certificate changes on every reissue. Part of the idea I'm
after is of course to have a canonical identity (i.e. the primary
DNS name, or whatever you want it to be) which just gets
reauthenticated at regular intervals, but doesn't change.

Thanks for your challenging questions. I'm well aware that this
isn't exactly postfix-users material, but it's helping me
tremendously, and I hope others also find this interesting. I do
hope Postfix will benefit from this long-term, by way of docs, or
something like check_certname_access or whatever we come up with.

Cheers,

--
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
"the mind of the thoroughly well-informed man is a dreadful thing.
 it is like a bric-à-brac shop, all monsters and dust,
 with everything priced above its proper value."
                                                      -- oscar wilde
 
spamtraps: [hidden email]

digital_signature_gpg.asc (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Authenticating clients based on CA/CN-match

martin f krafft-2
In reply to this post by Wietse Venema
also sprach Wietse Venema <[hidden email]> [2017-09-17 21:51 +0200]:
> I wonder, if this is used for 'internal' email traffic, why bother
> with certificates that require frequent renewal? If the organization
> is that large, I would expect that all external email is handled
> by relay hosts on the perimeter, instead of allowing direct mail
> from random 'internal' hosts.

That's precisely what we're trying to do, except the perimeter is
non-physical as the hosts are spread across the 'Net, and there's no
consistent VPN, unfortunately.

So yes, all external mail is handled by a defined set of relay hosts
on the perimeter, but we need a sensible way to authorize access to
those relay hosts. I'd prefer certificates over SASL passwords, and
I think that the ease of using letsencrypt far outweighs the
additional security we'd get in return for the effort required to
manage our own PKI.

--
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
in the beginning was the word,
and the word was content-type: text/plain
 
spamtraps: [hidden email]

digital_signature_gpg.asc (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Authenticating clients based on CA/CN-match

Viktor Dukhovni
In reply to this post by martin f krafft-2
On Sun, Sep 17, 2017 at 11:04:47PM +0200, martin f krafft wrote:

> > I think you're saying your organization places machines you
> > (collectively) build on other people's networks, but the machines
> > need to send call home to send email, which is sometimes outbound
> > to other domains?
>
> I'll go with that.
>
> > How does one of these far-flug clients get an LE certificate in
> > your domain in the first place?
>
> We control the DNS infrastructure centrally in all cases (using
> DNSSEC, of course), and so we issue them centrally. They are
> currently deployed over SSH tunnels to the hosts.

So your certral system generates the keys, and obtains the LE
certificates on behalf of the far-flung hosts?  And then pushes
these keys to the hosts over an SSH tunnel?

Is that only for the initial key issuance?  And then each host
rotates the certs independently of the central system using the
existing key to authenticate to LE?

I am curious why you want to rotate the submission TLS client keys.
If you are able to centrally push keys to the hosts, why bother
with a CA at all?  Why not generate a self-signed key+cert, store
the fingerprint in a database, and leave LE out of it?  The key
would not change for the lifetime of the host.

> > I am trying to understand why you want to delegate relay control
> > decisions for your domain to LE.
>
> It's a valid question, for sure. But I wouldn't say we delegate
> relay control decisions to LE per se. Of course they'd become part
> of the equation and could abuse it, but that'd be the end of their
> story, too.

Well, any certificate they issue in the future for your domain
becomes valid for relay host access.  It seems rather permissive.
Sure the domain is yours, and perhaps you trust all the variants
of their challenge protocol (including plain old email to
admin@, postmaster@, ...), but it seems overkill in this case
to open yourself up to this...

> > Well, it isn't typically "just as safe", the LE enrollment process
> > is often vulnerable to on-path or BGP-route forgery MiTM attacks
> > between the CA and the domain for which the certificates are being
> > issued.
>
> DNSSEC does address this somewhat.

DNSSEC helps with having CAA records that are difficult to MiTM,
and protectst the DNS challenge protocol, but I don't whether it
is possible to disable bootstrapping over weaker email challenges
and/or control over port 80.

> Apart, the current way by which Postfix uses cert fingerprints is
> just as vulnerable to those kinds of attacks, no?

No, not at all.  If you provision the fingerprints over a secure
channel they are quite safe from active attacks.

> Thanks for your challenging questions. I'm well aware that this
> isn't exactly postfix-users material, but it's helping me
> tremendously, and I hope others also find this interesting. I do
> hope Postfix will benefit from this long-term, by way of docs, or
> something like check_certname_access or whatever we come up with.

The reason I am asking them is not because I've decided to not
implement access by subject name (though given the SAN situation,
and the potentially large number of SANs to test, the feature is
tricky to implement fully and correctly).  Rather, understanding
the use cases that motivate feature requests help us figure out
whether we're building the right and sufficiently general feature.

I should also note that with LE and certbot's "--csr" option you
can renew LE certificates *without* changing the public key.  In
which case the public key fingerprint is stable, and need not
change.

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

Re: Authenticating clients based on CA/CN-match

Wietse Venema
In reply to this post by martin f krafft-2
martin f krafft:

Checking application/pgp-signature: FAILURE
-- Start of PGP signed section.

> also sprach Wietse Venema <[hidden email]> [2017-09-17 21:51 +0200]:
> > I wonder, if this is used for 'internal' email traffic, why bother
> > with certificates that require frequent renewal? If the organization
> > is that large, I would expect that all external email is handled
> > by relay hosts on the perimeter, instead of allowing direct mail
> > from random 'internal' hosts.
>
> That's precisely what we're trying to do, except the perimeter is
> non-physical as the hosts are spread across the 'Net, and there's no
> consistent VPN, unfortunately.
>
> So yes, all external mail is handled by a defined set of relay hosts
> on the perimeter, but we need a sensible way to authorize access to
> those relay hosts. I'd prefer certificates over SASL passwords, and
> I think that the ease of using letsencrypt far outweighs the
> additional security we'd get in return for the effort required to
> manage our own PKI.

Why involve PKI when these hosts can't send direct mail to the
Internet, and have to send through your relays?

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Authenticating clients based on CA/CN-match

Marat Khalili
In reply to this post by Viktor Dukhovni
A very interesting discussion...

On 17/09/17 22:49, Viktor Dukhovni wrote:
> There is no meaningful ordering of SANs.
Can you explain a bit more detail here? (c) :) I though you can list
SANs in the order you want in your certificate request and everything
else will preserve it, and that applies to Let's Encrypt signed
certificates too?

(Also, in case of OP, why couldn't LE certificate with single SAN be
obtained for each client?)

--

With Best Regards,
Marat Khalili

Reply | Threaded
Open this post in threaded view
|

Re: Authenticating clients based on CA/CN-match

martin f krafft-2
In reply to this post by Viktor Dukhovni
also sprach Viktor Dukhovni <[hidden email]> [2017-09-18 00:31 +0200]:
> So your certral system generates the keys, and obtains the LE
> certificates on behalf of the far-flung hosts?  And then pushes
> these keys to the hosts over an SSH tunnel?
>
> Is that only for the initial key issuance?  And then each host
> rotates the certs independently of the central system using the
> existing key to authenticate to LE?

No, they're all managed centrally and pushed regularly.

> I am curious why you want to rotate the submission TLS client
> keys. If you are able to centrally push keys to the hosts, why
> bother with a CA at all?  Why not generate a self-signed key+cert,
> store the fingerprint in a database, and leave LE out of it?  The
> key would not change for the lifetime of the host.

This is a very good question, and I'm blushing a bit having to admit
that I haven't thought of that. Heck, Debian even gives you a free
snakeoil cert on installation. I'll totally have to look into it.
Thanks for the brainfood.

> DNSSEC helps with having CAA records that are difficult to MiTM,
> and protectst the DNS challenge protocol, but I don't whether it
> is possible to disable bootstrapping over weaker email challenges
> and/or control over port 80.

This is another excellent point I'lll bring up with the LE folks: if
I go through lengths securing my DNS chain for their challenges,
I'd like to be able to lock my account onto that, a bit like HSTS.
At the moment, I have to assume, however, that LE wouldn't actually
care if I requested a cert renewal with a http-01 when I've used
dns-01 in the past.

Anyway, this is getting vastly off-topic… sorry about that.

> I should also note that with LE and certbot's "--csr" option you
> can renew LE certificates *without* changing the public key.  In
> which case the public key fingerprint is stable, and need not
> change.

Hm, yes, I knew that, but I only just found out that postfix 2.9+
can do check_ccert_access based on the public key fingerprint (not
the certificate fingerprint). So that's that then…

> The reason I am asking them is not because I've decided to not
> implement access by subject name (though given the SAN situation,
> and the potentially large number of SANs to test, the feature is
> tricky to implement fully and correctly).

Indeed, it's not as easy as I had imagined. OTOH, it would not be
unfathomable to iterate all SANs and check each against an access
map. For sanity, one could introduce an upper bound. And it's
a policy decision whether the final decision would be the min or the
max of the set of sub-decisions…

Thanks a lot for this enlightening exchange.

--
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
takt ist der auf das benehmen angewandte gute geschmack.
                                              -- nicolas de chamfort
 
spamtraps: [hidden email]

digital_signature_gpg.asc (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Authenticating clients based on CA/CN-match

Viktor Dukhovni
On Mon, Sep 18, 2017 at 10:09:14PM +0200, martin f krafft wrote:

> > Is that only for the initial key issuance?  And then each host
> > rotates the certs independently of the central system using the
> > existing key to authenticate to LE?
>
> No, they're all managed centrally and pushed regularly.

So, though this is not your best option, you can centrally capture
the updated fingerprints and automate their deployment (along with
the most recent previous fingerprint to avoid race conditions).

> > I am curious why you want to rotate the submission TLS client
> > keys. If you are able to centrally push keys to the hosts, why
> > bother with a CA at all?  Why not generate a self-signed key+cert,
> > store the fingerprint in a database, and leave LE out of it?  The
> > key would not change for the lifetime of the host.
>
> This is a very good question, and I'm blushing a bit having to admit
> that I haven't thought of that. Heck, Debian even gives you a free
> snakeoil cert on installation. I'll totally have to look into it.
> Thanks for the brainfood.

That should address your problem.  You can think of these are
complex passwords, where the server only knows the hash.  You'd
get the same security with a SASL password database that used
decently hashed passwords as a backend.  I agree that public key
fingerprints are easier to manage, as that gets SASL out of the
way.

> At the moment, I have to assume, however, that LE wouldn't actually
> care if I requested a cert renewal with a http-01 when I've used
> dns-01 in the past.

I'd also be curious to know the answer to that.  Please follow-up
if you find out.  I'm sure that enough folks here use LE certs to
justify a slightly off-topic post.

> > I should also note that with LE and certbot's "--csr" option you
> > can renew LE certificates *without* changing the public key.  In
> > which case the public key fingerprint is stable, and need not
> > change.
>
> Hm, yes, I knew that, but I only just found out that postfix 2.9+
> can do check_ccert_access based on the public key fingerprint (not
> the certificate fingerprint). So that's that then…

The Postfix fingerprint security level does not distinguish between
certificate fingerprints and public key fingerprints.  It is assumed
computationally infeasible to take a given public key and construct
a certificate with the same hash.  That'd be a 2nd pre-image attack,
and none are known even for MD5 at present.  So the client is
accepted when the key in the lookup table matches either the
certificate or the public key.

I think I made the right call, a non-negligible number of DANE
users initially get confused about the "selector" field, and publish
the certificate digests along the public key selector (SPKI(1)
instead of Cert(0)).

> Indeed, it's not as easy as I had imagined. OTOH, it would not be
> unfathomable to iterate all SANs and check each against an access
> map. For sanity, one could introduce an upper bound. And it's
> a policy decision whether the final decision would be the min or the
> max of the set of sub-decisions…

Yes, that's possible, but not architecturally appealing.  We could
default the limit to say 10, and if the client has more than 10
names process none of them.  I'd not be a fan of processing just
a subset.

All that said, the case for submission based on CA authenticated
key -> name bindings is not looking too strong.  This is not going
to have a significant priority unless a more compelling use-case
shows up.

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

Re: Authenticating clients based on CA/CN-match

Michael Ströder
In reply to this post by martin f krafft-2
martin f krafft wrote:

> also sprach Viktor Dukhovni <[hidden email]> [2017-09-18 00:31 +0200]:
>> So your certral system generates the keys, and obtains the LE
>> certificates on behalf of the far-flung hosts?  And then pushes
>> these keys to the hosts over an SSH tunnel?
>>
>> Is that only for the initial key issuance?  And then each host
>> rotates the certs independently of the central system using the
>> existing key to authenticate to LE?
>
> No, they're all managed centrally and pushed regularly.
Then you have all the cert fingerprints available in a central location
and can easily push them on your smart host. Maybe I misread something
though.

Ciao, Michael.


smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Authenticating clients based on CA/CN-match

martin f krafft-2
In reply to this post by Viktor Dukhovni
also sprach Viktor Dukhovni <[hidden email]> [2017-09-18 22:39 +0200]:
> > No, they're all managed centrally and pushed regularly.
>
> So, though this is not your best option, you can centrally capture
> the updated fingerprints and automate their deployment (along with
> the most recent previous fingerprint to avoid race conditions).

In fact, there are three options right now:

  a/ collect and deploy the fingerprints, as you say
  b/ use a self-signed certificate with life-time 99 years just for
     this purpose
  c/ use public key fingerprints instead of the cert fingerprints

I think (a) is really just ungood. I just implemented (c), which was
trivial and solves the problem. Thanks also to Daniel Kahn Gilmor
for the vital hint that made me realise Postfix 2.9 supports this.

Long-term, I think I might want to look into (b) though. I like the
idea of having a single certificate ("identity") of a host, that
then gets used in its various facets, but that's actually probably
not good security advice anyway.

> > At the moment, I have to assume, however, that LE wouldn't actually
> > care if I requested a cert renewal with a http-01 when I've used
> > dns-01 in the past.
>
> I'd also be curious to know the answer to that.  Please follow-up
> if you find out.  I'm sure that enough folks here use LE certs to
> justify a slightly off-topic post.

I'll put this in my tickler file for 30 days from now.

> All that said, the case for submission based on CA authenticated
> key -> name bindings is not looking too strong.  This is not going
> to have a significant priority unless a more compelling use-case
> shows up.

Yeah, makes sense. Thanks for your patience!

--
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
"computer science is no more about computers
 than astronomy is about telescopes."
                                               -- edsgar w. dijkstra
 
spamtraps: [hidden email]

digital_signature_gpg.asc (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Authenticating clients based on CA/CN-match

Michael Ströder
martin f krafft wrote:

> In fact, there are three options right now:
>
>   a/ collect and deploy the fingerprints, as you say
>   b/ use a self-signed certificate with life-time 99 years just for
>      this purpose
>   c/ use public key fingerprints instead of the cert fingerprints
>
> I think (a) is really just ungood. I just implemented (c), which was
> trivial and solves the problem. Thanks also to Daniel Kahn Gilmor
> for the vital hint that made me realise Postfix 2.9 supports this.
>
> Long-term, I think I might want to look into (b) though. I like the
> idea of having a single certificate ("identity") of a host, that
> then gets used in its various facets, but that's actually probably
> not good security advice anyway.
Frankly I don't get why you prefer (b) over (a). If you enroll the LE
certs in a central location then you already have the fingerprint and
you don't have to collect them over an untrusted channel like for
self-signed certs generated during OS installation (b). Well, you
probably trust your SSH connection but right after OS deployment you
have a hen-and-egg trust problem with SSH host key too.

Ciao, Michael.


smime.p7s (5K) Download Attachment