Received-SPF: pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20200519202519.219335-1-luiz.dentz@gmail.com> <20200519202519.219335-2-luiz.dentz@gmail.com>
 <C478BA49-0BBF-4323-AC3A-30442F65D346@holtmann.org> <CALWDO_UEPaAGyLFG93JzT41P=yGePB-N2Pbh5hioLBOXdh2YBw@mail.gmail.com>
 <23C4DB2B-4C5E-45E7-A777-6F26A675EB92@holtmann.org>
In-Reply-To: <23C4DB2B-4C5E-45E7-A777-6F26A675EB92@holtmann.org>
From:   Alain Michaud <alainmichaud@google.com>
Date:   Tue, 26 May 2020 10:30:25 -0400
Message-ID: <CALWDO_XztiDRfQEtioALNmO9smLm-qTW56hxkw8-ZH-Aw2cH1g@mail.gmail.com>
Subject: Re: [PATCH 2/4] Bluetooth: Fix assuming EIR flags can result in SSP authentication
To:     Marcel Holtmann <marcel@holtmann.org>
Cc:     Luiz Augusto von Dentz <luiz.dentz@gmail.com>,
        BlueZ <linux-bluetooth@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

Hi Luiz,

On Tue, May 26, 2020 at 10:17 AM Marcel Holtmann <marcel@holtmann.org> wrot=
e:
>
> Hi Alain,
>
> > Starting with the 2.1 specification, it is my interpretation that it
> > is not valid to support EIR but not SSP.  I understand that SSP may be
> > disabled from BlueZ's point of view, but this doesn't seem to be a
> > legitimate/qualifiable configuration.  Should we instead fail the
> > legacy pairing if EIR was received as an invalid condition?
>
> I know that using EIR requires to also use SSP. However this is just a pr=
ecaution in case the other device is an attacked and tries to trick us.
>
> You might get an inquiry result and not extended inquiry result, but you =
are still talking to a SSP device. This has to do with the fact that the re=
ception of EIR is not guaranteed. In case of radio interference you might m=
iss one and only get an ordinary inquiry result.
>
> If we indeed received an EIR and then get legacy pairing request, we coul=
d try to reject the pairing. However keep in mind that our inquiry cache is=
 time limited and we through outdated information away. This might cause so=
me race condition. So I rather read the remote host features to ensure we k=
now the actual host features of the remote device.

You are correct, the EIR response is not a guaranteed thing.  For this
reason, the host should try to resolve the name of the device before
initiating bonding where a Remote Host Supported Feature Notification
Event is generated to signal the remote side's support of SSP.  As you
allude to, a remote spoofing a legitimate SSP device may always just
jam and downgrade to not SSP, but if you have any signals that SSP is
supported by the device, it may be a good defensive posture.
Receiving an EIR response or a Remote Host Supported Feature Event
with the SSP bit set is a good indication that the device supports SSP
and you should expect SSP to take place.  Again, it is not a valid
configuration to have EIR enabled but not SSP per my interpretation of
the 2.1 specification.


>
> Regards
>
> Marcel
>