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. 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. 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. 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. From: Daniel Mihai Sent: Friday, February 12, 2016 2:14 PM To: Swinson, Ken <[email protected]>; Kevin Kane <[email protected]>; '[email protected]' <[email protected]> Cc: Dave Thaler <[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
