SSd2ZSBqdXN0IG5vdGljZWQgdGhhdCB3aGVuIGEgMi4xKyBob3N0IGNvbnRyb2xsZXIgY29ubmVj
dHMgdG8gYSAyLjAtDQpyZW1vdGUgZGV2aWNlLCB0aGUga2VybmVsIHJlLWF1dGhlbnRpY2F0ZXMg
YW5kIHJlLWVuY3J5cHRzIHRoZSBBQ0wgbGluaw0KLS0gYWx0aG91Z2ggdGhlIGxpbmsgd2FzIGFs
cmVhZHkgZW5jcnlwdGVkLiBGb3IgZXhhbXBsZSwNCg0KMjAxMS0wOC0wOCAxMjo0MzoxOC41NTg1
ODQgPCBIQ0kgQ29tbWFuZDogQWNjZXB0IENvbm5lY3Rpb24gUmVxdWVzdCAoMHgwMXwweDAwMDkp
IHBsZW4gNw0KICAgIGJkYWRkciAwMDowRDpGRDoxRTo5OTozMCByb2xlIDB4MDANCiAgICBSb2xl
OiBNYXN0ZXINCjIwMTEtMDgtMDggMTI6NDM6MTguNTYxNTU4ID4gSENJIEV2ZW50OiBDb21tYW5k
IFN0YXR1cyAoMHgwZikgcGxlbiA0DQogICAgQWNjZXB0IENvbm5lY3Rpb24gUmVxdWVzdCAoMHgw
MXwweDAwMDkpIHN0YXR1cyAweDAwIG5jbWQgMQ0KMjAxMS0wOC0wOCAxMjo0MzoxOC43Mzc2NDcg
PiBIQ0kgRXZlbnQ6IFJvbGUgQ2hhbmdlICgweDEyKSBwbGVuIDgNCiAgICBzdGF0dXMgMHgwMCBi
ZGFkZHIgMDA6MEQ6RkQ6MUU6OTk6MzAgcm9sZSAweDAwDQogICAgUm9sZTogTWFzdGVyDQoyMDEx
LTA4LTA4IDEyOjQzOjE4Ljg3NjcxNyA+IEhDSSBFdmVudDogTGluayBLZXkgUmVxdWVzdCAoMHgx
NykgcGxlbiA2DQogICAgYmRhZGRyIDAwOjBEOkZEOjFFOjk5OjMwDQoyMDExLTA4LTA4IDEyOjQz
OjE4Ljg3NjgyNCA8IEhDSSBDb21tYW5kOiBMaW5rIEtleSBSZXF1ZXN0IFJlcGx5ICgweDAxfDB4
MDAwYikgcGxlbiAyMg0KICAgIGJkYWRkciAwMDowRDpGRDoxRTo5OTozMCBrZXkgQUYyMDExMEVF
MUQzMkUyQzI3ODIxRUMzNzE5RkU3RkYNCjIwMTEtMDgtMDggMTI6NDM6MTguOTU2NzU3ID4gSENJ
IEV2ZW50OiBDb21tYW5kIENvbXBsZXRlICgweDBlKSBwbGVuIDEwDQogICAgTGluayBLZXkgUmVx
dWVzdCBSZXBseSAoMHgwMXwweDAwMGIpIG5jbWQgMQ0KICAgIHN0YXR1cyAweDAwIGJkYWRkciAw
MDowRDpGRDoxRTo5OTozMA0KMjAxMS0wOC0wOCAxMjo0MzoxOS4xNDM4NTAgPiBIQ0kgRXZlbnQ6
IENvbm5lY3QgQ29tcGxldGUgKDB4MDMpIHBsZW4gMTENCiAgICBzdGF0dXMgMHgwMCBoYW5kbGUg
MTMgYmRhZGRyIDAwOjBEOkZEOjFFOjk5OjMwIHR5cGUgQUNMIGVuY3J5cHQgMHgwMQ0KDQpMZWdh
Y3kgc2VjdXJpdHktbGV2ZWwgMyByZW1vdGUgZGV2aWNlIHRoYXQgY3JlYXRlcyBhbiBlbmNyeXB0
ZWQNCmNvbm5lY3Rpb24uDQoNCi4uLiA8IHNuaXAgPiAuLi4gSW5jb21pbmcgUkZDT01NIGNvbm5l
Y3Rpb24NCg0KMjAxMS0wOC0wOCAxMjo0MzoxOS41MTAwMzUgPiBBQ0wgZGF0YTogaGFuZGxlIDEz
IGZsYWdzIDB4MDIgZGxlbiAxMg0KICAgIEwyQ0FQKHMpOiBDb25uZWN0IHJlcTogcHNtIDMgc2Np
ZCAweDAwNDENCjIwMTEtMDgtMDggMTI6NDM6MTkuNTEwMDUxIDwgQUNMIGRhdGE6IGhhbmRsZSAx
MyBmbGFncyAweDAwIGRsZW4gMTYNCiAgICBMMkNBUChzKTogQ29ubmVjdCByc3A6IGRjaWQgMHgw
MDQwIHNjaWQgMHgwMDQxIHJlc3VsdCAwIHN0YXR1cyAwDQogICAgICBDb25uZWN0aW9uIHN1Y2Nl
c3NmdWwNCg0KLi4uIDwgc25pcCA+IC4uLiBSZS1hdXRoICYgcmUtZW5jcnlwdCAoc2VjX2xldmVs
IG9mIFJGQ09NTSBkbGMgd2FzIG1lZGl1bSkNCg0KMjAxMS0wOC0wOCAxMjo0MzoxOS42NzcxMTkg
PiBBQ0wgZGF0YTogaGFuZGxlIDEzIGZsYWdzIDB4MDIgZGxlbiA4DQogICAgTDJDQVAoZCk6IGNp
ZCAweDAwNDAgbGVuIDQgW3BzbSAzXQ0KICAgICAgUkZDT01NKHMpOiBTQUJNOiBjciAxIGRsY2kg
MjYgcGYgMSBpbGVuIDAgZmNzIDB4ZTcgDQoyMDExLTA4LTA4IDEyOjQzOjE5LjY3NzE0NCA8IEhD
SSBDb21tYW5kOiBBdXRoZW50aWNhdGlvbiBSZXF1ZXN0ZWQgKDB4MDF8MHgwMDExKSBwbGVuIDIN
CiAgICBoYW5kbGUgMTMNCjIwMTEtMDgtMDggMTI6NDM6MTkuNjc5MTE4ID4gSENJIEV2ZW50OiBD
b21tYW5kIFN0YXR1cyAoMHgwZikgcGxlbiA0DQogICAgQXV0aGVudGljYXRpb24gUmVxdWVzdGVk
ICgweDAxfDB4MDAxMSkgc3RhdHVzIDB4MDAgbmNtZCAxDQoyMDExLTA4LTA4IDEyOjQzOjE5Ljc1
NDE1NiA+IEhDSSBFdmVudDogTGluayBLZXkgUmVxdWVzdCAoMHgxNykgcGxlbiA2DQogICAgYmRh
ZGRyIDAwOjBEOkZEOjFFOjk5OjMwDQoyMDExLTA4LTA4IDEyOjQzOjE5Ljc1NDIzNCA8IEhDSSBD
b21tYW5kOiBMaW5rIEtleSBSZXF1ZXN0IFJlcGx5ICgweDAxfDB4MDAwYikgcGxlbiAyMg0KICAg
IGJkYWRkciAwMDowRDpGRDoxRTo5OTozMCBrZXkgQUYyMDExMEVFMUQzMkUyQzI3ODIxRUMzNzE5
RkU3RkYNCjIwMTEtMDgtMDggMTI6NDM6MTkuODM2MTk2ID4gSENJIEV2ZW50OiBDb21tYW5kIENv
bXBsZXRlICgweDBlKSBwbGVuIDEwDQogICAgTGluayBLZXkgUmVxdWVzdCBSZXBseSAoMHgwMXww
eDAwMGIpIG5jbWQgMQ0KICAgIHN0YXR1cyAweDAwIGJkYWRkciAwMDowRDpGRDoxRTo5OTozMA0K
MjAxMS0wOC0wOCAxMjo0MzoxOS44MzcxOTcgPiBIQ0kgRXZlbnQ6IEF1dGggQ29tcGxldGUgKDB4
MDYpIHBsZW4gMw0KICAgIHN0YXR1cyAweDAwIGhhbmRsZSAxMw0KMjAxMS0wOC0wOCAxMjo0Mzox
OS44MzcyMDcgPCBIQ0kgQ29tbWFuZDogU2V0IENvbm5lY3Rpb24gRW5jcnlwdGlvbiAoMHgwMXww
eDAwMTMpIHBsZW4gMw0KICAgIGhhbmRsZSAxMyBlbmNyeXB0IDB4MDENCjIwMTEtMDgtMDggMTI6
NDM6MTkuODM5MTk4ID4gSENJIEV2ZW50OiBOdW1iZXIgb2YgQ29tcGxldGVkIFBhY2tldHMgKDB4
MTMpIHBsZW4gNQ0KICAgIGhhbmRsZSAxMyBwYWNrZXRzIDENCjIwMTEtMDgtMDggMTI6NDM6MTku
ODQxMTk3ID4gSENJIEV2ZW50OiBDb21tYW5kIFN0YXR1cyAoMHgwZikgcGxlbiA0DQogICAgU2V0
IENvbm5lY3Rpb24gRW5jcnlwdGlvbiAoMHgwMXwweDAwMTMpIHN0YXR1cyAweDAwIG5jbWQgMQ0K
MjAxMS0wOC0wOCAxMjo0MzoxOS44NDMxOTkgPiBIQ0kgRXZlbnQ6IEVuY3J5cHQgQ2hhbmdlICgw
eDA4KSBwbGVuIDQNCiAgICBzdGF0dXMgMHgwMCBoYW5kbGUgMTMgZW5jcnlwdCAweDAxDQoNCg0K
V2hhdCBpcyB0aGUgY29uc2Vuc3VzIG9waW5pb24gcmVnYXJkaW5nIHJlZHVuZGFudCBhdXRoICsg
ZW5jcnlwdCBmb3INCmxlZ2FjeSBkZXZpY2VzPw0KDQpGV0lXLCBpbiBteSBvcGluaW9uLCBGaWd1
cmUgNS41IG9mIHRoZSBDb3JlIDQuMCBzcGVjLCBWb2wgMywgUGFydCBDIC0NCkdlbmVyaWMgQWNj
ZXNzIFByb2ZpbGUgKHBnIDMwNSBvZiA2NTYpIHNob3dzIGEgZmxvd2NoYXJ0IHdpdGggYSBkZWNp
c2lvbg0KYnJhbmNoIGxhYmVsZWQgIkVuY3J5cHRpb24gRW5hYmxlZD8iIHRoYXQgYWxsb3dzIGFu
IGltbWVkaWF0ZSBieXBhc3Mgb2YNCmF1dGggKyBlbmNyeXB0IHRvIGEgcG9zaXRpdmUgTDJDQVBf
Q29ubmVjdF9SZXNwLg0KDQpSZWdhcmRzLA0KUGV0ZXIgSHVybGV5DQo=
On Mon, 2011-08-08 at 15:27 -0400, Peter Hurley wrote:
> I've just noticed that when a 2.1+ host controller connects to a 2.0-
> remote device, the kernel re-authenticates and re-encrypts the ACL link
> -- although the link was already encrypted. For example,
>
> 2011-08-08 12:43:18.558584 < HCI Command: Accept Connection Request (0x01|0x0009) plen 7
> bdaddr 00:0D:FD:1E:99:30 role 0x00
> Role: Master
> 2011-08-08 12:43:18.561558 > HCI Event: Command Status (0x0f) plen 4
> Accept Connection Request (0x01|0x0009) status 0x00 ncmd 1
> 2011-08-08 12:43:18.737647 > HCI Event: Role Change (0x12) plen 8
> status 0x00 bdaddr 00:0D:FD:1E:99:30 role 0x00
> Role: Master
> 2011-08-08 12:43:18.876717 > HCI Event: Link Key Request (0x17) plen 6
> bdaddr 00:0D:FD:1E:99:30
> 2011-08-08 12:43:18.876824 < HCI Command: Link Key Request Reply (0x01|0x000b) plen 22
> bdaddr 00:0D:FD:1E:99:30 key AF20110EE1D32E2C27821EC3719FE7FF
> 2011-08-08 12:43:18.956757 > HCI Event: Command Complete (0x0e) plen 10
> Link Key Request Reply (0x01|0x000b) ncmd 1
> status 0x00 bdaddr 00:0D:FD:1E:99:30
> 2011-08-08 12:43:19.143850 > HCI Event: Connect Complete (0x03) plen 11
> status 0x00 handle 13 bdaddr 00:0D:FD:1E:99:30 type ACL encrypt 0x01
>
> Legacy security-level 3 remote device that creates an encrypted
> connection.
>
> ... < snip > ... Incoming RFCOMM connection
>
> 2011-08-08 12:43:19.510035 > ACL data: handle 13 flags 0x02 dlen 12
> L2CAP(s): Connect req: psm 3 scid 0x0041
> 2011-08-08 12:43:19.510051 < ACL data: handle 13 flags 0x00 dlen 16
> L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0041 result 0 status 0
> Connection successful
>
> ... < snip > ... Re-auth & re-encrypt (sec_level of RFCOMM dlc was medium)
>
> 2011-08-08 12:43:19.677119 > ACL data: handle 13 flags 0x02 dlen 8
> L2CAP(d): cid 0x0040 len 4 [psm 3]
> RFCOMM(s): SABM: cr 1 dlci 26 pf 1 ilen 0 fcs 0xe7
> 2011-08-08 12:43:19.677144 < HCI Command: Authentication Requested (0x01|0x0011) plen 2
> handle 13
> 2011-08-08 12:43:19.679118 > HCI Event: Command Status (0x0f) plen 4
> Authentication Requested (0x01|0x0011) status 0x00 ncmd 1
> 2011-08-08 12:43:19.754156 > HCI Event: Link Key Request (0x17) plen 6
> bdaddr 00:0D:FD:1E:99:30
> 2011-08-08 12:43:19.754234 < HCI Command: Link Key Request Reply (0x01|0x000b) plen 22
> bdaddr 00:0D:FD:1E:99:30 key AF20110EE1D32E2C27821EC3719FE7FF
> 2011-08-08 12:43:19.836196 > HCI Event: Command Complete (0x0e) plen 10
> Link Key Request Reply (0x01|0x000b) ncmd 1
> status 0x00 bdaddr 00:0D:FD:1E:99:30
> 2011-08-08 12:43:19.837197 > HCI Event: Auth Complete (0x06) plen 3
> status 0x00 handle 13
> 2011-08-08 12:43:19.837207 < HCI Command: Set Connection Encryption (0x01|0x0013) plen 3
> handle 13 encrypt 0x01
> 2011-08-08 12:43:19.839198 > HCI Event: Number of Completed Packets (0x13) plen 5
> handle 13 packets 1
> 2011-08-08 12:43:19.841197 > HCI Event: Command Status (0x0f) plen 4
> Set Connection Encryption (0x01|0x0013) status 0x00 ncmd 1
> 2011-08-08 12:43:19.843199 > HCI Event: Encrypt Change (0x08) plen 4
> status 0x00 handle 13 encrypt 0x01
>
>
> What is the consensus opinion regarding redundant auth + encrypt for
> legacy devices?
>
> FWIW, in my opinion, Figure 5.5 of the Core 4.0 spec, Vol 3, Part C -
> Generic Access Profile (pg 305 of 656) shows a flowchart with a decision
> branch labeled "Encryption Enabled?" that allows an immediate bypass of
> auth + encrypt to a positive L2CAP_Connect_Resp.
To answer my own query here, the Core 4.0 spec, Vol 3, Part C - Generic
Access Profile has this to say in section 5.2.2.2.2, Authentication
Required for Access to Local Service by Remote Device:
"A Bluetooth device in security mode 4 shall respond to authentication
and pairing requests during link establishment when the remote device is
in security mode 3 for backwards compatibility reasons. However,
authentication of the remote device shall be performed after the receipt
of the channel establishment request is received, and before the channel
establishment response is sent."
The way I read this statement is that legacy devices *must* be
re-authenticated -- so that precludes my associated patch, "Bluetooth:
Preserve auth + encrypt for sec mode 3 remotes".