Subject: [Nea] PB Trust Model Authentication

From: <[email-masked]>
Date: Fri, 21 Sep 2007 15:44:12 -0700

Sorry to not have posted this comment sooner, but Parvez and I have had
to think long and hard prior to posting. This comment is in part a
continuation from the trust model discussions regarding the requirement
for PA-5 and in part a discussion of mutual authentication of PT-2 in a
previous thread with Kaushik.

The discussion here is, which NEA component is central to the entire
trust model? Parvez and I assert the PB Server is the center of the
trust model as it is responsible for brokering all of the posture
assessments and by extension must provide assurances of posture state to
the network enforcement and network auditing machinery. Conversely, the
PB Client has a duality role, it must represent the interests of both
the NEA server in determining posture but also must protect the privacy
of the user.  As such, one could argue it is equally eligible as the
center of the trust model.  However, given the NEA mission is for
network security and the NEA Server acts entirely in the interests of
the network operator, we conclude it is the true center. As described in
the previous trust model comments regarding PA-5, the minimalist trust
model could involve just a direct trust between the PB Server and its
registered PVs and rely transitively on strong cryptography present in
the PA protocol between the PVs and their PCs.  In practice however,
this simple model isn't likely to be realized for a majority of use
cases due in part to key distribution complexities of PV/PC pairs, PB
Client trust of PB Server for authorized disclosures and run time
environments which preclude PB Client from ascertaining the authenticity
of PC code via an out of scope interface as illustrated in figure 1.
Given these impracticalities, it suggests a strong trust relationship
between PB Server and PB Client is necessary.  Given this need for such
PB mutual Trust, the question becomes should the PB protocol provide its
own authentication, confidentiality and integrity via requirement PB-5
or rely transitively on the PT protocol for mutual authentication of the
PB Server and PB Client credentials? We don't see a practical need for
both the PB (PB-5) and the PT (PT-2) to provide redundant services as
either can be employed to meet the trust relationship and thus think the
WG needs to make a choice on one or the other but not both in order to
simplify the complexities of PB/PT protocol stack requirements.

Heretofore our comments on PT-2 have been based on the assumption a
mixed model was needed in many TLS deployments where PB did its own
authentication and relied on PT (TLS) for confidentiality and integrity.
This seemed natural to us as common practice in SSL VPNs has been for
server side only authentication and upper level protocols doing the
authentication.  However, we've reconsidered our position after
examining available key distribution mechanisms and believe requiring
Mutual authentication for TLS is acceptable. With this in mind, we
retract our previous comments on
PT-2 and would prefer the WG simplify the PB protocol requirements and
rely entirely on PT-2 for PB cryptographic message dialogue; and
additionally request the elimination of requirement PB-5.  

We still stand by our comments on PA-5 (separate thread) as there are
use cases where the PB Client can't establish sufficient authenticity of
PCs to enable the PB Server to establish transitive trust with the PVs.
However, we do think there are many use cases where it will be possible
to rely entirely on the PT for all cryptographic support including PA
without any the need for optionally employing PA-5 and that this will be
a common deployment.

Regards,
Gary

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

---

From: Kaushik Narayan <[email-masked]>
Date: Mon, 24 Sep 2007 17:39:36 -0700

Hi Gary,

I just want to confirm my reading of your assessment of the NEA security
requirements

1. The mutual authentication requirements in PT-2 are fine and PT-2 should
be sufficient to provide security for most common deployments of NEA.

2. You are in favor of changing PA-5 from a MUST to a SHOULD to simplify key
management for the PA protocol.

regards,
 kaushik

On 9/21/07 3:44 PM, "[email-masked]" <[email-masked]>
wrote:

> trust model? Parvez and I assert the PB Server is the center of theHi G

---

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

Hi Kaushik,

> -----Original Message-----
> From: Kaushik Narayan [mailto:[email-masked]] 
> Sent: Monday, September 24, 2007 5:40 PM
> To: Gary Tomlinson; [email-masked]
> Subject: Re: [Nea] PB Trust Model Authentication
> 
> Hi Gary,
> 
> I just want to confirm my reading of your assessment of the 
> NEA security requirements
> 
> 1. The mutual authentication requirements in PT-2 are fine 
> and PT-2 should be sufficient to provide security for most 
> common deployments of NEA.

<Gary>
Yes, PT-2 is sufficient as specified.
</Gary>
> 
> 2. You are in favor of changing PA-5 from a MUST to a SHOULD 
> to simplify key management for the PA protocol.

<Gary>
I think configuration of PA-5 at a site is optional and thus would be
a MAY in RFC parlance. However, as a requirement capability for a
standardized 
protocol to provide I see it as a MUST as the optional behavior is not
for the 
protocol developers but rather a policy of either a vendor or a network
operator.
This is why I stated PA-5 is MUST for the requirements RFC and a MAY
configuration 
requirement for the PA protocol RFC. However, the more I think about it,
I think
PA-5 can be reduced to just authentication as I'm pretty sure
confidentiality and
integrity can always be met with PT-2. I find the semantics of MUST,
SHOULD, MAY tricky
between requirements of protocols and guidance to utilization of
protocol capabilities.
We could add in guidance to PA-5 stating its use should be employed when
authentication
of PCs can't be guaranteed by PB Client. Does this make sense? 
</Gary>

>  kaushik

Regards
Gary