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:
> Assume services might be offered by various third-parties.  There is a
> likelihood a service might work for one OS and not another.  By
> indicating the type of service and the suitable OS within each
> certificate, the user could then select a service that is both
> compatible and acceptable.

  Yes... each third party (virus scanner, etc.) would indicate the
scenarios under which it's validation of the clients posture is OK.  But
as I stated earlier, there's no need to exchange the full set of
certificates for every network access request.

> Who is producing the certificate?  Who is offering the service?  You do
> not want individuals to start trusting just any access point running
> NEA.

  The charter scenario targets the enterprise space, where NEA client
and server are in the same administrative domain (i.e. owned by the same
people).  In that case, trust is irrelevant, because there's only one
party involved: the enterprise that owns the equipment.  And the
enterprise administrators are the ones producing the certificates and
offering the services.

  For the case of someone visiting an enterprise with NEA, they can
choose to trust the NEA server and accept it's security policies.  Or,
they can choose to not trust it, and then not obtain network access.

>  Service providers should be the ones offering the certificates.

  The service provider space is explicitly outside of the WG charter.

  Maybe you mean "services offered by third parties", as above?
Overloading the word "service" here is impractical.  And your discussion
mixes "service" as third party software running on both the client and
server, *and* as the action of doing something to obtain updates.  As a
result, it's extremely difficult to understand what you're getting at.

> It seems impractical for an NEA server to assess thousands of details
> related to various services being contemplated.

  Then NEA as a whole is impractical.

>  Unless the certificate
> is something as simple as agreeing to an AUP, the NEA server is not
> really able to generate certificates directly.

  I fail to understand why.  If others can produce certificates, then
the NEA server can produce them, too.  If others can supply their
certificates (i.e. posture assessment) to the NEA server, then it can
produce a certificate saying that it believes the client is compliant at
a particular date.  And the only certificate that normally needs to be
presented to the NEA server is the one issued by the NEA server.

> The NEA server might know that service X has a critical update available
> at time Y.  The NEA server could then reject certificates that might
> make the client prone to a zero-day exploit.

  Which is a scenario I explicitly described, and which my proposal was
demonstrated to satisfy.  I don't think you're disagreeing with me, but
you don't seem to be addressing my proposal.

> The posture information would be in the form of a service completion
> classification.  This completion classification might be "Server-OS
> updated".  The information conveyed could be extremely general, and yet
> offer all that is needed when deciding acceptance.

  I have no idea what that means.  I haven't seem that terminology
explained, or used elsewhere, so it is difficult for to establish a
frame of reference.

  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