Subject: [Nea] Comments on draft-ietf-nea-requirements-03.txt

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Fri, 10 Aug 2007 17:00:16 -0700

In general the document looks pretty good, but I do have a few comments.

Comments on Section 2

- I expected to see a term along the lines of "Network Endpoint
Assessment Authority."  This is the entity who is trusted to perform the
endpoint assessment.  This is often related to the device owner in that
it is either specific entities that are part of the device owner or a
third party that has been delegated the authority to perform assessment
by the device owner.  

Comments on Section 3

- Is the case where an device is owned by an individual who contracts
out compliance assessment to a third party in scope?

Comment on Section 5

Section 5.1.1.1

- The last paragraph is asking the reader to "Recall that this is not a
set of requirements for what each Posture Collector implementation must
support."  Where is the reader recalling this from?  Also does this
apply to the other sections.

Section 5.1.1.1,2,3

- 5.1.1.1 and 5.1.1.3 describe cryptographic protection at the
transport, the collector, why wouldn't the broker be able to provide
cryptographic protection as well?  What are the goals of the
cryptographic protection cited?

Section 5.2.1

- Is the application of cryptographic protection a matter of policy as
in 5.2.3?

Section 6

Section 6.1.1.x

- In this case it is not clear when network access is given or not, or
really what it means to have network access.  It is also not clear that
the NEA client itself would the component that requests network access. 

Section 7

- C-5 - It seems that it might be advantageous for the PA and PB
protocols to have knowledge of which transport they are running over.
This may help in determining which mode from c-10 to run in.  

- PA-6 - It seems that different posture collectors may use different
mechanisms to protect their attributes based on there requirements
necessary to protect their data and the type of security relationship
their components have.  Is it necessary to specify protection at this
layer?  These different layers of cryptography introduce complexities
around key management suggest multiple trust relationships.  

- PT-6 What does "This MAY occur by leveraging by-products (e.g., keys)
supplied by the PB protocol authentication." mean and is it important at
this level of requirements.  

Section 8 

- Section 8.1 - the discussion of trust left me a bit unsatisfied.
There are lots of components (PC,PV,etc.) in the NEA system that have
the requirement for a cryptographic basis for trust.  This section
glosses over trust between components in favor of discussing a NEA
Client and NEA Server. Since the document treats these as composed of
separate components with apparently their own trust relationships the
should be discussed in this section.

Section 9 

- Just a comment that there may be benefit to the endpoint user to have
their compliance checked,  NEA should be as much about protecting the
end point rather than protecting the client.  Most of the document seems
OK with the respect, but it something to keep in mind. 

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

---

From: "Paul Sangster" <[email-masked]>
Date: Tue, 14 Aug 2007 15:41:19 -0700

Thanks for the comments on the draft, some feedback is in-lined... 

> -----Original Message-----
> From: Joseph Salowey (jsalowey) [mailto:[email-masked]] 
> Sent: Friday, August 10, 2007 5:00 PM
> To: [email-masked]
> Subject: [Nea] Comments on draft-ietf-nea-requirements-03.txt
> 
> - I expected to see a term along the lines of "Network 
> Endpoint Assessment Authority."  This is the entity who is 
> trusted to perform the endpoint assessment.  This is often 
> related to the device owner in that it is either specific 
> entities that are part of the device owner or a third party 
> that has been delegated the authority to perform assessment 
> by the device owner.  

I presume by "device owner" your referring to the owner of the endpoint
(device being assessed).  Would you envision this authority being
someone other than the NEA Server for this document?  We discuss the
trust relationships in section 8.1 and I suspect the NEA Server is
fulfilling the role your describing.

Did the lack of a term take away from readibility of the document?

> 
> Comments on Section 3
> 
> - Is the case where an device is owned by an individual who 
> contracts out compliance assessment to a third party in scope?

No, our scope is pretty narrow as dictated by our charter.  Section 3.2
paragraph 2 and 3 discusses the scope regarding ownership of the
endpoint (device) vs. the network which is primarily about when both the
endpoint and network are owned by the same entity.

> 
> Comment on Section 5
> 
> Section 5.1.1.1
> 
> - The last paragraph is asking the reader to "Recall that 
> this is not a set of requirements for what each Posture 
> Collector implementation must support."  Where is the reader 
> recalling this from?  Also does this apply to the other sections.

Will fix the text (recall isn't the best word).  I'll review the other
NEA component descriptions to see if a similar note is required.  Its
particularly important for the collector and validator where we expect
many to exist and likely be pretty simple so not every responsibility
listed may be applicable.

> 
> Section 5.1.1.1,2,3
> 
> - 5.1.1.1 and 5.1.1.3 describe cryptographic protection at 
> the transport, the collector, why wouldn't the broker be able 
> to provide cryptographic protection as well?  What are the 
> goals of the cryptographic protection cited?

Each layer provides different cryptographic security services.  The PA
layer security is providing true end to end protection even when the
Posture Validator is located on a different system then the Posture
Broker Server.  This enables the end Posture Validator to
cryptographically authenticate the Posture Collector and even provide
private (encrypted) messages spanning multiple systems.  This mentioned
later in the document and in requirement PA-5 but we could make it more
clear if you think it would help.
 
> 
> Section 5.2.1
> 
> - Is the application of cryptographic protection a matter of 
> policy as in 5.2.3?

Yes, we talk about this in section 8.2.

> 
> Section 6
> 
> Section 6.1.1.x
> 
> - In this case it is not clear when network access is given 
> or not, or really what it means to have network access.  It 
> is also not clear that the NEA client itself would the 
> component that requests network access. 

Not sure I follow.  For example, in 6.1.1.x it's the last sentence of
the last paragraph of 6.1.1.1 and step 16 in 6.1.1.2.  Does this need to
be more clear or were you referring to something to something else.  

I agree its possible the NEA client doesn't necessarily directly request
network access but it would be tied into the sequence of events during
the entrance to the network.  We expect their may be lower layer
protocols below the NEA client that might directly request network
access.  One might argue they are part of the carrier protocol which we
define to be part of PT (in the NEA Client) but some portion may be
below it without damaging the model.

> 
> Section 7
> 
> - C-5 - It seems that it might be advantageous for the PA and 
> PB protocols to have knowledge of which transport they are 
> running over.

Agreed.  We're reworded C-5 which should help as it might be helpful for
PA/PB to know information about bandwidth, MTU, latency in order to
optimize its payload sizes.  We didn't want the PA or PB message formats
to change for different PT protocols.  Its now says:

"The PA and PB protocols MUST be capable of operating over any PT
protocol." The 2nd sentence remains as it was.

> 
> - PA-6 - It seems that different posture collectors may use 
> different mechanisms to protect their attributes based on 
> there requirements necessary to protect their data and the 
> type of security relationship their components have.  Is it 
> necessary to specify protection at this layer?  These 
> different layers of cryptography introduce complexities 

The PA candidate protocols will specify how they provide these
cryptographic protections to attributes if desired by a
collector/validator.  I'm not sure about 'different mechanisms' as they
will all use what ever the PA protocol the NEA WG selects offers.  The
WG did discuss the cryptography at multiple layers issue a few times
most recently in Prague and agreed we wanted support for end to end
security even when the Posture Validator was remote from the Posture
Broker Server.  (We did however downgrade the PB protocol to a MAY for
having to provide such cryptographic mechanisms).
 
> 
> - PT-6 What does "This MAY occur by leveraging by-products 
> (e.g., keys) supplied by the PB protocol authentication." 
> mean and is it important at this level of requirements.

This text was removed from the next version of the I-D, but it used to
refer to cryptographic binding between protocol layers by exposing
by-products (derived) keying material to higher layers (also might be
nice for channel binding if desired).  The text is now gone based on
other feedback.  Of course candidate protocols may offer this feature.
  
> There are lots of components (PC,PV,etc.) in the NEA system 
> that have the requirement for a cryptographic basis for 
> trust.  This section glosses over trust between components in 
> favor of discussing a NEA Client and NEA Server. Since the 
> document treats these as composed of separate components with 
> apparently their own trust relationships the should be 
> discussed in this section.

Not sure how to address your comment.  Do you have any proposed text or
even specific boundaries to make this more clear?  I'm not opposed to
doing this particularly if it's a key trust boundary.  The trust section
focuses on the key boundaries between components where trust is
essential.  We didn't focus on trust issues between some components that
we expected (or even assumed by charter) to be co-located.

> 
> Section 9 
> 
> - Just a comment that there may be benefit to the endpoint 
> user to have their compliance checked,  NEA should be as much 
> about protecting the end point rather than protecting the 
> client.  Most of the document seems OK with the respect, but 
> it something to keep in mind. 

Agree, so you suggesting we highlight this elsewhere in the spec (since
its not a privacy topic)?  We did try to mention this including in use
case example section 6.1.2.1.

---

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Wed, 22 Aug 2007 22:32:18 -0700

Hi Paul, 

Inline below: 

> From: Paul Sangster [mailto:[email-masked]] 
> Sent: Tuesday, August 14, 2007 3:41 PM
> To: Joseph Salowey (jsalowey); [email-masked]
> Subject: RE: [Nea] Comments on draft-ietf-nea-requirements-03.txt
> 
> > Assessment Authority."  This is the entity who is trusted 
> to perform 
> > the endpoint assessment.  This is often related to the 
> device owner in 
> > that it is either specific entities that are part of the 
> device owner 
> > or a third party that has been delegated the authority to perform 
> > assessment by the device owner.
> 
> I presume by "device owner" your referring to the owner of 
> the endpoint (device being assessed).  Would you envision 
> this authority being someone other than the NEA Server for 
> this document?  We discuss the trust relationships in section 
> 8.1 and I suspect the NEA Server is fulfilling the role your 
> describing.
> 
[Joe] I had envisioned the NEA server being the authority, however I'm
not sure that the rest of the document supported this.  There seems to
be many trust relationships involved. 

> contracts 
> No, our scope is pretty narrow as dictated by our charter.  
> Section 3.2 paragraph 2 and 3 discusses the scope regarding 
> ownership of the endpoint (device) vs. the network which is 
> primarily about when both the endpoint and network are owned 
> by the same entity.
> 
[Joe] OK

> this is not 
> > a set of requirements for what each Posture Collector 
> implementation 
> > must support."  Where is the reader recalling this from?  Also does 
> > this apply to the other sections.
> 
> Will fix the text (recall isn't the best word).  I'll review 
> the other NEA component descriptions to see if a similar note 
> is required.  Its particularly important for the collector 
> and validator where we expect many to exist and likely be 
> pretty simple so not every responsibility listed may be applicable.
> 
> > 
> > Section 5.1.1.1,2,3
> > 
> Each layer provides different cryptographic security 
> services.  The PA layer security is providing true end to end 
> protection even when the Posture Validator is located on a 
> different system then the Posture Broker Server.  This 
> enables the end Posture Validator to cryptographically 
> authenticate the Posture Collector and even provide private 
> (encrypted) messages spanning multiple systems.  This 
> mentioned later in the document and in requirement PA-5 but 
> we could make it more clear if you think it would help.
>  
[Joe] This is where I get worried.  This is requiring a trust
relationship between each posture validator and posture collector.  Is
this really necessary.  This is introducing a lot of trust management
and key management issues that are not well discussed in the rest of the
document.  I would expect that mot deployable solutions would require
cryptographic protection of the transport or at the broker.  I think
requiring standardized protection at this layer introduces a lot of
complexity and I'm not exactly sure how it would help.  

> or not, or 
> > really what it means to have network access.  It is also not clear 
> > that the NEA client itself would the component that 
> requests network 
> > access.
> 
> Not sure I follow.  For example, in 6.1.1.x it's the last 
> sentence of the last paragraph of 6.1.1.1 and step 16 in 
> 6.1.1.2.  Does this need to be more clear or were you 
> referring to something to something else.  
> 
> I agree its possible the NEA client doesn't necessarily 
> directly request network access but it would be tied into the 
> sequence of events during the entrance to the network.  We 
> expect their may be lower layer protocols below the NEA 
> client that might directly request network access.  One might 
> argue they are part of the carrier protocol which we define 
> to be part of PT (in the NEA Client) but some portion may be 
[Joe] OK, I think I understand.  However it seems to me that in step 13
the client is downloading patches, etc. while they are not connected to
the network.  How is this supposed to happen?  

> Agreed.  We're reworded C-5 which should help as it might be 
> helpful for PA/PB to know information about bandwidth, MTU, 
> latency in order to optimize its payload sizes.  We didn't 
> want the PA or PB message formats to change for different PT 
> protocols.  Its now says:
> 
> "The PA and PB protocols MUST be capable of operating over 
> any PT protocol." The 2nd sentence remains as it was.
> 
[Joe] OK, sounds good. 

> different 
> The PA candidate protocols will specify how they provide 
> these cryptographic protections to attributes if desired by a 
> collector/validator.  I'm not sure about 'different 
> mechanisms' as they will all use what ever the PA protocol 
> the NEA WG selects offers.  The WG did discuss the 
> cryptography at multiple layers issue a few times most 
> recently in Prague and agreed we wanted support for end to 
> end security even when the Posture Validator was remote from 
> the Posture Broker Server.  (We did however downgrade the PB 
> protocol to a MAY for having to provide such cryptographic 
> mechanisms).
>  
[Joe] As I stated above, I don't think this is a good approach.  You are
requiring key management and associated trust relationships above the
NEA server level.  This introduces multiple authorities and the need to
manage them.  I think this adds a lot of complexity.  In most of the
rest of the document you describe relationships between the NEA client
and NEA server.  I think this is more manageable.  Requiring
cryptography at the PA layer introduces  requirements that are not
discussed in this document. 

> > 
> > - PT-6 What does "This MAY occur by leveraging by-products (e.g., 
> > keys) supplied by the PB protocol authentication."
> This text was removed from the next version of the I-D, but 
> it used to refer to cryptographic binding between protocol 
> layers by exposing by-products (derived) keying material to 
> higher layers (also might be nice for channel binding if 
> desired).  The text is now gone based on other feedback.  Of 
> course candidate protocols may offer this feature.
>   
[Joe] OK

> that have 
> Not sure how to address your comment.  Do you have any 
> proposed text or even specific boundaries to make this more 
> clear?  I'm not opposed to doing this particularly if it's a 
> key trust boundary.  The trust section focuses on the key 
> boundaries between components where trust is essential.  We 
> didn't focus on trust issues between some components that we 
> expected (or even assumed by charter) to be co-located.
> 

[Joe] Unfortunately the rest of the document introduces trust
relationships between these components.  I really would rather see this
section as it is, but it does not reflect what comes before.  

> > 
> > Section 9
> > 
> > - Just a comment that there may be benefit to the endpoint user to 
> > have their compliance checked,  NEA should be as much about 
> protecting 
> > the end point rather than protecting the client.  Most of 
> the document 
> > seems OK with the respect, but it something to keep in mind.
> 
> Agree, so you suggesting we highlight this elsewhere in the 
> spec (since its not a privacy topic)?  We did try to mention 
> this including in use case example section 6.1.2.1.
> 
{Joe] Yes, this was really just a rant.  Section 6.1.2.1 does cover
this.