Subject: [Nea] Comments on draft -04

From: Yaron Sheffer <[email-masked]>
Date: Wed, 19 Sep 2007 14:25:46 +0200

Hi,

attached is a (rather long) list of comments. I appreciate the huge 
effort that went into this draft and apologize for being so late with my 
comments. I hope you can consider them for the next revision.

Thanks,

    Yaron

    * Sec. 2: Sessions should be in the scope of the requirements if
      they are relevant to the integrity (security) of the exchange. For
      example if the protocol is susceptible to message reordering. See
      last sentence of Sec. 8.1.3.
    * Sec. 2: "Owner" - the language is a bit convoluted. "The legal,
      rightful possessor", followed by "even if the asset is not within
      the owner's possession".
    * Sec. 2: the "user" is a person, not an entity.
    * Sec. 3.1: the first (positive) part of the Scope should be
      normative, since it sets the stage for the more detailed Sec. 7.
      Use stronger language, rather than "the WG intends".
    * Sec. 3.1: even if PT is/are defined in other workgroups, a
      NEA-specific PT profile may be specified within NEA for some
      particular PT protocol(s). It would be clearer to say that NEA
      prefers to use existing protocols for PT (this is in fact
      mentioned elsewhere).
    * General: the word "privacy" is used quite liberally throughout the
      document. In most cases when it is used, the problem is much more
      that of security exposure than of privacy, in the usual sense of
      the word. Most people would not consider their OS version and
      build number to be privacy sensitive, but this information is
      certainly security sensitive, since it allows an adversary to
      tailor an attack to the particular OS.
    * Sec. 4: what is "gateway access"?
    * Sec. 5: although the "vertical lines" are out of scope, it is
      important to note which ones are expected to be available to
      component developers.
    * Sec. 5: the paragraph about discovery is out of sync with the
      common 802.1X deployment. In that case, the client is not
      configured with the server address, it just talks to the
      enforcement point. On a different level, is there discussion on
      the discovery of protocol peers at the PA/PB layers?
    * Sec. 5.1.1.2: there may be scenarios where the Posture Broker
      Client should receive remediation attributes and handle them
      itself, e.g. by restarting (or even installling) individual
      Posture Collectors.
    * General: the model is unclear on whether there is a 1:1
      correspondence between PC and PV, or whether there may be one PV
      communicating with multiple PC etc.
    * General: it is assumed here that there is one global yes/no policy
      decision. But consider the following scenario: a computer is
      evaluated against two policies, a Contrator policy and an Employee
      policy. It is compliant to the first, and non-compliant to the
      second (and receives remediation instructions). The Posture Broker
      and/or the user may decide whether it wants to remediate its
      posture to be compliant with the stricter policy.
    * Sec. 6.1.1.2, step (15): typo, "the each".
    * Sec. 6.1.2.1: I wonder about this use case, since in a "shared
      terminal" environment, the most straightforward attack would be to
      simply replace the GUI front end, causing it to always report
      success to the user. I believe the general NEA model breaks in
      such an extremely insecure environment.
    * Sec. 6.2.1.2: I would expect such a policy-driven reassessment to
      be initiated by the server, rather than a client-based agent. This
      would also be more secure. Moreover, user interaction may not be
      appropriate in this scenario (or any other "reassessment"
      scenario), as there's nothing to guarantee that there's a person
      there.
    * Sec. 7: the WG certainly needs to define the attribute format, as
      well as a good number of attributes. Why are there no requirements
      on the format and the particular attributes?
    * PA-5 (security of PA protocol): security at this level is probably
      infeasible, especially if PB entities should be able to intercept
      PA messages (not just to mux and demux them). This is also related
      to the comment above regarding 1:1 correspondence between PC and PV.
    * PA-6: I propose to extend this requirement: The PA protocol MUST
      be capable of carrying *fully typed* attributes, including
      non-binary and binary data, large binary objects and encrypted
      content.
    * PA-*: there is also addressing at this level, why are there no
      related requirements? PA requirements should not be relegated to
      the PB section.
    * PB-*: I propose to add: PB MUST provide reliable flow control,
      ensuring that the failure of a single PC or PV does not impact
      other such components.
    * Sec. 7.4: this is implying we will end up with a single PT
      protocol, which quite magically can be embedded in IKE and 802.1X
      and also carried in raw form over TCP. This is very optimistic.
      There will probably be several PT *profiles* (for IKE and 802.1X,
      for example), and a similar but different protocol for running on
      UDP or TCP.
    * Sec. 8.1.3: this section should state whether there is trust
      between different PC components on a single client, and between
      different PV components on a server. This would influence the
      security requirements at the PA level.

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

---

From: Kaushik Narayan <[email-masked]>
Date: Thu, 20 Sep 2007 09:57:18 -0700

Hi Yaron,

Thanks for your comments. I haven¹t commented on your editorial suggestions,
we will review the relevant text in light of your editorial suggestions and
update appropriately

Please find my reply inline.

<snipped>
> 
>     
> Sec. 2: Sessions should be in the scope of the requirements if they are
> relevant to the integrity (security) of the exchange. For example if the
> protocol is susceptible to message reordering. See last sentence of Sec.
> 8.1.3. 
> 
> <Kaushik> 
> 
> The term session is used in this document to represent the context shared
> between the Posture Broker Client and Posture Broker Server.  The requirements
> leave it to the PB protocol design to define the specifics of the context
> shared at the PB layer and the security implications of a ³session² at the PB
> layer won¹t be clear unless the specifics of the session are defined. You are
> right in pointing out that Section 8.1.3 talks about protection of sessions
> but the real intent of that text is to indicate the need for end-to-end
> security between the PA & PB layers in the event the NEA server side
> components are not co-located.  We will edit text in section 8.1.3 to clarify
> the usage of the term session.
> 
> </Kaushik>
> 
> 
> * Sec. 2: "Owner" - the language is a bit convoluted. "The legal, rightful
> possessor", followed by "even if the asset is not within the owner's
> possession". 
> * Sec. 3.1: the first (positive) part of the Scope should be normative, since
> it sets the stage for the more detailed Sec. 7. Use stronger language, rather
> than "the WG intends".

> * Sec. 3.1: even if PT is/are defined in other workgroups, a NEA-specific PT
> profile may be specified within NEA for some particular PT protocol(s). It
> would be clearer to say that NEA prefers to use existing protocols for PT
> (this is in fact mentioned elsewhere).

           <Kaushik>

            I am not sure about the NEA-specific PT profile since that might
depend on the specific transport protocol in question. You have a valid
point regarding the lack of text to
            indicate that we plan to use existing protocols for PT although
the examples in several sections (including PT requirements in section 7.4)
call out existing protocols such as TLS, EAP etc. .
            We will edit the text in section 3.1 to make this clear.

             </Kaushik>

> * General: the word "privacy" is used quite liberally throughout the document.
> In most cases when it is used, the problem is much more that of security
> exposure than of privacy, in the usual sense of the word. Most people would
> not consider their OS version and build number to be privacy sensitive, but
> this information is certainly security sensitive, since it allows an adversary
> to tailor an attack to the particular OS.

              <Kaushik>

             I think the term ³gateway access² refers to points of network
interconnect within an enterprise, for e.g. A branch office being connected
to the central office via a gateway device.

            </Kaushik>

> * Sec. 5: although the "vertical lines" are out of scope, it is important to
> note which ones are expected to be available to component developers.

            <Kaushik>

          Agreed, I am however not sure that this needs to be part of the
requirements document.
       
           </Kaushik>

> * Sec. 5: the paragraph about discovery is out of sync with the common 802.1X
> deployment. In that case, the client is not configured with the server
> address, it just talks to the enforcement point. On a different level, is
> there discussion on the discovery of protocol peers at the PA/PB layers?

           <Kaushik>
 
              Fair point. The reference model does not require the posture
transport to provide mechanisms for discovery, it is definitely simplifies
deployments if a particular PT provides such a
             capability, i.e. 802.1x as you point out. We will add text to
clarify this. The aren¹t any requirements for PA & PB peers to discover each
other.
                   
          </Kaushik>
                   
> * Sec. 5.1.1.2: there may be scenarios where the Posture Broker Client should
> receive remediation attributes and handle them itself, e.g. by restarting (or
> even installling) individual Posture Collectors.

             <Kaushik>
             
             Agreed. Doesn¹t the following text  from 5.1.1.2 capture that
³ The Posture Broker Client also handles the global assessment  decision
from the Posture Broker Server and may
             interact with  the user communicate the global assessment
decision and aid  in any necessary remediation steps.²
 
             </Kaushik>

> * General: the model is unclear on whether there is a 1:1 correspondence
> between PC and PV, or whether there may be one PV communicating with multiple
> PC etc. 

            <Kaushik>

           The model is not limited to a 1:1 between a PC & PV. Here is text
from Section 5.1.2.1 ³A Posture Validator is responsible for handling
Posture  Attributes from corresponding Posture
           Collector(s).  A Posture  Validator can handle Posture Attributes
from one or more Posture  Collector(s) and vice-versa.²

         </Kaushik>

> * General: it is assumed here that there is one global yes/no policy decision.
> But consider the following scenario: a computer is evaluated against two
> policies, a Contrator policy and an Employee policy. It is compliant to the
> first, and non-compliant to the second (and receives remediation
> instructions). The Posture Broker and/or the user may decide whether it wants
> to remediate its posture to be compliant with the stricter policy.

             <Kaushik>

          There is an assumption that the posture broker produces one global
assessment decision per assessment. This decision need not be a yes/no, it
could be a grade/state (from healthy to
          infected). The scenario you point out can be implemented by a
cascading set of assessments.

       </Kaushik>

> * Sec. 6.1.2.1: I wonder about this use case, since in a "shared terminal"
> environment, the most straightforward attack would be to simply replace the
> GUI front end, causing it to always report success to the user. I believe the
> general NEA model breaks in such an extremely insecure environment.

            <Kaushik>

              I agree that assessment in a shared environment is not
foolproof to attacks on the client. The example was to point out voluntary
assessment triggered by the user to protect the
            endpoint he is using. A slight variation to this example that
might be a student who is just back from using his laptop to browse in a
public network (kiosk)  & initiates an assessment
             before he connects to the university network to start his work.
  
        </Kaushik>

> * Sec. 6.2.1.2: I would expect such a policy-driven reassessment to be
> initiated by the server, rather than a client-based agent. This would also be
> more secure. Moreover, user interaction may not be appropriate in this
> scenario (or any other "reassessment" scenario), as there's nothing to
> guarantee that there's a person there.

              <Kaushik>

            The policy is defined on the server in this example, the client
agent is useful in detecting a change to the client configuration and
initiating a re-assessment; the only way this change can be detected by a
server-only solution is via periodic re-assessment. The user interaction may
be necessary to reset the non-compliant configuration, i.e. Turn on the
desktop firewall in this example.

   </Kaushik>

> * Sec. 7: the WG certainly needs to define the attribute format, as well as a
> good number of attributes. Why are there no requirements on the format and the
> particular attributes?

<Kaushik> This will be part of PA protocol specification. </Kaushik>

> infeasible, especially if PB entities should be able to intercept PA messages
> (not just to mux and demux them). This is also related to the comment above
> regarding 1:1 correspondence between PC and PV.

<Kaushik> I am not sure that PA-5 implies that all of the PA data will
enveloped; PA security must ensure that there is enough data in the clear to
allow for the PB layer to appropriately route the attribute messages. There
is also another thread on the WG mailing list that questions whether PA
security needs to be a MUST, do you have any input to that discussion ?
</Kaushik>

> * PA-6: I propose to extend this requirement: The PA protocol MUST be capable
> of carrying *fully typed* attributes, including non-binary and binary data,
> large binary objects and encrypted content.
<Kaushik> I would consider large binary objects & encrypted content as
examples of binary data, We would like to avoid additional text in normative
requirements unless it is necessary </Kaushik>

> * PA-*: there is also addressing at this level, why are there no related
> requirements? PA requirements should not be relegated to the PB section.
> * 
<Kaushik> We did not want to specify normative schemes for
addressing/identification at the PA layer in the requirements document since
it might be better to address that in PA protocol design. We do have text in
the reference model that provides guidance to protocol design. Here is the
text I am referring to ³Each Posture Validator will be associated with one
or more  identifiers that enable it to be the specified as the  destination
in a PA message.  The Posture Broker Server uses  this identifier to route
messages to this Validator.  This  identifier might be dynamic (e.g.
generated by the Posture   Broker Server at run-time during registration) or
more static   (e.g. pre-assigned to a Posture Validator at install-time and
passed to the Posture Broker Server during registration) or a   function of
the attribute messages the validator desires to  receive (e.g. message type
for subscription). </Kaushik>

> * PB-*: I propose to add: PB MUST provide reliable flow control, ensuring that
> the failure of a single PC or PV does not impact other such components.

<Kaushik> I am not sure whether failure of  a PC/PV creates any requirements
for the over-the-wire PB protocol between the NEA client and NEA server. Can
you elaborate on this ? </Kaushik>

> * Sec. 7.4: this is implying we will end up with a single PT protocol, which
> quite magically can be embedded in IKE and 802.1X and also carried in raw form
> over TCP. This is very optimistic. There will probably be several PT
> *profiles* (for IKE and 802.1X, for example), and a similar but different
> protocol for running on UDP or TCP.
<Kaushik> A mandatory to implement PT is mandated by the WG charter. I agree
that NEA protocols realistically will need to utilize multiple PTs but I
guess the first step is to define the NEA with one specific PT protocol
</Kaushik> 

> * Sec. 8.1.3: this section should state whether there is trust between
> different PC components on a single client, and between different PV
> components on a server. This would influence the security requirements at the
> PA level. 

<Kaushik> The PV and PC components are expected to be independent, this
probably needs to be clarified in Section 8.1 </Kaushik>

Regards,
  kaushik