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

Re: [STDS-802-11-TGBH] TGbh CIDs 135 and 224 ("Mismatch")



Hi Dan,

As usual, food for thought.

However, simple soul that I am, I see it as follows.

The “authentication” prior to 4 w HS is simply to say “I am an 802.11 device”, and in the 802.11bh world “you may know me from my TA (IRM)”.  At the 4 w HS it adds that it knows the network password, and, in the 11bh world, “I have an identity that you gave me previously”. 

 

To cover Antonio’s problem with having 2 identities, as stated in the Draft they are separate and a STA may choose to use one or the other, or indeed both.  The IRM is a MAC Address assigned by the STA, whilst device ID is a long term identity concept and is assigned by the AP.  Going through the Use Cases, one can see advantages in one or the other, or indeed both.  Having said that, I am still struggling a bit to understand why we are now changing the device ID concept by making it a one-time number/code, to cover some use cases which are adequately covered by IRM.  I don’t fundamentally object to doing this, but do not call it “Device ID”, it needs a new name. 

 

Graham

 

 

From: Harkins, Dan <daniel.harkins@xxxxxxx>
Sent: Thursday, August 31, 2023 4:19 PM
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] TGbh CIDs 135 and 224 ("Mismatch")

 

 

  Hello,

 

  I'm gonna butt in here….

 

  I just did a search for "definition of authentication" and it came back with this:

 

  1. the process or action of proving or showing something to be true, genuine, or valid.

"the prints will be stamped with his seal and accompanied by a letter of authentication"

    • Computing

the process or action of verifying the identity of a user or process.

"user authentication for each device ensures that the individual using the device is recognized by the company"

 

So authentication in the computing realm is the process of verifying the identity of someone or something. This is significant because these identities—IRMs and Device IDs—care conveyed in the 4way HS but the 4way HS happens after authentication. There is no way to get to the 4way HS unless you've authenticated. So after we have verified an identity we are exchanging these 11bh identifiers. Am I the only one to see a problem here? If we have verified the identity of the STA, if we have authenticated it, what use is there in exchanging them in the 4way HS. To say, "things really happen only in the 4-way handshake" is to say that the things happening are pointless—"I have verified your identity, now what is your identity?"

 

  At the beginning when we accepted this text to add this stuff to the 4way HS, I thought it was so the network could provide a new blob—and encrypted form of the STA's long-term identity per the Annex—that would be used in a subsequent connection and, significantly, outside the 4way HS. But if things are only going to happen in the 4way HS then I'm not sure what the point of this group is.

 

  Also, one more comment, if a STA provides some 11bh identifier that the AP doesn't recognize, some "bad information", I would hope that the AP would just treat the message as if the identifier was not there. This is analogous to PMKSA caching. If the STA asserts some PMKID and the AP doesn't recognize it, it just proceeds as if the PMKID was not there and there will be no PMKSA caching for this association. It doesn't refuse association. "Be conservative in what you send and liberal in what you accept" is a useful guide for protocols, it's not the law but it's a good guide. We should follow it unless there is a very good reason not to and I haven't seen that reason.

 

  OK, I lied. One more comment. I'm still not able to deal with the cognitive dissonance of worry about attacks to discover valid identities and a simultaneous desire to give back a status to the STA about whether the ID was recognized or not. What is the consensus of this group? Are we worried about this attack or not? Might need a straw poll in the next teleconference.

 

  regards,

 

  Dan.

 

--

"the object of life is not to be on the side of the majority, but to

escape finding oneself in the ranks of the insane." – Marcus Aurelius

 

On 8/31/23, 12:50 PM, "Mark Hamilton" <mark.hamilton2152@xxxxxxxxx> wrote:

 

Graham,

 

I continue to be confused by the idea that “the IRM comes first”.

 

For sake of discussion, let’s stick with the normal association process (not FILS, not PASN).  I think those others work the same way in the end, but it is too confusing to try to cover them all in the same logic flow.

 

I agree, the IRM hits the air first, in the TA of some messages.  But, I don’t think that’s important useful.  The way it really lays out, as I understand it, is that an associating client device will use some (local) address for authentication/association messages – this may or may not even be an IRM.  The network will know if this is meant to be an IRM only at the Association exchange (from the RSNXE).  But, it doesn’t communicate anything to the client device about what it thinks it knows, until Message 3 of the 4-way.

 

Thus, things really happen only in the 4-way handshake.  In Message 2 the non-AP STA sends its Device ID.  And, now, in Message 3 the AP can say what it thinks of both the IRM and the Device ID.  At this point, the AP has received both, and should have done the mapping to the stored state objects that it has.  That mapping could turn out to be any of: neither match anything, one matches and the other doesn’t, both match to the same state object, or both match but to two different state objects.

 

Also, at this point, the AP might know who the client device is from a security perspective, depending on the security mode being used.  And, the AP might have a connection between the client device’s security identity and it’s TGbh identity, or it might not.  If it does has such a connection, it could tell if either/both/neither of the TGbh identities match the security identity.  A bunch of “maybes” in this aspect of the process.

 

Anyway, at the point of sending Message 3, when the AP can really say anything useful back to the client, it has all that information all at once.  I don’t see that the IRM, nor the Device ID, are particularly “first” anymore.  The AP says what it thinks the status is, based on all the possible conditions I mentioned above, all in parallel (same time). 

 

My opinion is that if the AP doesn’t recognize either of the identifications, or if the identifications don’t match each other (map to the same state object), or if the AP happens to be able to tell if the security identity matches the TGbh identity(ies) and those don’t match, then it should say “Not recognized” to everything, and make the non-AP STA start over.

 

I think that’s what you said in the end, but I got confused by your comments along the logical path (like saying IRM comes first, and I wasn’t clear about the handling of all the other matching cases).  My takeaway is that the AP should refuse to accept anything from a non-AP STA that provides “bad” information, where bad is claiming to have a TGbh identity, but that identity either doesn’t match anything on the AP, or the identify has any sort of mismatch with other information the AP has. 

 

Are we saying the same thing?  And, did that answer Antonio’s question – which I think is that in response to his question, “The new one will be coupled to the "stored state" the IRM is coupled to?” the answer is “No, something went wrong, and everything must start over.”  In all these cases, either the problem is because either the AP has “timed out” its state information, in which case there is nothing left to re-connect to anyway, or the non-AP STA is broken or lying (an attacker?) with its information, in which case the AP should refuse to make any connection to prior state.

 

Mark

 

From: G Smith <gsmith@xxxxxxxxxxxxxxxxxxx>
Sent: Thursday, August 31, 2023 9:11 AM
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] TGbh CIDs 135 and 224 ("Mismatch")

 

Hi Antonio,

The IRM comes first as that is the TA that the STA is using to associate/authenticate.  The basic idea is that if, for any reason, the AP has a problem with the recognizing the IRM, i.e., not already stored, then the AP returns “IRM not recognized”. This is the also the case for a first time association, so the STA sends a new IRM and now the STA is “registered” via the IRM with the AP.

Similarly, if the STA sends a device ID, and the AP does not have that already stored, then AP returns “Device ID not recognized”.  In this case, there is something wrong but I am proposing that the AP “starts again” and provides a new device ID and now the STA is “registered” via the device ID with the AP.

So  now for the “mismatch” condition.  The AP will send the IRM status and the device ID status in the same frame, e.g., msg 3 of 4w HS.  If, it has a problem with matching the IRMand device ID  to the stored information, then it simply treats both IRM and Device ID as “not recognized”. 

This gives us a clean way ahead, “if in doubt, start again”.

 

Hope this helps.

 

Graham

 

From: ANTONIO DE LA OLIVA DELGADO <aoliva@xxxxxxxxxx>
Sent: Thursday, August 31, 2023 7:50 AM
To: G Smith <gsmith@xxxxxxxxxxxxxxxxxxx>
Cc: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBH] TGbh CIDs 135 and 224 ("Mismatch")

 

Hi Graham, regarding the sending of the new DID in case it is not recognized, but when the IRM is recognized. The new one will be coupled to the "stored state" the IRM is coupled to? 

So basically, if IRM is recognized, the AP knows the "stored state" of the STA and bounds a new DID to it, is this the intention?

Thanks

Antonio

 

El mié, 30 ago 2023 a las 23:05, G Smith (<gsmith@xxxxxxxxxxxxxxxxxxx>) escribió:

Hi Mark,

Thanks for detailed argument. I think we are on the same track. After the meeting today I reworked the resolution along the lines we appeared to getting consensus.

Basically, we do not add a “mismatch” status, and we do not add any detailed description of the ‘mismatch’ occurrence. 

We assume that if in any way the AP is confused, it will return status “not recognized”.  In the case of a mismatch then we assume the AP will probably set both Device ID and IRM status to “not recognized”. 

BUT then I propose to add that if the AP sends Device ID not recognized it may send a new device ID in the same KDE or element.  AND if AP sends IRM “not recognized” the STA may send a new IRM in the subsequent KDE or element.  The idea being that the STA is re-establishing itself.

 

Hence, as I understood it, although you set out the ‘mismatch’ condition(s) we do not intend to discuss this condition specifically in the Draft.

 

Specifically these are the changes I am proposing at this moment: (Maybe find a better word than “confused” in the Note?)

 

Edit at 31.29

When a non-AP STA receives an AP Identity frame with the Identifier Status equal to “Not Recognized”, it must assume that no shared identity state exists with the AP or ESS (as per the concepts of 12.2.10) and the non-AP STA must (re)establish any desired, shared identity state per the procedures previously described.  If an AP sends a Device ID element or Device ID KDE with the Device ID status field set to 1 indicating “Not Recognized”, then the AP may also provide, in that same Device ID element or Device ID KDE, a new device ID.

Note: An AP might send a Device ID status field set to 1 indicating “Not Recognized” for any reason if the AP is confused about the non-AP STA shared identity state

Note: An AP might send a Device ID status field set to 1 indicating “Not Recognized” for any reason if the AP is confused about the non-AP shared identity state.

Edit at 33.8

Note to Editor:  The changes are based on the revised text as approved for CIDS 2,3,4,5, 149, 197

 

When a non-AP STA that advertises support for IRM associates to an AP that advertises support for IRM, the AP shall include an IRM KDE in message 3 of the 4-way handshake or, when using FILS authentication, including an IRM element in the Association Request frame. If the AP recognizes the IRM MAC address, the IRM Status field of the IRM KDE or IRM element is set to 0 to indicate that the AP recognizes the IRM and the IRM field is not present. If the AP does not recognize the IRM MAC address, the IRM Status field of the IRM KDE or IRM element is set to 1 to indicate that AP does not recognize the IRM and the IRM field is not present. The non-AP STA, on receipt of an IRM Status field of value 1, indicating the AP has not recognized the IRM, may either continue to associate to the AP and provide a new IRM in an IRM KDE in message 3 of the 4-way handshake or, when using FILS authentication, including an IRM element in the Association Request frame, in or disassociate

Note: An AP might send an IRM status field set to 1 indicating “Not Recognized” for any reason if the AP is confused about the non-AP STA shared identity state.

 

 

 

 

 

From: Mark Hamilton <mark.hamilton2152@xxxxxxxxx>
Sent: Tuesday, August 29, 2023 7:24 PM
To: STDS-802-11-TGBH@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-11-TGBH] TGbh CIDs 135 and 224 ("Mismatch")

 

All,

 

Just to be clear, and also to pull in those who may not have been on today’s call.  As I understand the sequence of events that can lead up to the “mismatch” of identifiers, it looks something like this (for the regular association case, not pre-association/PASN, not FILS, etc.), and please correct me if I got something wrong:

 

Let’s assume an AP (network) has built up state for three client devices, STATE X, STATE Y, and STATE Z.  It is storing this information somewhere in/behind the network, and how it identifies these is implementation-dependent.  The state might include Layer 2 information, or it might be only “higher-layer” information, or both.  As far as 802.11 is concerned, it is just an “implementation-dependent collection of state information”.

 

The AP (network) also has some sort of “mapping table” that maps a list of expected IRMAs to these state objects.  And, similarly, it also maps the last provided device ID to these state objects.  In both cases, it is expecting the relevant STAs to provide the appropriate identification whenever they come back to the network.

 

Along comes a STA with an RCM, let’s call it STA 1.  It goes through Probes (optional), Authentication, and Association, all using IRM#1.

·       At this point, the AP (network) thinks it knows that STA 1 maps to STATE Z, based on the IRMA that it is using.

 

Now, STA 1 gets to the 4-way handshake, and provides Message 2 with a Device ID KDE.

·       The AP (network) maps the device ID (let’s call it DID#1) in the KDE, and finds that it maps to STATE Y.

 

At this point, the network knows there is a problem.  Either, IRM#1 is not really this device, or DID#1 is not really this device.  So, in message 3, does the AP say either of these are recognized?  I don’t see the argument that either of them “came first”, or is more to be trusted than the other.  So, I am arguing that message 3 should have _both_ the Device ID KDE and IRM KDE and both should say “Not Recognized”.

 

Q1: Is this agreed, or are there thoughts to do this differently?

 

I think the proposal is that at this point, the AP also includes a new device ID in the message 3 Device ID KDE, and the non-AP STA includes a new IRMA the message 4 IRM KDE, and those can be used for this device going forward, but all past state is lost and the device is effectively “starting over” (whatever that means to it/to the network) with a new identity.   The network starts a new state, STATE A, and maps the new device ID and IRMA to STATE A, and all proceeds as if this were a new device.

 

Q2: Just checking.  That is what we were working toward on the call today, right?

 

(An aside, but… what if the 4-way handshake also completes such that the network “knows the real identity” of the device – that is, at least the identity for network security purposes, which may or may not have anything to do with the state identity (STATE X, STATE Y or STATE Z) – but this identity turns out to be meaningful and it maps to STATE X?  So, now the network has gotten mappings to three different state objects for this single device.  Do we care?  Do we suggest this check even be done – for example if the device mapped to STATE Z state with both device ID and IRMA, but then the security negotiation concluded it is STATE X?  Is this another “mismatch” that we have to deal with?)

 

Mark


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


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


 

--

Antonio de la Oliva

Associate Professor
Telematics Department
Universidad Carlos III de Madrid
E-mail: 
aoliva@xxxxxxxxxx
Phone: +34 91 624 8803
Fax:   +34 91 624 8749

 


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


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


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


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