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)
- Revocation and Policy Update capabilities
- Interface description server/client (to let the device download
trusted interface descriptions to be presented to admin)
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]>
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
