Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-11-TGBH] TSID



Sure, see inline. Thanks

- N

On Fri, Jan 7, 2022 at 1:15 PM G Smith <gsmith@xxxxxxxxxxxxxxxxxxx> wrote:

Hi Nehru,

Thanks for response.

 

As I said I am (sadly) not an expert in security so please help me understand.  I have looked at 21/1697 and see that you are using “option 2”  (slide 7).  In this proposal the HDDF expand and extract are:

rPMKID-PRK = HKDF-Extract(current PMKID, KDK) 

rPMKID = HKDF-Expand(rPMKID-PRK, "rPMKID expansion", 16)

 

I think I follow that but not sure what “rPMKID expansion” is in this formula.  I assume TSID = rPMKID?


nb> TSID is logically separate from rPMKID. The similarity is that it is derived based on KDK and uses HKDF as defined in slide 5 of 11-21-1839r1; so TSID != rPMKID.
TSID-PRK = HKDF-Extract(“Transient Station Identity” || ID || SA, KDK)
TSID = HKDF-Expand(TSID-PRK, “TSID”, TSID-NBYTES)

 

Forgive me if I have got anything wrong, but I am almost looking at this from first principles and to understand it I need to ask a few questions (which may be obvious to you and others, but not to me).  I thank you in advance.  

nb> NP 

 

Now, as per slide 5 of your TSID proposal

During PTKSA creation each side derives the next TSID, TSIDK, TSKPN using IETF RFC5869

(I looked at HKDF so I think I’ve got the basics).

Step 1.    TSID-PRK = HKDF-Extract(“Transient Station Identity” || ID || SA, KDK) 

 

What is “Transient Station Identity”?  How does AP and STA know what it is?  What precisely are “ID” and “SA” ?

Also, just to check, is “KDK” the same as “PTK”, or something different?

nb> TSID (transient station identity) is derived as specified in slide 5. ID is outlined as opaque/higher layer on slide 4 i.e. the scheme works with any notion of an ID - that could be derived from the security context, MAC addresses used first time or from an ID exchange (like one of the other proposals) the first time one connects to the network. Please refer to 802.11me Draft V1.0 as to what KDK is - it is introduced in 11ba, and used in 11ba and 11az to extend keying material to other uses - see Figure 12-30—Pairwise key hierarchy

 

Then Step 2 is

TSID = HKDF-Expand(TSID-PRK, “TSID”, TSID-NBYTES)

What is “TSID”?  Is it a chosen name or something?   How does AP and STA  know this?  Also what length are you proposing?

nb> TSID (needs renaming because of prior use in 802.11 spec for a different purpose, but it is Transient Station Identification/Identifier in this discussion) is the output of HKDF-Expand function which is defined in IETF RFC 5869; the length is the last argument to the function and defined in Table on Slide 8 in the TSID proposal; it is 8 bytes based on advertisement in RSNXE.
 

 

Then you derive two more HKDF-expands:

TSIDK = HKDF-Expand(TSID-PRK, “TSIDK”, TSIDK-NBYTES)

TSKPN = HKDF-Expand(TSID-PRK, “TSKPN”, 6)      // 48-bit random initial packet number

 

So you now have three fields TSID, TSIDK, and TSKPN and

“TSKSA is updated with TSID, TSIDK and TSKPN”, presumably TSKSA consists of these three fields, is that right?  Is that what the AP and STA need to store?

nb> Yes 

 

Next step is

“HMAC-Hash defined by AKM, TSID-NBITS, TSIDK-NBITS by RSNXE caps”

I’m having trouble understanding this.  Looking at the explanation of HKDF, HMAC-Hash appears to be another name for HKDF-Extract but that does not seem to be right.   Not really sure what this HMAC-Hash is doing.


nb> HMAC-Hash is defined in the current 802.11 spec and used for SAE, FILS etc. Hash depends on the AKM that is used deriving PTKSA.  HMAC-Hash is not the same as HKDF-Extract

 

Moving onto slide 6

The TSID element IE includes the fields TSKPN, TSID, and TSID-Hash.

The formula for the TSID-Hash is given and consists of TSKPN(incremented by 1), TSID, SA (which one?), and BSSID.  The “AP uses the TSID to lookup the TSKSA”.  So the AP stores a list of TSHSAs (TSID, TSIDK, TSKPN) indexed using the TSID? 

nb> Yes, TSID can be used as an index to some table that identifies the STA; but there might be additional (implementation specific) ways to optimize...

 

The STA also stores a list of TSKSAs for each AP?  Does the STA also store the TSID-Hash or does it calculate that when it wants to re-associate?  (I suppose it does not matter which order). 

 nb> TSID is stored, TSID-Hash is calculated (and need not be precomputed). Slide 6 specifies how TSID-Hash is computed.

 

Then the “AP validates TSID using the TSID-Hash and TSIDK”.  So the AP carries out the TSID-Hash calculation using its stored values for TSKPN, SA and BSSID and checks it gets the same value for TSID-Hash in the TSID IE?   

Which flag does it use (Identify or Identify and Update)?  What are the rules for that? So at this stage the AP is sure that this is a STA that has associated before, yes?  How does it inform the STA that it has been recognized?

  nb> Compute using 'identify' - the normal case; if that fails compute using 'identify and update'; the element carrying the Hash can be in the clear and an observer cannot infer whether the TSID is being updated - at some expense on the AP, of course. As it was pointed out during the call, there may need to be an acknowledgement of some kind to make the update more robust in some cases; but in other cases such as SA query based update, there is already an SA query response.

 

The AP does this before the 4-way Handshake?  After 4–way handshake a new PTK is created, and then both the AP and STA recalculate the TSID, TSIDK, TSKPN, etc.  maybe calculate a new TSID-Hash, and store the results.  Is that right? You stated that the AP stores 30 octets per client, how is that broken down? 

 nb> Before TSKSA is established either a 4-way or FT or FILS handshake or PASN (11az, unassociated) needs to happen. The 30 octets are 8 bytes of TSID, 16 bytes of TSIDK, and 6 bytes of TSKPN (packet number for replay checking, similar to PN/IPN used for CCMP, GCMP, BIP etc.)

 

I may have not understood all the details, but basically at the first association, the STA and AP store the TSID, TSKPN  etc.  When the STA re-associates, it declares the TSID, the TSKPN (is this incremented?), and the TSID-Hash in the TSID IE in the association request, and the AP can confirm it has seen this STA before by checking its store of TSIDs. 

 nb> Roughly. Yes, TSKPN is incremented after each use to avoid replay attacks.

 

What response from the AP informs the STA that the TSID is accepted? 

 nb> Successful completion of 4-way or FT or FILS handshake or PASN. There is no additional exchange needed. Although we need to think about the 'auto update mechanism' and updating it while not associated (using the probe request etc.) - that was pointed out when the proposal was first presented.
How does STA inform AP this the first time it associates and wants AP to save TSID?

How big is TSID?  Is there any way that this compromises the PMK or PTK?

nb> Per slide 6, and as stated above, TSID is 8 bytes. The key derivations used as standard mechanisms to extract key material from a base key, so I'll have to trust those mechanisms and say no.

If rogue STA knows the PMK, can it mess up the TSID or cause AP and STA to get out of step?

 nb> Of course, if PMK is compromised, all bets are off.

 

This is certainly a very interesting proposal.  I would appreciate your comments on my questions and observations. 

 

Thanks

Graham

 

 

 

From: Nehru Bhandaru [mailto:nehru.bhandaru@xxxxxxxxxxxx]
Sent: Friday, January 7, 2022 2:03 AM
To: G Smith <gsmith@xxxxxxxxxxxxxxxxxxx>
Cc: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: TSID

 

Updated TSID slides to 11-21-1839r1 with the correct doc# ref to rPMKID proposal.

 

PTKSA is described in the base 802.11 spec - See 11me Draft 1.0

12.6.1.1.6 PTKSA

The PTKSA results from a successful 4-way handshake...

 

Thanks,

- N

On Thu, Jan 6, 2022 at 10:33 PM Nehru Bhandaru <nehru.bhandaru@xxxxxxxxxxxx> wrote:

Apologize. Seems to be transposition error - here is the link to rPMKID proposal to 11bi on mentor - https://mentor.ieee.org/802.11/dcn/21/11-21-1697-00-00bi-mac-privacy-and-pmksa-caching.pptx. I will update the tsid slides

 

Thanks,

 

- N

 

On Thu, Jan 6, 2022 at 7:27 PM G Smith <gsmith@xxxxxxxxxxxxxxxxxxx> wrote:

HI Nehru,

I have been reading through the TSID slides.  I am not a security expert so I am having to do a lot of background stuff so as to make sure I understand the TSID proposal.  On slide 5, I read

 

       Create TSID based on PTKSA (similar to rPMKID 11-21-1679)

 

Now I know what PMKSA is, and I know PMKID, but not PTKSA or rPMKID.  I looked at 21/1679 but that is “Start time sync PPDUs medium access considering internal collisions” so I think that is the wrong reference.  Can you please give us some more details on this and what PTKSA consists of? 

 

Thanks

 

Graham


To unsubscribe from the STDS-802-11-TGBH list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBH&A=1