RE: PTS / linkkey issue

["Tom Allebrandi" <wyrles@ytram.com>]

> -----Original Message-----
> From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-
> owner@vger.kernel.org] On Behalf Of Marcel Holtmann
> Sent: Monday, April 23, 2012 2:41 AM
> To: Johan Hedberg
> Cc: Mike; linux-bluetooth
> Subject: Re: PTS / linkkey issue
>=20
> Hi Johan,
>
> > I don't think it's a good idea to mix the security level
> > (MITM/no-MITM) requirement with the permanence requirement
> > (no-bonding/bonding). Those really are and should remain as =
orthogonal
> > requirements. Even though OPP is the only profile we know that it's
> > natural to use no-bonding for there may well be use cases where you
> > want a secure connection for sensitive data but want to forget about
> > the security relationship once the connection is gone.
> >
> > I also think this is what the core spec intends since you've got the
> > option of no-bonding with MITM and no-bonding without MITM. Even the
> > table (5.7, page 1671) that defines the security levels talks =
nothing
> > about the permanence of the link key but only about authenticated vs
> > unauthenticated and MITM vs no MITM. Mixing the no-bonding stuff =
into
> > the security level would then also confuse anyone thinking that our
> > security levels are mappings to how the core spec defines them to =
be.
>=20
> fair point. Let them get the PTS fixed.
>=20
> However we could add an extra option to the security field that would =
make
> it depend on the pairing setting. This is all still speculation since =
we have no
> idea if it would not break GAP qualification.
>=20
> Regards
>=20
> Marcel


Hi All -

Out of curiosity, what is the PIXIT value TSPX_delete_link_key set to?

>From the discussion that has been going on here, I think it should set =
to FALSE in all of the profiles where you want the bonding to persist.

As you might guess from its name: TSPX_delete_link_key set to TRUE will =
delete the stored link key at the start of a test case. In other words, =
delete the bonding. TSPX_delete_link_key set to FALSE will leave the =
stored link key in place and use it during the authentication process -- =
that is, using the existing bonding.

There are some issues with selecting the proper security mode and I/O =
Capabilities. Part of it >>> seems <<< to be related to the security =
module in our host stack ignoring the security configuration we send =
down from the test cases. ("Seems" because it feels that way to me but I =
have no hard evidence.)

For the issues that have been reported, some combination of =
TSPX_delete_link_key is a workaround. Sometimes it works best to set it =
one way, sometimes the other.

At times, setting it to TRUE to trigger a pairing process and then =
setting it to FALSE works best.

Because of the available workaround, the issues that Mike mentioned =
earlier have not been given a high priority. A general review/repair of =
the security management situation is on my list of projects for later =
for this year. It may get bumped up in priority due to some other work I =
am doing where I need "fine granularity" control over the security =
configuration.


So, in summary, play with TSPX_delete_link_key and see if that helps. I =
know that it's not a satisfying solution, I >>> personally <<< don't =
like it either. But, a workaround is a workaround until something better =
comes along :-).

Cheers!

--- tom
tom allebrandi
wyrles@ytram.com