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://jira.allseenalliance.org/browse/ASACORE-2614>, 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
