If an attacker can intercept and modify requests, they have complete control. Trying to protect OAuth at that point is probably not practical. If you want that then we need a confidential client with tpm storage of key material and move to signed requests and responses.
That is possible but is out of scope for this spec. The none transform protects against an attacker who can only intercept the response. The S256 transform protects against an attacker that can observe the request perhaps via a log on the device (this has happened) and intercept the response. The code verifier is short lived as is the code so an attacker would have a short time to find a collision for the S256 hash. There is no easy protection for an attacker who can modify requests. The none transform protects against a common attack that is easy to perform on iOS and more difficult but possible on other platforms. The S256 transform provides additional protection for something going wrong in the OS and leaking the code_challange. It may not be required in most cases, but in cases where it is you probably won't find out untill after the bad guys, so it is better to be safe than sorry for the overhead of a hash operation. John B. On Nov 13, 2014, at 5:13 PM, takamichi saito <sa...@cs.meiji.ac.jp> wrote: > > > 2014/11/14 11:00、Nat Sakimura <sakim...@gmail.com> のメール： > >> Regarding >> >>> Other problem is the following, using Nat’s slide: >>> http://www.slideshare.net/nat_sakimura/1112-spoppresso . >>> >>> 0. Attacker prepares own code_verifier and code_challenge. >>> 1. replage legitimate challenge with malicious code_challenge. >>> 5. Attacker can submits own code_verifier. >>> >>> It may be out of the draft, I think. >> >> I think this is out of scope. > > I agree. > But we may need to add the scope or out of the scope. > There is no definition of "A malicious client” in Section 1 of the draft, > isn’t it? > Many people can be led to misunderstand the scheme. > >> >> On Fri Nov 14 2014 at 10:46:07 John Bradley <ve7...@ve7jtb.com> wrote: >> We have discussed it and that was in fact my original recommendation. >> However I have been convinced that it adds complexity without any real >> improvement in security. >> >> The reality is that people don't bother with rainbow tables these days. >> They calculate hashes on the fly faster than they can look them up. If you >> are generating the hashes to find a collision then having fixed text that is >> known to the attacker won't help. >> >> It is better for people to have more entropy in the code verifier than to >> have a fixed block of text. I want to avoid people using less bits of >> entropy because they think the hmac is adding something. >> >> I will come up with some text for the spec, as you are not the only person >> asking that question. >> >> The other issue is that the term HMAC is scary to developers and we want >> maximum adoption. >> >> John B. >> >> Sent from my iPhone >> >>> On Nov 13, 2014, at 3:28 PM, takamichi saito <sa...@cs.meiji.ac.jp> wrote: >>> >>> >>> Hi all, >>> >>> I appreciate this idea, simple and powerful to achieve proof of possession. >>> But, I have some questions against the scheme. >>> Sorry if these ware already discussed. >>> >>> I worry about using a hash function in simple way. >>> I mean, a simple use of random as code_verifier may cause that malicious >>> client can have any code_verifier and code_challenge. >>> All combinations of random and its hash can be obtained, it may not be risk? >>> >>> So, we should use: >>> S256 "code_challenge" = BASE64URL(SHA256("code_verifier" + “client ID”)) >>> or >>> S256 "code_challenge" = BASE64URL(SHA256("code_verifier" + “client ID” + >>> “server ID”)) >>> Where, you know that client ID is client’s unique name. >>> >>> >>> Other problem is the following, using Nat’s slide: >>> http://www.slideshare.net/nat_sakimura/1112-spoppresso . >>> >>> 0. Attacker prepares own code_verifier and code_challenge. >>> 1. replage legitimate challenge with malicious code_challenge. >>> 5. Attacker can submits own code_verifier. >>> >>> It may be out of the draft, I think. >>> >>> Best regards, >>> >>> >>> ;; takamixhi saito >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > > ;; takamixhi saito > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
