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

[Ben Laurie <[e-mail]>]

On 6 June 2015 at 02:48, John Bradley <[e-mail]> wrote:
> inline
>> On Jun 5, 2015, at 11:56 AM, Ben Laurie <[e-mail]> wrote:
>>
>> On 5 June 2015 at 14:54, John Bradley <[e-mail]> wrote:
>>> 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 <[e-mail]> wrote:
>>>>
>>>> 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?
>>>>
>>> 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.
>>
>> Ah, I see. Though you then have to explain why you are constraining to
>> 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.

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.

>
>>
>>>> 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.
>>>>
>>>
>>> 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.
>>
>> 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?
>>
>
> 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.

Fine.

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