Caching TLS Session Results in Device Retaining PSK and UUID after RESET
During interactions between an IoTivity-Lite OCF client and server, a TLS session is cached. There are two behaviors as a result:
- When an OBT is used to perform ownership transfer on client and server, and then provisions the proper credentials (pairwise symmetric key) and ACEs for the client to operate on the server, the change is not reflected in a cached TLS session. For example, the server returns OC_STATUS_UNAUTHORIZED to a client before credentials are provisioned and an ACE is provisioned to the server, and the session is cached. However, after provisioning credentials and an ACE to the server, the client still receives OC_STATUS_UNAUTHORIZED (so long as it is not reinitialized or the session is closed and reopened).
- Of more concern
- is the case where the client and server have been provisioned the necessary credentials and ACE for normal operation. Both devices are RFNOP, and the client can perform operations on the server properly (e.g., toggling an oic.r.switch.binary). If the OBT initiates a hard RESET on the client, the credential store is erased and the client's UUID is reset. However, the cached TLS session retains the pairwise credential as well as the UUID, and so the client is able to continue operating on the server, despite being reset and back to RFOTM. The most notable aspect of this issue is the retention of the UUID, which is able to continue matching against a subject UUID in the ACL of the server- from the server's perspective, the client is still able to perform operations. This behavior may continue until the session is closed.
Steps to reproduce 2nd behavior:
- Onboard an OCF server and client, and provision the proper credentials and ACE for the client to perform operations on the server.
- Reinitialize the client and the server (which should be able to interact in RFNOP state at this point).
- During these operations, use the OBT to perform a hard RESET on the client.
- Without reinitializing the client, observe the fact that the client can still operate on the server, despite being RFOTM and having a reset UUID.
JIRA migration meta data
- JIRA Issue ID: LITE-77
- Reporter: adolan
- Assignee: adolan
- Creator: adolan
- Created at: 2019-08-09T15:36:31.000-0700
- Found in Version: Tag GETTING_STARTED_2 (Commit 822ab4a2)
- Fix in Version: None
- Issue Severity: Critical
- Reproducibility: Always (100%)
- Operating System: Ubuntu
- Hardware/ OEM Platform: None
- External URL: None
- Bugzilla ID: None
- Product: None
- Status: Done
- Components: security
- Priority: Undecided
- Due Date: None
Issue Type: Bug
END of JIRA migration meta data