Subject: [Nea] Draft minutes from IETF 67 NEA WG meeting

From: "Stephen Hanna" <[email-masked]>
Date: Fri, 8 Dec 2006 17:34:33 -0500

Here are the draft minutes from the IETF 67 NEA WG meeting.
If you have comments or corrections, please send them to me
or to the NEA list ASAP.

Thanks,

Steve

----------

Minutes from NEA WG Meeting
IETF 67 in San Diego, CA
November 7, 2006, 3:20 PM - 5:20 PM
Chaired by Steve Hanna and Susan Thomson
Notes taken by Kaushik Narayanan, Mauricio Sanchez, and Paul Sangster

These notes do not attempt to duplicate all the material in the
slides. Instead, they provide a brief summary of that material and
focus on comments and discussion (especially consensus checks).

Steve Hanna welcomed people to the first meeting of the Network
Endpoint Assessment Working Group. He reviewed logistical information
about the group (email list, chairs, etc.). Blue sheets were
distributed and minutes scribes found. No Jabber scribes were found.
The following draft agenda was agreed to:

3:20 Circulate Blue Sheets, Identify Jabber & Minutes Scribes
3:25 Agenda Bashing
3:30 NEA Milestones
3:40 Discussion of Requirements I-D
5:10 Next Steps
5:20 Adjourn

*NEA Milestones*

Susan Thomson reviewed the milestones in the NEA charter. The current
milestones are aimed at getting a NEA Requirements document submitted
to the IESG by April 2007. Then we'll request AD approval to add
milestones to standardize PA and PB.

Susan Thomson reviewed roles and responsibilities within the NEA WG.
A NEA Requirements design team will be formed to develop an initial
draft of the NEA Requirements I-D and revise that I-D in response to
WG rough consensus. Volunteers for the design team should contact
Steve and Susan. A request for volunteers will be sent to the NEA
list and we hope to have the design team launched within a couple of
weeks.

The goal for today is to discuss what the requirements I-D should
contain and what use cases that requirements I-D should support.
And we'll solicit volunteers for the design team.

*Discussion of Requirements I-D*

Susan reviewed a draft outline for the Requirements I-D (included in
the slides) and asked if there are any obvious missing areas. There
were no responses.

Susan reviewed some basic terminology: endpoint and posture. An
endpoint is any device that can be connected to a network and get
an IP address. Posture is security-relevant configuration of an
endpoint.

Kaushik Narayanan: Isn't it true that posture can be a wide variety of
information as long as it's used in a security policy? That makes it
security relevant.
Susan: Yes.

Susan summarized the NEA problem statement: to assess the posture of
an endpoint and determine whether it's in compliance with a security
policy. Susan reviewed items that our charter says are in scope and
others that are out of scope but must be accommodated.

Susan presented the NEA Reference Model as described in the previously
published problem statement. She suggested a refinement to the model
to change the bottom layer to only perform posture transport since the
PT protocol may be separate from that used in access
control/enforcement.
She asked if there are any comments or questions on this change. There
were none.

Steve Hanna took the mike to discuss use cases. The goal here is not
to identify all possible use cases for NEA. It is to identify a
minimal set of use cases that can be included in the Requirements I-D
and that spans the problem space. We don't need to have a lot of
information here, just enough to drive requirements definition.

Paul Ferguson: How can we discuss requirements before defining the
problem space?

Steve: The problem space is described in the charter and will be
described in more detail in the Requirements I-D.

Steve listed several types of flows:

 - Initial assessment - triggered by network connection or service
request
 - Re-assessment - triggered by NEA server or client (because of an
   event, timer, etc.)

Steve listed and described several types of attributes:

 - Endpoint Data (client to server), by value or by reference
 - Compliance Policy (server to client)
 - Compliance Policy Evaluation Results (client to server)
 - Cryptographic Protocols (multiple round trips)
 - Compliance Result (server to client)
 - Remediation Instructions (server to client)

Eric Rescorla: Is cryptographic protocol information considered an
attribute? It's not helpful to have it defined as an attribute.

Yaron Sheffer: I thought compliance policy was out of scope. How can
you be including it in an attribute then?
Steve: I'm not suggesting that attribute should be standardized.
I'm just saying that's one attribute that can be sent. In fact,
our charter states that the set of attributes to be standardized
will be minimal. I don't expect policy would be in that set.

Mani Mahalingam: Are enforcement points out of scope?
Steve: Yes, our charter says so. Enforcement is out of scope. Other
IETF WGs do enforcement protocols.

Kaushik: Could completion of remediation be a trigger for reassessment?
Steve: Yes, that would fall under the category of client triggered
reassessment.

Steve: I'll present a set of use cases that seem to span the problem 
space as I understand it, driving all necessary requirements. See
slides for details of those use cases. Brief summary here:

John Smith - inventory collection of software on JS's endpoint at
network join
             No enforcement.
Jane Doe -   send patch levels upon service request, upgrade advisory
sent
             No enforcement.
Colonel Mustard - constant monitoring while on network. Endpoint detects
a 
             posture change so triggers re-assessment. Access is
             limited since the system isn't in compliance.
             Re-assessment occurs after remediation which allows
             access to be restored.

Steve: Are there other use cases that must be addressed and which
drive new PA, PB, or PT requirements?

Bob Morgan: If the first use case is triggered by network connection,
you should show the network access elements. And this would drive PT
requirements since the endpoint may not have full network connectivity.

Doug Otis: Most assessments involve a separate assessment server.
Maybe that server should sign some credentials saying that the
assessment has been completed. Then the NEA server can just look at
those credentials.

Steve: Does that drive any new requirements?

Doug: Lots of trust issues are raised. The client needs to decide
whether it trusts the remediation instructions.

Steve: So that relates to the contents of the remediation instructions.

Alan DeKok: I'm concerned about the defined architecture being overly
limited as I can imagine other architectures for solving this problem.
We could have remediation happen inside EAP-TLS, for instance.

Steve: Using EAP to transport a lot of information such as remediation
doesn't work well. EAP is not well suited for bulk data transfer and
most wireless APs will time out after 25-200 round trips.

However the point remains that there are other architectures for
endpoint
assessment. We need to stay within our charter, which talks about NEA
Servers
and NEA Clients. So there are some limitations to what's in scope.

Khaja Ahmed: I wonder if a P2P use case would be helpful. And what
about non-enterprise scenarios where an ISP checks the consumer system
for them?
Steve: I think that may violate an applicability limitation in our
charter.

Khaja: Am I right that PA might involve multiple round trips?
Steve: Yes. There are use cases where that's required.
Khaja: That could cause lots of latency due to many collectors causing
lots of round trips. There must be a better way.

Khaja: Compliance policy attributes (where the server tells the client
what the policy is) doesn't sound like a good model.

Steve: Any other comments? About any of this? None. So we'll take it
to the list.

Steve: I'm surprised at how quickly this has gone. We've come to the
end of the slides that Susan and I had prepared. Fortunately, Paul
Sangster has a presentation on the requirements I-D that was prepared
last spring when we were a NEA BOF. Of course, these are somewhat
dated and don't reflect the discussions around our chartering. But
it's probably useful to discuss them, given that we have the time.

Kapil Sood: We need a set of security requirements not just the
functional requirements discussed so far.
Steve: Yes, absolutely. We're going to have to do a complete security
analysis of the entire system. We can derive security requirements
from that.

*Review of Previous Requirements I-D*

Paul Sangster presented an overview of the old NEA BOF requirements I-D:
draft-khosravi-nea-requirements-01.txt. See Paul's slides for details.

Paul reviewed the outline and contributors for the spec. Then he
described terminology: component, message, session, and dialog.

Next, he summarized Common Requirements (common to PA, PB, and PT).

1. Capable of multi-message dialog

Khaja: This shouldn't be a requirement. Requirements should be higher
level, as they might be articulated by an IT administrator. This is
more design. And I don't think this is a good idea.

After further discussion, it was agreed that this should be discussed
more later.

2. Allow server requests prior and after network access
3. Possible for client to initiate a posture re-evaluation request
4. Protection against active/passive attacks by intermediaries
5. PA and PB transport agnostic interfaces
6. Selection process prefer reuse of existing open standards
7. Scalable (many collectors and validators on multiple servers)

Kaushik Narayanan: Requirements currently specify horizontal protocols
between NEA client and NEA server, how about the vertical protocols on
the client or server side?
Paul: Vertical protocols are currently out-of-scope in the charter.

Then Paul reviewed PA requirements:

1. Transport core attributes (vendor, version, operational status, ...)
2. Transport of vendor defined attributes
3. Validator request of particular client component's posture
4. Allow for multiple requests for posture information
5. Carry validator results and remediation instructions
6. Selection process prefer re-use of existing open standards for
   transport and attribute representation

Bob Morgan: Whenever you get into schema (attribute formats, etc.),
lots of issues come up. The client and server may need to agree on
which attributes are supported by each.

Doug Otis: We don't need any vendor-unique attributes if instead the
server just asks for certificates proving the client has passed
certain compliance checks. Vendor-specific attributes will cause lots
of compatibility problems.
Paul: Well, it would be nice to avoid those problems. Let's discuss
your idea more.

7. SHOULD support expression of prior remediation state (e.g. time,
   server used.) 
8. Capable of authentication, integrity and confidentiality of
   attributes, results and remediation instructions 

Yaron Sheffer: Those properties can be provided by PB or PT.
Paul: Actually, this requirement is specifically on PA. There are some
use cases that drive that requirement. For instance, a validator that
wants to know the collector is valid. Or a validatror and collector
that want to keep their messages confidential from other components in
the system (like the Posture Broker). We may not want to address
those use cases but we should consider them.

Yaron: PA should define the core attributes not just transport them.
Steve: This requirements I-D is old and pre-dates IETF 66 where the
group did agree to define the attributes. That's in our charter now
and it will be done.

Dave Nelson: When you say authentication of attributes, you really
mean authentication of the component that sent the attributes, right?
Paul: Right. The collector or validator.

Khaja: Does this mean all collectors and validators must be able to
protect their messages?
Paul: No. This means that the protocol must support such protection.
But the collector doesn't have to implement that feature.

9. SHOULD optimize transport of messages and minimize PB RTs

PB Requirements

1. Capable of carrying the decision and (if present) remediation
instructions
2. Carry naming for collectors and validators (used for message
delivery)
   Naming should allow for dynamic registration
3. Multiplex message dialogs between multiple collectors and validators
4. Capable of authentication, integrity and confidentiality of
   messages, decision and remediation instructions 
5. SHOULD support grouping of attributes to optimize messages/RTs

Kaushik Narayanan: The requirements I-D being presented just seems to
cover use cases with raw attributes. It does not capture requirements
for where rules are being transferred.
Paul: Yes. We need to include those requirements as part of the design
process.

PT Requirements
1. SHOULD incur low overhead for low bandwidth links

Kaushik: The low overhead requirement for PT has a cascading
requirement on PA and PB protocol requirements.
Paul: Yes. There are PA and PB efficiency requirements also.
Kaushik: And data needs to be compact.

2. SHOULD be capable of using a half duplex link
3. MUST NOT interpret the contents of PB messages
4. Capable of protecting the integrity and confidentiality of the PB
   messages

Yaron: Will PT requirements cover everything all the way down to the
IP layer?
Paul: No, we'll primarily capture the requirements of the transport
and not all layers below the PT.
Yaron: The Requirements I-D talks about EAP as the transport.
Steve: That's an historical artifact.

Kapil: The requirement for PT to protect PB messages and the
requirement for PT not to interpret PB messages seem to be in
conflict. If PT protects PB messages, we can't keep it from
interpreting them. And how would you test compliance with those
requirements, anyway?
Paul: These are requirements on the PT protocol. We wouldn't pick a PT
that requires poking around in PB messages.

5. Reliable delivery of PB messages (detect dups, fragmentation)
6. Capable of mutual authentication (possibly leveraging an
   authentication inside the protected tunnel)
7. Establish a restricted session between NAR and NAA prior to
   allowing general access
8. Allow for NAR/NAA session to be initiated from either party when
   both have assigned network addresses

Steve discussed next steps:

1) Solicit Design Team Members (through Nov. 16)
2) Start Design Team Weekly Concalls (probably week of Nov. 27)
3) First Requirements I-D Posted

Meeting adjourned at 5:17pm

_______________________________________________
Nea mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nea

---

From: Keith Moore <[email-masked]>
Date: Fri, 08 Dec 2006 17:56:34 -0500

Stephen & Susan,

I really have to question the use of a design team to develop 
requirements for the NEA WG.  A lot of the strength of the IETF process 
has traditionally been from its inclusiveness.  Experience suggests that 
this is most beneficial in two areas - one is determining requirements 
and design considerations (the more people who have input into these, 
the more chances there are to spot important considerations that might 
otherwise have been overlooked) and another is in reviewing documents 
(the more reviewers, the greater the chance that a flaw in the document 
is discovered).

It's generally a good thing to have a small team to be selected as 
editors of a document, but IMHO, not so good to make that team 
responsible for actually determining requirements.  If that is really 
the intent, I think this will tend to impair the ability of the WG to 
produce a sound set of requirements, particularly when there are a 
number of dubious assumptions already included in the WG's charter.

Particularly given that the list has essentially been silent since the 
design team was announced, and also given that the design team was 
formed before much discussion had taken place here, it's hard to escape 
the impression that the parameters of the solution are being dictated 
rather than determined by WG consensus, and before the problem is even 
well understood.  I do not believe it is sufficient to have a design 
team develop requirements in isolation and then to have the WG ratify them.

Keith

---

From: Khaja Ahmed <[email-masked]>
Date: Fri, 8 Dec 2006 17:49:10 -0800

I agree with Keith.  It is probably fine to have a 'design team' in the
sense of a designated set of people who have committed to contribute to
the development of requirements.  However I would prefer to see the
actual work and related discussion conducted on the list.

Khaja

-----Original Message-----
From: Keith Moore [mailto:[email-masked]] 
Sent: Friday, December 08, 2006 2:57 PM
To: Stephen Hanna; Susan Thompson
Cc: Sam Hartman; [email-masked]
Subject: [Nea] use of a design team to develop requirements

Stephen & Susan,

team develop requirements in isolation and then to have the WG ratify
them.

Keith

---

From: "Stephen Hanna" <[email-masked]>
Date: Sat, 9 Dec 2006 06:38:14 -0500

A better time for this discussion would have been at the NEA WG
meeting or during the month since then. I sent email to the NEA
list on November 8 explaining that a requirements design team
was being formed and an email to the SAAG list on November 9
reiterating this. Several more follow-up emails to the NEA list
were sent over the next few weeks. The design team is well under
way now. But I suppose it's never too late for an objection.

Certainly, the intent of using a design team is not to exclude
mailing list discussions and participation. It's to prepare a
reasonable starting proposal for discussions. This is not an
unusual process in the IETF. Working groups often create a
design team to solve a problem or create a first draft of
a specification. In fact, many specs are initially drafted
by one person and then revised in response to discussions
on the mailing list. As long as the initial draft from the
design team is regarded as only an initial proposal subject
to revision or rejection by the working group, this is a
perfectly acceptable process. In fact, RFC 2418 describes
this process explicitly and positively in section 6.5.

We have asked the design team to deliver the first draft
of the requirements document in early January. That's a
very short timeline and there are a lot of holidays there.
If we abandon the design team process and instead hold an
unstructured discussion of requirements on the mailing list
during this holiday period, I'm concerned that it will not
be a productive discussion. I'm especially concerned that
many working group participants will be absent during this
period and one or two people will end up dominating the
discussion. I have already seen tendencies in this direction
in recent NEA WG discussions.

I suggest that we allow the design team to finish their work
on the first draft of the requirements document and deliver
it to us in early January. Then we can have a free-ranging
discussion about the document, any assumptions implicit in
the document, what should be done instead, etc. We'll have
all hands on deck during January and can have a much more
productive and inclusive discussion then.

Thanks,

Steve

-----Original Message-----
From: Khaja Ahmed [mailto:[email-masked]] 
Sent: Friday, December 08, 2006 8:49 PM
To: Keith Moore; Stephen Hanna; Susan Thompson
Cc: Sam Hartman; [email-masked]
Subject: RE: [Nea] use of a design team to develop requirements

Khaja

-----Original Message-----
From: Keith Moore [mailto:[email-masked]] 
Sent: Friday, December 08, 2006 2:57 PM
To: Stephen Hanna; Susan Thompson
Cc: Sam Hartman; [email-masked]
Subject: [Nea] use of a design team to develop requirements

Stephen & Susan,

Keith

---

From: Sam Hartman <[email-masked]>
Date: Tue, 12 Dec 2006 09:27:01 -0500

>>>>> "Keith" == Keith Moore <[email-masked]> writes:

    Keith> Stephen & Susan, I really have to question the use of a
    Keith> design team to develop requirements for the NEA WG.  A lot
    Keith> of the strength of the IETF process has traditionally been
    Keith> from its inclusiveness.  Experience suggests that this is
    Keith> most beneficial in two areas - one is determining
    Keith> requirements and design considerations (the more people who
    Keith> have input into these, the more chances there are to spot
    Keith> important considerations that might otherwise have been
    Keith> overlooked) and another is in reviewing documents (the more
    Keith> reviewers, the greater the chance that a flaw in the
    Keith> document is discovered).

Keith, speaking only to the correctness of process: it is absolutely
clear to me that a WG can choose to use a design team to solve any
problem before them.  However, for sponsored design teams, it's also
clear to me that decision is subject to WG consensus like all other WG
decisinos.  Discussing the formation of the team at the meeting and
then on the list seems to meet the requirement of confirming WG
consensus for that decision.

Obviously, ad-hoc design teams formed by participants and not given
support by the chair can be formed for any problem without the
approval of the WG.  That too is a critical part of the IETF process.

Again, I'm speaking to process issues, not to whether it is right to
form a design team in this case.  Also, as you well know, this is
Russ's group not mine; my opinion here holds no more weight than your
own.

---

From: Keith Moore <[email-masked]>
Date: Tue, 12 Dec 2006 10:40:13 -0500

-------- Original Message --------

> problem before them. 

strictly speaking, it may be allowed by our process, though I think of 
this as an omission or ambiguity in our process documents.  I don't 
think our process was intended to allow handpicked design teams to 
develop requirements.

I also think that is is contrary to good engineering practice and common 
sense to try to define requirements of a solution before the problem 
itself is well understood.  the chairs and the design team may believe 
that they understand the problem well, but they haven't bothered to get 
much input from the larger group before starting to draft requirements.

Keith

---

From: Alan DeKok <[email-masked]>
Date: Tue, 12 Dec 2006 11:40:12 -0800

> much input from the larger group before starting to draft requirements.

  Then let's discuss the requirements here.

  Personally, I think that there are many kinds of endpoint assessment
that can be done simply by leveraging information in existing protocols.
 e.g. MAC address filtering in DHCP, to allow only known hosts onto the
network.  None of those steps to a full-blown NEA are perfect, but NEA
won't be perfect, either.

  I would like to see the requirements stated as a series of stages,
from "anyone is allowed on the network with no checks", to "you must
submit to invasive probes", with a graduated range of assessments in
between.

  The main problem I see with that approach is the extremes are easy to
document, but the grey area in the middle is difficult to quantify.
Maybe even before requirements, we should discuss what information
exists where, and who is willing to exchange what information.

  Alan DeKok.
--
  http://deployingradius.com       - The web site of the book
  http://deployingradius.com/blog/ - The blog

---

From: "Mike Fratto" <[email-masked]>
Date: Wed, 13 Dec 2006 12:50:41 -0500

> submit to invasive probes", with a graduated range of assessments in

Alan, this needs to be generalized to something like "products must
have configurable actions based on posture assessment" but this is a
policy or action statement that will be defined by oranganizations and
is beyond the scope of the working group. It's important and perhaps
an informational RFC on best practices would be a good spot for those
types of discussions.

At this point, it looks like the requirements are focusing on features
that should be in PA and PB.

For example, I think it is critical:

1) that a set of basic attributes such as MAC, IP, and NEA client
time, be defined that MUST be exchanged between a NEA client and NEA
server

2) that the NEA attributes sent to the NEA server from the NEA client
be secured in such a way that only the NEA server can open and view
them

3) that prior to attribute exchange there is a mechanism in place
where the NEA server requests attributes and the NEA client makes a
choice according to it's local policy whether to send those attributes
or not.  Perhaps a negotiation MUST take place even if that means the
server policy dictates all attributes must be returned. (default NAK).
I am thinking of something similar to PPP.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 13 Dec 2006 10:24:52 -0800

Mike Fratto wrote:

> have configurable actions based on posture assessment"

  That statement is already assuming a host of requirements and
functionality.  My intent was to describe the *administrators*
requirements for controlling network access, independent of the
capabilities of the end hosts.  Once those requirements are quantified,
we can then move on to describing the requirements that the end hosts
have to meet in order to satisfy the larger objectives.

  According to the charter, this is part of what the requirements
document is supposed to cover.  Since there were concerns raised about
the openness of the process, I would like to see a public discussion here.

  If there is no public discussion about the requirements, then the WG
members are saying they have no opinion about the requirements, and that
 we should just rubber-stamp whatever document is produced by the
requirements team.

> time, be defined that MUST be exchanged between a NEA client and NEA

  To what end?  I'm not being facetious here.  The charter indicates
that the requirements document should include a problem statement.  We
should discuss that before talking about attributes and solutions.

  My $0.02 for a problem statement is that administrators want to know:

1) who is on their network (users/machines)
2) that those users/machines engage in behavior that is mutually agreed
to by the users and network administrators.

  The invasive "scan your machine" system that Keith is rightly worried
about is a poor proxy for statement (2).  i.e. It's hard to put content
scanners everywhere in the network, to prevent bad behavior, so the next
best thing is to ensure that all the machines have patchlevel X, because
we know it's not vulnerable to an attack which as a side effect produces
bad behavior.

  To put it another way, it doesn't matter much if a machine is
vulnerable to an attack, so long as that attack is never executed.

  Many of the claimed NEA benefits about controlling network access can
be achieved by leveraging information that's already in the network, but
which isn't being looked at or used.  Many more of the NEA benefits
about protecting the network can be achieved by running IDS machines, or
by traffic filtering on the switch/router.  And other NEA benefits about
controlling the remote machine can be obtained by running the vulnerable
OS's in a VMware image, on a host OS that is much less vulnerable.

  Alan DeKok.

---

From: "Mike Fratto" <[email-masked]>
Date: Wed, 13 Dec 2006 14:39:58 -0500

> capabilities of the end hosts.

Ok, I am not going to act as charter police, but what you are
describing is a matter local policy and a matter of deployed
infrastructure regarding both assessment and enforcement. Maybe I am
wrong about that, but I don't think so. ha-ha  :)

> to by the users and network administrators.

I think your problem statement is too specific and really is kind of
obvious. Organizations are assessing, piloting, and deploying network
access control solutions today and in the next year or so. That is
happening regardless of what happens in this, or any, group. But I
think the problem statement that NAC address (from talking to those
very same organizations) more generally comes down to the following:

Network owners want to control access to network resources based on a
one or more factors such as (this is NOT an exhaustive list), MAC
address, IP address, location, time of day, host configuration,
assessment of installed applicaitons, assessment of running
applications, determination of whether the host is known or unknown,
and operating system patch levels and network owners want
interoperable products that will grant host assessment, remeidation,
and enforcement. In short, network owners want the tools that will
allow them to enforce a policy they deem appropriate for thier
network. That is the problem NAC attempts to solve (for better or
worse, that is also debateable)

Making the resonable asusmption that NAC is being deployed, the
problem with the NAC market today is that there are three competing
frameworks, Cisco Network Admission Contron, Microsoft Network Access
Protection, and the Trusted Computing Group Trusted Network Connect.
Cisco and Microsoft have announced interoperabilty plans, but neither
interperate with TNC. That means there is a very real possibility that
the market will continue to be fractured and that means interoperation
will be  impossible and that hurts organizations deploying NAC. If
your chosen products don't conform with a specific framework, then
you're SoL. For example, if a host attempts to access the network, but
their host software can't be assessed because it does not interoperate
with the assessment tool, that is a problem. That is a very differnet
problem than a host denying an assessment transmitted through an
agreed upon protocol.

So the problem really comes down to getting the different frameworks
to interoperate and also to allow other products to interoperate
regarding host assessment. That leads me back to my short bullet list
which addresses what the protocols should support.

mike

---

From: Keith Moore <[email-masked]>
Date: Wed, 13 Dec 2006 15:46:43 -0500

> is beyond the scope of the working group.

I don't know that I agree with the "series of stages" argument, but the
topic is certainly  NOT beyond the scope of the WG - because NEA has
privacy implications for hosts and such implications could affect the
ability of NEA to meet IETF criteria for Proposed Standard status. 
 
Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 13 Dec 2006 15:51:59 -0500

> wrong about that, but I don't think so. ha-ha  :)

Why in the world should IETF standardize a protocol that enables
networks to impose whatever policies they wish on hosts, given that we
already understand how this could be harmful to the Internet and
counter to IETF's organizational goals?

> access control solutions today and in the next year or so. 

Perhaps, but that doesn't justify IETF's endorsement of such practices.

> which addresses what the protocols should support.

Interoperability is not always a good thing.  Making it easier for
networks to impose draconinan and intrustive policies on hosts that
they do not own is not consistent with IETF goals.  NEA either needs to
be fixed so that it balances risk between host, user, and network, or
it needs to be taken out of IETF.

Keith

---

From: Alan DeKok <[email-masked]>
Date: Wed, 13 Dec 2006 14:33:40 -0800

Mike Fratto wrote:

> infrastructure regarding both assessment and enforcement.

  If all requirements are a matter of local policy, then this WG will
never develop a standard.

> obvious.

  It still needs saying.  Much of the NEA architecture and requirements
are obvious to many, but perhaps not to all.  That's why we have working
groups and public discussions: to publicly ensure we have consensus.

> one or more factors such as ...

  Many versions of this have been deployed already, some for decades.  I
believe we need to spend *some* time enumerating what's deployed and
what works, before we go design complex systems systems.  If we don't,
then there's a good chance we will re-invent what already exists.

> Protection, and the Trusted Computing Group Trusted Network Connect.

  How does the TNC overlap with NEA?  The chair of NEA is also the chair
of TNC, but I haven't seen any statement about that topic.

> will be  impossible and that hurts organizations deploying NAC.

  Interoperation of... what, exactly?  Again, discussion of the
requirements and architecture is on topic for this list.  You're
skipping over that entirely, and assuming certain technologies.

  Alan DeKok.

---

From: "Mike Fratto" <[email-masked]>
Date: Wed, 13 Dec 2006 17:42:20 -0500

> counter to IETF's organizational goals?

I think I can safely say that the purpose of NAC is NOT to impose
anything on a host. The purpose of NAC is to allow a network owner to
control access to it's resources, which is well within the network
owner's right. Nothing more and nothing less. If a host is not upto
snuff and the network owner requires certain actions to take place,
the host can *choose* not to participate in the network. There is no
forcing anything. There is no other social, racial, national, or
political agenda. And no, I don't agree with your claim that NAC is
harmful to anyone

I can't speak for the IETF at large, but off the top of my noggin here
are some other examples of potentially draconian standards,

1) RADIUS is an IETF standard that past muster and is used to control
user access. RADIUS imposes the rule that if you can't authenticate,
you don't get access. If a user can't authenticate to a RADIUS server
for any reason, including not supporting any required authentication
mechanisms, then they are denied access. Heck, if you do authenticate
and are part of a group, the network can segment you.

2) PKIX is a whole suite of standards. It too can be used to grant or
deny access to a number of resource via the presence or absense of
attributes or heck, knowledge, or lack of knowlege, of the signing
certificate.

3) PPP.  Is that also the tool of oppression? Ya know, if a host
doesn't accept an offered IP address or other configuration option,
they don't attach the network. To think a network owner might want to
enforce that!

4) IKE V1 maybe the worst offender of all. If the peers don't find
agreement on proposals in the first round of offers, communications
stops. Period. There is no negotiation.

By your reasoning, none of them should have been in the IETF either.

---

From: Keith Moore <[email-masked]>
Date: Wed, 13 Dec 2006 18:07:19 -0500

> are obvious to many, but perhaps not to all. 

...and some of what is "obvious to many" may actually be wrong or 
misdirected.  There's a big difference between developing a product and 
developing an Internet standard.  One important difference is that 
Internet standards have to function at Internet scale - i.e. what would 
happen if everyone on the Internet used this however they wanted? 
That's why a handpicked panel of "experts" isn't fit to develop 
requirements in isolation - there are no "experts" at doing this on an 
Internet scale.  It needs to be rethought from first principles.

Keith

---

From: "Mike Fratto" <[email-masked]>
Date: Wed, 13 Dec 2006 18:14:13 -0500

> never develop a standard.

Nah, local policies are the "WHY". Protocols are the "HOW." It is the
how that matters, IMHO, to working groups.

> of TNC, but I haven't seen any statement about that topic.

To see how the the *functions* of PA, PB, and PT, as defined in the
charter are also defined by these other frameworks are related to the
work proposed by the NEA, read:

http://www.microsoft.com/technet/network/nap/default.mspx
http://www.cisco.com/en/US/netsol/ns466/networking_solutions_package.html
https://www.trustedcomputinggroup.org/groups/network/

If you can't see how the functional aspects of PA, PB, and PT are
related to TNC, CNAC and NAP, let me know and I will lay it out for
you.

> skipping over that entirely, and assuming certain technologies.

No, I am not. Stop being argumentative.

---

From: Keith Moore <[email-masked]>
Date: Wed, 13 Dec 2006 18:22:42 -0500

> anything on a host.

It's not the explicit purpose, but it is certainly a consequence of NEA 
if it is successful.  If you know something is going to do harm, and you 
do it anyway, you're still culpable for the harm even if doing harm 
wasn't your explicit purpose.

> The purpose of NAC is to allow a network owner to control access to 
> it's resources, which is well within the network owner's right. 
> Nothing more and nothing less.

Well, let's look at an analogy.  Let's say that you work for me, and I
want to establish whether you're trustworthy.  So I require you to
consent to have your house searched, at any time, for evidence of
anything that you might have or do that would cause me to question my
trust in you.  Would that be well within my rights as an employer?  And
if it's not okay for me to search your house, why is it okay for me to
search your laptop?

The real question is something like this - how invasive a search is
reasonable?

> If a host is not upto snuff and the network owner requires certain
> actions to take place, the host can *choose* not to participate in
> the network. There is no forcing anything. There is no other social,
> racial, national, or political agenda. And no, I don't agree with
> your claim that NAC is harmful to anyone

I strongly disagree.  Saying that a host can choose whether to use a 
particular network is like saying that a person can choose whether or 
not to breathe the local air, drink the local water, buy electricity 
from the local power company.  In many cases you have to use a 
particular network in order to function.  So the choice is to a large 
degree already taken away from the user.  When the user doesn't have 
choice other mechanisms are needed to protect the user's privacy.

> 
> I can't speak for the IETF at large, but off the top of my noggin 
> here are some other examples of potentially draconian standards,
> 

(RADIUS, PKIX, PPP, IKE)

None of these requires arbitrary information from a host - only a small 
amount of information that specifically exists for the purpose of 
authentication.  And if you can reduce NEA to a protocol that just gives 
a host a way to say to a network "XYZ virus scanner certifies that this 
host is good up to version X.Y of its virus tests" then I wouldn't have 
a problem with it.  The problems come from the potential that NEA can be 
used by a network to ask arbitrary questions of a host.  Standardizing 
spyware is not in the best interest of the Internet community.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 13 Dec 2006 18:25:15 -0500

-------- Original Message --------

> how that matters, IMHO, to working groups.

WGs are certainly concerned with how, but they're also concerned with 
security implications of their protocols.  It's irresponsible to design 
something that can have harmful consequences without considering those 
consequences and how to reduce their harmful effects.

> https://www.trustedcomputinggroup.org/groups/network/

Seems like way too much prior work is being assumed to be relevant by 
certain members of this group.  Protocols that weren't designed to work 
at Internet scale tend to be hard to adapt to Internet scale.

Keith

---

From: Khaja Ahmed <[email-masked]>
Date: Wed, 13 Dec 2006 15:59:52 -0800

-----Original Message-----
From: Keith Moore [mailto:[email-masked]] 
Sent: Wednesday, December 13, 2006 3:25 PM
To: Mike Fratto
Cc: [email-masked]
Subject: Re: Fwd: [Nea] Re: use of a design team to develop requirements

-------- Original Message --------

> http://www.microsoft.com/technet/network/nap/default.mspx
http://www.cisco.com/en/US/netsol/ns466/networking_solutions_package.htm
l

[Khaja] it is not the goals of this WG to produce and protocol that
scales to the internet. This is meant to be an enterprise only solution.
When I raised this question previously the chairs ruled, and the ADs
have concurred, that internet wide behavior (implying ISP participation)
is out of scope.  Enterprise behavior is the only thing we can consider.

[Khaja] Question to chairs: Given that we cannot discuss requirements
that pertain to internet wide usage, can we still discuss potential
impact of such a protocol if it were to be used in place it is not
designed for? ...i.e. the internet.  

Keith

---

From: Alan DeKok <[email-masked]>
Date: Wed, 13 Dec 2006 16:08:33 -0800

> if it's not okay for me to search your house, why is it okay for me to

  As noted earlier on this list, both kinds of searches may be illegal
in certain jurisdictions.  Complying with all legal requirements may, in
fact be impossible for NEA.

>... And if you can reduce NEA to a protocol that just gives
> a problem with it.

  And that's probably not too hard to do, or to retrofit on existing
protocols.  On the other hand, allowing open-ended queries means that
the queries will probably be turing complete.  That leaves a wonderful
attack vector:  Visit a cafe, and have them run arbitrary code on your
machine.

  If the turing complete queries are NOT what is intended, it would be
nice to know that, and to have clear statements about what capabilities
the queries have.

  Alan DeKok.

---

From: Keith Moore <[email-masked]>
Date: Wed, 13 Dec 2006 19:15:04 -0500

> is out of scope.  Enterprise behavior is the only thing we can consider.

Maybe the ADs disagree, but I don't think this flies, for several reasons:

One is that IETF has a long history of requiring that its protocols work 
at Internet scale, even if they are only intended for use within an 
enterprise network.  For instance, we require that protocols have robust 
authentication even if they're generally expected to be used only behind 
firewalls.

Another is that even if a protocol is only intended to be used on an 
enterprise network, it will necessarily be installed on large numbers of 
hosts that are occasionally plugged into other networks, and the 
security implications of this need to be examined.

Keith

---

From: Alan DeKok <[email-masked]>
Date: Wed, 13 Dec 2006 16:13:49 -0800

> https://www.trustedcomputinggroup.org/groups/network/

  As I said, you're assuming certain problems, requirements, and
architectures.

> related to TNC, CNAC and NAP, let me know and I will lay it out for

  I can see it. I just can't see how you can say you're not assuming
certain technologies, and then in the same message, refer to
pre-existing technologies as normitive references for NEA terminology
and operation.

  Alan DeKok.

---

From: Keith Moore <[email-masked]>
Date: Wed, 13 Dec 2006 19:18:34 -0500

> in certain jurisdictions.

whether the search is illegal is irrelevant to this discussion.  if you 
put a lock on your house, and it's easily defeated, the fact that it's 
illegal for a spy to defeat the lock and enter your house doesn't mean 
that the lock was doing its job.

> the queries will probably be turing complete. 

you don't need Turing completeness to be extremely invasive.  for 
example, a way to ask "tell me what the value of octet X at offset Y in 
file Z" is sufficient to download the entire file system.

Keith

---

From: Khaja Ahmed <[email-masked]>
Date: Wed, 13 Dec 2006 16:19:04 -0800

I appealed to the chairs and the AD.  Their position was that the
charter should not be changed and it is what it is.  So, whether it
flies or not, this is what we are stuck with for now.  If you have some
way of changing that, I would love to see internet wide back in scope.

Khaja

-----Original Message-----
From: Keith Moore [mailto:[email-masked]] 
Sent: Wednesday, December 13, 2006 4:15 PM
To: Khaja Ahmed
Cc: [email-masked]
Subject: Re: Fwd: [Nea] Re: use of a design team to develop requirements

> is out of scope.  Enterprise behavior is the only thing we can
consider.

Maybe the ADs disagree, but I don't think this flies, for several
reasons:

firewalls.

Keith

---

From: Alan DeKok <[email-masked]>
Date: Wed, 13 Dec 2006 16:22:21 -0800

Mike Fratto wrote:
> forcing anything.

  So you're saying that the NEA protocol is informative:

a) client informs server what it has
b) server informs client what to do in order to gain network access
c) client does it, and is on the net, OR doesn't, and is kicked off.

> are some other examples of potentially draconian standards,

  The "draconian standards" you reference are all informative, as
outlined above.  The issue with the NEA discussions is that NEA has been
claimed to allow arbitrary open-ended *queries* of the end host.

  Since you said above that NEA isn't about open-ended queries, I don't
think there's a need for more discussion on that point.

  Alan DeKok.

---

From: "Mike Fratto" <[email-masked]>
Date: Wed, 13 Dec 2006 19:27:01 -0500

> pre-existing technologies as normitive references for NEA terminology

I never said they were normative references. Never even suggested it.
I never even made a claim about thier worth and I said they are
examples of pre-existing work.

---

From: Khaja Ahmed <[email-masked]>
Date: Wed, 13 Dec 2006 16:26:14 -0800

I should add... in the meantime, our discussion on the group, in this
thread, should be consistent with the charter.  You should start a
separate thread requesting charter revision if you intend to pursue
that.  

Khaja

-----Original Message-----
From: Khaja Ahmed [mailto:[email-masked]] 
Sent: Wednesday, December 13, 2006 4:19 PM
To: Keith Moore
Cc: [email-masked]
Subject: RE: Fwd: [Nea] Re: use of a design team to develop requirements

Khaja

-----Original Message-----
From: Keith Moore [mailto:[email-masked]] 
Sent: Wednesday, December 13, 2006 4:15 PM
To: Khaja Ahmed
Cc: [email-masked]
Subject: Re: Fwd: [Nea] Re: use of a design team to develop requirements

firewalls.

Keith

---

From: "Mike Fratto" <[email-masked]>
Date: Wed, 13 Dec 2006 19:35:54 -0500

> c) client does it, and is on the net, OR doesn't, and is kicked off.

Ok, I guess I will play the role of charter police. As it stands, the
NEA is concerned with a). Not b) (that falls to remediation) and not
c). Please, correct me if I am wrong.

> think there's a need for more discussion on that point.

I did not say that. Read the thread again. In fact, I am completely
convinced that the threat that NEA, or any NAC framework, will be used
for open ended queries is groundless.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 13 Dec 2006 16:36:09 -0800

Keith Moore wrote:

> whether the search is illegal is irrelevant to this discussion.

  My point was that certain architectures of NEA are more likely to be
legal than others.  This knowledge should have *some* effect on the
design of the solution.  Why design something we know can't be deployed?

> file Z" is sufficient to download the entire file system.

  Which is why *informative* protocols are much more robust than ones
that perform queries.

  What should be a major point in these discussions is that if the
network admin "owns" the end host, then he should be able to configure
it to send out the information needed when the machine connects to the
network.  Any querying protocol is overkill, and adds nothing.

  So long as the protocol involves remediation, then the end host can
connect to a remediation network, and download the latest rules about
what information needs to be sent to the network.  It then disconnects
from the remediation network, and reconnects to the normal network,
supplying the newly requested information.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 13 Dec 2006 16:39:45 -0800

> c). Please, correct me if I am wrong.

  That sounds good to me.

> for open ended queries is groundless.

  Should we say that a requirement for NEA is that open-ended qeuries
are unnecessary, and therefore shouldn't be included?

  I like that.

  Alan DeKok.

---

From: "Mike Fratto" <[email-masked]>
Date: Wed, 13 Dec 2006 19:47:18 -0500

> are unnecessary, and therefore shouldn't be included?

Me too. :)

---

From: "Mike Fratto" <[email-masked]>
Date: Wed, 13 Dec 2006 19:49:54 -0500

> network.

Ok, that makes sense as a starting point.

> Any querying protocol is overkill, and adds nothing.

Then what does the network owner do with an unmanged host (one that is
not owned by the network owner)? Something has to be done, what is the
requirement? I don't know.

---

From: Keith Moore <[email-masked]>
Date: Wed, 13 Dec 2006 19:54:28 -0500

>  In fact, I am completely

since the NEA protocol does not exist yet, and there has been pushback 
against trying to impose requirements on the NEA protocol that would 
prevent it from being used for open ended queries, I fail to understand 
the source of your conviction.

do you believe there's really interest in designing NEA in such a way 
that it can't be used for open ended queries?  or do you just believe 
that it won't get used that way even if it's possible to use it that way?

---

From: "Mike Fratto" <[email-masked]>
Date: Wed, 13 Dec 2006 20:15:15 -0500

> the source of your conviction.

If the protocol can be designed that prevents open ended queries while
still allowing queries, then I think doing so probably makes a cleaner
protocol and any mitigation to the claimed privacy threat is a
side-effect.

> that it won't get used that way even if it's possible to use it that way?

I believe there is interest in the working group to design a robust
protocol. That may mean a protocol that can't be used for open-ended
queries.

Any protocol could be used for nefarious purposes. I don't think that
there is need for alarm that the work of the NEA will be abused any
more than any other protocol.

---

From: Keith Moore <[email-masked]>
Date: Wed, 13 Dec 2006 20:21:17 -0500

> more than any other protocol.

well, you may have a very different view of NEA than I do.  it is clear 
to me that a protocol that meets NEA's description could be designed in 
such a way as to be dangerous to hosts' and users' privacy, and that a 
protocol that was dangerous in such a way would give network operators 
more flexibility.

I don't think the comparison with 'any other protocol' is valid because 
some protocols have much more potential for abuse than others.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 13 Dec 2006 17:18:12 -0800

> requirement? I don't know.

  Do what people do today: deny network access, OR put them into a
quarantine network.  They may have limited access to the Internet, but
may be denied access to the corporate network.

  But that's assuming "unmanaged" means "non-NEA aware desktop".  I
don't envision switches implementing NEA any time soon, so they may be
labelled "unmanaged", too.

  Again, this is where requirements and architecture come in.  The whole
PA/PB/etc. thing is nice, but ultimately it comes down to a cable being
plugged into a network device.  Keeping the conversation related to
physical devices means that it's easier to stay focussed.

  Alan DeKok.

---

From: Keith Moore <[email-masked]>
Date: Wed, 13 Dec 2006 20:22:37 -0500

> design of the solution.  Why design something we know can't be deployed?

okay, I think I see your point.

>   Which is why *informative* protocols are much more robust than ones

the word "informative" seems rather vague.

> supplying the newly requested information.

somehow I think the concept of a remediation network really should be 
out of scope for the NEA discussion.  we understand that this is one way 
that NEA might be used, of course, but the idea that there should be a 
separate remediation network seems very shortsighted from an 
architectural perspective.  also, in some cases (zero-day exploits) 
remediation may not be immediately possible.

Keith

---

From: Alan DeKok <[email-masked]>
Date: Wed, 13 Dec 2006 19:20:25 -0800

> the word "informative" seems rather vague.

  I'm trying to come up with useful vocabulary for behaviors that aren't
currently well described.

  What I mean is that many IETF protocols involve the client sending a
list of attributes/values to a server, which thinks about the data, and
sends a response.  I've called this "informative", in that the client
informs the server of what it has, and the server informs the client of
the response.

 PPP, RADIUS, and many other protocols work like this.  There is no
explicit query in the protocol (which is currently an ongoing problem in
RADIUS).  Contrast those protocols with LDAP or SQL, where the intent is
to permit nearly arbitrary queries.

> remediation may not be immediately possible.

  Yes.  Remediation can be done as part of gaining network access
(you're at patchlevel X?  Here's patch Y...), but existing network
access protocols can't carry arbitrary amounts of data.  So some kind of
network access is required to perform remediation, but they can't be
allowed on the network until they have gone through the remediation process.

  But I do *not* think it's desirable or even useful to design NEA such
that it can carry arbitrary amounts of data for remediation.  We already
have too many network protocols that have turned into IP tunnels.

  And for zero-day exploits, shutting down the network may be cheaper
than having it destroyed by an attacker.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 18 Dec 2006 09:29:38 -0800

Mike Fratto wrote:

> still allowing queries,

  What kind of queries?  Do you have examples?

  And I still don't see why *any* queries are required.  Look at the
target deployments specified by the charter, the enterprise admin "owns"
the machines.  So there is *always* a way for that admin to inform the
machines off-line what information is required.  This can be done when
the machines are first configured, or as part of a remediation update.

  i.e. remediation updates inform the machines of updates to local site
policy.  Updates to virus scanners, etc. are just subsets of updates to
the local site policy.  The updates will also include statements sycg as
"install new software program X, and when you reconnect, tell me what it
says."

  Requiring queries in the NEA protocol looks to me like the intended
deployment scenarios are *outside* of the scenarios described in the
charter.

> more than any other protocol.

   Most network access protocols (PPP, DHCP, RADIUS, etc.) do NOT
support queries.  If the NEA protocol supports queries, it *will* be
abused more than protocols that do not support queries.

  That conclusion is inescapable: The more functionality exists in a
protocol, the more potential for abuse.  We should therefore be careful
to put only required functionality into NEA, and nothing more.

  Alan DeKok.

---

From: John Vollbrecht <[email-masked]>
Date: Mon, 18 Dec 2006 14:27:38 -0500

> deployment scenarios are *outside* of the scenarios described in the
I have assumed that the network could require information to allow  
access.  The user could also refuse to provided certain information.   
The result on the network side might be to allow only access to a  
remediation network.  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.

The value of queries  to at least some people is the reason for the wg.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 18 Dec 2006 12:05:45 -0800

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.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 18 Dec 2006 12:21:34 -0800

John Vollbrecht wrote:
> access.

  What kind of information?  Why?  What will the NEA server do with that
information once it receives it?

  When I work through the various scenarios, I don't see much use for
queries.

>  The user could also refuse to provided certain information. 
> remediation network.  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.

> The value of queries  to at least some people is the reason for the wg.

  That's nice.  Do you have *concrete* examples that we can talk about?

  Alan DeKok.

---

From: "Mike Fratto" <[email-masked]>
Date: Tue, 19 Dec 2006 08:47:35 -0500

To: Alan DeKok <[email-masked]>

> the NEA server knows about?

So what does an NEA server make a decision on? It can't make a
decision in a vacuum. Reporting product X, version y, update
DD-MM-YYYY-hh:mm:ss, tells the NEA server the current status of that
piece of software. This is used to make a decision based on local
policy. The NEA server doesn't need to know about vulns or exploits.
The human administring the local policy does, however. Some person has
to say that products prior to version Z are unacceptable and configure
a policy decision.

That could be a query/response or it could be notification mechanism,
though the latter is highly inflexible and severly limiting. Now ask
me why.

---

From: Keith Moore <[email-masked]>
Date: Tue, 19 Dec 2006 09:08:50 -0500

-------- Original Message --------

> So what does an NEA server make a decision on? 

who says the NEA server has to make a (nontrivial) decision?  if the 
client presents a statement, signed by a key that is traceable to a host 
and a product, that says that the host conforms to a certain level of a 
profile, what more does the server need to do other than to tell the 
network to give the host whatever level of access corresponds to that 
profile?

> though the latter is highly inflexible and severly limiting. 

yes, but that's the point - the limitations are highly desirable in 
reducing the threat of NEA to privacy, and they don't get in the way of 
letting NEA do the job that it is designed to do.  they also have the 
advantage of making NEA a fairly trivial protocol to design and 
implement, allowing the standard to get to market much more quickly.

Keith

---

From: Alan DeKok <[email-masked]>
Date: Tue, 19 Dec 2006 10:22:19 -0800

> network to give the host whatever level of access corresponds to that

  Exactly.

  I would like to see use-cases to the contrary.  If they exist, and are
important, then support for queries may be useful.

  Alan DeKok.

---

From: "Mike Fratto" <[email-masked]>
Date: Tue, 19 Dec 2006 13:26:33 -0500

> important, then support for queries may be useful.

What uses cases are you looking for?

---

From: "Mike Fratto" <[email-masked]>
Date: Tue, 19 Dec 2006 13:26:56 -0500

> who says the NEA server has to make a (nontrivial) decision?

who said the decision is trivial or non-trivial? I don't even know
what that means.

 > if the

Ok, I am going to pass on the key signing for the moment. It's an
implementation issue and can be discussed later. Your general point,
one where the client sends a statement that it conforms to a level of
profile makes sense make sense but I have two questions.

1) How do you propose the handshake happen?
2) What happens in the case where a NEA client doesn't send sufficient
information to the NEA server for the NEA server to make a decision?

> implement, allowing the standard to get to market much more quickly.

I was not referring to privacy limitations. Remember, I don't think
privacy is much of an issue. The limitations in a notification
mechanism is that the communication is one-way with no chance for the
two system to converge. The policy decision comes down to "Did the NEA
client send me what I need to know?" and "Does that fit my policy?" If
the exchange fails at question 1 and there is no recourse for the NEA
server to query the NEA client for more information, then the exchange
ends. That is inflexible and a non-starter.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 19 Dec 2006 10:40:59 -0800

> What uses cases are you looking for?

  Ones where the scenarios we presented don't work.

  e.g. where the NEA server needs to know about the status of something
on the client, and where there's no third party involved.

  We'll ignore the case where the NEA server is the "third party".  That
scenario is identical to ones where there is a real third party.

  That is, if the NEA server needs more information than is supplied by
any third party software, the enterprise administrator can install his
own software on the NEA client.  That software then uses the same
methods as used by any other third parties to report posture.

  Alan DeKok.

---

From: Keith Moore <[email-masked]>
Date: Tue, 19 Dec 2006 13:52:59 -0500

-------- Original Message --------

> important, then support for queries may be useful.

I suppose that begs the question of how NEA clients learn the profiles 
that they need to evaluate.  Does the NEA protocol need to support, or 
is this somebody else's problem?  What if the client connects and finds 
that its profile is out-of-date, should NEA allow the client to download 
the current profile?  And how different is that (from a security/privacy 
point-of-view) than a query?

Keith

---

From: Alan DeKok <[email-masked]>
Date: Tue, 19 Dec 2006 10:50:06 -0800

> information to the NEA server for the NEA server to make a decision?

  Huh?  See previous posts.  This has been discussed many times.

  Alan DeKok.

---

From: Keith Moore <[email-masked]>
Date: Tue, 19 Dec 2006 14:17:13 -0500

> who said the decision is trivial or non-trivial? I don't even know 

in my mind a trivial decision would be a situation where the client
software is responsible for determining whether the host conforms to the
profile for that network, it simply reports this to the NEA server, and
the NEA server then verifies that the profile is current and that the
NEA client is trustworthy.  that's why the signature, because the server
would want some way to establish trust in the NEA client before granting
access to the network.  but in this model, the server's decision-making
role is fairly "trivial" - if the signature checks out, believe whatever
the client is saying and give the client whatever level of network
access corresponds to that client and that profile.

by contrast, a non-trivial decision would be one where the NEA server
has to decide, based on several pieces of information provided by the
client (say, the results of some arbitrary number of tests), what level
of network access a client should have.

>> if the client presents a statement, signed by a key that is
>> traceable to a host and a product, that says that the host conforms
>> to a certain level of a profile, what more does the server need to
>> do other than to tell the network to give the host whatever level
>> of access corresponds to that profile?
> 
> implementation issue and can be discussed later.

I don't think it's an implementation issue - it needs to be specified as
part of the protocol.

> Your general point, one where the client sends a statement that it
> conforms to a level of profile makes sense make sense but I have two
> questions.
> 

It seems a bit early to do protocol design but offhand I think it would
look something like this:

