On 23 Mar 2011, at 06:26 , Johan Hedberg wrote: > Hi, > > On Wed, Mar 23, 2011, Santiago Carot wrote: >>>> There has been discussion whether BlueZ HDP is correct or not in this >>>> respect. The HDP specification says that devices SHOULD require authenticated >>>> and encrypted connections (which maps to SEC_HIGH) while some devices are >>>> known not to use authentication (SEC_MEDIUM). But the word in spec is 'SHOULD', >>>> not 'SHALL'. >>> >>> An "authenticated" connection has a slightly ambiguous meaning in >>> Bluetooth since 2.1+EDR, since you can have an authenticated link that >>> does not have any MITM protection. >>> >>> I think the correct behavior is that HDP should be using "Level 2" >>> (from GAP in the Core specification), where HDP wants the strongest >>> level of security it can achieve with a device, but it does not want to >>> exclude devices that do not have the capability to support input/output. >>> >>> There does seem to be a slight discrepancy between SEC_MEDIUM in BlueZ >>> and Security Level 2 in GAP. I believe that the intention of Level 2 >>> is to propose that MITM protection is needed - however it will happily >>> accept security where no MITM protection has been achieved (this being >>> the difference between Level 2 and Level 3). BlueZ however does not >>> seem to propose MITM protection for SEC_MEDIUM - which would be important >>> for HDP (at least in the BlueZ <-> BlueZ case). >> >> I remember that issue with we were developing HDP and MCAP. We set >> SEC_HIGH in HDP to get encrypted channels and to pass Bluetooth PTS. >> The problem doing that is related with devices that don't support MITM >> protection (In fact if they don't have any >> user input capabilities). This may be a good opportunity to go back >> about this issue. What do you think? >> >> In any case, such as Elvis has said, you can disable sspmode to get >> HDP working without modify BlueZ code. > > Either I just don't remember correctly how SEC_MEDIUM is supposed to > work or then there's some confusion here. Medium security will require > encryption. The main difference that high security brings is that > unauthenticated link keys will not be accepted. Furthermore, you should > also be able to get an authenticated link key with medium security as > long as both sides have the IO capabilities for it and at least one side > requires MITM protection (only if *neither* side requires MITM will Just > Works be triggered). So it is a matter of testing HDP with Nonin oximeter (which works with HIGH security) having BlueZ set to MEDIUM. If it works ok, we should submit a patch to change HDP to MEDIUM.-- 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
