[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ISAKMP Extended Authentication



John Irish writes:
> I should point out that the application I am looking at is a Network
> Computer which could be powered down at any point in time.

I don't think that is a problem, as long as it has kind of protected
permanent storage to store the host private key and its certificate. 

> Such a host is not necessarily trusted to the same extent that a CA
> would be.

If the machine cannot be trusted, why you try to authenticate the
machine at all? Remember that you can also make the system so that the
host always sends also the permament user certificate from the smart
card to the server, so the server can check:

	1) that the permanent user certificate is valid (validity,
	   crls etc), and is signed by trusted CA.
	2) that the host certificate is valid (validity, crls etc) and
	   is signed by the trusted CA (same than the user certificate
	   or different one).
	3) that the temporary user certificate contains the same
	   user identification that the permanent user certificate.
	4) that the temporary user certificate is signed by the host
	   certificate, and contains the identification of that (for
	   example host adds subjectAltName ipaddress field having its
	   own ip-number).
	5) that the temporary user certificate has short enough
	   validity period (check against policy).

So after that the server can be sure that both the hosts private key
and user private key are are needed for the authentication.

> The approach Tero recommends would also permit the host to fabricate
> a user certificate since the host could easily make up a
> public/private key pair and ignore the smart card altogether.

Yes, but if the server wants to see also the permanent user
certificate, then the host cannot do it, because it doesn't know the
private key in the smart card. You need to do this if you don't trust
the host enough. 

> I don't think turning all these host systems into CA's is prudent.
> If every host had the authority of a CA, the trust associated with a
> CA would disappear.

No. The host is not a real CA, it is just sub CA, which is not trusted
itself. The host still must provide the chain of certificates to
proper root CA to get any trust at all. The trust will still be in the
root CA, the host CA is just a way to say, that this host
(authenticated by the root CA) is saying that this user (authenticated
by the user root CA and permanent user certificate) is using this
machine, and this certificate will be provided to proof that for next
10 minutes. 

> Given that this level of trust is not acceptable when deploying
> 100's of such systems, I would think that the extended
> authentication mechanism I suggested may be cleaner - presuming it
> could be adapted to this role. What are your thoughts on the use of
> this mechanism?

If you don't trust the host, why are you trying to authenticate it?
Why isn't the user authentication enough, so just using the user
certificate on the smart card?

I would say that implementing the system I explain above is propably
easier than using extended authentication. Also it doesn't need any
changes to the isakmp protocol, only some changes to the
implementations. 
-- 
kivinen@iki.fi                               Work : +358-9-4354 3218
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/


References: