I prefer Tuesday 2/23 @ 10AM PST. From: Swinson, Ken [mailto:[email protected]] Sent: Thursday, February 18, 2016 11:08 AM To: Kevin Kane <[email protected]>; Daniel Mihai <[email protected]>; '[email protected]' <[email protected]> Cc: Dave Thaler <[email protected]> Subject: RE: Multiple manifests proposal for 16.04
Since we were not able to fit this into the core working group weekly meeting, I am proposing that we have an ad hoc technical meeting to discuss the open security 2 issues. I'm assuming there are more interested in the discussion than just Kevin and myself. My calendar is pretty flexible these days with before 10:00 AM and Thursday before noon being unavailable. I propose either Monday 2/22 @ AM 8:00 or Tuesday 2/23 @ 10:00 AM as opening time options. Please respond with interest and time preference. Note, that all times referenced are Pacific Time Zone. Suggested Topics: - Hardcoding or manifests or policies for select interfaces. - Vision for how visiting works. The options are documented in the HLD following the "Inter Security Manager Interaction" subheading. I'm in favor of the "restricted user" method and impacts my questioning the issuing of manifests under the membership certificate authority. - Any other open questions or comments on the multi-manifest proposal From: Kevin Kane [mailto:[email protected]] Sent: Wednesday, February 17, 2016 8:36 AM To: Swinson, Ken; Daniel Mihai; '[email protected]' Cc: Dave Thaler Subject: RE: Multiple manifests proposal for 16.04 [kens] Your friend's TV would have a policy that gives permission to the holder of the membership certificate. You seem to be using the manifest to reinforce the policy. I see the manifest(s) as providing an outer bound of what a peer is allowed to do regardless of what various security manager have decided to allow. It should allow me (the holder of the peer) to be most aware of the extent to which the peer should be allowed to interact as I am presumable most familiar with it. Maybe I misunderstand how the access control check works. I thought both the producer-side policy and the consumer-side manifest had to allow the access for it all to pass? Won't my friend's TV not trust my TV app's identity certificate (issued by my security manager) and therefore my manifest? I thought the friend's TV's policy is necessary but not sufficient to allow the interaction. [kens] Would there be the ability for a 2.0 peer to restrict itself from interacting with 1.0 peers? From the perspective of the 2.0 peer, it is not known if the contract of the remote peer enforcing the manifest is fulfilled or not. Think in terms of the 2.0 peer application developer. This developer does not want to interact in a way that is outside of what his customer has allowed but is not able to rely upon the implementation to enforce this. A security manager can certainly decide this by not issuing credentials with the special flag to a 1.0 peer (through whatever out-of-band process at 1.0 peer gets credentials in this scenario), but I don't know off-hand if the app can figure out somehow by querying the AllJoyn API if it's talking to a 1.0 peer. Is this even desirable? If the security manager decides a 1.0 peer can interact with a 2.0 peer, and issues credentials to that effect, why would the app developer want to prevent this? [kens] We intentionally removed any special cases. I'm not convinced we got all of them but that was the intent. This is why we have the "default" policy. As I recall, the most significant drivers for this were reducing code paths/test cases and reducing the need for security manager to be aware of the various special cases. We also have tried not to predict the future use cases or even our understanding of current use cases where there wasn't a driving need to do so. To go back to the concept of manifests granted under the authority of the membership certificate issuer, the manifest permitting org.alljoyn.Bus.Security.ManagedApplication may not be provided with the identity certificate. We could still leave in the spot for the manifest argument in the Claim and UpdateIdentity, but taking the new format, or taking an array of signed manifests. If ManagedApplication is subject to manifest enforcement then we need to always provide one that allows it to be produced. I'd like to discuss producing the ManagedApplication interface being subject to manifest enforcement, though. It's an interface every security 2.0 app produces. Is there any other reason for this besides reducing code paths and test cases? If a security manager can cut itself off from its ability to manage an app by setting the wrong manifest, this seems a likely source of pain for security manager developers in case of a configuration error, and I don't see what we're enabling to justify the tradeoff. Recovering the app from this bad state would then either require resetting, or the security manager ignoring producer manifest enforcement. If we keep manifest assignment as part of Claim and UpdateIdentity, we can change this behavior later without having to change the interface again, if a compelling scenario comes up. ManagedApplication is the only interface I envision special casing in this way. I think of it like the physical lock on the office building door that takes a metal key, so the security staff can still get in even if the electronic badge readers malfunction. From: Swinson, Ken [mailto:[email protected]] Sent: Tuesday, February 16, 2016 4:49 PM To: Kevin Kane <[email protected]<mailto:[email protected]>>; Daniel Mihai <[email protected]<mailto:[email protected]>>; '[email protected]' <[email protected]<mailto:[email protected]>> Cc: Dave Thaler <[email protected]<mailto:[email protected]>> Subject: RE: Multiple manifests proposal for 16.04 Thanks Kevin, Please see comments inline. I think the intent was to discuss during this week's core working group call(?) so I'll keep the responses short. Ken From: Kevin Kane [mailto:[email protected]] Sent: Tuesday, February 16, 2016 11:55 AM To: Daniel Mihai; Swinson, Ken; '[email protected]' Cc: Dave Thaler Subject: RE: Multiple manifests proposal for 16.04 Hi Ken, The proposal looks good to me. I struggled a little initially with allowing a manifest to be provided under the authority of the membership certificate signer but I think I came to terms with it. My concern was with how consumers would perceive this but in the end they are free to not use this method If it is not understood. I welcome further discussion on different authorities for the manifest. One of my goals here was to look forward to possible roaming scenarios, where an app may get a membership certificate from a security manager it wasn't claimed by; it seems odd in this case to expect its home security manager to provide it with a manifest that covers interfaces provided by apps managed by the foreign security manager, and there would be no reason for those foreign apps to accept a manifest from an unknown security manager. To give a concrete scenario, if a TV app on my phone is claimed by my security manager, and I go to a friend's place and (through some as yet undetermined process) acquire a membership cert from my friend's security manager to use her TV, the manifest that lets me access that TV's interface should also come from my friend's security manager. Even if my security manager provisioned a manifest when it claimed my TV app, my friend's TV has no reason to trust it. In normal non-roaming scenarios it ends up being the same: manifests can all be issued by the identity authority. The logic for deciding which manifests to trust we can change later, but it's important to do the manifest format changes in 16.04 so we don't have a breaking change/back-compat issue later, since we seem to be okay with not being compatible with 15.09 manifests. [kens] Your friend's TV would have a policy that gives permission to the holder of the membership certificate. You seem to be using the manifest to reinforce the policy. I see the manifest(s) as providing an outer bound of what a peer is allowed to do regardless of what various security manager have decided to allow. It should allow me (the holder of the peer) to be most aware of the extent to which the peer should be allowed to interact as I am presumable most familiar with it. The backwards compatibility proposal not only provides a wildcard manifest to the 1.0 peer, it also provides a wildcard manifest to the sec 2 peer for that session. I think this is okay? Since this is from the perspective of the security 1.0 peer, you can't really say what manifest the 2.0 peer has because the concept doesn't exist. That kind of policy enforcement is out of scope in security 1.0; it would be up to the app's code to implement such a policy decision. I claim it is okay, and more importantly, there's nothing we can do differently here. [kens] Would there be the ability for a 2.0 peer to restrict itself from interacting with 1.0 peers? From the perspective of the 2.0 peer, it is not known if the contract of the remote peer enforcing the manifest is fulfilled or not. Think in terms of the 2.0 peer application developer. This developer does not want to interact in a way that is outside of what his customer has allowed but is not able to rely upon the implementation to enforce this. I assume you are planning to allow at least one manifest to be provided when the identity certificate is installed to enable the peer to be managed. Not in the same method call. I proposed removing this argument from the UpdateIdentity call, Now that you bring it up, I realize I forgot to remove the spot for the manifest in the Claim call as well. My intention is that, much like group membership certificates and policy, signed manifests are assigned to the peer after Claim in separate calls to AssignManifests. Leaving a space for one manifest in Claim or UpdateIdentity might encourage continuing to use a single manifest, and so I'd rather remove it entirely. If the org.alljoyn.Bus.Security.ManagedApplication interface isn't already a special case when it comes to manifest validation, I claim it should be. Every app should always be permitted to provide this interface no matter what. If anyone can imagine a scenario enabled by denying an app the ability to produce this interface please chime in. I can't think of one and it just seems like a pitfall for a security manager to unwittingly cut off its ability to manage an app: it erroneously assigns the wrong manifest, and boom, the core will refuse to talk to the management interface on that peer. [kens] We intentionally removed any special cases. I'm not convinced we got all of them but that was the intent. This is why we have the "default" policy. As I recall, the most significant drivers for this were reducing code paths/test cases and reducing the need for security manager to be aware of the various special cases. We also have tried not to predict the future use cases or even our understanding of current use cases where there wasn't a driving need to do so. To go back to the concept of manifests granted under the authority of the membership certificate issuer, the manifest permitting org.alljoyn.Bus.Security.ManagedApplication may not be provided with the identity certificate. To do: 1. Remove the manifest from the argument list for Claim. 2. Change the Manifest property on ManagedApplication to be called Manifests and return an array. 3. Make sure any app can provide the ManagedApplication interface after Claim. Is your thought that a security manager would typically generate one manifest for interfaces that are provided then 0 or more for interfaces the peer will consume? I assume a peer will send all manifests that contain a rule permitting the current access or will it send the one that contains the most specific matching rule? Providing this enables security managers to do the right thing, to limit information disclosure. I actually envision one manifest per interface provided, or maybe one manifest per group of closely-related interfaces. It still could generate just one monolithic manifest, but with this it doesn't have to, and recommended practice would be to scope the manifests per interface. For the interface being accessed as part of an interaction, the peer should send the minimum number of manifests that it must. The logic to do this is up to the peer, but at the very least going through the manifests and sending the first that has the interface name and the right permission bits set should be a good start. But these decisions are ultimately up to the security manager. The proposal doesn't discuss the concern we had with how generic some interfaces are. Is that coming? I'm not working on that, so it's not coming from me. Dan commented on this below. [kens] I'm okay with this approach assuming the IRB takes on this responsibility and there is adequate participating from the Security Subcommittee reviewers that are aware and understand this need. I'm not convinced the current state of the SSC staffing is adequate as it is probably reliant on too few that have the awareness of this need. From: Daniel Mihai Sent: Friday, February 12, 2016 2:14 PM To: Swinson, Ken <[email protected]<mailto:[email protected]>>; Kevin Kane <[email protected]<mailto:[email protected]>>; '[email protected]' <[email protected]<mailto:[email protected]>> Cc: Dave Thaler <[email protected]<mailto:[email protected]>> Subject: RE: Multiple manifests proposal for 16.04 >> The proposal doesn't discuss the concern we had with how generic some >> interfaces are. Is that coming? When we discussed back in November, we at MSFT adopted Dave's position that: the IRB strongly discourages such generic interfaces, and that the IRB process is a good enough mitigation. As a result, as far as I know, there aren't any changes coming up in this area. Dan From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Swinson, Ken Sent: Friday, February 12, 2016 10:24 AM To: Kevin Kane <[email protected]<mailto:[email protected]>>; '[email protected]' <[email protected]<mailto:[email protected]>> Subject: Re: [Allseen-core] Multiple manifests proposal for 16.04 Hi Kevin, The proposal looks good to me. I struggled a little initially with allowing a manifest to be provided under the authority of the membership certificate signer but I think I came to terms with it. My concern was with how consumers would perceive this but in the end they are free to not use this method If it is not understood. The backwards compatibility proposal not only provides a wildcard manifest to the 1.0 peer, it also provides a wildcard manifest to the sec 2 peer for that session. I think this is okay? I assume you are planning to allow at least one manifest to be provided when the identity certificate is installed to enable the peer to be managed. Is your thought that a security manager would typically generate one manifest for interfaces that are provided then 0 or more for interfaces the peer will consume? I assume a peer will send all manifests that contain a rule permitting the current access or will it send the one that contains the most specific matching rule? The proposal doesn't discuss the concern we had with how generic some interfaces are. Is that coming? Ken From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Kevin Kane Sent: Thursday, February 11, 2016 9:04 AM To: '[email protected]' Subject: [Allseen-core] Multiple manifests proposal for 16.04 Please review and comment on this proposal on enabling multiple manifests per peer: Motivation As of 15.09, Security 2.0 peers must present a single security manifest during the creation of a session with another peer. The security manifest is a list of capabilities granted to the peer by its claiming security manager listing the interfaces it is permitted to produce and consume. This allows apps to be scoped to particular interfaces no matter what policy might otherwise allow; an app for controlling a light bulb should not be allowed to do anything else. Well-behaved peers cryptographically validate and then enforce these manifests in addition to their own local policy when making access control decisions. The following problems have arisen with the current implementation, however: 1. Only a single manifest is supported per peer. This means that all interfaces the app can produce or consume are listed, and that list is presented to every peer with which it interacts. Because it is cryptographically protected, it must be sent in its entirety to those peers. In addition to being potentially wasteful, this represents an information disclosure vulnerability: other peers find out what the peer is capable of. The manifest may list known sensitive or privileged interfaces that disclose the peer is likely in possession of privileged credentials, and may also list the contents of private interfaces. 2. The manifest is authenticated by a digest contained in the identity certificate of the peer. This requires reissuance of the identity certificate in order to update the manifest, and limits the issuing of the manifest to the certificate authority that claimed the app. This may limit potential roaming scenarios in the future. 3. Peers operating under Security 1.0 are unable to interact with peers using Security 2.0 because they by definition have no manifest to present, and in the Security 2.0 model, an empty manifest is a manifest that denies all. We would like a way to securely enable Security 1.0-style interactions with Security 2.0-using peers, if the security manager decides that is desired. Proposal Legacy Manifests As Security 2.0 in 15.09 was labeled a developer preview feature, consensus is looking to be that support for legacy manifests should be cut, instead of maintaining and supporting two manifest mechanisms going forward. Therefore the digest stored in the identity certificate in a custom extension will be discontinued. (The extension may still be used to enable Security 1.0 peers to communicate with Security 2.0 peers; see the bottom of this proposal and ASACORE-2614.) Signed Manifests In 16.04, we will introduce signed manifests that a peer can provide instead of or in addition to the legacy manifest. We will remove SendManifest from org.alljoyn.Bus.Peer.Authentication and in its place add SendManifests, which can be invoked at any time during a secure session to send one or more signed manifests to the remote peer, and receive zero or more signed manifests in reply. The argument list for both the call and the reply will take an array of signed manifests. During the call, sending less than one manifest is an error; the reply can return with zero. This allows a consumer to present a manifest to consume a particular interface, and seeing the consumer is authorized to consume this interface, the producer can respond with a manifest showing it is authorized to produce that interface. Peers will store all manifests received during the lifetime of a secure session, and will consider the manifest check satisfied if any time-valid manifest satisfies the current request. A signed manifest contains a manifest description (with the same format as the manifest in 15.09 developer preview); the thumbprint of a certificate which can the manifest is bound to and usable by; and a digital signature over the manifest and thumbprint. The digital signature must be produced by the same key pair as signed the indicated certificate. The common case will be the thumbprint of an identity certificate, but there seems to be no need to restrict it from referring to a group membership certificate. If it's the group membership certificate that really allows access to an interface provider-side, it may be preferable for that same authority to also endorse the manifest which allows that access consumer-side. This list of manifests will be part of the state maintained for the secure session, and so only exists for its lifetime; when a new association is later created, manifests will need to be re-sent. Since changing of trust anchors implies a policy change, which implies a reset of all existing security associations, signature and trust validation of a signed manifest will be performed during the SendManifests method call, and an error returned to the caller if validation of any of the manifests fails. This will avoid storing untrusted signed manifests needlessly. Valid manifests will still be stored, so interaction can attempt to proceed, to prevent a single invalid and unrelated manifest from breaking the interaction. Management of Signed Manifests So that a security manager can install signed manifests to a peer, we will add an AssignManifests method to the the org.alljoyn.Bus.Security.ManagedApplication standard interface, which will be access-controlled to the administrative group, like most of the other methods in this interface. It will take an array of signed manifests, but it is an error to send less than one. This method will append the received manifests to the list of manifests the peer already has, and the peer can opportunistically remove manifests that have expired. The existing UpdateIdentity method's behavior will be changed to clear out all manifests; this will allow a security manager to wipe the slate clean when it reissues the identity certificate. UpdateIdentity's argument list will also have the current place for a single manifest removed. Usage of Signed Manifests Before sending a message, the sending peer will select the necessary manifest to send. SendManifests will then be called with this manifest if it's not been previously sent during the session, followed by the actual message. Security 1.0 and 2.0 Interop This section separately addresses ASACORE-2614<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fjira.allseenalliance.org%2fbrowse%2fASACORE-2614&data=01%7c01%7cDaniel.Mihai%40microsoft.com%7ca0e0de1e6021445dec2108d333d9c98e%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=iIARa9Q5df9l565SFLZmOMTFb4rjmbGIEn8%2b0u5bg2k%3d>, but is included here as it may be desirable to implement both changes together. If Security 1.0 peers wish to interact with Security 2.0 peers, they still must acquire credentials the 2.0 peers will accept, which means acquiring an identity certificate. To enable them to interact, we'll introduce a special identifier into the identity certificate the security manager can add to indicate an implied wildcard manifest that will satisfy all requests; re-using the existing AllJoyn custom extension for this purpose seems ideal, assuming Security 1.0 peers can present such certificates. This requires the security manager to explicitly sign off on a Security 1.0 peer being unconstrained by a manifest, so that a malicious peer can't simply pretend not to have a manifest; it must receive permission to not have a manifest.
_______________________________________________ Allseen-core mailing list [email protected] https://lists.allseenalliance.org/mailman/listinfo/allseen-core
