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

[Douglas Otis <dotis at mail-abuse.org>]

On Dec 21, 2006, at 11:22 PM, Alan DeKok wrote:

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

Sending posture data (describing the state of third-party software)  
seems unlikely to result in either standardization or minimized  
amounts of data.

1) The signing of the collected information should not occur at the  
client.
2) The signing of the collected information should not occur within  
the NEA architecture.

Consider how this task is best described, and used to both  
standardize and minimize the information being exchanged.

> > 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?

That was being suggested.  Allow an exchange by reference, and allow  
specific "Host" certificates (those signed with hostmaster@ for  
example) to be requested in order to determine the validity of the  
service and the related resource information based upon mutually  
trusted third-parties.  You seem to be suggesting that a component of  
the NEA will be creating and vouching for this information.  That  
would reduce the general level of security.

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

The charter does not fully describe this function and only refers to  
this as Posture information.  The reason for introducing this  
terminology is to suggest that NEA should not be the entity trusted  
to provide Posture information except perhaps in non-intrusive  
cases.  Stating that the environment is "Enterprise" does not justify  
getting sloppy about points of trust.

> > 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 enterprise network.

The certificate must be trusted by the client before acting upon the  
information contained.  This might involve firewall settings and  
where Posturing related services might be obtained, for example.  It  
would be a bad practice to assume that within an "Enterprise"  
environment, the NEA server _must_ be considered trustworthy.  When  
coming into an environment, what standards would allow guests to  
safely accept information and services being offered?  This trust is  
best established directly from organizations offering services that  
can _actually_ establish Posture information.  This would greatly  
improve the chances that employee X from company Y can accept NEA  
requests made by company Z.

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

That is not in question.

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

There would be CAR service providers mutually trusted by both the  
client and the NEA server.  In "guest hostile" environments, there  
might be requirements to accept services being offered or by the NEA  
server or else not gain acceptance.  This is very poor solution that  
will likely decrease network security by forcing trust in this manner.

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

The CAR related services, for the most part, already exist in various  
forms within various OS environments.  It is unlikely that thousands  
of organizations will wish to "reinvent" the detailed and complex  
efforts required to establish useful Posture information.  By looking  
to what already exists, introduction of NEA is less likely to  
introduce unacceptable trust requirements of perhaps questionably  
maintained NEA servers.

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

A mutually trusted service is not ridiculous.  Expecting various  
enterprises to create their own "CAR service wrapper" to produce  
posture certificates represents a poor choice with respect to  
security.  When NEA gets accepted, third-party CAR service providers  
will be willing to directly offer NEA compatible certificates.  This  
would improve the odds that a technician or sale rep would be able to  
utilize a network without introducing an array of questionable  
applications into their system.  A reasonable list of certificates  
recognized by NEA servers will accommodate a fairly large population  
without forcing someone to blindly trust some application.  In  
general, a requirement of blind trust is a bad idea, especially  
within an enterprise environment.  Imagine the precedent this would  
be setting.

-Doug






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