Re: Fwd: NEA requirements (was Re: Fwd: [Nea] Re: use of a design team to develop requirements)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fwd: NEA requirements (was Re: Fwd: [Nea] Re: use of a design team to develop requirements)
Keith Moore wrote:
>> I would like to see use-cases to the contrary. If they exist, and are
>> important, then support for queries may be useful.
>
> I suppose that begs the question of how NEA clients learn the profiles
> that they need to evaluate.
I think it's "via the remediation network, which is outside of the
scope of NEA".
> Does the NEA protocol need to support, or
> is this somebody else's problem? What if the client connects and finds
> that its profile is out-of-date, should NEA allow the client to download
> the current profile?
The server should decide if the clients profile is out of date. The
alternative is the client system saying "Yeah, I'm fine... honest...",
which is pretty much what we have today.
> And how different is that (from a security/privacy
> point-of-view) than a query?
Not much, but if the system doesn't have a process for policy updates,
it isn't that useful.
My take is that policy updates will happen much less often than
connection requests. So if nothing else, it's more efficient to not
have queries at every connection attempt. Since the queries and/or
policy updates may be large, it would be better to leverage real
networks for that process, rather than trying to carry large amounts of
data in the NEA protocol itself.
I'll try to write up an I-D that summarises the discussion so far. It
may be mid January before it's out, though.
Alan DeKok.
--
http://deployingradius.com - The web site of the book
http://deployingradius.com/blog/ - The blog
_______________________________________________
Nea mailing list
Nea at ietf.org
https://www1.ietf.org/mailman/listinfo/nea
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.