[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: issues with IKE that need resolution
Is there a point in identifying yourself as "198.31.2.0/24"? What
does that mean? "I speak for this network"? Without something like the KX
record in DNS to delegate that authority why should I belive it? Chances
are he'd probably be making this statement through another interface anyway
so what should I do if 198.31.1.18 says "I'm 198.31.2.0/24"? Also, what are
you going to do about the ID_KEY_ID identity? A certificate that certifies
that my identity is an intentionally incomprehensible blob is not going
to be all that useful.
It seems to me that we have identities that are only useful in phase 1 and
some of those should have ways to be encoded into a cert. There are others
that really only make sense in phase 2 because their purpose is to
constrain use of an IPSec SA. As an example, a gateway product receiving
phase 2 identities of IDci = "IPv4_ADDR 132.39.3.12" and IDcr =
"ID_FQDN dharkins@cisco.com" would not be particularly useful. What
does "dharkins@cisco.com" mean? There is no machine cisco.com and there
sure isn't a user dharkins there. Clearly, FQDN is a phase 1 identity and
a way to encode it in a cert is good. But passing it in phase 2 would not
make much sense. Similarly, a list of subnets is not a very good phase 1
identity and I don't see much value in defining a way to encode that in a
cert but as a phase 2 identity it may be quite useful. Or am I missing
something here?
Addressing Scott's point: the ID payload is woefully overloaded. We're
trying to express SPD policy in it and that was not its original purpose.
If I remember correctly Steve Kent removed some selector types from the
Architecture Draft because IKE was unable to express them. It would not
only be nice to have lists of address ranges, it would be nice to express
the "everything but" construct: "this SA is to be used for all TCP except
port 80". But I'm not sure the poor ID payload is the place to do it.
Anybody have any ideas on how to express policy _right_? At the TrustMgt
BOF in Chicago KeyNote was presented and that seems like a good start.
Actions are described as attribute-value pairs. IKE expresses attribute-value
pairs quite well. If we had a good way to define desired actions ("I'd
like to access your ftp server on machine A and your http server on machine
B and C") we could apply a request for those actions-- a series of
attribute-value pairs in some new payload-- to the collection of assertions
we have that define our local policy ("only <some class of people> may
access our ftp server and all other TCP ports except telnet can be accessed
by anyone except <some other class of people> and RIP goes in the clear").
I think the whole phase 2 identity stuff needs some serious revisiting
and alot more than just defining new types.
Dan.
On Thu, 17 Sep 1998 17:39:27 PDT you wrote
> What do you want certificates to contain for these other ID types? People
> have asked me, off and on, about subnets having their own certificates and
> other cases. Sounds reasonable to me, but I can just see some PKI service
> provider blanching at the notion of issuing a certificate for an entire
> class A subnetwork.
>
> >We would like to be able to specify a list of subnets, addresss ranges,
> >or individual ip addresses in the ID payload without having to send
> >multiple payloads if possible. One idea we've come up with for doing
> >this which seems appropriate would be to add a couple of new ID types:
> >
> > ID type Value
> > ------- -----
> > RESERVED 0
> > ID_IPV4_ADDR 1
> > ID_FQDN 2
> > ID_USER_FQDN 3
> > ID_IPV4_ADDR_SUBNET 4
> > ID_IPV6_ADDR 5
> > ID_IPV6_ADDR_SUBNET 6
> > ID_IPV4_ADDR_RANGE 7
> > ID_IPV6_ADDR_RANGE 8
> > ID_DER_ASN1_DN 9
> > ID_DER_ASN1_GN 10
> > ID_KEY_ID 11
> > ------- SUGGESTED -------
> > ID_IPV4_ADDR_LIST 12
> > ID_IPV4_ADDR_SUBNET_LIST 13
> > ID_IPV4_ADDR_RANGE_LIST 14
Follow-Ups:
References: