All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Gix <bgix@codeaurora.org>
To: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Cc: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>,
	linux-bluetooth@vger.kernel.org
Subject: Re: LE Kernel (bluetooth-le-2.6) and LE Security Manager
Date: Tue, 25 Jan 2011 09:10:51 -0800	[thread overview]
Message-ID: <1295975451.2656.63.camel@ubuntuLab1> (raw)
In-Reply-To: <1295974727.2656.57.camel@ubuntuLab1>

Hi Luiz & Vinicius,


On Tue, 2011-01-25 at 08:58 -0800, Brian Gix wrote:
> On Tue, 2011-01-25 at 10:35 +0200, Luiz Augusto von Dentz wrote:
> > Hi Vinicius,
> > 
> > On Mon, Jan 24, 2011 at 11:34 PM, Vinicius Costa Gomes
> > <vinicius.gomes@openbossa.org> wrote:
> > > Hi Brian,
> > >
> > > On 11:03 Mon 24 Jan, Brian Gix wrote:
> > >> Hi Vinicius,
> > >>
> > >> I am sorry that it has taken so long to test the snapshot that you
> > >> placed on gitorious, but I have now done so.
> > >>
> > >> On Fri, 2010-12-03 at 19:05 -0300, Vinicius Costa Gomes wrote:
> > >> > Hi Brian,
> > >> >
> > >> > On 11:11 Fri 03 Dec, Brian Gix wrote:
> > >> > >
> > >> > > Hi Claudio, Johan & All,
> > >> > >
> > >> > > Is this LE capable kernel that Ville is working on, the development stream
> > >> > > for the LE Security Manager?  And if so, is it in a partial fleshed out
> > >> > > state?
> > >> >
> > >> > There is a simple implementation of SMP here[1] on my "devel" branch. I am
> > >> > cleaning it up for sending it for review.
> > >> >
> > >> > If you want to help, have any comments or just want to tell us what you are
> > >> > working on, please drop by #bluez on freenode, or send an email.
> > >>
> > >> I have been able to verify that the Just Works negotiation of the Short
> > >> Term Key does work against an independent implementation of the LE
> > >> Security Manager, as long as I have requested no MITM protection.  I
> > >> have the following comments:
> > >>
> > >> 1. You currently reject security if I *do* request MITM protection.
> > >> This should not be done.  The correct functionality should be to
> > >> continue the negotiation.  Even though I requested MITM, it will be
> > >> clear to both sides that JUST_WORKS methodology has been used, and so
> > >> when the Keys are generated and exchanged, both sides will indicate in
> > >> their Key Database that they are no-MITM keys. If I then actually
> > >> *needed* MITM protection, then whatever functionality requiring that
> > >> level of security will fail with an insufficient security error code.
> > >> However, security should *never* be rejected unless there is a
> > >> fundamental incompatibility such as no level of security actually
> > >> supported.  This is the only functionality that I found to be actually
> > >> incorrect.
> > >>
> > >
> > > I was assuming that the meaning of setting the MITM protection bit, was that
> > > it was *requiring* MITM protection, and when that couldn't be fulfilled the
> > > Pairing Request should be rejected.
> > >
> > > So my assumption was incorrect, going to fix it soon.
> > 
> > Well the spec says it is a requirement:
> > 
> > "If the STK generation method does not result in an STK that provides
> > sufficient security properties then the device shall send the Pairing
> > Failed command with the error code “Authentication Requirements”" -
> > 2.3.5.1 Selecting STK Generation Method - Page 608

My interpretation of the paragraph at the end of page 608 is that if a
device realizes that the security level that will results will not meet
it's minimum security requirements, then it may reject and abort the
pairing.

I think it is a bad reading, though, for a device to reject a pairing if
it thinks that the *other* device will not be satisfied.  However that
is the case here.  In this case, it was the device that did *not* have
the MITM option set (the low security device) that was rejecting the
device *with* the MITM option set.

> 
> >From Page 607:
> "If both devices have out of band authentication data, then the
> Authentication Requirements Flags shall be ignored when selecting the
> pairing method and the Out of Band pairing method shall be used. If both
> devices have not set the MITM option in the Authentication Requirements
> Flags, then the IO capabilities shall be ignored and the Just Works
> association model shall be used. Otherwise the IO capabilities of the
> devices shall be used to determine the pairing method as defined in
> Table 2.4."
> 
> In the test case I ran, only One device (i.e. NOT BOTH) had the MITM
> option set. So my reading is that the IO Capabilities should be ignored,
> and JUST_WORKS used.
> 
> Remember the phone use case: When it needs to pair with a remote device,
> it is usually a GATT client that can support any level of security. It
> does not know if this new remote device requires MITM security, or No
> security.  However as the link Master and Initiator, it has to choose
> one.  It Chooses MITM, and if the remote side supports MITM, then
> pairing proceeds with a resulting MITM protection level. If the remote
> device is a simple dumb device with no security, it also needs to
> proceed without failing, but this time it completes with NO-MITM as the
> protection level. If it fails because the remote doesn't require
> security, then there is a fundamental incompatibility between the
> devices, which in the SIG we have tried to avoid.
> 
> > 
> > In my interpretation this is exactly what should happen when MITM is
> > set but there is no way to generate an authenticated key as Table 2.4:
> > Mapping of IO Capabilities to STK Generation Method suggest, in other
> > words if one of sides has NoInputNoOutput and MITM is set we should
> > return "Authentication Requirements" error.
> > 
> 

-- 
Brian Gix
bgix@codeaurora.org
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum


  reply	other threads:[~2011-01-25 17:10 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-03 19:11 LE Kernel (bluetooth-le-2.6) and LE Security Manager Brian Gix
2010-12-03 22:05 ` Vinicius Costa Gomes
2010-12-04  0:40   ` Brian Gix
2010-12-06 14:50     ` Vinicius Costa Gomes
2011-01-24 19:03   ` Brian Gix
2011-01-24 20:09     ` Luiz Augusto von Dentz
2011-01-24 20:33       ` Brian Gix
2011-01-24 21:34     ` Vinicius Costa Gomes
2011-01-25  8:35       ` Luiz Augusto von Dentz
2011-01-25 16:58         ` Brian Gix
2011-01-25 17:10           ` Brian Gix [this message]
2011-01-25 17:59           ` Johan Hedberg
2011-01-25 18:35             ` Brian Gix
2011-01-25 21:44               ` Luiz Augusto von Dentz
2011-01-25 22:04                 ` Brian Gix
2011-01-26 17:54                   ` Brian Gix
2011-01-28 23:19       ` GATT and D-Bus Inga Stotland
2011-01-29  0:07         ` Vinicius Costa Gomes

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=1295975451.2656.63.camel@ubuntuLab1 \
    --to=bgix@codeaurora.org \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=luiz.dentz@gmail.com \
    --cc=vinicius.gomes@openbossa.org \
    /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.