Subject: RE: [Nea] RE: Should we downgrade PA security to a SHOULD, MAY or remove it?

From: <[email-masked]>
Date: Mon, 17 Sep 2007 16:54:19 -0700

Hello Paul,

Parvez and I have been thinking about this quite a bit, especially since
discussing the requirements of PT mutual authentication with Kaushik,
which has lead us to quite a bit of trust model analysis.

Our PA-5 response is inline.  We will be commenting separately on the
PB/PT trust relationship which is germane to the PT mutual
authentication discussion thread.

> Date: Sat, 15 Sep 2007 13:29:20 -0700
> From: "Paul Sangster" <[email-masked]>
> Subject: [Nea] RE: Should we downgrade PA security to a 
> SHOULD,	MAY or
> 	remove it?
> To: <[email-masked]>
> Message-ID:
> 	
> <[email-masked]
> rise.veritas.com>
> 	
> Content-Type: text/plain; charset="us-ascii"
> 
> Unfortunately, this thread has failed to have traction.  
> Since we currently have a MUST for PA security would someone like to 
> assert that this MUST should be lowered and provide some rationale to 
> start this discussion?
> 

We'll take a stab at asserting PA-5 should be a [MUST].  Here is our
argument. 

Unfortunately, we've come to the group late in the requirements game and
thus didn't participate in the Prague discussions and as such don't have
the context that lead to the downgrading of PB authentication and
shifting all of this responsibility to PT and PA respectively. However,
we think the most important question is how does the trust model work.  

If a PV does not utilize PA authentication then it implicitly is relying
upon the PB protocol and/or the PT protocol for authentication of its
associated PC. Such transitive trust is possible in use cases where a
NEA Client can provide assurances on the authenticity of the PCs it
hosts, such as in systems with immutable software images. However, for
use cases where such assurances can't be made, such as when PCs can be
installed on systems for which the PB Client can't ascertain
authenticity in behalf of the PV, the transitive trust relationship
breaks down. Given such use cases exist, we don't see how PA-5
authentication can be dropped. In fact, thinking about this more, it
occurs to us that the minimum trust model required for NEA is PA-5 with
mutual authentication and trust between the PB Server and its associated
PVs via a (out of WG scope) secure interface.  Our rationale for this
assertion is, if each PV/PC combination has a cryptographically sound
communication channel, then it isn't possible for a PB Client, or PT
stack to spoof said messages and if PB Server has a secure trusted
relationship with each PV, then PB Server can rely entirely on
assertions from the PV's in composing the complete end point posture
state.
We're not advocating this minimalist model as the only trust
requirements, just stating we think it is the minimum set of trust
requirements.

Now comes the semantic fun.  What is the meaning of [MUST], [SHOULD] and
[MAY] in the context of PA-5?  Our assertion is PA-5 is a protocol
requirement and as such, given our assertion there is a need for PA-5
mutual authentication, then the PA protocol [MUST] be capable of
providing mutual authentication.  Since, the need for mutual
authentication is use case dependent, we assert implementation of it is
an optional requirement and therefore think a [MAY] implementation
requirement is appropriate to consider in the forthcoming PA protocol
RFC work.

[omitted]

Regards,

Gary

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

---

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Mon, 17 Sep 2007 20:43:51 -0700

Hi Gary,

Comments inline. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Monday, September 17, 2007 4:54 PM
> To: [email-masked]; [email-masked]
> Subject: RE: [Nea] RE: Should we downgrade PA security to a 
> SHOULD,MAY or remove it?
> 
> Hello Paul,
> 
> Parvez and I have been thinking about this quite a bit, 
> especially since discussing the requirements of PT mutual 
> authentication with Kaushik, which has lead us to quite a bit 
> of trust model analysis.
> 
> Our PA-5 response is inline.  We will be commenting 
> separately on the PB/PT trust relationship which is germane 
> to the PT mutual authentication discussion thread.
> 
> We'll take a stab at asserting PA-5 should be a [MUST].  Here 
> is our argument. 
> 
> Unfortunately, we've come to the group late in the 
> requirements game and thus didn't participate in the Prague 
> discussions and as such don't have the context that lead to 
> the downgrading of PB authentication and shifting all of this 
> responsibility to PT and PA respectively. However, we think 
> the most important question is how does the trust model work.  
> 
> If a PV does not utilize PA authentication then it implicitly 
> is relying upon the PB protocol and/or the PT protocol for 
> authentication of its associated PC. Such transitive trust is 
> possible in use cases where a NEA Client can provide 
> assurances on the authenticity of the PCs it hosts, such as 
> in systems with immutable software images. However, for use 
> cases where such assurances can't be made, such as when PCs 
> can be installed on systems for which the PB Client can't 
> ascertain authenticity in behalf of the PV, the transitive 
> trust relationship breaks down. Given such use cases exist, 

[Joe] OK, but its not clear to that if the NEA client cannot provide
assurances of authenticity for its host that the PC will be a better
place to root trust than the PB or PT.  It would seem that in many
architectures the PT and/or PB will run with higher privilege than the
PC.  

> we don't see how PA-5 authentication can be dropped. In fact, 
> thinking about this more, it occurs to us that the minimum 
> trust model required for NEA is PA-5 with mutual 
> authentication and trust between the PB Server and its 
> associated PVs via a (out of WG scope) secure interface.  Our 
> rationale for this assertion is, if each PV/PC combination 
> has a cryptographically sound communication channel, then it 
> isn't possible for a PB Client, or PT stack to spoof said 
> messages and if PB Server has a secure trusted relationship 
> with each PV, then PB Server can rely entirely on assertions 
> from the PV's in composing the complete end point posture state.
> requirements, just stating we think it is the minimum set of 
> trust requirements.
> 
> Now comes the semantic fun.  What is the meaning of [MUST], 
> [SHOULD] and [MAY] in the context of PA-5?  Our assertion is 
> PA-5 is a protocol requirement and as such, given our 
> assertion there is a need for PA-5 mutual authentication, 
> then the PA protocol [MUST] be capable of providing mutual 
> authentication.  Since, the need for mutual authentication is 
> use case dependent, we assert implementation of it is an 
> optional requirement and therefore think a [MAY] 
> implementation requirement is appropriate to consider in the 
> forthcoming PA protocol RFC work.
> 
[Joe] In looking at the complexity of managing keys and cryptography at
the PA I think most deployments will opt for managing trust at the PB or
PT layer.  I would rather see the working group focus on things that
will be deployed as a higher priority requirement.

---

From: <[email-masked]>
Date: Fri, 21 Sep 2007 16:46:35 -0700

Hi Joseph,

[PA] Comment inline.

Thanks,
Parvez

-----Original Message-----
From: Joseph Salowey (jsalowey) [mailto:[email-masked]] 
Sent: Monday, September 17, 2007 8:44 PM
To: Gary Tomlinson; [email-masked]; [email-masked]
Subject: RE: [Nea] RE: Should we downgrade PA security to a SHOULD,MAY
or remove it?

Hi Gary,

Comments inline. 

[PA] Gary and I agree with you that most deployments will opt for
managing trust at the PT layer. We still think that the PA protocol must
be capable of providing cryptographic security for at least the
following two reasons. First, a vendor may provide a combined solution
of a Posture Validator and a Posture Collector; they may want the
collected posture data to be opaque, to protect their intellectual
property. Second, without the possibility of using cryptography at the
PA layer, the "vertical lines" (the API lines, as opposed to the
horizontal protocol lines) need to provide strong security guarantees.
On some operating systems, this may be reasonable, but on others, these
guarantees might be non-existent or very difficult to implement. For
these reasons, we think that the PA layer should support the PA-5 [MUST]
for those who have no option but to rely on it.

---

From: "Hao Zhou \(hzhou\)" <[email-masked]>
Date: Tue, 25 Sep 2007 09:52:34 -0400

> [PA] Gary and I agree with you that most deployments will opt 
> for managing trust at the PT layer. We still think that the 
> PA protocol must be capable of providing cryptographic 
> security for at least the following two reasons. First, a 
> vendor may provide a combined solution of a Posture Validator 
> and a Posture Collector; they may want the collected posture 
> data to be opaque, to protect their intellectual property. 
> Second, without the possibility of using cryptography at the 
> PA layer, the "vertical lines" (the API lines, as opposed to 
> the horizontal protocol lines) need to provide strong 
> security guarantees.
> On some operating systems, this may be reasonable, but on 
> others, these guarantees might be non-existent or very 
> difficult to implement. For these reasons, we think that the 
> PA layer should support the PA-5 [MUST] for those who have no 
> option but to rely on it.

A vendor can still provide cryptographic security using vendor specific
attribute if they want to. They can define their own key management
scheme and framework. Do we really want to mandate PA protocol to
support cryptographic security, only for a very small percentage of the
use cases, where PA is from one vendor and PA validator is from another
vendor? 

