Protecting Password Identifiers in IEEE 802.11-21

 
April 2021
 
Dan Harkins, HPE
 
Slide 1
 
Protecting Password Identifiers
 
Date:
 2021-03-30
 
Authors:
 
April 2021
 
Dan Harkins, HPE
 
Slide 2
 
Abstract
 
This submission discusses protection of password
identifiers in SAE
 
April 2021
 
Dan Harkins, HPE
 
Slide 3
 
What’s The Problem?
 
Password identifiers are used to look up passwords
Passwords could be for groups of users– the way they’re used
now– or per-user
In degenerate case, they could become like usernames
Password identifiers are passed in the clear 
 PII!
STA is a member of an identified group for shared passwords
STA is a particular individual when used like usernames
We need to provide privacy to password identifiers
Give the attacker no information about the underlying identity
Prevent the attacker from using constructing PII
 
 
Two Possible Solutions
 
1.
Asymmetric crypto
AP has a trusted public key, STA does HPKE-like wrapping of
password identifier
Pros: good, modular use of secure building blocks
Cons: requires distribution of trusted public key, slower, bulkier,
possible DOS issues
2.
Symmetric crypto
AP creates a stateless pseudonym that it can decipher later on
Pros: faster, lower overhead
Cons: first connection is with a plaintext identifier
 
Let’s choose option 2 (trusted public key distribution is 
hard
)
 
Slide 4
 
Dan Harkins, HPE
 
April 2021
 
Solution (broadly speaking)
 
Have AP maintain a symmetric key
First time the STA associates it does so with an
unprotected password identifier
AP encrypts the password identifier (with some salt)
and gives it back to the STA during the 4way HS
Subsequent association is with encrypted password
identifier, STA gets a new and different pseudonym in
the subsequent 4way HS
Each association will have a unique password identifier
that can be decrypted by the AP
If STA doesn’t understand protected password
identifiers it will just respond in the clear again
 
Slide 5
 
Dan Harkins, HPE
 
April 2021
 
Issue to Consider
 
Everyone who can receive a pseudonym has to be able
to decrypt it
For ESS, that means all APs share the same symmetric key
For mesh, that means every mesh point (everyone?) shares the
same symmetric key
What’s the Issue?
STA identities can be protected against other STAs in an ESS– a
STA will not know what group another STA is in even if it’s the
same group
Group membership cannot be protected against other mesh points
in a mesh (just like APs are not protected against other APs)
 
Slide 6
 
Dan Harkins, HPE
 
April 2021
 
Protected Identifiers and Mesh
 
Random MACs and different passwords per-mesh point links
make encrypted password identifiers difficult to use
There is no way to know which encrypted password identifier to use
when constructing a Commit message
Mesh point can generate its own protected identifier but that assumes
recipients will know it, and if every mesh point knows the password and
identifier of every other mesh point, then what’s the point of doing
different passwords per-mesh link? Same security as a single password
OK, then what if it’s not random MACs?
Then what’s the privacy concern? The fixed MAC is the identity bound
to the password! No need to use protected password identifiers!
Well, what if there’s a single password for the whole mesh?
There is no point in using password identifiers then!
Conclusion: password identifiers don’t really work with mesh
 
Slide 7
 
Dan Harkins, HPE
 
April 2021
 
Proposal
 
All APs in ESS share a symmetric key
Password identifier is padded and encrypted with an 8
octet random nonce which is used as a tweak to
generate a stateless, one-time-use, pseudonym
Pseudonym is given out to STA using a KDE in the 4-
way handshake
Pseudonym is transferred via IE in next SAE Commit
Peculiarities of mesh
All mesh points must use the same symmetric key to generate and
validate protected password identities
Each mesh point will generate its own protected password identifier
There’s little point in doing password identifiers with mesh though
 
Slide 8
 
Dan Harkins, HPE
 
April 2021
April 2021
Dan Harkins, HPE
Slide 9
AES-SIV
 
key
password identifier:
 
blahfubar
 
4000blahfubar
 
padded:
 
tweaked:
 
71a08cf14000blahfubar
 
protected
password
identifier:
 
891b52f0725635f3abc8a6b13159df5afbf0a
 
Properties of Proposed Scheme
 
A passive attacker cannot determine a protected identity;
Identifiers are protected against active attack insofar as SAE is resistant to active
attack;
A passive attacker cannot connect protected identities across SAE protocol runs
Password identifiers can be arbitrarily padded to foil passive traffic analysis;
Protected identities are secure under a birthday bound of 2
32
 encryptions;
An attacker cannot substitute identifiers to connect distinct runs of SAE;
An AP needs to only manage a single symmetric secret;
APs in an ESS, and all mesh points in a mesh, share a single symmetric secret (in
an out of band, out of scope manner);
AP can use the same symmetric secret to protect all groups in the ESS that use
password identifiers;
Identities are protected against members of the same group, except in a mesh;
The interface for password identifiers on a STA is unchanged;
The overhead is minimal—25 octets plus padding;
Uses symmetric cryptography for speed and DOS resistance
 
Slide 10
 
Dan Harkins, HPE
 
April 2021
 
April 2021
 
Dan Harkins, HPE
 
Slide 11
 
References
 
11-21/0488r0
Slide Note

doc.: IEEE 802.11-yy/0541r0

April 2021

Dan Harkins, HPE

Page

Embed
Share

This submission addresses the need for safeguarding password identifiers in SAE to ensure privacy and prevent attackers from constructing personally identifiable information. The document presents two potential solutions, ultimately recommending the use of symmetric cryptography for efficient protection. By encrypting password identifiers with a symmetric key, each association receives a unique pseudonym for secure communication.

  • Password Protection
  • IEEE 802.11-21
  • Privacy
  • Symmetric Cryptography
  • Pseudonym

Uploaded on Oct 11, 2024 | 0 Views


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


  1. April 2021 doc.: IEEE 802.11-21/0541r0 Protecting Password Identifiers Date: 2021-03-30 Authors: Name Dan Harkins Affiliations Address HPE Phone email Submission Slide 1 Dan Harkins, HPE

  2. April 2021 doc.: IEEE 802.11-21/0541r0 Abstract This submission discusses protection of password identifiers in SAE Submission Slide 2 Dan Harkins, HPE

  3. April 2021 doc.: IEEE 802.11-21/0541r0 What s The Problem? Password identifiers are used to look up passwords Passwords could be for groups of users the way they re used now or per-user In degenerate case, they could become like usernames Password identifiers are passed in the clear STA is a member of an identified group for shared passwords STA is a particular individual when used like usernames We need to provide privacy to password identifiers Give the attacker no information about the underlying identity Prevent the attacker from using constructing PII PII! Submission Slide 3 Dan Harkins, HPE

  4. April 2021 doc.: IEEE 802.11-21/0541r0 Two Possible Solutions 1. Asymmetric crypto AP has a trusted public key, STA does HPKE-like wrapping of password identifier Pros: good, modular use of secure building blocks Cons: requires distribution of trusted public key, slower, bulkier, possible DOS issues 2. Symmetric crypto AP creates a stateless pseudonym that it can decipher later on Pros: faster, lower overhead Cons: first connection is with a plaintext identifier Let s choose option 2 (trusted public key distribution is hard) Submission Slide 4 Dan Harkins, HPE

  5. April 2021 doc.: IEEE 802.11-21/0541r0 Solution (broadly speaking) Have AP maintain a symmetric key First time the STA associates it does so with an unprotected password identifier AP encrypts the password identifier (with some salt) and gives it back to the STA during the 4way HS Subsequent association is with encrypted password identifier, STA gets a new and different pseudonym in the subsequent 4way HS Each association will have a unique password identifier that can be decrypted by the AP If STA doesn t understand protected password identifiers it will just respond in the clear again Slide 5 Submission Dan Harkins, HPE

  6. April 2021 doc.: IEEE 802.11-21/0541r0 Issue to Consider Everyone who can receive a pseudonym has to be able to decrypt it For ESS, that means all APs share the same symmetric key For mesh, that means every mesh point (everyone?) shares the same symmetric key What s the Issue? STA identities can be protected against other STAs in an ESS a STA will not know what group another STA is in even if it s the same group Group membership cannot be protected against other mesh points in a mesh (just like APs are not protected against other APs) Submission Slide 6 Dan Harkins, HPE

  7. April 2021 doc.: IEEE 802.11-21/0541r0 Protected Identifiers and Mesh Random MACs and different passwords per-mesh point links make encrypted password identifiers difficult to use There is no way to know which encrypted password identifier to use when constructing a Commit message Mesh point can generate its own protected identifier but that assumes recipients will know it, and if every mesh point knows the password and identifier of every other mesh point, then what s the point of doing different passwords per-mesh link? Same security as a single password OK, then what if it s not random MACs? Then what s the privacy concern? The fixed MAC is the identity bound to the password! No need to use protected password identifiers! Well, what if there s a single password for the whole mesh? There is no point in using password identifiers then! Conclusion: password identifiers don t really work with mesh Submission Slide 7 Dan Harkins, HPE

  8. April 2021 doc.: IEEE 802.11-21/0541r0 Proposal All APs in ESS share a symmetric key Password identifier is padded and encrypted with an 8 octet random nonce which is used as a tweak to generate a stateless, one-time-use, pseudonym Pseudonym is given out to STA using a KDE in the 4- way handshake Pseudonym is transferred via IE in next SAE Commit Peculiarities of mesh All mesh points must use the same symmetric key to generate and validate protected password identities Each mesh point will generate its own protected password identifier There s little point in doing password identifiers with mesh though Submission Slide 8 Dan Harkins, HPE

  9. April 2021 doc.: IEEE 802.11-21/0541r0 password identifier: blahfubar 4000blahfubar padded: tweaked: 71a08cf14000blahfubar key AES-SIV protected password identifier: 891b52f0725635f3abc8a6b13159df5afbf0a Submission Slide 9 Dan Harkins, HPE

  10. April 2021 doc.: IEEE 802.11-21/0541r0 Properties of Proposed Scheme A passive attacker cannot determine a protected identity; Identifiers are protected against active attack insofar as SAE is resistant to active attack; A passive attacker cannot connect protected identities across SAE protocol runs Password identifiers can be arbitrarily padded to foil passive traffic analysis; Protected identities are secure under a birthday bound of 232 encryptions; An attacker cannot substitute identifiers to connect distinct runs of SAE; An AP needs to only manage a single symmetric secret; APs in an ESS, and all mesh points in a mesh, share a single symmetric secret (in an out of band, out of scope manner); AP can use the same symmetric secret to protect all groups in the ESS that use password identifiers; Identities are protected against members of the same group, except in a mesh; The interface for password identifiers on a STA is unchanged; The overhead is minimal 25 octets plus padding; Uses symmetric cryptography for speed and DOS resistance Submission Slide 10 Dan Harkins, HPE

  11. April 2021 doc.: IEEE 802.11-21/0541r0 References 11-21/0488r0 Submission Slide 11 Dan Harkins, HPE

Related


More Related Content

giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#