SACM WG Virtual Interim 1 May 2020, 1400-1530 UTC ========================= AGENDA ====== Intro / Agenda Bash - Chairs Status on Document not on agenda today: - Information Model - Terminology Endpoint Posture Collection Profile (EPCP) (Haynes/Fitzgerald-McKay) https://tools.ietf.org/wg/sacm/draft-ietf-sacm-epcp/ Concise Software Identification Tags https://datatracker.ietf.org/doc/draft-ietf-sacm-coswid/ SACM Architecture (Montville/Munyan) https://tools.ietf.org/wg/sacm/draft-ietf-sacm-arch/ AOB MINUTES ======= Provided by Peter Yee Karen OÕDonoghue (ISOC) led the SACM WG virtual interim on 1 May 2020. She showed the Note Well and made sure we noted it well. Adam Montville (Center for Internet Security) stated that Chris Inacio (Carnegie Mellon University) is going to be doing some work on the information model draft (expired: draft-ietf-sacm-information-model), but thereÕs not a lot to change there. He hasnÕt looked at the terminology draft (expired: draft-ietf-sacm-terminology) recently and he doesnÕt know if Henk Birkholz (Fraunhofer SIT) has looked at it either recently. With some drafts expiring and the architecture draft (expired: draft-ietf-sacm-arch) pointing at the terminology draft, an update is needed. Birkholz recommends merging them for ease of management. Montville suggested that needed terms be pulled in from the expired drafts as needed, but Birkholz thinks it would be better to bring in everything into GitHub and prune unnecessary terms as needed. The best course of action will be discussed on the mailing list. Birkholz asked if thereÕs a public GitHub repository where this work can actually be done. Apparently, there is. He proposes to create a PR (pull request) to merge in the terminology document into the architecture draft. Danny Haynes (The MITRE Corporation) discussed the Endpoint Posture Collection Profile draft (draft-ietf-sacm-epcp). The latest version of the draft was published in February. The question was raised whether this draft should be a BCP or just Standards Track. With no current implementations, it was decided that Standards Track made more sense. The draft should now be ready for submission to the IESG for publication if thatÕs the groupÕs consensus. Jessica Fitzgeral-McKay (US Department of Defense) agreed with this move. Montville said he hadnÕt read the latest draft, but he has read previous drafts and has no objections. He wants to know if Haynes is requesting that people give it a good read and provide feedback. Haynes doesnÕt object to that, but he believes that the most recent changes (made in response to previous feedback) were not particularly substantial, so thereÕs not a lot of difference between the current draft and the ones on which feedback was submitted. He thinks the draft is ready for submission. McKay asked that if we think weÕre done, what are the next steps? Inacio would like to know about the change from BCP to Standard Track. He wants to understand the implications. He has reviewed the document a number of times and is good with the content. Haynes noted that BCP status requires implementations. Inacio stated that to progress down the Standards Track also requires implementations and interop go beyond Proposed Standard. HeÕs not terribly worried about that, but wanted to know if there were language changes in the draft to accommodate the change in status. He would like to see a final look-through of the document to make sure that the draft has the right changes to use RFC 2119 language. Roman Danyliw (Security AD, CERT) apologized for the amount of time it took to resolve the disposition and asked if the WGLC had been done. This happened last year. Comments were incorporated into the draft. OÕDonoghue believes it is time to move this document on. She said a short WGLC could be done. Danyliw is ready to take the document into the IESG as soon as the word is given. Ira McDonald (High North) said the draft was always written as though it was on the Standards Track and he was the one who had suggested the move to Standards Track from BCP. The WGLC comments were pretty modesty and reflected into the draft in short order. The draft hasnÕt changed in any significant way, so he supports going straight to the IESG or a short WGLC. Montville concurred. OÕDonoghue said that a one-week WGLC to catch any last nits will be held and then the document would move forward. Those present agreed with this plan. Henk Birkholz took the virtual floor to discuss the CoSWID draft. He presented the change log for the last two versions of the draft. These reflect the WGLC from last year. The most important change is to the Appendix. The key identifier in the unprotected header was moved to the protected COSE header. Most of the other changes were relatively minor, correcting oversights or polishing the document. Birkholz doesnÕt believe there are any pending changes that have not been addressed, but there was a question about which IANA algorithm registry is to be used. Both the Named Information Hash Algorithm Registry and the COSE Algorithms Registry are used and in context using both makes sense. Does anyone object? Dave Waltermire (NIST) said that Kathleen Moriarty (EMC) had raised a point about adding CWTs that the group had covered. Birkholz said thereÕs another slide that covers that, but itÕs a detached point and will be handled separately. There is a Java-based implementation already available from NIST, documentation, and a Maven-based management tool. A shepherd has now taken on the draft, so the shepherd write-up will be the next step. One nit in the draft: a ÒSHOULD NOTÓ where the ÒNOTÓ is not capitalized needs to be corrected. Waltermire has been speaking with the ISO group and asked if a maintainer being added to the entity table would cause a lot of heartburn? ItÕs a minor changes and Danyliw agrees that the document should move forward without another WGLC. Waltermire will make the change and then the document can move on. As for the question about why CWTs are not being used in CoSWID, their use, while quite helpful, would take it out of alignment with the ISO SWID document. CWT would be helpful for CoSWID RIM (reference integrity measurement/reference values) to note things like expiration date or best-before. He suggests that UCCS (Unprotected CWT Claims Sets, draft-birkholz-rats-uccs?) is a good place to discuss this topic more. Maybe the CWT claims can be reused in CoSWID. Or maybe CoSWID claims are wrapped in COSE. He thinks there might be open work to be done there or at least explored. That wouldnÕt influence how CoSWID looks today. OÕDonoghue summarized that CoSWID is ready for shepherd write-up (pending the one small change noted above). Bill Munyan (Center for Internet Security) talked about the architecture update (draft-ietf-sacm-arch) . The authors are still working on the -05 update, although the -04 draft has expired. The XMPP-specific materials in the appendices have been removed, while the ÒSecurity Program WorkflowÓ will be moved to an appendix. Text on Òhow to collect stateÓ and Òhow to evaluate stateÓ will be beefed up and illustrated in the appendix. For collection, the draft will discuss the three classifications of collection (Ad-Hoc, Continuous/Scheduled, Observational/Event-based [triggered external to the endpoint]). Interactions cover the interactions of the roles. These include broadcast (pub/sub) and directed (point-to-point, either synchronous or asynchronous). The majority of interactions will move towards broadcast (event-based) that helps to decouple the different components of the architecture. That way the parties can be completely independent, similar to cloud-native design patterns. The first interaction is collector onboarding/registration, which is essentially the step in which a Posture Collection Service (collector) becomes part of the ecosystem. The PCS authenticates to the integration service and initiates registration according the described ÒtaxonomyÓ (a new section to be added to the draft that will describe the different interactions, including the payloads and actions). Once registered, the collector tells the orchestrator what its capabilities are. The orchestrator will then tell the collector which topics it should subscribe to based on those capabilities. Collector interactions include initiating ad-hoc collection, coordinating periodic collection, and coordinating observational collection. The collector can also persist collected posture attributes, including normalizing data from the disparate types of collection systems. Evaluation interactions similarly are there to initiate ad-hoc evaluation, coordinate periodic evaluation, and coordinate change-based evaluation. The taxonomy section will cover the conventions for interactions between components. It will list the interaction, the parties to that interaction, the topic, and the format of request and response payloads. Still to be added are the interactions for the PCS registration, the orchestrator-to-collector administrative interface, and publishing collection instructions. Munyan and Montville are working to get the -05 draft out quickly. Outstanding questions include: 1) What really are the next steps on the draft? 2) How much detail does this draft need to show: how much of the information model is necessary? 3) How much implementation is needed to prove that this is a working architecture? (this has been demonstrated to a certain extent in the Hackathon). 4) How do we make this a Òliving documentÓ Ð does that end up being an IANA registry for things like topic naming conventions? Birkholz asked if directed (point-to-point) interactions allow for subscriptions. Munyan said that asynchronous directed communications involve sending a response whenever the data necessary to formulate that response becomes available. Synchronous puts other things on hold. In broadcast, a collector could act like a publisher and send its feed of information it is collecting to a topic, so it could be a publisher to an endpoint of information. The attribute repository could be the subscriber to that information. There are multiple subscribers. In directed, asynchronous requests, the requester waits for the response, but if it doesnÕt care what the response is, then this case is similar to the broadcast interaction. Pub/sub with one subscriber looks like a directed message. Birkholz asked if the publisher knows if it has to send some number of redundant PDUs to subscribers or if it has to send one PDU to the broker. Munyan replied that the publisher hands the information off to the integration service (a broker). Birkholz believes that a directed subscription is just unicast pub/sub. Munyan stated that it doesnÕt matter how many subscribers there are, the publisher leaves that to the broker to deal with whatever number of subscribers there are. Birkholz would like this point to be reflected in the draft. Birkholz also asked how the clash between slide 2 (removal of Òsolution-eyÓ things) and slide 6 (discussion of payloads, which is solution-ey) is resolved. Munyan replied that the draft is not being technology specific about the payload, whereas the XMPP part (mentioned on slide 2) in the document that is being removed was too specific. Payloads should be described in terms of information elements rather than the serialization of that information. Roman Danyliw asked what the next steps are for this draft. Will there be companion drafts? Chris Inacio says that there are some lessons learned that could be documented. ItÕs not yet clear from implementation experience whether thereÕs enough material to make another draft useful. Munyan agrees that there is potential for technology-specific drafts if those would useful down the road. OÕDonoghue said that from a WG perspective that we talk a lot of what we could do, but we need to commit only to things that people are willing to work on. The mailing list is quiet, document production is slow, and the group is on life support at this point. We could list things to do in the future, but nothing will happen unless there is interest in advancing those topics. Munyan will send a pointer to his slides on the datatracker to the start the discussion on the mailing list. The next virtual interim will take place the week of June 8th or 15th. A Doodle poll will be sent to the mailing list to determine the most amenable date. Ira McDonald noted that the IEEE Security and Privacy conference will be held the entire week of the 15th. As it will be virtual, the price has been reduced to $25, so that might eat up the week of the 15th for many people. On that basis, the week of the 8th will be used for the Doodle poll. OÕDonoghue asked about using Zoom for the next meeting. Some people arenÕt in favor of using Zoom for various security and technical reasons.