IEEE 802.11-20-0745r0 Identifier Privacy Service
1
Identifier Privacy Service
Date:
2020-05-12
Authors:
•
Privacy is about protecting any identifiable information
–
Avoid tracking without knowledge and permission of a tracked device/user
–
802.11 protocols contain identifiers not protected by RSNA mechanisms
•
Increasing industry attention to privacy
•
TGm has had various related discussions and specific proposals
–
11-20/0543r2 - Privacy of password identifiers
–
11-20/0366r0 - MAC privacy and PMKSA caching
–
11-19/0489r0 - Client Privacy Discussion
•
Some comments in TGm suggested the possibility of a general
scheme
–
Cover privacy of Password Identifiers, PMKIDs, extensible to potentially
cover other identifiers
•
This submission is a summary of generic identifier protection service
capability for 802.11 described in 11-20/0746r0
–
Based on ECIES, a scheme also used by 3GPP (TS 133.501) and IETF
RFC8492 for identifier protection
–
Can be applied to password identifiers to resolve CID 4731
–
Extended to support privacy of other identifiers and downgrade protection
P
r
o
b
l
e
m
&
B
a
c
k
g
r
o
u
n
d
•
Possibility to protect identifiers in initial exchange of a first-time
connection to the network, as well as subsequent connections
•
Protection against active attacks, including downgrade protection
•
Avoid changes to existing protocols/computation
•
Minimizing state on AP and non-AP STA
•
Low overhead per identifier protected
•
Minimal protocol complexity, e.g. new information elements
•
Potentially extensible to support other identifiers
–
e.g. support for avoiding device/user fingerprinting
S
o
l
u
t
i
o
n
C
o
n
s
i
d
e
r
a
t
i
o
n
s
•
Protection using ECIES [2]
•
ESS-wide public-private key pair
–
Private key distributed across APs in the ESS (out-of-scope distribution)
–
P
u
b
l
i
c
k
e
y
i
d
p
k
s
e
c
u
r
e
l
y
d
i
s
t
r
i
b
u
t
e
d
t
o
n
o
n
-
A
P
S
T
A
s
u
s
i
n
g
e
x
i
s
t
i
n
g
h
a
n
d
s
h
a
k
e
s
(
e
.
g
.
4
-
w
a
y
)
–
Key pair assumed constant for the lifetime of the network
•
Identifier Privacy (IDP) service – dot11IdentifierPrivacySupported
–
A
d
v
e
r
t
i
s
e
d
i
n
R
S
N
X
E
,
D
o
w
n
g
r
a
d
e
p
r
o
t
e
c
t
e
d
b
y
S
T
A
p
o
l
i
c
y
,
o
n
c
e
i
d
p
k
i
s
k
n
o
w
n
•
Non-AP STA chooses which identifiers it wants to protect, if any
–
Protected by in-place encryption of the entire Information field of IEs that contain
the identifiers, using symmetric key
–
IDP MIC element included in frames that include protected IEs – e.g.
authentication/association frames, containing:
–
list of the protected element IDs, Ephemeral DH public key and MIC
•
AP protects the response if non-AP STA is requesting the service
–
Includes IDP MIC element; Status fields included in AAD to prevent
downgrade
•
Pseudonym scheme for PMKID protection in EAPOL M1 and M2
P
r
o
p
o
s
a
l
O
u
t
l
i
n
e
•
Similar in complexity to 11-20-0543r2
–
Requires two ECC operations per-exchange on non-AP STA
–
One ECC operation per protected frame on the AP
–
Optimize to one operation per exchange by STA using same ephemeral
key for all frames sent during the same exchange
–
Similar complexity to 0543r2 where encrypted value is used to generate
PT with an ECC Scalar Operation
–
Most 802.11 devices now support ECC
•
I
f
i
d
p
k
i
s
o
b
t
a
i
n
e
d
a
-
p
r
i
o
r
i
,
c
a
n
p
r
o
t
e
c
t
t
h
e
e
x
c
h
a
n
g
e
o
f
t
h
e
f
i
r
s
t
-
t
i
m
e
c
o
n
n
e
c
t
i
o
n
–
Protects against passive attacks
–
If obtained in a trusted manner, protects against active attacks
•
Non-AP STA has control over what to protect
•
Minimal effect on underlying protocols
–
No change to SAE to provide password identifier protection
–
One MIC for all the identifiers protected
•
Proposal covers
–
General framework, Password Identifier privacy, PMK Identifier privacy
C
o
s
t
/
B
e
n
e
f
i
t
•
Some Issues
–
B
o
o
t
s
t
r
a
p
p
i
n
g
i
d
p
k
–
Should there be an unprotected initial exchange to provision idpk, for use cases
where there is no secure out-of-band channel
–
Trusted out-of-band bootstrapping mechanisms might include MDM-configured
network profiles, attribute in QR code URI, etc.
–
U
p
d
a
t
e
o
f
i
d
p
k
–
Enhanced denial of service protection – e.g. based on proof of work
–
Padding for hiding password identifier length w/ in-place encryption
–
reuse the same IE with IETF RFC 8018 padding when protected with IDP
mechanism
•
TG member feedback
O
p
e
n
I
s
s
u
e
s
a
n
d
N
e
x
t
s
t
e
p
s
[1] IEEE P802.11-REVmd™/D3.2, March 2020
[2] SEC1 – Elliptic Curve Cryptography -
https://www.secg.org/sec1-v2.pdf
[3] 11-20/0543r2 – Protected Password Identifiers for Privacy
[4] 11-20/0366r0 – MAC Privacy and PMKSA caching
[5] ETSI TS 133 501 V15.1.0 (2018-07) – 5G Security Architecture and Procedures
[6] IETF RFC 8492 – Secured Password Ciphersuites for TLS
[7] 11-19/0489r0 – Client Privacy Discussion
[8] IETF RFC 8018 - PKCS #5: Password-Based Cryptography Specification Version 2.1
R
e
f
e
r
e
n
c
e
s
In IEEE 802.11-20-0745r0, the focus is on protecting identifiers to enhance privacy in wireless networks. The proposal suggests using ECIES for identifier protection, covering various identifiers like password identifiers and PMKIDs. By implementing a scheme similar to 3GPP and IETF standards, the solution aims to safeguard against active attacks while minimizing protocol complexity and overhead per identifier. The proposal outlines a systematic approach for protecting identifiers during network connections, emphasizing the importance of privacy in the evolving landscape of wireless communication.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
doc.: IEEE 802.11-20-0745r0 Identifier Privacy Service Date: 2020-05-12 Authors: Name Affiliations Address Phone email Nehru Bhandaru Broadcom Inc. 250 Innovation Drive, San Jose CA 95134 408-391-2159 nehru.bhandaru@Broadcom.com Thomas Derham Broadcom Inc. 16340 W Bernardo Dr, San Diego CA 92127 thomas.derham@Broadcom.com Submission 1
doc.: IEEE 802.11-20-0745r0 Problem & Background Privacy is about protecting any identifiable information Avoid tracking without knowledge and permission of a tracked device/user 802.11 protocols contain identifiers not protected by RSNA mechanisms Increasing industry attention to privacy TGm has had various related discussions and specific proposals 11-20/0543r2 - Privacy of password identifiers 11-20/0366r0 - MAC privacy and PMKSA caching 11-19/0489r0 - Client Privacy Discussion Some comments in TGm suggested the possibility of a general scheme Cover privacy of Password Identifiers, PMKIDs, extensible to potentially cover other identifiers This submission is a summary of generic identifier protection service capability for 802.11 described in 11-20/0746r0 Based on ECIES, a scheme also used by 3GPP (TS 133.501) and IETF RFC8492 for identifier protection Can be applied to password identifiers to resolve CID 4731 Extended to support privacy of other identifiers and downgrade protection Submission
doc.: IEEE 802.11-20-0745r0 Solution Considerations Possibility to protect identifiers in initial exchange of a first-time connection to the network, as well as subsequent connections Protection against active attacks, including downgrade protection Avoid changes to existing protocols/computation Minimizing state on AP and non-AP STA Low overhead per identifier protected Minimal protocol complexity, e.g. new information elements Potentially extensible to support other identifiers e.g. support for avoiding device/user fingerprinting Submission
doc.: IEEE 802.11-20-0745r0 Proposal Outline Protection using ECIES [2] ESS-wide public-private key pair Private key distributed across APs in the ESS (out-of-scope distribution) Public key idpk securely distributed to non-AP STAs using existing handshakes (e.g. 4-way) Key pair assumed constant for the lifetime of the network Identifier Privacy (IDP) service dot11IdentifierPrivacySupported Advertised in RSNXE, Downgrade protected by STA policy, once idpk is known Non-AP STA chooses which identifiers it wants to protect, if any Protected by in-place encryption of the entire Information field of IEs that contain the identifiers, using symmetric key IDP MIC element included in frames that include protected IEs e.g. authentication/association frames, containing: list of the protected element IDs, Ephemeral DH public key and MIC AP protects the response if non-AP STA is requesting the service Includes IDP MIC element; Status fields included in AAD to prevent downgrade Pseudonym scheme for PMKID protection in EAPOL M1 and M2 Submission
doc.: IEEE 802.11-20-0745r0 Cost/Benefit Similar in complexity to 11-20-0543r2 Requires two ECC operations per-exchange on non-AP STA One ECC operation per protected frame on the AP Optimize to one operation per exchange by STA using same ephemeral key for all frames sent during the same exchange Similar complexity to 0543r2 where encrypted value is used to generate PT with an ECC Scalar Operation Most 802.11 devices now support ECC If idpk is obtained a-priori, can protect the exchange of the first-time connection Protects against passive attacks If obtained in a trusted manner, protects against active attacks Non-AP STA has control over what to protect Minimal effect on underlying protocols No change to SAE to provide password identifier protection One MIC for all the identifiers protected Proposal covers General framework, Password Identifier privacy, PMK Identifier privacy Submission
doc.: IEEE 802.11-20-0745r0 Open Issues and Next steps Some Issues Bootstrapping idpk Should there be an unprotected initial exchange to provision idpk, for use cases where there is no secure out-of-band channel Trusted out-of-band bootstrapping mechanisms might include MDM-configured network profiles, attribute in QR code URI, etc. Update of idpk Enhanced denial of service protection e.g. based on proof of work Padding for hiding password identifier length w/ in-place encryption reuse the same IE with IETF RFC 8018 padding when protected with IDP mechanism TG member feedback Submission
doc.: IEEE 802.11-20-0745r0 References [1] IEEE P802.11-REVmd /D3.2, March 2020 [2] SEC1 Elliptic Curve Cryptography - https://www.secg.org/sec1-v2.pdf [3] 11-20/0543r2 Protected Password Identifiers for Privacy [4] 11-20/0366r0 MAC Privacy and PMKSA caching [5] ETSI TS 133 501 V15.1.0 (2018-07) 5G Security Architecture and Procedures [6] IETF RFC 8492 Secured Password Ciphersuites for TLS [7] 11-19/0489r0 Client Privacy Discussion [8] IETF RFC 8018 - PKCS #5: Password-Based Cryptography Specification Version 2.1 Submission
