From: Timo Mueller <timo.mueller@oss.bmw-carit.de>
To: linux-bluetooth@vger.kernel.org
Cc: Timo Mueller <timo.mueller@bmw-carit.de>
Subject: [RFCv5 0/4] SSP MITM protection
Date: Tue, 8 Apr 2014 14:21:30 +0200 [thread overview]
Message-ID: <cover.1396943583.git.timo.mueller@bmw-carit.de> (raw)
From: Timo Mueller <timo.mueller@bmw-carit.de>
Hi,
this is an updated version of v4 with the following changes:
1) The management option to relax the MITM Protection was dropped
2) Some minor modifications to the commit messages
Test information from the v4 cover letter:
<snip>
I've successfully tested these changes in the last couple of months at
the UPF #46 in Vienna, with the CE4A golden device and the bluetooth
PTS (where applicable).
<snip>
>From the original cover letter:
The way the kernel handles MITM Protection during pairing is
inconsistent: General Bonding and Dedicated Bonding are not treated
equally.
<snip>
Therefore, the safest choice is to always request MITM Protection,
also for General Bonding [1]. The proposal here is to do this for both
incoming (patch 6/8) and outgoing (patch 7/8) procedures, as it was
previously done for Dedicated Bonding. This "conservative" approach is
smart enough to fall back to not using MITM Protection if the IO
capabilities don't allow it (this policy already existed before for
Dedicated Bonding, see patch 5/8).
<snip>
For completeness, a quick recap on the motivation behind this patch
set:
In our cars we always want to use SSP methods other than Just
Works. We even go as far as rejecting JW connection attempts. In order
to still be able to pair all devices that are capable of using any of
the remaining SSP methods, we need to make sure that we're not falling
back to JW, regardless of the bonding type (Dedicated or General). For
example, currently a connection with the iPhone acting as the
initiating LM would lead a JW connection which would get rejected.
Best regards
Timo
Mikel Astiz (3):
Bluetooth: Refactor hci_get_auth_req()
Bluetooth: Refactor code for outgoing dedicated bonding
Bluetooth: Request MITM Protection when initiator
Timo Mueller (1):
Bluetooth: Use MITM Protection when IO caps allow it
net/bluetooth/hci_event.c | 48 ++++++++++++++++++++++++++---------------------
net/bluetooth/mgmt.c | 5 +----
2 files changed, 28 insertions(+), 25 deletions(-)
--
1.9.0
next reply other threads:[~2014-04-08 12:21 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-08 12:21 Timo Mueller [this message]
2014-04-08 12:21 ` [RFCv5 1/4] Bluetooth: Refactor hci_get_auth_req() Timo Mueller
2014-04-08 12:21 ` [RFCv5 2/4] Bluetooth: Refactor code for outgoing dedicated bonding Timo Mueller
2014-04-08 12:21 ` [RFCv5 3/4] Bluetooth: Use MITM Protection when IO caps allow it Timo Mueller
2014-04-08 12:21 ` [RFCv5 4/4] Bluetooth: Request MITM Protection when initiator Timo Mueller
2014-04-11 19:04 ` [RFCv5 0/4] SSP MITM protection Johan Hedberg
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=cover.1396943583.git.timo.mueller@bmw-carit.de \
--to=timo.mueller@oss.bmw-carit.de \
--cc=linux-bluetooth@vger.kernel.org \
--cc=timo.mueller@bmw-carit.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).