Hi Qin, Qin Wu wrote:
Hi folks: May I interrupt in? Comments in line!
Of course you can!. Mine are also inline
[Rafa] Yeah, that is, without any doubt, EAP pre-authentication where, in fact, CA is involved in the EAP authentication signalling with the peer.When I proposed the alternative of using ERP (also as an illustrative example) between the peer and the CA (acting as authenticator) through SA is because that is what I understood that EAP pre-authentication does (peer-SA-CA-AAA).[Qin]I think it works. In the model of (peer-SA-CA-AAA), the CA can be activated by the SA-CA signalling and interact with the AAA/EAP server to obtain the keying materials.
[Rafa] Sorry, but these parts you mention about what EAP pre-authentication comprises are too much general for me. I shall suggest to go into the details and implications (as you know, I went into details in posterior text :) ) in order to determine if simply 1. and 2. can be considered as EAP pre-authentication or not. In my opinion, that is not enough. For example, could you clarify how these steps are performed in which order, and which entities are involved in each step?. If you don't mind, could you explain it in base of Fig. 1 in RFC 5247?. I believe that could really help.On the other hand, I always thought that, the type of scenario you propose (peer-SA-AAA-CA) (even before you mentioned it in the ML) was proactive key distribution and not EAP pre-authentication.[Qin] Actually EAP pre-authentication comprises of two parts: 1. Authentication between the peer and AAA/EAP server 2. Keying materials derivation and distribution. What you conern here is whether the keying derivation and distribution in Pre-authentication can be viewed as proactive key distribution if the model of (peer-SA-AAA-CA) is applied for pre-authentication, am I right?
[Rafa]. The problem here, as I see it, is different. When CA's EAP state machine is activated is with the purpose to perform EAP between the peer and the CA as, for example, it is defined in RFC 4137 (Fig.1 for standalone and Fig.2 for pass-through). What do you achieve by activating the CA eap state machine from the AAA? I'm sorry but I don't understand it. Could you explain this a little bit more?But let me explain the technical motives of my reasoning. RFC 5247 states In EAP pre-authentication, an EAP peer pre-establishes EAP keying material with an authenticator prior to arrival. EAP pre-authentication only affects the timing of EAP authentication, but does not shorten or eliminate EAP (phase 1a) or AAA (phase 1b) exchanges; Discovery (phase 0) and Secure Association Protocol (phase 2) exchanges occur as described in Section 1.3. As a result, the primary benefit is to enable EAP authentication to be removed from the handoff critical path, thereby reducing latency. Use of EAP pre-authentication within IEEE 802.11 is described in [IEEE-802.11] and [8021XPreAuth].Mmmm... it seems your scenario might fit in here. But let's "ask" to the candidate authenticator CA. The CA sees a key coming from the server without even running EAP. At least, we should agree that CA does not perform the EAP authenticator state machine at all, shouldn't we?.[Qin] Let me try to understand the above paraghraph. In the model (Peer-SA-CA-model), CA can be activated by the request from CA/Peer and run the EAP authenticator state machine for CA. However in the model (Peer-SA-AAA-CA), there is no trigger from SA to activate the EAP authenticatior state machine of CA? Is that your understanding?So my question is Do you think only the SA can activate the EAP authenticator state machine of CA, is it possible for AAA to activate the EAP authenticator state machine of CA if we think state machine of CA must run before authentication?
[Rafa] To be more precise, "EAP" pre-authentication problem statement is ongoing. So we should agree on what EAP pre-authentication is, it implies etc... . Also we should agree on what proactive key distribution is , it implies, etc... in order to determine if peer-SA-AAA-CA model is EAP pre-authentication or not. My personal opinion here is, as I am trying to explain, that is not EAP pre-authentication but it is proactive key distribution.So, the CA "suddenly" receives a key for some particular peer without even running EAP. Mmmm... interesting. Let's take a look to the text of[Qin] I am confused, Actually there are no solution for pre-authentication , only pre-authentication problem statement is ongoing.
[Rafa] The relationship to me is that they are two different approaches to reduce the handoff latency. To me EAP pre-authentication has different implications than proactive key distribution. In fact, RFC 5247 analyzes them in a separated section, which is completely correct to me.Is it Proactive key distribution? What's the relationship between pre-authentication and proactive key distribution in your understanding?
What you explain here is if we use proactive key distrituion for pre-authentication, what will happen to pre-authentication?
[Rafa] Sorry, but I don't understand the question here.
Do you imply that if we does not change proactive key distribution to adapt to pre-authentiction, the proactive key distribution is not applicable to pre-authentication?[Rafa] I have basically referred to RFC 5247 where there is a clear distinction between EAP pre-authentication and proactive key distribution (for example, two separated paragraphs that I have copied). Let me insist on this, as far as I understand EAP pre-authentication and proactive key distribution, they are two different alternatives. I don't see the need of any change on none of them, because they work well to achieve a common purpose by two different ways.
[Rafa] To me, definitely no. At least from my understanding of RFC 5247. In any case, could you please illustrate and specify how that is supposed to work?proactive key distribution in RFC 5247Proactive key distribution In proactive key distribution, keying material and authorizations are transported from the backend authentication server to a candidate authenticator in advance of a handoff.the CA receives authorization information and keying material. Let's follow:Right, the candidate authenticator "feels" precisely this. In fact,As a result, EAP (phase 1a) is not needed,authentication. That is, it received a key without even running EAP. Let's go on:Right, at least under CA standpoint, it does not even perform the EAPbut the Discovery (phase 0), and Secure Association Protocol exchanges (phase 2) are still necessary. Within the AAA exchange (phase 1b), authorization and key distribution functions are typically supported, but not authentication.distribution functions but not for authentication. Thus, for the CA, it seems that everything is a consequence of a proactive key distribution process.Right. The CA sees AAA exchanges for authorization and keyOk, let's analyze the case I mention (and that you also agreed that should be considered as EAP pre-authentication). The case clearly involves an EAP authentication (phase 1a), in this case with the CA. This happens before movement to bring a key to the CA. The CA is involved in the authentication signalling and it clearly performs the EAP state machine, apart from receiving authorization and keys from the[Qin]Do you think we can not make the CA involve in the authentication signaling if we apply the model (peer-SA-AAA-CA)?
[Rafa] As I said before, I don't understand this. The problem is not merely to activate the EAP state machine. The problem is for what the EAP state machine is activated. You activate the EAP state machine to perform EAP between the peer and the CA according to the model in RFC 5247. In the model peer-SA-CA-AAA, clearly peer and CA performs EAP, in particular : peer acting as EAP peer :), CA acting as EAP authenticator, and AAA server acting as EAP server). Therefore, I cannot see how AAA activating the CA's EAP state machine can help in any manner.Do you think the AAA can not help the CA to activate the state machine for EAP authentication?
[Rafa]. My opinion, (e.g. based on the text of RFC 5247), is that proactive key distribution is an very valid alternative to reduce handoff latency but it is not EAP pre-authentication (that, btw, it is also a very valid solution for the same purpose). In particular, proactive key distribution consists of proactively pushing a key from the server (e.g. AAA) to a CA, where CA does not perform EAP.server. So it fits in the term EAP pre-authentication. Moreover, the involved parties, even the CA, know (without any doubt) that this is clearly not a proactive key distribution process.Therefore, my conclusion is that, in the scenario you mention, the CA really believes that it is part of a proactive key distribution process (according to the definitions in RFC 5247) whereas in the scenario I mention, without any doubt, CA can know it is taking part in an EAP pre-authentication process. To me, this is an indication that the scenario you propose is not EAP pre-authentication but a proactive key distribution process, where particularly the peer requests the server to proactively distribute a key to the CA. Therefore, I believe that the set of models already discussed in EAP pre-authentication PS is complete as it is right now.[Qin] I can not understand how could you get this conclusion? From my understanding, your conlusion is thatthe proactive key distribution is not applicable to Pre-authenticaion.
As I said before, in the peer-SA-AAA-CA model: "...the peer requests the server to proactively distribute a key to the CA". It does not mean that it is EAP pre-authentication.
Therefore, as I see it, they are two different alternatives that try to achieve the same goal: reduce handoff latency by reducing authentication time. Thus, I don't see a need to "apply" proactive key distribution to EAP pre-authentication.
In particular, as far as I know, EAP pre-authentication PS defines the problem statement for EAP pre-authentication (if you'll forgive the repetition :)) and not for proactive key distribution.
Glen Zorn wrote:Rafa Marin Lopez [mailto:rafa at um.es] writes:Hi Glen, I was wondering whether it would not be easier a scenario where ERP is used between the CA (acting as authenticator) and the peer, through the SA. It would follow a known model for EAP pre-authentication as happens in 802.11i and it uses ERP to reduce the EAP authentication involved in the pre-authentication. As consequence, the distributed rMSK would be installed in the CA, so when the peer moves to the CA, it has to perform the security association protocol. In this way, ERP fits in the EAP pre-authentication problem statement as it is.I'm sorry, I guess I wasn't really clear: my mention of ERP was purely illustrative. The point is that the model of peer<->SA<->[hokey server]<->CA communication seems to me to be a perfectly viable one for preauthentication (and actually compatible with the stuff we've already standardized (i.e., a hokey server)). As it stands, however, that model is not included in the problem statement draft while the model you mention explicitly is.The scenario you mention requires to push a key to the CA (as proactive key distribution does), doesn't it?. To me, that might complicate things.I don't really want to discuss solutions (let alone implementation!) right now, but I find it hard to believe that it would be more complicated than requiring a many-to-many PANA infrastructure (esp. since AFAIK virtually no one is shipping PANA). That said, I'm not suggesting that the discussion of the peer<->SA<->CA<->AAA model be removed from the draft, merely that the set of models discussed is incomplete. ...-- ------------------------------------------------------ Rafael Marin Lopez Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34968398501 e-mail: rafa at um.es ------------------------------------------------------ _______________________________________________ HOKEY mailing list HOKEY at ietf.org https://www.ietf.org/mailman/listinfo/hokey
-- ------------------------------------------------------ Rafael Marin Lopez Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34968398501 e-mail: rafa at um.es ------------------------------------------------------ _______________________________________________ HOKEY mailing list HOKEY at ietf.org https://www.ietf.org/mailman/listinfo/hokey