Hi Jouni, Requiring a match against all the session identifying attributes supplied would be fine and, of course, an order of precedence would be not applicable and meaningless at this point. That would be stricter that what the that patch I submitted does. Currently hostapd implements faulty logic such that any session identifying attribute that matches is acceptable. Herein lies the fault in the implementation. In the case that more than one session is matched, hostapd currently elects to do nothing. If this was changed in the future to permit more than one session to be matched, this could result in unexpected sessions being changed or disconnected. At present, this may result in expected sessions not being changed or disconnected due to multiple sessions being matched. Where the User-Name is being sent as a session identifying attribute alongside others, this can be manipulated for to cause deliberate malfunction of CoA-Request and Disconnect-Request by stations. Cheers, Nick On Sun, Mar 6, 2016 at 6:34 PM, Jouni Malinen <j@xxxxx> wrote: > On Sun, Mar 06, 2016 at 04:16:06PM +0000, Nick Lowe wrote: >> The current behaviour of hostapd_das_find_sta() is undesirable >> as it can result in over broad, potentially insecure matching. > > Could you please describe in detail why this is undesirable and what > exactly would be "potential insecure"? > >> It is best is to define an order of precedence for session identifying >> attributes, based on their specificity, and to match only by the most >> specific attribute that is present in a CoA-Request or >> Disconnect-Request packet. > > What is this based on? RFC 5176 is pretty clear on mandating _all_ the > specified attributes matching. This patch would not be compliant with > that. > > RFC 5176, Chapter 3. Attributes: > > In Disconnect-Request and CoA-Request packets, certain attributes are > used to uniquely identify the NAS as well as user session(s) on the > NAS. The combination of NAS and session identification attributes > included in a CoA-Request or Disconnect-Request packet MUST match at > least one session in order for a Request to be successful; otherwise > a Disconnect-NAK or CoA-NAK MUST be sent. If all NAS identification > attributes match, and more than one session matches all of the > session identification attributes, then a CoA-Request or Disconnect- > Request MUST apply to all matching sessions. > >> This order of precedence should be: >> >> Acct-Session-Id (Session) >> Acct-Multi-Session-Id (Session) >> Calling-Station-Id (Station) >> Chargeable-User-Identity (User) >> User-Name (User) > > It is up to the DAC to decide which filtering rules (and these are ANDed > together) to use. If it knows Acct-Session-Id and Acct-Multi-Session-Id > are supported, those should really be used. > >> Of particular concern is that the EAP outer identity, typically used >> to populate the User-Name can often be anonymised in a way that spoofs >> another active user. > > Sure, I would not a DAC to use User-Name with EAP authentication. Still, > I see no reason to change DAS implementation for this, i.e., this is > something to guide on the DAC side.. > >> Where we are given a specific CoA-Request or Disconnect-Request >> packet, we should handle it as being such. > > As far as I can tell, the current implementation complies with the RFC > 5176 requirements. You would need to provide quite a bit more > justification to change that to something non-compliant. > > -- > Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
