Minutes interim-2020-sacm-01: Fri 10:00
minutes-interim-2020-sacm-01-202005011000-00

SACM WG Virtual Interim
1 May 2020, 1400-1530 UTC
=========================

AGENDA
======

<as updated by agenda bash>

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.