Re: Confirm decision on identity handling.

[Charlie_Kaufman@notesdev.ibm.com]

EKR <ekr@rtfm.com> wrote:
> Gregory Lebovitz <Gregory@netscreen.com>
writes:
> > I vote for disassociating ID from cert contents. (BUT, I proposed
text that
> > would allow for those who desired/required to be able to match
if they
> > wanted to).
> The problem, then, of course, is that you've just made it near
> impossible to make a system which works in the generic 
> "I want to establish an SA with some I've never heard
> of before" mode.

Many conventions need to be established
to be able to establish SAs with someone you've never heard of before.

The easiest would be opportunistic encryption,
where both ends would ignore both the ID fields and the cert contents (if
any). There is no authentication. You have no idea who you're talking to.
But you're protected from passive eavesdroppers.

To replace what SSL/TLS does, you would
need a convention at least on the responder end as to what goes in IDs
and/or certs. My recommendation for a convention would be that IDr is ignored,
the responder's cert must pass whatever rules it must pass in SSL/TLS.
I don't know whether those rules are spelled out in the spec, but I believe
the convention is that the cert must have a CN= the DNS name the initiator
was looking up. This is very un-IPsec like, because IPsec likes to pretend
that DNS names are irrelevant. But I think it's what's most appropriate
in this scenario. For initiator certs, I'd use the same rules as SSL/TLS.
Except I don't know if there are any rules in the spec and in practice
no one uses client certs with SSL/TLS other than in very specific (and
probably non-interoperable) ways.

It's hard to use IPsec between gateways
that have never heard of each other. The only access control they enforce
is who can talk to who, and if they will allow parties they have never
heard of to talk, it seems unlikely they are protecting against much.

        --Charlie