[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Aggressive/Base Mode Signature Queries
For certificate based exchanges, I have always believed that the certificate
is the best identifier of the peer and that the phase 1 ID payload is
generally superfluous dead weight. Although I could see that specifying
different parts of the cert within the ID payload for different connection
requirements could perhaps be used to indicate something useful.
Generally, I believe that the only reason that the phase 1 ID payload has
any significance for a certificate based exchange is for the case where a
certificate doesn't need to be sent within IKE (cert retrieved via some
other means) and for the majority of implementations which prefer the ease
of policy lookups based on ID payload (a subset of the certificate) as
opposed to policy lookups based on the whole certificate (or a subset of the
certificate as determined by local policy and not what is supplied/dictated
by the peer - here again the peer's ID payload could possibly be used to
indicate which of several "matching" policies should be used).
For implementations that base policy decisions on the ID payload, the
scenario described will never result in the successful completion of Phase 1
(unless the implementation is broken and doesn't verify that the ID is
contained within the cert). For implementations that base policy decisions
on actually identity (the cert) as opposed to stated identity (ID payload),
phase 1 will complete (assuming B's policy allows A2).
-dave
-----Original Message-----
From: Radia Perlman - Boston Center for Networking
[mailto:Radia.Perlman@East.Sun.COM]
Sent: Monday, January 08, 2001 11:10 AM
To: kivinen@ssh.fi; jesse.walker@intel.com
Cc: ipsec@lists.tislabs.com
Subject: RE: Aggressive/Base Mode Signature Queries
Re: Jesse's question
Perhaps another way of
looking at it is that in Jesse's example
A1 and B1 have C1 in common, and A2 and B2
share a CA C2. It's not that A and B share
two CAs {C1 and C2}. The different names (A1, A2) are different identities
from the protocol viewpoint.
So if A doesn't have a cert from C2 for
identity A1, and C2 is the only one trusted by B1, then A1 and B1
can't communicate, although if A tries to communicate via identity
A2 it will work (assuming B1 trusts CA2).
Given Jesse's quote from the spec:
The
responder to the Certificate Request payload MUST send its
certificate, if certificates are supported, based on the values
contained in the payload.
It doesn't seem right to respond with a certificate from a different
CA than was requested by the other side. So in any case, it
would seem like the spec is clear that if you don't have a cert
from the CA requested by the other side for the
identity with which you initiated contact, authentication fails.
Perhaps some heuristics might be good, like if A1 asks B1 for
a cert from CA1, and B1 has one, AND B1 trusts CA1 (as well
as perhaps other CAs), B1 should request a cert from CA1 in preference to
any of the other CAs that B1 also trusts.
Radia
Follow-Ups: