Internet Engineering Task Force Interim Meetings, 26 Oct 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: OAUTH WG Interim Meeting, 2020-10-26

Description

OAUTH WG Interim Meeting, 2020-10-26

A

This is starting: oh yeah, okay, perfect yeah! Thank you. Okay, uh welcome everyone. So this is um the first day internet meeting the working group enter meeting um just uh as a reminder, and not well applies here. So if you're not familiar with this, please make sure you understand what that means.

A

um What we are going to talk about here is a security bcp this week, so we still have two more meetings. um Next week we'll be talking about, is logged in and web id, so make sure to attend this meeting, and in november 30th um we will be talking about d-pop.

A

So this is our schedule for the coming um a few weeks um before we switch it to a give it to daniel. I just want to um talk about one topic.

A

There was some flair of activities around there or literally of discussions about just want to make sure that it is clear uh that currently, the authby group is not working on any new version of oauth protocol and we are working with them with roman, to kind of put the official statement to clarify the proper way of bringing um any work to the author group and working on a new version of this protocol, and so this is just a statement and just to make it clear what what the status of uh of any welcome name was that the 3.0 here is we, don't we don't while working on any anything like this, and we will talk about a proper way of doing this?

A

Okay, so that's a that's a lot. All we have from a kind of a church perspective. I will hand it now to uh to daniel to talk talk us through stop sharing here to talk about security bcp. Thank you.

B

C

Okay, let me find the right screen here.

C

Okay, you should now see something: yes, excellent, okay, um welcome everybody here today um we want to talk about the auth to security, best current practice document, which is a graph by torsten, john andre, and me.

C

The document itself, as I guess most of you know, sets out to describe the best current security practice for what two it updates and extends the auth to security threat model.

C

We try to incorporate experience from practice, as well as from research and cover new threats that are relevant to earth too, in particular also those that arise in high-risk environments, for example, in open banking environments or when auth is used to um yeah in eid schemes or for electronic signatures or applications like that.

C

um This is a relatively old draft. um I think it started in 2016 or something we had the first working group last call end of last year, that was on version 13..

C

We got a lot of feedback on that very good feedback, um but it also meant we had to do a lot of work still um now we are at version 16, and I think that things are looking much better than they did last time. um So yeah.

D

C

Let's, let's go through the changes that we made since version 13., so what's new um one thing is that we notice that you can do something which we called pixie downgrade attacks um relatively simple: an attacker uses a stone, non-pixie bound code and injects it into a flow where pixi is actually used.

C

If the authorization server can handle both non-pixyflows and pixelflows, then the authorization server might accept the non-pixie bound code, although in the current flow declined things it's using pixy to protect itself, we have a more detailed description of the attack, of course, in the document.

C

um Our new recommendation regarding this attack is that authorization servers must ensure that if there was no code challenge in the authorization request, a request to the token endpoint that contains a code verifier uh must be rejected. So this is, as we heard, also something that uh implementations actually or some implementations already do. um So I suspect this is a relatively small range.

C

Then we have some uh smaller changes regarding uh pixie and nons, and the recommendations around that a new recommendation is that I think it's a very natural thing. Pixie is now a must for public clients. um We kind of missed to to state this very clearly in the old versions.

C

So pixie is a must for public lines and there's no way around that. You can't use nons in this case, just as before, you can use nons instead of pixie for confidential clients. Pixel is recommended, but you may use nons if you also observe some additional precautions.

C

These additional precautions are essentially that you must ensure that the nonce um is checked properly and from the correct id token. That is, if you have an id token, uh both at the token endpoint, as well as in the in the authorization response, then um you must also check the nonce in the first one. um So that's that's something we stated very clearly again in this draft um because it might not be obvious to.

C

Implementers and then we had another a couple of other important changes, um something we discussed in. I think it was the last call um regarding the security bcp um somewhere earlier in the year.

C

