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

Re: ISAKMP Extended Authentication

Taking this a step further ... presuming you generated this temporary User
certificate.  How could the "server" use this certificate to authenticate
via public key "encryption" during an ISAKMP/Oakley (IKE) Phase 1
negotiation?

Assuming a certificate push were permitted with the first "HDR, SA" packet,
how would the initiator know which CA and certificate type was acceptable to
the responder?  Per the IKE spec, issuing a certificate request, when using
public key encryption for authentication in Phase 1, is not supported.

As a Network Computer we are trying to avoid the use of pre-shared
secrets/keys leaving us with public key encryption for the Phase 1
authentication method.  This method would appear to dictate the use of a
directory server to acquire certificates prior to completing the
Diffie-Hellman exchange in Phase 1.

John

-----Original Message-----
From: Tero Kivinen <kivinen@ssh.fi>
To: John Irish <irishjd@erols.com>
Cc: Greg Carter <greg.carter@entrust.com>; IPSEC <ipsec@tis.com>
Date: Tuesday, November 24, 1998 2:56 PM
Subject: 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/
Follow-Ups: