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

[Alan DeKok <aland at deployingradius.com>]

Mike Fratto wrote:

> Queries that ask the client to tell the authorization server about
> itself such as:
...

  If the clients are "managed" as you say, then the queries aren't
necessary, as I pointed out earlier.  If the clients aren't managed,
then I still think the queries aren't necessary.

> I think you are making the assumption that the only use of NEA is to
> allow *managed computers* (meaning computers under the direct control
> of the network owner)  to attach the network. That is one use case.

  Agreed, and I think it's the main use-case.

> The other use case is allowing unmanaged computers access to the
> network. Examples of unmanaged computers are temporary workers like
> contractors and consultants, sales people, and on-site support--people
> who are not employees, but need network access.

  Agreed.

  But... do they need unfettered access to the internals of the
enterprise network?  Why not just drop them into a quarantine zone, or
maybe filter/block most of their traffic?  This can be done today
without the use of NEA, so I'm not sure what value-add NEA has.

> Or you are making the assumtion that ALL computers owned or not-owned
> will run NEA clients, which is unwarranted.

  No, I've stated repeatedly on this list than machines not running NEA
are expected to connect to the network, and that there are methods for
dealing with those machines.

> OK, perhaps not explicity, but implicitly. PPP negotiations converge
> because the peers try to determine a common set of parameters that
> they want set and the attributes assigned to them. DHCP clients want
> to set/get specific attributes, etc.  The point is you can discover
> some interesting things about a network via PPP and DHCP.

  Discovery is not the same as query.

  The issue is one of trust and security.  For unmanaged machines,
neither client nor server trust each other.  As an NEA client, why would
you volunteer that you're running product X at version Y?  There might
be an exploit you don't know about, and the NEA server might just use
its knowledge of that exploit to attack you.

  The only "queries" I see as being useful from NEA server to client are
statements like "prove to me that product X is up to date".  The client
can supply a certificate (like Doug O suggests), that the server can
validate with the manufacturer of product X.  But in no way does this
mean that the certificate has to *publicly* state which version of
product X is installed.  There's simply no need for the NEA server to
know that information.

  In fact, the NEA server has little use for that information to make
any decision independent of the manufacturer of product X.  If the NEA
server gets told product X is at version Y, what does that mean?  Is it
a good thing?  Is that version vulnerable?  Is it newer than the version
the NEA server knows about?

  The only way to know is to ask the manufacturer, which means that
there's no reason for the NEA server to know detailed product
information about what's running on the client.

  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