[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: issues with IKE that need resolution
On 17 Sep 98 at 21:11, Daniel Harkins wrote:
Hi, Dan,
I'm sorry to interrupt, but the discussion is important for me.
> 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?
I agreed with you. It would be great if applicability of every ID
type to phase 1 or 2 were explicitly stated somewhere in the drafts.
> 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.
What is the purpose of ID payloads in phase 2 other than policy
negotiating? We authenticate ISAKMP peer in phase 1 and it is where ID
payload plays its identification role. But once phase 1 is
successfully finished, it is only local policy that links IPSEC peer
with authenticated ISAKMP peer. Even the way that ID payloads are
included in phase 2 (there always must be two of them) doesn't look
like simple identification ("That is host A"), instead it implies
policy exchange semantic ("Host A wishes to communicate with host B").
Please, correct me if I'm missing something here.
> 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").
What will ID payloads in phase 2 mean in this case? And another
question - how peers will agree upon mutually acceptable policy? It
seemes that general ISAKMP approach (initiator sends a list of
proposals and responder must choose one of them or refuse all)
doesn't work in this case. It seemes that responder must be able to
return something different from initiator's proposal, something like
responder's proposal (its own policy or its intersection with
initiator's proposal). What should initiator do in case the returned
proposal is unacceptable for him? Or, more general, how should they
construct mutually acceptable policy? Just make an intersection?
> I think the whole phase 2 identity stuff needs some serious revisiting
> and alot more than just defining new types.
Agreed.
> Dan.
Regards, Valery Smyslov.
References: