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

RE: ISAKMP Extended Authentication



Greg Carter writes:
> While a neat idea I don't see how this could scale, as well tuning every
> host system into a CA seems problematic.

I don't think that is that problematic. Note that this host is not
really acting as a real CA, it only creates (short lived) temporary
certificate. It doesn't have to maintain any kind of permanent
directory of the certificates, it can even restrict itself to having
only one valid signed certificates at a time.

> How do you enforce the identity in
> the temporary cert when the 'authority' is the host, the host can claim the
> 'user' identity is anyone?

If the other end trusts the host, it trusts the host. If the other end
doesn't trust the host, there is no use to try to authenticate the
host, and we just use end user certificate directly.

Of course the host can also send the permanent end user certificate to
the server so the server can check that the temporary certificate has
identical data than the permanent certificate. This migth be needed if
the server doesn't trust the host to be smart enough to check crls and
such for the end user certificate. 

> Is the gateway obligated to verify the info in
> the temp cert matches the one in the 'permanent' cert?

It can either check that, or trust the host (which is authenticated
by the host key certificate) to do the check. It depends on the
security policy you want to enforce. 

> What about access to
> the crl repository, typically it would be behind the gateway, so how does
> the host gain access to post the crl?

The CA root is propably going to issue CRLs, but the host propably
just uses very short validity period (like 10 minutes), and creates
new certificate every 10 minutes.

If the host provides crls, it does not put them in to any crl
repository, but just sends them along the IKE negotiation (so instead
of creating new certificate every 10 minutes it creates new CRL every
10 minutes).

Creating a new certificate and creating a new crl takes equal amount
of time (one signing operation), so I would just simplify the system
so that the host system never creates crls, it just uses very short
validity periods.
-- 
kivinen@iki.fi                               Work : +358-9-4354 3218
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/


References: