[Freeipa-devel] Re: Certificate enrollment, principal names

[Simo Sorce]

On Fri, 2009-11-06 at 11:48 -0500, Dmitri Pal wrote:
> This is where you lost me.
> You can't trust the client unless it is authenticated.
> But it authenticated so it is trusted to say what it wants.
> If it wants something not allowed it would not be
> allowed but at least after authentication you trust
> client's claim that the client is actually the entity
> it says it is. Where is the problem? That the client sends some
> garbage?
> That the client's identity was hijacked?

Yes. A host can be compromised, we can't entirely trust a CSR coming
from a host if we do automatic approval. We need to always validate what
clients present us.

> If it was we either have a case of a stolen admin password and then I
> do not think you can do a lot about it or
> someone impersonated the host and requested a cert for a service that
> this host is allowed to request certs for
> so how you can distinguish it from a valid request?

If a (senior enough) admin requests a cert we can allow everything in
the CSR, once you have admin credentials you can do whatever you want, I
am not concerned about that case too much.

If a host is requesting a cert then no, we need some more validation, as
host credentials are stored in the hosts themselves, so anyone with root
access on the host can use those credentials.

> Sorry, may be I am missing something  but I still do not get the
> point.

The point is that the level of trust you can give to a host is not
limited.

> Can someone explain please what we want to prevent from happening?

That we allow to generate and ship certificates that can be used to MITM
or otherwise deceive clients.

We may want to do some validation also in case cert creation for host is
delegated to some lower level admins, actually.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York