Hi Marcel, On Mon, Apr 23, 2012, Marcel Holtmann wrote: > > > the real problem that you are seeing here is that the disappearing of > > > the BlueZ devices and with that the oFono modem is actually fully > > > intentional. It boils all down to the no bonding pairing. The device > > > never gets marked as bonded. > > > > > > I honestly have no idea on how to workaround this issue. My only idea is > > > that we combine the access to a RFCOMM server channel with a re-pairing > > > to upgrade this to general bonding. Problem is just that I have no idea > > > if this would fly with the GAP qualification or not. Or if we would > > > break that one then. > > > > This whole thing looks so obviously as a PTS issue to me that I don't > > see why anyone should spend any effort on anything else than raising an > > errata for the PTS. > > > > As far as what you're suggesting as a potential workaround it still > > wouldn't guarantee that the PTS would start giving an authentication > > requirement other than no-bonding. We can only control our own > > authentication requirement. > > > > Furthermore, you couldn't have this as general RFCOMM server behavior > > since there are servers for which no-bonding may be desirable, like OPP, > > and clients might not be tested to handle rejecting our general bonding > > request properly if they were designed to assume they can get by with > > their initial no-bonding request. > > I was considering that if pairing is allowed and security is either > medium or high, then we force a repairing if the link key is temporary. > > Something like in the area of a no bonding link key is only allowed to > connect a security low service. And if pairing is not allowed and you > try to access a medium or high security service with no bonding, you > will just get rejected. 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. Johan -- 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
