[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [HOKEY] Is peer-SA-AAA-CA model EAP pre-authentication?
Hi,Rafa:
Thank for your clarification. Please see my followup comments!
Best regards!
-Qin
> -----Original Message-----
> From: hokey-bounces at ietf.org [mailto:hokey-bounces at ietf.org]
> On Behalf Of Rafa Marin Lopez
> Sent: Saturday, January 10, 2009 12:56 AM
> To: Qin Wu
> Cc: hokey at ietf.org
> Subject: Re: [HOKEY] Is peer-SA-AAA-CA model EAP pre-authentication?
>
> Hi Qin,
> > Hi,Rafa:
> > Thank for your reply. Please see inline.
> > Wish you happy in the new year!
> >
> I wish you the same!!!. Please see my comments inline (I
> think this e-mail is shorter ;) )
> >
> > [Qin] From different perspective, I also can say SA is the
> EAP authenticator. Otherwise how to distinguish the model
> (Peer-SA-CA-AAA) and the model (Peer-CA-AAA). Also
> Re-authentication can be viewed as model (Peer-CA-AAA). So
> your explanation is not concrete enough.
> >
> [Rafa] To me that perspective is incorrect. Let me explain
> why. In the model peer-SA-CA-AAA, the SA is NOT acting as EAP
> authenticator at all, as I already mentioned and I state again:
> "In the model peer-SA-CA-AAA the peer is the EAP peer, the CA
> is the EAP authenticator and the EAP server is in the AAA server."
>
> The SA does not perform anything at EAP level. In other
> words, no EAP authenticator state machine is performed in
> the SA. In fact, you already asked me about SA and I already answered:
>
> "To me, the SA is an entity that is carrying EAP between the
> peer and the CA during an EAP authentication that involves
> the peer (EAP peer), the CA (EAP authenticator) and the EAP
> server (AAA)."
[Qin] That's your understanding,To me,the SA and CA in all the model are acting as EAP authenticator.
It depends how you understand the role of SA and CA in different situations.e.g., before the peer moves to the CA,
SA still plays the role of authenticator to perform EAP exchange with the peer.When the peer moves from the SA to the CA,
for the model peer-SA-CA-AAA, the SA can interact with the CA to perform pre-authentication with the peer.In this situation, the SA also acts as part of authenticator to initialize authentication.
> However, in the model peer-SA-AAA-CA, the CA is NOT acting as
> EAP authenticator at all.
[Qin]:In this scenario,SA can act as EAP authenticator. What's more, how to understand pre-authentication? Why we call one
process as a pre-authentication? Who initialize pre-authentication? We need to think about it. If we ask the SA to initialize pre-authentication before the peer moves to the CA, I think it is more reasonable to view the SA as the EAP authenticator. Otherwise, if we ask CA to act as EAP authenticator, why we call it as a pre-authentication? why not call it as re-authentication?
> Regarding to your "doubt" about how to distinguish the model
> peer-SA-CA-AAA, please see section 4.1 in RFC 5247.
>As you may see the distinction is provided by the lower-layer:
[Qin]As regarding how to distinguish the model peer-SA-CA-AAA and the model peer-CA-AAA, I can not see any answer from the section 4.1 in RFC5247.What I confuse here is lower-layer mechanism in section 4.1 of RFC5247 has nothing to do with pre-authentication.
> "EAP pre-authentication differs from a normal EAP
> conversation primarily with respect to the lower-layer encapsulation."
[Qin] Do you mean PANA or AAA can be viewed as the lower-layer encapsulation?
But I don't think lower-layer encapsulation is the key difference between the model peer-SA-CA-AAA and the model peer-CA-AAA.The reason is even for the basic model peer-authenticator-AAA, the lower-layer encapsulation will also be used to transport EAP packets.
> Is that concrete enough?. (If you really want to see a nice
> example of this, see how IEEE 802.11i EAP pre-authentication works)
>
> So, please let's avoid to confuse the "transport"
> (lower-layer) of those EAP packets between the peer and the
> CA, with EAP itself.
[Qin] I can not understand what you emphasize here.
>
> >>>>
> >>>>
> >>> [Qin]: Actually I try to figure out what your intention is here.
> >>>
> >> [Rafa] My intention is that you kindly explained us in
> base of (e.g.)
> >> Fig. 1 of RFC 5247 how peer-SA-AAA-CA model is supposed to work.
> >> Would you mind to detail it? (phase 1a, phase 1b, etc...) With
> >> details the discussion will improve, without them it is
> going to be very hard to agree.
> >>
> [Rafa] It seems you skipped this comment. This is related
> with the above. Could you kindly explain us in base of (e.g.)
> Fig. 1 of RFC 5247 how peer-SA-AAA-CA model is supposed to work?
> >> On the other hand, in my opinion, peer-SA-AAA-CA model is not EAP
> >> pre-authentication but proactive key distribution. And
> this is what I
> >> have been trying to explain, my opinion by giving
> technical comments
> >> on that.
> >>
> > [Qin] It is your understanding but not very convincing.
> >
> [Rafa] Well, you should say that they are not very convincing
> "for you", because others share the same thought as mine :).
> Regarding peer-SA-AAA-CA model, I have not been able to see
> any technical detail that could convince me that I am wrong.
> In this manner, I can only conclude so far that the scenario
> in question (peer-SA-AAA-CA) is NOT EAP pre-authentication.
> > The point is key management is one integral part of
> preauthentication,
> > also in the model(peer-SA-AAA-CA),
> [Rafa] For example, this statement is too much general. Let's
> go to specific detail. In EAP, what are the parts involved in
> the EAP key material distribution?. Could you detail it in
> the peer-SA-AAA-CA model?
>
> > key derivation and distribution is
> > also a indispensable procedure after successful authentication. so
> > different model has its position and value. So my feeling
> is if we keep on arguing on this issue, why not clarify the
> relationship between proactive key distribution and
> pre-authentication firstly? Too many confusion and
> misunderstanding with the defintion of this two terms.
> >
> [Rafa]. I really believed that I have explained with detail a
> few times before :). In fact, others have also agreed on that
> explanation. But let me summarize again:
>
> According to EAP Key Management, where the authenticator
> involved in the EAP authentication (acting as EAP
> authenticator) receives the key material (e.g. MSK):
>
> EAP pre-authentication requires CA acting as EAP
> authenticator to run EAP with peer to obtain EAP keying
> material (e.g. the MSK) from EAP server.
>
> Proactive key distribution does not require CA to run EAP
> with the EAP peer before obtaining EAP keying material from
> EAP server. The key material is pushed (proactively
> distributed) to the CA before the handoff, without the
> involvement of the CA (as EAP authenticator) in the process.
[Qin]Thank for your clarification. From the conception perspective, I wish I could agree with you. However from the details perspective, I can not wholly agree with your understanding.Why we always emphasize it is CA to run EAP exchange? Who tell the CA to run EAP exchange? When to tell the CA to run EAP exchange? I think there are lots of optimized approaches we need to think about it.Although I can not image the more details of these mechanisms, more work is required to work on this.
>
> > [Qin] I can understand your feeling. However in my
> understanding, The target to be authenticated is not
> authenticator but the peer. What authenticators do is to play
> the pass through role and provision some binding in itself
> with the help of AAA server.
> >
> [Rafa]. Again, this is a very general comment and not
> accurate enough.
> In fact, you missed something really important in this
> discussion: The EAP key management. In fact, to me, the EAP
> authenticator has an important role during key distribution
> process in EAP, because it receives a key (e.g. MSK) from the
> EAP server after that EAP authenticator (and not other) has
> been involved in the EAP authentication. More importantly,
> the MSK is received by the authenticator that is involved in
> the EAP authentication as EAP authenticator.
[Qin]As i said before, key management happens after sucessful pre-authentication.
I never doubt key materials can be distributed from AAA to the authenticator.
> That clearly happens in the peer-SA-CA-AAA model where the CA
> is acting as EAP authenticator. Could you explain how does it
> happen in peer-SA-AAA-CA model?.
[Qin]It is easy to make AAA allocate key materials to the CA after success pre-authentication between the peer and AAA server.This pre-authentication process obeys the basic EAP protocol RFC3748.
> >>>>
> >>> [Qin] RFC 4137 only points out authenticator's EAP state
> machine is required to be activated, not imply it is the CA
> to activate its state machine.
> >>>
> >>>
> >> [Rafa] Right, the RFC 4137 describes the authenticator's EAP state
> >> machine. But it seems you got wrong when I referred to RFC 4137. I
> >> referred to RFC 4137 in order to highlight that, in
> peer-SA-CA-AAA,
> >> the CA performs an EAP authenticator state machine because it is
> >> involved in the EAP authentication as EAP authenticator. In the
> >> peer-SA-AAA-CA model it does NOT ever happen, so nothing
> related to
> >> the EAP authentication happens in the CA where peer is
> going (potentially) to hand off.
> >>
> > [Qin]In your understanding, the key difference between the
> > model(Peer-SA-CA-AAA)and the model(Peer-SA-AAA-CA), the
> model lacks the trigger to activate the state machine.
> However it is not a hard thing to make SA or AAA to activate
> the CA's state machine. So it seems your worry is surplus.
> >
> [Rafa] Let me clarify this, in my understanding, that is only
> ONE of the SEVERAL key differences (please see my comments
> about EAP key management).
[Qin] Sorry, I can not see any other difference between them.
> > [Qin] Sorry, I forgot where to see some materials on how
> AAA activate the CA eap state machine. If my memory is
> correct, it does exists.
> >
> [Rafa] Please enlight me because I don't see how this makes
> any sense.
> For example, according with your idea, where will the EAP
> Response/Id coming from the CA travel to?
[Qin]If my understanding is correct, the EAP Response/Id is coming from the EAP peer not from CA.
of course upon reciving the EAP response/Id message, the CA can translate this message into AAA message and
carry the EAP message in AAA message and send AAA message to the EAP server.
> >>
> >> Regarding the the SA, I already defined the role of SA
> before. (from
> >> my understanding).
> >>
> >> Btw, could you explain with detail what does "activate CA" mean in
> >> the model peer-SA-AAA-CA and how it would work?
> >>
> > [Qin]That's what we disagreed with. As regarding "activate
> CA", my understanding is it means the EAP state machine in CA
> is initialized for some reason.
> > Am I right?
> >
> [Rafa]. I think I already mentioned this in a previous e-mail:
>
> When CA's EAP authenticator state machine is activated is
> with the purpose to perform EAP between the peer and the CA
> (acting as EAP authenticator).
>
> Therefore, your statement is not accurate enough, because
> "for some reason" is, in reality, only one reason: to perform
> EAP between the peer and the CA (acting as EAP authenticator).
>
> In particular, in the model peer-SA-AAA-CA, it does not make
> any sense to activate CA to perform EAP with the peer,
> because in the model peer-SA-AAA-CA, the CA is NOT acting as
> EAP authenticator. In fact, the CA is ONLY proactively
> receiving a key from the AAA.
[Qin]I have known your perspective and conclusion. However I can not see any concrete reasons to kill it.
As I said before,the CA is activated to perform pre-authentication. But who will activate the CA to perform pre-authentication is the key issue.
> Best Regards.
>
> --
> ------------------------------------------------------
> 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