[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: use of client IDs
Bryan Gleeson wrote:
<trimmed...>
>
> I think the current draft is sufficiently ambiguous that it does not
> rule out either conclusion. There is definitely a need for a statement
> that "for a security gateway the use of the client ID is foobar", where
> foobar is either "mandatory" or "optional".
I think the draft is clear: specifying the ID of the client is a local
policy decision, and the meaning of a missing ID payload is implied.
<trimmed...>
> With the concept of client/proxy negotiation I think the ID payload
> is overloaded with the concept of policy.
<trimmed...>
Again, I don't see the issue here. The current policy model is
identity-based, and that requires some basis of identification. The ID
payload serves to provide this basis. How is this overloading the ID
payload? It is serving one, and only one purpose, which is to identify
the endpoint for which security services are being negotiated. Sometimes
that endpoint is the system doing the negotiating, and sometimes it is
not.
Regarding extending the ID payload to represent disjoint subnets, this
is a DOI issue which has been discussed offline. There are a few other
related items which were also discussed. As I said, I've been waiting
for the new agenda before presenting it to the list. I agree that there
are numerous remaining issues regarding policy, negotiation, etc. I'm
sure we'll be seeing the new agenda soon...
References: