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 <[email protected]> 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 <[email protected]> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
