Re: Fwd: NEA requirements (was Re: Fwd: [Nea] Re: use of a design team to develop requirements)

[Keith Moore <moore at cs.utk.edu>]

> > who says the NEA server has to make a (nontrivial) decision?
>
> who said the decision is trivial or non-trivial? I don't even know 
> what that means.

in my mind a trivial decision would be a situation where the client
software is responsible for determining whether the host conforms to the
profile for that network, it simply reports this to the NEA server, and
the NEA server then verifies that the profile is current and that the
NEA client is trustworthy.  that's why the signature, because the server
would want some way to establish trust in the NEA client before granting
access to the network.  but in this model, the server's decision-making
role is fairly "trivial" - if the signature checks out, believe whatever
the client is saying and give the client whatever level of network
access corresponds to that client and that profile.

by contrast, a non-trivial decision would be one where the NEA server
has to decide, based on several pieces of information provided by the
client (say, the results of some arbitrary number of tests), what level
of network access a client should have.

> > if the client presents a statement, signed by a key that is
> > traceable to a host and a product, that says that the host conforms
> > to a certain level of a profile, what more does the server need to
> > do other than to tell the network to give the host whatever level
> > of access corresponds to that profile?
>
> Ok, I am going to pass on the key signing for the moment. It's an 
> implementation issue and can be discussed later.

I don't think it's an implementation issue - it needs to be specified as
part of the protocol.

> Your general point, one where the client sends a statement that it
> conforms to a level of profile makes sense make sense but I have two
> questions.
>
> 1) How do you propose the handshake happen?

It seems a bit early to do protocol design but offhand I think it would
look something like this:

<some event triggers an NEA verification>
S: I'm server <servername>, acting on behalf of network <networkname>
and here are my credentials.
C: I'm client <clientname>, and here are my credentials.
S: current profile for you is <profilename, profileversion>.
C: For network <networkname>, I {do, don't} conform to profile <profile 
name, profile version>, signed <clientname>, and here are my credentials.
S: You are granted access level {full, reduced, remedial, none}.
C: thanks!

and that would be it.  Or maybe

<some event triggers an NEA verification>
S: I'm server <servername>, acting on behalf of network <networkname>
and here are my credentials.
C: I'm client <clientname>, and here are my credentials.
S: current profile for you is <profilename, profileversion>.
C: I don't have profile <profilename, profileversion>
S: <profilename, profileversion> consists of "bits..."
C: bye!

(with the assumption that the client then needs to take some time to 
evaluate that profile before attempting to connect again)

and just in case it's not obvious, the profile would contain a list of 
tests that needed to be carried out by the client.

> 2) What happens in the case where a NEA client doesn't send
> sufficient information to the NEA server for the NEA server to make a
> decision?

In this model, there's always sufficient information provided to the
server because most of the decision is made on the client, and the
client just reports the result of that evaluation to the server.  The
server just decides whether the client's decision-making and reporting
are trustworthy and gives the client the level of access that it's
configured to give based on the client identity and profile.

> > > That could be a query/response or it could be notification
> > > mechanism, though the latter is highly inflexible and severly
> > > limiting.
> >
> > yes, but that's the point - the limitations are highly desirable in
> >  reducing the threat of NEA to privacy, and they don't get in the
> > way of letting NEA do the job that it is designed to do.  they also
> > have the advantage of making NEA a fairly trivial protocol to
> > design and implement, allowing the standard to get to market much
> > more quickly.
>
> I was not referring to privacy limitations. Remember, I don't think 
> privacy is much of an issue.

Well, perhaps we simply disagree, or perhaps you just have in mind a
different model which deals with privacy threats in a different way.
But it's important to not assume that NEA will be used only by
people/networks who respect users' privacy.

> The limitations in a notification mechanism is that the communication
> is one-way with no chance for the two system to converge. The policy
> decision comes down to "Did the NEA client send me what I need to
> know?" and "Does that fit my policy?" If the exchange fails at
> question 1 and there is no recourse for the NEA server to query the
> NEA client for more information, then the exchange ends. That is
> inflexible and a non-starter.

Any protocol that allows the client and server to iterate with the
server demanding arbitrary information from the client is a huge privacy
risk and a non-starter for that reason.

Keith


_______________________________________________
Nea mailing list
Nea at ietf.org
https://www1.ietf.org/mailman/listinfo/nea