Hi Tom,
>> > 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?
Not 100% sure since I'm not the one running PTS. From what I've been
told (and have a trace of), if the value is FALSE, we can hardly even
run the tests because the tests expect the other side to authenticate
against that key, which it won't. If it is TRUE, we pass most of the
tests.
> 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.
Ideally, yes, but BlueZ is deleting the link key because of the "No
Bonding" type. From what the BlueZ developers say, this is the
correct behavior. Unless that is refuted, it is PTS that must change.
> 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 :-).
We have, only partially helps. I'll know tomorrow if the CreateDevice
workaround is effective. It may be. If not, the only real solution
to passing TP/OOR/BV-02-I is for PTS to request "General Bonding".
Thanks,
Mike
--
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
