[Request] Clarification related to pairing in a particular scenario

[Request] Clarification related to pairing in a particular scenario

[Nagaraj D R]

SGVsbG8gYWxsLApjb3VsZCBzb21lb25lIHBsZWFzZSBjbGFyaWZ5IG15IGRvdWJ0IHJlbGF0ZWQg
dG8gdGhlIGNvbmNlcHQgb2YgcGFpcmluZyBpbiBhIHBhcnRpY3VsYXIgc2NlbmFyaW8KCklmIGEg
cmVtb3RlIGRldmljZSBoYXZpbmcgbm8gSS9PIGNhcGFiaWxpdHkgKGFsc28gYXV0aGVudGljYXRp
b24gOiBnZW5lcmFsIGJvbmRpbmcsIGFuZCAgTm8gTUlUTSBwcm90ZWN0aW9uKQpzZW50IGEgcGFp
cmluZyByZXF1ZXN0IHRvIG91ciBsb2NhbCBkZXZpY2UoRFVUIHJ1bm5pbmcgd2l0aCB0aGUgYmx1
ZXogc3RhY2spLCBsb2NhbCBkZXZpY2Ugc3RhY2sgYXV0byBhY2NlcHQKdGhlIHBhaXJpbmcgcmVx
dWVzdCBldmVuIHRob3VnaCBsb2NhbCBkZXZpY2UgaGFzIEkvTyBjYXBhYmlsaXR5CgpJcyB0aGUg
QmVoYXZpb3Igb2YgYXV0by1hY2NlcHRpbmcgdGhlIHBhaXJpbmcgcmVxdWVzdCBqdXN0aWZpZWQ/
Ci0tIEFjY29yZGluZyB0byB0aGUgc3BlY2lmaWNhdGlvbiAiRnJvbSB0aGUgQmx1ZXRvb3RoIENv
cmUgU3BlY2lmaWNhdGlvbiA0LjEgcGFnZSAxOTU4OgogImlmIGJvdGggZGV2aWNlcyBoYXZlIHNl
dCB0aGUgQXV0aGVudGljYXRpb25fUmVxdWlyZW1lbnRzIHBhcmFtZXRlciB0byBvbmUgb2YgdGhl
IE1JVE0KICBQcm90ZWN0aW9uIE5vdCBSZXF1aXJlZCBvcHRpb25zLCBhdXRoZW50aWNhdGlvbiBz
dGFnZSAxIHNoYWxsIGZ1bmN0aW9uIGFzIGlmIGJvdGggZGV2aWNlcwogIHNldCB0aGVpciBJTyBj
YXBhYmlsaXRpZXMgdG8gIERpc3BsYXlPbmx5IChlLmcuLCBOdW1lcmljIGNvbXBhcmlzb24gd2l0
aCBhdXRvbWF0aWMgY29uZmlybWF0aW9uIG9uIGJvdGggZGV2aWNlcykiCiAKIExvY2FsIGRldmlj
ZSBoYWQgc2V0IHRoZSAiTk8gTUlUTSBwcm90ZWN0aW9uIHJlcXVpcmVkIiBiYXNlZCBvbiB0aGUg
cmVtb3RlIGF1dGhlbnRpY2F0aW9uIGFuZCBjYXBhYmlsaXRpZXMuCiAgSXMgdGhlIGJlaGF2aW9y
IG9mIG92ZXItcmlkaW5nIGxvY2FsIGRldmljZSBNSVRNIGNhcGFiaWxpdHkgbmVjZXNzYXJ5PwoK
SW4gY2FzZSBvZiBsb2NhbCBkZXZpY2UgaW5pdGlhdGluZyBhIGNvbm5lY3Rpb24gdG8gdGhlIHJl
bW90ZSBkZXZpY2UsIGF1dG8gYWNjZXB0IGZyb20gdGhlIHN0YWNrIGlzIGFjY2VwdGFibGUKYnV0
IGluIGNhc2Ugb2YgcmVtb3RlIGluaXRpYXRlZCBjb25uZWN0aW9uLCBhdXRvLWFjY2VwdCB3aWxs
IGNhdXNlIHVzZXIgaW5jb252ZW5pZW5jZSwgSXNuJ3QgaXQ/CgpJIGhhdmUgdGVzdGVkIHRoZSBz
aW1pbGFyIHNjZW5hcmlvIHdpdGggdGhlIGRldmljZSBoYXZpbmcgYmx1ZWRyb2lkIHN0YWNrLCBo
ZXJlIHdlIGdldCBhIGF1dGhvcml6YXRpb24gcG9wdXAsCmFjdGlvbiBvbiB3aGljaCB3aWxsIGNv
bXBsZXRlIHRoZSBwYWlyaW5nIGFuZCBjb25uZWN0aW9uLiBpLmUgYXV0by1wYWlyaW5nIGlzIG5v
dCBkb25lIGluIHN0YWNrCgpNYXkgYmUgd2UgYWxsIGhhdmUgdGhlIGZvbGxvd2luZyBxdWVyeSwK
SG93IGRvZXMgcmVtb3RlLWRldmljZSBzZW50IHBhaXJpbmcgcmVxdWVzdCB0byBMb2NhbCBkZXZp
Y2UsIHdoZW4gaXQgZG9lc24ndCBoYXZlICJOb0lucHV0Tm9PdXRwdXQiIGNhcGFiaWxpdHk/CkFu
czogUmVtb3RlIGRldmljZSB3YXMgcGFpcmVkIGFuZCBjb25uZWN0ZWQgYnkgbG9jYWwgZGV2aWNl
IGZpcnN0IGFuZCB0aGVuIGRpc2Nvbm5lY3RlZCBhbmQgbGluayBrZXkgaXMgcmVtb3ZlZCBpbiB0
aGUgbG9jYWwgZGV2aWNlLgogICAgICAgIFdoZW4gcmVtb3RlIGRldmljZSBpcyByZXN0YXJ0ZWQs
IGl0IGlzIGF0dGVtcHRpbmcgdG8gY29ubmVjdCB0byB0aGUgbG9jYWwgZGV2aWNlLiBXaGVuIGxp
bmsta2V5IHZhbGlkYXRpb24gZmFpbGVkLCBpdCBhdHRlbXB0ZWQgcGFpcmluZwoKUmVtb3RlIGRl
dmljZSA6IEknbSB1c2luZyBNb3Rvcm9sYSBSb2Fkc3RlciAyCkxvY2FsIGRldmljZSA6IERVVCBy
dW5uaW5nIHdpdGggbGF0ZXN0IGJsdWV6IHN0YWNrCgoKSENJX0R1bXAgc25pcHBldCB3aGVuIHJl
bW90ZSBkZXZpY2UgaW5pdGlhdGVkIHRoZSBjb25uZWN0aW9uIHRvIGxvY2FsIGRldmljZShEVVQp
Cj4gSENJIEV2ZW50OiBMaW5rIEtleSBSZXF1ZXN0ICgweDE3KSBwbGVuIDYKICAgIGJkYWRkciAw
MDoyNDoxQzpENjo2RjoxQgo8IEhDSSBDb21tYW5kOiBMaW5rIEtleSBSZXF1ZXN0IE5lZ2F0aXZl
IFJlcGx5ICgweDAxfDB4MDAwYykgcGxlbiA2CiAgICBiZGFkZHIgMDA6MjQ6MUM6RDY6NkY6MUIK
PiBIQ0kgRXZlbnQ6IENvbW1hbmQgQ29tcGxldGUgKDB4MGUpIHBsZW4gMTAKICAgIExpbmsgS2V5
IFJlcXVlc3QgTmVnYXRpdmUgUmVwbHkgKDB4MDF8MHgwMDBjKSBuY21kIDEKICAgIHN0YXR1cyAw
eDAwIGJkYWRkciAwMDoyNDoxQzpENjo2RjoxQgo+IEhDSSBFdmVudDogSU8gQ2FwYWJpbGl0eSBS
ZXNwb25zZSAoMHgzMikgcGxlbiA5CiAgICBiZGFkZHIgMDA6MjQ6MUM6RDY6NkY6MUIgY2FwYWJp
bGl0eSAweDAzIG9vYiAweDAwIGF1dGggMHgwNAogICAgQ2FwYWJpbGl0eTogTm9JbnB1dE5vT3V0
cHV0IChPT0IgZGF0YSBub3QgcHJlc2VudCkKICAgIEF1dGhlbnRpY2F0aW9uOiBHZW5lcmFsIEJv
bmRpbmcgKE5vIE1JVE0gUHJvdGVjdGlvbikKPiBIQ0kgRXZlbnQ6IElPIENhcGFiaWxpdHkgUmVx
dWVzdCAoMHgzMSkgcGxlbiA2CiAgICBiZGFkZHIgMDA6MjQ6MUM6RDY6NkY6MUIKPCBIQ0kgQ29t
bWFuZDogSU8gQ2FwYWJpbGl0eSBSZXF1ZXN0IFJlcGx5ICgweDAxfDB4MDAyYikgcGxlbiA5CiAg
ICBiZGFkZHIgMDA6MjQ6MUM6RDY6NkY6MUIgY2FwYWJpbGl0eSAweDAxIG9vYiAweDAwIGF1dGgg
MHgwNAogICAgQ2FwYWJpbGl0eTogRGlzcGxheVllc05vIChPT0IgZGF0YSBub3QgcHJlc2VudCkK
ICAgIEF1dGhlbnRpY2F0aW9uOiBHZW5lcmFsIEJvbmRpbmcgKE5vIE1JVE0gUHJvdGVjdGlvbikK
PiBIQ0kgRXZlbnQ6IENvbW1hbmQgQ29tcGxldGUgKDB4MGUpIHBsZW4gMTAKICAgIElPIENhcGFi
aWxpdHkgUmVxdWVzdCBSZXBseSAoMHgwMXwweDAwMmIpIG5jbWQgMQogICAgc3RhdHVzIDB4MDAg
YmRhZGRyIDAwOjI0OjFDOkQ2OjZGOjFCCj4gSENJIEV2ZW50OiBVc2VyIENvbmZpcm1hdGlvbiBS
ZXF1ZXN0ICgweDMzKSBwbGVuIDEwCiAgICBiZGFkZHIgMDA6MjQ6MUM6RDY6NkY6MUIgcGFzc2tl
eSAyOTc1ODcKPCBIQ0kgQ29tbWFuZDogVXNlciBDb25maXJtYXRpb24gUmVxdWVzdCBSZXBseSAo
MHgwMXwweDAwMmMpIHBsZW4gNgogICAgYmRhZGRyIDAwOjI0OjFDOkQ2OjZGOjFCCj4gSENJIEV2
ZW50OiBDb21tYW5kIENvbXBsZXRlICgweDBlKSBwbGVuIDEwCiAgICBVc2VyIENvbmZpcm1hdGlv
biBSZXF1ZXN0IFJlcGx5ICgweDAxfDB4MDAyYykgbmNtZCAxCiAgICBzdGF0dXMgMHgwMCBiZGFk
ZHIgMDA6MjQ6MUM6RDY6NkY6MUIKPiBIQ0kgRXZlbnQ6IFNpbXBsZSBQYWlyaW5nIENvbXBsZXRl
ICgweDM2KSBwbGVuIDcKICAgIHN0YXR1cyAweDAwIGJkYWRkciAwMDoyNDoxQzpENjo2RjoxQgo+
IEhDSSBFdmVudDogTGluayBLZXkgTm90aWZpY2F0aW9uICgweDE4KSBwbGVuIDIzCiAgICBiZGFk
ZHIgMDA6MjQ6MUM6RDY6NkY6MUIga2V5IDFGOUE3RTk0MTFFNDM1RUE0REYwNUExMEU2REVFNDUx
IHR5cGUgNAogICAgVHlwZTogVW5hdXRoZW50aWNhdGVkIENvbWJpbmF0aW9uIEtleQoKCgpSZWdh
cmRzCk5hZ2FyYWogRCBS

Re: [Request] Clarification related to pairing in a particular scenario

[Luiz Augusto von Dentz]

Hi,

On Thu, Jul 9, 2015 at 9:46 AM, Nagaraj D R <nagaraj.dr@samsung.com> wrote:
> Hello all,
> could someone please clarify my doubt related to the concept of pairing in a particular scenario
>
> If a remote device having no I/O capability (also authentication : general bonding, and  No MITM protection)
> sent a pairing request to our local device(DUT running with the bluez stack), local device stack auto accept
> the pairing request even though local device has I/O capability
>
> Is the Behavior of auto-accepting the pairing request justified?
> -- According to the specification "From the Bluetooth Core Specification 4.1 page 1958:
>  "if both devices have set the Authentication_Requirements parameter to one of the MITM
>   Protection Not Required options, authentication stage 1 shall function as if both devices
>   set their IO capabilities to  DisplayOnly (e.g., Numeric comparison with automatic confirmation on both devices)"

There is a more precise answer to this in:

BLUETOOTH SPECIFICATION Version 4.2 [Vol 3, Part C]
page 323 Table 5.7: IO Capability Mapping to Authentication Stage 1

So if we rule No MITM shall be treated as DisplayOnly it would fall
into the very first case described in that table:

'Numeric Comparison with automatic confirmation on both devices'.

>  Local device had set the "NO MITM protection required" based on the remote authentication and capabilities.
>   Is the behavior of over-riding local device MITM capability necessary?
>
> In case of local device initiating a connection to the remote device, auto accept from the stack is acceptable
> but in case of remote initiated connection, auto-accept will cause user inconvenience, Isn't it?
>
> I have tested the similar scenario with the device having bluedroid stack, here we get a authorization popup,
> action on which will complete the pairing and connection. i.e auto-pairing is not done in stack

I guess it is because it does not take into account that No MITM shall
be treated as DisplayOnly.

> May be we all have the following query,
> How does remote-device sent pairing request to Local device, when it doesn't have "NoInputNoOutput" capability?
> Ans: Remote device was paired and connected by local device first and then disconnected and link key is removed in the local device.
>         When remote device is restarted, it is attempting to connect to the local device. When link-key validation failed, it attempted pairing

We I assume the default for Android in DisplayYesNo, so I have no idea
how it end up with NoInputNoOutput, also this could downgrade the
previous link key from authenticated to unauthenticated which I don't
think is secure, in short I think there is a bug in Android and it
shall never send NoInputNoOutput. In fact I experience something
different recently, Android would sent No Bonding flag when
reconnecting but with MITM, but this was with 4.4 not 5.0.

> Remote device : I'm using Motorola Roadster 2
> Local device : DUT running with latest bluez stack
>
>
> HCI_Dump snippet when remote device initiated the connection to local device(DUT)
>> HCI Event: Link Key Request (0x17) plen 6
>     bdaddr 00:24:1C:D6:6F:1B
> < HCI Command: Link Key Request Negative Reply (0x01|0x000c) plen 6
>     bdaddr 00:24:1C:D6:6F:1B
>> HCI Event: Command Complete (0x0e) plen 10
>     Link Key Request Negative Reply (0x01|0x000c) ncmd 1
>     status 0x00 bdaddr 00:24:1C:D6:6F:1B
>> HCI Event: IO Capability Response (0x32) plen 9
>     bdaddr 00:24:1C:D6:6F:1B capability 0x03 oob 0x00 auth 0x04
>     Capability: NoInputNoOutput (OOB data not present)
>     Authentication: General Bonding (No MITM Protection)
>> HCI Event: IO Capability Request (0x31) plen 6
>     bdaddr 00:24:1C:D6:6F:1B
> < HCI Command: IO Capability Request Reply (0x01|0x002b) plen 9
>     bdaddr 00:24:1C:D6:6F:1B capability 0x01 oob 0x00 auth 0x04
>     Capability: DisplayYesNo (OOB data not present)
>     Authentication: General Bonding (No MITM Protection)
>> HCI Event: Command Complete (0x0e) plen 10
>     IO Capability Request Reply (0x01|0x002b) ncmd 1
>     status 0x00 bdaddr 00:24:1C:D6:6F:1B
>> HCI Event: User Confirmation Request (0x33) plen 10
>     bdaddr 00:24:1C:D6:6F:1B passkey 297587
> < HCI Command: User Confirmation Request Reply (0x01|0x002c) plen 6
>     bdaddr 00:24:1C:D6:6F:1B
>> HCI Event: Command Complete (0x0e) plen 10
>     User Confirmation Request Reply (0x01|0x002c) ncmd 1
>     status 0x00 bdaddr 00:24:1C:D6:6F:1B
>> HCI Event: Simple Pairing Complete (0x36) plen 7
>     status 0x00 bdaddr 00:24:1C:D6:6F:1B
>> HCI Event: Link Key Notification (0x18) plen 23
>     bdaddr 00:24:1C:D6:6F:1B key 1F9A7E9411E435EA4DF05A10E6DEE451 type 4
>     Type: Unauthenticated Combination Key
>
>
>
> Regards
> Nagaraj D R



-- 
Luiz Augusto von Dentz