<some event triggers an NEA verification>
S: I'm server <servername>, acting on behalf of network <networkname>
and here are my credentials.
C: I'm client <clientname>, and here are my credentials.
S: current profile for you is <profilename, profileversion>.
C: For network <networkname>, I {do, don't} conform to profile <profile 
name, profile version>, signed <clientname>, and here are my credentials.
S: You are granted access level {full, reduced, remedial, none}.
C: thanks!

and that would be it.  Or maybe

<some event triggers an NEA verification>
S: I'm server <servername>, acting on behalf of network <networkname>
and here are my credentials.
C: I'm client <clientname>, and here are my credentials.
S: current profile for you is <profilename, profileversion>.
C: I don't have profile <profilename, profileversion>
S: <profilename, profileversion> consists of "bits..."
C: bye!

(with the assumption that the client then needs to take some time to 
evaluate that profile before attempting to connect again)

and just in case it's not obvious, the profile would contain a list of 
tests that needed to be carried out by the client.

> 2) What happens in the case where a NEA client doesn't send
> sufficient information to the NEA server for the NEA server to make a
> decision?

In this model, there's always sufficient information provided to the
server because most of the decision is made on the client, and the
client just reports the result of that evaluation to the server.  The
server just decides whether the client's decision-making and reporting
are trustworthy and gives the client the level of access that it's
configured to give based on the client identity and profile.

>>> That could be a query/response or it could be notification
>>> mechanism, though the latter is highly inflexible and severly
>>> limiting.
>> 
>>  reducing the threat of NEA to privacy, and they don't get in the
>> way of letting NEA do the job that it is designed to do.  they also
>> have the advantage of making NEA a fairly trivial protocol to
>> design and implement, allowing the standard to get to market much
>> more quickly.
> 
> privacy is much of an issue.

Well, perhaps we simply disagree, or perhaps you just have in mind a
different model which deals with privacy threats in a different way.
But it's important to not assume that NEA will be used only by
people/networks who respect users' privacy.

> The limitations in a notification mechanism is that the communication
> is one-way with no chance for the two system to converge. The policy
> decision comes down to "Did the NEA client send me what I need to
> know?" and "Does that fit my policy?" If the exchange fails at
> question 1 and there is no recourse for the NEA server to query the
> NEA client for more information, then the exchange ends. That is
> inflexible and a non-starter.

Any protocol that allows the client and server to iterate with the
server demanding arbitrary information from the client is a huge privacy
risk and a non-starter for that reason.

Keith

---

From: Alan DeKok <[email-masked]>
Date: Tue, 19 Dec 2006 11:56:07 -0800

Keith Moore wrote:
> that they need to evaluate.

  I think it's "via the remediation network, which is outside of the
scope of NEA".

>  Does the NEA protocol need to support, or
> the current profile?

  The server should decide if the clients profile is out of date.  The
alternative is the client system saying "Yeah, I'm fine... honest...",
which is pretty much what we have today.

>  And how different is that (from a security/privacy

  Not much, but if the system doesn't have a process for policy updates,
it isn't that useful.

  My take is that policy updates will happen much less often than
connection requests.  So if nothing else, it's more efficient to not
have queries at every connection attempt.  Since the queries and/or
policy updates may be large, it would be better to leverage real
networks for that process, rather than trying to carry large amounts of
data in the NEA protocol itself.

  I'll try to write up an I-D that summarises the discussion so far.  It
may be mid January before it's out, though.

  Alan DeKok.

---

From: Keith Moore <[email-masked]>
Date: Tue, 19 Dec 2006 15:12:50 -0500

>   I think it's "via the remediation network, which is outside of the

not clear.  at least the format of the profiles needs to be 
standardized, IMHO, otherwise there's no capability for interoperation 
and no point to having an NEA standard.

>   The server should decide if the clients profile is out of date. 

on that much we agree.  the question is how the client gets the new 
profile.  I don't like having the answer be "via the remediation 
network" because I think the whole concept of a remediation network is 
architecturally dubious.  it might be fine for now but is not IMHO 
something we want to base a standard on.  it also seems to me that some 
networks will not want to provide remediation but will want to use NEA 
and that NEA should still be able to provide a definite answer.  that 
implies to me that the profile downloading should be able to happen via 
NEA, rather than introduce a situation where NEA can't tell whether a 
client is trustworthy or not because the client doesn't have a current 
profile.

I also suspect that we're going to need to put some limitations on how 
frequently a profile can be changed in order to limit the potential for 
NEA to be used as a means of extracting arbitrary information from a 
client.  If the server can keep changing the profile that's about as bad 
as allowing the server to iterate queries.

> data in the NEA protocol itself.

what do you mean by "real networks"?  do you assume that NEA will 
operate over something besides TCP/IP? TCP seems perfectly capable of 
carrying enough data to transmit an NEA profile.

Keith

---

From: Alan DeKok <[email-masked]>
Date: Tue, 19 Dec 2006 13:57:33 -0800

> and no point to having an NEA standard.

  Yes.

> ...  that

  My main concern with this is that NEA is *before* the machine obtains
full network access.  So... how does it download potentially megabytes
of updates?  IP tunneling inside of NEA?  Yuck...

> carrying enough data to transmit an NEA profile.

  No, I mean TCP/IP shouldn't operate over NEA.  That way lies madness.

  Remediation must use TCP/IP to download updates, but it can't use a
public/open network (otherwise you wouldn't be using NEA).  The
remediation process therefore must severely limit the capability of the
clients network connection.  This can be done via a quarantine network
as people do today. Or, it can be done via massive & dynamically updated
filter rules, which are fragile and difficult to administer.

  Alan DeKok.

---

From: Keith Moore <[email-masked]>
Date: Tue, 19 Dec 2006 20:50:55 -0500

-------- Original Message --------

> of updates?  IP tunneling inside of NEA?  Yuck...

I assume the network supports IP to the extent that it needs to 
implement NEA.  It doesn't have to route IP packets anywhere other than 
between the host and the NEA server(s), but it does have to do that much.

>   No, I mean TCP/IP shouldn't operate over NEA.  That way lies madness.

perhaps, but nobody has suggested doing that.

>  public/open network (otherwise you wouldn't be using NEA).  

I'm not talking about remediation, I'm only talking about downloading 
the information that the NEA client needs to make the checks.  This 
should be a list of generic tests, NOT arbitrary code.

Keith

---

From: Douglas Otis <[email-masked]>
Date: Wed, 20 Dec 2006 14:34:14 -0800

On Dec 19, 2006, at 12:12 PM, Keith Moore wrote:

> standardized, IMHO, otherwise there's no capability for  
> interoperation and no point to having an NEA standard.

It seems the entire exchange could be an exchanging certificates.   
The provider offers certificates in sets, perhaps by reference based  
upon a service URI, OS, and service name, where clients then request  
and verify a producer of the certificate which may be some third- 
party.  Within the certificates held by the provider, there should be  
a time-stamp, their identity (perhaps hostmaster@), the type of  
service providing the certificate, suitable OS, and resources needed  
to obtain the service that in the end generates a certificate for the  
client based upon the client's identity.

The black-box would be the service.  The standardization would not  
need an elaborate profile, as this should be handled by the service  
as a means to retain privacy regarding the perhaps thousands of  
details involved.  These certificates could be broken down into sets,  
such as OS patches, AV solutions, Network configuration, etc.  The  
provider can decide what they find to be important by presenting both  
mandatory and option sets of certificates.  The user could then be  
allowed to interact to select those certificates that pertain to  
their system, as well as which services they are willing to accept.

The "profile" could be a simple status field entered into the  
certificate classifying a level of conformance achieved.  There  
should be error codes to indicate which field has not been accepted,  
such as the time-stamp or the classification.  Within the  
certificates, the status/classification result should provide  
adequate information upon which the provider could then make  
decisions on acceptance.

> network" because I think the whole concept of a remediation network  
> is architecturally dubious.  it might be fine for now but is not  
> IMHO something we want to base a standard on.  it also seems to me  
> that some networks will not want to provide remediation but will  
> want to use NEA and that NEA should still be able to provide a  
> definite answer.  that implies to me that the profile downloading  
> should be able to happen via NEA, rather than introduce a situation  
> where NEA can't tell whether a client is trustworthy or not because  
> the client doesn't have a current profile.
>
> I also suspect that we're going to need to put some limitations on  
> how frequently a profile can be changed in order to limit the  
> potential for NEA to be used as a means of extracting arbitrary  
> information from a client.  If the server can keep changing the  
> profile that's about as bad as allowing the server to iterate queries.

By indicating specifically what is required for a particular service,  
either the client or the provider could open their firewalls enough  
to allow these services to run.  The protection is really found by  
knowing exactly what is needed. How the barriers are erected depends  
upon who feels threatened.  Others sharing the network may wish to  
have the provider impose the barriers, but that is largely due to the  
current state.  This state could be dramatically improved when using  
NEA to impose upon problematic clients a need to achieve compliance  
within a reasonable timeframe.

-Doug

---

From: Alan DeKok <[email-masked]>
Date: Wed, 20 Dec 2006 15:20:53 -0800

Douglas Otis wrote:
>
> It seems the entire exchange could be an exchanging certificates.  The
> provider offers certificates in sets,

  Why sets?  Why not just one certificate?

  We can presume that NEA client policy updates are much rarer than
network connection requests (i.e. posture assessments).  In that case,
the client can be issued a certificate for a particular network once it
has downloaded the latest set of updates.  That certificate may then be
used for repeated posture assessments.

  i.e. the NEA server issues the client a certificate that validates a
particular posture (or set of provider certificates).  Once that's done,
the client only has to present one certificate to the NEA server, rather
than a set.

  When the NEA server decided that it has new updates available, it can
compare the date of "last known update" to the "client certificate issue
date".  If the clients certificate was issued before the last update,
then the client needs remediation.  Otherwise, the client doesn't need
remediation.  The process then repeats.

  Similarly, if the client notices that updates are available, it can
invalidate it's own certificate (i.e. by not using it), at which point
the NEA server will ask it to perform remediation, and then issue a new
certificate.

> perhaps by reference based upon a
> service URI, OS, and service name, where clients then request and verify
> a producer of the certificate which may be some third-party.  Within the
> certificates held by the provider, there should be a time-stamp, their
> identity (perhaps hostmaster@), the type of service providing the
> certificate, suitable OS, and resources needed to obtain the service
> that in the end generates a certificate for the client based upon the
> client's identity.

  Yes, although it's not clear what provider posture information (if
any) needs to be available to the NEA server.

  Alan DeKok.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 21 Dec 2006 11:39:33 -0800

On Dec 20, 2006, at 3:20 PM, Alan DeKok wrote:

>> The provider offers certificates in sets,
>

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.

There could be mandatory sets, and optional sets.  In the case of  
optional sets, these could be seen as advertisements of recommended  
services.  Even within an enterprise environment, it is extremely  
common for laptops from individuals outside the enterprise to seek  
access.  It should not be assumed that everyone uses Windows or  
MacOSX.  Linux and FreeBSD are also fairly common, depending upon the  
nature of the work.  Within the IETF, this list will be even larger.   
It seems eating one's own dog food provides a good basis for judging  
requirements.  Can IETF meetings utilize NEA?

> network connection requests (i.e. posture assessments).  In that  
> case, the client can be issued a certificate for a particular  
> network once it has downloaded the latest set of updates.  That  
> certificate may then be used for repeated posture assessments.

Who is producing the certificate?  Who is offering the service?  You  
do not want individuals to start trusting just any access point  
running NEA.  Service providers should be the ones offering the  
certificates.  Each service may need to update on a regular basis.   
Each service may represent a large diversity of service providers.

> i.e. the NEA server issues the client a certificate that validates  
> a particular posture (or set of provider certificates).  Once  
> that's done, the client only has to present one certificate to the  
> NEA server, rather than a set.

It seems impractical for an NEA server to assess thousands of details  
related to various services being contemplated.  Unless the  
certificate is something as simple as agreeing to an AUP, the NEA  
server is not really able to generate certificates directly.  The NEA  
server must delegate assessments to trusted organizations able to  
properly determine the state of the client.  The NEA server does not  
need to know these details, nor is that really desired.  The NEA  
server indicates which services they both trust and expect to have  
been completed by the client.  The NEA server may also recommend  
services as well.

> When the NEA server decided that it has new updates available, it  
> can compare the date of "last known update" to the "client  
> certificate issue date".  If the clients certificate was issued  
> before the last update, then the client needs remediation.   
> Otherwise, the client doesn't need remediation.  The process then  
> repeats.

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.  Being able  
to tell the client to open specific resources and obtain a specific  
service would be one method that NEA might help prevent non- 
compromised systems from being compromised.  Certificates should be  
consider simply an end-product of completing some service.  There  
might be many services needed to support a possibly vast array of  
systems and uses, even within an enterprise environment.  The NEA  
would list these Certificates by reference and allow the client to  
request the host's version of the certificate when needed.  (This  
would be a rare event.)

> invalidate it's own certificate (i.e. by not using it), at which  
> point the NEA server will ask it to perform remediation, and then  
> issue a new certificate.

I don't see that as part of the NEA service.  Most of these types of  
services are already done routinely.  There might be cases where this  
routine needs to be changed in the face of a new zero-day exploit.   
It can also help large organizations better track problematic  
systems.  There have been embarrassing situations where some system  
within an enterprise becomes compromised, and this machine must be  
physically found to correct the situation.  Knowing the nature of the  
problem might allow targeted services aimed at resolving specific  
issues.  They happen far too often to not be considered.

>> perhaps by reference based upon a service URI, OS, and service  
>> name, where clients then request and verify a producer of the  
>> certificate which may be some third-party.  Within the  
>> certificates held by the provider, there should be a time-stamp,  
>> their identity (perhaps hostmaster@), the type of service  
>> providing the certificate, suitable OS, and resources needed to  
>> obtain the service that in the end generates a certificate for the  

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.

-Doug

---

From: Alan DeKok <[email-masked]>
Date: Thu, 21 Dec 2006 13:15:31 -0800

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

  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.

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

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

---

From: Douglas Otis <[email-masked]>
Date: Thu, 21 Dec 2006 18:32:17 -0800

On Dec 21, 2006, at 1:15 PM, Alan DeKok wrote:

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

The goal is to minimize data held within a certificate such that it  
remains possible to hold several within a single packet.  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.

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

Any large enterprise will host a number of guests, contractors,  
salesmen, and consultants.  These individuals should not be forced to  
trust some NEA server's profiling application.  Few will remain  
within the same environment, so NEA should consider the effects a  
compromised NEA server might have.

The NEA design should allow the entities providing services be  
trusted instead, rather than a larger number of NEA servers of  
questionable status.  Rather than assuming a work environment  
requires that one must always expose their system directly to the NEA  
server, a normal mode of operation should permit trust based upon  
those directly providing a service, such as OS updates or AV  
scanners.  Few would want to be forced to run an enterprise Brand X  
application that does who-knows-what at an administrative level.   
Working within an enterprise environment should not demand the NEA  
server itself be trusted.

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

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.  By service provider,  
this was not meant to imply an access server provider, although they  
would not be excluded either.

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

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

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

NEA facilitates a means to communicate with an endpoint specific  
requirements based upon generalized status contained within a CAR  
certificate.  The CAR service is well beyond the scope of the NEA  
server.  CAR certificates form a basis for NEA acceptance or  
notification.  The NEA server should not be directly trusted in  
providing CAR services however.

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

An NEA server could offer minimally intrusive CAR services, such as  
negotiating an AUP or caching previously exchanged certificates.  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.

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

Ensure there is a two-way negotiation of CAR services.  The NEA  
server should in essence say "pick one from each set" and then offer  
a related certificate.  For details, the Server can offer their  
certificate signed for them (i.e. hostmaster@).  These sets might be  
mandatory or simply recommended.

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

Provide a clearer distinction between what a CAR provides and what an  
NEA server negotiates.  In essence, NEA adds a requirement that CAR  
services offer clients a receipt in the form of a certificate.  These  
services exist today.  With a minimal effort, these certificates can  
be exchanged indicating the results.  The NEA server is not where  
these CAR services are run without major and rather risky changes.

-Doug

---

From: Alan DeKok <[email-masked]>
Date: Thu, 21 Dec 2006 23:22:10 -0800

Douglas Otis wrote:
> 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 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.

> Assessment and Remediation (CAR) service?

  How about using the terms from the charter?

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

---

From: Douglas Otis <[email-masked]>
Date: Fri, 22 Dec 2006 08:23:38 -0800

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

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.

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

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

> 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

---

From: Alan DeKok <[email-masked]>
Date: Fri, 22 Dec 2006 08:57:49 -0800

Douglas Otis wrote:
> 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.

  That isn't in dispute.

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

  No, I did NOT say that.  Please read my messages again.

> A mutually trusted service is not ridiculous.

  Did you read the text you're allegedly responding to?

  I won't respond to the rest of your post.  It's yet another repetition
of the same opinions, and doesn't address my earlier comments about
those opinions.

  Alan DeKok.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 22 Dec 2006 11:34:39 -0800

>   Did you read the text you're allegedly responding to?

Review the open issues for discussion indicated in the charter.  If  
you have an I-D you would like reviewed, please provide a reference.   
Sharing elaborate system details with every NEA server is not a good  
strategy for security or compatibility.  It is difficult to imagine  
that asking the end-point what they claim to have accomplished offers  
any type of solution whatsoever.  Such a solution will be immediately  
defeated.

-Doug