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

RE: Aggressive/Base Mode Signature Queries

Walker, Jesse writes:
> Thanks for the response, but this answer seems to contradict
> 
>    The
>    responder to the Certificate Request payload MUST send its
>    certificate, if certificates are supported, based on the values
>    contained in the payload.
> 
> from p 34 Section "3.10 Certificate Request Payload" from RFC 2408, the
> ISAKMP spec. The peer asked for a cert signed by C2, not C1. I don't follow
> why the initiator gets to ignore the MUST in the above sentence in this
> particular circumstance.

It did send its certificate, so it did follow the MUST. It can also
send another certificate Cert(A2,C2), but I think it will be useless
as the certificate is not used in the exchange, but it can do so.

The issue here is that the signature generated is tied to the identity
it sent, i.e it is going to bi Sig(A1), no matter what certificates
are sent or not sent in the exchange.

So the acceptable responses are:

a) (3) HDR, Sig(A1), Cert(A1, C1), Cert(A2, C2)
b) (3) HDR, Sig(A1), Cert(A2, C2)
c) (3) HDR, Sig(A1), Cert(A1, C1)

etc, i.e anything that contains Sig(A1), and some certificates.
Sending Cert(A2,C2) does not gain anything for this exchange, but it
might be usefull for the later exchanges, so the preferred reply is
propably the case a. I agree that the case c is might be agaist the
rfc, as we sent certificate only based some values in the certificate
request, not all. The reason I used that is that it is the one that
works with most of the implementations. 

Anyways, the initiator CANNOT reply with

(3) HDR, Sig(A2) ...

because the Signature A2, does not match the identity sent in the
first message. Draft-ietf-ipsec-pki-req-05.txt says in section 6.7:

----------------------------------------------------------------------
6.7	Matching ID payloads with certificate subjects

An IKE implementation that conforms to this profile MUST NOT use an end
entity certificate received from an IKE peer for purposes of completing
the IKE authentication process unless there is a match in both content
and format between the ID payload (IDii or IDir) offered by the peer in
the IKE negotiation and at least one of the name forms carried in
either the subject or subjectAltName fields in the certificate
received.
----------------------------------------------------------------------

There are two basic methods to implement this:

      1) Search the certificate based on the ID payload
      2) Verify the ID and certificate after successfull signature
         check.

If we use the ID payload to search the certificate, then it does not
really matter if we used case a, b, or c. If the certificate can be
found we select the correct certificate and use that the verify the
signature. In case b it might be that we don't have the Cert(A1, C1),
and it might be possible that we don't find it from the ldap or
anywhere else, thus the negotiation might fail. For cases a and c the
negotiation will succeed.

The problem with this method is that if there multiple certificates
matching the ID payload then we don't know which of them to use, and
we have to do some extra checks for those. This include using all of
the certificates to verify the signature and if any of them succeeds
then the signature check succeed. Of course there can be all kind of
optimizations there, like first trying those certificates the other
end actually sent to you, and hope that the other end sent you the one
he actually used. This kind of situation, where you have multiple
certificates with same ID can happen for example when we have two
certificates for the same host having different validity periods.

The second case doesn't really specify how to find the certificate in
first place, but normally those implementations will assume it is
inside the IKE negotiation, and take the first or all certificates
inside the IKE negotiation. If they just take first certificate, then
case a will fail or succeed depending on the order of certificates.
Case b is always going to fail, and case c is always going to succeed. 
-- 
kivinen@ssh.fi                               Work : +358 303 9870
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/
References: