I agree with Ken - but to clarify, as far as I know, a Security Manager app *can* update policy (using SecurityApplicationProxy::UpdatePolicy). Please let me know in case that doesn't actually work.
Ondrej, another example of Key Store shortcoming is https://jira.allseenalliance.org/browse/ASACORE-2587. I don't remember others right now. Dan -----Original Message----- From: Swinson, Ken [mailto:[email protected]] Sent: Friday, February 12, 2016 7:52 AM To: [email protected]; Daniel Mihai <[email protected]> Cc: Lioy, Marcello <[email protected]>; [email protected] Subject: RE: [Allseen-core] Security 2.0 status, and proposals for improvements Hi, The draft16v1.6 edition of the Security 2 HLD is significantly old. We left the archived versions referenced from the wiki for historical purposes and moved to maintaining the HLD in the wiki. See https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit.allseenalliance.org%2fcgit%2fextras%2fwebdocs.git%2flog%2fdocs%2flearn%2fcore%2fsecurity2_0%2fhld.md%3fh%3drefs%2fheads%2ffeature%2fsecurity2.0&data=01%7c01%7cDaniel.Mihai%40microsoft.com%7ca9a6ebf3823a453ea41208d333c483ab%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=YV1skzg4D5OO45YwvXt8Ul5kYYjynaNbLTWGmiESblQ%3d The published documentation at https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fallseenalliance.org%2fframework%2fdocumentation%2flearn%2fcore%2fsecurity2_0&data=01%7c01%7cDaniel.Mihai%40microsoft.com%7ca9a6ebf3823a453ea41208d333c483ab%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=LHvEXpadoF5jVdQ6n5srX3nBo2HkrrE7K7Y7CxO2F6Y%3d is the most recent for the current release. We're just finalizing the changes for 16.04 so you should see updates to the HLD in git in the near future. See inline for additional comments. Ken -----Original Message----- From: [email protected] [mailto:[email protected]] Sent: Friday, February 12, 2016 12:38 AM To: Daniel Mihai Cc: Swinson, Ken; Lioy, Marcello; [email protected] Subject: Re: [Allseen-core] Security 2.0 status, and proposals for improvements This is great to hear, thank you all for the outlook ! Dan, by "changes to address other shortcomings of the Keystore implementation" you meant any security enhancements ? Also, while reading the docs/HLD (draft17v1.6), I get a feeling that there are still some missing pieces to enable the end-to-end Security 2.0 deployment, specifically: - Rich Security Manager (there is a prototype implementation out now and a rich implementation was planned for 2016) [kens] This is still desired but there is no current plan to implement. We just discussed the need for this earlier this week and will be looking for options to complete this task. - Revocation and Policy Update capabilities [kens] Look at the most recent HLD. We don't have traditional revocation yet but do have a means of addressing the need. There are no immediate plans to update beyond our current solution, at least not that I am aware of. - Interface description server/client (to let the device download trusted interface descriptions to be presented to admin) [kens] I am not aware of any activity on this topic. Are any of these possible with the current release or on track for 16.04 ? Thanks again for clarification, Ondrej T Quoting Daniel Mihai <[email protected]>: > Thanks for the feedback Ken! > > Some thoughts below: > > From: Swinson, Ken [mailto:[email protected]] > Sent: Monday, February 8, 2016 3:04 PM > To: Daniel Mihai <[email protected]>; Lioy, Marcello > <[email protected]>; [email protected]; > [email protected] > Cc: [email protected]; Dominique Chanet (QEO LLC) > <[email protected]>; Josh Spain <[email protected]>; > [email protected] > Subject: RE: [Allseen-core] Security 2.0 status, and proposals for > improvements > > Dan, Thanks for the list, > > Has device certificates dropped from the active discussions? I > suspect code changes would be desirable regardless of the decision to > move forward with a single root CA or multiple root CAs selected by > individual OEMs. > [DM] This one is currently not on my radar at all. Please bring it up > in the Core WG meetings if it's important. > > > See inline for other comments. > > Ken > > > From: Daniel Mihai [mailto:[email protected]] > Sent: Friday, February 05, 2016 2:11 PM > To: Lioy, Marcello; > [email protected]<mailto:[email protected]>; > [email protected]<mailto:[email protected] > https://na01.safelinks.protection.outlook.com/?url=enalliance.org&data=01%7c01%7cDaniel.Mihai%40microsoft.com%7ca9a6ebf3823a453ea41208d333c483ab%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=u4sGL5312r5RmEHQHXvCTSybYIdUgfXWz%2bQ1FyxGWdA%3d> > Cc: [email protected]<mailto:[email protected]>; Dominique > Chanet (QEO LLC); Swinson, Ken; Josh Spain; > [email protected]<mailto:[email protected]> > Subject: RE: [Allseen-core] Security 2.0 status, and proposals for > improvements > > > This is the current high-level wish list of improvements that we are > investigating at MSFT. It is still unclear how many and when we'll be > able to implement them. > > > > 1. Add new Manifest format, more granular, as I proposed in the > attached email. > > - Also consider removing the support for the > problematic 15.09 Manifest format > > [kens] I need clarification on what you are proposing. Is it as > Phil summarized in the e-mail you attached? In which case then > more granular refers to segmenting the manifest? The 15.09 manifest > should not be supported if it is replaced. > > [DM] We will share our detailed proposal as soon as possible. We are > currently reviewing one such proposal in our team - stay tuned. > > > > > > 2. Add XML-based public methods for Policy, Manifest, Manifest Template. > > - Consider removing the current public methods, if they are > superseded by the new methods > > [kens] I agree with removing superseded methods that would fall > under the developer preview for sec 2 > > > > 3. Add StartManagement + EndManagement methods, called by a Security > Manager to notify the target app that its Security settings are > about to change. > > [kens] I'll reply to your later email on the topic. > > > > 4. Add public C APIs corresponding to the most useful public C++ methods. > > > > 5. Significant changes to the implementation of the Key Store - to > address ASACORE-2661, ASACORE-2664, and other shortcomings. > > > > 6. Make it easier to share a single Key Store between two processes > running on a single machine. > > [kens] This should include making it easy for a security manager to > determine that the key store is shared so that it can construct > policies and manifests. > > [DM] Agreed that would be a worthy goal. Let's see how close we can > get to that goal in 16.04. We'll provide our detailed proposal as > soon as we can. > > > > > > 7. Add a new SPEKE auth mechanism - similar but better than the current PSK. > > > > 8. Introduce the concept of "Recommended Security Level". For example: > > - Manufacturer of an "org.Contoso.GunSafe" device might want to > recommend that interface as accessible just to "Privileged" users > > - Manufacturer of an "org.Contoso.WirelessSpeaker" device might > want to recommend that interface as "NonPrivileged" > > - Manufacturer of an "org.Contoso.LightSwitch" device might want to > recommend that interface as "Unauthenticated" > > [kens] I like it. Consider mapping the recommendation to the peer > types for consistency. > > [DM] Peer types would definitely be used by the Security Manager > behind the scenes, to implement the Security Levels mentioned above: > > > > "Unauthenticated" maps well to PEER_ALL. > > > > I look at a particular implementation of Security Manager as having > more flexibility when it wants to implement "NonPrivileged" and/or > "Privileged" Levels. For example, we're currently still debating in > our team if we want to use just PEER_FROM_CERTIFICATE_AUTHORITY, or > just PEER_WITH_MEMBERSHIP, or a combination of these two, for our > particular scenarios. Each of these choices seems to have advantages > and disadvantages. > > > > 9. Investigate the numerous active JIRA tickets related to Security > and fix those that the Core WG decides are important. > > > > If anyone has questions or other kind of feedback, please speak up. > > > > Dan > > > > -----Original Message----- > From: Lioy, Marcello [mailto:[email protected]] > Sent: Thursday, February 4, 2016 11:39 AM > To: [email protected]<mailto:[email protected]>; > [email protected]<mailto:[email protected]> > Cc: Daniel Mihai > <[email protected]<mailto:[email protected]>> > Subject: RE: [Allseen-core] Security 2.0 status > > > > There are some changes being proposed, however, I think it is > developer API changes rather than the interface definitions on the > wire. I have CC'ed Dan Mihai who is driving the updates to Security > 2.0. He can correct or elaborate as appropriate. > > > > -----Original Message----- > > From: > [email protected]<mailto:[email protected]> > [mailto:[email protected]] On Behalf Of > [email protected]<mailto:[email protected]> > > Sent: Monday, January 25, 2016 2:08 AM > > To: > [email protected]<mailto:[email protected]> > > Subject: [Allseen-core] Security 2.0 status > > > > > > Hi everyone, > > > > Is it possible to release the latest 15.09(a)-related Security 2.0 > HLD ? As both the > https://na01.safelinks.protection.outlook.com/?url=allseenalliance.org&data=01%7c01%7cDaniel.Mihai%40microsoft.com%7c1761def47b9b40ff54da08d32d9adcb0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=8t3KSB3ksxrk%2fFOPp7gcPWW%2btMdZsmovppbK0g3%2fwzQ%3d > documentation and wiki seem to point to out-of-date > documents. > > > > Also, is the production-grade 16.04 Security 2.0 roadmap decided > upon (e.g. things like interface description servers and like) ? > > > > Thanks, > > Ondrej T > > > > _______________________________________________ > > Allseen-core mailing list > > [email protected]<mailto:[email protected]> > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2flists.allseenalliance.org%2fmailman%2flistinfo%2fallseen-core&data=01%7c01%7cDaniel.Mihai%40microsoft.com%7c1761def47b9b40ff54da08d32d9adcb0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=%2fZzxaUmnFC9opwKhE%2bnozXKB04TnGNL3Kxw%2bn3FtYtM%3d _______________________________________________ Allseen-core mailing list [email protected] https://lists.allseenalliance.org/mailman/listinfo/allseen-core
