PASE support for access control #10242
Comments
|
Current approach will be to store PASE verifier IDs in type NodeId in the subject descriptor, since the upper bits have discriminating ranges we can use to tell what "type" of NodeId it is. |
|
PR #13003 provides a place to do this. In theory it's done for the PASE session and verifier ID (as subject), but upstream code needs some fixes before it works (needs to provide the SessionHandle.mPeerNodeId with discriminating high bits set properly). In addition, SubjectDescriptor.fabricIndex needs to be set properly, because there are some cases during commissioning where a fabric is available (e.g. to create ACL entries for that fabric), before switching to CASE. This isn't done yet, in part because it also needs to be tested. |
Peer node ID for PASE sessions is the passcode ID with discriminant in the top bits (to discriminate it from other kinds of node ID). Also, passcode ID cannot be zero in non-default commissioning cases. Progress towards project-chip#10242
Peer node ID for PASE sessions is the passcode ID with discriminant in the top bits (to discriminate it from other kinds of node ID). Also, passcode ID cannot be zero in non-default commissioning cases. Progress towards #10242
PASE sessions start with no fabric, but during commissioning, after OperationalCredentialsCluster::AddNOC, they should be placed on the newly commissioned fabric so administrative actions pertaining to the newly commissioned fabric can be performed over the PASE session, if desired. Work towards issue project-chip#10242
* Place PASESession on new fabric PASE sessions start with no fabric, but during commissioning, after OperationalCredentialsCluster::AddNOC, they should be placed on the newly commissioned fabric so administrative actions pertaining to the newly commissioned fabric can be performed over the PASE session, if desired. Work towards issue #10242 * Change SecureSession::NewFabric to alter mFabric This makes it easier to also have it be the accessing fabric after the change.
|
Almost everything in the list is done. There's still some churn on migrating the PASE session to the new fabric index. (E.g. see PR #13765) Still need to handle the "implicit PASE admin during commissioning" in AccessControl::Check, including getting a commissioning flag down there, so we can ensure the PASE session in the subject descriptor is the one doing commissioning. But actually, there appears to be a desire to just edit the spec to disallow explicit PASE ACL entries for v1 (because PASE is only for commissioning, and multi-fabric is tricky with PASE), so if we do this spec change, and enforce that PASE is only able to connect during commissioning, we can just simply do "any PASE subject gets admin privilege" in AccessControl::Check. |
mlepage-google
changed the title
|
Spec change for reserving explicit PASE ACL entries for future use: |
* Place PASESession on new fabric PASE sessions start with no fabric, but during commissioning, after OperationalCredentialsCluster::AddNOC, they should be placed on the newly commissioned fabric so administrative actions pertaining to the newly commissioned fabric can be performed over the PASE session, if desired. Work towards issue project-chip#10242 * Change SecureSession::NewFabric to alter mFabric This makes it easier to also have it be the accessing fabric after the change.
We won't have explicit operational PASE ACL entries for v1.0. We will enforce that PASE is only during commissioning, therefore all PASE subjects will be granted administer privilege. Past v1.0, if/when we want operational PASE (requires solving some tricky multi-fabric issues), we'll have to check against PASE subjects in entries, and also for implicite PASE administer privilege during commissioning we'll have to verify that the incoming PASE subject is commissioning (otherwise it should not get that implicit privilege escalation). Part of issue project-chip#10242
|
PR #14550 will affect the required change in AccessControl::Check, should not go in until the spec change goes in. We'll need to double check that PASE sessions are only ever allowed during commissioning for v1.0 (and that this is enforced). If we only ever allow them on PAKE Verifier Key ID 0, I can add a verify/check for that as well. |
* Disallow operational PASE in AccessControl::Check We won't have explicit operational PASE ACL entries for v1.0. We will enforce that PASE is only during commissioning, therefore all PASE subjects will be granted administer privilege. Past v1.0, if/when we want operational PASE (requires solving some tricky multi-fabric issues), we'll have to check against PASE subjects in entries, and also for implicite PASE administer privilege during commissioning we'll have to verify that the incoming PASE subject is commissioning (otherwise it should not get that implicit privilege escalation). Part of issue #10242 * Update unit tests * Use unused variable in test code To avoid warning about unused variable.
andy31415
added
v1_triage_split_2
V1.0
acl
OK since non-zero passcode ID for PASE sessions during commissioning is required for multi-fabric-admin, we cannot have any checks to ensure passcode ID is 0 (because it isn't always 0). But, it is always commissioning. (Still needs to be enforced that it's only for commissioning, because we're going to be granting it administer privileges.) |
|
Final piece of the puzzle is tracked in issue #14604. |
|
All work for this in v1 is done in access control, anything dangling is tracked in other issues. |
Peer node ID for PASE sessions is the passcode ID with discriminant in the top bits (to discriminate it from other kinds of node ID). Also, passcode ID cannot be zero in non-default commissioning cases. Progress towards project-chip#10242
The text was updated successfully, but these errors were encountered: