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

From: Qin Wu <[email-masked]>
Date: Wed, 04 Feb 2009 16:51:41 +0800

Hi,Rafa:
Thank for your clarification. Please see my followup comments!
Best regards!
-Qin
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Rafa Marin Lopez
> Sent: Saturday, January 10, 2009 12:56 AM
> To: Qin Wu
> Cc: [email-masked]
> 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: [email-masked]
> ------------------------------------------------------
> 
> _______________________________________________
> HOKEY mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hokey

---

From: Rafa Marin Lopez <[email-masked]>
Date: Wed, 04 Feb 2009 18:05:02 +0100

Hi Qin,
> [Qin] That's your understanding,
[Rafa] Well, it seems that (e.g.) IEEE 802.11i EAP pre-authentication 
design has the same understanding than mine ;).
> To me,the SA and CA in all the model are acting as EAP authenticator.
> SA still plays the role of authenticator to perform EAP exchange with the peer.
[Rafa]. I am sorry but this is simply wrong. Let me repeat again 
(section 4.1 , RFC 5247)

Therefore in EAP pre-authentication involves an EAP authentication, 
where we find: only one EAP peer, only one authenticator acting as EAP 
authenticator and only one EAP server (see Fig.1 in RFC 5247). For 
example, in the peer-SA-CA-AAA model you have:  peer(EAP peer), CA(EAP 
authenticator), AAA(EAP server), where the SA is NOT performing any EAP 
authenticator state machine because basically "the SA is an entity that 
carries EAP between the peer and the CA during an EAP authentication".

Now you're claiming that there are two entities (SA and CA) acting, at 
the same time, as EAP authenticators :|. This is completely mistaken.

On the other hand, we had already agreed that peer-SA-CA-AAA is EAP 
pre-authentication. In that model what I can tell you is that SA is NOT 
acting as EAP authenticator in the EAP conversation (see an example in 
IEEE 802.11i below), and there is only one authenticator acting as EAP 
authenticator involved during the EAP authentication: the CA.

> When the peer moves from the SA to the CA,
> [Qin]:In this scenario,SA can act as EAP authenticator.
[Rafa] Yes, only in the peer-SA-AAA-CA model, SA is acting as EAP 
authenticator, but the CA receives the keys. Or in other words, 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.

According to EAP Key Management (RFC 5247) and, in particular, section 
1.3, 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. Since CA is NOT acting as EAP authenticator, the AAA has 
to proactively send (push) a key to the CA before the handoff.

Moreover, taking into account that "EAP pre-authentication differs from 
a normal EAP conversation primarily with respect to the lower-layer 
encapsulation.", I would really expect of a so-called EAP 
pre-authentication process, that the authenticator acting as EAP 
authenticator in the EAP conversation receives the keys. That clearly 
happens in the peer-SA-CA-AAA model where in the EAP conversation, peer 
is the EAP peer, the CA is acting as EAP authenticator and the EAP 
server is placed on the AAA; and CA receives the keys. Unfortunately, 
that DOES NOT happen in the peer-SA-AAA-CA model at all where the CA, 
which is NOT acting as EAP authenticator in any EAP conversation, 
proactively receives a key.

>  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. 
[Rafa] What model are you talking about when you say that SA is acting 
as the EAP authenticator? I assume the model peer-SA-AAA-CA since, in 
the model peer-SA-CA-AAA , the SA is NOT acting as EAP authenticator but 
the CA.
> 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?
>   
[Rafa] Please see my comments above and below :).
> [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 sec…
[Rafa]. To me, the text is pretty clear. Please, read carefully again:

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

This is related to your comment "lower-layer mechanism in section 4.1 of RFC5247 has nothing to do with pre-authentication". This is incorrect. In order to clarify things, let me encourage you to read IEEE 802.11i EAP pre-authentication as an example (section 8.4.6.1 in IEEE 802.11i spec.). There you can read, "Preauthentication uses the IEEE 802.1X protocol and state machines with EtherType 88-C7" (that is, lower-layer support) and the peer starts the EAP pre-authentication with the target AP (CA) by using EAPOL-Start, where "the AP with which the STA is currently associated" ([Rafa]: That is, the SA)) "need not apply any special handling".

Yes, IEEE 802.11i EAP pre-authentication matches with the text in RFC 5247.

> [Qin] Do you mean PANA or AAA can be viewed as the lower-layer encapsulation?
see section 2.2 in RFC 3748.
[a] Lower layer.  The lower layer is responsible for transmitting and
       receiving EAP frames between the peer and authenticator.

AAA is not lower layer.
> 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.
[Rafa] If you don't think so, you should say that RFC 5247 is wrong. Is 
that what you think?.
In any case, under you point of view, what is the key difference?
> The reason is even for the basic model peer-authenticator-AAA, the lower-layer encapsulation will also be used to transport EAP packets.
>   
[Rafa] Yes, but in pre-authentication process, the EAP lower-layer can 
give assistance to the EAP pre-authentication process. Please see for 
example IEEE 802.11i: "Preauthentication uses the IEEE 802.1X protocol 
and state machines with EtherType 88-C7".

In this way, EAP itself does NOT need any modification, and the EAP 
lower-layer gives support to the pre-authentication 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.
[Rafa]. Please, give the detail perspective that makes you be in 
disagreement.

>  always emphasize it is CA to run EAP exchange?
[Rafa] The CA is the one that must receive key material. In EAP key 
management model, that entity that acts as EAP authenticator in the EAP 
conversation receives the key material. If the CA is NOT acting EAP 
authenticator (as happens in peer-SA-AAA-CA model) does NOT receive any 
key, and other key distribution is needed, for example proactively 
PUSHING a key to the CA. Since EAP pre-authentication differs from a 
normal EAP conversation primarily with respect to the lower-layer 
encapsulation, the EAP key management described in RFC 5247 still 
applies for EAP pre-authentication, where the authenticator acting as 
EAP authenticator must receive the key material. That DOES NOT happen in 
the peer-SA-AAA-CA model.
>  Who tell the CA to run EAP exchange? When to tell the CA to run EAP exchange?
[Rafa]. See an example in IEEE 802.11i.
> I never doubt key materials can be distributed from AAA to the authenticator.
[Rafa] Again your comment "key management happens after sucessful 
pre-authentication" is not precise. Your sentence has more details 
behind. Have you read what I have written?. Please read it again 
carefully and see fig.1 in RFC 5247.

"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]It is easy to make AAA allocate key materials to the CA after success pre-authentication between the peer and AAA server.
[Rafa]. Please see fig.1 in RFC 5247 and all my previous explanation.
> This pre-authentication process obeys the basic EAP protocol RFC3748.
>   
[Rafa]. In peer-SA-AAA-CA model, this is INCORRECT :(. Please, take a 
careful look to both RFC 5247 and RFC 3748.
> carry the EAP message in AAA message and send AAA message to the EAP server.
[Rafa] Yeah, what I meant was EAP Request/Id.

So you said

"AAA activate the CA eap state machine. If my memory is 
correct, it does exists".

And let me rephrase my question:

where will the "EAP Request/Id" coming from the CA travel to?.

Btw, can you send a reference about AAA activating the CA eap state 
machine?.
> [Qin]I have known your perspective and conclusion. However I can not see any concrete reasons to kill it.
[Rafa]. so can I conclude from your comment that you agree with my 
perspective?.
> 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. 
>   
[Rafa] I don't see an issue there. The lower-layer activates the CA to 
start EAP authentication involved in the EAP pre-authentication. About 
who is activating the CA in the EAP pre-authentication, you have a few 
examples (Alper gave one), I gave another: IEEE 802.11i, please read it.

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: [email-masked]
------------------------------------------------------

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 17 Feb 2009 20:14:16 +0700

Rafa Marin Lopez [mailto:[email-masked]] writes:

> > It depends how you understand the role of SA and CA in different
> situations.e.g., before the peer moves to the CA,

OK, so speaking as WG Chair, this endless interpretation of RFC 5247 is
useless & worse, counterproductive.  This WG isn't bound to the limited
taxonomy given in 5247: we are free to define "hokey preauthentication" in
any way we wish, as long as the result is secure, efficient, implementable
and, most of all, useful.  It would also be nice if we could build our
previous work (e.g., ERP).  Therefore, I'd like to see a stop to this
quasi-religious nonsense & the beginning of some actual _technical_
discussion around Qin's proposal, beginning with a coherent and detailed
discussion of what that proposal actually is & how it would work.

...

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 17 Feb 2009 16:12:12 +0200

Glen,

> and, most of all, useful.  

This is same as saying "any optimization solution that is secure, efficient,
implementable, useful and that has EAP relevance" can be called
"pre-authentication", or can be simply standardized by Hokey WG. There is a
purpose to define scope when chartering WGs. Going out of that scope, or
interpreting that scope loosely (like in your suggestion of giving the WG
the power to redefine "hokey pre-auth anyway we wish") is a recipe to
attract boundless ideas and proposals to the WG. 

I think a better way would be to deliver on the current charter. And later,
if people want to extend the charter to work on other work items, we can
re-charter. Why are we not doing that? 

Alper

> It would also be nice if we could build our

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 19 Feb 2009 14:16:41 +0700

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

> > taxonomy given in 5247: we are free to define "hokey
> preauthentication"
> > in
> "pre-authentication", 

Incredible as it may seem, my request to end the interminable debate over
the jots & tittles of RFC 5247 was not an invitation to begin another on the
interpretation of our charter ;-).

> or can be simply standardized by Hokey WG. There
> is a

What a horrible thing _that_ would be!

> re-charter. Why are we not doing that?

The IESG has given us a fair amount of leeway WRT charter interpretation
thus far (for example, in allowing the development of ERP which some
(including myself) have argued is not EAP at all), but I'm sure that they'll
let me know if I'm getting out of line ;-).  That said, I suppose that we
could begin to interpret the charter strictly now.  However, in that case
I'm afraid that we would have to instruct the editor to remove the section
on indirect preauthentication from the draft because the charter says that
"EAP re-authentication and EAP pre-authentication authenticator are expected
to use the same layer and the same protocol as the original EAP
authentication used for the 
authenticator" & it's pretty clear that indirect preauth (as defined) would
have to use L3.  While it might be possible to run ERP over L3 (i.e., PANA)
for reauthentication that would at least double the amount of overhead
involved, defeating the purpose.  OTOH, it also states that the (preferred)
use of AAA protocols for the "reactive or proactive distribution or
retrieval of keys by the proper entities" is explicitly in scope, so it
appears that the model that you're trying every trick in the book to kill
(though I have no idea why) is in scope, too, whether one wishes to call it
"preauthentication" or not.

...

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 19 Feb 2009 11:04:10 +0200

> > > OK, so speaking as WG Chair, this endless interpretation of RFC
> 5247
> > is
> > interpreting that scope loosely (like in your suggestion of giving
> the
> > WG

Indeed, as anyone who dealt with "standardizations of performance
optimizations" would already know...

> let me know if I'm getting out of line ;-).  

So, does Hokey WG have a special permit to stretch the charter in any way it
likes?

> That said, I suppose that
> we
> have to use L3.  

No. 

L2 pre-auth can be tunneled between the SA and CA. Hence L2-only indirect
pre-auth is very well possible.

> While it might be possible to run ERP over L3 (i.e.,
> PANA)

First of all, I'm not trying to kill the model. I'm saying it is one of
those other 1,000,000 possible optimizations that happens to fall outside
the scope of this WG. It can be done, but elsewhere or at another time
(after rechartering). 

I don't know what trick you are talking about. I, like many other people
(except only you, and the owner of the proposal), are arguing that the work
does not fit the scope of WG. 

And now you are saying that model shall be standardized because it fits
"reactive or proactive distribution or retrieval of keys by the proper
entities"?? Oh, what doesn't fit that? Everything that has something to do
with key-generating EAP methods :)

Alper

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 19 Feb 2009 17:01:20 +0700

...

> pre-auth is very well possible.

You are right, of course -- my mistake.  There is no end to the levels of
complexity that could be introduced...

> the scope of this WG. It can be done, but elsewhere or at another time

But we're not talking about a million other things, we're talking about one.

> does not fit the scope of WG.

I beg to differ: the last months of debate have been over the meaning of
"preauthentication" & the nuances of RFC 5247; the "not in the charter" tack
is a new one.

---

From: Rafa Marin Lopez <[email-masked]>
Date: Thu, 19 Feb 2009 12:56:07 +0100

Hi Glen
> "preauthentication" & the nuances of RFC 5247; 
Due to the continuous & unfortunate attempt of qualifying peer-SA-AAA-CA 
model as EAP
pre-authentication.

Best Regards.

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 19 Feb 2009 12:08:15 -0800 (PST)

Hi Glen,

> discussion of what that proposal actually is & how it would work.

  Could we possibly use a different term than "preauthentication"
which already has a specific meaning that is different than what you're
describing as "hokey preauthentication"?

  regards,

  Dan.

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 20 Feb 2009 15:38:13 +0700

> Due to the continuous & unfortunate attempt of qualifying peer-SA-AAA-

I think that the most unfortunate thing was that the arguments were (for me,
anyway) virtually impossible to follow.  So, in an effort to gain a little
closure here, would you mind summarizing your _technical_ arguments that the
peer-SA-AAA-CA model is not EAP pre-authentication?  I'd like to see some
direct & pertinent quotes from RFCs, preferably containing the word "MUST"
:-).

...

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 20 Feb 2009 00:57:35 -0800 (PST)

Hi Glen,

  The term "pre-authentication" is used in 802.11 to describe something
that is different than what you're talking about. It's not an RFC but
it is an internationally recognized standard (in the form of ISO/IEC
8802-11.2005 plus amendments).

  I hope you don't discount this reference because it is 802.11 that is
creating a need for hokey. EAP on a dial-up line or EAP on a wired jack
just doesn't have the necessary mobility to create a handover problem.
I don't think we can avoid 802.11 in this WG and I don't think we should
re-use a term from 802.11 to describe something different in hokey.

  Dan.

---

From: Qin Wu <[email-masked]>
Date: Fri, 20 Feb 2009 17:23:21 +0800

Hi, Dan:
I have to say pre-authentication is not limited to 802.11 scenario, in the problem statement of draft-ietf-hokey-preauth-ps-05, it points out the limitation of 802.11 based pre-authentication mechanism is that it is not applicable for inter-technology handover or inter-access-domain handover. So more preauthentication mechanisms on inter-technology handover or inter AAA-domain handover are required. That is one key motivation to develope this drafts. 
Also pre-authentication mechanism is complementary to re-authentiction mechanism as this draft emphasized. As we know, re-authentication has been widely implemented in 3G scenarios,e.g, WiMAX mobile network, 3GPP mobile network. But for the hetergeneous handover scenarios, Re-authentication has its limitation. That's why we try to develope pre-authentication to solve this issue. So for the inter-technology support, it is not necessary to limit our applicability in 802.11.
-Qin

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 20 Feb 2009 16:26:47 +0700

> 8802-11.2005 plus amendments).

Unfortunately, 802.11 use the term "authenticator" to mean something
different than what is meant in EAP (almost always the Authenticator PAE
IIRC), too.  This seems to confuse some people...

> creating a need for hokey. 

Actually, I believe that the first to specify the use of hokey technology
(ERP) were the 3G folks.  But your statement kind of puzzles me: since, as
you point out, 802.11 already has a preauth method, why would they need us
to define another?  I would imagine that our work might be of much more
interest amongst the "break before make" handover 3G guys.

> EAP on a dial-up line or EAP on a wired jack

Maybe not; unfortunately, since we can't really bridge frames & have no DS,
it might be hard use the term in exactly the same way ;-).

...

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 20 Feb 2009 09:58:35 -0800 (PST)

Hi Qin,

  The thing that 802.11 calls "pre-authentication" may not be useful for
everyone everywhere. I'm not debating that. And I'm not saying that
development of this draft should not proceed. I'm just saying that we
should not call this "pre-authentication", even with a "hokey" qualifier,
since that word has a certain connotation.

  Dan.

On Fri, February 20, 2009 1:23 am, Qin Wu wrote:
> Hi, Dan:
> I have to say pre-authentication is not limited to 802.11 scenario, in the
> problem statement of draft-ietf-hokey-preauth-ps-05, it points out the
> limitation of 802.11 based pre-authentication mechanism is that it is not
> applicable for inter-technology handover or inter-access-domain handover.
> So more preauthentication mechanisms on inter-technology handover or inter
> AAA-domain handover are required. That is one key motivation to develope
> this drafts.
> Also pre-authentication mechanism is complementary to re-authentiction
> mechanism as this draft emphasized. As we know, re-authentication has been
> widely implemented in 3G scenarios,e.g, WiMAX mobile network, 3GPP mobile
> network. But for the hetergeneous handover scenarios, Re-authentication
> has its limitation. That's why we try to develope pre-authentication to
> solve this issue. So for the inter-technology support, it is not necessary
> to limit our applicability in 802.11.
> -Qin
>>>> > I beg to differ: the last months of debate have been over the
>>>> meaning
>>>> of
>>> I think that the most unfortunate thing was that the arguments were
>>> (for
>>> me,
>>> closure here, would you mind summarizing your _technical_ arguments
>>> that
>>> the

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 20 Feb 2009 10:06:29 -0800 (PST)

Hi Glen,

> IIRC), too.  This seems to confuse some people...

  You may be mixing 802.11 with 802.1. But it doesn't really matter since
it's not particularly germane to the discussion.

> interest amongst the "break before make" handover 3G guys.

  And bully for the 3G folks.

  802.11 doesn't have a "preauth method" they have a way to encapsulate
EAP frames over the DS to allow a peer to authenticate directly to an
authenticator. I don't think 802.11 needs hokey to define anything for it.
That is really not my point. My point is that there is this thing called
"pre-authentication" and it is different than what is being called
"pre-authentication" in hokey and I think hokey should not abuse that
term.

> it might be hard use the term in exactly the same way ;-).

  Right, we can't use the term in the same way. So let's not try. Let's
use a different term.

  Dan.

---

From: "Glen Zorn" <[email-masked]>
Date: Sat, 21 Feb 2009 10:20:42 +0700

Dan Harkins [mailto:[email-masked]] writes:

>   You may be mixing 802.11 with 802.1. 

That's what .11 does, too.

> But it doesn't really matter
> since

My point is that 802.11 uses a term that was previously defined by both
802.1X & RFC 2284 to identify a set of functionality significantly different
than either.  Is that not germane to the discussion?

> EAP 

802.1X

> frames over the DS to allow a peer to authenticate directly to an

I can't feature allowing the IEEE to hijack the entire English language but
OTOH it might make sense to clearly delineate our work from 802.11.

> > Maybe not; unfortunately, since we can't really bridge frames & have
> no
> > DS,

OK, what shall we call it?

---

From: "Dan Harkins" <[email-masked]>
Date: Sun, 22 Feb 2009 00:55:33 -0800 (PST)

Hi Glen,

> than either.  Is that not germane to the discussion?

  It's germane if you want to say "but they do it too!" If 802.11 is
using a term that was defined somewhere else prior to 802.11's use of it
and for a different functionality then that's not very good and I think
you agree.

  The only way it's germane to the discussion is if you think that
two wrongs make a right.

> OTOH it might make sense to clearly delineate our work from 802.11.

  Well if "pre-authentication" was the only word in the English language
then I guess you're right. But what language are we communicating in?
It's English, isn't it?

> OK, what shall we call it?

  We can call it "pro-active key distribution" or "glen" or maybe we can
call it "kerberos" (provided that no other standards body has hijacked
the entire English language, that is). Anything but "pre-authentication".

  Dan.

---

From: Rafa Marin Lopez <[email-masked]>
Date: Tue, 24 Feb 2009 01:15:14 +0100

Hi Glen,
> would you mind summarizing your _technical_ arguments that the
> peer-SA-AAA-CA model is not EAP pre-authentication?  
My intention in all e-mails that I have sent to this list was to provide
technical arguments. My apologies if I failed in any moment.

Anyway, of course, I don't mind summarizing:

a) During an EAP authentication, the authenticator acting as EAP
authenticator (in pass-through mode)
receives the key material (e.g. MSK) from AAA (phase 1b).

References: RFC 5247. section 1.3. More details e.g. RFC 4137 (Fig. 7): 
the EAP authenticator state machine in pass-through mode receives
keys (aaaEapKeyData) from the AAA server.

b) EAP pre-authentication differs little from the model in section 1.3

References: RFC 5247. Section 4.1

"As a result, an EAP pre-authentication conversation differs little from
the model described in Section 1.3,
other than the introduction of a delay between phase 1 and phase 2."

In fact, and I apologize to mention this again, but basically "EAP
pre-authentication differs from a normal EAP conversation primarily with
respect to the lower-layer encapsulation" (literally extracted from RFC
5247). So at EAP level conversation and key management, the procedure is
the same : there is a peer (EAP peer) , one authenticator acting as EAP
authenticator which receives the key material, and the EAP server in the 
AAA server. The differences appear at lower-layer level. That is why 
e.g. IEEE 802.11 EAP pre-authentication does not need to change the EAP 
model to implement EAP pre-authentication.

In the peer-SA-AAA-CA model, the SA acts as EAP authenticator. In this
way, according to RFC 5247, the SA should receive the key material (e.g.
MSK). However, that is not useful, right?, because we want to have a key
in CA. Therefore, the peer-SA-AAA-CA model requires to proactively push
a key to the CA, which basically is not acting as EAP authenticator.

Therefore in the case peer-SA-AAA-CA model, the key management differs
NO little from the model in section 1.3 of RFC 5247. In fact, basically
we need a new key management and distribution for the peer-SA-AAA-CA
model. So, let's avoid to qualify this model as EAP pre-authentication 
and choose some more suitable term.

Best Regards.

---

From: Rafa Marin Lopez <[email-masked]>
Date: Tue, 24 Feb 2009 01:26:08 +0100

> the entire English language, that is). Anything but "pre-authentication".
Completely agree. My vote would be for "pro-active key distribution".

---

From: Tom Taylor <[email-masked]>
Date: Mon, 23 Feb 2009 19:37:12 -0500

OK, just to be clear, you're not saying the configuration is invalid, only that 
the name collides with a procedure and architecture that are distinctly 
different. Also, they will both achieve the same result: authorization of access 
with reduced delay at the actual time of handover.

---

From: Ashutosh Dutta <[email-masked]>
Date: Mon, 23 Feb 2009 20:04:41 -0500

The term "pro-active key distribution" for this mechanism sounds reasonable.

Thanks
Ashutosh

---

From: Tom Taylor <[email-masked]>
Date: Mon, 23 Feb 2009 20:10:39 -0500

The point of my question to Rafa was to determine whether we can find a term 
that encompasses all approaches to the same objective, which is minimization of 
the component of handover delay caused by authentication and authorization.

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 24 Feb 2009 10:22:47 +0700

> Completely agree. My vote would be for "pro-active key distribution".

Just to be clear, my understanding is that Dan's comment refers to the
schemes already incorporated in the draft as well as the peer->SA->AAA->CA
scheme being debated, since none but indirect preauth bear even the
slightest resemblance to 802.11 preauthentication.

...