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

[Steve Hanna <[e-mail]>]

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

On 4/23/2014 12:47 PM, Trevor Freeman wrote:
> 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:[e-mail]] On Behalf Of Steve Hanna
> Sent: Wednesday, April 23, 2014 4:30 AM
> To: [e-mail]
> 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:
>> 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
>>
>>
>>> -----Original Message-----
>>> From: Trevor Freeman [mailto:[e-mail]]
>>> Sent: Tuesday, April 22, 2014 11:59 PM
>>> To: Romascanu, Dan (Dan); Lisa Lorenzin; [e-mail]
>>> Subject: RE: Proposing a SACM architecture based on TNC standards
>>>
>>> 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:[e-mail]] On Behalf Of Romascanu, Dan
>>> (Dan)
>>> Sent: Tuesday, April 22, 2014 5:01 AM
>>> To: Lisa Lorenzin; [e-mail]
>>> Subject: Re: [sacm] Proposing a SACM architecture based on TNC
>>> standards
>>>
>>> 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:[e-mail]] On Behalf Of Lisa Lorenzin
>>>> Sent: Tuesday, April 22, 2014 1:46 AM
>>>> To: [e-mail]
>>>> 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:
>>>>
>>>> http://www.ietf.org/internet-drafts/draft-shah-sacm-tnc-architecture
>>>> -0
>>>> 0.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  /  [e-mail] Principal
>>>> Solutions Architect - Security & Mobility Juniper Networks  /
>>>> http://www.juniper.net/
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> sacm mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/sacm
>>>
>>> _______________________________________________
>>> sacm mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/sacm
>>
>> _______________________________________________
>> sacm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/sacm
>>
>
> _______________________________________________
> sacm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sacm
>
> _______________________________________________
> sacm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sacm
>