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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf