All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcel Holtmann <marcel@holtmann.org>
To: Alain Michaud <alainmichaud@google.com>
Cc: Luiz Augusto von Dentz <luiz.dentz@gmail.com>,
	BlueZ <linux-bluetooth@vger.kernel.org>
Subject: Re: [PATCH 2/4] Bluetooth: Fix assuming EIR flags can result in SSP authentication
Date: Tue, 26 May 2020 16:17:35 +0200	[thread overview]
Message-ID: <23C4DB2B-4C5E-45E7-A777-6F26A675EB92@holtmann.org> (raw)
In-Reply-To: <CALWDO_UEPaAGyLFG93JzT41P=yGePB-N2Pbh5hioLBOXdh2YBw@mail.gmail.com>

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 precaution 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 reception of EIR is not guaranteed. In case of radio interference you might miss one and only get an ordinary inquiry result.

If we indeed received an EIR and then get legacy pairing request, we could 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 some race condition. So I rather read the remote host features to ensure we know the actual host features of the remote device.

Regards

Marcel


  reply	other threads:[~2020-05-26 14:17 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-19 20:25 [PATCH 1/4] Bluetooth: Disconnect if E0 is used for Level 4 Luiz Augusto von Dentz
2020-05-19 20:25 ` [PATCH 2/4] Bluetooth: Fix assuming EIR flags can result in SSP authentication Luiz Augusto von Dentz
2020-05-20 14:34   ` Marcel Holtmann
2020-05-26 13:53     ` Alain Michaud
2020-05-26 14:17       ` Marcel Holtmann [this message]
2020-05-26 14:30         ` Alain Michaud
2020-05-28  8:22           ` Marcel Holtmann
2020-05-28 13:17             ` Alain Michaud
2020-05-28 16:53               ` Luiz Augusto von Dentz
2020-05-28 17:16                 ` Alain Michaud
2020-06-03 18:02                   ` Marcel Holtmann
2020-05-19 20:25 ` [PATCH 3/4] Bluetooth: Fix bogus check for re-auth no supported with non-ssp Luiz Augusto von Dentz
2020-05-20 14:25   ` Marcel Holtmann
2020-05-20 16:12     ` Luiz Augusto von Dentz
2020-05-19 20:25 ` [PATCH 4/4] Bluetooth: Consolidate encryption handling in hci_encrypt_cfm Luiz Augusto von Dentz
2020-05-20 14:31   ` Marcel Holtmann
2020-05-20 14:23 ` [PATCH 1/4] Bluetooth: Disconnect if E0 is used for Level 4 Marcel Holtmann
2020-05-20 16:00   ` Luiz Augusto von Dentz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=23C4DB2B-4C5E-45E7-A777-6F26A675EB92@holtmann.org \
    --to=marcel@holtmann.org \
    --cc=alainmichaud@google.com \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=luiz.dentz@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.