We discussed a new wording around the implicit ground, and this is also, I think this has been discussed um very extensively.

C

This writing is now what also can be found in the document, um a smaller change, as you know, as you probably know, um we say that you um that you should use um exact string matching for redirect your eyes because it protects from a couple of attacks and we we now have one caveat to that which we've taken from the native apps pcp.

C

We say that if you use a localhost redirect uri, you may use variable port numbers, because native applications just might need that we also covered two new topics regarding attacks. First, one is essentially just one paragraph: um what happens if you have cross-site scripting? Of course this can undermine your token replay protection. If um somebody can inject code into your application- and we also have a section on click checking attacks, which is essentially completely new.

C

In the last call, we also discussed um what we want to say regarding mtls mtls is now um the kind of suggested method for token replay protection, but it's not longer as it used to be the only recommended option.

C

We have also gotten feedback that um the discussions were a bit, let's say lengthy, so we discussed um several approaches to um to mitigate some attacks. uh Some of these discussions were not very um helpful. They discussed uh things yet that might not be very practical, um so we tightened the text around that and we improved the examples, also feedback free. We got from the working group last call and, of course, we made several editorial improvements.

C

um So this these are the changes in a nutshell that we made um since the last working group last call. um So what's there left to discuss, actually, I think not too much. We have two things that I'd like to discuss today and, of course, also on the mailing list. Afterwards, um this one has already been on the mailing list.

C

As you know, we say that because we now have pxe as a mandatory feature, you should also publish both metadata to tell your clients that you actually support pixi.

C

We say that you can have a deployment specific way to communicate, communicate, pixie support, but oauth metadata is recommended, but this is only for the as side of things. What we currently don't say is that clients should actually use this as um so. This came from discussion with peter and the other guys at the stuttgart university.

C

We found that it might be a good idea to actually recommend oauth metadata to clients for their discovery process. We can reach several goals with that. First one is. We can promote automation in the sense that you can now use features just based on this discovery process, so you might also be able to use advanced features like power or jar just based on this discovery process.

C

This also affects security features. Of course, pixi is a prime example, but it also reduces the chance for mistakes, as you might know, in the frb in the current floppy specification, there's a paragraph that says um that one venue for attackers might be a misconfigured token endpoint.

C

Of course, this is um is something that can happen if you configure the token endpoint manually, but it's less likely to happen. If you have a metadata document that you can um pull this information from, so I think it's a it would be very useful if we would see a broader adoption of auth metadata and it actually improves security if we, if we recommend each client to use auth metadata, if available.

C

Of course, it just makes all also easier to deploy, but it also makes security features easier to deploy. You have essentially solved one um one part of your key exchange problem. If you want to use signed or encrypted messages, and it might also promote the use or the concept of the oauth issuer, which can also help to mitigate or mix-up attacks, speaking of which, um regarding mix-up attacks, so this is the second topic I'd like to discuss today.

C

The current recommendation, as you probably know, is that you should use so you must mitigate mix-up mitigation and one way to do that is to use separate, redirect uris per issue. That means that if a client can work with multiple authorization servers, the client should have a different redirect uri uri registered at each of the authorization servers.

C

This was a result of the discussion on how to solve the mix-up attack, and I think we settled on that because it's this solution is based on existing wealth features, but it turns out that it's not always the best solution. I think, for example- and this is a problem that we actually have at yes.com, uh this solution is not suitable for schemes where you have a centralized, client registration, um so the client just registers once and can use many or authorization servers or issuers. So to say, um I I think this is a pattern.

C

You often see in open banking schemes.

C

This solution, also, as you can tell from the text that we have in the bcp, needs a lot of explanation to developers. So what do they need to do so? Why do they need to use a separate redirect uri per issuer? What is an issuer um is a separate redirect uri per authorization server, okay, or is it not okay? uh What's the difference between the authorization server and issuer? What exactly to to pull what to put into that uri and so on?

C

