[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: issues with IKE that need resolution
On Fri, 18 Sep 1998 06:47:08 PDT you wrote
> The requirement is -- we want one SA for multiple purposes
But do the IDs that are used to express our desires need to be encoded
in a certificate?
There's IDs used to identify ourselves (phase 1) and IDs used to
constrain IPSec SAs (phase 2). They're not necessarily interchangable.
And the IDs used to identify ourselves should be encoded in a cert
(well some. I don't see ID_KEY_ID being too useful) but the IDs used
to constrain the IPSec SAs don't need to be. At least I don't see why.
Can anyone enlighten me?
> The problem is -- expressing what we want gets complex, ugly,
> and possibly unworkable.
>
> I note also that rough consensus is that rfc822name and fqdn
> are, for all intents and purposes, a slab of printable characters.
Well, yes, but a well-defined subset of the possible characters that
can fit in a slab. I'm not arguing with the consensus for rfc822names
and fqdn. They have a place as a phase 1 identity and it makes sense
to encode them into a cert for identification purposes, but what's the
point of sending an rfc822name as in phase 2? What's the point of encoding
a list of subnets in a cert for a phase 1 identity?
> Why don't we add ONE ID type, LABEL, which is an "arbitrary printable
> string"? It's meaning gets defined outside of IKE (but within bounds
> of the archtecture or something). So then we'd say something like
> "id=banktellers" which means "telnet between 9 and 5 local time to
> host-a and FTP between 4 and 5 local time to host-b". These
> labels could be Policy Language (program names) or (gasp!) email addresses
> or driver's licence numbers or whatever you want.
I can't tell if your serious or being sarcastic here. I think the later.
> THEN, building on that, the ideas that Scott mentioned could be
> dealt with as specially defined labels. This would be done in the
> previously-invented style of host "localhost" or email address
> "postmaster@cisco.com".
>
> This does not get the information itself (the list of subnets or ports, etc.)
> transmitted over the IKE data path but it lets you say something more
> sophisticated than "ugh, let me talk to 10.0.0.1".
We can already say that. We can even say "let me speak ftp to all hosts
on 10.10.10.0/24". But that's about it. We can't express things like
"let me speak UDP with a port higher than 1024 to 10.10.10.1". We can't
say "let me speak to 10.10.10.0/24 and 10.10.8.23" etc.
And the ID payload wasn't designed to express these things anyway. We can
try to make it express these things (square pegs do fit in round holes
with enough effort) or we can say that the ID payload is already too
overloaded and we should define a new way of expressing our desires to
the other party.
Dan.
Follow-Ups:
References: