PTS / linkkey issue

PTS / linkkey issue

[Mike]

Hi,

I'm having a somewhat relate issue to Vishal AGARWAL [1].  The trouble
I have is that the PTS system is requesting auth type 0, and Bluez
happily obliges.  This leaves the PTS device as temporary, and BlueZ
then deletes this device after the end of the connection.  This
prevents me from being able to pass TP/OOR/BV-02-I: [HF reconnects to
AG].  The code is designed to periodically reconnect to the AG after
it detects a link timeout.  But, if BlueZ has deleted the device, I
don't do that.  This also somewhat applies to the A2DP test cases, as
my device must be left in pairing mode in order for the tests to pass.

So, my question to people who have used PTS, is there a way to get the
PTS to perform a pairing that is not 0x00 MITM Protection Not Required
– No Bonding. Numeric comparison with automatic accept allowed?  I'm
using an older kernel that doesn't have the mgmt interface (2.6.33
with some features/fixes backported from newer kernels) but am using
the latest BlueZ from git (at least of a month ago or so).  But even
so, the proposal of keeping the linkkey around for the ACL session
would be useless, I think, because the intent is to have a link
timeout event.

Thanks,
Mike

[1] http://www.spinics.net/lists/linux-bluetooth/msg23346.html

RE: PTS / linkkey issue

[Tom Allebrandi]

Hi Mike -

PTS may be requesting "no man in the middle protection" but what is your
system (BlueZ) requesting? If your system is also requesting no MITM then
that would explain what you are seeing.

If your system is requesting "man in the middle protection", then I think
that is what gets used resulting in an authenticated link key. Do you have
an HCIdump or PTSPV trace around so we can see what your device is asking
for.

At least that's the way I read the core spec. I could be wrong, that area is
a little confusing :-).

--- tom
tom allebrandi
wyrles@ytram.com

> -----Original Message-----
> From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-
> owner@vger.kernel.org] On Behalf Of Mike
> Sent: Friday, April 20, 2012 3:40 PM
> To: linux-bluetooth
> Subject: PTS / linkkey issue
> 
> Hi,
> 
> I'm having a somewhat relate issue to Vishal AGARWAL [1].  The trouble I
> have is that the PTS system is requesting auth type 0, and Bluez happily
> obliges.  This leaves the PTS device as temporary, and BlueZ then deletes
this
> device after the end of the connection.  This prevents me from being able
to
> pass TP/OOR/BV-02-I: [HF reconnects to AG].  The code is designed to
> periodically reconnect to the AG after it detects a link timeout.  But, if
BlueZ
> has deleted the device, I don't do that.  This also somewhat applies to
the
> A2DP test cases, as my device must be left in pairing mode in order for
the
> tests to pass.
> 
> So, my question to people who have used PTS, is there a way to get the PTS
> to perform a pairing that is not 0x00 MITM Protection Not Required - No
> Bonding. Numeric comparison with automatic accept allowed?  I'm using an
> older kernel that doesn't have the mgmt interface (2.6.33 with some
> features/fixes backported from newer kernels) but am using the latest
BlueZ
> from git (at least of a month ago or so).  But even so, the proposal of
keeping
> the linkkey around for the ACL session would be useless, I think, because
the
> intent is to have a link timeout event.
> 
> Thanks,
> Mike
> 
> [1] http://www.spinics.net/lists/linux-bluetooth/msg23346.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth"
in
> the body of a message to majordomo@vger.kernel.org More majordomo
> info at  http://vger.kernel.org/majordomo-info.html

Re: PTS / linkkey issue

[Mike]

Hi Tom,

On Fri, Apr 20, 2012 at 7:28 PM, Tom Allebrandi <wyrles@ytram.com> wrote:
> Hi Mike -
>
>> -----Original Message-----
>> From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-
>> owner@vger.kernel.org] On Behalf Of Mike
>> Sent: Friday, April 20, 2012 3:40 PM
>> To: linux-bluetooth
>> Subject: PTS / linkkey issue
>>
>> Hi,
>>
>> I'm having a somewhat relate issue to Vishal AGARWAL [1].  The trouble I
>> have is that the PTS system is requesting auth type 0, and Bluez happily
>> obliges.  This leaves the PTS device as temporary, and BlueZ then deletes
> this
>> device after the end of the connection.  This prevents me from being able
> to
>> pass TP/OOR/BV-02-I: [HF reconnects to AG].  The code is designed to
>> periodically reconnect to the AG after it detects a link timeout.  But, if
> BlueZ
>> has deleted the device, I don't do that.  This also somewhat applies to
> the
>> A2DP test cases, as my device must be left in pairing mode in order for
> the
>> tests to pass.
>>
>> So, my question to people who have used PTS, is there a way to get the PTS
>> to perform a pairing that is not 0x00 MITM Protection Not Required - No
>> Bonding. Numeric comparison with automatic accept allowed?  I'm using an
>> older kernel that doesn't have the mgmt interface (2.6.33 with some
>> features/fixes backported from newer kernels) but am using the latest
> BlueZ
>> from git (at least of a month ago or so).  But even so, the proposal of
> keeping
>> the linkkey around for the ACL session would be useless, I think, because
> the
>> intent is to have a link timeout event.
>>
>> Thanks,
>> Mike
>>
>> [1] http://www.spinics.net/lists/linux-bluetooth/msg23346.html
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth"
> in
>> the body of a message to majordomo@vger.kernel.org More majordomo
>> info at  http://vger.kernel.org/majordomo-info.html
>
> PTS may be requesting "no man in the middle protection" but what is your
> system (BlueZ) requesting? If your system is also requesting no MITM then
> that would explain what you are seeing.
>
> If your system is requesting "man in the middle protection", then I think
> that is what gets used resulting in an authenticated link key. Do you have
> an HCIdump or PTSPV trace around so we can see what your device is asking
> for.
>
> At least that's the way I read the core spec. I could be wrong, that area is
> a little confusing :-).
>
> --- tom
> tom allebrandi
> wyrles@ytram.com
>

There's not much to the trace.  The PTS' response to the HCI IO
Capability request event gives a 0x00.  The default in the BlueZ code
is 0x04, but it appears it gives that up and takes the 0x00.  In
pairing with an iPhone, I see BlueZ respond with a 0x04 code, and
eventually both sides have indicated 0x04.

The bluetoothd log with PTS containted:

bluetoothd[501]: plugins/hciops.c:link_key_notify() key type 0x04 old
key type 0x04
bluetoothd[501]: plugins/hciops.c:link_key_notify() local auth 0x00
and remote auth 0x00

Thanks,
Mike

Re: PTS / linkkey issue

[Mike]

On Fri, Apr 20, 2012 at 7:45 PM, Mike <puffy.taco@gmail.com> wrote:
> Hi Tom,
>
> On Fri, Apr 20, 2012 at 7:28 PM, Tom Allebrandi <wyrles@ytram.com> wrote:
>> Hi Mike -
>>
>>> -----Original Message-----
>>> From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-
>>> owner@vger.kernel.org] On Behalf Of Mike
>>> Sent: Friday, April 20, 2012 3:40 PM
>>> To: linux-bluetooth
>>> Subject: PTS / linkkey issue
>>>
>>> Hi,
>>>
>>> I'm having a somewhat relate issue to Vishal AGARWAL [1].  The trouble I
>>> have is that the PTS system is requesting auth type 0, and Bluez happily
>>> obliges.  This leaves the PTS device as temporary, and BlueZ then deletes
>> this
>>> device after the end of the connection.  This prevents me from being able
>> to
>>> pass TP/OOR/BV-02-I: [HF reconnects to AG].  The code is designed to
>>> periodically reconnect to the AG after it detects a link timeout.  But, if
>> BlueZ
>>> has deleted the device, I don't do that.  This also somewhat applies to
>> the
>>> A2DP test cases, as my device must be left in pairing mode in order for
>> the
>>> tests to pass.
>>>
>>> So, my question to people who have used PTS, is there a way to get the PTS
>>> to perform a pairing that is not 0x00 MITM Protection Not Required - No
>>> Bonding. Numeric comparison with automatic accept allowed?  I'm using an
>>> older kernel that doesn't have the mgmt interface (2.6.33 with some
>>> features/fixes backported from newer kernels) but am using the latest
>> BlueZ
>>> from git (at least of a month ago or so).  But even so, the proposal of
>> keeping
>>> the linkkey around for the ACL session would be useless, I think, because
>> the
>>> intent is to have a link timeout event.
>>>
>>> Thanks,
>>> Mike
>>>
>>> [1] http://www.spinics.net/lists/linux-bluetooth/msg23346.html
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth"
>> in
>>> the body of a message to majordomo@vger.kernel.org More majordomo
>>> info at  http://vger.kernel.org/majordomo-info.html
>>
>> PTS may be requesting "no man in the middle protection" but what is your
>> system (BlueZ) requesting? If your system is also requesting no MITM then
>> that would explain what you are seeing.
>>
>> If your system is requesting "man in the middle protection", then I think
>> that is what gets used resulting in an authenticated link key. Do you have
>> an HCIdump or PTSPV trace around so we can see what your device is asking
>> for.
>>
>> At least that's the way I read the core spec. I could be wrong, that area is
>> a little confusing :-).
>>
>> --- tom
>> tom allebrandi
>> wyrles@ytram.com
>>
>
> There's not much to the trace.  The PTS' response to the HCI IO
> Capability request event gives a 0x00.  The default in the BlueZ code
> is 0x04, but it appears it gives that up and takes the 0x00.  In
> pairing with an iPhone, I see BlueZ respond with a 0x04 code, and
> eventually both sides have indicated 0x04.
>
> The bluetoothd log with PTS containted:
>
> bluetoothd[501]: plugins/hciops.c:link_key_notify() key type 0x04 old
> key type 0x04
> bluetoothd[501]: plugins/hciops.c:link_key_notify() local auth 0x00
> and remote auth 0x00
>
> Thanks,
> Mike

I see that there are at least two open issues filed against PTS on this:

https://www.bluetooth.org/pts/issues/view_issue.cfm?id=6925
https://www.bluetooth.org/pts/issues/view_issue.cfm?id=6942

These have been open for almost 2 years!  Tom, is this something that
is actively being worked on by the Bluetooth SIG?  I see it was
assigned to you at one point.  Does BlueZ have something wrong?  It
seems like an option to select General Bonding would fix things for a
bunch of people!

Thanks,
Mike

Re: PTS / linkkey issue

[Marcel Holtmann]

Hi Mike,

> I'm having a somewhat relate issue to Vishal AGARWAL [1].  The trouble
> I have is that the PTS system is requesting auth type 0, and Bluez
> happily obliges.  This leaves the PTS device as temporary, and BlueZ
> then deletes this device after the end of the connection.  This
> prevents me from being able to pass TP/OOR/BV-02-I: [HF reconnects to
> AG].  The code is designed to periodically reconnect to the AG after
> it detects a link timeout.  But, if BlueZ has deleted the device, I
> don't do that.  This also somewhat applies to the A2DP test cases, as
> my device must be left in pairing mode in order for the tests to pass.
> 
> So, my question to people who have used PTS, is there a way to get the
> PTS to perform a pairing that is not 0x00 MITM Protection Not Required
> – No Bonding. Numeric comparison with automatic accept allowed?  I'm
> using an older kernel that doesn't have the mgmt interface (2.6.33
> with some features/fixes backported from newer kernels) but am using
> the latest BlueZ from git (at least of a month ago or so).  But even
> so, the proposal of keeping the linkkey around for the ACL session
> would be useless, I think, because the intent is to have a link
> timeout event.

can you quickly check if for some weird reason the PTS uses debug keys
or if you enabled debug keys within BlueZ.

We treat debug keys even worse than no bonding. Unless you set DebugKeys
in /etc/bluetooth/main.conf they are thrown out right away. However be
really careful here. That option is only for debugging. You should never
ever leave that on in a production device. You would make your device
vulnerable like no tomorrow.

Regards

Marcel

Re: PTS / linkkey issue

[Mike]

Hi Marcel,

On Sat, Apr 21, 2012 at 5:35 AM, Marcel Holtmann <marcel@holtmann.org> wrot=
e:
> Hi Mike,
>
>> I'm having a somewhat relate issue to Vishal AGARWAL [1]. =A0The trouble
>> I have is that the PTS system is requesting auth type 0, and Bluez
>> happily obliges. =A0This leaves the PTS device as temporary, and BlueZ
>> then deletes this device after the end of the connection. =A0This
>> prevents me from being able to pass TP/OOR/BV-02-I: [HF reconnects to
>> AG]. =A0The code is designed to periodically reconnect to the AG after
>> it detects a link timeout. =A0But, if BlueZ has deleted the device, I
>> don't do that. =A0This also somewhat applies to the A2DP test cases, as
>> my device must be left in pairing mode in order for the tests to pass.
>>
>> So, my question to people who have used PTS, is there a way to get the
>> PTS to perform a pairing that is not 0x00 MITM Protection Not Required
>> =96 No Bonding. Numeric comparison with automatic accept allowed? =A0I'm
>> using an older kernel that doesn't have the mgmt interface (2.6.33
>> with some features/fixes backported from newer kernels) but am using
>> the latest BlueZ from git (at least of a month ago or so). =A0But even
>> so, the proposal of keeping the linkkey around for the ACL session
>> would be useless, I think, because the intent is to have a link
>> timeout event.
>
> can you quickly check if for some weird reason the PTS uses debug keys
> or if you enabled debug keys within BlueZ.
>
> We treat debug keys even worse than no bonding. Unless you set DebugKeys
> in /etc/bluetooth/main.conf they are thrown out right away. However be
> really careful here. That option is only for debugging. You should never
> ever leave that on in a production device. You would make your device
> vulnerable like no tomorrow.
>
> Regards
>
> Marcel
>
>

I checked hci dumps of both the init of my unit and the trace from the
PTS run, and neither had sent the HCI_Write_Simple_Pairing_Debug_mode
command.  Plus we can see that the key type is 0x04, Unauthenticated
Combination Key.  I also verified that DebugKeys was false in
main.conf.

Thanks,
Mike

Re: PTS / linkkey issue

[Marcel Holtmann]

Hi Mike,

> >> I'm having a somewhat relate issue to Vishal AGARWAL [1].  The trouble
> >> I have is that the PTS system is requesting auth type 0, and Bluez
> >> happily obliges.  This leaves the PTS device as temporary, and BlueZ
> >> then deletes this device after the end of the connection.  This
> >> prevents me from being able to pass TP/OOR/BV-02-I: [HF reconnects to
> >> AG].  The code is designed to periodically reconnect to the AG after
> >> it detects a link timeout.  But, if BlueZ has deleted the device, I
> >> don't do that.  This also somewhat applies to the A2DP test cases, as
> >> my device must be left in pairing mode in order for the tests to pass.
> >>
> >> So, my question to people who have used PTS, is there a way to get the
> >> PTS to perform a pairing that is not 0x00 MITM Protection Not Required
> >> – No Bonding. Numeric comparison with automatic accept allowed?  I'm
> >> using an older kernel that doesn't have the mgmt interface (2.6.33
> >> with some features/fixes backported from newer kernels) but am using
> >> the latest BlueZ from git (at least of a month ago or so).  But even
> >> so, the proposal of keeping the linkkey around for the ACL session
> >> would be useless, I think, because the intent is to have a link
> >> timeout event.
> >
> > can you quickly check if for some weird reason the PTS uses debug keys
> > or if you enabled debug keys within BlueZ.
> >
> > We treat debug keys even worse than no bonding. Unless you set DebugKeys
> > in /etc/bluetooth/main.conf they are thrown out right away. However be
> > really careful here. That option is only for debugging. You should never
> > ever leave that on in a production device. You would make your device
> > vulnerable like no tomorrow.
>
> I checked hci dumps of both the init of my unit and the trace from the
> PTS run, and neither had sent the HCI_Write_Simple_Pairing_Debug_mode
> command.  Plus we can see that the key type is 0x04, Unauthenticated
> Combination Key.  I also verified that DebugKeys was false in
> main.conf.

please post the actual pairing exchange here, but this seems like the
PTS is fundamentally broken. If we pair with no bonding, we do throw the
link key away and that is suppose to be done this way.

Is there any chance to do a dedicated or general bonding with the PTS to
keep the link key around? Like you would actually be doing when using
any HFP device.

Regards

Marcel

Re: PTS / linkkey issue

[Mike]

[-- Attachment #1: Type: text/plain, Size: 4433 bytes --]

Hi Marcel,

>> >> I'm having a somewhat relate issue to Vishal AGARWAL [1].  The trouble
>> >> I have is that the PTS system is requesting auth type 0, and Bluez
>> >> happily obliges.  This leaves the PTS device as temporary, and BlueZ
>> >> then deletes this device after the end of the connection.  This
>> >> prevents me from being able to pass TP/OOR/BV-02-I: [HF reconnects to
>> >> AG].  The code is designed to periodically reconnect to the AG after
>> >> it detects a link timeout.  But, if BlueZ has deleted the device, I
>> >> don't do that.  This also somewhat applies to the A2DP test cases, as
>> >> my device must be left in pairing mode in order for the tests to pass.
>> >>
>> >> So, my question to people who have used PTS, is there a way to get the
>> >> PTS to perform a pairing that is not 0x00 MITM Protection Not Required
>> >> – No Bonding. Numeric comparison with automatic accept allowed?  I'm
>> >> using an older kernel that doesn't have the mgmt interface (2.6.33
>> >> with some features/fixes backported from newer kernels) but am using
>> >> the latest BlueZ from git (at least of a month ago or so).  But even
>> >> so, the proposal of keeping the linkkey around for the ACL session
>> >> would be useless, I think, because the intent is to have a link
>> >> timeout event.
>> >
>> > can you quickly check if for some weird reason the PTS uses debug keys
>> > or if you enabled debug keys within BlueZ.
>> >
>> > We treat debug keys even worse than no bonding. Unless you set DebugKeys
>> > in /etc/bluetooth/main.conf they are thrown out right away. However be
>> > really careful here. That option is only for debugging. You should never
>> > ever leave that on in a production device. You would make your device
>> > vulnerable like no tomorrow.
>>
>> I checked hci dumps of both the init of my unit and the trace from the
>> PTS run, and neither had sent the HCI_Write_Simple_Pairing_Debug_mode
>> command.  Plus we can see that the key type is 0x04, Unauthenticated
>> Combination Key.  I also verified that DebugKeys was false in
>> main.conf.
>
> please post the actual pairing exchange here, but this seems like the
> PTS is fundamentally broken. If we pair with no bonding, we do throw the
> link key away and that is suppose to be done this way.

I have attached the trace both in Frontline ComProbe capture format
and as an export to a somewhat readable html format.  The trace was
taken on the PTS machine (so host=PTS machine).  Note that it is not a
trace from the particular test I mentioned above, but every test has
the same pairing experience.

I think what you're after is this section:

Frame 65: (Controller) Len=8
HCI
Packet from: Controller
HCI Event
Event: HCI IO Capability Request
Total Length: 6
BD_ADDR: 0x649c8ec1bce3

Frame 66: (Host) Len=12
HCI
Packet from: Host
HCI Command
Opcode: 0x042b
Group: Link Control
Command: HCI_IO_Capability_Response
Total Length: 9
Bluetooth Device Address: 0x64-9c-8e-c1-bc-e3
LAP: 0xc1-bc-e3
UAP: 0x8e
NAP: 0x64-9c
IO Capability: DisplayYesNo
OOB Data Present: OOB authentication data not present
Authentication_Requirements: MITM Protection Not Required - No
Bonding. Numeric comparision with automatic accept allowed

Frame 67: (Controller) Len=12
HCI
Packet from: Controller
HCI Event
Event: Command Complete
Total Length: 10
Number HCI Command Packets: 1
HCI Command
Opcode: 0x042b
Group: Link Control
Command: HCI_IO_Capability_Response
Return Parameters
Status: Success
Bluetooth Device Address: 0x64-9c-8e-c1-bc-e3
LAP: 0xc1-bc-e3
UAP: 0x8e
NAP: 0x64-9c

Frame 68: (Controller) Len=11
HCI
Packet from: Controller
HCI Event
Event: HCI IO Capability Response
Total Length: 9
BD_ADDR: 0x649c8ec1bce3
IO Capability: NoInputNoOutput
OOB Data Present: OOB authentication data not present
Authentication_Requirements: MITM Protection Not Required - No
Bonding. Numeric comparision with automatic accept allowed

> Is there any chance to do a dedicated or general bonding with the PTS to
> keep the link key around? Like you would actually be doing when using
> any HFP device.

It appears, based on the issues filed against PTS, that the PTS
doesn't have this option.  Right now, my device, which acts as HFP HF,
does not initiate pairing through any UI and requires the HFP AG to
make the first connection.

Thanks,
Mike

[-- Attachment #2: trace.zip --]
[-- Type: application/zip, Size: 39518 bytes --]

Re: PTS / linkkey issue

[Marcel Holtmann]

Hi Mike,

> >> >> I'm having a somewhat relate issue to Vishal AGARWAL [1].  The trouble
> >> >> I have is that the PTS system is requesting auth type 0, and Bluez
> >> >> happily obliges.  This leaves the PTS device as temporary, and BlueZ
> >> >> then deletes this device after the end of the connection.  This
> >> >> prevents me from being able to pass TP/OOR/BV-02-I: [HF reconnects to
> >> >> AG].  The code is designed to periodically reconnect to the AG after
> >> >> it detects a link timeout.  But, if BlueZ has deleted the device, I
> >> >> don't do that.  This also somewhat applies to the A2DP test cases, as
> >> >> my device must be left in pairing mode in order for the tests to pass.
> >> >>
> >> >> So, my question to people who have used PTS, is there a way to get the
> >> >> PTS to perform a pairing that is not 0x00 MITM Protection Not Required
> >> >> – No Bonding. Numeric comparison with automatic accept allowed?  I'm
> >> >> using an older kernel that doesn't have the mgmt interface (2.6.33
> >> >> with some features/fixes backported from newer kernels) but am using
> >> >> the latest BlueZ from git (at least of a month ago or so).  But even
> >> >> so, the proposal of keeping the linkkey around for the ACL session
> >> >> would be useless, I think, because the intent is to have a link
> >> >> timeout event.
> >> >
> >> > can you quickly check if for some weird reason the PTS uses debug keys
> >> > or if you enabled debug keys within BlueZ.
> >> >
> >> > We treat debug keys even worse than no bonding. Unless you set DebugKeys
> >> > in /etc/bluetooth/main.conf they are thrown out right away. However be
> >> > really careful here. That option is only for debugging. You should never
> >> > ever leave that on in a production device. You would make your device
> >> > vulnerable like no tomorrow.
> >>
> >> I checked hci dumps of both the init of my unit and the trace from the
> >> PTS run, and neither had sent the HCI_Write_Simple_Pairing_Debug_mode
> >> command.  Plus we can see that the key type is 0x04, Unauthenticated
> >> Combination Key.  I also verified that DebugKeys was false in
> >> main.conf.
> >
> > please post the actual pairing exchange here, but this seems like the
> > PTS is fundamentally broken. If we pair with no bonding, we do throw the
> > link key away and that is suppose to be done this way.
> 
> I have attached the trace both in Frontline ComProbe capture format
> and as an export to a somewhat readable html format.  The trace was
> taken on the PTS machine (so host=PTS machine).  Note that it is not a
> trace from the particular test I mentioned above, but every test has
> the same pairing experience.
> 
> I think what you're after is this section:
> 
> Frame 65: (Controller) Len=8
> HCI
> Packet from: Controller
> HCI Event
> Event: HCI IO Capability Request
> Total Length: 6
> BD_ADDR: 0x649c8ec1bce3
> 
> Frame 66: (Host) Len=12
> HCI
> Packet from: Host
> HCI Command
> Opcode: 0x042b
> Group: Link Control
> Command: HCI_IO_Capability_Response
> Total Length: 9
> Bluetooth Device Address: 0x64-9c-8e-c1-bc-e3
> LAP: 0xc1-bc-e3
> UAP: 0x8e
> NAP: 0x64-9c
> IO Capability: DisplayYesNo
> OOB Data Present: OOB authentication data not present
> Authentication_Requirements: MITM Protection Not Required - No
> Bonding. Numeric comparision with automatic accept allowed
> 
> Frame 67: (Controller) Len=12
> HCI
> Packet from: Controller
> HCI Event
> Event: Command Complete
> Total Length: 10
> Number HCI Command Packets: 1
> HCI Command
> Opcode: 0x042b
> Group: Link Control
> Command: HCI_IO_Capability_Response
> Return Parameters
> Status: Success
> Bluetooth Device Address: 0x64-9c-8e-c1-bc-e3
> LAP: 0xc1-bc-e3
> UAP: 0x8e
> NAP: 0x64-9c
> 
> Frame 68: (Controller) Len=11
> HCI
> Packet from: Controller
> HCI Event
> Event: HCI IO Capability Response
> Total Length: 9
> BD_ADDR: 0x649c8ec1bce3
> IO Capability: NoInputNoOutput
> OOB Data Present: OOB authentication data not present
> Authentication_Requirements: MITM Protection Not Required - No
> Bonding. Numeric comparision with automatic accept allowed
> 
> > Is there any chance to do a dedicated or general bonding with the PTS to
> > keep the link key around? Like you would actually be doing when using
> > any HFP device.
> 
> It appears, based on the issues filed against PTS, that the PTS
> doesn't have this option.  Right now, my device, which acts as HFP HF,
> does not initiate pairing through any UI and requires the HFP AG to
> make the first connection.

and if you are the HF role, then this is perfectly acceptable. The other
side should pair with you. And they need to use dedicated bonding to do
so. The no bonding pairing is utterly useless.

Going through the log, it it seems that the PTS initiates the connection
and then tries to pair. Since it has no link key for the other side, it
should realize that it has to run dedicated bonding first. Doing this
with no bonding is just wrong.

Any chance to run this PTS case against an actual Bluetooth headset and
see what it does in this area. We can not store the link key if it has
been requested with no bonding. The only thing I can think of right now
is that when the RFCOMM channel is requested we force an upgrade of the
link key to general bonding.

This essentially means pairing twice and that is still stupid, but might
be what we should be doing. Or at least provide another hint to the
L2CAP and RFCOMM channel's security to what we expect before allowing
any connection. This is far fetching and utterly pointless if it would
make break the GAP qualification.

So I am curious to see a trace from a headset and a standard headset
handles this. Or if they all just ignore the no bonding part.

Johan, have a look at this. You looked this stuff more recently than I
did.

Regards

Marcel

Re: PTS / linkkey issue

[Mike]

[-- Attachment #1: Type: text/plain, Size: 6647 bytes --]

Hi Marcel,

>> >> >> I'm having a somewhat relate issue to Vishal AGARWAL [1].  The trouble
>> >> >> I have is that the PTS system is requesting auth type 0, and Bluez
>> >> >> happily obliges.  This leaves the PTS device as temporary, and BlueZ
>> >> >> then deletes this device after the end of the connection.  This
>> >> >> prevents me from being able to pass TP/OOR/BV-02-I: [HF reconnects to
>> >> >> AG].  The code is designed to periodically reconnect to the AG after
>> >> >> it detects a link timeout.  But, if BlueZ has deleted the device, I
>> >> >> don't do that.  This also somewhat applies to the A2DP test cases, as
>> >> >> my device must be left in pairing mode in order for the tests to pass.
>> >> >>
>> >> >> So, my question to people who have used PTS, is there a way to get the
>> >> >> PTS to perform a pairing that is not 0x00 MITM Protection Not Required
>> >> >> – No Bonding. Numeric comparison with automatic accept allowed?  I'm
>> >> >> using an older kernel that doesn't have the mgmt interface (2.6.33
>> >> >> with some features/fixes backported from newer kernels) but am using
>> >> >> the latest BlueZ from git (at least of a month ago or so).  But even
>> >> >> so, the proposal of keeping the linkkey around for the ACL session
>> >> >> would be useless, I think, because the intent is to have a link
>> >> >> timeout event.
>> >> >
>> >> > can you quickly check if for some weird reason the PTS uses debug keys
>> >> > or if you enabled debug keys within BlueZ.
>> >> >
>> >> > We treat debug keys even worse than no bonding. Unless you set DebugKeys
>> >> > in /etc/bluetooth/main.conf they are thrown out right away. However be
>> >> > really careful here. That option is only for debugging. You should never
>> >> > ever leave that on in a production device. You would make your device
>> >> > vulnerable like no tomorrow.
>> >>
>> >> I checked hci dumps of both the init of my unit and the trace from the
>> >> PTS run, and neither had sent the HCI_Write_Simple_Pairing_Debug_mode
>> >> command.  Plus we can see that the key type is 0x04, Unauthenticated
>> >> Combination Key.  I also verified that DebugKeys was false in
>> >> main.conf.
>> >
>> > please post the actual pairing exchange here, but this seems like the
>> > PTS is fundamentally broken. If we pair with no bonding, we do throw the
>> > link key away and that is suppose to be done this way.
>>
>> I have attached the trace both in Frontline ComProbe capture format
>> and as an export to a somewhat readable html format.  The trace was
>> taken on the PTS machine (so host=PTS machine).  Note that it is not a
>> trace from the particular test I mentioned above, but every test has
>> the same pairing experience.
>>
>> I think what you're after is this section:
>>
>> Frame 65: (Controller) Len=8
>> HCI
>> Packet from: Controller
>> HCI Event
>> Event: HCI IO Capability Request
>> Total Length: 6
>> BD_ADDR: 0x649c8ec1bce3
>>
>> Frame 66: (Host) Len=12
>> HCI
>> Packet from: Host
>> HCI Command
>> Opcode: 0x042b
>> Group: Link Control
>> Command: HCI_IO_Capability_Response
>> Total Length: 9
>> Bluetooth Device Address: 0x64-9c-8e-c1-bc-e3
>> LAP: 0xc1-bc-e3
>> UAP: 0x8e
>> NAP: 0x64-9c
>> IO Capability: DisplayYesNo
>> OOB Data Present: OOB authentication data not present
>> Authentication_Requirements: MITM Protection Not Required - No
>> Bonding. Numeric comparision with automatic accept allowed
>>
>> Frame 67: (Controller) Len=12
>> HCI
>> Packet from: Controller
>> HCI Event
>> Event: Command Complete
>> Total Length: 10
>> Number HCI Command Packets: 1
>> HCI Command
>> Opcode: 0x042b
>> Group: Link Control
>> Command: HCI_IO_Capability_Response
>> Return Parameters
>> Status: Success
>> Bluetooth Device Address: 0x64-9c-8e-c1-bc-e3
>> LAP: 0xc1-bc-e3
>> UAP: 0x8e
>> NAP: 0x64-9c
>>
>> Frame 68: (Controller) Len=11
>> HCI
>> Packet from: Controller
>> HCI Event
>> Event: HCI IO Capability Response
>> Total Length: 9
>> BD_ADDR: 0x649c8ec1bce3
>> IO Capability: NoInputNoOutput
>> OOB Data Present: OOB authentication data not present
>> Authentication_Requirements: MITM Protection Not Required - No
>> Bonding. Numeric comparision with automatic accept allowed
>>
>> > Is there any chance to do a dedicated or general bonding with the PTS to
>> > keep the link key around? Like you would actually be doing when using
>> > any HFP device.
>>
>> It appears, based on the issues filed against PTS, that the PTS
>> doesn't have this option.  Right now, my device, which acts as HFP HF,
>> does not initiate pairing through any UI and requires the HFP AG to
>> make the first connection.
>
> and if you are the HF role, then this is perfectly acceptable. The other
> side should pair with you. And they need to use dedicated bonding to do
> so. The no bonding pairing is utterly useless.
>
> Going through the log, it it seems that the PTS initiates the connection
> and then tries to pair. Since it has no link key for the other side, it
> should realize that it has to run dedicated bonding first. Doing this
> with no bonding is just wrong.
>
> Any chance to run this PTS case against an actual Bluetooth headset and
> see what it does in this area. We can not store the link key if it has
> been requested with no bonding. The only thing I can think of right now
> is that when the RFCOMM channel is requested we force an upgrade of the
> link key to general bonding.

Attached a trace against a BT headset.  It looks pretty much the same,
except that the BT headset does keep the link key around in the no
bonding case, so future PTS runs work without have to do a new
pairing.

It's not just HFP that's affected.  The same type of problem exists
with A2DP where we're forced to leave the Pairable Bluez adapter
property True for every PTS connection attempt.  We normally set
Discoverable and Pairable at the same time.  So even if the RFCOMM
case caused extra actions, it hardly fixes it.

> This essentially means pairing twice and that is still stupid, but might
> be what we should be doing. Or at least provide another hint to the
> L2CAP and RFCOMM channel's security to what we expect before allowing
> any connection. This is far fetching and utterly pointless if it would
> make break the GAP qualification.
>
> So I am curious to see a trace from a headset and a standard headset
> handles this. Or if they all just ignore the no bonding part.
>
> Johan, have a look at this. You looked this stuff more recently than I
> did.

Thanks,
Mike

[-- Attachment #2: btheadset.zip --]
[-- Type: application/zip, Size: 16064 bytes --]

Re: PTS / linkkey issue

[Marcel Holtmann]

Hi Mike,

> >> >> >> I'm having a somewhat relate issue to Vishal AGARWAL [1].  The trouble
> >> >> >> I have is that the PTS system is requesting auth type 0, and Bluez
> >> >> >> happily obliges.  This leaves the PTS device as temporary, and BlueZ
> >> >> >> then deletes this device after the end of the connection.  This
> >> >> >> prevents me from being able to pass TP/OOR/BV-02-I: [HF reconnects to
> >> >> >> AG].  The code is designed to periodically reconnect to the AG after
> >> >> >> it detects a link timeout.  But, if BlueZ has deleted the device, I
> >> >> >> don't do that.  This also somewhat applies to the A2DP test cases, as
> >> >> >> my device must be left in pairing mode in order for the tests to pass.
> >> >> >>
> >> >> >> So, my question to people who have used PTS, is there a way to get the
> >> >> >> PTS to perform a pairing that is not 0x00 MITM Protection Not Required
> >> >> >> – No Bonding. Numeric comparison with automatic accept allowed?  I'm
> >> >> >> using an older kernel that doesn't have the mgmt interface (2.6.33
> >> >> >> with some features/fixes backported from newer kernels) but am using
> >> >> >> the latest BlueZ from git (at least of a month ago or so).  But even
> >> >> >> so, the proposal of keeping the linkkey around for the ACL session
> >> >> >> would be useless, I think, because the intent is to have a link
> >> >> >> timeout event.
> >> >> >
> >> >> > can you quickly check if for some weird reason the PTS uses debug keys
> >> >> > or if you enabled debug keys within BlueZ.
> >> >> >
> >> >> > We treat debug keys even worse than no bonding. Unless you set DebugKeys
> >> >> > in /etc/bluetooth/main.conf they are thrown out right away. However be
> >> >> > really careful here. That option is only for debugging. You should never
> >> >> > ever leave that on in a production device. You would make your device
> >> >> > vulnerable like no tomorrow.
> >> >>
> >> >> I checked hci dumps of both the init of my unit and the trace from the
> >> >> PTS run, and neither had sent the HCI_Write_Simple_Pairing_Debug_mode
> >> >> command.  Plus we can see that the key type is 0x04, Unauthenticated
> >> >> Combination Key.  I also verified that DebugKeys was false in
> >> >> main.conf.
> >> >
> >> > please post the actual pairing exchange here, but this seems like the
> >> > PTS is fundamentally broken. If we pair with no bonding, we do throw the
> >> > link key away and that is suppose to be done this way.
> >>
> >> I have attached the trace both in Frontline ComProbe capture format
> >> and as an export to a somewhat readable html format.  The trace was
> >> taken on the PTS machine (so host=PTS machine).  Note that it is not a
> >> trace from the particular test I mentioned above, but every test has
> >> the same pairing experience.
> >>
> >> I think what you're after is this section:
> >>
> >> Frame 65: (Controller) Len=8
> >> HCI
> >> Packet from: Controller
> >> HCI Event
> >> Event: HCI IO Capability Request
> >> Total Length: 6
> >> BD_ADDR: 0x649c8ec1bce3
> >>
> >> Frame 66: (Host) Len=12
> >> HCI
> >> Packet from: Host
> >> HCI Command
> >> Opcode: 0x042b
> >> Group: Link Control
> >> Command: HCI_IO_Capability_Response
> >> Total Length: 9
> >> Bluetooth Device Address: 0x64-9c-8e-c1-bc-e3
> >> LAP: 0xc1-bc-e3
> >> UAP: 0x8e
> >> NAP: 0x64-9c
> >> IO Capability: DisplayYesNo
> >> OOB Data Present: OOB authentication data not present
> >> Authentication_Requirements: MITM Protection Not Required - No
> >> Bonding. Numeric comparision with automatic accept allowed
> >>
> >> Frame 67: (Controller) Len=12
> >> HCI
> >> Packet from: Controller
> >> HCI Event
> >> Event: Command Complete
> >> Total Length: 10
> >> Number HCI Command Packets: 1
> >> HCI Command
> >> Opcode: 0x042b
> >> Group: Link Control
> >> Command: HCI_IO_Capability_Response
> >> Return Parameters
> >> Status: Success
> >> Bluetooth Device Address: 0x64-9c-8e-c1-bc-e3
> >> LAP: 0xc1-bc-e3
> >> UAP: 0x8e
> >> NAP: 0x64-9c
> >>
> >> Frame 68: (Controller) Len=11
> >> HCI
> >> Packet from: Controller
> >> HCI Event
> >> Event: HCI IO Capability Response
> >> Total Length: 9
> >> BD_ADDR: 0x649c8ec1bce3
> >> IO Capability: NoInputNoOutput
> >> OOB Data Present: OOB authentication data not present
> >> Authentication_Requirements: MITM Protection Not Required - No
> >> Bonding. Numeric comparision with automatic accept allowed
> >>
> >> > Is there any chance to do a dedicated or general bonding with the PTS to
> >> > keep the link key around? Like you would actually be doing when using
> >> > any HFP device.
> >>
> >> It appears, based on the issues filed against PTS, that the PTS
> >> doesn't have this option.  Right now, my device, which acts as HFP HF,
> >> does not initiate pairing through any UI and requires the HFP AG to
> >> make the first connection.
> >
> > and if you are the HF role, then this is perfectly acceptable. The other
> > side should pair with you. And they need to use dedicated bonding to do
> > so. The no bonding pairing is utterly useless.
> >
> > Going through the log, it it seems that the PTS initiates the connection
> > and then tries to pair. Since it has no link key for the other side, it
> > should realize that it has to run dedicated bonding first. Doing this
> > with no bonding is just wrong.
> >
> > Any chance to run this PTS case against an actual Bluetooth headset and
> > see what it does in this area. We can not store the link key if it has
> > been requested with no bonding. The only thing I can think of right now
> > is that when the RFCOMM channel is requested we force an upgrade of the
> > link key to general bonding.
> 
> Attached a trace against a BT headset.  It looks pretty much the same,
> except that the BT headset does keep the link key around in the no
> bonding case, so future PTS runs work without have to do a new
> pairing.

that just means that everybody has worked around PTS being utterly
stupid. This is so sad.

> It's not just HFP that's affected.  The same type of problem exists
> with A2DP where we're forced to leave the Pairable Bluez adapter
> property True for every PTS connection attempt.  We normally set
> Discoverable and Pairable at the same time.  So even if the RFCOMM
> case caused extra actions, it hardly fixes it.

The concept of Pairable is exactly present so that an attacker can not
pair with you out of the blue. If you are not in Pairable and have no
link key, you just get rejected right away. Which is the right way to do
it.

Secure Simple Pairing might give you an unbreakable authentication, but
you can now just go in an redo the pairing any time you like. Not really
what should happen.

I am curious if the PTS would even survive a pairing request with
general bonding after we just paired with no bonding. But essentially
you are correct here. If Pairable is not set, it is not going to help
us.

So I have not seen the complete log since even the HTML is ugly, but
when the PTS tries to re-connect and we re-connect to the PTS, would it
actually store the link key? If PTS also throws the key away, then this
is all pointless attempt.

Personally, the PTS should be doing a dedicated bonding first as
preamble for every test case. Otherwise this is by no means real world
testing anyway.

Regards

Marcel

Re: PTS / linkkey issue

[Mike]

Hi Marcel,

>> >> >> >> I'm having a somewhat relate issue to Vishal AGARWAL [1]. =A0Th=
e trouble
>> >> >> >> I have is that the PTS system is requesting auth type 0, and Bl=
uez
>> >> >> >> happily obliges. =A0This leaves the PTS device as temporary, an=
d BlueZ
>> >> >> >> then deletes this device after the end of the connection. =A0Th=
is
>> >> >> >> prevents me from being able to pass TP/OOR/BV-02-I: [HF reconne=
cts to
>> >> >> >> AG]. =A0The code is designed to periodically reconnect to the A=
G after
>> >> >> >> it detects a link timeout. =A0But, if BlueZ has deleted the dev=
ice, I
>> >> >> >> don't do that. =A0This also somewhat applies to the A2DP test c=
ases, as
>> >> >> >> my device must be left in pairing mode in order for the tests t=
o pass.
>> >> >> >>
>> >> >> >> So, my question to people who have used PTS, is there a way to =
get the
>> >> >> >> PTS to perform a pairing that is not 0x00 MITM Protection Not R=
equired
>> >> >> >> =96 No Bonding. Numeric comparison with automatic accept allowe=
d? =A0I'm
>> >> >> >> using an older kernel that doesn't have the mgmt interface (2.6=
.33
>> >> >> >> with some features/fixes backported from newer kernels) but am =
using
>> >> >> >> the latest BlueZ from git (at least of a month ago or so). =A0B=
ut even
>> >> >> >> so, the proposal of keeping the linkkey around for the ACL sess=
ion
>> >> >> >> would be useless, I think, because the intent is to have a link
>> >> >> >> timeout event.
>> >> >> >
>> >> >> > can you quickly check if for some weird reason the PTS uses debu=
g keys
>> >> >> > or if you enabled debug keys within BlueZ.
>> >> >> >
>> >> >> > We treat debug keys even worse than no bonding. Unless you set D=
ebugKeys
>> >> >> > in /etc/bluetooth/main.conf they are thrown out right away. Howe=
ver be
>> >> >> > really careful here. That option is only for debugging. You shou=
ld never
>> >> >> > ever leave that on in a production device. You would make your d=
evice
>> >> >> > vulnerable like no tomorrow.
>> >> >>
>> >> >> I checked hci dumps of both the init of my unit and the trace from=
 the
>> >> >> PTS run, and neither had sent the HCI_Write_Simple_Pairing_Debug_m=
ode
>> >> >> command. =A0Plus we can see that the key type is 0x04, Unauthentic=
ated
>> >> >> Combination Key. =A0I also verified that DebugKeys was false in
>> >> >> main.conf.
>> >> >
>> >> > please post the actual pairing exchange here, but this seems like t=
he
>> >> > PTS is fundamentally broken. If we pair with no bonding, we do thro=
w the
>> >> > link key away and that is suppose to be done this way.
>> >>
>> >> I have attached the trace both in Frontline ComProbe capture format
>> >> and as an export to a somewhat readable html format. =A0The trace was
>> >> taken on the PTS machine (so host=3DPTS machine). =A0Note that it is =
not a
>> >> trace from the particular test I mentioned above, but every test has
>> >> the same pairing experience.
>> >>
>> >> I think what you're after is this section:
>> >>
>> >> Frame 65: (Controller) Len=3D8
>> >> HCI
>> >> Packet from: Controller
>> >> HCI Event
>> >> Event: HCI IO Capability Request
>> >> Total Length: 6
>> >> BD_ADDR: 0x649c8ec1bce3
>> >>
>> >> Frame 66: (Host) Len=3D12
>> >> HCI
>> >> Packet from: Host
>> >> HCI Command
>> >> Opcode: 0x042b
>> >> Group: Link Control
>> >> Command: HCI_IO_Capability_Response
>> >> Total Length: 9
>> >> Bluetooth Device Address: 0x64-9c-8e-c1-bc-e3
>> >> LAP: 0xc1-bc-e3
>> >> UAP: 0x8e
>> >> NAP: 0x64-9c
>> >> IO Capability: DisplayYesNo
>> >> OOB Data Present: OOB authentication data not present
>> >> Authentication_Requirements: MITM Protection Not Required - No
>> >> Bonding. Numeric comparision with automatic accept allowed
>> >>
>> >> Frame 67: (Controller) Len=3D12
>> >> HCI
>> >> Packet from: Controller
>> >> HCI Event
>> >> Event: Command Complete
>> >> Total Length: 10
>> >> Number HCI Command Packets: 1
>> >> HCI Command
>> >> Opcode: 0x042b
>> >> Group: Link Control
>> >> Command: HCI_IO_Capability_Response
>> >> Return Parameters
>> >> Status: Success
>> >> Bluetooth Device Address: 0x64-9c-8e-c1-bc-e3
>> >> LAP: 0xc1-bc-e3
>> >> UAP: 0x8e
>> >> NAP: 0x64-9c
>> >>
>> >> Frame 68: (Controller) Len=3D11
>> >> HCI
>> >> Packet from: Controller
>> >> HCI Event
>> >> Event: HCI IO Capability Response
>> >> Total Length: 9
>> >> BD_ADDR: 0x649c8ec1bce3
>> >> IO Capability: NoInputNoOutput
>> >> OOB Data Present: OOB authentication data not present
>> >> Authentication_Requirements: MITM Protection Not Required - No
>> >> Bonding. Numeric comparision with automatic accept allowed
>> >>
>> >> > Is there any chance to do a dedicated or general bonding with the P=
TS to
>> >> > keep the link key around? Like you would actually be doing when usi=
ng
>> >> > any HFP device.
>> >>
>> >> It appears, based on the issues filed against PTS, that the PTS
>> >> doesn't have this option. =A0Right now, my device, which acts as HFP =
HF,
>> >> does not initiate pairing through any UI and requires the HFP AG to
>> >> make the first connection.
>> >
>> > and if you are the HF role, then this is perfectly acceptable. The oth=
er
>> > side should pair with you. And they need to use dedicated bonding to d=
o
>> > so. The no bonding pairing is utterly useless.
>> >
>> > Going through the log, it it seems that the PTS initiates the connecti=
on
>> > and then tries to pair. Since it has no link key for the other side, i=
t
>> > should realize that it has to run dedicated bonding first. Doing this
>> > with no bonding is just wrong.
>> >
>> > Any chance to run this PTS case against an actual Bluetooth headset an=
d
>> > see what it does in this area. We can not store the link key if it has
>> > been requested with no bonding. The only thing I can think of right no=
w
>> > is that when the RFCOMM channel is requested we force an upgrade of th=
e
>> > link key to general bonding.
>>
>> Attached a trace against a BT headset. =A0It looks pretty much the same,
>> except that the BT headset does keep the link key around in the no
>> bonding case, so future PTS runs work without have to do a new
>> pairing.
>
> that just means that everybody has worked around PTS being utterly
> stupid. This is so sad.
>
>> It's not just HFP that's affected. =A0The same type of problem exists
>> with A2DP where we're forced to leave the Pairable Bluez adapter
>> property True for every PTS connection attempt. =A0We normally set
>> Discoverable and Pairable at the same time. =A0So even if the RFCOMM
>> case caused extra actions, it hardly fixes it.
>
> The concept of Pairable is exactly present so that an attacker can not
> pair with you out of the blue. If you are not in Pairable and have no
> link key, you just get rejected right away. Which is the right way to do
> it.
>
> Secure Simple Pairing might give you an unbreakable authentication, but
> you can now just go in an redo the pairing any time you like. Not really
> what should happen.
>
> I am curious if the PTS would even survive a pairing request with
> general bonding after we just paired with no bonding. But essentially
> you are correct here. If Pairable is not set, it is not going to help
> us.
>
> So I have not seen the complete log since even the HTML is ugly, but
> when the PTS tries to re-connect and we re-connect to the PTS, would it
> actually store the link key? If PTS also throws the key away, then this
> is all pointless attempt.

>From what the BQE doing the testing for me has shown, there is some
means by which the same link key can be used in multiple sessions of
the PTS.  Not sure exactly what causes that.

In any case, the real trouble I have is that BlueZ doesn't keep the
device around.  The link key issue is worked around enough by leaving
Pairable as true for the PTS session.  Since the link key is not going
to be kept, the device keeps the temporary marking.  Once I lose
connection, all D-Bus paths for the device disappear.  Without the
D-Bus paths, the Ofono Modem disappears and I don't have a mechanism
to attempt a reconnection.  I had mentioned the BQE try to call the
CreateDevice method against the BlueZ adapter, thinking as long as the
device is created first, it might all work.  I'm told that it didn't.
It may be that the Pairable property went back to false (timeout) and
that caused problems.  Do you think that should have worked?  If so,
I'll have him give it a try again.  If we can get that working, then
there is at least a means to workaround PTS' issues.

Thanks,
Mike

> Personally, the PTS should be doing a dedicated bonding first as
> preamble for every test case. Otherwise this is by no means real world
> testing anyway.

Re: PTS / linkkey issue

[Marcel Holtmann]

Hi Mike,

> >> >> >> >> I'm having a somewhat relate issue to Vishal AGARWAL [1].  The trouble
> >> >> >> >> I have is that the PTS system is requesting auth type 0, and Bluez
> >> >> >> >> happily obliges.  This leaves the PTS device as temporary, and BlueZ
> >> >> >> >> then deletes this device after the end of the connection.  This
> >> >> >> >> prevents me from being able to pass TP/OOR/BV-02-I: [HF reconnects to
> >> >> >> >> AG].  The code is designed to periodically reconnect to the AG after
> >> >> >> >> it detects a link timeout.  But, if BlueZ has deleted the device, I
> >> >> >> >> don't do that.  This also somewhat applies to the A2DP test cases, as
> >> >> >> >> my device must be left in pairing mode in order for the tests to pass.
> >> >> >> >>
> >> >> >> >> So, my question to people who have used PTS, is there a way to get the
> >> >> >> >> PTS to perform a pairing that is not 0x00 MITM Protection Not Required
> >> >> >> >> – No Bonding. Numeric comparison with automatic accept allowed?  I'm
> >> >> >> >> using an older kernel that doesn't have the mgmt interface (2.6.33
> >> >> >> >> with some features/fixes backported from newer kernels) but am using
> >> >> >> >> the latest BlueZ from git (at least of a month ago or so).  But even
> >> >> >> >> so, the proposal of keeping the linkkey around for the ACL session
> >> >> >> >> would be useless, I think, because the intent is to have a link
> >> >> >> >> timeout event.
> >> >> >> >
> >> >> >> > can you quickly check if for some weird reason the PTS uses debug keys
> >> >> >> > or if you enabled debug keys within BlueZ.
> >> >> >> >
> >> >> >> > We treat debug keys even worse than no bonding. Unless you set DebugKeys
> >> >> >> > in /etc/bluetooth/main.conf they are thrown out right away. However be
> >> >> >> > really careful here. That option is only for debugging. You should never
> >> >> >> > ever leave that on in a production device. You would make your device
> >> >> >> > vulnerable like no tomorrow.
> >> >> >>
> >> >> >> I checked hci dumps of both the init of my unit and the trace from the
> >> >> >> PTS run, and neither had sent the HCI_Write_Simple_Pairing_Debug_mode
> >> >> >> command.  Plus we can see that the key type is 0x04, Unauthenticated
> >> >> >> Combination Key.  I also verified that DebugKeys was false in
> >> >> >> main.conf.
> >> >> >
> >> >> > please post the actual pairing exchange here, but this seems like the
> >> >> > PTS is fundamentally broken. If we pair with no bonding, we do throw the
> >> >> > link key away and that is suppose to be done this way.
> >> >>
> >> >> I have attached the trace both in Frontline ComProbe capture format
> >> >> and as an export to a somewhat readable html format.  The trace was
> >> >> taken on the PTS machine (so host=PTS machine).  Note that it is not a
> >> >> trace from the particular test I mentioned above, but every test has
> >> >> the same pairing experience.
> >> >>
> >> >> I think what you're after is this section:
> >> >>
> >> >> Frame 65: (Controller) Len=8
> >> >> HCI
> >> >> Packet from: Controller
> >> >> HCI Event
> >> >> Event: HCI IO Capability Request
> >> >> Total Length: 6
> >> >> BD_ADDR: 0x649c8ec1bce3
> >> >>
> >> >> Frame 66: (Host) Len=12
> >> >> HCI
> >> >> Packet from: Host
> >> >> HCI Command
> >> >> Opcode: 0x042b
> >> >> Group: Link Control
> >> >> Command: HCI_IO_Capability_Response
> >> >> Total Length: 9
> >> >> Bluetooth Device Address: 0x64-9c-8e-c1-bc-e3
> >> >> LAP: 0xc1-bc-e3
> >> >> UAP: 0x8e
> >> >> NAP: 0x64-9c
> >> >> IO Capability: DisplayYesNo
> >> >> OOB Data Present: OOB authentication data not present
> >> >> Authentication_Requirements: MITM Protection Not Required - No
> >> >> Bonding. Numeric comparision with automatic accept allowed
> >> >>
> >> >> Frame 67: (Controller) Len=12
> >> >> HCI
> >> >> Packet from: Controller
> >> >> HCI Event
> >> >> Event: Command Complete
> >> >> Total Length: 10
> >> >> Number HCI Command Packets: 1
> >> >> HCI Command
> >> >> Opcode: 0x042b
> >> >> Group: Link Control
> >> >> Command: HCI_IO_Capability_Response
> >> >> Return Parameters
> >> >> Status: Success
> >> >> Bluetooth Device Address: 0x64-9c-8e-c1-bc-e3
> >> >> LAP: 0xc1-bc-e3
> >> >> UAP: 0x8e
> >> >> NAP: 0x64-9c
> >> >>
> >> >> Frame 68: (Controller) Len=11
> >> >> HCI
> >> >> Packet from: Controller
> >> >> HCI Event
> >> >> Event: HCI IO Capability Response
> >> >> Total Length: 9
> >> >> BD_ADDR: 0x649c8ec1bce3
> >> >> IO Capability: NoInputNoOutput
> >> >> OOB Data Present: OOB authentication data not present
> >> >> Authentication_Requirements: MITM Protection Not Required - No
> >> >> Bonding. Numeric comparision with automatic accept allowed
> >> >>
> >> >> > Is there any chance to do a dedicated or general bonding with the PTS to
> >> >> > keep the link key around? Like you would actually be doing when using
> >> >> > any HFP device.
> >> >>
> >> >> It appears, based on the issues filed against PTS, that the PTS
> >> >> doesn't have this option.  Right now, my device, which acts as HFP HF,
> >> >> does not initiate pairing through any UI and requires the HFP AG to
> >> >> make the first connection.
> >> >
> >> > and if you are the HF role, then this is perfectly acceptable. The other
> >> > side should pair with you. And they need to use dedicated bonding to do
> >> > so. The no bonding pairing is utterly useless.
> >> >
> >> > Going through the log, it it seems that the PTS initiates the connection
> >> > and then tries to pair. Since it has no link key for the other side, it
> >> > should realize that it has to run dedicated bonding first. Doing this
> >> > with no bonding is just wrong.
> >> >
> >> > Any chance to run this PTS case against an actual Bluetooth headset and
> >> > see what it does in this area. We can not store the link key if it has
> >> > been requested with no bonding. The only thing I can think of right now
> >> > is that when the RFCOMM channel is requested we force an upgrade of the
> >> > link key to general bonding.
> >>
> >> Attached a trace against a BT headset.  It looks pretty much the same,
> >> except that the BT headset does keep the link key around in the no
> >> bonding case, so future PTS runs work without have to do a new
> >> pairing.
> >
> > that just means that everybody has worked around PTS being utterly
> > stupid. This is so sad.
> >
> >> It's not just HFP that's affected.  The same type of problem exists
> >> with A2DP where we're forced to leave the Pairable Bluez adapter
> >> property True for every PTS connection attempt.  We normally set
> >> Discoverable and Pairable at the same time.  So even if the RFCOMM
> >> case caused extra actions, it hardly fixes it.
> >
> > The concept of Pairable is exactly present so that an attacker can not
> > pair with you out of the blue. If you are not in Pairable and have no
> > link key, you just get rejected right away. Which is the right way to do
> > it.
> >
> > Secure Simple Pairing might give you an unbreakable authentication, but
> > you can now just go in an redo the pairing any time you like. Not really
> > what should happen.
> >
> > I am curious if the PTS would even survive a pairing request with
> > general bonding after we just paired with no bonding. But essentially
> > you are correct here. If Pairable is not set, it is not going to help
> > us.
> >
> > So I have not seen the complete log since even the HTML is ugly, but
> > when the PTS tries to re-connect and we re-connect to the PTS, would it
> > actually store the link key? If PTS also throws the key away, then this
> > is all pointless attempt.
> 
> From what the BQE doing the testing for me has shown, there is some
> means by which the same link key can be used in multiple sessions of
> the PTS.  Not sure exactly what causes that.
> 
> In any case, the real trouble I have is that BlueZ doesn't keep the
> device around.  The link key issue is worked around enough by leaving
> Pairable as true for the PTS session.  Since the link key is not going
> to be kept, the device keeps the temporary marking.  Once I lose
> connection, all D-Bus paths for the device disappear.  Without the
> D-Bus paths, the Ofono Modem disappears and I don't have a mechanism
> to attempt a reconnection.  I had mentioned the BQE try to call the
> CreateDevice method against the BlueZ adapter, thinking as long as the
> device is created first, it might all work.  I'm told that it didn't.
> It may be that the Pairable property went back to false (timeout) and
> that caused problems.  Do you think that should have worked?  If so,
> I'll have him give it a try again.  If we can get that working, then
> there is at least a means to workaround PTS' issues.

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.

In addition this is of course only possible with the new management
interface since we need to know the value if pairing is allowed or not.
We can not just randomly pair any device that tries to connect to us.
That would be a security issue. So this is not helping you either.

And frankly, the PTS guys need to get it together and start writing
proper software. This is just embarrassing. It is not BlueZ's fault. The
test system is flawed.

Regards

Marcel

Re: PTS / linkkey issue

[Johan Hedberg]

Hi Marcel,

On Sun, Apr 22, 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.

Johan

Re: PTS / linkkey issue

[Marcel Holtmann]

Hi Johan,

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

Regards

Marcel

Re: PTS / linkkey issue

[Luiz Augusto von Dentz]

Hi Marcel,

On Mon, Apr 23, 2012 at 10:02 AM, Marcel Holtmann <marcel@holtmann.org> wrote:
>
> 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.
>

But the reattempt could possible generate a no bonding again and if we
just reject it might cause more IOP problems.

@Mike: You can mark the device as non-temporary by calling
Adapter.CreateDevice, bluetoothd will attempt to do another sdp browse
but it should be fine for PTS as we do reversed sdp anyway when
someone pair to us, I guess that would work as workaround for
qualification but I wouldn't enable this behavior on production.

-- 
Luiz Augusto von Dentz

Re: PTS / linkkey issue

[Johan Hedberg]

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

Re: PTS / linkkey issue

[Marcel Holtmann]

Hi Johan,

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

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

RE: PTS / linkkey issue

[Tom Allebrandi]

> -----Original Message-----
> From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-
> owner@vger.kernel.org] 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
>=20
> 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.
>=20
> fair point. Let them get the PTS fixed.
>=20
> 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.
>=20
> Regards
>=20
> 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@ytram.com

Re: PTS / linkkey issue

[Mike]

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 ma=
ke
>> 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 d=
elete the stored link key at the start of a test case. In other words, dele=
te the bonding. TSPX_delete_link_key set to FALSE will leave the stored lin=
k key in place and use it during the authentication process -- that is, usi=
ng the existing bonding.
>
> There are some issues with selecting the proper security mode and I/O Cap=
abilities. Part of it >>> seems <<< to be related to the security module in=
 our host stack ignoring the security configuration we send down from the t=
est cases. ("Seems" because it feels that way to me but I have no hard evid=
ence.)
>
> For the issues that have been reported, some combination of TSPX_delete_l=
ink_key is a workaround. Sometimes it works best to set it one way, sometim=
es the other.
>
> At times, setting it to TRUE to trigger a pairing process and then settin=
g it to FALSE works best.
>
> Because of the available workaround, the issues that Mike mentioned earli=
er have not been given a high priority. A general review/repair of the secu=
rity 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 k=
now that it's not a satisfying solution, I >>> personally <<< don't like it=
 either. But, a workaround is a workaround until something better comes alo=
ng :-).

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

Re: PTS / linkkey issue

[Mike]

On Mon, Apr 23, 2012 at 7:36 PM, Mike <puffy.taco@gmail.com> wrote:
> 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 orthogona=
l
>>> > 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 m=
ake
>>> it depend on the pairing setting. This is all still speculation since w=
e 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. =A0From 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. =A0If it is TRUE, we pass most of the
> tests.
>
>> From the discussion that has been going on here, I think it should set t=
o 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. =A0From what the BlueZ developers say, this is the
> correct behavior. =A0Unless 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, del=
ete the bonding. TSPX_delete_link_key set to FALSE will leave the stored li=
nk key in place and use it during the authentication process -- that is, us=
ing the existing bonding.
>>
>> There are some issues with selecting the proper security mode and I/O Ca=
pabilities. Part of it >>> seems <<< to be related to the security module i=
n 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 evi=
dence.)
>>
>> 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, someti=
mes the other.
>>
>> At times, setting it to TRUE to trigger a pairing process and then setti=
ng it to FALSE works best.
>>
>> Because of the available workaround, the issues that Mike mentioned earl=
ier have not been given a high priority. A general review/repair of the sec=
urity management situation is on my list of projects for later for this yea=
r. 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 i=
t either. But, a workaround is a workaround until something better comes al=
ong :-).
>
> We have, only partially helps. =A0I'll know tomorrow if the CreateDevice
> workaround is effective. =A0It may be. =A0If not, the only real solution
> to passing TP/OOR/BV-02-I is for PTS to request "General Bonding".

So I don't have any details, but the BQE is reporting that suddenly he
can disable deleting the link key in the PIXIT and it works.  I'm
really unsure of what made it happen, but I'm pretty sure he had added
the device using the D-Bus CreateDevice API at some point.  He also
set the Trusted flag to True, but my code inspection indicates that
probably didn't do much.  It sounds like he added it using
CreateDevice and then ran DIS/BV-01 to pair.

Wish I had a better answer, but that's all I have for now.  At least
one of the reconnect test cases that need this passed, not sure if the
others have been attempted yet.

Mike