um And it's also easy to get wrong and I think the the best argument uh against this solution actually is um it's very hard to automate in libraries, because library um might not know about your uri um how your uris are built, um what you put into that into these uris and so on? um So it's a. I still think it's a valuable thing to have, but I think there are better solutions and one such solution is something where also discussed very early on in this.

C

This whole mix-up topic is to put an iss parameter into the authorization response that tells the client um which issuer the authorization server thinks it belongs to and which was used in that authorization process.

C

This iss parameter is something um that again, we discussed very early on already in the process, so it's actually um the solution that we have in the first paper where we described the mix-up attack, we already had the solution with the issuer parameter, and we already proved formally that it actually solves the mix-up attack.

C

So it's a very um good mechanism against mix-up attacks, uh carson who's cast meyer to zelhausen, who is also in the call. Today he wrote he created a new draft which specifies exactly that an iss parameter for the authorization response. I think he also already posted on the mailing list. Today the draft defines the iss parameter and an respective metadata flag. Of course, it's a very short draft. um I think most of the parts most of the things in the draft um tell about um how this source mix up um it's uh again.

C

It's formally proven already, and I think if we had this iss parameter, this would be easy to automate on defense. That is very easy to automate in both implementations in libraries that evaluate that metadata flag.

C

So I propose that we put this into the security bcp, so we could say that clients must prevent mix-up attack attacks either by using the per issue or redirect uris or by using the iss parameter where we would then point to that new document.

E

This this is mike jones. Can I reply to that sure um if you're using an id token, you already have the issue a parameter or the issue or value, so you don't need the parameter so just like we did with nonce. You should describe that. If you have an id token in your flow, then you already have the issuer and can use it.

C

That's the valid point. Yes, thank you.

F

This is aaron. Can I ask the question about this.

E

F

Seems like another way to solve the attack is for the client to maintain state itself. It knows the request initiated. Is that a valid way to solve it as well? um Well,.

C

How would the client know where the code came from.

F

Same way, it is during the pixie code, verifier.

C

Well, the the um the client, so the client just gets a an authorization response and it just doesn't see where it comes from. So the client just gets it from the browser, and this is just a redirect to the client containing a code and since, of course, the code is opaque, can't tell where this. If this code is coming from the attacker as or the honest as.

F

I guess my point is that it already has to store uh state. It already has to store the pixie code verifier to know to no defend that in uh with your authorization code, so it seems like it could also store where it expects the code to come from, and if the code is coming from an attacker, the attacker could just as well swap out the iss parameter.

C

Yeah um exactly so, this is so the client in when using this this mitigation, the client would need to do exactly that, so the client would need to know um which is parameter it expects in response, and the nature of the mix-up attack is that the authorization response always comes from the honest as directly from the honest as and the attacker cannot um intercept the the authorization response from the honest as because, of course, if the attacker could intercept that that authorization response, then the attacker wouldn't need to do the mix-up attack in the first place.

C

So if you do mix-up, you know that the authorization response comes from the honest as so, it's not tampered with and the iss parameter is the original.

B

One daniel: could you just walk through that as to how does it protect about a bad uh iss, sending it.

C

Sure sure, um okay, how would we pull off a mix-up attack? um Let's say you're using um oauth metadata, so the whole thing starts with. As you know, in the mix-up attack, you have one client and at least two issuers, so one issuer is honest.com and one is attacker.com.

C

These are the issuers and the user would go to the client and say I'd like to use attacker.com as an issuer. So, for example, by pressing a button I don't know authorize with attacker.com. I don't know um so. The client starts the interaction with attacker.com retweets, the metadata document and in the metadata document, the client, the the attacker acting under the issuer, attacker.com would say my authorization, endpoint is honest.com auth and my token endpoint is attacker.com token.

C

Okay, so the metadata document points one thing: the authorization endpoint to the honest one and the token endpoint to the attacker.

C

Now what happens is of course the client sees a metadata document, evaluates the authorization, server url and then sends the user to that authorization server and that is honest.com auth.

C

So the user sees honest.com authorization endpoint logs in authorizes the client for access and then gets sent back to the client, so the client receives an authorization response which comes from honest.com contains a code for honors.com, but the client of course still thinks that all these things are happening with the issuer. Attacker.Com.

C

And now the client will, of course, want to re-redeem that code for an access token, so the client goes to the token endpoint. The token endpoint, of course, is attacker.com token. So what happens? Is the client sends the code that it acquired from honest.com to the token endpoint attacker.com, and at this point um the attacker knows the code and um yeah. So essentially it's it's game over. At this point, of course, you have then features like pixi making this attack harder and and other things, um but still to get defense in depth.

C

You need to prevent, in the first place that the code can reach the token endpoint of attacker.com.

C

So if you had the iss parameter in the authorization response, then of course in the scenario that I just showed, the honest dot com, slash, auth authorization endpoint would put into the authorization response the issuer honest.com, because the honest.com authorization server knows that it's acting under the issuer on a sidecar, so the authorization response arrives at the client and the client sees okay. This response comes from honest.com while me, while I as a client, I'm thinking uh I'm acting or I'm interacting with attacker.com.

C

So the client would see the mismatch there and then can stop the transaction.

C

And the whole thing also works. If you don't have metadata, but then you need to um essentially you need to need a deployment specific way to to say what is the issuer so to say in that case, which can be as easy as a fixed string that you know that facebook always sends this string, and google always sends this string.

F

Thank you make sense thanks for describing that, can you explain how pixi does not solve this.

C

Well, pxe kind of does um so with pixi. The code would arrive at the wrong token endpoint, but of course the um the the um the attacker wouldn't know which pxe verifier to use for that code um problem is that, first of all, we don't know if pixel was used. Of course, if you follow all the recommendation, pixel was used, um but if you don't, then you still have the mixer problem.

C

Second, is that there might have been a chance for the attacker to influence the authorization request in the first place, um for example, by by kind of proxying that through his own server, and that means that the attacker could know which code challenge was used.

C

If that code challenge was clear text, then of course the attacker would just know the code verifier.

C

Otherwise, the attacker might be able to just select their own code challenge in the authorization request.

C

So the idea would be that in the metadata document the attacker would not write authorization, endpoint is honest.com, but instead the attacker would write. Authorization, endpoint is attacker.com proxy and attacker.comproxy would just change the authorization request.

F

I think I see that um last question if a client is only ever interacting with one authorization server, none of this is necessary. Is that correct and if so, can that be explicitly stated.

C

Yes, that's correct and yeah, I I I see whether we have that already in the text or otherwise we'll need to put that there very explicitly. Yes,.

C

A

Okay, any anybody has any other questions about previous slides.

A

Okay, so so daniel, um like do, do you think you you want to wait for this document to kind of progress and then kind of see how that goes before you kind of continue to move this document along.

C

um That's an excellent question. um I think it's it's um it's time that we publish the security bcp and I think, by putting the iss parameter into a separate document, we've um kind of decoupled those that's at least what I hope. um Of course. I know that um it's it's. It could be a problem to link to to reference.

C

What is right now an individual draft, um so I think it would be great if we would find a way to proceed with the security bcp um more or less independent of the other document.

C

I'm not not exactly sure what we would need to do, but I guess that this could help me out there.

A

Yeah individual is that specifically it's right, uh it'll, be a challenge. Roman, have any any thoughts on if we can't progress. The document with the individual draft in our reference.

G

Sorry, but I I don't understand the question, could you say it again if we can't progress the document? What sorry so.

A

So that it seems that what what daniel is trying to do here is he's trying to describe an attack and refer to uh an individual draft, which is just, was there a lot of noise on that on the bridge? So if you are not team, can you please go.

D

A

There is lots of knowing somebody is, is doing something there so so the point is that question is: is there a way to progress, a document through the isg, with a reference to an individual draft still.

G

Sure, I think a couple of things matter. It depends on the track. We want to publish this particular document in uh you know. Ultimately what will happen is if you have a document that has a normative reference on another document that is not yet published. It'll sit in the rfc editor queue as a misref until until they're deconflicted and then, depending on the track of that other document.

G

uh You know if you were, for example, on a standards track document that you want to advance, but the reference is normative and if it's informational, we're just we'll just need to make sure that we appropriately broadcast uh the down ref during last call. um This is.

D

Harness here uh I was wondering like I was listening to mike's comment early on with. He was saying that the id token, so, if you use id token, you essentially have that parameter in there already. Is that or something that we need to take into account in this whole debate, our write-up.

E

I would ask that this is mike again. I would ask that we update the document with the resolutions to my comments and the resolutions to aaron's comments before we would do another last call.

C

Yes, that would be the plan anyway, right.

A

Okay, thank you, yeah yeah. The plan wasn't.

D

um Like if it depends on how we reference that uh solution, specifically in the document, if it's referenced as a informative, um then obviously that would it wouldn't be blocked, but otherwise, um clearly, as roman explained, it would be sort of stalled till this other document is completed. Yeah.

C

Yeah I mean this could be a chance right, so it looks like we have kind of two ways to transport: the iss, not the not the space station um in the authorization response. One is the id token. One is a separate parameter, so um this could be, in my opinion, an informative reference. um At least.

G

uh I mean as long as the solution is described in the pcp text. I could also see the you know further details on the attack as being informational, because they would not be required to be known to implement the solution and as long as we keep to that line, I think we can have that that arrangement.

G

That would actually be the solution.

C

Not the not the attacks, but um we we would, I mean in the in the security bcp we would. We could say if you have a way of sending the issuer from the um authorization endpoint uh to the client, then that also solves the problem and one way could be the id token and informative reference. This other draft.

D

Yeah that that could uh I think that could then make it a normative, informative reference and that that would be good.

A

Okay, why would that be informative like if, if the id token is not there, then the right way to do it is through uh this parameter. So it's not gonna be informative right.

D

Yeah yeah, but at least uh yeah.

F

No, it sounds like the security bcp would be saying you need to solve this attack and there are several options to do that. You could also make up your own solution. However, it would then point people toward the standardized the intended to be standardized version of that, which is this iss parameter.

C

H

Wasn't speaking you could you could uh uh see that way, the security pcp states, um the parameter, could be a solution and the new draft picks up on that point and makes an interpretable standard.

I

A

Okay, I guess we need to think about a way kind of to progress, this okay. So then, then,.

J

Would it would it make sense just to go ahead and define the parameter and business metadata in the security bcp and avoid the logistics? I know that was folks were trying to avoid that, but.

A

But but then and the document wouldn't be a bcp anymore, it would be a standard track right because you're changing introducing no functionality right. Well, I I'm not sure.

J

It's not clear to me that that's the case just including a one additional parameter and and how it's used. um I guess I would defer to that.

G

This is roman speaking. It would feel a little odd to me to be registering new parameters in the bcp document. It seems like that document should be pointing to all.

D

The other things that.

G

Have the guidance and having the normative language around using using those protocol features or not or whatever is the appropriate caution.

J

That that's fair, it just seemed like, potentially it's less awkward than all these various attempts to downplay a down ref or back rough to an individual draft document. Although I presume that this discussion sort of presupposes the adoption of the other document and attempts to progress it quickly,.

C

I mean this is something we could also just just try to. We could just try to progress with the security bcp and see how much um need for discussion. There is with the other document. um It is a relatively short document and very concise. So maybe maybe this progress is quick enough. Otherwise we could still think about how to reference that.

A

Properly: okay, okay, so then I guess for now you still have this some work to do. Danielle.

A

Let's update this document based on the feedback you got today um and see if we can have some discussion about this new draft and if we can make a progress on that uh in parallel and see how far we can go with this exactly sounds good, okay, okay, any any other questions for danielle.

I

Yes, this is danny speaking.

A

A

A

Go ahead. Do you have a question? Okay,.

I

Okay, it's a topic that I've already raised on the version 15. Currently the section 3 states, the updated, auto article model is supposed to have been updated to account the potentially involving multiple, multiple parties. However, he still misses to address the case of dynamic relationship between clients, which includes scenario of collaborative clients.

I

Now, on november last year, daniel wrote has the feeling that this attack, which means a collaborative attack, aims at breaking a security property that does not claim to fall fulfill and that nobody expects or to fulfill.

I

Well, I believe that the attack should be mentioned and it has two flavors. Let us suppose that you have a token that contains only a verification of the age saying that the person is more than 20 21.

I

Well, this kind of token should never be accepted by a server, because in case of a probation between clients, you cannot know who has charged or has provided the token to the other client.

I

However, if the token includes the subject identifier, you know that who is the person during the impersonation and now you feel in the problem of impersonation and see it means that the way to counter the attack is basically to always include a subject, identifier that allows the service or the server to auto, to basically authenticate the owner of the token.

I

So I believe that this should be mentioned in the document.

A

Okay, danielle any any thoughts on that.

C

Yeah, um I think we've discussed this attack a number of times, also in different working groups, um and it seems that there's so I still stand by what dennis quoted um that this seems to break something that nobody really expect or to provide, um which is also kind of supported by the. I don't know the my general impression that that um this this discussion of the attack um has not brought us um really to to to the conclusion that this is an interesting attack, so to say um just one.

C

One thing that I also pointed out before this attack is covered by the attacker model. um Collaborative clients is something that can happen. um The thing is, it is not covered by the kind of security goals that people expect oauth to fulfill and yeah. So I don't really think that this is something we should cover in the security bcp.

I

Well collaborative is not a word that exists in the current bcp, so collaborative clients do not exist as well. As you mentioned, this kind of attack can happen and we should say what should be done in case. That attack happened and mentioned that there is a way to counter that attack, and this should be mentioned.

C

Then collaborative clients are covered by the attacker model, because clients can of course send messages to each other. um This is also something that we covered in the formal analysis where this attacker model kind of is derived from where clients can collaborate, so they can collaborate to reach a common goal.

C

Could you point me to the text where you have the word collaborative in this document? No, this word is not in the document. We just say that clients can send messages to each other and they can act together.

I

So um it's much more than that, it's not sending messages is making cryptographic computation for the benefit of the other client, and this is never mentioned in the document.

C

Again, I I recommend you to read the original formal analysis which covers explicitly this thing. That's.

I

Eternal, there is no section dealing with that problem in the bcp. That's such a key point.

D

Yeah this is this harness here um um yeah. I wonder I so I I see uh two aspects here. One is um to the question of like how well is uh this aspect covered uh right in the document itself rather than in in uh reference documents, uh and can we can we do a better job in in pointing uh these things out on what's covered and what's not covered?

D

uh The other aspect is um I'm sort of talking about uh solution aspects and having an agreement on a group, but this is uh something they uh worry about in in oas, and I I I know that in like uh what people care about in a group in terms of attacks uh changes uh from time to time, uh but maybe maybe that's something to to think about, and- and um I can kick off an email to discuss this aspect as we as you are uh then, as you are updating the document uh for the other issue we discussed before, is that how does that sound.

C

Yeah, um I think we should also in the interest of publishing the security bcp, consider this maybe for a future update.

B

A

Okay: okay, any any other questions comments.

A

Okay, then, I think uh we're done for for today and uh we'll uh we'll see you next week guys we still have a another interim next week next monday same time. Okay, thank you all.

F

D

Thanks, thanks for the feedback, distribute the meeting minutes as soon as possible. Awesome thank.

D