Subject: Re: [HOKEY] Is peer-SA-AAA-CA model EAP pre-authentication?

From: Qin Wu <[email-masked]>
Date: Wed, 07 Jan 2009 15:35:43 +0800

Hi,Rafa:
Thank for your reply. Please see inline.
Wish you happy in the new year!

-Qin
----- Original Message ----- 
From: "Rafa Marin Lopez" <[email-masked]>
To: "wuqin" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, December 31, 2008 1:46 AM
Subject: Re: [HOKEY] Is peer-SA-AAA-CA model EAP pre-authentication?

> Hi Qin,
> 
> many thanks for your answers!!!. Please see my comments inline.
>>>>> 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]: I'm confused here. I can understand the CA is involved in EAP authentication with AAA, also I can understand the CA is involved in the SA-CA signaling with the SA, But given the model(Peer-SA-CA-AAA), I can not understand the CA could be invloved in the EAP authentication with the peer. I have to remind you in your model, two authenticator are both invloved in the relevant exchange. There are no direct signaling exchange between the peer and the CA.
>>   
> [Rafa] First of all, I thought that we had agreed on that, at least, the 
> peer-SA-CA-AAA model must be considered EAP pre-authentication no?. Am I 
> wrong?.
[Qin]:This model has been agreeed in the last couples of IETF meeting. So, no doubt.
> In any case, in response to your comment, I don't know why you say that 
> "I can not understand the CA could be invloved in the EAP 
> authentication", referring to the model peer-SA-CA-AAA. In that model it 
> seems clear to me that EAP peer is the peer, the CA is the EAP 
> authenticator and the EAP server is in the AAA server. I believe you are 
> confusing the "transport" (lower-layer) of those EAP packets between the 
> peer and the CA, with EAP itself.

[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.

>>>> [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] 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.
>>>     
>> [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.
> 
>> if my understanding is correct, you try to convince folks that the model(Peer-SA-AAA-CA) is not pre-authentication.
> [Rafa] Btw, I am NOT trying to convince anybody. I am only giving my 
> technical (personal) opinion about what I think it is right.
> 
> 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. 
The point is key management is one integral part of preauthentication, also in the model(peer-SA-AAA-CA), 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.

>>  But your reason is not sufficient. All your proof is described as follows:
>> First you assume the model(Peer-SA-AAA-CA) applies the proactive key distribution mechanism for pre-authentication, 
>> And then you further lead us that the proactive key distribution mechnism can not work for pre-authentication for the proactive key distribution can not activate CA to perform EAP authentication signaling, therefore you get your last conclusion: the model(Peer-SA-AAA-CA) is not pre-authentication, 
> [Rafa] I don't understand what you mean with "applies the proactive key 
> distribution mechanism for pre-authentication". Could you ellaborate?
>> Actually your conclusion is not concrete as you expect.
> [Rafa] Obviously I disagree as I explained several times before.
>>  The model(Peer-SA-AAA-CA) Glen raised is only a usage scenario, it is not a solution. Any key management mechanism can be considered in this model. 
> [Rafa]. Any? Could you give us a few examples?
>> Why you try to impose the proactive key distribution  to this model/
>>   
> [Rafa] I am not trying to impose anything. Basically I am saying that  
> in peer-SA-AAA-CA model the AAA server is proactively distributing a key 
> to the CA, without the involvement of the CA in EAP in any manner. In 
> other words, you "push" (or proactively distribute a key) to the CA. 
> That is proactive key distribution to me.
[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.
>>>>> 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]. 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?
>>>     
>> [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.
> Having said that, I would like to know "what do you achieve by 
> activating the CA eap state machine from the AAA?".
[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.
>> Also in exsiting RFC4137, it is not the serving Authenticator but the peer to activate the Authenticator to initialize the state machine. 
> [Rafa] I think we have a different view. For example, in RFC 4137 there 
> are a couple of variables that activates the EAP authenticator state machine
> 
> portEnabled (boolean)
> Indicates that the EAP authenticator state machine should be ready for 
> communication. This is set to
> TRUE when the EAP conversation is started by the lower layer.
> 
> ....
> 
> eapRestart (boolean)
> Indicates that the lower layer would like to restart authentication.
> 
> 
> What I see is "lower layer" but not "peer". Obviously in the other side 
> of the EAP conversation the EAP peer state machine is also working to 
> engage the EAP conversation. But that also happens with peer-SA-CA-AAA. 
[Qin] It does not matter in which layer  EAP state machine will happen. The key point is RFC4137 does not focus on the model(Peer-SA-CA-AAA)
but the generic EAP model (Peer-authenticator-AAA). The main difference between these two models, the model(Peer-SA-CA-AAA) should focus on
inter-authenticator handover case. It is a  totally new scenario, new case. Therefore new feature for this model(Peer-SA-CA-AAA)should be considered. 
>> Since you extend
>> RFC4137 to make SA to activate CA,
> [Rafa]. Why do you mention that it is need to extend RFC 4137? It seems 
> you get wrong because I am NOT saying that an extension is needed.
[Qin] I can not believe the state machine for the authenticator does not make any change for the inter-authenticator handover is considered here.
>>  why not extend RFC4137 to make AAA to activate CA. 
> [Rafa] Are you saying that RFC 4137 needs to be extended for 
> peer-SA-AAA-CA model? Again, my question what is the objective of your 
> extension? Maybe if you explain details how it may operate and the 
> objective of that, I could understand it.
[Qin] I think the extension for model(Peer-SA-AAA-CA) is not more than the extension for the model(Peer-SA-CA-AAA).
So if you don't agree any change happens in the model(peer-SA-CA-AAA), I am sorry to say changes never happen the model(Peer-SA-AAA-CA)either.
>> I can not speak more details Because it is the solution scope, not problem statement scope.
>>   
> [Rafa] No, no, please, I am looking forward to seeing more details.  
> That could help a lot to think differently. So , please , could you 
> provide some details of it?.
[Qin] sorry, I am trying to understand the model(Peer-SA-CA-AAA), the model(Peer-CA-AAA), the model(Peer-SA-AAA-CA). How to implement this model
is the solution scope I guess. Also it is not appropriate for me to figure out each solution in each model at this time.
>>>>> 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] 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.
>>>     
>>>> Is it Proactive key distribution? What's the relationship between pre-authentication and proactive key distribution in your understanding?
>>>>   
>>>>       
>>> [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.
>>>     
>> [Qin]From my understanding, the proactive key distribution is only a different optimized approach from the different perspecive. It is intended to split the key
>> managment from authentication. On the other hand, Pre-authentication is intended to integrate key management with authentication. The Re-authentication does the same way. So don't confuse proactive key distribution with the pre-authentication together here.
>>   
> [Rafa] I think I am not confusing (nor mixing) anything. I believed I 
> was clear in my previous paragraph:
> 
> "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".
> 
> --> Two different VALID approaches
[Qin] Okay.That's fine.
> 
>>>> 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? 
>>>>       
>> [Qin] The signal you send the folks in hokey woring group is you impose the proactive key  distribution to the pre-authentication and mix them together, then try to
>> neglect the model(Peer-SA-AAA-CA).   
>>   
> [Rafa] As I said before I am not trying to send any signal. I am only 
> expressing my technical (personal) opinion.
> 
> Regarding to the other comment, have you seen my previous text? To me, 
> they are two different approaches so I don't know how I am mixing 
> anything. At least in my mind they are clearly separated: EAP 
> pre-authentication and proactive key distribution --> two different and 
> VALID alternatives to reduce handoff latency.
[Qin] I have never doubted these two terms. The point is the model(peer-SA-AAA-CA) is just a model, not a solution,
How could you understand the model(peer-SA-AAA-CA) should apply for the proactive key distribution mechanisms?
> 
> 
>>> [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.
>>>
>>>     
>>>>> proactive key distribution in RFC 5247
>>>>>     
>>>>>         
>> [Qin] I can not understand why you always link the proactive key distribution to the model(Peer-SA-AAA-CA)Glen suggests He just give us a scenarios. however
>> you try to mislead us to think the model and the proactive key distribution is the same thing.It is unfair.
> [Rafa] I am NOT trying to mislead anybody. I think I am FAIRLY 
> expressing my opinion based on my technical understanding of EAP and key 
> management. So, I shall kindly suggest to focus on technical comments, 
> specific details and avoid this kind of comments.
[Qin] sorry if i offend you. Anyway i agree with you at this point.
>>  Why only your model(Peer-SA-CA-model) is possible,
> [Rafa] To be fair, it is not "my" model. It has been already designed by 
> others and implemented in technologies such as IEEE 802.11. In the IETF, 
> you can find also a few references.
[Qin] Thanks for your clarification. I can understand.
>>  is the only choice? RFC4137 does not mention your model(Peer-SA-CA-AAA), RFC 4137 only focus on the general modle(Peer-Authenticator-AAA).
>>   
> [Rafa]. Really, I don't think that RFC 4137 needs to be modified in any 
> manner in order to the model peer-SA-CA-AAA operate. If you think so, 
> what do you think it is required to modify (adding new states?, or 
> variables? etc...).
[Qin] yeah, you are right. Because the model(Peer-SA-CA-AAA) focus on inter-authenticator handover issue. New feature is required i think.
> <snip>
>>>   
>> [Qin] RFC 5247 only provides two optimized approaches from the different perspective,i.e.,Proactive key distribution does not consider to perform authentication.
>> Pre-auth and Re-auth should both consider key distribution and authentication.
>> On the other hand, If my understanding is correct, RFC5247 does not provide the model(Peer-SA-CA-AAA), also does not consider inter-authenticator handover authentication problem. That's what EAP Pre-authentication Problem Statement want to further study. So I don't agree you make conclusion based on
>> RFC5247.
>>   
> [Rafa] I mentioned RFC 5247 because from there (and from the rest of 
> related literature) I usually extract my knowledge of EAP :). Taking 
> into account that, my conclusions are those.
> 
> Btw, I agree that EAP Pre-authentication PS should reflect the problem 
> statement of EAP pre-authentication. But it seems we disagree on what 
> EAP pre-authentication is and implies.
[Qin] yeah, I have the same feeling as yours. 
>>>> Do you think the AAA can not help the CA to activate the state machine for EAP authentication?
>>>>   
>>>>       
>>> [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.
>>>     
>>>     
>>>>> 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]In your model, what's the role of SA? Actually the SA is used to activate CA to run state machine which is not mentioned in RFC 4137.
>>   
> [Rafa] 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).
> 
> I don't know why you say that RFC 4137 needs to mention that. Could you 
> ellaborate the reasons that you think RFC 4137 needs to be modified?
[Qin] What i said here is RFC 4137 does not consider inter-authenticator handover issues. So RFC4137 does not support to make the SA to activate CA run state machine.
> 
>> Also RFC 4137 only applies to the model(peer-authenticator-AAA), not the model(peer-SA-CA-AAA), If you want to conform to RFC 4137, you also need to
>> extend the model(peer-authenticator-AAA) to support your model, i.e., inter-authenticator handover model.
>>   
> [Rafa] To me, that's incorrect. Please see above.
>>>> [Qin] I can not understand how could you get this conclusion? From my understanding,  your conlusion is that
>>>> the proactive key distribution is not applicable to Pre-authenticaion. 
>>>>   
>>>>       
>>> [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.
>>>
>>> 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.
>>>
>>>     
>> [Qin] As I mentioned above, you try to mix the proactive key distribution with Pre-authentication. That's too sad.
>>   
> [Rafa]. As I said above. I don't think I am mixing anything, one thing 
> is proactive key distribution (e.g. proactively distribute a key to CA, 
> where CA does not even perform EAP) and another thing is EAP 
> pre-authentication. I think the distinction is pretty clear.
[Qin] I know what you explain here. But i think the model(peer-SA-AAA-CA) can apply different key distribution approaches, rather than only proactive key distribution. I think Glen has a better understanding on this issue. This model is raised by him.
>> Based on the text of RFC4137, your model does not fit in. The reason is RFC4137 does not consider mobility at that time.
>>   
> [Rafa] How did you get that conclusion based on the text of RFC 4137?.
[Qin] RFC 4137 only applies on the generic model(peer-authenticator-AAA) while the model(peer-SA-CA-AAA) focus on inter-authenticator handover.
>> Given the inter-authenticator handover scenario, the mechanism for the model (peer-authenticator-AAA)can not be directly used for preauthentication without  any change or extension.e.g.,
> [Rafa] What kind of change or extension?.
[Qin] It should be identified in the future. I have not thought about it clearly.
> 
>>  In the model(peer-SA-CA-AAA) two authenticator are involved in, in the model(Peer-SA-AAA-CA),the mechanism to activate CA maybe is needed. 
> [Rafa] I disagree with this. In peer-SA-CA-AAA , as far as I can see  
> (and under EAP authentication standpoint), there is an EAP peer (peer), 
> and EAP authenticator (CA) and EAP server (AAA).
> 
> 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?
> 
> Thanks.
> 
>> So each model has its disadvantage and advantage.:)  
>>   
> 
> 
> -- 
> ------------------------------------------------------
> Rafael Marin Lopez
> Dept. Information and Communications Engineering (DIIC)
> Faculty of Computer Science-University of Murcia
> 30100 Murcia - Spain
> Telf: +34968398501    e-mail: [email-masked]
> ------------------------------------------------------
> 
>
_______________________________________________
HOKEY mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/hokey

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 7 Jan 2009 11:43:03 +0200

> [Qin] It is your understanding but not very convincing.

I agree with Rafa and I explained earlier why so. In your "peer-SA-AAA-CA"
model, what you call "CA" is not acting as "authenticator". It does not
deserve to be called "candidate AUTHENTICATOR". It's not involved in EAP at
all. It's just an intermediate key holder. Something inserted between the
serving authenticator and target BS. That's it. Just an additional layer in
the key hierarchy below "authenticator".

Alper

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 7 Jan 2009 18:42:24 -0800

Alper Yegin [mailto:[email-masked]] writes:

> > That depends upon how you define "authenticator".  IEEE 802.1X
> defines
> > it as
> > "An entity at one end of a point-to-point LAN segment that
> facilitates
> > authentication of
> > the entity attached to the other end of that link"; RFC 3748
> > incorporates
> > this definition by reference but further qualifies it as "[t]he end
> of
> > the
> > link initiating EAP authentication", while RFC 5247 (wisely, I think)
> > dumps
> > the .1X definition but keeps the qualification.
> > draft-ietf-hokey-preauth-ps-05.txt just references RFC 3748 (a
> mistake,
> > I
> > think, since it unnecessarily limits the scope of the document to
> > LANs).  As
> > it is, it's clear that in none of the scenarios described by
> > draft-ietf-hokey-preauth-ps-05.txt is the CA acting as an RFC 3748
> > authenticator since it is assumed that there is no L2 connectivity
> > between
> > the peer and the CA.  Even if we change the draft to use the least
> > restrictive definition of those cited ("The entity initiating EAP
> > authentication", from RFC 5247), it's not at all clear to me that
> that
> > alone
> > would fix the problem.
> 
> RFC 3748 is clear with respect to what an authenticator is, through its
> normative and descriptive text on the expected behavior from an
> authenticator, and the diagrams. If your entity is not involved in EAP
> messaging following those requirements, it is not an authenticator. I
> don't
> think an unfortunate mention of "L2 connectivity" or "LAN" (which fail
> even
> on well-accepted IKEv2 case) makes any difference.

I see.  So we pick what we like and ignore the rest?  OK.  How does the SA
initiate EAP authentication?

> 
> 
> > Furthermore, I'm having a hard time
> > understanding
> > your argument, since the existing draft explicitly states that "The
> > role of
> > the serving authenticator in indirect pre-authentication is to
> forward
> > EAP
> > pre-authentication signaling between the peer and the candidate
> > authenticator and not to act as an authenticator, while it acts as an
> > authenticator for normal authentication signaling."  Are you saying
> > that
> > it's OK for the SA to be called an "authenticator" (although it's not
> > acting
> > as one) but not for the CA?  If so, it seems to me that that
> assertion
> > is a
> > lot more political than technical...
> 
> The I-D says, SA is acting as "authenticator" for EAP that involves
> access
> to the serving network.
> SA is not acting as "authenticator" for EAP that involves access to the
> target network. 

OK, so some time in the past the SA was an authenticator but not now ("now"
being the point in time at which pre-auth is taking place).  That seems to
suggest a problem in terminology at the very least.  

> In that sense, you can see the functionality of SA as
> similar to what a base station does when it forwards the EAP messages
> to the
> authenticator (NAS) sitting behind it.
> 
> Sorry, this couldn't be more technical than that.

But you seem to be saying two different things: the base station is not an
authenticator but the SA (which provides similar functionality, you say)
rather magically is.

> 
> 
> > > For that matter, it does not even qualify as being called
> "candidate
> > > authenticator". It is just an intermediate key holder, which
> receives
> > > EAP-generated key from "serving authenticator" and it may be
> > generating
> > > that key's children and pushing them to "candidate attachment
> > points."
> >
> > No.  The only real difference between the scheme I am proposing and
> the
> > standard EAP/AAA scheme is the target of the affirmative
> authorization
> > message from AAA.  There is no transfer of keys between the SA & CA.
> 
> So you are talking about CA receiving MSK from AAA without being
> involved in
> EAP at all. Right?

Yup.

> Obviously that CA did not act as "authenticator" for the EAP exchange
> that
> yielded that MSK.

I'm not claiming that it did; what I am claiming is that the scheme fits the
RFC 5247 definition of pre-authentication.

...

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 7 Jan 2009 18:50:19 -0800

Alper Yegin [mailto:[email-masked]] writes:

> > > have been trying to explain, my opinion by giving technical
> comments
> > on
> > > that.

Just repeating something doesn't make it correct.  Section 4 of RFC 5247
says this about proactive 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."
So even if this _was_ "proactive key distribution" (which it's not, since
EAP authentication is _not_ bypassed), the CA would still be a CA according
to 5247.

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 8 Jan 2009 12:30:29 +0200

> initiate EAP authentication?

I'm not sure about the exact context of your question. But I can tell you
that depending on the access technology and the overall architecture, EAP
authentication may be initiated by the EAP peer (triggered in fact), or the
network; by means of L2 messages or L3. My response is generic because your
question is not specific enough. If you ask a more specific question, I'd
appreciate.

> suggest a problem in terminology at the very least.

OK.

> authenticator but the SA (which provides similar functionality, you

I'm missing your point.

> RFC 5247 definition of pre-authentication.

No it does not.

   EAP Pre-Authentication
      The use of EAP to pre-establish EAP keying material on an
      authenticator prior to arrival of the peer at the access network
      managed by that authenticator.

I don't see EAP peer using EAP with the so-called "CA" in your scheme.

Alper

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 8 Jan 2009 07:30:58 -0800

Alper Yegin [mailto:[email-masked]] writes:

> > I see.  So we pick what we like and ignore the rest?  OK.  How does
> the
> > SA

Certainly.  You rejected half of the RFC 3748 definition of the term
"Authenticator" due to the unfortunate (not to mention inconvenient for your
purposes ;-) mention of L2 connectivity in a normative reference; I was
asking about the other half, "The end of the link initiating EAP
authentication." (RFC 5247 says "The entity initiating EAP
authentication.").  

> > > > authenticator and not to act as an authenticator, while it acts
> as
> > an
> > being the point in time at which pre-auth is taking place).  That
> seems
> > to
> > But you seem to be saying two different things: the base station is
> not
> > an

Maybe I'm missing yours ;-).  Your entire argument seems to be based on the
idea that in the [P->SA->AAA->CA] scheme the CA is not a "real"
authenticator (since you seem to reject all known definitions of
"authenticator", it's hard to tell what such a thing might actually be).  In
the [P->SA->CA->AAA] scheme, the SA is not a "real" authenticator either but
some kind of proxy, yet you seem to be OK with calling it an authenticator.
I contend that this is incorrect.

> I don't see EAP peer using EAP with the so-called "CA" in your scheme.

I don't see any requirement for such a thing in the passage quoted above.
However, the terminology used in RFC 5247 is terribly flawed.  Just to start
with, there is, as you know, no such thing as "EAP keying material": keying
material (if any) is produced as a side-effect of the successful completion
of an EAP _method_ and distribution of that material always depends upon
methods external to EAP (e.g., AAA).  This being the case, an EAP
authenticator cannot possibly "know" anything about keying material unless
one extends the term to include the AAA subsystem and the interface to which
the traffic protection keys are to be plumbed.  In my scheme, EAP (and,
optionally, AAA) is used by an appropriate EAP method to establish fresh
keying material on what I would prefer to call a "candidate attachment
point" (just as it might be more appropriate for present purposes to call
the SA a "serving attachment point" in the [P->SA->CA->AAA] case).  How does
this not fit the definition above?

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 8 Jan 2009 18:41:39 +0200

Glen,

> > authentication may be initiated by the EAP peer (triggered in fact),
> or
> > the
> > network; by means of L2 messages or L3. My response is generic
> because
> > your
> purposes ;-) 

Glen, do me a favor and let's stick to a technical debate. Ok? 

> mention of L2 connectivity in a normative reference; I was

As I said, taking the "L2 connectivity" and "end of link" terms literally
and seeking compliance with that is a sure recipe to nullify a lot of
architectures, products, and deployments of EAP --  except those operating
EAP over pure L2 between two end points on the same L2 segment. Obviously
that's not the intent of RFC 5247, so your reading is not reasonable. If you
disagree, then the only way out is to seek RFC 5247 be revised (I don't
object if that's what you want to do).

> > > > > it's OK for the SA to be called an "authenticator" (although
> it's
> > > not
> > > > > acting
> > > > SA is not acting as "authenticator" for EAP that involves access
> to
> > > the
> > > > target network.
> > >
> > > OK, so some time in the past the SA was an authenticator but not
> now
> > > ("now"
> "authenticator", it's hard to tell what such a thing might actually
> be). 

I already told you what it might be: an intermediate level in the key
hierarchy between the SA and target BS (base station).

 In
> I contend that this is incorrect.

I do agree with that point. 
CA is a real "authenticator in the "P->X->CA->AAA" case though.

> > > > > message from AAA.  There is no transfer of keys between the SA
> &
> > > CA.
> > > >

If you want to dissect RFC 5247 and improve it, I have no objection.
But I think you are just picking on wording. It is *obvious* that the
definition, the rest of RFC 5247, and the references it provides
(8021XPreAuth) is all about "EAP pre-authentication" involving EAP through
target authenticator. 

I'd not call it "*EAP* pre-authentication" if we are talking about AAA
pushing some keys to some (non-authenticator) node in advance of handover.
Because if we did, then a lot of optimizations (if not all) become "EAP
pre-authentication".... For example:

	Consider host connected to BS1. BS1 and BS2 are attached to NAS.
	Prior to host's handover, NAS can push a key to BS2, hence host does

	not have to perform EAP when attached to BS2.

Now, according to your largely-scoped definition, this should also count as
"EAP pre-auth". But it does not make sense.

Alper

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 8 Jan 2009 14:16:01 -0800

Alper Yegin [mailto:[email-masked]] writes:

> Glen,
> 
> > > I'm not sure about the exact context of your question. But I can
> tell
> > > you
> > > that depending on the access technology and the overall
> architecture,
> > > EAP
> > > question is not specific enough. If you ask a more specific
> question,
> > > I'd
> > > appreciate.
> >
> > "Authenticator" due to the unfortunate (not to mention inconvenient
> for
> > your
> > purposes ;-)
> 

I'd like to _start_ having a technical debate, but that seems impossible.

> As I said, taking the "L2 connectivity" and "end of link" terms

How shall we take them?  Spiritually?  

> EAP over pure L2 between two end points on the same L2 segment.

You seem to be suggesting that, perhaps, that the authors of the documents
might not have been prescient or even that the RFCs themselves might not be
exhaustive.

> Obviously
> that's not the intent of RFC 5247, so your reading is not reasonable.

It says that an authenticator is an "entity initiating EAP authentication".
That seems pretty unambiguous to me.  So, one more time, in the
[P->SA->CA->AAA] scenario, how does the CA initiate EAP authentication?

> If you

On the contrary, the only way for you to make your case is to modify 5247 to
make it match your interpretation of it.

...

> > > I'm missing your point.
> >
> > Maybe I'm missing yours ;-).  Your entire argument seems to be based
> on
> > the

My parenthetical statement referred to "authenticator" in general, not the
role of the CA in this particular case.  I would appreciate it if we could
leave WiMAX out of this conversation, since that can only serve to limit the
discussion even further.

> CA is a real "authenticator in the "P->X->CA->AAA" case though.

One more time: if it is a real authenticator, then it must initiate EAP
authentication with the peer, so how can it do that?

> > > > > > No.  The only real difference between the scheme I am
> proposing
> > > and
> > > > > the
> > > > I'm not claiming that it did; what I am claiming is that the
> scheme
> > > > fits the
> > However, the terminology used in RFC 5247 is terribly flawed.  Just
> to
> > start
> > one extends the term to include the AAA subsystem and the interface
> to
> > which
> > the SA a "serving attachment point" in the [P->SA->CA->AAA] case).
> How
> > does
> But I think you are just picking on wording. 

Yes, words are so unimportant in standards ;->.  Actually, I'm trying
(apparently in vain) to start a technical debate by describing how EAP
actually works, as opposed to continuing a terminological discussion that
seems to be rapidly degenerating to the level of "How many authenticators
can dance on the head of a pin"..  

> It is *obvious* that the

I see.  So the _informative_ reference to a conference paper is important --
defining, in fact -- but the _normative_ reference to an IEEE standard is
just "unfortunate"?  Or could it be that (as RFC 5247 explicitly states
(there I go, getting all "literal" again ;-)) that the reference to
8021XPreAuth is meant to provide an example of preauthentication as used in
802.11?

> "EAP pre-auth". 

No.  I don't see any EAP authentication in your example.  Maybe I need to
make it even clearer: in the scheme I'm talking about (I'll have suggested
text to add to the draft soon, maybe that will help things), all of the
phases mentioned in section 1.3 of RFC 5247 take place.

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 9 Jan 2009 15:14:37 +0200

Glen,

> authentication with the peer, so how can it do that?

Now I understand your question, thank you.

There are multiple different ways. Here is one:

(Assuming you are using PANA) P discovers the IP address of the CA (e.g.,
via IEEE 802.21, DHCP, etc.) P sends PANA-Client-Initiation (PCI) message to
CA. Note that PCI does not carry EAP, but it triggers the CA to initiate
EAP. In response to PCI received from P, CA sends first PANA message that
carries an EAP-Request.

Alper

> -----Original Message-----
> From: Glen Zorn [mailto:[email-masked]]
> Sent: Friday, January 09, 2009 12:16 AM
> To: 'Alper Yegin'
> Cc: [email-masked]
> Subject: RE: [HOKEY] Is peer-SA-AAA-CA model EAP pre-authentication?
> 
> > > with, there is, as you know, no such thing as "EAP keying
> material":
> > > keying
> > > point" (just as it might be more appropriate for present purposes
> to
> > > call

---

From: Rafa Marin Lopez <[email-masked]>
Date: Fri, 09 Jan 2009 17:56:12 +0100

Hi Qin,
> 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 view…
[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)."

However, in the model peer-SA-AAA-CA, the CA is NOT acting as EAP authenticator at all. 

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: 

"EAP pre-authentication differs from a normal EAP conversation primarily with respect to the lower-layer encapsulation."

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.

>> 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?
> [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 
[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] 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 provi…
[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.

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?.
> 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 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?

In any case, I would really appreciate that you provide some reference.
> inter-authenticator handover case. It is a  totally new scenario, new case. Therefore new feature for this model(Peer-SA-CA-AAA)should be considered. 
[Rafa] To me, this is wrong. For example, as you may know, IEEE 802.11 
implements the model peer-SA-CA-AAA with no change to EAP. So it follows 
RFC 4137. Thus, to me, your assumption that RFC 4137 needs to be 
modified is wrong. The model peer-SA-CA-AAA does not change anything 
about EAP. The RFC 4137 explains EAP state machines and clearly mentions 
that lower layer activates the EAP authenticator state machine. Yes, and 
that precisely happens in IEEE 802.11 EAP pre-authentication 
(peer-SA-CA-AAA model) with the CA.
> [Qin] I can not believe the state machine for the authenticator does not make any change for the inter-authenticator handover is considered here.
[Rafa] Please see all my comments above. In any case, if you cannot 
believe it, please explain and prove the opposite.

<snip>
> is the solution scope I guess. Also it is not appropriate for me to figure out each solution in each model at this time.
[Rafa] Unfortunately, without specific technical details is going to be 
very hard to agree.

<snip>
> How could you understand the model(peer-SA-AAA-CA) should apply for the proactive key distribution mechanisms?
[Rafa] Please, see the definitions I provided at the beginning of this 
e-mail.

<snip>
> [Qin] yeah, you are right. Because the model(Peer-SA-CA-AAA) focus on inter-authenticator handover issue. New feature is required i think.
[Rafa] I believe you misunderstood what I said:

"I don't think that RFC 4137 needs to be modified in any 
manner in order to the model peer-SA-CA-AAA operate"

So, NO modification and NO new feature is required to me :).  

> [Qin] What i said here is RFC 4137 does not consider inter-authenticator handover issues. So RFC4137 does not support to make the SA to activate CA run state machine.
[Rafa] RFC 4137 is general enough to support EAP pre-authentication 
(peer-SA-CA-AAA to me) without modification basically because (from RFC 
5247):

"EAP pre-authentication differs from a normal EAP conversation
   primarily with respect to the lower-layer encapsulation"

> [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. 
[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.

Best Regards.

---

From: Rafa Marin Lopez <[email-masked]>
Date: Fri, 09 Jan 2009 18:10:35 +0100

Hi Glen,
> phases mentioned in section 1.3 of RFC 5247 take place.
It seems you're ignoring an important fact in the peer-SA-AAA-CA model. 
According to EAP Key Management (RFC 5247) and, in particular, the 
section 1.3 that you mention, the authenticator that acts as EAP 
authenticator in an EAP conversation is the one that receives the keys 
(e.g. MSK).

In the model peer-SA-AAA-CA, the CA is NOT acting as EAP authenticator 
in the EAP conversation that you mention. Since CA is NOT acting as EAP 
authenticator, the AAA has to proactively send (push) a key to the CA 
before the handoff.

In fact, you're trying to justify that this model is EAP 
pre-authentication based on the general thought: "all of the phases 
mentioned on 1.3 of RFC 5247 take place".

Unfortunately, this is a really weak justification to me and not 
accurate. Yes, all the phases must happen, but that is NOT enough. You 
forgot to mention that the proposal MUST BE coherent with key 
distribution in EAP (e.g. Fig. 1 in section 1.3 is really clear about 
that): the authenticator that acts as EAP authenticator in an EAP 
conversation is the one that receives the keys.

However, in the peer-SA-AAA-CA model, the authenticator involved in the 
EAP authentication as EAP authenticator is the SA!!!, however it is the 
CA (which has NOT participated in the EAP authentication) the one which 
proactively receives the key!!!.

Therefore, to me, it is NOT a very convincing argument ("all of the 
phases mentioned in section 1.3 of RFC 5247 take place") to categorize 
peer-SA-AAA-CA model as EAP pre-authentication. At least, it is NOT 
convincing for me at all.

Best Regards.