In Draft draft-jones-oauth-mix-up-mitigation-01 the iss in the response is compared to the iss that the request was made to, and if they are different it is an error.
Discovery is done only during registration. This is a point Mike and I have some disagreement on. He would like to do late binding of the issuer and do discovery on the returned issuer to support multi tenant. I think late binding introduces many issues most importantly enabling the easy theft of symmetric client credentials. The string compared could just be a string like a SAML EntityID, and that works as long as clients limit themselves to only one client_id per iss string. The reason it has to be only one is that you could have a bad guy claiming to have the same iss as another AS. Without checking the integrity of the Authorization URI and token endpoint URI then you leave yourself open to attack with multiple client_id with the same iss. In the discovery step iss x points to Authorization endpoint x and token endpoint X if you send a request to auth X of iss X and it says my iss is X then you are sage to send code to the token endpoint of iss X. A uer tampering with iss just breaks the flow and results in an error. They could change it to another valid iss for the client but then the client state sent it to X and got it back from Y would cause a error. I agree that it is important that clients understand that the endpoint configuration step is separate from the authorization flow, and the iss in the authorization response is an identifier only. (Yes one that can be validated by discovery separately) Having the client compare the iss and client strings that it used for the request with the response and throwing an error if they are different still seems like the simplest solution to me. That unfortunately means limiting the client to one client_id per iss without discovery. John B. > On Jan 28, 2016, at 3:16 AM, Manger, James <james.h.man...@team.telstra.com> > wrote: > > Even if theoretically secure, I don’t think it is a good idea to send turi > and require the client app to confirm it matches (or send duri and match > issuer+well-known…). It will be too tempting to client apps to just use the > turi/duri value. > > draft-jones-oauth-mix-up-mitigation-01 is slightly better in sending an "iss" > id to match, instead of a web address to follow. However, "iss" is actually a > URI and is defined as the basis for discovery. If an app did discovery based > on "iss" from the redirect it would be insecure. So I think apps using > different redirect URIs for different ASs is a better idea (which happens to > be the fix suggested in the paper on the “IdP Mix-Up” attack). > > If we have to send something that another party should match, but not > otherwise use, it might be better to send a hash instead of the actual value. > That feel much harder for apps or servers to accidentally misuse insecurely. > > -- > James Manger > > > From: Nat Sakimura [mailto:n-sakim...@nri.co.jp] > Sent: Thursday, 28 January 2016 3:02 PM > To: Manger, James <james.h.man...@team.telstra.com>; oauth@ietf.org > Subject: RE: [OAUTH-WG] oauth-meta: turi allows user to mislead app > > Hi James, <> > > Right. I thought of the man-in-the-browser case and was originally thinking > of sending them in signed JWT(state,c_hash,a_hash,turi,ruri,duri,…) or > sending HMAC(sha256, state+code+turi+ruri, client_secret) together but > subsequently dropped the idea as anything is broken in the man-in-the-browser > case. The bad user case did not occur to me then. I should not have dropped > the idea. Incidentally, this probably fixes the cut-n-paste attack as well. > For OpenID Connect, it amounts to returning these parameters in ID Token in > the front channel. As you can expect, this is my preferred way. > > If we do not want any crypto, then there has to be additional checks. > In case of duri, mandating the client to check that the duri = issuer + > .well-known/openid-configuration. > For turi, it has to match one of the entry listed in the discovery document > or or pre-set configuration. The same applies for ruri. > We probably want to have a cut-n-paste attack control in place as well. > > For the token endpoint response that does not go through user browser, it > should be ok to accept it as true. > > -- > PLEASE READ :This e-mail is confidential and intended for the > named recipient only. If you are not an intended recipient, > please notify the sender and delete this e-mail. > > From: OAuth [mailto:oauth-boun...@ietf.org <mailto:oauth-boun...@ietf.org>] > On Behalf Of Manger, James > Sent: Thursday, January 28, 2016 11:38 AM > To: oauth@ietf.org <mailto:oauth@ietf.org> > Subject: [OAUTH-WG] oauth-meta: turi allows user to mislead app > > The OAuth-Meta draft <draft-sakimura-oauth-meta-05> returns the token > endpoint (in a "turi" query parameter) when redirecting a user from the > authorization endpoint back to an app. The app presumably then POSTs the > "code" (also in the redirect) to "turi" to get an access token. However, apps > typically send their client_secret to the token endpoint to authenticate. > Sending a client_secret to a URI that came from a user is insecure. > > A RESTful OAuth would be a great improvement, but it doesn’t look like > providing the token endpoint (nor discovery endpoint) in a redirect is the > right approach. > > -- > James Manger > > _______________________________________________ > 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
