Subject: [Nea] REQ: Section 3

From: Alan DeKok <[email-masked]>
Date: Wed, 10 Jan 2007 23:47:39 -0500

The comments in Section 3.1 about lying endpoints should reference
section 8.1.1, and state that the issue is dealt with in more detail
there.  Without additional explanation, the current text seems to be
saying "we'll secure the system by asking it questions... but it can
lie.  Oh well."  Adding a reference to the security section indicates
that there may be mitigating circumstances.

  Much of Section 3.2 appears to directly contradict the charter.

      ... the use of NEA
      technologies may not apply in a variety of situations possible
      on the Internet

  The charter says that "NEA is applicable to computing enterprise
environments, ... All other cases are outside the scope of the NEA charter,"

      Therefore, this section discusses some of
      the scenarios where NEA is most likely to be applicable and
      some where it may not.

  No, the charter says that NEA is applicable only to certain scenarios.
 The requirements document MUST says that all non-charter scenarios are
outside of the scope of the NEA applicability.  The requirements
document SHOULD say that the ISP, etc. scenarios are explicitely not
being considered.  The document SHOULD say that NEA SHOULD NOT be used
in those scenarios.

      ... Environments where
      the Endpoint is owned by a party (possibly even the User)
      where the party has explicitly expressed a desire to conform
      to the policies established by a network or service provider

  No.  The charter states that NEA is not applicable to the network
provider or service provider market.  This text can mislead the reader
into believing that NEA is applicable to scenarios where the charter
says it is not applicable.

      ... Conversely, some environments where NEA is not expected to be
      applicable would be environments where the Endpoint is owned
      by a User and has not agreed to conform to a network
      provider�s policies.

  This text (and other similar text) appears to confuse the issue of NEA
or posture assesment with network access.  If I choose to not conform
with a network's policies by (say) not providing a correct password, the
network provider will not permit me to access the network.  This
scenario should be explicitely mentioned in the document: You do not
have to do NEA.  You do not have to agree to the network owners
policies.  But the network owner does not have to give you access.

  i.e. It's confusing to say "NEA is not applicable" when some does not
agree to use NEA.  NEA *is* applicable if it meets the charter
requirements, and the network owner demands that NEA be used.  Instead,
the document should say "NEA may be applicable, but MUST NOT be used if
the Endpoint does not agree to an NEA protocol exchange".

  Text like that would simplify much of the discussion around the
various scenarios.  It would cover legacy systems not running NEA,
systems running NEA but from a differing network, and systems running
NEA where the owner of the endpoint chooses not to comply.

      ... An example might include when the above
      contractor visits any public area like the local coffee shop
      which offers Internet access.  This coffee shop would not be
      expected to be able to use NEA technologies to assess the
      Posture of the contractor�s laptop.

  No, that is forbidden by the charter.  Privacy is not the issue.  The
charter states "... we do not know that NEA would be useful in such cases."

  i.e. Non-charter scenarios have many issues, some of which are
unknown.  Non-charter use of NEA is forbidden outright, and should not
be discussed in the document other than to say it is forbidden.

      Other environments are more difficult to determine whether NEA
      is a good fit, so the NEA WG intends to steer clear of such
      areas.

  Again, it is forbidden by charter.  Saying the WG has intentions is
saying we might steer clear... or we might not.

      ... In particular environments where the Owners of the
      Endpoint, the network infrastructure and/or the network
      service provider are different and do not have a strong
      binding contract(s) establishing their expectations for
      conformance and willingness to disclose information to each
      other security policies.

  I'm not sure what that sentence is saying.  Maybe a missing comma?

       ... In particular, environments where the Owners of the
      Endpoint, the network infrastructure and/or the network
      service provider are different and do not have a strong
      binding contract(s) establishing their expectations for
      conformance and willingness to disclose information to each
      other security policies.

  I suggest splitting the sentence into two or more shorter sentences.

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

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

---

From: "Paul Sangster" <[email-masked]>
Date: Thu, 11 Jan 2007 13:13:37 -0800

> -----Original Message-----
> From: Alan DeKok [mailto:[email-masked]] 
> Sent: Wednesday, January 10, 2007 8:48 PM
> To: [email-masked]
> Subject: [Nea] REQ: Section 3
> 
>   The comments in Section 3.1 about lying endpoints should 
> reference section 8.1.1, and state that the issue is dealt 
> with in more detail there.  Without additional explanation, 
> the current text seems to be saying "we'll secure the system 
> by asking it questions... but it can lie.  Oh well."  Adding 
> a reference to the security section indicates that there may 
> be mitigating circumstances.

Adding a reference makes sense.  As you know this section just describes
our specified scope so we need to say this is out of scope since a
reader might expect otherwise, but I agree its useful to reference 8.1.1
that might provide additive approaches to addressing the issue.

>   The charter says that "NEA is applicable to computing 
> enterprise environments, ... All other cases are outside the 
> scope of the NEA charter,"

If we look at the "..." text that wasn't included we might find how some
of the other text made it into -00.  The charter actually says:

"NEA is applicable to computing enterprise environments, where endpoints
accessing the enterprise's network are owned and/or expected to conform
to the policies set forth by the organization that owns and operates the
network."

For -00 it seemed reasonable to talk about both sides of the "and/or" so
the WG could decide whether to allow it to remain.  Please note the "or
expected to conform to the policies set forth by the organization"
phrase.  We certainly welcome dialog on whether the spec went to far (or
not far enough) in this regard.

With this in mind, we should discuss which scenarios discussed as
in-scope are considered out of scope by WG consensus so we can update
the spec.  

Does the WG believe we should not claim that scenarios where the
Endpoint is Owned by a different party then the Owner of the network
must always be out of scope?  We could decide this, but I do not see
this as a hard rule in the charter as long as the Owner of the Endpoint
establishes is "expected to conform to the policies set forth by the
organization that owns and operates the network."  Thoughts?

>  The requirements document MUST says that all non-charter 
> scenarios are outside of the scope of the NEA applicability. 

See above.
 
> The requirements document SHOULD say that the ISP, etc. 
> scenarios are explicitely not being considered.  The document 
> SHOULD say that NEA SHOULD NOT be used in those scenarios.

The text gives an ISP oriented example in paragraph 4 and says "NEA is
not expected to be applicable"  We could consider making the language
stronger if necessary.

>   No.  The charter states that NEA is not applicable to the 
> network provider or service provider market.  This text can 
> mislead the reader into believing that NEA is applicable to 
> scenarios where the charter says it is not applicable.

See above.

>       provider s policies.
>   This text (and other similar text) appears to confuse the 
> issue of NEA or posture assesment with network access.  If I 
> choose to not conform with a network's policies by (say) not 
> providing a correct password, the network provider will not 
> permit me to access the network.  This scenario should be 
> explicitely mentioned in the document: You do not have to do 
> NEA.  You do not have to agree to the network owners 

This is mentioned in several places in the document, but we could add a
phrase here if it helps.

> 
>   i.e. It's confusing to say "NEA is not applicable" when 
> some does not agree to use NEA.  NEA *is* applicable if it 
> meets the charter requirements, and the network owner demands 
> that NEA be used.  Instead, the document should say "NEA may 
> be applicable, but MUST NOT be used if the Endpoint does not 
> agree to an NEA protocol exchange".

Its my impression that this document provides context and requirements
for NEA protocol selection by the NEA WG.  The text suggested reads like
a normative requirement applying to the deployer and not to the NEA WG
selection of appropriate protocols for NEA.  Could this be reworded to
state the NEA WG intentions for how we envision NEA's use (and what it
was designed for) without 2119 language?

> 
>   Text like that would simplify much of the discussion around 
> the various scenarios.  It would cover legacy systems not 
> running NEA, systems running NEA but from a differing 
> network, and systems running NEA where the owner of the 
> endpoint chooses not to comply.
> 
>       Posture of the contractor s laptop.

Again expanding the "..." which seems to be causing confusion the "..."
reads:
"Conversely, some environments where NEA is not expected to be
applicable would be environments where the Endpoint is owned by a User
and has not agreed to conform to a network provider's policies.  An
example might include"

> 
>   No, that is forbidden by the charter.  Privacy is not the 
> issue.  The charter states "... we do not know that NEA would 
> be useful in such cases."

That is what this text (see the expanded "..." text above) says.  We're
stating where NEA is not applicable in this paragraph.  I'm open to
mentioning the charter of our WG if that adds clarity to our NEA
protocol selection process.

> 
>   i.e. Non-charter scenarios have many issues, some of which 
> are unknown.  Non-charter use of NEA is forbidden outright, 
> and should not be discussed in the document other than to say 
> it is forbidden.
> 
>   Again, it is forbidden by charter.  Saying the WG has 
> intentions is saying we might steer clear... or we might not.

Can you suggest a different word then "intends" which make it more clear
that we aren't planning to include this in our scope.  We could change
the last phrase to "so the NEA WG will not address such areas."

>   I suggest splitting the sentence into two or more shorter sentences.

Ok, it was trying to say there are 3 parties involved and if they have
different owners they need to have a contract-based expectation of
conformance and willingness to expose information with each other or
this scenario is not applicable.  Will reword.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 12 Jan 2007 09:40:59 -0500

> not far enough) in this regard.

  Both sides of the "and/or" involve endpoints, not networks.  The
charter is clear: enterprise networks, client endpoints.  The
requirements document discusses non-enterprise networks as being
applicable for NEA.  I believe such non-enterprise networks are out of
scope.

> must always be out of scope?

  No.  It is a charter requirement that the ownership of endpoints can
be different than the ownership of the enterprise networks.

> not expected to be applicable"  We could consider making the language

 Please do so.  It should be clear that the ISP deployment of NEA is
forbidden due to unknown security, privacy, and legal concerns.  And we
don't have time to discuss those issues, so they won't be resolved here.

> selection of appropriate protocols for NEA.

  It does both.  The protocol needs to include the capability that an
endpoint can decline an NEA protocol exchange, likely with more than
simple silence.

>  Could this be reworded to

  Likely, yes.  I can't suggest much right now.

> protocol selection process.

  My concern is less with the elided text than with the phrase "is not
expected to".  It reads as "we expect to follow the charter
requirements", which is more open to non-charter work than "we will
follow the charter requirements".

> the last phrase to "so the NEA WG will not address such areas."

  Yes.

> this scenario is not applicable.  Will reword.

  So the parties are: endpoint, network infrastructure owner, and
network service provider.

  Are we really saying that enterprise networks have two owners, who
don't mutually disclose security policies?  I don't understand.  What
use-case is satisfied by modeling the enterprise network this way?

  Alan DeKok.