RE: PTS / linkkey issue

["Tom Allebrandi" <wyrles@xxxxxxxxx>]

> -----Original Message-----
> From: linux-bluetooth-owner@xxxxxxxxxxxxxxx [mailto:linux-bluetooth-
> owner@xxxxxxxxxxxxxxx] 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
> 
> 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.
> 
> fair point. Let them get the PTS fixed.
> 
> 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.
> 
> Regards
> 
> 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@xxxxxxxxx


--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html