Subject: [sacm] Proposing a SACM architecture based on TNC standards

From: Lisa Lorenzin <[email-masked]>
Date: Mon, 21 Apr 2014 22:45:44 +0000

Greetings!

While reviewing the draft architecture included in the SACM
requirements document, several of us who contribute to the
Trusted Computing Group's Trusted Network Connect workgroup 
were struck by its similarity to the TNC architecture.

The TNC architecture is not a direct mapping to what SACM
is defining; in addition to endpoint posture checking (used 
by the IETF NEA WG) and security automation interfaces, the 
TNC architecture also addresses enforcement, which has been 
established to be out of scope for SACM.  And the TNC 
architecture doesn't currently address content repositories.
However, the TNC architecture is not monolithic; in real-world
deployments based on TNC, it's common to use the components 
that are useful, ignore components that aren't relevant, and 
add components to address additional use cases.

Atul Shah (of Microsoft) and I, with input from our TNC
colleagues, have put together a brief overview of a possible
SACM architecture, using the TNC architecture and interfaces
as a starting point, for consideration:

http://www.ietf.org/internet-drafts/draft-shah-sacm-tnc-architecture-00.txt

(Full disclosure: Atul & I are the current co-chairs of the TNC
WG.  However, we are submitting this proposal as individuals,
not as representatives of TCG/TNC or our respective employers.)

                                       Regards,

                                          Lisa

--
Lisa Lorenzin  /  919-384-7275  /  [email-masked] 
Principal Solutions Architect - Security & Mobility 
Juniper Networks  /  http://www.juniper.net/

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 22 Apr 2014 12:00:36 +0000

Hi Lisa,

Thank you for your contribution. 

I suggest that we include this I-D on the agenda of the virtual interim meeting next week.  Best would be if you can prepare a few slides to guide us through it, but all participants are invited to read the I-D in advance and come prepared for questions, comments and discussions. 

Thanks and Regards,

Dan

> -----Original Message-----
> From: sacm [mailto:[email-masked]] On Behalf Of Lisa Lorenzin
> Sent: Tuesday, April 22, 2014 1:46 AM
> To: [email-masked]
> Subject: [sacm] Proposing a SACM architecture based on TNC standards
> 
> Greetings!
> 
> While reviewing the draft architecture included in the SACM requirements
> document, several of us who contribute to the Trusted Computing Group's
> Trusted Network Connect workgroup were struck by its similarity to the TNC
> architecture.
> 
> The TNC architecture is not a direct mapping to what SACM is defining; in
> addition to endpoint posture checking (used by the IETF NEA WG) and
> security automation interfaces, the TNC architecture also addresses
> enforcement, which has been established to be out of scope for SACM.  And
> the TNC architecture doesn't currently address content repositories.
> However, the TNC architecture is not monolithic; in real-world deployments
> based on TNC, it's common to use the components that are useful, ignore
> components that aren't relevant, and add components to address additional
> use cases.
> 
> Atul Shah (of Microsoft) and I, with input from our TNC colleagues, have put
> together a brief overview of a possible SACM architecture, using the TNC
> architecture and interfaces as a starting point, for consideration:
> 
> (Full disclosure: Atul & I are the current co-chairs of the TNC WG.  However,
> we are submitting this proposal as individuals, not as representatives of
> TCG/TNC or our respective employers.)
> 
>                                        Regards,
> 
>                                           Lisa
> 
> 
> 
> 
> 
> --
> Lisa Lorenzin  /  919-384-7275  /  [email-masked] Principal Solutions
> Architect - Security & Mobility Juniper Networks  /  http://www.juniper.net/
> 
> 
> 
> 
> 
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm

---

From: Trevor Freeman <[email-masked]>
Date: Tue, 22 Apr 2014 20:59:29 +0000

Hi Dan,

We will have to be careful about BCP78/9 during discussion of Lisa's draft.

The TCG specifications themselves have not been contributed in this draft. 

Any discussion of the TCG protocols on the call would be a contribution to the IETF subject to BCP78/79.

I for one have company policy which requires authorization to make technical contributions so I cannot discuss the TCG protocols themselves. 

It was interesting to note that the TCG protocols that NEA was based on had to be extended. It sounds like SACM may need to draft a requirements doc for NEA to close the gaps. Certainly the breath of the definition of SACM posture attributes seems much broader that what NEA can currently support. 

Trevor

-----Original Message-----
From: sacm [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
Sent: Tuesday, April 22, 2014 5:01 AM
To: Lisa Lorenzin; [email-masked]
Subject: Re: [sacm] Proposing a SACM architecture based on TNC standards

Hi Lisa,

Thanks and Regards,

Dan

> requirements document, several of us who contribute to the Trusted 
> Computing Group's Trusted Network Connect workgroup were struck by its 
> similarity to the TNC architecture.
> 
> The TNC architecture is not a direct mapping to what SACM is defining; 
> in addition to endpoint posture checking (used by the IETF NEA WG) and 
> enforcement, which has been established to be out of scope for SACM.  
> And the TNC architecture doesn't currently address content repositories.
> deployments based on TNC, it's common to use the components that are 
> useful, ignore components that aren't relevant, and add components to 
> address additional use cases.
> 
> Atul Shah (of Microsoft) and I, with input from our TNC colleagues, 
> have put together a brief overview of a possible SACM architecture, 
> using the TNC architecture and interfaces as a starting point, for consideration:
> 
> (Full disclosure: Atul & I are the current co-chairs of the TNC WG.  
> However, we are submitting this proposal as individuals, not as 
> representatives of TCG/TNC or our respective employers.)
> 
>                                        Regards,
> 
>                                           Lisa
> 
> 
> 
> 
> 
> --
> Lisa Lorenzin  /  919-384-7275  /  [email-masked] Principal 
> Solutions Architect - Security & Mobility Juniper Networks  /  
> http://www.juniper.net/
> 
> 
> 
> 
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 23 Apr 2014 10:19:01 +0000

Of course. Please, everybody, pay (again) attention to http://www.ietf.org/about/note-well.html and read (again if necessary) RFC 5378 and RFC 3979 (updated by RFC 4879). 

Thanks and Regards,

Dan

> From: Trevor Freeman [mailto:[email-masked]]
> Sent: Tuesday, April 22, 2014 11:59 PM
> To: Romascanu, Dan (Dan); Lisa Lorenzin; [email-masked]
> Subject: RE: Proposing a SACM architecture based on TNC standards
> 
> Hi Dan,
> 
> I for one have company policy which requires authorization to make technical
> contributions so I cannot discuss the TCG protocols themselves.
> 
> It was interesting to note that the TCG protocols that NEA was based on had
> to be extended. It sounds like SACM may need to draft a requirements doc
> for NEA to close the gaps. Certainly the breath of the definition of SACM
> posture attributes seems much broader that what NEA can currently
> support.
> 
> Trevor
> 
> I suggest that we include this I-D on the agenda of the virtual interim meeting
> next week.  Best would be if you can prepare a few slides to guide us
> through it, but all participants are invited to read the I-D in advance and come
> prepared for questions, comments and discussions.
> 
> Thanks and Regards,
> 
> Dan
> 
>

---

From: Steve Hanna <[email-masked]>
Date: Wed, 23 Apr 2014 07:30:05 -0400

Certainly, everyone should read BCP 78 and BCP 79 before
participating in IETF discussions. That's always a good
idea. And if you have a corporate policy that restricts
what you can talk about in IETF, you should follow it.

I don't think that Lisa's draft presents any particular
challenges. On this mailing list, we have talked about
SCAP and SWIDs and many other things that haven't been
contributed to IETF (at least, not yet). If you can't
talk about something (because you have a patent on it
or whatever), then don't!

Now on to the semi-technical content of Trevor's email:

 > It was interesting to note that the TCG protocols that
 > NEA was based on had to be extended. It sounds like SACM
 > may need to draft a requirements doc for NEA to close
 > the gaps. Certainly the breath of the definition of SACM
 > posture attributes seems much broader that what NEA can
 > currently support.

The NEA protocols (which are part of the TNC architecture)
were designed to be extended. We spent a lot of time and
effort on making them extensible. We knew from the start
that there would be a continuous stream of new attributes
that people would want to get from endpoints. We even
designed the system so that it's easy to have plug-in
modules (Posture Collectors) on the NEA Client to gather
new attributes and plug-in modules (Posture Validators)
on the NEA Server to process new attributes. The PA Subtype
field indicates which kind of attribute is being sent
or gathered: Operating System, Anti-Virus, Firewall, etc.
TCG has defined new PA Subtypes for SWID, SCAP, and TPM
attestations with new attribute types to carry the content.

I expect that SACM will come up with some new attribute
types and probably also some new PA Subtypes.

Thanks,

Steve

---

From: Trevor Freeman <[email-masked]>
Date: Wed, 23 Apr 2014 16:47:45 +0000

Hi Steve,

As you say, Lisa draft by itself does not preset much of a challenge. If you subtract all the things referenced but not contributed, it looks very similar to what we already have. 

Even at a high level there are some aspects which raise concerns over unnecessary complexity. For example, the need to a different protocol to query current state vs historical state? Why would a need a different protocol just because the timestamp on the data is older?

You description of what TCG did to extend the NEA protocols confirmed my suspicion on their lack of flexibility. That will have to be fixed, but it is best to better understand what SACM need first. 

If TCG want to help us instantiate the SACM architecture by contributing some work, that would be great, but unlit that happens, I don't want to count chickens.

On the subject of counting chickens, I did not understand the reference to the RFC7171. The NEA PT-EAP draft still shows up in the editors queue. 

Trevor

-----Original Message-----
From: sacm [mailto:[email-masked]] On Behalf Of Steve Hanna
Sent: Wednesday, April 23, 2014 4:30 AM
To: [email-masked]
Subject: Re: [sacm] Proposing a SACM architecture based on TNC standards

Certainly, everyone should read BCP 78 and BCP 79 before participating in IETF discussions. That's always a good idea. And if you have a corporate policy that restricts what you can talk about in IETF, you should follow it.

I don't think that Lisa's draft presents any particular challenges. On this mailing list, we have talked about SCAP and SWIDs and many other things that haven't been contributed to IETF (at least, not yet). If you can't talk about something (because you have a patent on it or whatever), then don't!

Now on to the semi-technical content of Trevor's email:

 > It was interesting to note that the TCG protocols that  > NEA was based on had to be extended. It sounds like SACM  > may need to draft a requirements doc for NEA to close  > the gaps. Certainly the breath of the definition of SACM  > posture attributes seems much broader that what NEA can  > currently support.

The NEA protocols (which are part of the TNC architecture) were designed to be extended. We spent a lot of time and effort on making them extensible. We knew from the start that there would be a continuous stream of new attributes that people would want to get from endpoints. We even designed the system so that it's easy to have plug-in modules (Posture Collectors) on the NEA Client to gather new attributes and plug-in modules (Posture Validators) on the NEA Server to process new attributes. The PA Subtype field indicates which kind of attribute is being sent or gathered: Operating System, Anti-Virus, Firewall, etc.
TCG has defined new PA Subtypes for SWID, SCAP, and TPM attestations with new attribute types to carry the content.

I expect that SACM will come up with some new attribute types and probably also some new PA Subtypes.

Thanks,

Steve

On 4/23/2014 6:19 AM, Romascanu, Dan (Dan) wrote:
>> Any discussion of the TCG protocols on the call would be a 
>> contribution to the IETF subject to BCP78/79.
>>
>> I for one have company policy which requires authorization to make 
>> technical contributions so I cannot discuss the TCG protocols themselves.
>>
>> It was interesting to note that the TCG protocols that NEA was based 
>> on had to be extended. It sounds like SACM may need to draft a 
>> requirements doc for NEA to close the gaps. Certainly the breath of 
>> the definition of SACM posture attributes seems much broader that 
>> what NEA can currently support.
>>
>> Trevor
>>
>> I suggest that we include this I-D on the agenda of the virtual 
>> interim meeting next week.  Best would be if you can prepare a few 
>> slides to guide us through it, but all participants are invited to 
>> read the I-D in advance and come prepared for questions, comments and discussions.
>>
>> Thanks and Regards,
>>
>> Dan
>>
>>
>>> Computing Group's Trusted Network Connect workgroup were struck by 
>>> its similarity to the TNC architecture.
>>>
>>> The TNC architecture is not a direct mapping to what SACM is 
>>> defining; in addition to endpoint posture checking (used by the IETF 
>>> NEA WG) and security automation interfaces, the TNC architecture 
>>> also addresses enforcement, which has been established to be out of scope for SACM.
>>> useful, ignore components that aren't relevant, and add components 
>>> to address additional use cases.
>>>
>>> http://www.ietf.org/internet-drafts/draft-shah-sacm-tnc-architecture
>>> -0
>>> 0.txt
>>>

---

From: Steve Hanna <[email-masked]>
Date: Thu, 24 Apr 2014 07:18:59 -0400

Trevor Freeman wrote:
 > You description of what TCG did to extend the NEA protocols confirmed
 > my suspicion on their lack of flexibility. That will have to be
 > fixed, but it is best to better understand what SACM need first.

Hahaha! If you read the NEA specs, you'll see that flexibility is one
of their primary strengths. In fact, it's a defining characteristic.
The fact that it's easy to add support for new attributes confirms
this flexibility, which is fundamental to the NEA architecture.

But I do agree with you that we must first agree on what SACM needs.
Let's continue the work on use cases and requirements.

 > On the subject of counting chickens, I did not understand the
 > reference to the RFC7171. The NEA PT-EAP draft still shows up
 > in the editors queue.

Mea culpa. PT-EAP entered AUTH48 on March 25. When Lisa and Atul were
creating their draft, I assured them that it would be an RFC by now.
I underestimated the glacial pace of IETF progress. Who knew that
the 48-hour author's review period would extend for 30 days (so far)?

Thanks,

Steve

---

From: Lisa Lorenzin <[email-masked]>
Date: Fri, 25 Apr 2014 18:21:57 +0000

Hi Dan,

Thanks!  The inclusion in the virtual interim meeting agenda 
looks good to me.  I'll put some brief slides together and post 
them before the meeting.

						Regards,

								Lisa

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: Tuesday, April 22, 2014 8:01 AM
To: Lisa Lorenzin; [email-masked]
Subject: RE: Proposing a SACM architecture based on TNC standards

Hi Lisa,

Thanks and Regards,

Dan