When should client authentication be required?

[jmandel]

When should client authentication be a required element? There should be a specific threat that needs to be addressed, rather than simply "be capable of protecting a secret" -- otherwise, folks might choose to not use client authentication when it really should be doing so. The below is my recommendation. In addition, this prescribes the use PKI mechanisms in-line with the proposed EHR-to-EHR bits.

In-context at: http://fhir-docs.smarthealthit.org/argonaut-dev/specification/#q-issue-79

[jmandel]

I see compromised refresh tokens as one important threat that client authentication helps mitigate. But using client authentication whenever possible is also just part of a good "defense in depth" strategy -- e.g. it can prevent an attacker from fraudulently obtaining access tokens in a situation where a server's SSL certificates are compromised.

[whitehatguy]

@jmandel -- I'm partially in agreement with your statement; we could add such a sentiment, but I wanted to ensure that we call out the scenarios where it is a hard requirement. Here's an example scenario where a system could protect a client secret, but doing so doesn't protect against the threat you mentioned:

1. Web application protects a client secret.
2. Web application functions by pushing access tokens that it obtains down to the browser where javascript / CORS+XHR is used to invoke remote services.
3. Web application's certificate is compromised.
4. An attacker with access to a compromised network component (WAP, switch, etc.) uses the fraudulent certificate to eavesdrop communication to the client application's web site.

In this case, a man-in-the-middle attack still would allow an attacker to fraudulently obtain access tokens. Even if we outright required that applications not follow this architectural pattern, an attacker would likely still be able to get some data just by invoking requests the user would normally be able to perform. A client developer might successfully argue that such a requirement doesn't add additional security, and thus should be exempted from the requirement.

[jmandel]

Of course your analysis of the scenario you provided here is correct. But I wasn't trying to claim that client authentication was a universal panacea against ssl certificate compromise -- just that in some scenarios it helps (e.g. when a client keeps its authentication tokens on a secure Web server).

Another threat that client authentication protects against is the scenario where a client developer accidentally creates an open redirector at a valid redirect_uri. Of course the best policy is "don't create open redirects", and our specs attempt to prevent this by describing a highly restrictive redirect_uri matching policy -- but sometimes mistakes are introduced into real-world implementations. Again, client authentication is part of a defense in depth approach.

So I think as a rule of thumb, "clients that can keep secrets should be registered confidential clients" is a good one -- but I'm certainly not against a more nuanced explanation as long as it doesn't obscure the point.

On Tue, Aug 18, 2015, 10:41 Matt Randall <notifications@github.com

wrote:

@jmandel https://github.com/jmandel -- I'm partially in agreement with your statement; we could add such a sentiment, but I wanted to ensure that we call out the scenarios where it is a hard requirement. Here's an example scenario where a system could protect a client secret, but doing so doesn't protect against the threat you mentioned:

Web application protects a client secret. Web application functions by pushing access tokens that it obtains down to the browser where javascript / CORS+XHR is used to invoke remote services. Web application's certificate is compromised. An attacker with access to a compromised network component (WAP, switch, etc.) uses the fraudulent certificate to eavesdrop communication to the client application's web site.

In this case, a man-in-the-middle attack still would allow an attacker to fraudulently obtain access tokens. Even if we outright required that applications not follow this architectural pattern, an attacker would likely still be able to get some data just by invoking requests the user would normally be able to perform. A client developer might successfully argue that such a requirement doesn't add additional security, and thus should be exempted from the requirement.

— Reply to this email directly or view it on GitHub https://github.com/smart-on-fhir/smart-on-fhir.github.io/issues/79#issuecomment-132235375.<img src=" https://ci4.googleusercontent.com/proxy/wJIxFXuTzJIo_xakLEJ-HsWgL70-9iCJ6_DnyC0L-1rh7lIjJJmyO5PQPyEE57hNykIvrJ_VcFR9k039Z0SnJohnpWZoXKpLDTtOaEGpJr5Fa8bOwBPpAmrG2yD6OQ3r-qAMQj8XlJB63vw2P4Vw_4McYQzDmA=s0-d-e1-ft#https://github.com/notifications/beacon/AATHAc2eMyg81tvhETU0E0HoD-r_kvC8ks5oozuXgaJpZM4Fr-Zj.gif ">

[whitehatguy]

I think to summarize where we're in agreement:

• The specification recommends using client authentication wherever it is practically possible.

...and where I'm not certain if we're in agreement on hard requirement versus recommendation:

• The specification requires that client applications storing refresh tokens in a central location utilize client authentication.

[jmandel]

Well, "wherever it is practically possible" is a bit ambiguous. For example, is it "practically possible" for an in-browser app to have a (non-secret) client secret and thereby "use authentication"?

On Tue, Aug 18, 2015 at 2:06 PM, Matt Randall notifications@github.com wrote:

I think to summarize where we're in agreement:

• The specification recommends using client authentication wherever it is practically possible.

...and where I'm not certain if we're in agreement on hard requirement versus recommendation:

• The specification requires that client applications storing refresh tokens in a central location utilize client authentication.

— Reply to this email directly or view it on GitHub https://github.com/smart-on-fhir/smart-on-fhir.github.io/issues/79#issuecomment-132301216 .

[whitehatguy]

Well, "wherever it is practically possible" is a bit ambiguous.

Agreed on that point -- for what its worth, I hadn't intended on patching with that specific wording.

For example, is it "practically possible" for an in-browser app to have a (non-secret) client secret and thereby "use authentication"?

If the app is exposed as a static resource on a private (authenticated) network, and the secret inside the static content is rotated frequently (perhaps generated by a script daily), that might be both practically possible and have desirable security characteristics. Perhaps the best solution would be to simply point to the appropriate sections of the OAuth 2.0 security guidance rather than try and write our own equivalent? Even then, it's difficult to boil some of these things down to a decision tree.

[ghost]

Our current authorization profile requires confidential clients to authenticate themselves when exchanging an authorization code for an access token, and when presenting a refresh token for a new access token. It does not require that public clients present any kind of authentication credential.

But I agree that whether a client presents a credential to the AS shouldn’t be based on whether the client can protect a secret, but should be based on the specific threat. The “specific threat” here is an unauthorized entity capturing an access token or a refresh token – with the resulting risk being the unauthorized disclosure of PHI. This risk is applicable to both public and confidential clients, though the vulnerabilities are different between the two. I would agree that where a refresh token is stored may create a vulnerability, thereby affecting risk. However, this is just one implementation consideration, and I don’t think it would be wise for us to attempt to enumerate all design variations that affect risk.

The decision as to when a client should “be authenticated” is a decision the AS makes based on institutional policy. However, our specification does need to state what a client needs to present to the AS and under what circumstances. I agree that there are use cases where institutional policy may not require that certain clients be authenticated. To allow all of these variations in institutional policy and technical implementation, I suggest we say that IF the client holds a credential that can be used to authenticate the client’s identity, the client SHOULD present the credential along with any authorization code and refresh token it presents to the AS. That leaves it up to institutional policy to determine what clients are issued credentials, and what the AS does in response to receiving the request.

[whitehatguy]

I'm in favor of Dixie's analysis (the client SHOULD present any credential it possesses, institutional policy defines whether the credential is required for the given app.) I'm in agreement that we shouldn't enumerate all possible threats that should require client authentication -- should we at least provide a non-normative example (e.g. a static javascript app) where institutional policy may not require authentication?

[jmandel]

This analysis is certainly fair, and I agree with the sentiment. The issue I see, though, is that if we simply say the decision about which apps should have/use credentials is left up to "institutional policy", we may find ourselves in a situation where:

1. A desire for the appearance of security leads to provisioning client keys in situations where they just don't help (e.g. in-browser static HTML5/JS apps).
2. An app developer has to maintain multiple versions of an application to comply with varying policies, even though these policies don't enable meaningfully different security.

So I'd still like to see us say something affirmative about when client authentication should be used, and why. And sure, at the end of the day, institutional policy is a trump card.

-J

On Tue, Sep 29, 2015 at 9:44 AM, Matt Randall notifications@github.com wrote:

I'm in favor of Dixie's analysis (the client SHOULD present any credential it possesses, institutional policy defines whether the credential is required for the given app.) I'm in agreement that we shouldn't enumerate all possible threats that should require client authentication -- should we at least provide a non-normative example (e.g. a static javascript app) where institutional policy may not require authentication?

— Reply to this email directly or view it on GitHub https://github.com/smart-on-fhir/smart-on-fhir.github.io/issues/79#issuecomment-144064046 .

[whitehatguy]

Here's some proposed guidance for the security considerations:

• If a client application's architecture utilizes access tokens on the user's local device (e.g. via Javascript, native application), and such access utilizes the full set of scopes the client application may be authorized for, then client authentication SHOULD NOT be required; requiring such provides no additional security benefit.
• if a client application's architecture utilizes access tokens with the scope of offline_access that are shared outside of the user's local device (e.g. a remote server under control of the client application), clients SHOULD be required to obtain or refresh such tokens. This ensures that such tokens need not be revoked in the event of compromise, only that the client's credentials be changed.

I'm on the border of saying we ought to require client credentials for any form of offline_access, but that would get into the need for explicit definition of how native client apps would register credentials.