RE: NEA requirements (was Re: [Nea] Re: use of a design teamto developrequirements)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: NEA requirements (was Re: [Nea] Re: use of a design teamto developrequirements)



I think the approach that Alan outlines is a pretty reasonable one. I
too see no reason for a query/response based protocol.  In fact a query
response based protocol is only likely to add needless complexity and
make the scheme susceptible to abuse.  

Based on the identity of the network, the machine will communicate the
state necessary to gain (or be denied) admission.  With appropriate key
management and federated trust mechanisms in place the information can
also be encrypted so only authorized networks can get / see the
information.  

Khaja

-----Original Message-----
From: Alan DeKok [mailto:aland at deployingradius.com] 
Sent: Monday, December 18, 2006 2:03 PM
To: Blumenthal, Uri
Cc: nea at ietf.org
Subject: Re: NEA requirements (was Re: [Nea] Re: use of a design teamto
developrequirements)

Blumenthal, Uri wrote:

> Perhaps NEA server will be able to mention everything it 
> wants in one request, and the client might be able to 
> pack all the data into one response. Or perhaps NEA
> client will just shove everything it can get about
> the system and send it in one bunch, without being
> specific - in response to a generic request.

  What I see is something along the following lines:

Client -> Server: I'm client FOO
Server -> Client: I'm network BAR
Client -> Server: Here's my posture information for BAR
...

> Perhaps based upon the first response to small and generic query, 
> the server will choose to send more specific queries to learn 
> about some particulars of the client machine.

  Again, I don't see a need for this.  Ever.

>>> The result on the user side might be to only allow
>>> the user to connect to a particular web site. 
>>> The point is that policy exists at both places.
>> Of course.
> 
> What's that "second place" where the policy exists?

  The client.  It can be configured to tell network A one thing, and
network B another.

  e.g. It tells my workplace that its virus scanner is up to date, but
doesn't tell my broadband provider that information.

> Do you mean a small set of generic posture attributes that 
> every host is supposed to carry? 
> Regardless, it doesn't seem to be the main focus of this WG. :-)

  It seems so.  I would like to start off knowing use-cases, scenarios,
and the intent of the administrator.  From that, we determine what
information is needed in order for the administrator to make an informed
decision.  We then determine how to design a protocol that carries that
information.

  i.e. *concrete* use-cases.  "Assessing posture" is a nice phrase, but
I don't know how it translates to real-world decisions.

  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


_______________________________________________
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.