Lakshminath Dondeti wrote: >> Have existing EAP peer implementations been validated to work under >> these assumptions? i.e. will they break? Will they see "unexpected" >> EAP messages or content, and reject or discard the response? > > Kedar noted from his implementation experience and it worked with > hostap/wpa_supplicant. > Shouldn't compliant implementations discard EAP messages with unknown > codes? Well, yes. But I've successfully crashed EAP implementations in the past by intentionally violating SHOULD or MUST requirements. We need to be pro-active to ensure that this change not only is compatible with the standards, but also existing implementations and deployments. >> When does the peer send these messages? Under what circumstances? > > When the peer attaches to an authenticator. The text needs to be clarified to explain that. Right now, it appears that there are no time or state sequence restrictions on sending those messages. >> This work would appear to be fairly core to the solution. EAP servers >> are commonly deployed in conjunction with AAA servers, and interact with >> AAA proxies. Can any of that discussion be added to this document? As >> it stands, the document is unclear as to interaction between ERP and AAA >> protocols. > > Wouldn't that be duplication? A paragraph or two explaining the issues and concepts would help clarify the ERX document. As it stands now, the ERX document cannot really be understood without also reading a number of other documents. i.e. small amounts of duplication that stop a potential infinite regression is likely acceptable. > I see your point. On the other hand, EAP methods don't send lifetime of > the MSK. The peer already relies on the authenticator for lifetime > management. If the consensus shifts along these lines, I don't mind > doing this. EAP supplicants don't need to know the lifetime of the MSK because their network connection drops when the MSK expires. i.e. they are pro-actively notified. ERX supplicants need to know the lifetime of the keys that they use for re-authentication, because they may not be connected when a key expires. In that case, ERX would *increase* the number of packets and time required to authenticate. This is because the supplicant would have to try ERX, fail, and then fall back to EAP. >> This is the first mention of AAA proxies in this document. There is >> no definition of AAA proxy, and no discussion of how they interact with, >> or affect, ERP. > > Should be covered in draft-gaonkar. I strongly suggest adding *some* text about AAA and ERP interaction in this document. >> Subsequently, when the peer attaches to an authenticator within the >> local domain, it may perform an ERP exchange with the local ER server >> to obtain an rMSK for the new authenticator. >> >> It would be good to mention that this process only occurs for the >> lifetime of the relevant keys. > Not sure I understand. We are trying to treat the rMSK as similar to > the MSK as possible and so the peer does not know the lifetime. It > could, as you note earlier, but it does not at the moment. As it stands, the text I quoted has no time restrictions on the use of the rMSK. Text should be added to the section I quoted, saying that the ERP exchange may only be performed during the lifetime of the rMSK. Saying that here would also clarify the motivation for *always* sending the lifetime of the keys to the peer. If the rMSK is valid only for a particular time, then the peer *must* have that information. >> This change gives motivation to the derivation of multiple rMSKs, and >> ties them into specific entities in the network. > > Ok, so this would also address your note above about the motivation for > the hierarchy too, right? Yes. >> S = rRK Label + "\0" + NULL + length >> >> Is this string concatenation? What is NULL? How is "length" encoded? >> Are there test vectors that can be used to validate these calculations? >> > All of this comes from the EMSK document. Everything is specified in > that document. We might repeat it in this I-D, but that would be bad in > that we'd have to change things in two places if things do change. My issue was that as it stands, it's unclear as to what that text means. Perhaps the EMSK document could define parameterized functions to calculate S. This document could then reference those functions. Alan DeKok. _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf