Choosing the right architecture to establish and maintain a user session with the “authentic” user.
The purpose of this blog is to examine the issues related to a Relying Party (RP) authenticating a user, establishing a user session with that user, and then maintaining confidence that the user at the other end of the session (the endpoint) continues to be the “authentic user” for the duration of the user session. We start from the premise that asymmetric key based authentication is superior to other methods such as SMS text and OTP. Rather we focus just on the issue of endpoint vs out of band authentication.
Concepts and definitions used in this blog include:
· Authentication Channel: The channel or path between parties used to perform the authentication in the first place to establish the user session
· Re-authentication Channel: The channel or path used to maintain the session between the RP and the user.
· User Session: The connection between the RP and the authentic user on an end point device. The user session exists at a level above the underlying communication over the network and may persist for hours, days or weeks across even reboots or power cycles.
· End Point Device: The device (e.g., computer or phone etc.) that is on the user end of the user session between the RP and the authentic user.
· In-Band Authentication Channel: An authentication channel directly between the RP and the user/endpoint.
· Out Of Band Authentication Channel: An authentication channel separate from which will be used to access the service of the RP
Authentication
In-Band Authentication vs Out Of Band Authentication Channel
To establish a user session between the RP and the authentic user / end point device there are two basic options; In-Band Authentication and Out Of Band Authentication channel.
With an In-Band Authentication channel the user on the end point device creates a user session directly with the RP and authenticates. Examples include:
· A user on a laptop connecting to a website site from their browser and using a FIDO2 authenticator to authenticate.
· A user on a phone connecting to their bank from the bank’s App with FIDO UAF authentication built in to the App
In-Band authentication has the property that the device that the user is accessing the service with (or something directly connected to it) is also the “something you have” factor. With in-band authentication the User Session used to perform the authentication is the same session that the user communicates to the RP to access the service it provides.
With an Out Of Band Authentication channel the authentication is done on a channel separate from which will be used to access the service of the RP. A common example would be an out of band channel to a phone to authenticate a user accessing a web site from a web browser on their laptop. The Out Of Band Authentication channel has an inherent architectural incorrectness because it separate from the user session to be used to access the service. The authentication must be tightly bound to the authentic user and the RP but attackers can find ways to break that association when an Out Of Band Authentication channel is used.
Re-Authentication
Once a user has authenticated to a RP and established a user session between the two the RP needs to maintain confidence that the user is still the authentic user over time and other events that require re-authentication. This can be done with a session cookie or token that the RP can store on the user’s end point device or by an explicit re-authentication request. The recent SolarWinds / Sunburst attack (See https://www.winmagic.com/blog/can-the-solarwinds-mfa-bypass-attacks-be-prevented/)has shown that the passive cookie approach is vulnerable to attack so something stronger is required to maintain that confidence; a reauthentication or attestation. We call that an active cookie protected by the endpoint not a server key. The user / end point device needs to prove that they are still the authenticate user and in control of the end point device with which they are accessing the RP service on a more or less ongoing basis. This is where the architectural incorrectness of Out Of Band Authentication Channel becomes even more apparent. The out of band authentication method cannot be used to attest or verify this in any sort of meaningful or automated way because it is separate from the user session. Only the endpoint can attest that it is still the same endpoint on an ongoing basis with what might be called an active cookie.
With the In-Band Authentication method the continuous re-authentication can be automated for as long as the original end point is still at one end of the user session. For example, with FIDO this could take the form of a silent assertion (of course the original authentication would still require User Presence or User Verification) or the FIDO authenticator signing the session ID cookie that also contains a sequence number (an active cookie).
Conclusion:
Out of band authentication has an inherent architectural incorrectness. Many out of band authentication vulnerabilities have already been exploited. Even if these issues can be somehow addressed the use of an out of band authentication channel makes it almost impossible to address emerging threats where ongoing re-authentication is required.
