Mailing List Archive

On Tue, 16 Jun 2020, Rory Campbell-Lange wrote:

> I'm working on a small server written in Go to add short-lived user
> certificates to the forwarded agents of authorized users.
>
> https://github.com/rorycl/sshagentca
>
> This seems to work quite well for accessing sshd servers with the
> appropriately configured "TrustedUserCAKeys" directive.
>
> I have been in a debate about how similarly adding host certificates to
> forwarded agents could help mitigate man-in-the-middle attacks. This has
> raised a few questions.
>
> Firstly, given a host CA signing key on the sshagentca server, would an
> appropriately constructed host certificate added to a forwarded agent
> replace the necessity for a '@cert-authority' line in a user's known_hosts
> file?

I'm not sure I want to add yet another path (the agent) to ssh's already
twisty host key verification logic. However, a few people have requsted
a KnownHostsCommand option that allows the output of a subprocess to
be used in addition to the usual known_hosts. Would this work for you?

> Secondly, would there be any alteration to the requirement for a
> "HostCertificate" CA-signed public key (from a private "HostKey") on
> sshd receiving servers?

I don't understand what you mean here. Could you elabourate?

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On 17/06/20, Damien Miller (djm@mindrot.org) wrote:
> > Firstly, given a host CA signing key on the sshagentca server, would an
> > appropriately constructed host certificate added to a forwarded agent
> > replace the necessity for a '@cert-authority' line in a user's known_hosts
> > file?
>
> I'm not sure I want to add yet another path (the agent) to ssh's already
> twisty host key verification logic. However, a few people have requsted
> a KnownHostsCommand option that allows the output of a subprocess to
> be used in addition to the usual known_hosts. Would this work for you?
>
> > Secondly, would there be any alteration to the requirement for a
> > "HostCertificate" CA-signed public key (from a private "HostKey") on
> > sshd receiving servers?
>
> I don't understand what you mean here. Could you elabourate?

My apologies for the poor explanation. Let me try again.

Adding a user certificate to a client forwarded agent allows that client
to use that certificate to authenticate to servers with
TrustedUserCAKeys set to the public key used to sign the certificate.

What would host certificates added to a client forwarded agent give one
(if any), and what part of the normal set of configuration requirements*
does it help with?

* normal config : @cert-authority in the client's ~/.ssh/known_hosts;
setup of appropriate HostCertificate directives on receiving hosts

Thanks very much
Rory
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On 17/06/20, Rory Campbell-Lange (rory@campbell-lange.net) wrote:
> Adding a user certificate to a client forwarded agent allows that client
> to use that certificate to authenticate to servers with
> TrustedUserCAKeys set to the public key used to sign the certificate.
>
> What would host certificates added to a client forwarded agent give one
> (if any), and what part of the normal set of configuration requirements*
> does it help with?

My apologies -- I'd completely misunderstood the mode of operation of
host certificates.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Wed, 17 Jun 2020, Rory Campbell-Lange wrote:

> > > Secondly, would there be any alteration to the requirement for a
> > > "HostCertificate" CA-signed public key (from a private "HostKey") on
> > > sshd receiving servers?
> >
> > I don't understand what you mean here. Could you elabourate?
>
> My apologies for the poor explanation. Let me try again.
>
> Adding a user certificate to a client forwarded agent allows that client
> to use that certificate to authenticate to servers with
> TrustedUserCAKeys set to the public key used to sign the certificate.
>
> What would host certificates added to a client forwarded agent give one
> (if any),

Hmm, the agent deals with private keys only at present. Do you mean
modifying the agent to support adding the public part of host
certificates?

If so, then I guess it would be possible to use the agent as a kind of
known_hosts file but there is a lot of glue needed to make that happen
and I'm not sure the agent is an ideal place for it.

If you do mean adding the private host keys then it would additionally
make host-based authentication possible via the agent but, less
beneficially, give the user and anyone with access to their agent socket
the ability to impersonate those hosts.

> and what part of the normal set of configuration requirements*
> does it help with?
>
> * normal config : @cert-authority in the client's ~/.ssh/known_hosts;
> setup of appropriate HostCertificate directives on receiving hosts

I don't think it really helps with this. What you might want to be able
to forward around with you is your database of known_hosts, including
the @cert-authority markers. These are public keys only, plus the host
name(s) they apply to, plus a couple of bits per key of metadata (revoked,
cert-authority, etc.)

The agent, as it stands, only handles private keys (not public), has
no ancilliary metadata storage and no protocol verbs to perform the
actions needed by host key verification. All these would need to be
added for the agent to be capable of subsuming known_hosts operations.

However these are sufficiently different to the agent's current role
that it would be worth considering doing it in a different service,
as the agent really needs to be as simple and to present as little
attack surface as possible so it can protect its private keys.

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On 18/06/20, Damien Miller (djm@mindrot.org) wrote:
> On Wed, 17 Jun 2020, Rory Campbell-Lange wrote:
> > Adding a user certificate to a client forwarded agent allows that client
> > to use that certificate to authenticate to servers with
> > TrustedUserCAKeys set to the public key used to sign the certificate.
> >
> > What would host certificates added to a client forwarded agent give one
> > (if any),
>
> Hmm, the agent deals with private keys only at present. Do you mean
> modifying the agent to support adding the public part of host
> certificates?
>
> If so, then I guess it would be possible to use the agent as a kind of
> known_hosts file but there is a lot of glue needed to make that happen
> and I'm not sure the agent is an ideal place for it.
>
> If you do mean adding the private host keys then it would additionally
> make host-based authentication possible via the agent but, less
> beneficially, give the user and anyone with access to their agent socket
> the ability to impersonate those hosts.
>
> > and what part of the normal set of configuration requirements*
> > does it help with?
> >
> > * normal config : @cert-authority in the client's ~/.ssh/known_hosts;
> > setup of appropriate HostCertificate directives on receiving hosts
>
> I don't think it really helps with this. What you might want to be able
> to forward around with you is your database of known_hosts, including
> the @cert-authority markers. These are public keys only, plus the host
> name(s) they apply to, plus a couple of bits per key of metadata (revoked,
> cert-authority, etc.)
>
> The agent, as it stands, only handles private keys (not public), has
> no ancilliary metadata storage and no protocol verbs to perform the
> actions needed by host key verification. All these would need to be
> added for the agent to be capable of subsuming known_hosts operations.
>
> However these are sufficiently different to the agent's current role
> that it would be worth considering doing it in a different service,
> as the agent really needs to be as simple and to present as little
> attack surface as possible so it can protect its private keys.

Thank you for your thoughtful consideration of my rather misguided
enquiries.

The agent only having private keys and as small an attack surface as
possible makes complete sense.

Rory

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev