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