All of
 help / color / mirror / Atom feed
From: Brian Gix <>
To: Luiz Augusto von Dentz <>
Cc: Vinicius Costa Gomes <>,
Subject: Re: LE Kernel (bluetooth-le-2.6) and LE Security Manager
Date: Mon, 24 Jan 2011 12:33:00 -0800	[thread overview]
Message-ID: <1295901180.2656.45.camel@ubuntuLab1> (raw)
In-Reply-To: <>

Hi Luiz,

On Mon, 2011-01-24 at 22:09 +0200, Luiz Augusto von Dentz wrote:
> Hi,
> On Mon, Jan 24, 2011 at 9:03 PM, Brian Gix <> wrote:
> > Hi Vinicius,
> >
> >
> > 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.
> But the point of MITM is man in the middle protection, so if we end up
> with a key which is not MITM there is no protection why store the link
> key? Actually if we do that we can end up in a situation where
> insufficient security is always triggered and the other stack may
> attempt to repair but with current code it will never succeed to
> generate a valid MITM link key. Anyway I suppose supporting MITM is
> mandatory so obviously the only possible fix for this is to support

The basic use case envisioned is that the two sides do not necessarily
know what the other side can support or has available until it attempts
this "pairing" operation.  So we want to avoid this catch 22:

1. We support MITM but don't know if the other side does, nor if it
requires it. With the code I just tested, the remote side (bluez)
indicated that it doesn't not support MITM and therefore rejects

2. However, if we support MITM but don't know if the other side does and
we *do not* request MITM, then a remote side that *requires* MITM should
reject us for *not* requesting it.

The solution is therefore to *always* request MITM, if you are capable
of supporting it.  If it turns out that neither side actually needs it,
then there is no harm in having provided it. If one side does not
support it (as bluez currently does not) and the other side requires it,
then it is up to the side that *requested* MITM to reject the pairing
attempt, if it determines that MITM is required.

A low security device like the current bluez should *never* reject a
pairing request because the other side needs MITM.  It is up to the side
that has the MITM requirement to issue the Security Failure packet.

So until bluez can support MITM, it should *accept* remote requests for
MITM, knowing that the remote side may reject it.  As long as bluez
advertises no OOB and NO_IN_NO_OUT, there will be no MITM.  It should
just not request MITM, and then provide no way to achieve it.


Brian Gix
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum

  reply	other threads:[~2011-01-24 20:33 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 [this message]
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
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:

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

  git send-email \
    --in-reply-to=1295901180.2656.45.camel@ubuntuLab1 \ \ \ \ \

* 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.