|
|
Post by josephreynolds1 on Sept 17, 2021 20:59:03 GMT
Should the Redfish spec talk about requiring additional authentication when performing sensitive operations?
For example, changing a local user account password is a "sensitive operation". If a user walks away from an active session (or that session is hacked), a bad actor can POST a new password to the account, which locks out the legitimate user. A common solution is to to require additional authentication, such as providing the old password, when changing the password.
The same issue exists when a Redfish Administrator changes a local user account password as part of a "password reset" scheme.
|
|
|
|
Post by jautor on Oct 5, 2021 0:45:07 GMT
Part of this is solved already using basic authentication - as every operation includes the "current" password (along with the "new" password in the payload). For session-based authentication, we had discussed early on that implementations were free to force a new session to be created when sensitive data was being changed for exactly this reason - but I don't think that guidance was written into the spec language.
I think this is a matter worth discussing with the group to see if we can get some interoperable behavior here. We may want to create a standard (error) message for "Session closed to force re-authentication for modifying sensitive data" in that case. I prefer this approach because it doesn't require new semantics to use or implement - and it provides flexibility for the implementation (I can choose how old a session is before it needs re-authentication, etc.).
An alternative would be to create "OldPassword" style properties that are not shown in response payloads but are used to provide the current/new settings together. The issue there is that the method is invisible to developers until they read the spec or messages, etc. to learn how that is done. The same can be said for creating an Action to change a password (with new/old as parameters).
Jeff
|
|
|
|
Post by josephreynolds1 on Sept 28, 2022 16:21:09 GMT
Thanks.
Using basic auth is not an option for me. My project (OpenBMC) implements basic auth but uses Sessions for things like Web GUI access.
Also, I'm not sure how this topic applies when the user is authenticated a mechanism such as mTLS. I think that needs to be addressed, but I'm not going to cover it in this reply.
I like the idea of using session management to force re-authentication for sensitive administrative functions:
1. The spec should define the term "sensitive function". Do we need a list? All functions which require the "ManageUsers" or "ConfigureSelf" privilege?
2. The SessionService could have a new property SessionTimeout_ForSensitiveFunctions (tbd), less than or equal to SessionTimeout, with a description like: Number of seconds of inactivity that a session attempting to perform a sensitive function may have before the session service closes.... A new message ReauthenticationRequired is sent when a user:
2a. Is logged in with a valid session, and is allowed to perform the operation request, but
2b. The user's session was started more than SessionTimeout_ForSensitiveFunctions seconds ago.
3. In this case, (should the session be deleted or remain active:
3a. Delete the session. This seems easiest and cleanest. Redfish clients would get a single SessionTimeout_ForSensitiveFunctions message, and will have to re-authenticate to get a new session (new sesionID). The new session can then be used to perform the operation.
3b. The session remains active but with ReauthenticationRequired. In this state, the session can only be deleted or re-authenticated (similar to POSTing on the SessionCollection). This has the advantage of keeping the same session credentials, but is a more complex design and implementation.
|
|
|
|
Post by jautor on Sept 29, 2022 0:59:54 GMT
I'm not sure surfacing the actual timeout for "sensitive operations" is necessary, unless we think that would be the same for all operations, and would be allowed to be changed by a user. And I'd be concerned about attempting to define/codify the list of those operations in the specification - because there will be a lot of differing implementations and opinions on that list.
But for both of those, I don't think it's necessary for us to specify them. The behavior / reaction of a client will be the same regardless - as long as we have the behavior documented (and as I suggested above, a defined message to indicate this behavior as a response code to a request).
So if we just follow your 3a. and define the message (and probably add some language to the specification to explain the expected behavior), I think we get the interoperability we'd want without getting into a long debate about what constitutes a sensitive operation or not. As long as the client can recognize the "oh, I've been logged out due to attempting (what this service deemed as) a sensitive operation, so I need to re-authenticate" - it doesn't matter what the timeout was or what the operation was... And really, the same logic should already be in any long-running client code to handle the general session timeout.
Jeff
|
|
