Thanks, Thats why we have these reviews to help us poor authors get the stuff in our heads down in the specs, if it is not clear.
Once we have all the feedback from the reviews, I will see how I can work this back into the non normative text. John B. > On Jun 11, 2015, at 6:45 AM, Alexey Melnikov <[email protected]> > wrote: > > Hi John, > > On 11/06/2015 14:40, John Bradley wrote: >> The idea is that the communication in the first request request to the >> authorization endpoint is via a secure path that the attacker can’t modify. >> >> That is where the code_challenge and code_challenge_method are bound to the >> code. we expect that will be done by creating some extra columns a internal >> DB that is used to store whatever grants the AS is attaching to the code , >> client_id, and redirect_uri used. The AS needs all of those things for >> standard OAuth, so we are just adding two new things fro them to track. >> >> It is the response from the AS to the client that gets hijacked. >> >> If a bad client has the code, you don’t really want it to be able to >> downgrade the code_challenge_method. >> >> Sending code_challenge_method to the token endpoint would require that it be >> matched against the one stored in the db at the AS, so best case it is extra >> stuff to send with no value, worst case would be that a AS ignores the one >> from the authorization request and acts on the one to the token endpoint >> allowing a downgrade attack. >> >> The downgrade attack to plain is still impractical if they haven’t captured >> the authorization request, but that is no reason to do more work for less >> security. >> >> I hope that helps explain the logic. > This is fine, but I wish you've said that in the document! This was not clear. >> Regards >> John B. >> >>> On Jun 11, 2015, at 5:57 AM, Alexey Melnikov <[email protected]> >>> wrote: >>> >>> Hi John, >>> >>> On 11/06/2015 13:51, John Bradley wrote: >>>> I believe that the other comments were all-ready addressed in draft 12 as >>>> a result of Ben Laurie’s comments from last week. >>>> >>>> If Alexey can double check that I got everything that would be great. I >>>> re-worked those sections to capture Ben’s comments. >>> My comment on 7.1/7.3 is addressed. >>> >>> Can you elaborate a bit on why code_challenge_method is not needed in 4.5? >>>> John B. >>>> >>>>> On Jun 11, 2015, at 3:00 AM, Jari Arkko <[email protected]> wrote: >>>>> >>>>> Thanks for your review, Alexey. I have followed the discussion about >>>>> plain with interest, but will leave holding the discuss to Barry. >>>>> >>>>> John, it was not clear to me if you had done everything you needed to with >>>>> respect to Alexey’s other comments (reproduced below). Have you? >>>>> >>>>>> Minor Concerns: >>>>>> >>>>>> Is code_challenge_method missing in 4.5? >>>>>> >>>>>> Sections 7.1 and 7.3 are talking about the same thing? Should they be >>>>>> merged into one? If they are not talking about the same thing, should >>>>>> they be named differently? >>>>> Jari _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
