Sam Hartman [mailto:hartmans-i...@mit.edu] writes:
> >>>>> "Glen" == Glen Zorn <g...@net-zen.net> writes: > > the corporate network example from my first message as > >> a case in point. The corporation has two levels of trust: > >> internal and everyone else. Internal entities may claim to be > >> corporate access points. People who are part of "everyone else," > >> are not permitted to make this statement. The corporation need > >> not worry about what happens if a roaming partner claimed in AAA > >> attributes to be the corporation's network: such a statement > >> would simply be rejected by some proxy within the corporate > >> border. > > Glen> s/within/at: if said proxy is even one AAA hop inside the > Glen> border an invalid claim may be indistinguishable from a valid > Glen> one. > > The key word there is may. If that's the key word, then forget it ;-). In actual fact, it is impossible within either standard RADIUS or standard Diameter to securely determine where a message came from beyond the node from which it was sent. To be clear, if the filtering proxy is inside the corporate network, it will be incapable of securely determining whether the message originated outside that network or not. I used the word "may" because somebody somewhere may have devised a method for doing this; I make know claim of omniscience. > Depending on topology, configuration and > policy, it may be possible to distinguish things beyond the border. Policy & configuration cannot solve the problem, which is a protocol deficiency. > I agree the border is a logical place to make this distinction though. > > > >> > >> More general, at each level in a proxy chain, you can consider > >> whether the party you receive a message from is permitted to > >> claim the attributes that are claimed in the proxy request. > > Glen> You can. but in this context it's difficult to see how an > Glen> intermediate proxy could filter on SSID (for example) w/o > Glen> detailed knowledge of the topology of both the originating and > > I absolutely agree that the intermediate proxy needs sufficient > knowledge to perform the filtering. Depending on the specific filter, > it is definitely the case that the proxy will need information about the > origin and destination organizations and networks. That level of detail > is very often spelled out in business agreements for trading partners, > in the banking industry, and presumably in other industries I'm less > familiar with. I'm not aware of cases where AAA configuration was the > subject of these agreements, but I've also not been in a position where > I cared about the AAA infrastructure before. > > But yes, for a lot of filters you need to understand the routing > topology well enough to understand whether a particular proxy should > legitimately be on the path between you and a given origin. For RADIUS > at least, I do understand the difficulty in getting that information; > I'd rate it as higher than you'd probably want for most current network > access situations, but definitely not impossible. Nothing is impossible, but at the moment there is no way to do it and no clear way to accomplish it. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
