Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address, DoS, and privacy
Hello John, Steffi made some suggestions to improve the sections you criticized (see also https://github.com/ace-wg/ace-oauth/pull/177). Do you think they address your issues? Does the WG have an opinion on the way forward? (Chairs? Ads?) /Ludwig > -Original Message- > From: Ace On Behalf Of Stefanie Gerdes > Sent: den 10 september 2020 14:11 > To: ace@ietf.org > Subject: Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address, > DoS, and privacy > > Hi Ludwig, > > comments inline. > > On 09/10/2020 08:49 AM, Seitz Ludwig wrote: > > Seeing that the mechanism was introduced to bootstrap a client that > doesn't know which AS to talk to for a specific RS and given the issues raised > by John, what other options do we have that are more secure? > > The mechanism in itself does not have a security problem. If C would > communicate with an AS that is not authorized for this RS that would be a > problem, but as section 6.5 states, C must be able to validate that. > This point is really important for the security of the solution, regardless > of the > discovery mechanism. The privacy problem that AS URIs may pose should be > mentioned in the privacy considerations. I made a text proposal in my > response to John [1]. > > > > > a.) A resource directory lookup? I'm not knowledgeable enough on RD to > answer whether that is more secure, but Steffi or Olaf or Carsten should > have more insight on this. > > > > b.) A callback to a trusted entity (say the client owner). The issue here is > that we have not defined any interactions for that entity yet. > > > > c.) John suggested something with DNS in the first mail. I have no idea how > this would work, John what did you have in mind there? > > > > For the draft I see two ways forward: > > > > 1.) Remove the whole discovery mechanism and just state that at this point > we assume that the knowledge of the right AS is pre-configured/supplied > out-of-band to the client. This leaves room for future work that specifies an > in-band method. > > > > 2.) Try to fix this (e.g. by specifying one of the methods a-c above). > > > > I do not have the time to do 2 so I clearly prefer option 1, but if any of > > my > co-authors can put in the work I'd be very glad. > > I already made text proposals that hopefully clarify the problems that John > brought up [1]. I think it is really important to address these problems in > sections 6.4 and 6.5 in the draft and not just ignore them or leave them for > later. That would leave the framework open for attacks. Developers will have > difficulties to close this gap on their own. > > We also should decouple the AS request creation hints from the explanation > of the AS discovery mechanism. The hints have the additional purpose that > they may contain the resource server's cnonce that the resource server can > later use to validate the access token. > Therefore, the AS URI should be optional in the AS request creation hints, > and we should make section 5.1.1 section 5.2. > > Viele Grüße > Steffi > > [1] > https://mailarchive.ietf.org/arch/msg/ace/0639BdkMvJZdUjLBJIX21EiSvbw/ > > ___ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address, DoS, and privacy
Benjamin Kaduk wrote: >> > The requirement "the client MUST be able to determine whether an AS has >> > the authority to issue access tokens for a certain RS. This can for >> > example be done through pre-configured lists, or through an online >> > lookup mechanism that in turn also must be secured." indicates that C >> > is required to have another mechanism to determine the AS for a >> > specific RS and that the unauthorized AS address is completely >> > redundant. >> >> This is a hard problem. >> Q: "Who are you?" >> A: "Depends upon who is asking! Who are you?" >> A: "Depends upon who is asking! Who are you?" >> ... >> >> The DNS-SD WG produced rfc8882, but as I understand it, >> https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-privacy-05 >> was abandonned because the WG did not see implementation/energy. >> I can't seem to find the thread discussing that state. > Interestingly, the corresponding requirements document was just published > recently as RFC 8882. > "A problem with no solution is a hard problem"... I thought Christian Huitema's solution, which I think is three or four years old, was reasonable. The WG just couldn't get reviews or people interested in implementing. Maybe ACE cares enough now. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address, DoS, and privacy
On Thu, Sep 10, 2020 at 02:46:43PM -0400, Michael Richardson wrote: > > John Mattsson wrote: > > - That RS shares the AS address with anybody that asks can be a severe > > privacy problem. If RS is a medical device, the AS address can reveal > > sensitive information. If RS is a blood pressure sensor it could > > e.g. be “AS address = > > coaps://as.hopkinsmedicine.org/kimmel_cancer_center/” > > > The requirement "the client MUST be able to determine whether an AS has > > the authority to issue access tokens for a certain RS. This can for > > example be done through pre-configured lists, or through an online > > lookup mechanism that in turn also must be secured." indicates that C > > is required to have another mechanism to determine the AS for a > > specific RS and that the unauthorized AS address is completely > > redundant. > > This is a hard problem. > Q: "Who are you?" > A: "Depends upon who is asking! Who are you?" > A: "Depends upon who is asking! Who are you?" > ... > > The DNS-SD WG produced rfc8882, but as I understand it, >https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-privacy-05 > was abandonned because the WG did not see implementation/energy. > I can't seem to find the thread discussing that state. Interestingly, the corresponding requirements document was just published recently as RFC 8882. "A problem with no solution is a hard problem"... -Ben ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address, DoS, and privacy
sg> A compromised RS may use the hints for attempting to trick a client sg> into contacting an AS that is not supposed to be in charge of that RS. sg> Therefore, C must not communicate with an AS if it cannot determine sg> that this AS has the authority to issue access tokens for this sg> RS. Otherwise, a compromised RS may use this to perform a denial of sg> service against a specific AS, by redirecting a large number of client sg> requests to that AS. Jim Schaad wrote: > [JLS] I do not know how C is supposed to be able to determine if AS has > the authority to issue access tokens for a specific RS. If it had the > ability to do that then it can go directly to the AS in question > without ever needing to use this mechanism. This mechanism is designed > to be used for the case where C does not have a priori knowledge about > which AS it will talk to get the token for RS. I was going to ask the same thing. This is variation of the onboarding problem, but also it ignores how devices got network access in the first place. If C and RS share some trust in some nearby third party, then that party could vouch. I say "nearby", because having them both trust google or azure or amazon doesn't help, because that anchor has no real knowledge about whether RS or RS' is actually nearby. RS' could be legitimately onboarded with "cloud", but just happens to be a device "next door". Or could it? yes, in theory, but the question arises about how C and RS are communicating? If one assumes that they are on the same L2, or different L2's managed by the same L3, then there is a local third party. In most cases, if RS' can spoof a response, it's because it is on the same L2, having the same L2 security as C. If C and RS are distant (you try to turn on your blood pressure sensor across the Internet) then yes, it could wind up with the wrong sensor. - That RS shares the AS address with anybody that asks can be a severe privacy problem. If RS is a medical device, the AS address can reveal sensitive information. If RS is a blood pressure sensor it could e.g. be “AS address = coaps://as.hopkinsmedicine.org/kimmel_cancer_center/” > [JLS] My first hope is that this RS would never return an AS address to > a client. Sending information which has secure privacy problems > amounts to a case where the rule should be: If C does not know what AS > to talk to, it has no business talking to me (RS). At which point, I wonder what the point of the AS is. > [JLS] This is the type of situation where that information itself is > going to be information to which access is to be restricted and where > you need to talk to an AS to get permissions to get that information. > In this type of situation I would expect that the information would > only be available either throw an already secure channel or from a DS > with the, not yet defined, AS attributes. So, RS could answer with some less specific AS, that deals with who C is? The, as it were, cloudflare of IoT? -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address, DoS, and privacy
John Mattsson wrote: > - That RS shares the AS address with anybody that asks can be a severe > privacy problem. If RS is a medical device, the AS address can reveal > sensitive information. If RS is a blood pressure sensor it could > e.g. be “AS address = > coaps://as.hopkinsmedicine.org/kimmel_cancer_center/” > The requirement "the client MUST be able to determine whether an AS has > the authority to issue access tokens for a certain RS. This can for > example be done through pre-configured lists, or through an online > lookup mechanism that in turn also must be secured." indicates that C > is required to have another mechanism to determine the AS for a > specific RS and that the unauthorized AS address is completely > redundant. This is a hard problem. Q: "Who are you?" A: "Depends upon who is asking! Who are you?" A: "Depends upon who is asking! Who are you?" ... The DNS-SD WG produced rfc8882, but as I understand it, https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-privacy-05 was abandonned because the WG did not see implementation/energy. I can't seem to find the thread discussing that state. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address, DoS, and privacy
Hi all, On 09/10/2020 02:10 PM, Stefanie Gerdes wrote: > We also should decouple the AS request creation hints from the > explanation of the AS discovery mechanism. The hints have the additional > purpose that they may contain the resource server's cnonce that the > resource server can later use to validate the access token. > Therefore, the AS URI should be optional in the AS request creation > hints, and we should make section 5.1.1 section 5.2. Looking at section 5.1, I think that we would need to change the text in there, too. old: In order to determine the AS in charge of a resource hosted at the RS, C MAY send an initial Unauthorized Resource Request message to RS. RS then denies the request and sends the address of its AS back to C. Instead of the initial Unauthorized Resource Request message, other discovery methods may be used, or the client may be pre-provisioned with an RS-to-AS mapping. new: C must discover the AS in charge of RS to determine where to request the access token. To do so, C must 1. find out the AS URI to which the token request message must be sent and 2. MUST validate that the AS with this URI is authorized to provide access tokens for this RS. In order to determine the AS URI, C MAY send an initial Unauthorized Resource Request message to RS. RS then denies the request and sends the address of its AS back to C (see section 5.2). How C validates the AS authorization is not in scope for this document. C may, e.g., ask it's owner if this AS is authorized for this RS. C may also use a mechanism that addresses both problems at once. Viele Grüße Steffi ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address, DoS, and privacy
Hi Ludwig, comments inline. On 09/10/2020 08:49 AM, Seitz Ludwig wrote: > Seeing that the mechanism was introduced to bootstrap a client that doesn't > know which AS to talk to for a specific RS and given the issues raised by > John, what other options do we have that are more secure? The mechanism in itself does not have a security problem. If C would communicate with an AS that is not authorized for this RS that would be a problem, but as section 6.5 states, C must be able to validate that. This point is really important for the security of the solution, regardless of the discovery mechanism. The privacy problem that AS URIs may pose should be mentioned in the privacy considerations. I made a text proposal in my response to John [1]. > > a.) A resource directory lookup? I'm not knowledgeable enough on RD to answer > whether that is more secure, but Steffi or Olaf or Carsten should have more > insight on this. > > b.) A callback to a trusted entity (say the client owner). The issue here is > that we have not defined any interactions for that entity yet. > > c.) John suggested something with DNS in the first mail. I have no idea how > this would work, John what did you have in mind there? > > For the draft I see two ways forward: > > 1.) Remove the whole discovery mechanism and just state that at this point we > assume that the knowledge of the right AS is pre-configured/supplied > out-of-band to the client. This leaves room for future work that specifies an > in-band method. > > 2.) Try to fix this (e.g. by specifying one of the methods a-c above). > > I do not have the time to do 2 so I clearly prefer option 1, but if any of my > co-authors can put in the work I'd be very glad. I already made text proposals that hopefully clarify the problems that John brought up [1]. I think it is really important to address these problems in sections 6.4 and 6.5 in the draft and not just ignore them or leave them for later. That would leave the framework open for attacks. Developers will have difficulties to close this gap on their own. We also should decouple the AS request creation hints from the explanation of the AS discovery mechanism. The hints have the additional purpose that they may contain the resource server's cnonce that the resource server can later use to validate the access token. Therefore, the AS URI should be optional in the AS request creation hints, and we should make section 5.1.1 section 5.2. Viele Grüße Steffi [1] https://mailarchive.ietf.org/arch/msg/ace/0639BdkMvJZdUjLBJIX21EiSvbw/ ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address, DoS, and privacy
Hi Jim, comments inline. On 09/10/2020 12:11 AM, Jim Schaad wrote: > A compromised RS may use the hints for attempting to trick a client into > contacting an AS that is not supposed to be in charge of that RS. > Therefore, C must not communicate with an AS if it cannot determine that this > AS has the authority to issue access tokens for this RS. Otherwise, a > compromised RS may use this to perform a denial of service against a specific > AS, by redirecting a large number of client requests to that AS. > > [JLS] I do not know how C is supposed to be able to determine if AS has the > authority to issue access tokens for a specific RS. If it had the ability to > do that then it can go directly to the AS in question without ever needing to > use this mechanism. This mechanism is designed to be used for the case where > C does not have a priori knowledge about which AS it will talk to get the > token for RS. C may use the AS URI to determine if the AS is responsible for this server, e.g., by looking it up in a secured resource directory that contains the necessary information or by asking its own authorization manager. As there may be large numbers of resource server that may change a lot, it may be beneficial to also have the AS URI. That depends on the client side authorization mechanism, of course. If C does not require this information, it does not have to use it. The unauthorized resource request mechanism has an additional purpose: it also enables RS to specify a nonce that can later be reflected to it in the access token and thereby enables RS to validate that the access token is recent. It would be useful to make the AS address optional in the AS request creation hints. > >> - That RS shares the AS address with anybody that asks can be a severe privacy problem. If RS is a medical device, the AS address can reveal sensitive information. If RS is a blood pressure sensor it could e.g. be “AS address = coaps://as.hopkinsmedicine.org/kimmel_cancer_center/” > > [JLS] My first hope is that this RS would never return an AS address to a > client. Sending information which has secure privacy problems amounts to a > case where the rule should be: If C does not know what AS to talk to, it has > no business talking to me (RS). > > [JLS] This is the type of situation where that information itself is going to > be information to which access is to be restricted and where you need to talk > to an AS to get permissions to get that information. In this type of > situation I would expect that the information would only be available either > throw an already secure channel or from a DS with the, not yet defined, AS > attributes. Wouldn't the client breach the privacy of its owner simply by communicating with an AS with such a URI? I send a proposal to address this problem in my answer to John [1]. Viele Grüße Steffi [1] https://mailarchive.ietf.org/arch/msg/ace/0639BdkMvJZdUjLBJIX21EiSvbw/ ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address, DoS, and privacy
Seitz Ludwig writes: > Seeing that the mechanism was introduced to bootstrap a client that > doesn't know which AS to talk to for a specific RS and given the > issues raised by John, what other options do we have that are more > secure? > > a.) A resource directory lookup? I'm not knowledgeable enough on RD to > answer whether that is more secure, but Steffi or Olaf or Carsten > should have more insight on this. > > b.) A callback to a trusted entity (say the client owner). The issue > here is that we have not defined any interactions for that entity yet. > > c.) John suggested something with DNS in the first mail. I have no > idea how this would work, John what did you have in mind there? > > For the draft I see two ways forward: > > 1.) Remove the whole discovery mechanism and just state that at this > point we assume that the knowledge of the right AS is > pre-configured/supplied out-of-band to the client. This leaves room > for future work that specifies an in-band method. > > 2.) Try to fix this (e.g. by specifying one of the methods a-c above). > > I do not have the time to do 2 so I clearly prefer option 1, but if > any of my co-authors can put in the work I'd be very glad. The issue with options a and c is that they have the same privacy issues as the current solution. And, of course, they need a way for C to determine whether the used service (RD or DNS) is authorized to tell C which AS is supposed to issue access tokens for RS. And after that, C needs to check the very same things as before. Option b) is what OAuth does (by presenting the login screen to the user in front of the web browser). As said before, the current draft mimics exactly that behavior. But as the client is assumed to act autonomously, this client owner authorization process has been made upfront by configuring authorized AS's. Grüße Olaf ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address, DoS, and privacy
Seeing that the mechanism was introduced to bootstrap a client that doesn't know which AS to talk to for a specific RS and given the issues raised by John, what other options do we have that are more secure? a.) A resource directory lookup? I'm not knowledgeable enough on RD to answer whether that is more secure, but Steffi or Olaf or Carsten should have more insight on this. b.) A callback to a trusted entity (say the client owner). The issue here is that we have not defined any interactions for that entity yet. c.) John suggested something with DNS in the first mail. I have no idea how this would work, John what did you have in mind there? For the draft I see two ways forward: 1.) Remove the whole discovery mechanism and just state that at this point we assume that the knowledge of the right AS is pre-configured/supplied out-of-band to the client. This leaves room for future work that specifies an in-band method. 2.) Try to fix this (e.g. by specifying one of the methods a-c above). I do not have the time to do 2 so I clearly prefer option 1, but if any of my co-authors can put in the work I'd be very glad. /Ludwig > -Original Message- > From: Ace On Behalf Of Jim Schaad > Sent: den 10 september 2020 00:11 > To: 'Stefanie Gerdes' ; ace@ietf.org > Subject: Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address, > DoS, and privacy > > > > -Original Message- > From: Ace On Behalf Of Stefanie Gerdes > Sent: Wednesday, September 9, 2020 4:12 AM > To: ace@ietf.org > Subject: Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address, > DoS, and privacy > > Hi John, > > On 09/09/2020 11:36 AM, John Mattsson wrote: > > > > >>> As currently specified in draft-ietf-ace-oauth-authz-35, the RS will > >>> happily send the AS address to any node that asks. This causes two > >>> problems. > >>> > >>> - If C acts on the unauthorized information, this is an attack > >>> vector for DoS attacks as an attacker on the C-RS path can make C > >>> contact a chosen node on the Internet. > >> > >> The important part here is the "If". A proper client MUST NOT act on > >> unauthorized information at any time. The workaround is the list of > >> known AS'es in the draft. (In the current architecture, a client > >> would not and cannot communicate with an unknown AS anyway as it has > >> no way to establish a secure communication.) > > > > I cannot find anything in the draft stating that “A proper client MUST NOT > act on unauthorized information at any time”. This also raises the question > why the unauthorized information is needed in the first place. > > Hm, section 6.5 already states "the client MUST be able to determine > whether an AS has the authority to issue access tokens for a certain RS." We > can add "The client must not interact with an AS if it cannot determine that > AS has the authority for this RS." > > We also should change section 6.4 because the attack described there is not > possible as C must not interact with an AS that is not authorized for this > RS. I > think that paragraph is a relic. > > How about: > > old: > Initially, no secure channel exists to protect the communication between C > and RS. Thus, C cannot determine if the AS Request Creation Hints contained > in an unprotected response from RS to an unauthorized request (see Section > 5.1.2) are authentic. It is therefore advisable to provide C with a (possibly > hard-coded) list of trustworthy authorization servers, possibly including > information used to authenticate the AS, such as a public key or certificate > fingerprint. AS Request Creation Hints referring to a URI not listed there > would be ignored. > > A compromised RS may use the hints to trick a client into contacting an AS > that is not supposed to be in charge of that RS. Since this AS must be in the > hard-coded list of trusted AS no violation of privileges and or exposure of > credentials should happen, since a trusted AS is expected to refuse > requestes for which it is not applicable and render a corresponding error > response. However a compromised RS may use this to perform a denial of > service against a specific AS, by redirecting a large number of client > requests > to that AS. > > new: > Initially, no secure channel exists to protect the communication between C > and RS. Thus, C cannot determine if the AS Request Creation Hints contained > in an unprotected response from RS to an unauthorized request (see Section > 5.1.2) are authentic. C therefore must be able to determine if an AS is > authorized to provide access tokens for a certain R
Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address, DoS, and privacy
-Original Message- From: Ace On Behalf Of Stefanie Gerdes Sent: Wednesday, September 9, 2020 4:12 AM To: ace@ietf.org Subject: Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address, DoS, and privacy Hi John, On 09/09/2020 11:36 AM, John Mattsson wrote: >>> As currently specified in draft-ietf-ace-oauth-authz-35, the RS will >>> happily send the AS address to any node that asks. This causes two >>> problems. >>> >>> - If C acts on the unauthorized information, this is an attack >>> vector for DoS attacks as an attacker on the C-RS path can make C >>> contact a chosen node on the Internet. >> >> The important part here is the "If". A proper client MUST NOT act on >> unauthorized information at any time. The workaround is the list of >> known AS'es in the draft. (In the current architecture, a client >> would not and cannot communicate with an unknown AS anyway as it has >> no way to establish a secure communication.) > > I cannot find anything in the draft stating that “A proper client MUST NOT > act on unauthorized information at any time”. This also raises the question > why the unauthorized information is needed in the first place. Hm, section 6.5 already states "the client MUST be able to determine whether an AS has the authority to issue access tokens for a certain RS." We can add "The client must not interact with an AS if it cannot determine that AS has the authority for this RS." We also should change section 6.4 because the attack described there is not possible as C must not interact with an AS that is not authorized for this RS. I think that paragraph is a relic. How about: old: Initially, no secure channel exists to protect the communication between C and RS. Thus, C cannot determine if the AS Request Creation Hints contained in an unprotected response from RS to an unauthorized request (see Section 5.1.2) are authentic. It is therefore advisable to provide C with a (possibly hard-coded) list of trustworthy authorization servers, possibly including information used to authenticate the AS, such as a public key or certificate fingerprint. AS Request Creation Hints referring to a URI not listed there would be ignored. A compromised RS may use the hints to trick a client into contacting an AS that is not supposed to be in charge of that RS. Since this AS must be in the hard-coded list of trusted AS no violation of privileges and or exposure of credentials should happen, since a trusted AS is expected to refuse requestes for which it is not applicable and render a corresponding error response. However a compromised RS may use this to perform a denial of service against a specific AS, by redirecting a large number of client requests to that AS. new: Initially, no secure channel exists to protect the communication between C and RS. Thus, C cannot determine if the AS Request Creation Hints contained in an unprotected response from RS to an unauthorized request (see Section 5.1.2) are authentic. C therefore must be able to determine if an AS is authorized to provide access tokens for a certain RS. A compromised RS may use the hints for attempting to trick a client into contacting an AS that is not supposed to be in charge of that RS. Therefore, C must not communicate with an AS if it cannot determine that this AS has the authority to issue access tokens for this RS. Otherwise, a compromised RS may use this to perform a denial of service against a specific AS, by redirecting a large number of client requests to that AS. [JLS] I do not know how C is supposed to be able to determine if AS has the authority to issue access tokens for a specific RS. If it had the ability to do that then it can go directly to the AS in question without ever needing to use this mechanism. This mechanism is designed to be used for the case where C does not have a priori knowledge about which AS it will talk to get the token for RS. > >>> - That RS shares the AS address with anybody that asks can be a >>> severe privacy problem. If RS is a medical device, the AS address >>> can reveal sensitive information. If RS is a blood pressure sensor >>> it could e.g. be “AS address = >>> coaps://as.hopkinsmedicine.org/kimmel_cancer_center/” [JLS] My first hope is that this RS would never return an AS address to a client. Sending information which has secure privacy problems amounts to a case where the rule should be: If C does not know what AS to talk to, it has no business talking to me (RS). [JLS] This is the type of situation where that information itself is going to be information to which access is to be restricted and where you need to talk to an AS to get permissions to get that information. In this type of situation I would expect that the in
Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address, DoS, and privacy
John Mattsson writes: > Hi Olof, > > Your reasoning does seem to be anchored in the draft. See inline. > > The current state of the draft is not acceptable. I may agree with you in this point in so far as the sections 6.4 and 6.5 might contradict each other as Steffi has pointed out previously. And I agree with you also if the requirements on proper behavior I have stated are not clearly stated in the draft as you seem to believe. More inline. > > -Original Message- > From: Olaf Bergmann > Date: Wednesday, 9 September 2020 at 10:20 > To: John Mattsson > Cc: "ace@ietf.org" , > "draft-ietf-ace-oauth-authz....@ietf.org" > > Subject: Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS > address, DoS, and privacy > > Hello John, > > Thank you for condensing this discussion thread. See inline for my > reasoning why I think that this issue is less severe than one would > expect at first: > > John Mattsson writes: > >>> Summarizing my thoughts and opinion on this issue. Changing the title >>> to highlight the issues better. >>> >>> As currently specified in draft-ietf-ace-oauth-authz-35, the RS will >>> happily send the AS address to any node that asks. This causes two >>> problems. >>> >>> - If C acts on the unauthorized information, this is an attack vector >>> for DoS attacks as an attacker on the C-RS path can make C contact a >>> chosen node on the Internet. >> >>The important part here is the "If". A proper client MUST NOT act on >>unauthorized information at any time. The workaround is the list of >>known AS'es in the draft. (In the current architecture, a client would >>not and cannot communicate with an unknown AS anyway as it has no way to >>establish a secure communication.) > > I cannot find anything in the draft stating that “A proper client MUST > NOT act on unauthorized information at any time”. In this case we may need to state that. I presume the authors have treated that as natural behavior of any networked station on the Internet. > This also raises the question why the unauthorized information is > needed in the first place. As explained at the end of my previous post it is needed if there is no other discovery mechanism and to prevent the need to do a wks lookup in case an unauthorized plain-text request failed with a 4.01. >>> - That RS shares the AS address with anybody that asks can be a severe >>> privacy problem. If RS is a medical device, the AS address can reveal >>> sensitive information. If RS is a blood pressure sensor it could >>> e.g. be “AS address = >>> coaps://as.hopkinsmedicine.org/kimmel_cancer_center/” >> >>This is a valid concern. However, I would argue that the Uri-Path in >>this URI should not be constructed to reveal this information in the >>first place. All discussions so far assumed that the authorization >>information endpoint on the AS would be named more descriptively as, >>e.g., /autz-info. This could at least mitigate the issue. > > I don’t find anything in the draft stating that “the Uri-Path in this > URI should not be constructed to reveal this information”, or how such > a construction would look like. This is not trivial. The construction would be easy: coaps://as.hopkinsmedicine.org/authz-info. Not trivial if you want to disguise the FQDN as well. There is a lot of work on how to achieve this. See, e.g., [1] for a brief discussion and a working solution [2]. I agree with you that this might be worth a paragraph in the Privacy Considerations section. [1] S. Stadler, S. Gerdes, O. Bergmann: Privacy-enhanced Authenticationfor the Internet of Things. In: Proceedings of the 18. GI/ITG KuVS FachGespräch SensorNetze, FGSN 2019, Magdeburg, Germany, p. 37—40. Available online http://dx.doi.org/10.25673/28428, last access 2020-09-09. [2] https://gitlab.informatik.uni-bremen.de/DCAF/dcaf/-/tree/abc >>> The requirement "the client MUST be able to determine whether an AS >>> has the authority to issue access tokens for a certain RS. This can >>> for example be done through pre-configured lists, or through an online >>> lookup mechanism that in turn also must be secured." indicates that C >>> is required to have another mechanism to determine the AS for a >>> specific RS and that the unauthorized AS address is completely >>> redundant. >> >>No. This indicates that before contacting an AS (in order to retrieve an >>access token for its communication with RS), the client must be sure >>that it trusts the AS to provide this access token. This is something >>that the client always needs to
Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address, DoS, and privacy
Hi John, On 09/09/2020 11:36 AM, John Mattsson wrote: >>> As currently specified in draft-ietf-ace-oauth-authz-35, the RS will >>> happily send the AS address to any node that asks. This causes two >>> problems. >>> >>> - If C acts on the unauthorized information, this is an attack vector >>> for DoS attacks as an attacker on the C-RS path can make C contact a >>> chosen node on the Internet. >> >> The important part here is the "If". A proper client MUST NOT act on >> unauthorized information at any time. The workaround is the list of >> known AS'es in the draft. (In the current architecture, a client would >> not and cannot communicate with an unknown AS anyway as it has no way to >> establish a secure communication.) > > I cannot find anything in the draft stating that “A proper client MUST NOT > act on unauthorized information at any time”. This also raises the question > why the unauthorized information is needed in the first place. Hm, section 6.5 already states "the client MUST be able to determine whether an AS has the authority to issue access tokens for a certain RS." We can add "The client must not interact with an AS if it cannot determine that AS has the authority for this RS." We also should change section 6.4 because the attack described there is not possible as C must not interact with an AS that is not authorized for this RS. I think that paragraph is a relic. How about: old: Initially, no secure channel exists to protect the communication between C and RS. Thus, C cannot determine if the AS Request Creation Hints contained in an unprotected response from RS to an unauthorized request (see Section 5.1.2) are authentic. It is therefore advisable to provide C with a (possibly hard-coded) list of trustworthy authorization servers, possibly including information used to authenticate the AS, such as a public key or certificate fingerprint. AS Request Creation Hints referring to a URI not listed there would be ignored. A compromised RS may use the hints to trick a client into contacting an AS that is not supposed to be in charge of that RS. Since this AS must be in the hard-coded list of trusted AS no violation of privileges and or exposure of credentials should happen, since a trusted AS is expected to refuse requestes for which it is not applicable and render a corresponding error response. However a compromised RS may use this to perform a denial of service against a specific AS, by redirecting a large number of client requests to that AS. new: Initially, no secure channel exists to protect the communication between C and RS. Thus, C cannot determine if the AS Request Creation Hints contained in an unprotected response from RS to an unauthorized request (see Section 5.1.2) are authentic. C therefore must be able to determine if an AS is authorized to provide access tokens for a certain RS. A compromised RS may use the hints for attempting to trick a client into contacting an AS that is not supposed to be in charge of that RS. Therefore, C must not communicate with an AS if it cannot determine that this AS has the authority to issue access tokens for this RS. Otherwise, a compromised RS may use this to perform a denial of service against a specific AS, by redirecting a large number of client requests to that AS. > >>> - That RS shares the AS address with anybody that asks can be a severe >>> privacy problem. If RS is a medical device, the AS address can reveal >>> sensitive information. If RS is a blood pressure sensor it could >>> e.g. be “AS address = >>> coaps://as.hopkinsmedicine.org/kimmel_cancer_center/” >> >> This is a valid concern. However, I would argue that the Uri-Path in >> this URI should not be constructed to reveal this information in the >> first place. All discussions so far assumed that the authorization >> information endpoint on the AS would be named more descriptively as, >> e.g., /autz-info. This could at least mitigate the issue. > > I don’t find anything in the draft stating that “the Uri-Path in this URI > should not be constructed to reveal this information”, or how such a > construction would look like. This is not trivial. I guess that an authorization server with such a URI is a general problem since the client needs to communicate with it at some point. This problem therefore is not specific for the AS Request Creation Hints. Nevertheless, we should clarify the impact of the not carefully chosen hints on the privacy in the privacy considerations. There already is some text about the unauthorized request in the privacy considerations. How about: old: An unprotected response to an unauthorized request (see Section 5.1.2) may disclose information about RS and/or its existing relationship with C. It is advisable to include as little information as possible in an unencrypted response. new: An unprotected response to an unauthorized request (see Section 5.1.2) may disclose information about RS and/or its existing relationship with C. It
Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address, DoS, and privacy
Hi Olof, Your reasoning does seem to be anchored in the draft. See inline. The current state of the draft is not acceptable. Grüße, John Preuß Mattsson -Original Message- From: Olaf Bergmann Date: Wednesday, 9 September 2020 at 10:20 To: John Mattsson Cc: "ace@ietf.org" , "draft-ietf-ace-oauth-authz@ietf.org" Subject: Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address, DoS, and privacy Hello John, Thank you for condensing this discussion thread. See inline for my reasoning why I think that this issue is less severe than one would expect at first: John Mattsson writes: >> Summarizing my thoughts and opinion on this issue. Changing the title >> to highlight the issues better. >> >> As currently specified in draft-ietf-ace-oauth-authz-35, the RS will >> happily send the AS address to any node that asks. This causes two >> problems. >> >> - If C acts on the unauthorized information, this is an attack vector >> for DoS attacks as an attacker on the C-RS path can make C contact a >> chosen node on the Internet. > >The important part here is the "If". A proper client MUST NOT act on >unauthorized information at any time. The workaround is the list of >known AS'es in the draft. (In the current architecture, a client would >not and cannot communicate with an unknown AS anyway as it has no way to >establish a secure communication.) I cannot find anything in the draft stating that “A proper client MUST NOT act on unauthorized information at any time”. This also raises the question why the unauthorized information is needed in the first place. >> - That RS shares the AS address with anybody that asks can be a severe >> privacy problem. If RS is a medical device, the AS address can reveal >> sensitive information. If RS is a blood pressure sensor it could >> e.g. be “AS address = >> coaps://as.hopkinsmedicine.org/kimmel_cancer_center/” > >This is a valid concern. However, I would argue that the Uri-Path in >this URI should not be constructed to reveal this information in the >first place. All discussions so far assumed that the authorization >information endpoint on the AS would be named more descriptively as, >e.g., /autz-info. This could at least mitigate the issue. I don’t find anything in the draft stating that “the Uri-Path in this URI should not be constructed to reveal this information”, or how such a construction would look like. This is not trivial. >> The requirement "the client MUST be able to determine whether an AS >> has the authority to issue access tokens for a certain RS. This can >> for example be done through pre-configured lists, or through an online >> lookup mechanism that in turn also must be secured." indicates that C >> is required to have another mechanism to determine the AS for a >> specific RS and that the unauthorized AS address is completely >> redundant. > >No. This indicates that before contacting an AS (in order to retrieve an >access token for its communication with RS), the client must be sure >that it trusts the AS to provide this access token. This is something >that the client always needs to do, independent of the discovery >mechanism. I don’t find anything in the draft stating that “the client must be sure that it trusts the AS”. The draft states that “It is therefore advisable to provide C with a (possibly hard-coded) list of trustworthy authorization servers”. “Advisable” is not the same as “must”, “trustworthy” is not the same as “trust, and “C trust in AS” is completely different than “whether an AS has the authority to issue access tokens for a certain RS” >> The draft does not discuss the privacy issues of unauthorized AS >> addresses at all and the draft is diminishing the DoS issues by only >> talking about compromised RS and attacking an AS. This indicates that >> none of these issues has been discussed enough. >> >> I currently have a strong opinion that Unauthorized AS address should >> be removed from the specification. > >I still think that due to the lack of a secure discovery mechanism for >authorized AS'es, this mechanism is the best we have. Otherwise, the >specification would leave the reader completely in the dark on how to >guess to which AS the RS has delegated its authorization tasks. (A >natural way would be to include it in /.well-known/core but I fail to >see a difference except for an additional roundtrip in case the client >is not aware a priori that the requested resource is protected.) Your reasoning seems to indicate that the mechanism "the client MUST be able to determine whether an AS has the authority to issue access tokens for a certain RS” is just an imaginary requirement, and not something you believe will be possible in practice. Grüße Olaf ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address, DoS, and privacy
Hello John, Thank you for condensing this discussion thread. See inline for my reasoning why I think that this issue is less severe than one would expect at first: John Mattsson writes: > Summarizing my thoughts and opinion on this issue. Changing the title > to highlight the issues better. > > As currently specified in draft-ietf-ace-oauth-authz-35, the RS will > happily send the AS address to any node that asks. This causes two > problems. > > - If C acts on the unauthorized information, this is an attack vector > for DoS attacks as an attacker on the C-RS path can make C contact a > chosen node on the Internet. The important part here is the "If". A proper client MUST NOT act on unauthorized information at any time. The workaround is the list of known AS'es in the draft. (In the current architecture, a client would not and cannot communicate with an unknown AS anyway as it has no way to establish a secure communication.) > - That RS shares the AS address with anybody that asks can be a severe > privacy problem. If RS is a medical device, the AS address can reveal > sensitive information. If RS is a blood pressure sensor it could > e.g. be “AS address = > coaps://as.hopkinsmedicine.org/kimmel_cancer_center/” This is a valid concern. However, I would argue that the Uri-Path in this URI should not be constructed to reveal this information in the first place. All discussions so far assumed that the authorization information endpoint on the AS would be named more descriptively as, e.g., /autz-info. This could at least mitigate the issue. > The requirement "the client MUST be able to determine whether an AS > has the authority to issue access tokens for a certain RS. This can > for example be done through pre-configured lists, or through an online > lookup mechanism that in turn also must be secured." indicates that C > is required to have another mechanism to determine the AS for a > specific RS and that the unauthorized AS address is completely > redundant. No. This indicates that before contacting an AS (in order to retrieve an access token for its communication with RS), the client must be sure that it trusts the AS to provide this access token. This is something that the client always needs to do, independent of the discovery mechanism. > The draft does not discuss the privacy issues of unauthorized AS > addresses at all and the draft is diminishing the DoS issues by only > talking about compromised RS and attacking an AS. This indicates that > none of these issues has been discussed enough. > > I currently have a strong opinion that Unauthorized AS address should > be removed from the specification. I still think that due to the lack of a secure discovery mechanism for authorized AS'es, this mechanism is the best we have. Otherwise, the specification would leave the reader completely in the dark on how to guess to which AS the RS has delegated its authorization tasks. (A natural way would be to include it in /.well-known/core but I fail to see a difference except for an additional roundtrip in case the client is not aware a priori that the requested resource is protected.) Grüße Olaf ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
[Ace] draft-ietf-ace-oauth-authz-35 - unauthorized AS address, DoS, and privacy
Hi, Summarizing my thoughts and opinion on this issue. Changing the title to highlight the issues better. As currently specified in draft-ietf-ace-oauth-authz-35, the RS will happily send the AS address to any node that asks. This causes two problems. - If C acts on the unauthorized information, this is an attack vector for DoS attacks as an attacker on the C-RS path can make C contact a chosen node on the Internet. - That RS shares the AS address with anybody that asks can be a severe privacy problem. If RS is a medical device, the AS address can reveal sensitive information. If RS is a blood pressure sensor it could e.g. be “AS address = coaps://as.hopkinsmedicine.org/kimmel_cancer_center/” The requirement "the client MUST be able to determine whether an AS has the authority to issue access tokens for a certain RS. This can for example be done through pre-configured lists, or through an online lookup mechanism that in turn also must be secured." indicates that C is required to have another mechanism to determine the AS for a specific RS and that the unauthorized AS address is completely redundant. The draft does not discuss the privacy issues of unauthorized AS addresses at all and the draft is diminishing the DoS issues by only talking about compromised RS and attacking an AS. This indicates that none of these issues has been discussed enough. I currently have a strong opinion that Unauthorized AS address should be removed from the specification. Cheers, John ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
