Proposed F19 Feature: Trusted Network Connect (TNC)

[Jaroslav Reznik]

= Features/Trusted Network Connect (TNC) =
https://fedoraproject.org/wiki/Features/Trusted_Network_Connect_%28TNC%29

Feature owner(s): Avesh Agarwal <avagarwa(a)redhat.com&gt; 

This feature provides Trusted Network Connect(TNC) framework that can be used 
to assess and verify clients' posture (or integrity measurements or 
configuration) and its compliance to a predefined policy with existing network 
access control (NAC) solutions.

== Detailed description ==
Traditionally network access control (NAC) has lacked the ability in its 
decision making to asses endpoint's security posture and its compliance to 
enterprise policies. This lack of assessment may leave an enterprise's network 
vulnerable to malicious attacks. Trusted Computing Group (TCG) (and IETF too) 
has defined an open architecture called Trusted network connect (TNC) (IETF's 
Network Endpoint Assessment (NEA)) to fill this gap. TNC, as part of its 
architectural components, includes integrity measurement collectors (IMCs) and 
TNC client at endpoint and integrity measurement verifiers (IMVs) and TNC 
server at enterprise network side communicating over NAC solutions such as EAP 
with 802.1X to evaluate and verify the security posture of the endpoint 
against the enterprise policies before allowing network access. For this, TCG 
has released transport (IF-T), session (IF-TNCCS) and messaging (IF-M) 
standards which are open and interoperable. TNC architecture by virtue of it's 
IF-M protocol can leverage NIST's SCAP's (OpenSCAP) automated security aspects 
for measurement collection, verification and remediation. In addition, TCG has 
defined IF-PTS and PTS protocol specifications to integrate platform trust 
services (PTS) with TNC for TPM based attestation of integrity measurements. 
PTS protocol defines messaging payloads to be used over IF-M protocol.

This feature includes the aforementioned functionalities and aims to provide 
an end-to-end network based client assessment, verification and remediation. 
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

[Bill Nottingham]

Jaroslav Reznik (jreznik(a)redhat.com) said: 
>  = Features/Trusted Network Connect (TNC) =
>  https://fedoraproject.org/wiki/Features/Trusted_Network_Connect_%28TNC%29
>  
>  Feature owner(s): Avesh Agarwal <avagarwa(a)redhat.com&gt; 
>  
>  This feature provides Trusted Network Connect(TNC) framework that can be used 
>  to assess and verify clients' posture (or integrity measurements or 
>  configuration) and its compliance to a predefined policy with existing network 
>  access control (NAC) solutions. 
Is this intended to be integrated into NetworkManager?

Bill

[Avesh Agarwal]

On 01/29/2013 03:01 PM, Bill Nottingham wrote:
>  Jaroslav Reznik (jreznik(a)redhat.com) said:
> > = Features/Trusted Network Connect (TNC) =
> > https://fedoraproject.org/wiki/Features/Trusted_Network_Connect_%28TNC%29
> >
> > Feature owner(s): Avesh Agarwal <avagarwa(a)redhat.com&gt;
> >
> > This feature provides Trusted Network Connect(TNC) framework that can be used
> > to assess and verify clients' posture (or integrity measurements or
> > configuration) and its compliance to a predefined policy with existing network
> > access control (NAC) solutions.
>  Is this intended to be integrated into NetworkManager?
>
>  Bill 
There is no such plan with this feature as right now the focus is to get 
the functionality right, but this is something that may be done in 
future fedora releases.

-- 
Thanks
Avesh

[Bill Nottingham]

Avesh Agarwal (avagarwa(a)redhat.com) said: 
>  >Is this intended to be integrated into NetworkManager?
>
>  There is no such plan with this feature as right now the focus is to
>  get the functionality right, but this is something that may be done
>  in future fedora releases. 
Given that NM is the networking stack by default, and the traditional
network scripts have no support for wpa_supplicant... how is this supposed
to work out of the box, then?

Bill

[Avesh Agarwal]

On 01/29/2013 03:11 PM, Bill Nottingham wrote:
>  Avesh Agarwal (avagarwa(a)redhat.com) said:
> >> Is this intended to be integrated into NetworkManager?
> > There is no such plan with this feature as right now the focus is to
> > get the functionality right, but this is something that may be done
> > in future fedora releases.
>  Given that NM is the networking stack by default, and the traditional
>  network scripts have no support for wpa_supplicant... how is this supposed
>  to work out of the box, then?
>
>  Bill 
Right now it is done using wpa_supplicant provided cli.

-- 
Thanks
Avesh

[Avesh Agarwal]

On 01/29/2013 03:16 PM, Avesh Agarwal wrote:
>  On 01/29/2013 03:11 PM, Bill Nottingham wrote:
> > Avesh Agarwal (avagarwa(a)redhat.com) said:
> >>> Is this intended to be integrated into NetworkManager?
> >> There is no such plan with this feature as right now the focus is to
> >> get the functionality right, but this is something that may be done
> >> in future fedora releases.
> > Given that NM is the networking stack by default, and the traditional
> > network scripts have no support for wpa_supplicant... how is this 
> > supposed
> > to work out of the box, then?
> >
> > Bill
>  Right now it is done using wpa_supplicant provided cli.
>  
Just to clarify a little bit further, wpa_supplicant provided cli takes 
care of authentication and tnc's end point assessment. Once it is done, 
NM or network scripts takes care of setting up networking as usual. I 
have not checked if the current support of wpa_supplicant in NM is 
enough for this.

-- 
Thanks
Avesh

[Bill Nottingham]

Avesh Agarwal (avagarwa(a)redhat.com) said: 
>  >Right now it is done using wpa_supplicant provided cli.
>
>  Just to clarify a little bit further, wpa_supplicant provided cli
>  takes care of authentication and tnc's end point assessment. Once it
>  is done, NM or network scripts takes care of setting up networking
>  as usual. I have not checked if the current support of
>  wpa_supplicant in NM is enough for this. 
My concern is with it being something that has to be massaged on the
commandline by hand. I'm not sure it should be presented as a 'Feature'
to the users if it's not integrated into how the system normally works.

Bill

[Dan Williams]

On Tue, 2013-01-29 at 17:28 -0500, Bill Nottingham wrote:
>  Avesh Agarwal (avagarwa(a)redhat.com) said: 
>  > >Right now it is done using wpa_supplicant provided cli.
>  >
>  > Just to clarify a little bit further, wpa_supplicant provided cli
>  > takes care of authentication and tnc's end point assessment. Once it
>  > is done, NM or network scripts takes care of setting up networking
>  > as usual. I have not checked if the current support of
>  > wpa_supplicant in NM is enough for this.
>  
>  My concern is with it being something that has to be massaged on the
>  commandline by hand. I'm not sure it should be presented as a 'Feature'
>  to the users if it's not integrated into how the system normally works. 
Obviously wpa_supplicant support is a prereq for NM support.  So as long
as the options for TNC aren't awful and are fairly flexibly architected
(eg, *unlike* supplicant smartcard support) then we can support it in NM
as well fairly easily.

Avesh, what is the command sequence used with wpa_cli for TNC stuff?

Dan

[Avesh Agarwal]

On 01/31/2013 11:10 AM, Dan Williams wrote:
>  On Tue, 2013-01-29 at 17:28 -0500, Bill Nottingham wrote:
> > Avesh Agarwal (avagarwa(a)redhat.com) said:
> >>> Right now it is done using wpa_supplicant provided cli.
> >> Just to clarify a little bit further, wpa_supplicant provided cli
> >> takes care of authentication and tnc's end point assessment. Once it
> >> is done, NM or network scripts takes care of setting up networking
> >> as usual. I have not checked if the current support of
> >> wpa_supplicant in NM is enough for this.
> > My concern is with it being something that has to be massaged on the
> > commandline by hand. I'm not sure it should be presented as a 'Feature'
> > to the users if it's not integrated into how the system normally works.
>  Obviously wpa_supplicant support is a prereq for NM support.  So as long
>  as the options for TNC aren't awful and are fairly flexibly architected
>  (eg, *unlike* supplicant smartcard support) then we can support it in NM
>  as well fairly easily.
>
>  Avesh, what is the command sequence used with wpa_cli for TNC stuff?
>
>  Dan
>  
wpa_supplicant -c /etc/wpa_supplicant/wpa_supplicant.conf -i em1 -D 
wired -dd

-- 
Thanks
Avesh

[Avesh Agarwal]

On 01/29/2013 05:28 PM, Bill Nottingham wrote:
>  Avesh Agarwal (avagarwa(a)redhat.com) said:
> >> Right now it is done using wpa_supplicant provided cli.
> > Just to clarify a little bit further, wpa_supplicant provided cli
> > takes care of authentication and tnc's end point assessment. Once it
> > is done, NM or network scripts takes care of setting up networking
> > as usual. I have not checked if the current support of
> > wpa_supplicant in NM is enough for this.
>  My concern is with it being something that has to be massaged on the
>  commandline by hand. I'm not sure it should be presented as a 'Feature'
>  to the users if it's not integrated into how the system normally works.
>
>  Bill 
After having discussion with Dan Williams, it is possible that it can be 
used with NM too. I have updated goals section of the feature page to 
reflect this.

-- 
Thanks
Avesh

[Toshio Kuratomi]

On Tue, Jan 29, 2013 at 03:35:06PM +0000, Jaroslav Reznik wrote:
>  = Features/Trusted Network Connect (TNC) =
>  https://fedoraproject.org/wiki/Features/Trusted_Network_Connect_%28TNC%29
>   
I note that this Feature lacks a contingency plan.  Since it touches the
networking stack and brokenness there would be a blocker to release, I think
we need one.

-Toshio

[Avesh Agarwal]

On 02/06/2013 11:12 AM, Toshio Kuratomi wrote:
>  On Tue, Jan 29, 2013 at 03:35:06PM +0000, Jaroslav Reznik wrote:
> > = Features/Trusted Network Connect (TNC) =
> > https://fedoraproject.org/wiki/Features/Trusted_Network_Connect_%28TNC%29
> >
>  I note that this Feature lacks a contingency plan.  Since it touches the
>  networking stack and brokenness there would be a blocker to release, I think
>  we need one. 
It does not change wpa_supplicant or any parts of networking stack so

will not impact any existing functionality. I have explained this in 
contingency plan section of this feature page.
>  -Toshio
>
>  

-- 
Thanks
Avesh