| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
After reading through all the thread, I would like to contribute the following:
By addressing IRM and Device ID getting out of sync and restarting the process – the above may not/can not be accomplished. This results in returning to the same basic issues that were caused by RCM – so are we truly solving/addressing
the foundations of the group. Luther From: Mark Hamilton <mark.hamilton2152@xxxxxxxxx> Dan, below. Mark From: Harkins, Dan <daniel.harkins@xxxxxxx>
Hi Mark, On 8/31/23, 2:59 PM, "mark.hamilton2152@xxxxxxxxx" <mark.hamilton2152@xxxxxxxxx> wrote: Dan, So I think we are there (or very close) on all but a couple points:
-
We seem to agree that currently (without SAE password identifiers – and even then only if the passwords are 1:1 per client, which is not a “rule” per the proposal, as far as I know) the things 802.11 calls authentication are not getting
down to the level of a unique (per-STA) identification being made, unless 802.1X is used. Let's be careful. 802.1x does not mean that your credential is useful. At the IETF they deploy an 802.1X network that does PEAP (or maybe it's TTLS) and the username is "ietf" and the password is "ietf". Is that a useful identity? Is that
any more useful than a single shared password for an SSID with SAE? [[MAH]] Point taken. OK, even more so. We are in agreement, “802.11 authentication” is not a way to say “I know which device this is”. SAE password identifiers provide value to the credential and that value depends on how it's used. They could be 1:1 like a traditional username/password
[[MAH]] I don’t see username/password as 1:1, either. I have a bunch of devices that use my same username/password on my network. In fact, one of the (ab)uses of MAC address checks that providers loved to use was to limit the number
of devices that could access their network, before they charged you more. They needed _per device_ identification. Client steering (via probes) needs it to be per device, also. but they don't have to be. In a multi-tenant apartment it might be good to know that some device is in "apartment 205" and another is in "apartment 441". Is it necessary to get more granular? Probably not, for the purposes of the network
that's enough. In other deployments it might be good to know that someone associating to my home network is "guest" and someone else is "harkins" (known only by my family members). If all you want to know is whether this person gets shunted off to the Internet
("guest") or allowed access to the playstation, tv, and printer ("harkins") then that's enough, that identity is useful and an authentication protocol validating that identity is valuable.
-
Thanks for catching me, it is the EAP Authentication that validates identity, not the 4way, so you’re right, my argument is a bit off. But, my point is that it is well after 802.11 Authentication.
-
Probably the key point:
o
>>> “I guess we could say that 11bh exists to provide some useful additional identity on top of the useless identity verified with the useless (shared, publicly viewable) credential used in authentication. Is that our mission?
I thought it was different.”
o
Recall that our mission is to replace what people used to do with MAC Addresses (that were even remotely valid things to do) and won’t work now because of randomized MAC addresses. So, yes, I claim that includes providing an
identity that, like MAC addresses used to do, gives a unique identification to each client device/STA, (“on top of the useless identity verified with the useless credential used in authentication”). But that doesn't address some of the use cases that compelled our formation. Notably, the help desk. If I provide my useful identity only after authenticating with my useless identity then the network help desk won't know my useful identity
if I'm having trouble connecting with my useless identity. "Hi, I can't connect". OK, let me see what identity you're providing in the 4way handshake.
Oh wait, you're never getting to the 4way handshake. Oh well, you're out of luck, good bye.
"Thank you 11bh!" [[MAH]] So, this example is starting to cross both our email threads, just FYI… But, anyway, this is where IRM (as opposed to Device ID) is useful: “Hi, I can’t connect” “What’s your identity, as you try? You can find that in <xyz Wi-Fi status screen on the device that tells you the IRM it’s using>” 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 Mark From: Harkins, Dan <daniel.harkins@xxxxxxx>
Hi Mark, On 8/31/23, 1:55 PM, "Mark Hamilton" <mark.hamilton2152@xxxxxxxxx> wrote: Dan, my thoughts below. Mark From: Harkins, Dan <daniel.harkins@xxxxxxx>
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"
o
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. [[MAH]] As a general statement, yes. But, in 802.11, we have a lot of “authentication” processes that in fact don’t authenticate this particular client. 802.11 Open Authentication does nothing. SAE only
identifies that the client knows the secret, but it could still be one of many, many such clients. Etc. It is unfortunate that 11i decided to not use 802.11 authentication frames to do authentication. That has always been a mistake in my view and I've been trying to rectify that by defining SAE and FILS to use authentication
frames to do authentication. Yes, passwords are shared. They are also written on boards in public view. This makes the credential less useful. But there is still authentication when using it. The identity is "one of the group that knows the
password". You may find little value in that identity but that is because the identity is as useless as the credential. If you want useful identities, use useful credentials. SAE password identifiers are your friend
☺ 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. [[MAH]] I would argue that in 802.1X security, the actual authentication is happening during the 4-way HS. So, I disagree that you get to the 4way after authentication (not in any meaningful sense). No, the 4way HS does not do authentication, it does proof-of-possession of the PMK (as well as generating a unique PTK from it). When doing 802.1X the actual authentication happens in the EAP method. The identity
is verified by the EAP method and it exports a PMK bound to that identity. Scaling issues cause EAP servers to be deployed in situations where they support a multitude of Authenticators and therefore we decided that proving the Authenticator (AP) was in possession
of the PMK, which was derived by the authenticating EAP method, was crucial to the security of 11i. So yes, meaningful authentication must happen prior to the 4way HS. Of course meaningful is modulo the usefulness of your credential and useless credentials
get useless identity but the process is the same: authenticate (verify identity), generate secret bound to identity, prove possession of secret, and generate encryption key.
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?" [[MAH]] So, in summary, we are exchanging identifiers at worst case timing, at the same time as the security authentication is happening, and in many cases we doing it because there is no (singular) identity
being authenticated at all via the security methods. Not "at the same time", it really is after.
I guess we could say that 11bh exists to provide some useful
additional identity on top of the useless identity verified with the useless (shared, publicly viewable) credential used in authentication. Is that our mission? I thought it was different. (Note: it would be much easier for a supplicant to implement protected password identifiers in SAE and thereby provide useful identities with useful credentials than it would be for a supplicant to implement 11bh.
And yet for some reason vendors can't implement protected password identifiers in their supplicants so I'm wondering whether we believe they will be able to implement 11bh. I'm having doubts). 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. [[MAH]] My points above aside, I do agree that some of our choice of doing this in the 4way HS is convenience. Even if in some cases we could have done TGbh things sooner, there is an encryption key available
by the 4way messages, so it’s easy to keep the TGbh exchanges private. Well privacy of the exchange is achieved simply because an
authenticated (identity verified) key exists. Again, "I have verified your identity, now what is your identity?" seems like an odd protocol.
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. [[MAH]] I think that is effectively what Graham is suggesting. If something goes wrong, then treat this like it’s a new client showing up, and give it all new identification stuff. Excellent. 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. [[MAH]] I think this is a valid point, and we should discuss/straw poll further. That said, I was under the impression that the “attacks to discover valid identities” concern had been mostly
set aside at this point, recognizing that 1) we can’t really stop it completely, and it is getting pretty hard/rare to occur with our recent proposals; and 2) this could have happened long before there were RCM addresses, and can still happen with RCM addresses
today, so is this is “new” problem that TGbh is supposed to solve – or is this a security problem, solved by using existing security methods? But, if there are members still worried about such attacks, let’s discuss and clear this up. I think it would be useful to have this straw poll. I don't want to see this attack brought up in the future if the group doesn't think it's realistic, and if the group thinks it's realistic then we need to address
the whole status thing differently. 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 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>
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>
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ó:
--
Antonio de la Oliva Associate Professor 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 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 |