[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
ISAKMP/Oakley - Certificate exchange
John Irish writes:
> Within the IKE spec <draft-ietf-ipsec-isakmp-oakley-08.txt>, Section 5.2 -
> Authentication with Public Key Encryption, the 2nd paragraph states:
>
> "In order to perform public key encryption, the initiator must already have
> the responder's public key."
>
> My statement should have indicated that the initiator can not issue a
> certificate request based upon the statement above.
That doesn't say anything about certificate requests or certificates.
The isakmp draft (draft-ietf-ipsec-isakmp-10.txt) says:
----------------------------------------------------------------------
3.9 Certificate Payload
...
... The Certificate payload MUST be
accepted at any point during an exchange.
...
3.10 Certificate Request Payload
...
... The Certificate Request payload MUST be accepted at any point dur-
ing the exchange. The responder to the Certificate Request payload MUST
send its certificate, if certificates are supported, based on the values
contained in the payload. ...
----------------------------------------------------------------------
And the ike draft (draft-ietf-ipsec-isakmp-oakley-08.txt) limits the
certificate request only by this:
----------------------------------------------------------------------
...
Exchanges in IKE are not open ended and have a fixed number of
messages. Receipt of a Certificate Request payload MUST NOT extend
the number of messages transmitted or expected.
...
----------------------------------------------------------------------
So and certificate payload MUST be supported in any packet using any
authentication method etc. Certificate requests MUST be supported in
any packet using any authentication method except when it would expand
the exchange (== it cannot be in the final packet).
The reason for this:
> "In order to perform public key encryption, the initiator must already have
> the responder's public key."
Is that in order to encrypt the identity and the nonce the initiator
needs the public key of the other end in the 3rd packet in the main
mode or in the 1st packet in the aggressive mode.
So in the aggressive mode using public key encryption as a
authentication method the initiator must already have responder's
public key.
In main mode the initiator needs that certificate only in the when it
sends its second packet (3rd packet in the main mode), and if the
other end didn't send his certificate in the his first packet (2nd
packet in the main mode), and he don't have methods to find the key he
has no other choise than to abort the negotiation.
Because of this the draft says that you must already have the
responder's public key.
> It would appear, although it is not stated, that in Main mode the responder
> could include a certificate request with the first response packet which
> includes the SA payload. It is not clear why the initiator could not
> include a certificate request with the very first packet, and the responder
> include its certificate plus a certificate request in the first response
> packet.
It could, but it is not mandated that the responder must send its
certificates inside his first packet. The certificate request
description only says that the response must come, but it doesn't say
when.
I think we could remove that paragraph from the draft. In the
aggressive mode it is quite clear that we need that certificate before
we can start, because we need it to construct the first packet. In the
main mode if the initiator is capable of finding certificates it can
start the exchange and wait until the second packet before starting
the lookup for the certificate. This gives the responder opportunity
to send his certificate inside the his first ike packet, saving the
initiator a lookup from the directory.
> Part of the reason may be that system identities would be revealed
> by the certificate exchange in Main mode.
That is true, and if that is the reason (it might be), then it should
be stated in the draft also.
> In addition, the certificate
> needed by the initiator may depend upon the proposal selected by the
> responder, thus making a certificate request in the first packet premature
> (I'm guessing here). Does anyone have an answer to this?
That is true, but it doesn't matter. Extra certificates are cheap
inside the ike messages, if they save one extra ldap search from the
directory...
> HDR, SA, CertReq -->
> <-- HDR, SA, CERT, CertReq
> HDR, KE, CERT, <IDii_b>PubKey_r, <Ni_b>PubKey_r -->
> <-- HDR, KE, <IDir_b>PubKey_i, <Nr_b>PubKey_i
> HDR, HASH_I -->
> <-- HDR, HASH_R
This doesn't violate the draft, but what do you do if the responder
doesn't send his certificate request in his first packet (2nd packet
of the whole exchange), but still selected the public key encryption
authentication. You can either try to lookup the certificate from
somewhere or you can abort the negotiation.
--
kivinen@iki.fi Work : +358-9-4354 3218
SSH Communications Security http://www.ssh.fi/
SSH IPSEC Toolkit http://www.ssh.fi/ipsec/
References: