Subject: [secdir] Secdir review of draft-ietf-oauth-spop-11

From: Ben Laurie <[email-masked]>
Date: Fri, 5 Jun 2015 13:44:39 +0100

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

Status: ready with issues.

It is disappointing that such a protocol must be introduced to work
around security deficiencies in application platforms - have these
security issues been reported to vendors?

Anyway, issues:

1. Security consideration says: "Concatenating a publicly known value
to a code_challenge
   (with 256 bits of entropy) and then hashing it with SHA256 would
   actually reduce the entropy in the resulting code_verifier making it
   easier for an attacker to brute force." This makes no sense. A
brute force attack would still require iteration of 2^256 inputs. How
is that easier?

2. The introduction says "No client secret is used (since public
clients cannot keep their secrets confidential.)". However, a client
secret is used. I suspect I know what is intended, but this should be
clarified.

---

From: John Bradley <[email-masked]>
Date: Fri, 5 Jun 2015 10:54:08 -0300

Thanks for the review Ben.

The security issue is well known to Apple and the subject of debate for some time.

OAuth states native applications SHOULD use the system browser to train users not to expose credentials to applications.

Apples approach to this point has been to recommend application developers use web views to get around the feature/security issue of insecure inter application communications.

This is documenting the work around that Google , Ping, T-Mobile and others have in production to work around the issue of multiple applications being allowed to register the same custom scheme and not prompting the user about what app to return to.

Prompting the user as on Android is only a partial solution as users are not perfect.  So doing a proof for code is not a bad thing, and may prevent new attacks on public clients.

The OIDF NAPPS working group is working with MDM vendors, Google, Microsoft (for there apps on other platforms), to develop a better identity API approach for native apps.
We are hoping that can provide a better long term solution for platforms.

I will also note that custom per IdP API solutions have not always worked.  Facebook has recently abandoned the custom solution apple provided them with in iOS as apple was not able to keep up with changes on the Facebook side.

From a protocol point of view this was the best we could come up with to deal with the issue now.

Inline.
> On Jun 5, 2015, at 9:44 AM, Ben Laurie <[email-masked]> wrote:
> 
I can try an make it clearer that the 256 bits being referred to is the total size of salt + secret.

The point we were trying to make is that if the salt is included in the 256 bit input then the attack space is reduced by the size of the nonce. 
If you make the hash bigger then you are still better off making all the entropy secret.

An example would be having a 128 bit salt that is known and a 128 bit secret.  A brute force attack would require 2^128 inputs rather than 2^256 inputs if it were all secret.

This came from a request to explain why we don’t have a salt to protect against rainbow table lookup, like passwords.

> secret is used. I suspect I know what is intended, but this should be

How about?

3) The attacker has access to the client id and client secret (if provisioned).  All native app client-
      instances use the same client id, and client secret.  Secrets provisioned in client binaries cannot be considered confidential.

John B.

> _______________________________________________
> secdir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

---

From: Ben Laurie <[email-masked]>
Date: Fri, 5 Jun 2015 15:56:19 +0100

> This came from a request to explain why we don’t have a salt to protect against rainbow table lookup, like passwords.

Ah, I see. Though you then have to explain why you are constraining to
256 bits...

>       instances use the same client id, and client secret.  Secrets provisioned in client binaries cannot be considered confidential.

I think the issue is that "client secret" has meaning independent of
OAuth, but you are using it in the sense that the OAuth standards use
it - perhaps "OAuth client secret" would make this clearer?

---

From: John Bradley <[email-masked]>
Date: Fri, 5 Jun 2015 22:48:00 -0300

inline
> On Jun 5, 2015, at 11:56 AM, Ben Laurie <[email-masked]> wrote:
> 
> 256 bits…

This wouldn't apply to the plain transform.   For the S256 transform having more than 256bits of entropy is just more work for no benefit.

Later someone could define a SHA512 transform if they want to use more entropy, though 256bits is probably enough unless some flaw is found in SHA256.
We did debate truncating the hash as 256bits is probably overkill for a single use challenge at this point, but that would have introduced possible implementation errors, and only provide a small saving of message size.

A asymmetric transform is also possible as an extension once we have Token Binding completed and deployed,  but that is future work.

For the moment SHA 256 with 256bits of entropy for the input to generate a key for a single use token, is infeasible to brute force. 

How about?

3) The attacker has access to the OAuth client id and OAuth client secret (if provisioned).  All OAuth native app client-
     instances use the same client id, and client secret.  Secrets provisioned in client binaries cannot be considered confidential.

John B.

---

From: Ben Laurie <[email-masked]>
Date: Sat, 6 Jun 2015 10:03:04 +0100

> For the moment SHA 256 with 256bits of entropy for the input to generate a key for a single use token, is infeasible to brute force.

I agree. But we're not debating that, we're debating the claim that
adding salt reduces attack cost. Which is only true if you add an
artificial constraint on input size.

>      instances use the same client id, and client secret.  Secrets provisioned in client binaries cannot be considered confidential.

Fine.

---

From: John Bradley <[email-masked]>
Date: Sat, 6 Jun 2015 12:52:22 -0300

Ben,

I have updated the draft based on your feedback.

I changed the wording in the security consideration to say that adding a salt doesn’t increase the workload for an attacker given 256 bits of entropy and a sha256 hash.

Let me know if that wording works for you.

John B.
> On Jun 6, 2015, at 6:03 AM, Ben Laurie <[email-masked]> wrote:
>