SACM Virtual Interim Notes 2014-10-14 ========================== The following is a consolidated overview of notes taken during the October 2014 SACM Virtual Interim. Raw notes are included for informational purposes at the end. All updates considered "resolved" or otherwise agreed upon should make their way into submissions in support of work to be done during IETF 91. Many thanks to Nancy Cam-Winget, Jim Bieda, and Lisa Lorenzin for providing their notes from the session. ========================== After going through agenda bashing and a review of late milestones, we had a brief discussion about endpoint identity and whether that should be considered a milestone. It seems as though there may be some further discussion that needs to happen. At this point the concept of endpoint identity is implicit in milestones and there has been a call to make this explicit. We moved into the information model after that portion of the discussion where we went through some discussion of issues previously sent to list. Some issues were considered resolved, but need to be validated on the mailing list: 1. Add sections as proposed by Cliff Kahn a. http://www.ietf.org/mail-archive/web/sacm/current/msg02103.html 2. Graph model references in the information model draft a. Move section 5 of information model to appendix b. Rewrite section 6 to remove graph references 3. UML diagram a. Upper part of diagram describes potential endpoint/attribute pairs b. Lower part (Endpoint Attribute Assertion) is prescriptive (MUST be provided). These updates should be submitted by the IETF 91 submission deadline of 10/27. Other issues are still open to discussion. Specifically: 1. What is an endpoint? 2. What is a unique identifier? 3. Is there prior art for endpoint identification? 4. We need flexibility for dynamic nature of endpoints This can be a tricky secnario where even MAC addresses can be duplicated in certain environments - essentially, many of the "identity handholds" we rely upon in "traditional" environments may not suffice in novel enterprise deployments. This may warrant an additional type of SACM component that handles endpoint identity and/or reconciliation. For prior art with respect to endpoint identity see: - http://scap.nist.gov/specifications/ai/ - http://csrc.nist.gov/publications/nistir/ir7693/NISTIR-7693.pdf We also discussed the notion of assertion uncertainty. Do we need to do assertion checking based on provenance? The idea is that we should strongly consider providing points in the information/data models where we can record provenance information, though not necessarily provide the methodology used to determine levels of trust. After the information model review we moved into Requirements review and discussed the differences between current and prior drafts. The Requirements draft is somewhat lopsided where there are verbose requirements for most things aside from the Information Model. It was explictly noted that we need wider reivew of the Requirements draft. After the Requirements discussion we moved directly into Architecture discussion. We, again, discussed differences between the current and prior drafts, and believe that there is one more iteration of the Architecture draft before WGLC. As with the Requirements draft, it was noted that we need wider review of the Architecture draft as well. The Way Forward is as follows for IETF 91: - 1st meeting: Charter review and editing feedback on updated drafts - 2nd meeting: Adopt docs and update milestones - Goals: - Finalize requirements draft for WGLC and submission to IESG - Close outstanding architecture issues and move to WGLC - Discuss the Information Model - Update milestones - Accept and discuss protocol proposals *********** *RAW NOTES* *********** Jim Bieda ========= SACM Summary Notes: 14 Oct 2014 *WG Status – Dan Romascanu Late on milestone timeline IETF Cutoff date for updated drafts: 27 Oct Lisa: Should the charter of the group should include milestone for “Identity”? Dan: Should be included in Info-Model and Requirements by reference RESOLVED: Need to reserve time for discussing new milestones at IETF-91. *Information Model review – Lisa Lorenzin, Cliff Kahn RESOLVED: Add sections proposed by Cliff Kahn email see: http://www.ietf.org/mail-archive/web/sacm/current/msg02103.html 2.2 – What is an endpoint? Unique identifier? Prior art on endpoint ID? see: http://scap.nist.gov/specifications/ai/ see: http://csrc.nist.gov/publications/nistir/ir7693/NISTIR-7693.pdf Need flexibility to deal with dynamic nature of endpoints. 2.3 – Dealing with uncertainty – Need to do assertion checking based on provenance? Adam: Don’t conflate info model with process to determine truth of assertions? Cliff: Need to record provenance along with the assertion. RESOLVED: Graph model references in the Info Model draft Move Section 5 of Info Model draft to Appendix. Rewrite section 6 to remove references to graph. (May be an option for data model.) RESOLVED: UML diagram Upper part of diagram describes POTENTIAL endpoint Attribute Value Pairs. (MAY be provided) Lower part (Endpoint Attribute Assertion) is prescriptive (MUST be provided). Dan: Please complete IM update by the IETF-91 submission deadline. *Requirements review – Nancy Cam-Winget Discussed diffs vs. prior draft. Need one more iteration of draft (perhaps in Info Model & Transport) before we adopt. Security Considerations beyond data protection in transport? Ira – remove the word “task” from SACM docs RESOLVED: One more iteration before WGLC. *Architecture review – Nancy Cam-Winget Discussed diffs vs. prior draft RESOLVED: One more iteration before WGLC. *Way Forward – Dan Romascanu By 27 Oct: Updates for Reqs, IM, and Architecture drafts due IETF 91: 1st meeting: charter review & editing feedback on docs 2nd meeting: adopt docs and update milestones Goals: Final Reqs doc for submission to IESG Close arch issues and do WGLC Discuss Information Model Update milestones Accept & discuss protocols proposals Nancy Cam-Winget ================ SACM Interim Notes Agenda bash 4 Call-in Users + Alan Lei, Cliff Kahn, Danny Haynes, Ira McDonald, Jarrett, Jessica Fitzgerald-McKay, Jim Bieda, Josh Lubell, Kathleen Moriarty, Lisa Lorenzin, Rob Walters, Scott Pope, Thomas Joy We are behind on milestones: Dan and Adam will update milestones to discuss at the IETF 91 face-to-face meeting. We currently have a 9month delay based on original milestones Need at least one iteration on the Requirements draft, not quite ready for WGLC Architecture draft was published and confirmed today Late on Information Model as well Submission cutoff is Monday the 27th so there’s still some time to get updates Lisa asks Jan 2014 info: retrieving config and policy information but there’s no mention for collecting identity. Dan asks if its because we took for granted that when talking about posture, there’s the need for identity already? Lisa believes it’s a huge handwave…needs to be more explicit. Need to clearly define identity Adam agrees; though in the milestone it doesn’t need to call out every little thing. Believe identity is implicit. Dan also feels that unless something big is missing, or a separate document is needed for something (like identity) then it doesn’t need to be called out explicitly or wordsmithing the current charter. But that may require a rechartering. Lisa believes that if we can not define identity then we can not move forward and accomplish our goal. Nancy comments Dan says if we’re not comfortable with the text that’s in the charter, then we can modify the charter but that may set us back as we’ll need to recharter. Would prefer that we work thru it in the actual drafts that we standardize. Lisa doesn’t believe that its excluded in the charter as it is implicit, but wants to make sure that the work is identified and know where its going to be done. Nancy points that its in the requirements draft….even tho the charter is implicit Dan notes that we’re in agreement and new milestones are to be updated. NOTE for Chairs: reserve time for discussing new milestones in IETF 91 Lisa to drive Information Model discussion: Update: no calls were scheduled so no progress on the info model. Wants to address the two questions submitted by Cliff to help move the draft forward. In the virtual interim, the model was posted too recently so people didn’t have much time to go thru it and wanted to solicit feedback. Cliff asks about problem statement text to be added, he sent and email today subject “proposed addition to problem statement of SACM Information Model”: How do you refer to an endpoint? It may not have a unique identifier….a MAC address is not meant to be a unique identifier. Information model has background to drive towards an endpoint attribute assertion: attribute value pairs with semantics where some endpoints have a certain set of attributes over a time interval; but it doesn’t mean that the set provides a unique identifier to the endpoint. Lisa comments: MAC address in a multi-tenant environment then a richer context is needed to help better define the endpoint. Dan asks for clarification: the same MAC address can show up in different geographic data….because of mobility? Lisa comments reuse of MAC address, etc Dan: time and location context can be used to better provide scenario Cliff: encourages review text defining endpoint attribute assertion as its core to information model. It needs refining but its in the right direction Lisa asks if there’s prior art Adam notes that there are efforts but they’re proprietary; one based on NIST that is similar to what’s being proposed here. NIST asset identification spec; Adam will send a link for this. Comments that there are dynamic behaviors that need to be accounted for that didn’t exist in the “static” deployments (or old enterprises) Cliff notes that we need to have agility, because it will have to be dynamic Adam agrees that flexibility needs to be there for future growth Discussion of where the identity reference exists between Cliff, Ira and Adam Adam inferences of cross checking should be outside information model, but info model needs to be concise to allow for the representation for the assertion types Cliff clarifies: info model should not prescribe how to do the cross check, the info model should provide abstraction for components to allow for non-standard specific ways. Adam: if a given piece of data came from user vs. hw land, observed or taken from the endpoint does need to be expressed. We want the data to be present in the info model, not necessarily the method Lisa: sounds like we’re agreeing so we can move forward Cliff: next question of whether the graph model should be in the draft or not Suggests that it be moved out of normative text….it may be moved to an appendix No comments or objections to move it out of normative to either a different draft or as an Appendix Cliff: next question regarding the “Revised UML diagram of information model” An endpoint assertion may contain a bunch of attributes but not all endpoints will have the same attributes…so perhaps the UML diagram is not correct Cliff, Nancy, Ira and Lisa discuss normative text as having a set of interoperable set of attributes and set of containers. For instance, an endpoint assertion would be a container but the model can not dictate specific attribute value pairs inside the container because of the different types of endpoint. It should be a “descriptive” list of attributes versus being “prescriptive” of the attributes that should fall inside attributes or containers. Requirements discussion: Ira comments that the word “task” should not be used but either replace it with component or function Nancy comments that we need to clean up Information Model section and perhaps needing more in the transport. Dan asks what’s next? Hope that we get more review…. Nancy can get another update based on her own comments and do cleanup as she sees fit Chris will provide feedback by end of this week Architecture discussion: Nancy describes the updates, notes that she wants to incorporate feedback from Jessica as well. Nancy would like to get feedback from the group by this Friday so she can get another rev by the 27th Dan remarks and shows updated milestones to get drafts submitted by 10/27 and notes that by IETF 91 milestones need to be updated. Adam asks on confidence to get the drafts done; Nancy suggests getting feedback; Lisa’s confident on getting info model by 10/27 but needs feedback by next Wednesday. Discussions on getting proposals, Dan notes that he’d like to see some but needs to be submitted by 10/27. Chris asks/notes that it may be hard to evaluate current XMPP-Grid without solid requirements and architecture. Dan notes that we have some drafts in place to help so we can parallel process as requirements and architecture is in place albeit solidifying. Lisa Lorenzin ============= 141014 SACM virtual interim Submission cutoff is Monday 10/27 for IETF 91 Endpoint identity goes into requirements, information model Implicit in submission milestones for retrieving configuration and policy information, endpoint posture Proposed additions to problem statement of SACM information model CK - not sure problem statement is where these should go - both problems and requirements Content that was buried in previous draft, seemed to deserve promoting and explicating One problem is how to refer to an endpoint Identifying an endpoint - how to refer to an endpoint We won't always be able to use a unique identifier to refer to an endpoint Not all will have one, not all observers will know the identifier when they observe something Profiler may observe that a certain MAC address is an iPhone running iOS That's what Profilers do - it won't know from that - MAC address is by no means a unique identifier This is still useful posture data, is the premise here We need to be able to capture information like that in the information model My claim here is that this observer should not have to go digging and try to figure out what endpoint has this MAC address That could be the job of a different SACM component Correlates different observations to figure out what's going on with a certain endpoint Led to the idea that the information model had already Idea of endpoint attribute assertion - collection of attributes A/V pairs with semantics that the observer says that some endpoint that has all of these attributes over some time interval Doesn't meant that the attributes are sufficient to uniquely identify the endpoint Maybe in combination with other things, some other endpoint can figure out what endpoint it was Referring to an endpoint without always having a unique identifier Part of the information modeling problem LL - if capturing information about an endpoint in a multi-tenant cloud environment, might have multiple endpoints with same MAC address Causes a need for context about the domain of the observation DR - same MAC address can show up why? LL - reuse of MAC address across different domains, or single MAC address in different domains DR - then time and location context are useful CK - encourage people to take a look at the text on defining endpoint attribute assertion Think it's very core to the proposed information model Don't think it's cooked yet - think it needs refining, sort of in the right direction Allows you to make assertions about an endpoint without knowing uniquely what endpoints you're discussing LL - not familiar with this area - would love prior art, anything we can point at AM - have been efforts, nothing gained traction, proprietary NIST came out with asset identification spec Doesn't describe what identifies an asset Up to the user using the spec to decide what constitutes an identifier Think Dave would have more to say about it Submission either before charter or shortly after charter - prior to charter, doesn't exist at this point Will send out a link CK - I've talked about some of this with Dave & Kim Their model was a central administration model, each endpoint onboarded by central authority and given unique identification in enterprise Great, but for BYOD, IoT, slew of endpoints where that doesn't work Would be good to talk more with Dave May work well in certain kinds of enterprises where everything is onboarded in centrally administered way Want our scope to include BYOD and IoT kinds of endpoints, taking that as a given AM - lot of these specs that exist today were made for datacenters, well-understood deployments, not necessarily dynamic assets Asset identification spec would allow for some of that dynamic behavior to be accounted for Don't believe it went into anything like matching algorithms, don't know how detailed we want to be If we know about something in our CMDB, has synthetic identifier, this app has ID X Find information about a given asset, how do we match those two? CK - did look at that spec, Dave pointed me at it Want to keep some agility about this, see identification as not a thing we can fix once and for all AM - absolutely agree with that - keep as much flexibility in how we define expressions, better off we'll be in the long run CK - other thing in this memo is about dealing with uncertainty In figure 1 of the information model Internet-Draft, there's a dotted line across the middle Everything above is the world we're describing, everything below is SACM components The relationship between the two was not fully developed - needs to be more fully developed One thing about that relationship - in many information models, have certainty Model is modeling facts Here we don't have that, won't necessarily be true Attacker may develop countermeasures to fool some of our components Since SACM is a security component, behoove us to have tolerance for those things Endpoint attribute assertions are assertions - not true or false necessarily Can be cross-checked with each other An observer can assert something, another can consume assertions and decide whether assertions agree If so, gets more credence, if not, gets more concern - secondary reasoning Why we need provenance - helps explain what provenance is for Being able to take into account reputation of observer, whoever put information into information model - are they reliable? They themselves are also an endpoint, could be out of compliance or vulnerable Should think about using SACM to monitor SACM - feeding into reputation That's just part of the uncertainty Network observations are inferential - not 100% anyway Need corroborating / hedging Do all of those considerations need to be captured in an information model, or many of them? This is a problem IM - NIST spec is IR, information report, not an SP-800 standard - IR-7693 Its main Achilles heel is it presumes throughout direct communication with endpoint All security appliances that observe, watch traffic, it's useless for Don't have unique identity from concatenation of identifiers, because they're not on the wire Has some applicability, by no means the answer Sent a note to a TNC list in TCG a couple months back, should take a look at this - we did, saw that it had pluses and minuses AM - comment about dealing with uncertainty There are assertions, no facts - I like that See the degree of certainty as being an issue Wondering whether cross-checking and being able to infer against each other, meaning not clear Whether that belongs in the information model or whether the information model should be relegated to what needs to be done in order to assess posture Inferences and posture can be done outside of that Wouldn't want to conflate too many functions inside the information model LL - where else would we do it? AM - something outside of that Information model represents assertions being made, information represents assertions How we cross-check those assertions could be done outside of that CK - clarify what I was trying to say Don't think the information model should prescribe how you should cross-check Maybe SACM standards shouldn't Information model should provide information that would allow components to do that in vendor-specific ways In some of the TNC standards, observations get tagged with method used, place to do that Self-reported vs. reported by observer, different techniques, and also identity of source SACM component reporting information AM - given piece of data, come from third-party agent or userland? Observed on wire or taken from endpoint? Things like that CK - yes - make sense to have it? AM - want the data that would be used for cross-checking and inferring to be present in the information model, not necessarily the method LL - absolutely CK - talked last time about whether graph model should be in information model, didn't reach a decision I make an argument that it shouldn’t be - two-part argument One is a question of whether the parts of an endpoint should be represented with separate identifiers If there's going to be a graph, how would we use the graph? One YANG model of endpoint attached as metadata to an identifier that denotes the endpoint Maybe not, maybe expressed with subgraph - interesting question, distraction to tackle it now NCW - my recollection of the previous call was that there was consensus that the graph model was not to be the normative text in the information model LL - think that what Cliff is recommending is that we remove it, even non-normative, as a distraction Didn't belong in the information model - what wasn't clear was whether graph could be example for how we could organize the information DR - how would this be reflected in the information model draft? Completely out? CK - move section 5 to an appendix so we don't lose it, have available when working on data models to consider Section 6 would need to be rewritten in a way that does not assume a graph DR - that works for me LL - any objections? CK - UML diagram showing that every endpoint attribute assertion has UML relationship with endpoint What we'd like, but sort of not true Will have endpoint attribute assertions where -if you assume by endpoint we mean something with a unique identifier Endpoint attribute assertion doesn't have that Many of those A/V pairs refer to things in upper half of diagram IP addresses, MAC addresses, hardware components, software components, locations, unique endpoint identifier Almost all things in upper half could appear Tried to make the diagram say that If we like that, text also needs to change to say that too NCW - you can refer to the diagram as an example I agree that the endpoint attribute assertion is just a collection of attributes, not all assertions are alike CK - I think it needs to be more than an example Need to have some normative attributes Is your point that it needs to be extensible? NCW - needs to be extensible, but I thought in our discussions an asset could be a physical thing or virtual thing Would find it hard to put a single handle to an endpoint CK - agreed IM - I think what Cliff is trying to say - kind of a hard idea to get across - not all endpoint attribute assertions contain the same set of attribute value pairs Varies wildly depending on whether virtual / physical, hardware chunks in endpoint What's inside an endpoint attribute assertion that's used generally for identity in the broadest sense is utterly contextual We've found that unique identifier problem is a hard problem LL - think we need some normative set of attributes, need extensibility as well NCW - we know we need something that describes and endpoint assertion, that can be normative But the attributes are not I don't think we can put normative "you must have one of" LL - I agree, but I think there's value of defining a normative set of attributes so entities that can use those can use them out of the box IM - only if it's in context - attributes for software asset no overlap with hardware NCW - I would assume, similar to what NetConf has done with YANG They have a set of containers and attributes - for interoperability, MUST set of attributes from implementation standpoint Assertion container, set of attributes, we have to decide which ones are MUSTs What's contained within the endpoint assertion, don't' think we can construe as normative CK - the diagram I drew yesterday says an endpoint attribute assertion has one or more A/V pairs An A/V pair may refer to one of the kinds of things in the upper half of the diagram, or it may not Will certainly be some attribute values - quite precise With UML, easy to be precise, consistent with what you're saying Not trying to mandate that particular attributes appear It may be that an A/V assertion that doesn't have at least one of X is meaningless, but I'm hesitant to add normative text - have restrictions without being sure we need them Seen that turn out to be a bad idea in the past LL - think we need a descriptive list of attributes, not a prescriptive list of attributes IM - descriptions of attributes without having prescriptive requirements that an endpoint attribute assertion bundle always contain them CK - normative not only in syntax but in meaning LL - yes, that's what I care about CK - were a little lax about that in things like RADIUS, IF-MAP - has caused problems Won't be a closed set - will be extensible by IETF and presumably by implementers as well TJ - in your diagram, you have credential on the top Endpoint not always manageable to have a credential to identify endpoints on the network Just one point CK - it shows that an endpoint MAY have one - it's a star An endpoint has zero or more credentials TJ - that sounds right Identifying an endpoint is a set of attributes that keep on changing From an enterprise level, people have to do definition CK - attributes change - agreed IM - they have a lifetime, too - not always the same as the lifetime of the endpoint JB - just to be absolutely - stuff in upper parts of diagram is descriptive of things you may have as A/V pairs provided to lower half of diagram in endpoint attribute assertion, which must be there for any endpoint LL - endpoint attribute assertion MUST be there, upper half is things that MAY be in it LL - wraps up on information model DR - have 13 days until the cutoff for submitting the Internet-Draft You basically need to complete the work this week and the next week LL - yes - I do expect to have updated information model draft submitted by deadline DR - should be draft-ietf-sacm LL - yes, will rename it correctly Requirements NCW - don't have slides prepared Based on text in information model draft, tried to elaborate more to highlight need for scalability and so on Not happy with what's requirement on information model For transport, not sure whether data protection was transport data protection, or security considerations for interfaces, which include transport More on architecture than requirements Would like to get your input and feedback on that JB - want to know whether or not there should be a requirement for security at a specific layer, or handle in architecture? NCW - for requirements on architecture In section I added, trying to be consistent with how we'd had it in general requirements All we had noted was data protection Could speak to just data integrity, or confidentiality LL - I thought we agreed that we wanted both and they were separate requirements NCW - we did - that's why I left requirement for data protection in general section, also requirement in transport JB - do we want to say that function has to happen in transport? LL - think that is necessary, but not the only place NCW - putting requirement in transport means we have to address in transport layer JB - we want to solve that in transport NCW - transport being one of the places we want to solve that - yes DR - what next? Hoping more folks will read and provide comments in the next week or so Facing the same cutoff for the 27th Wondering whether a new iteration which is good enough for WGLC can be done NCW - I can do the cleanup based on my own feedback, try to get it done by the 27th Hoping to get more review, otherwise… DR - trying to figure out what happens between now and IETF 91 Can do nothing and wait for comments to come Can do cleanup and wait for new release without issuing last call Can issue last call, which may not necessarily be the last last call Last call has capacity sometimes to mobilize people who didn't pay close attention until then to read and provide comments Discussion at IETF 91 CI - will commit to giving you feedback this week - it's 11 pages Architecture Left the architectural figure as the main figure New section is cut-n-paste of one of the appendices of information model Given that we've now defined high-level components, Provider / Consumer / Control Plane Had a hard time with comments about guidance Didn't include from original text - function called out which was collection guidance capability Didn't quite make sense to me, didn't bring it from information model Need to sync with Dave Capability seemed like more of control function When read it closer, seemed like producer or consumer that could go to collection or evaluation Still functional components that act as producers or consumers LL - think that's correct - collection guidance was a way for producers or consumers to instruct other components on information needed NCW - removed that task Called it a component, to flow better with taxonomy of this draft Component that articulates guidance as producer or consumer Need to look at diagram to make sure flow still makes sense Jess provided other diagrams, I had a hard enough time trying to get this updated That I may show as better workflow examples I'm hoping you guys will provide more feedback on this draft If I can get the feedback from you guys by this Friday, may give me enough time to get it in by the deadline Figures always give me a hard time, or IDNITS does Given that I wanted to incorporate some of the feedback from Jess, I need about a week LL - might talk to Aaron, he did magic with Cliff's figures NCW - unfortunately Aaron is not focused on this anymore DM - instruction is to try to do your best and complete by the deadline Probably good to go through at least one more iteration before going to last call Have the best we can by deadline, discuss it in Honolulu Questions or comments?