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

Re: ISAKMP Extended Authentication

John Irish writes:
> 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?

If you want to use public key encryption authentication then you
either must have the certificate already or, you must send it along
the first ike packet of the main mode (you cannot use aggressive
mode). There are also some other problems with public key encryption
authentication. 

> Assuming a certificate push were permitted with the first "HDR, SA" packet,

Yes, it is allowed. The isakmp draft says that certificate payloads
may exists in any 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.

The isakmp draft says that the certificate request payload may exists
in any packet, and the ike draft only limits them in the final packet
(== i.e. where it would expand the negotiation).

Certificate requests are allowed also with public key encryption
authentication. The example in the draft doesn't list any CERT or CR
payloads, but that doesn't mean they are not allowed. 

The problem with the public key encryption is that you
must be able to find correct certificate for the other end, when you
are encrypting the identity to be send to other end. This means that
if the other end doesn't send certificates in the first or second
packet then you must have some other method of finding them.

Note also, that in this case it doesn't really matter which
certificate we choose (temporary user certificate or permanent user
certificate), because both of them have the same public key.

What we cannot select is the host certificate based on the ip-address,
because the other end is using the user public key to authenticate
itself, not host public key. The selection is quite easy, because host
certificate has the basic constraints extension saying it is CA, so we
can select any of the certificates other end sends, that doesn't have
CA bit on.

> 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.

Note, that public key signatures authentication doesn't have this
restrictions, there we need certificates only in the end to
authenticate the full exchange.
-- 
kivinen@iki.fi                               Work : +358-9-4354 3218
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/
References: