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

[Alan DeKok <aland at deployingradius.com>]

Douglas Otis wrote:
> The goal is to minimize data held within a certificate such that it
> remains possible to hold several within a single packet.

  I can't find that goal in the charter text.  If it is a goal, it's
secondary to the goals stated in the charter.

>  When the
> number of certificates becomes burdensome, an exchange reduction could
> be accomplished by a "caching" NEA server producing a certificate that
> reflects the client's certificates currently held.  That seems overly
> complex for what is likely not a problem when certificates are kept to a
> minimum size.

  Why not have one solution that works everywhere, for all cases?

> The word service might cover any number of things related to securing
> the client.  OS, applications, as well as supplemental defenses-in-depth
> could be covered by the term service.

  A word that can take on any meaning ends up meaning nothing.

> What would you suggest that it be called?  How about Comprehensive
> Assessment and Remediation (CAR) service?

  How about using the terms from the charter?

>  It
> seems a bad idea to add more points of trust at administrative levels
> and pose the potential for catastrophic security breaches.  Leveraging
> existing trusted services would be much safer, more acceptable, and
> easier to administer.

  There are no trust issues in an NEA client accepting a certificate
from an NEA server.  That certificate says *nothing* to the client.
It's just a magic token that the client needs to use to obtain access in
a particular enterpise network.

  The certificate has meaning to the NEA server that issued it.  The NEA
server "trusts" the certificate... because it issued the certificate.

  As for clients not holding a valid certificate, a contractors NEA
client is perfectly free to *not* trust the NEA server for a particular
enterprise.  In that case, please explain why the NEA server would trust
the client, and let that client on it's network.

  The answer is "it won't".  Your whole worry about trust is misplaced,
and is causing you to come up with convoluted scenarios and solutions.
Allowing a client to obtain network access if it passes posture
assessment by third parties is ridiculous: they don't own the network.
The enterprise administrator running the NEA server owns the network,
and is the ONLY one who controls network access.

  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