linux-bluetooth.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mikel Astiz <mikel.astiz.oss@gmail.com>
To: linux-bluetooth@vger.kernel.org
Cc: Mikel Astiz <mikel.astiz@bmw-carit.de>
Subject: [RFC BlueZ v3 5/8] Bluetooth: Refactor code for outgoing dedicated bonding
Date: Fri, 28 Jun 2013 10:56:31 +0200	[thread overview]
Message-ID: <1372409794-24688-6-git-send-email-mikel.astiz.oss@gmail.com> (raw)
In-Reply-To: <1372409794-24688-1-git-send-email-mikel.astiz.oss@gmail.com>

From: Mikel Astiz <mikel.astiz@bmw-carit.de>

Do not always set the MITM protection requirement by default in the
field conn->auth_type, since this will be added later in
hci_io_capa_request_evt(), as part of the requirements specified in
HCI_OP_IO_CAPABILITY_REPLY.

This avoids a hackish exception for the auto-reject case, but doesn't
change the behavior of the code at all.

Signed-off-by: Mikel Astiz <mikel.astiz@bmw-carit.de>
---
 net/bluetooth/hci_event.c | 14 ++++++++------
 net/bluetooth/mgmt.c      |  5 +----
 2 files changed, 9 insertions(+), 10 deletions(-)

diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index fe78b9c..4e5dc5b 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -3075,6 +3075,11 @@ static void hci_io_capa_request_evt(struct hci_dev *hdev, struct sk_buff *skb)
 		/* If we are initiators, there is no remote information yet */
 		if (conn->remote_auth == 0xff) {
 			cp.authentication = conn->auth_type;
+
+			/* Use MITM protection for outgoing dedicated bonding */
+			if (conn->io_capability != HCI_IO_NO_INPUT_OUTPUT &&
+			    cp.authentication == HCI_AT_DEDICATED_BONDING)
+				cp.authentication |= 0x01;
 		} else {
 			conn->auth_type = hci_get_auth_req(conn);
 			cp.authentication = conn->auth_type;
@@ -3146,12 +3151,9 @@ static void hci_user_confirm_request_evt(struct hci_dev *hdev,
 	rem_mitm = (conn->remote_auth & 0x01);
 
 	/* If we require MITM but the remote device can't provide that
-	 * (it has NoInputNoOutput) then reject the confirmation
-	 * request. The only exception is when we're dedicated bonding
-	 * initiators (connect_cfm_cb set) since then we always have the MITM
-	 * bit set. */
-	if (!conn->connect_cfm_cb && loc_mitm &&
-	    conn->remote_cap == HCI_IO_NO_INPUT_OUTPUT) {
+	 * (it has NoInputNoOutput) then reject the confirmation request
+	 */
+	if (loc_mitm && conn->remote_cap == HCI_IO_NO_INPUT_OUTPUT) {
 		BT_DBG("Rejecting request: remote device can't provide MITM");
 		hci_send_cmd(hdev, HCI_OP_USER_CONFIRM_NEG_REPLY,
 			     sizeof(ev->bdaddr), &ev->bdaddr);
diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
index fedc539..ca0ad32 100644
--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
@@ -2185,10 +2185,7 @@ static int pair_device(struct sock *sk, struct hci_dev *hdev, void *data,
 	}
 
 	sec_level = BT_SECURITY_MEDIUM;
-	if (cp->io_cap == 0x03)
-		auth_type = HCI_AT_DEDICATED_BONDING;
-	else
-		auth_type = HCI_AT_DEDICATED_BONDING_MITM;
+	auth_type = HCI_AT_DEDICATED_BONDING;
 
 	if (cp->addr.type == BDADDR_BREDR)
 		conn = hci_connect(hdev, ACL_LINK, &cp->addr.bdaddr,
-- 
1.8.1.4


  parent reply	other threads:[~2013-06-28  8:56 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-28  8:56 [RFC BlueZ v3 0/8] SSP MITM protection Mikel Astiz
2013-06-28  8:56 ` [RFC BlueZ v3 1/8] Bluetooth: Add HCI authentication capabilities macros Mikel Astiz
2013-06-28  8:56 ` [RFC BlueZ v3 2/8] Bluetooth: Use defines in in hci_get_auth_req() Mikel Astiz
2013-06-28  8:56 ` [RFC BlueZ v3 3/8] Bluetooth: Use defines instead of integer literals Mikel Astiz
2013-07-09 15:13   ` Gustavo Padovan
2013-06-28  8:56 ` [RFC BlueZ v3 4/8] Bluetooth: Refactor hci_get_auth_req() Mikel Astiz
2013-06-28  8:56 ` Mikel Astiz [this message]
2013-06-28  8:56 ` [RFC BlueZ v3 6/8] Bluetooth: Use MITM Protection when IO caps allow it Mikel Astiz
2013-06-28  8:56 ` [RFC BlueZ v3 7/8] Bluetooth: Request MITM Protection when initiator Mikel Astiz
2013-06-28  8:56 ` [RFC BlueZ v3 8/8] Bluetooth: Add management command to relax MITM Protection Mikel Astiz
2013-06-28 11:40 ` [RFC BlueZ v3 0/8] SSP MITM protection Mikel Astiz
2013-07-08 11:13   ` Mikel Astiz
2013-07-09 13:32     ` 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=1372409794-24688-6-git-send-email-mikel.astiz.oss@gmail.com \
    --to=mikel.astiz.oss@gmail.com \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=mikel.astiz@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).