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

Rob Crittenden rcritten at redhat.com
Fri Nov 6 19:19:08 UTC 2009


Dmitri Pal wrote:
> Simo Sorce wrote:
>> 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.
>>
>>   
> 
> This all makes sense but Rob's question from the bug is still open:
> 
> "The question is, even if we can look at subjectAltName in the IPA
> backend how
> will we prevent users from mis-using subjectAltName, such as requesting
> a cert
> for a host they don't control?"

Right. I'm not entirely sure how I'll implement this check. And I think 
the answer is different depending on whether an admin or a machine is 
doing the request.

I'd think that for a host we'd want a list of acceptable hostnames.

For an admin user I'm not so sure.

rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20091106/ac6c662a/attachment.bin>


More information about the Freeipa-devel mailing list