My vote is [SHOULD] at most, to allow WG to focus on high priority
requirements.

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Friday, September 21, 2007 7:47 PM
> To: [email-masked]
> SHOULD,MAY 
> > Parvez and I have been thinking about this quite a bit, especially 
> > since discussing the requirements of PT mutual authentication with 
> > Kaushik, which has lead us to quite a bit of trust model analysis.
> > 
> separately on the 
> requirements game 
> > and thus didn't participate in the Prague discussions and as such 
> > don't have the context that lead to the downgrading of PB 
> > authentication and shifting all of this responsibility to PT and PA 
> > respectively. However, we think the most important question is how 
> > does the trust model work.
> > 
> > If a PV does not utilize PA authentication then it implicitly is 
> > relying upon the PB protocol and/or the PT protocol for 
> authentication 
> > of its associated PC. Such transitive trust is possible in 
> use cases 
> > where a NEA Client can provide assurances on the 
> authenticity of the 
> > PCs it hosts, such as in systems with immutable software images. 
> > However, for use cases where such assurances can't be made, such as 
> > when PCs can be installed on systems for which the PB Client can't 
> > ascertain authenticity in behalf of the PV, the transitive trust 
> > relationship breaks down. Given such use cases exist,
> 
> [Joe] OK, but its not clear to that if the NEA client cannot 
> provide assurances of authenticity for its host that the PC 
> will be a better place to root trust than the PB or PT.  It 
> would seem that in many architectures the PT and/or PB will 
> run with higher privilege than the PC.  
> 
> > we don't see how PA-5 authentication can be dropped. In 
> fact, thinking 
> > about this more, it occurs to us that the minimum trust 
> model required 
> > for NEA is PA-5 with mutual authentication and trust between the PB 
> > Server and its associated PVs via a (out of WG scope) secure 
> > interface.  Our rationale for this assertion is, if each PV/PC 
> > combination has a cryptographically sound communication 
> channel, then 
> > it isn't possible for a PB Client, or PT stack to spoof 
> said messages 
> > and if PB Server has a secure trusted relationship with 
> each PV, then 
> > PB Server can rely entirely on assertions from the PV's in 
> composing 
> > the complete end point posture state.
> [SHOULD] 
> > and [MAY] in the context of PA-5?  Our assertion is
> assertion there 
> > is a need for PA-5 mutual authentication, then the PA 
> protocol [MUST] 
> > be capable of providing mutual authentication.  Since, the need for 
> > mutual authentication is use case dependent, we assert 
> implementation 
> > of it is an optional requirement and therefore think a [MAY] 
> [Joe] In looking at the complexity of managing keys and 
> cryptography at the PA I think most deployments will opt for 
> managing trust at the PB or PT layer.  I would rather see the 
> working group focus on things that will be deployed as a 
> higher priority requirement.  
> 
> 
> [PA] Gary and I agree with you that most deployments will opt 
> for managing trust at the PT layer. We still think that the 
> PA protocol must be capable of providing cryptographic 
> security for at least the following two reasons. First, a 
> vendor may provide a combined solution of a Posture Validator 
> and a Posture Collector; they may want the collected posture 
> data to be opaque, to protect their intellectual property. 
> Second, without the possibility of using cryptography at the 
> PA layer, the "vertical lines" (the API lines, as opposed to 
> the horizontal protocol lines) need to provide strong 
> security guarantees.
> On some operating systems, this may be reasonable, but on 
> others, these guarantees might be non-existent or very 
> difficult to implement. For these reasons, we think that the 
> PA layer should support the PA-5 [MUST] for those who have no 
> option but to rely on it.
> 
> 
> 
>

---

From: <[email-masked]>
Date: Tue, 25 Sep 2007 13:26:32 -0700

At this point, I think we agree in spirit but it's the exact wording
that worries me.

First, let me state an assumption that may not be universally held. I am
assuming that there is going to be a SINGLE PA protocol, a SINGLE PB
protocol and MULTIPLE PT protocols. The reason I make this assumption is
because I don't see the necessity of having several PA and PB protocols
that accomplish the exact same purpose; since these protocols will be
designed from scratch, a single one of each should suffice.

In particular, I am assuming that the unique PA protocol will carry BOTH
the standard attributes and the vendor proprietary attributes. Thus, the
unique PA protocol will support multiple attribute name spaces.

Now, given that there is a unique PA protocol, if the "MUST provide
authentication, integrity, and confidentiality" requirement for this
protocol is made into a "SHOULD provide authentication, integrity, and
confidentiality" requirement, it is left up to the WG that designs this
unique PA protocol to include this capability or not. While I think that
it SHOULD be left up to the user of the protocol whether to employ this
capability, the unique PA protocol "MUST provide" this capability in
order for the user to have this choice.

I apologize for belaboring the point but this is a very important
requirement and I'd like to make sure I understand the implications.

Thanks,
Parvez Anandam

-----Original Message-----
From: Hao Zhou (hzhou) [mailto:[email-masked]] 
Sent: Tuesday, September 25, 2007 6:53 AM
To: Parvez Anandam; [email-masked]
Subject: RE: [Nea] RE: Should we downgrade PA security to a SHOULD,MAY
or remove it?