[PATCH] The current behaviour of hostapd_das_find_sta() is undesirable as it can result in over broad, potentially insecure matching.

[Nick Lowe]

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 at w1.fi> 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