Subject: [HOKEY] I-D Action:draft-ietf-hokey-preauth-ps-06.txt

From: [email-masked]
Date: Mon, 9 Mar 2009 00:00:01 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Handover Keying Working Group of the IETF.

	Title           : EAP Pre-authentication Problem Statement
	Author(s)       : W. Wu, Y. Ohba
	Filename        : draft-ietf-hokey-preauth-ps-06.txt
	Pages           : 19
	Date            : 2009-03-08

EAP (Extensible Authentication Protocol) pre-authentication is
defined as the use of EAP to pre-establish EAP keying material on a
target authenticator prior to arrival of the peer at the access
network managed by that authenticator.  This draft discusses EAP pre-
authentication problems in detail.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-hokey-preauth-ps-06.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Qin Wu <[email-masked]>
Date: Mon, 09 Mar 2009 15:10:48 +0800

Hi,

I have just submitted a new version for "EAP Pre-authentication Problem Statement"
<draft-ietf-hokey-preauth-ps-06>. The URL for this internet draft is:
http://www.ietf.org/internet-drafts/draft-ietf-hokey-preauth-ps-06.txt

The changes to the previous 05-version are mainly based on the open discussion in the maillist.
Most of them are pure editorial changes including some terminology change,ambiguity elimination and 
coherence improvement.The scope of this draft focuses on inter-technology handover or inter-AAA-
domain handover.

Besides, the usage scenarios in the section 4 of the draft is restructured into usage models to accommodate the third usage model.

I would like to request all previous contributors to this draft to check
whether they feel their content is still presented in the intended way.

Comments from all the contributors as well as anybody else who is interested in this topic are highly appreciated. 

Best regards,
Qin
----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, March 09, 2009 3:00 PM
Subject: [HOKEY] I-D Action:draft-ietf-hokey-preauth-ps-06.txt

> Author(s)       : Q. Wu, Y. Ohba

--------------------------------------------------------------------------------

> _______________________________________________
> HOKEY mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hokey
>

---

From: Qin Wu <[email-masked]>
Date: Mon, 09 Mar 2009 15:14:45 +0800

Hi,

Best regards,
Qin

---

From: Rafa Marin Lopez <[email-masked]>
Date: Mon, 09 Mar 2009 09:30:52 +0100

Hi Qin,

I must deeply check the new document but I have seen section 4.3. My 
question is: why has been peer-SA-AAA-CA model included in the draft 
titled "EAP Pre-authentication Problem Statement" when it is NOT EAP 
pre-authentication? Is there any consensus to this respect?. I have 
checked the HOKEY ML archive and I think I have not missed any e-mail. I 
already gave my vote to NOT call peer-SA-AAA-CA model as EAP 
pre-authentication. And I provided technical (summarized) comments in

http://www.ietf.org/mail-archive/web/hokey/current/msg01390.html

Thanks.

-- 
------------------------------------------------------
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: Qin Wu <[email-masked]>
Date: Mon, 09 Mar 2009 20:40:15 +0800

Hi,Rafa:
Thank for your quick feedback. This new version draft has  not become a baseline draft which needs to be consented in the IETF74 hokey working group meeting.
As regarding the debate on the model peer-AAA-CA,  my points are
1.This model is quite useful when there is no trust relationship between the SA and CA. It will be complementary to the model peer-SA-CA-AAA which requires the anticipated trust relationship between the serving network and candidate network. 

2. On the other hand, the key management is a integral part of pre-authentication. All existing key management mechanism can be reused here. Why do we need to separate the key management from pre-authentication?

3. Also part of experts in the ML actually didn't oppose to consider the model Peer-SA-AAA-CA except the terminology usage scope if my understanding is correct.
If possible, I would like to request a slot to make clarification in the face to face meeting. Thanks for your understanding,:)

Best regards!
-Qin

---

From: Rafa Marin Lopez <[email-masked]>
Date: Mon, 09 Mar 2009 15:38:12 +0100

Hi Qin, thanks for the answer.

First of all, I would like to say that I already considered (some time 
ago) the peer-SA-AAA-CA model as a valid alternative to reduce access 
time. What I don't understand is why peer-SA-AAA-CA model is included in 
the EAP Pre-authentication Problem Statement I-D when peer-SA-AAA-CA 
model is not EAP pre-authentication.

Please see below for additional comments.

> 2. On the other hand, the key management is a integral part of pre-authentication. All existing key management mechanism can be reused here. Why do we need to separate the key management from pre-a…
[Rafa] You have formulated this question several times. And my answer 
has been always the same. If possible, I would appreciate if you read a 
recent answer in

Maybe then, you will notice that peer-SA-AAA-CA model cannot be 
categorized as EAP pre-authentication due to that, precisely, the key 
management required for peer-SA-AAA-CA model is different than the one 
defined for EAP pre-authentication.

I am not against to discuss peer-SA-AAA-CA model as an alternative to 
reduce the network access time. But including peer-SA-AAA-CA model in a 
draft that talks about EAP pre-authentication is simply wrong.
> 3. Also part of experts in the ML actually didn't oppose to consider the model Peer-SA-AAA-CA except the terminology usage scope if my understanding is correct.
[Rafa] The problem is more serious than only terminology. EAP 
pre-authentication as defined in RFC 5247 applies the EAP Key Management 
model. The peer-SA-AAA-CA applies a completely different key management 
and distribution model.

As far as I know, there was no consensus to qualify peer-SA-AAA-CA model 
as EAP pre-authentication. We can discuss about peer-SA-AAA-CA model and 
try to put a name to this model (my vote is proactive key distribution). 
However, I believe that including peer-SA-AAA-CA model in a draft titled 
"EAP Pre-authentication Problem Statement" is not the solution, taking 
into account peer-SA-AAA-CA cannot be categorized as EAP 
pre-authentication.

I was also wondering why this model cannot be included in a separate 
document called "Proactive Key Distribution Problem Statement" and leave 
"EAP Pre-authentication Problem Statement" with the previous scenarios. 
Is there any problem with that?

Best Regards.

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 9 Mar 2009 17:05:23 +0200

Qin,

> Thank for your quick feedback. This new version draft has  not become a
> baseline draft which needs to be consented in the IETF74 hokey working
> group meeting.

Sorry, it does not work that way.

When "so many people repeatedly" stated that what you have is not EAP
pre-auth and it is not in scope of this document and not even the WG
charter, you shall not include it in the official WG draft.

Thank you.

Alper

---

From: Ashutosh Dutta <[email-masked]>
Date: Mon, 09 Mar 2009 11:20:59 -0400

Hi Qin,

    I agree with Rafa here. I have also been following the mailing list 
discussion and there has not been any consensus on including 
peer-SA-AAA-CA model as part of "EAP Pre-authentication Problem 
Statement" draft. On the other hand, from the mailing list discussion, 
there appears to be general suggestion to consider this specific case 
(peer-SA-AAA-CA) separate from EAP-Pre-authentication Problem Statement 
and treat it as something like "proactive key distribution". It 
definitely warrants more discussion.

Since this could be a valid deployment scenario, having a separate 
document to take care of this scenario could probably be a good alternative.

Thanks
Ashutosh

>> 3. Also part of experts in the ML actually didn't oppose to consider 
>> the model Peer-SA-AAA-CA except the terminology usage scope if my 
>> understanding is correct.
>>

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 9 Mar 2009 16:14:35 -0700

> > Thank for your quick feedback. This new version draft has  not become
> a baseline draft which needs to be consented in the IETF74 hokey
> working group meeting.
> > 1.This model is quite useful when there is no trust relationship
> between the SA and CA. It will be complementary to the model peer-SA-
> CA-AAA which requires the anticipated trust relationship between the
> serving network and candidate network.
> >
> > 2. On the other hand, the key management is a integral part of pre-
> authentication. All existing key management mechanism can be reused
> here. Why do we need to separate the key management from pre-
> authentication?
> >

Your claim seems to be that RFC 5248 is both exhaustive and=d exclusive
(i.e., that there is no possibility that a form of EAP pre-authentication
that is not listed in that document.  This is what I would call a religious
argument: we have the holy, infallible book which any right-thinking person
will interpret in the same way (no matter what the  document actually says).
When I asked for a summary of your technical comments, that was not what I
had in mind.

> draft that talks about EAP pre-authentication is simply wrong.

No, it's not.

> model. The peer-SA-AAA-CA applies a completely different key management

There is no key transport in EAP.  Keys are exported by EAP methods.  How
they are actually delivered to those entities (by definition external to
EAP) that utilize the keys is outside the scope of EAP.

> into account peer-SA-AAA-CA cannot be categorized as EAP

More religion.
h
> Is there any problem with that?

One problem is that it doesn't fit the definition of "proactive key
distribution" in the holy book.

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 9 Mar 2009 16:20:10 -0700

> a
> When "so many people repeatedly" 

3

> stated that what you have is not EAP

Gosh, we seem to have a lot of volunteers for WG Chair!  There is no such
thing as an "official" Internet-Draft, whether it is a WG document or not.
If you wish to imagine that there is such a thing in the pana WG, you are
welcome to, but please keep your hallucinations to yourself.

---

From: Qin Wu <[email-masked]>
Date: Tue, 10 Mar 2009 12:13:12 +0800

Hi, Ashutosh:
Thank for your good suggestion. I will think it about to see whether we should merge or separate this specific case to the draft based on all the folk's opinions.

Best regards!
-Qin

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 10 Mar 2009 10:31:48 +0200

Glen,

> > When "so many people repeatedly"

Yoshi
Ashutosh
Rafa
Dan Harkins
Alper

Please do count accurately.

> welcome to, but please keep your hallucinations to yourself.

Huh? If you are going to discard WG member's objection to an idea and let it
slide into the WG document, what is the point of having a "WG"? Not sure who
is hallucinating, but this is not how IETF is supposed to work. Who does not
know that? Geez.....

Alper

---

From: Rafa Marin Lopez <[email-masked]>
Date: Tue, 10 Mar 2009 16:30:17 +0100

Hi Glen,
> When I asked for a summary of your technical comments, that was not what I
[Rafa] Well, the argument of considering peer-SA-AAA-CA model as EAP 
pre-authentication has been based on no technical comment (there have 
not been any single technical comment to justify this so far) or 
document. To me, this argument is certainly a matter of blind faith 
(talking about religion).

In http://www.ietf.org/mail-archive/web/hokey/current/msg01390.html I 
already provided my technical comments. My apologies if they are not 
what you had in mind, but the text I pasted is coming from RFC 5247.

In contrast, for peer-SA-AAA-CA model, I have not seen any technical 
justification to consider it as EAP pre-authentication.

Having said that, I have not mentioned that peer-SA-AAA-CA model should 
not be discussed as a valid alternative to reduce handoff time. To me, 
it may be a valid alternative. However, for some reason, there is a 
repeated intent of including peer-SA-AAA-CA model in a draft that talks 
about "EAP Pre-authentication Problem Statement". Actually, this is not 
only an intent but a fact, since it has been already included in the 
draft without any technical reason behind, and with the disagreement of 
part of this WG; that is, without consensus. Sincerely, I don't 
understand it.

>> draft that talks about EAP pre-authentication is simply wrong.
[Rafa] Let me disagree.
> EAP) that utilize the keys is outside the scope of EAP.
[Rafa] Again, it seems you ignore for example the MSK is sent to the 
authenticator acting as EAP authenticator (RFC 5247).
And the document RFC 5247 talks about Extensible Authentication Protocol 
(EAP) Key Management Framework. Maybe you're proposing that we should 
ignore it.
> distribution" in the holy book.
[Rafa] Ok no problem. Let's choose another name, but not EAP 
pre-authentication.

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 10 Mar 2009 09:29:01 -0700

Alper Yegin [mailto:[email-masked]]

> > > When "so many people repeatedly"

It's not at all clear to me that Dan's opinion did not apply to _all_ of the
methods, both your favorites & mine...

> is hallucinating, but this is not how IETF is supposed to work. Who

A single WG member's objection is, by itself, no reason to change anything.
I realize that you want your opinion to be declared to be WG consensus but
I'm rather interested in seeing what some people outside the choir have to
say...if it turns out that the WG really has less interest in technical
qualities & the mission of the WG than in the almost Talmudic dissection of
(deeply flawed) RFCs, so be it; I'm not altogether convinced of that,
though.

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 10 Mar 2009 10:19:35 -0700

> (talking about religion).

I fully understand how you may have forgotten (since it was so long ago) but
near the beginning of this debate I pointed out that the P->SA->AAA->CA
model conforms to the definitions of preauthentication in both sections 1.2
& 4 of RFC 5247; the response from you & Alper was (IIRC) along the lines of
'never mind what it _says_, this is what it _means_ (as any right-thinking
person can see)'.

> justification to consider it as EAP pre-authentication.

See above.

> authenticator acting as EAP authenticator (RFC 5247).

How is this possible, since there is no key transport in EAP?  In fact, the
key is either exported directly to an L2 entity (like the 802.11
authenticator, NOT the same as an EAP Authenticator) or to AAA.

> (EAP) Key Management Framework. Maybe you're proposing that we should

Actually, that document (along with RFC 4137) is so deeply flawed and
self-contradictory that I question whether it is salvageable.  I must admit
fault in this: the first few years of revisions of that draft were
incomprehensible & so I just sort of ignored it; when it was finally
published, I consoled myself with the thought that no person in their right
mind would pay any attention to it but apparently I was wrong again.

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 10 Mar 2009 21:50:22 +0200

> methods, both your favorites & mine...

  http://www.ietf.org/mail-archive/web/hokey/current/msg01389.html

  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.

> > > Gosh, we seem to have a lot of volunteers for WG Chair!  There is
> no
> > > such
> > > thing as an "official" Internet-Draft, whether it is a WG document
> or
> > > not.
> > > If you wish to imagine that there is such a thing in the pana WG,
> you
> > > are

Very colorful thinking and framing, thanks.

WG consensus has been in the WG document, all along.
A newcomer idea has to fit in there with support from the WG.
Anything short of that, the idea stays out. As simple as that.
Turning the IETF process upside down by first letting it in and then
expecting the forces to take it out is ..... (sigh, why are we discussing
such an obvious thing) It is wrong!

Alper

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 10 Mar 2009 14:37:15 -0700

>   the entire English language, that is). Anything but "pre-

What's your point?  The question is what 'it' means in the sentence "We can
call it...".

> > > > > pre-auth and it is not in scope of this document and not even
> the
> > > WG
> > > Huh? If you are going to discard WG member's objection to an idea
> and
> > > let it
> > I realize that you want your opinion to be declared to be WG
> consensus
> > but
> > I'm rather interested in seeing what some people outside the choir
> have
> > to

What's 'been in the draft all along' is what the former editor put there.

> such an obvious thing) It is wrong!

Since you very fond of quoting RFCs, perhaps you can quote one that
specifies the exact method that WG Chairs must use to determine WG
consensus?  Or is this another of those things that any right-thinking
person just knows?  It is possible that the modifications made are not
favored by the actual WG, in which case they will be taken out.  I suspect,
however,  that nobody else really cares about "EAP preauthentication" at
all, which really raises doubt in my mind about the validity of the draft as
a WG item.

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 11 Mar 2009 00:29:07 +0200

> What's your point?  The question is what 'it' means in the sentence "We

It is obvious to me that "it" is referring to the subject line of the whole
thread: "Is peer-SA-AAA-CA model EAP pre-authentication?"

> What's 'been in the draft all along' is what the former editor put

Wow, so how did that author hide that (or avoid WG backlash!) throughout the
whole 6 versions of the draft?!? Interesting theory.

> favored by the actual WG, in which case they will be taken out.  

Why are we taking that path, can you explain -- when there are repeated
objections from several members of WG, with no support for inclusion (except
for the WG chair's)? 

> I
> suspect,

Yeah, if we (dis)count the WG feedback the way you are counting.....

Alper

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 10 Mar 2009 15:52:19 -0700

> > >   We can call it "pro-active key distribution" or "glen" or maybe
> we
> > > can
> > What's your point?  The question is what 'it' means in the sentence
> "We
> > can
> > call it...".
> 

Glad to hear it -- it's not obvious to Rafa or myself.

> whole 6 versions of the draft?!? Interesting theory.

Nobody read it?  I didn't, until the last one, but when I did I came up with
the idea you hate so much (as did Qin, apparently).

> objections from several members of WG, with no support for inclusion

That's Chair -- Charles isn't involved -- & Qin (please count correctly ;-).

> Yeah, if we (dis)count the WG feedback the way you are counting.....

Note that I said "nobody else".  Believe it or not, you are not the Working
Group.  I'm interested, as I said, in determining WG consensus, not merely
the opinions of the noisiest few.  I know your opinion; it is not being
discounted.  However, you & Rafa, etc. are not the complete WG & if you guys
are the only ones interested in the subject (& furthermore, only interested
in it if it's your way), I have question why the WG should be spending all
this time on it.

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 10 Mar 2009 16:08:54 -0700

...

> whole 6 versions of the draft?!? Interesting theory.

Actually, if (as I suspect) nobody cares about this, it would hardly have
been necessary to "hide" anything ;-)

...

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 10 Mar 2009 19:34:47 -0400

> the idea you hate so much (as did Qin, apparently).

Are you sure you did not read it?

Let me show jabber log at the time of IETF73 HOKEY meeting:

http://jabber.ietf.org/logs/hokey/2008-11-19.txt

"
[14:24:32] vifajardo1 joins the room
[14:50:35] Yoshi joins the room
[14:59:56] lliuhto joins the room
[15:03:15] <Yoshi> Has the meeting started already?
[15:03:21] <vifajardo1> Yes
[15:03:35] <vifajardo1> agenda bashing started
[15:03:42] <Yoshi> ok.
[15:04:37] <vifajardo1> reauth, erx, emsk keying now rfcs
[15:04:49] <vifajardo1> reauth, key manangment in progress
[15:05:16] <vifajardo1> glenn re-read preauth, thanks to yoshi for re-editing
[15:05:19] lliuhto leaves the room: offline
[15:05:31] <vifajardo1> he has a few minor comments ... he will save it for last call
[15:05:41] <vifajardo1> its very minor and will not cause any contreversy
"

I assume "glenn" is you who "re-read" preauth.  

Note that at the time of IETF73, the latest preauth-ps draft version
was 04.

Yoshihiro Ohba

---

From: Tom Taylor <[email-masked]>
Date: Tue, 10 Mar 2009 22:52:05 -0400

Time I took a hand in this conversation. I believe the Peer-SA-AAA-CA model does 
fall within the RFC 5462 definition of EAP pre-authentication. But leaving that 
aside, I believe there is agreement the model is technically valid and of 
interest. So if we change the name of the draft to EAP-Based Methods of Early 
Authentication we can cover both models without stepping on the terminologyu issue.

---

From: Qin Wu <[email-masked]>
Date: Wed, 11 Mar 2009 10:58:39 +0800

Hi,all:
As regarding the debat of considering peer-SA-AAA-CA model as EAP pre-authentication
Let me summarize what I understand and whether this model Peer-SA-AAA-CA can be qualified as pre-authentication model.
1. The purpose of EAP Pre-authentication is proactively generating an MSK for the candidate authenticator. This model can achieve this purpose.
2. This model is quite useful when there is no trust relationship between the SA and CA. It will be complementary to the model peer-SA-CA-AAA which requires   the anticipated trust relationship between the serving network and candidate network. In other words, the model peer-SA-CA-AAA has some limitation.
3. The key management is a integral part of pre-authentication. All existing key management mechanism can be reused here
4. In the section 4 of RFC 5247, EAP pre-authentication and Proactive key distribution are addressed as two mechanisms. However it does not restrict to apply similar mechanism as proactive key distribution in the EAP pre-authentication procedure. The details can be seen in the section 4.1 of RFC5247.
5. In the section 4.1 of RFC 5247, it mentions the unnecessary pre-authentication can be avoided . I wonder How to avoid unnecssary pre-authentication? But if we ask the peer carry candidate authenticator information in the EAP message to the AAA server, upon the peer attaches to the serving authenticator,the extra pre-authentication maybe can be avoided.
6. In the section 4.1 of RFC 5247, we can see EAP pre-authentication can not be completed before the peer loss connectivity and multiple times pre-authentication is needed, why? 
However if we consider the model Peer-SA-AAA-CA, firstly pre-establish keying material in the candidate authenticator through the EAP exchange between the SA and AAA, and then one more pre-authentication is needed to validate the keying materials and authenticate the peer via the candidate authenticator. We can get the right answer.
I wonder whether these bullets listed above can be taken as technical comments or justification :). On the other hand, I have no objection to separate the model(Peer-SA-AAA-CA) as EAP pre-authentication if everybody agree.

Best regards.
-Qin

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 10 Mar 2009 23:36:22 -0400

Qin,

Thank you for the summary, but I think the summary is not addressing
the most important point that has never been explained by you.  That
is, how your model can fit Figure 1 of RFC 5247.  In Figure 1 of RFC
5247, the authenticator is the one who runs EAP authentication with
the peer and also gets EAP keying material from the authentication
server.  It is apparent that CA is such an authenticator in EAP
pre-authentication.  Your model does not fit Figure 1 unless both SA
and CA are viewed as *big authenticator*.  This simply tells that
Peer-SA-AAA-CA model is not categorized as EAP pre-authentication.

Thanks,
Yoshihiro Ohba

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 11 Mar 2009 09:15:45 +0200

> the idea you hate so much (as did Qin, apparently).

Once again, for the last time: People are saying the issue is your
optimization does not fit the scope. It is one of million other
optimizations we could be discussing, but only after re-scoping work. I am
not hating the proposal, but the way WG is being put under pressure to
forcefully swallow it. OK?

> > > I
> > > suspect,
> > > however,  that nobody else really cares about "EAP
> preauthentication"
> > > at

So, you are already on to Plan B? :)

OK, I think I made my points too many times. 

Alper

---

From: Qin Wu <[email-masked]>
Date: Wed, 11 Mar 2009 17:35:09 +0800

Hi,Yoshi:
Nice to see you again. Thank for your feedback.
Firstly I would like to say the model seems no conflict with RFC5247 except some interpretation misunderstanding.

As we know , RFC5247 mainly focuses on normal authentication, just as RFC 5247 implied in section 4 “handoff vulnerabilities”, when pre-authentication is employed, quite a lot of new issues need to be reconsidered and handoff vulnerabilities will happen, e.g., inter-authenticator handover, inter-technology handover. That's why we need to develop the draft-ietf-hokey-preauth-ps to deal with this.

In the Figure1 of RFC5247, the normal authentication between the peer and AAA is given, of course the pre-authentication can reuse the mechanism in this normal authentication, further more, the pre-authentication also can reuse the keying management for normal authentication or re-authentication.

Secondly, based on the last two bulletins in my summarization, I can give you one example:

Suppose the peer is attaching to the serving authenticator, the normal authentication is required to qualify whether the peer can 
get access to the serving network. At the same time, the peer intends to pre-establish the keying material on one candidate authenticator, the 
pre-authentication can be done with the normal authentication together to reduce unnecessary pre-authentication and carry the candidate authentication information to the AAA server. 

However this pre-authentication is not enough to check whether the keying materials is validated on the peer and the candidate authenticator or AAA, the pre-authentication between the peer and AAA server can be performed again through the candidate authenticator prior to arrival of the peer at the candidate authenticator. 

The difference between the first pre-authentication and the second pre-authentication is the first pre-authentication between the peer and the AAA is performed via the serving authenticator and the second pre-authentication is preformed via the candidate authenticator.

Best regards!

-Qin

---

From: Rafa Marin Lopez <[email-masked]>
Date: Wed, 11 Mar 2009 12:38:30 +0100

Hi Qin,

I am glad to see this kind of details in an e-mail :). I appreciate it.

> 1. The purpose of EAP Pre-authentication is proactively generating an MSK for the candidate authenticator. This model can achieve this purpose.
[Rafa] However, according to EAP Key Management in order to deliver a 
key to an authenticator, this authenticator acts as EAP authenticator. 
Unfortunately, in the peer-SA-CA-AAA model the EAP authenticator is the 
SA, right?.
> 3. The key management is a integral part of pre-authentication. All existing key management mechanism can be reused here
[Rafa] Before going further in the next bullets, let me ask you 
something. Section 4.1 of RFC 5247 says

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

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

I guess you have seen this text. How do you interpret this?. That text 
refers to section 1.3 as well. See Fig. 1. What I see is that in EAP 
pre-authentication, the key management that we have to use is EAP Key 
Management as described in RFC 5247.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 11 Mar 2009 09:56:10 -0400

Qin,

Unfortunately, your response still does not explain how your model
fits Figure 1.

EAP pre-authentication needs to fit Figure 1 as described in Section
4.1 of RFC 5247:

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

Following Figure 1 is a requirement to be qualified as EAP
pre-authentication, and peer-SA-AAA-CA model differs far from Figure
1.  This is the basic reason why you keep getting pushback from those
who are concerned.  Unless you accept the reason, the debate will go
nowhere for sure.

Your example below discloses performing normal authentication with SA
and proactive key distribution to CA together, which is an interesting
optimization, but again it does not fits Figure 1 with regard to
authentication and key establishment for CA.  

Thanks,
Yoshihiro Ohba

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 11 Mar 2009 15:19:51 -0700

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

> > > > What's 'been in the draft all along' is what the former editor
> put
> > > > there.
> > >
> > Nobody read it?  I didn't, until the last one, but when I did I came
> up
> > with
> optimization does not fit the scope. 

Sorry, I don't buy it.  Typically, when people talk about the "scope of the
charter" they are afraid that progress will slow; however, you have pretty
much halted progress for about 4 months now...

> It is one of million other
> optimizations we could be discussing, but only after re-scoping work. 

But there aren't a million proposals, there's one.

> I am not hating the proposal, but the way WG is being put under pressure
to
> forcefully swallow it. OK?

Once again, you aren't the whole of the WG & I don't have a sense of what
the whole WG wants to do or even if they care.

> > > > all, which really raises doubt in my mind about the validity of
> the
> > > > draft as
> > > > a WG item.
> > >
> > discounted.  However, you & Rafa, etc. are not the complete WG & if
> you
> > guys
> > in it if it's your way), I have question why the WG should be
> spending
> > all
> > this time on it.
> 

I don't know what "Plan B" is; I do think that if there are only 3-4 people
out of the WG who are interested in something, maybe it would be better for
them to publish it as an Individual submission & let the WG get on with
other work.

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 12 Mar 2009 09:50:22 +0200

Glen,

> Typically, when people talk about the "scope of
> the

Tell me you are joking..... "You" are inhibiting the progress because Qin
brings in an out-of scope idea and you insist on getting it included; and
now seeing that it is not getting included you are even suggesting we drop
this work item...... 

> But there aren't a million proposals, there's one.

Believe me there are. Once you enlarge the scope of optimization to include
Qin's idea, there are so many other ideas that fall under that scope, you'd
be amazed. I'd bring up 3 of mine. Unless of course the charter is
constrained to say "preauth + Qin's idea". OK, then you are right, it
becomes just one more idea...

> the whole WG wants to do or even if they care.

OK, ask now... if the volume of past discussions was not convincing to
you...

Let's not waste any more time on this. Here is my recommendation (as a WG
member :-)
- let's ask if people still care about pre-auth work item? 
- let's ask if people think Qin's idea is in or out of current scope?

Alper

---

From: Qin Wu <[email-masked]>
Date: Thu, 12 Mar 2009 15:57:13 +0800

Hi,Rafa:
Thank for your feedback and understanding. Please see inline.
-Qin
----- Original Message ----- 
From: "Rafa Marin Lopez" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, March 11, 2009 7:38 PM
Subject: Re: [HOKEY] I-D Action:draft-ietf-hokey-preauth-ps-06.txt

> Unfortunately, in the peer-SA-CA-AAA model the EAP authenticator is the 
[Qin]: According to the section 4.1 of RFC5247, it allow multiple pre-authentications. if we allow two time pre-authentications happen before loss connectivity.
in the first pre-authentication, we can make the SA act as EAP authenticator on behalf of CA, in the second pre-authentication, we can make the CA acts as EAP authenticator to validate keying materials. So it does not clash with basic principal for EAP key managment as described in RFC5247. What do you think of it? :)

> Management as described in RFC 5247.

[Qin] Good question. You get to the point, 
For the normal authentication, there are no delay between phase 1 and phase2 concerned, in contrast with pre-authentication. That's right, 
However for the pre-authentication, firstly I would like to say pre-authentication can reuse the existing mechanism for normal authentication including reusing existing keying materials.
Secondly, normal authentication will fall short when quite a lot of new situations are considered, e.g., inter-technology handover, inter-domain handover. That's why we develop the draft-ietf-hokey-preauth-ps-06.
As the section 4.1 of RFC5247 implied, handoff vulnerabilities occurs. different mechanisms can be utilized together to tackle with this.e.g., key caching mechanism can be used with pre-authentication, also, context transfer can be considered in the pre-authentication.
As regarding the difference in the lower-layer encapsulation, the model peer-SA-AAA-CA can apply the same lower-layer encapsulation as the model peer-CA-AAA or the model peer-SA-CA-AAA. e.g., we consider multiple pre-authentication, the first pre-authentication is performed via SA, the second pre-authentication is performed via CA.

---

From: Qin Wu <[email-masked]>
Date: Thu, 12 Mar 2009 15:57:31 +0800

Hi, Yoshi:
Thank for your kindly reply and reminding. 
It seems you raise the similar question as Rafa. Let me tell you what I understand with the text you referred..

Firstly the figure 1 is used to qualify the normal authentication. And I can not see any text in the section associated with figure1 but the section 4.1"handoff vulnerabilities". Just as the  title of section 4.1 said, normal authentication fall short when the inter-authenticator handover is considered,in other words, the handoff vulnerabilities will occur. Some new mechanisms are required to tackle with this issue, e.g., pre-authentication mechanism, key caching mechanisms, token distribution mechanisms, obviously these mechanism can not be simple utilized separately. These mechanism can be utilized together, e.g., some similar mechanism as proactive key distribution can be used in the pre-authentication process.

secondly, please referred the text also in the same section 4.1:
"
it is possible that the peer will not be able to complete EAP pre-authentication prior to connectivity loss or that it can pre-authenticate multiple times with the same authenticator
"
>From the text above, we see multiple times pre-authentication is allowed in some scenario. e.g., according to my example, the peer indirectly pre-authenticate with the CA via the SA through the AAA in the first pre-authentication, and direct pre-authenticate with the CA via the CA.

Third, I want to point out the RFC5247 mostly focus on normal authentication in the the IEEE 802.11 domain or IEEE 802.16e domain, however pre-authentication face more complicated situations,such as hetergeneous technology handover, inter-domain handover. Do you think each RFC
has no limitation or is always a truth with more and more new technologies emergering..:)

As regarding your suggestion, I have expressed my opinion in the earlier emails. I have no objection to separate the model (peer-SA-AAA-CA) out if everybody agrees. :)
-Qin

---

From: Rafa Marin Lopez <[email-masked]>
Date: Thu, 12 Mar 2009 12:06:45 +0100

Hi Qin, thanks for your answer.
> in the first pre-authentication, we can make the SA act as EAP authenticator on behalf of CA, in the second pre-authentication, we can make the CA acts as EAP authenticator to validate keying mater…
[Rafa] Basically, your statement is incorrect. The text clearly says 
"pre-authenticate multiples times with the SAME AUTHENTICATOR".

On the other hand, I don't know the relation of this and what I have 
asked for.

> However for the pre-authentication, firstly I would like to say pre-authentication can reuse the existing mechanism for normal authentication including reusing existing keying materials.
[Rafa] I referred both paragraphs to highlight that there is NO 
difference between normal authentication and EAP pre-authentication in 
terms of key management and distribution.

What I see in RFC 5247 is:

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

And in section 1.3 the authenticator involved in the EAP authentication as EAP authenticator receives the key material. 

As first step, can we agree on this at least?: the authenticator involved in the EAP authentication as EAP authenticator receives the key material (e.g. MSK) according to section 1.3. Agree?.

> As regarding the difference in the lower-layer encapsulation, the model peer-SA-AAA-CA can apply the same lower-layer encapsulation as the model peer-CA-AAA or the model peer-SA-CA-AAA. e.g., we co…
[Rafa] If the difference is in the lower-layer encapsulation, the 
difference is NOT in the key management and in the key distribution, right?.

But let me ask you again. According to RFC 5247, what does authenticator 
receive the key material?. The answer can be formulated in one sentence: 
the authenticator that acts as EAP authenticator in the EAP 
conversation. Can we agree on that?.

Best Regards.

---

From: Qin Wu <[email-masked]>
Date: Thu, 12 Mar 2009 20:55:54 +0800

Hi, Rafa:
Thank for your reply soon.
-Qin
----- Original Message ----- 
From: "Rafa Marin Lopez" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, March 12, 2009 7:06 PM
Subject: Re: [HOKEY] I-D Action:draft-ietf-hokey-preauth-ps-06.txt

> On the other hand, I don't know the relation of this and what I have 
[Qin] Normally we say the peer pre-authenticate with the AAA server ,not the authenticator, 
I am sure whether it is appropriate to say the peer pre-authentication with the authenticator.
Even  that, based on the text above, if we allow two times pre-authentication, we can say:
In the first pre-authentication, the peer indirectly pre-authenticate with the same authentication through the AAA, in the second pre-authentication, the peer directly pre-authenticate with the same  authenticator through the Candidate authenticator.

> As first step, can we agree on this at least?: the authenticator involved in the EAP authentication as EAP authenticator receives the key material (e.g. MSK) according to section 1.3. Agree?.

[Qin]: I wonder where the delay between phase 1 and phase 2 comes from if pre-authentication is normal authentication. If the normal authentication is pre-authentication or re-authentication, why we need to develop the new draft without new situation considered. If we say the difference is lower-layer encapsualtion, the model peer-SA-AAA-CA can apply the similar mechanism as the other models. If you neglect  the example I raised and the second paragraph of the section 4.1(i.e.,multiple pre-authentication is allowed or unnecessary pre-authentication can be avoided as described in the section 4.1), I wonder what agreement can we achieve? Sorry for my difficulties.

> difference is NOT in the key management and in the key distribution, right?.

[Qin] I agree.

> conversation. Can we agree on that?.
[Qin]
 I have to point out EAP is two parties protocol, the authenticator is only a pass through if the authentication does not play backend AAA part. The EAP exchange definitely happen between the peer and AAA server. EAP authenticator is only the third party. The purpose of EAP exchange between the peer and the AAA is to establish keying materials on the peer, authentication. It does not matter who will be an authenticator if my understanding is correct.

---

From: Rafa Marin Lopez <[email-masked]>
Date: Thu, 12 Mar 2009 14:45:08 +0100

Hi Qin, thanks for reply.

> In the first pre-authentication, the peer indirectly pre-authenticate with the same authentication through the AAA, in the second pre-authentication, the peer directly pre-authenticate with the sam…
[Rafa] What does two times pre-authentication mean? Why do you say there 
are two pre-authentications? Where did you extract that?.
> [Qin]: I wonder where the delay between phase 1 and phase 2 comes from if pre-authentication is normal authentication. If the normal authentication is pre-authentication or re-authentication, why w…
[Rafa] Qin, as you may know you have not answered my question.

The authenticator involved in the EAP authentication as EAP 
authenticator receives the key material (e.g. MSK) according to section 
1.3. Agree?.

Btw, I am not neglecting the second paragraph on RFC 5247. Have you seen 
that I wrote?

The text clearly says "pre-authenticate multiples times with the SAME AUTHENTICATOR". Don't you see the SAME AUTHENTICATOR in RFC 5247.?

But it seem you want to neglect the words: SAME AUTHENTICATOR.

>> difference is NOT in the key management and in the key distribution, right?.
[Rafa]. OK, you agree. If the difference is NOT in the key management 
and the key distribution, according to RFC 5247 what is the 
authenticator which receives the key material (e.g. MSK)?.
>  I have to point out EAP is two parties protocol, the authenticator is only a pass through if the authentication does not play backend AAA part. The EAP exchange definitely happen between the peer and AAA server. EAP authenticator is only the third party. The purpose of EAP exchange between the peer and the AAA is to establish keying materials on the peer, authentication. 
Basically, you don't answer my question again. According to RFC 5247, 
what does authenticator receive the key material?.

I think the question is pretty easy and easy to answer. I would 
appreciate a simple answer.

> It does not matter who will be an authenticator if my understanding is correct.
>   
[Rafa] I am afraid you're understanding is NOT correct. EAP Key 
Management RFC 5247 is clear about that. See Fig. 1 in section 1.3.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 12 Mar 2009 04:02:18 -0400

> Firstly the figure 1 is used to qualify the normal authentication. And I can not see any text in the section associated with figure1 but the section 4.1"handoff vulnerabilities". Just as the  title…

Section 4.1 of RFC 5247 is "EAP Pre-Authentication", not "handoff
vulnerabilities".  The text in Section 4.1 I quoted in my previous
email refers to Section 3.1 which contains Figure 1.  So EAP
pre-authentication needs to fit Figure 1.  Your responses keep failing
to explain how peer-CA-AAA-SA fits Figure 1.  I already explained my
point multiple times.  Unless you succeed to explain how
peer-CA-AAA-SA fits Figure 1, I will not respond further, but please
don't take my silence as my agreement.

> From the text above, we see multiple times pre-authentication is allowed in some scenario. e.g., according to my example, the peer indirectly pre-authenticate with the CA via the SA through the AAA…

The 1st authentication is peer-SA-AAA-CA model, which is not EAP pre-authentication.

The 2nd one is EAP pre-authentication, that is fine.

To be clear, my concern is on the 1st one.

> has no limitation or is always a truth with more and more new technologies emergering..:)

This is what exactly hokey-preauth-ps is trying to identify as the
problem to solve.  I don't understand which RFC you mean by "each
RFC".

> As regarding your suggestion, I have expressed my opinion in the earlier emails. I have no objection to separate the model (peer-SA-AAA-CA) out if everybody agrees. :)

That's fine, as long as the peer-SA-AAA-CA model is not qualified as
EAP pre-authentication.  Thank you for remembering my suggestion.

Regards,
Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 12 Mar 2009 04:16:26 -0400

> email refers to Section 3.1 which contains Figure 1.  So EAP

s/3.1/1.3/.

Yoshihiro Ohba

> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email 
> ______________________________________________________________________
>

---

From: Qin Wu <[email-masked]>
Date: Fri, 13 Mar 2009 16:43:12 +0800

Hi, Rafa:
I am glad we have agreed to consider the peer-SA-AAA-CA model as a valid alternative to reduce access time. Whether it should be taken out from the draft-ietf-hokey-preauth-ps and develop new draft, I would like to yield to the working group chairmen to make decision.

But I am sorry you didn't catch up what I emphasized again and again in the earlier mails. And I don't mind summarizing it again. 

As we know the limitation of the existing model peer-SA-CA-AAA is that it requires the trust relationship between the serving network and the candidate network. What if there is no trust relationship between the serving network and the candidate network, especially in the hetergenous technology handover enviroment, what we should do using pre-authentication?

In this situation, the model (Peer-SA-AAA-CA) can work instead of the model peer-SA-CA-AAA. Just as my example said, we can allow multiple pre-authentication as described in section 4.1 of  RFC5247, my example is also based on the second paragraph of section 4.1 of RFC5247. However Rafa argue that it is the SAME AUTHENTICATOR that the peer pre-authenticate with for twice. My explaination is:
If we allow the pre-authentication happen twice, we can consider for the first time pre-authentication, the peer pre-authenticates INDIRECTLY with the SAME AUTHENTICATOR through the AAA server, for the second pre-authentication, the peer pre-authenticates DIRECTLY with the SAME AUTHENTICATOR through the SA or CA. Does this example convince you or not? :)

As regarding who will be authenticator, In my example, at the first time pre-authentication, the authentication should be the SA and at the second time pre-authentication, the authentication should be the CA. Also I want to emphasize EAP exchange is two parties protocol, the authenticator is only a pass through part.
I am not sure whether my example can answer your question.

On the other hand, RFC5247 mostly focuses on the normal EAP authentication, in other words, only one peer, one authenticator, one AAA server are considered. It does not cover any more details when two authenticators are involved. just as the title of section 4 "Handoff vulnerabilities" said, When inter-authenticator handoff or inter-technology handoff is considered in the RFC 5257, it will fall short and handoff vulnerabilities will occur. 
If you say the normal authentication differ little from pre-authentication except lower-layer encapsulation, that is correct, we can use the same lower-layer encapsulation as the model Peer-SA-CA-AAA. I am not sure whether I can answer your question? Thank for your understanding.

Regards!
-Qin

---

From: Qin Wu <[email-masked]>
Date: Fri, 13 Mar 2009 17:11:25 +0800

Hi, Ｙｏｓｈｉ：
Thank for your understanding. I am highly appriciated. 
Let me try to explain to you how peer-CA-AAA-SA fits figure 1. :)
If we agree to allow pre-authentication happen twice, i.e.,
1. The 1st pre-authentication
2. The 2st pre-authentication
The 1st pre-authentication will be used when 
a. the Candiate authenticator is discovered in advance.
b. the peer moves across hetegeneous networks or inter-domain, e.g., the peer move from the last authenticator in the WiMAX access network to the first authenticator in the the 3GPP access network.
c.there is no trust relationship between the serving authenticator(SA) and the candidate authenticator(CA),e.g, we consider inter-technology handover scenarios. the trust relationship between the SA and the CA is not possible.
d. and there exist trust relationship between the AAA server and the SA.

At this time, what the peer should do for 1st pre-authentication? Peer can pre-authenticate with the AAA server through the SA and carry the CA information to the AAA server. In other words,  in this situation, the SA can ON BEHALF OF CA involve in the EAP exchange with the AAA server. If the AAA server is aware of the preauthentiction from the peer and will extract the CA information, the AAA server can authorize whether the peer is qualified to access to the Candidate network based on the peer Identity, e.g., NAI. and then the AAA server pre-establish the keying materials shared between the peer and the CA on the peer and the CA. 

In order to avoid unnecssary pre-authentication as described in the second paragraph of the section 4.1 in RFC5247, the 1st pre-authentication can be performed with the normal EAP authentication which is used to authorize the peer to access the Serving network.

But this is not enough for pre-authentication. The 2st pre-authentication can be used to validate the keying materials shared between the peer and the CA. This keying materials is pre-established in the 1st pre-authentication.

I am not sure this example can convince you that how peer-CA-AAA-SA fits figure1 which is complemtary to the model peer-SA-CA-AAA.
Hope you can understand,:), Thanks a lot!

Regards!
-Qin
----- Original Message ----- 
From: "Yoshihiro Ohba" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, March 12, 2009 4:16 PM
Subject: Re: [HOKEY] I-D Action:draft-ietf-hokey-preauth-ps-06.txt

>> email refers to Section 3.1 which contains Figure 1.  So EAP
[Qin] Sorry, what I refer here is not section 4.1. Please
s/4.1/4./.

---

From: Rafa Marin Lopez <[email-masked]>
Date: Fri, 13 Mar 2009 12:38:06 +0100

Hi Qin,

I have read your e-mail. Unfortunately, you have NOT answered my 
question yet.

According to RFC 5247, what does authenticator receive the key material? (section 1.3).

Once this question is answered we can continue the discussion about "SAME AUTHENTICATOR". 

Best Regards.

---

From: "Glen Zorn" <[email-masked]>
Date: Sat, 14 Mar 2009 17:38:22 -0700

> brings in an out-of scope idea 

Yes, finally someone read & analyzed the draft & found it lacking.  Why is
the idea out of scope?  Because Yoshi's draft says so?  Because you say so?
Because an RFC doesn't mention it?  Are you seriously trying to claim that
RFC 5247 lists every form of EAP preauthentication possible?  

> and you insist on getting it included;

Nonsense.  What I am insisting upon is that a technical discussion about it
take place, one which you refuse to take part in.

> now seeing that it is not getting included you are even suggesting we

I'm talking about dropping the work item simply because I'm not interested
in allowing this WG to become a vanity publishing house.

> be amazed. 

What scope is that?  It is certainly not "proactive key distribution" as I
have shown repeatedly.  Authentication is taking place before the peer moves
& the right key is arriving at the right destination at the right time (or
so I would claim; I must be right, since you refuse to debate the point,
preferring to hide behind administrative nonsense.

...

---

From: "Alper Yegin" <[email-masked]>
Date: Sun, 15 Mar 2009 15:34:02 +0200

My last email on this thread (because you are simply making me and others
repeat ourselves and also making non-technical statements that are not
constructive).

I did get involved in the technical part of the discussion and technically
concluded that Qin's idea does not qualify as pre-authentication. Please go
back and read the emails. 

You are liberally defining "EAP Pre-authentication" as "Authentication is
taking place before the peer moves & the right key is arriving at the right
destination at the right time". If you really want to go with such a wide
open definition just so that Qin's idea qualifies, then first get the WG to
agree on it (without threatening the WG that you'd stop the work if they
don't accept it your way :-), and then let me know so I start typing my 3
I-Ds, and let the flush flood gates open to the ones from others. Because,
*any* authentication optimization satisfies your definition. Then we get
into infinite rounds of beauty contest. 

My recommendation, once again, is:
- Let the pre-auth work progress based on the current and common
understanding.
- Re-charter the WG to include another well defined set (not infinite set!)
of optimizations
- Solicit proposals, evaluate them, and make progress on selected ones...

If you want to deviate (i.e., change the course of the WG), please ask WG's
input. 

That's it from me on this thread, thanks.

Alper

> -----Original Message-----
> From: Glen Zorn [mailto:[email-masked]]
> Sent: Sunday, March 15, 2009 2:38 AM
> To: 'Alper Yegin'; 'Glen Zorn'
> Cc: [email-masked]
> Subject: RE: [HOKEY] I-D Action:draft-ietf-hokey-preauth-ps-06.txt
> 
> > Glen,
> >

---

From: Ashutosh Dutta <[email-masked]>
Date: Sun, 15 Mar 2009 10:35:47 -0400

Alper,
       This sounds like a reasonable set of suggestions as a way forward 
to get out of a 4 month old stalemate.

Regards
Ashutosh

---

From: Tom Taylor <[email-masked]>
Date: Sun, 15 Mar 2009 20:56:52 -0400

I assume by "Let the pre-auth work progress based on the current and common
understanding" you mean to work on protocol for the following interfaces:
  -- Peer to SA (content but not encapsulation);
  -- SA to CA (content but not encapsulation);
  -- CA to AAA (content and transport).

---

From: Qin Wu <[email-masked]>
Date: Mon, 16 Mar 2009 12:03:38 +0800

Hi, Rafa:
Actually I have answered you with the example indirectly in this thread. Also I don't mind answer your question directly.
I am not sure whether it makes sense to answer your debat based on RFC5247.
However since your question is based on the RFC 5247. I will quote the same section 1.3 of RFC5247 to answer you and convince you.
In the section 1.3 of RFC5247, the conversation between parties is shown below:
   EAP peer                   Authenticator               Auth. Server
   --------                   -------------               ------------
    |<----------------------------->|                               |
    |     Discovery (phase 0)       |                               |
    |<----------------------------->|<----------------------------->|
    |   EAP auth (phase 1a)         |  AAA pass-through (optional)  |
    |                               |                               |
    |                               |<----------------------------->|
    |                               |       AAA Key transport       |
    |                               |      (optional; phase 1b)     |
    |<----------------------------->|                               |
    |  Unicast Secure association   |                               |
    |          (phase 2a)           |                               |
    |                               |                               |
    |<----------------------------->|                               |
    | Multicast Secure association  |                               |
    |     (optional; phase 2b)      |                               |
    |                               |                               |

              Figure 1: Conversation Overview
 
.From the figure 1 above, it is obvious to see that AAA key transport is optional in the phase 1b. So the authenticator who involves in the EAP exchange is not mandatory to receive the keying materials shared between the peer and this authenticator from the AAA server. Also there are no clear texts to restrict the AAA to pre-establish the keying materials shared between the peer and the other authenticator on the other authenticator. And the RFC5247 fall short and handover vulnerabilites will occur when it covers inter-authenticators handover scenarios.

On the other hand, EAP protocol is two parties protocol and EAP exchange actually occurs betweeen the Peer and the AAA server. The authenticator is only a pass through. The AAA server is not necessary to validate whether the authenticator is qualified to be a pass through part. The trust relationship between the authenticators and the AAA can be proactively established.

Regards!
-Qin

---

From: Rafa Marin Lopez <[email-masked]>
Date: Mon, 16 Mar 2009 10:34:08 +0100

Let me tell first that the phase you mention is optional for two reasons:

a) When the EAP method does not generate any key material (it does not 
make sense to send a key :) )
b) When the EAP authenticator is working as standalone mode.

If the authenticator is working in pass-through mode, the authenticator 
that acts as EAP authenticator receives the key material and NOT other. 
The figure is clear: if the phase 1b happens, it happens with the same 
authenticator involved in the phase 1a :) and NOT other. (see also a 
related comment below).

It is not my fault that EAP works in this way. It is not my fault that 
"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" :).

Honestly, I think at this point of time, we could be already discussing 
the different aspects of peer-SA-AAA-CA model, security requirements 
benefits, problems and everything, if we had put a stop to qualify the 
peer-SA-AAA-CA model as EAP pre-authentication; and moreover, if it had 
not been included in an I-D which is dedicated to EAP 
pre-authentication. As long as we insist on that, this will never end. 
The reason is that it is simply wrong.

My point is : let's remove this model from the EAP pre-authentication PS 
I-D. Let's write the details and everything in another I-D and start the 
discussion over that new document dedicated to peer-SA-AAA-CA model. 
But, please, let's maintain the EAP pre-authentication PS I-D as it was 
in version 05.

Please, see more comments below.
> Also there are no clear texts to restrict the AAA to pre-establish the keying materials shared between the peer and the other authenticator on the other authenticator.
[Rafa] See below.
>  And the RFC5247 fall short and handover vulnerabilites will occur when it covers inter-authenticators handover scenarios. 
>   
> On the other hand, EAP protocol is two parties protocol and EAP exchange actually occurs betweeen the Peer and the AAA server.
[Rafa] Btw, let me clarify that EAP protocol is two party that involves 
EAP peer and EAP server. Due to mode independence the peer does not need 
to know if the EAP server is in the AAA server or the EAP authenticator :).

"Within EAP, the primary function of the AAA protocol is to maintain
   the principle of mode independence.  As far as the EAP peer is
   concerned, its conversation with the EAP authenticator, and all
   consequences of that conversation, are identical, regardless of the
   authenticator mode of operation."

Due to this, the key management in EAP implies that if pass-through mode 
is used the AAA server sends a key to the authenticator involved in the 
EAP signaling as EAP authenticator and NOT other to maintain mode 
independence.

>  The authenticator is only a pass through. The AAA server is not necessary to validate whether the authenticator is qualified to be a pass through part. The trust relationship between the authenticators and the AAA can be proactively established.
>   
[Rafa] I don't understand this.

Best Regards.

---

From: Qin Wu <[email-masked]>
Date: Mon, 16 Mar 2009 20:51:43 +0800

Hi, Rafa:
I am sorry we are still in the debate on whether the model peer-SA-CA-AAA is qualified as pre-authentication.
I am also sorry you misunderstand what the RFC5247 should be. 
I suggest we do not need to go into loops if further discussion is on.
Firstly Let me summarize again on  whether this model Peer-SA-AAA-CA can be qualified as pre-authentication model. Also I reinforces these reasons based on the discission with the Rafa. Thank for Rafa's enlightening me.
1. The purpose of EAP Pre-authentication is proactively generating an MSK for the candidate authenticator. This model can achieve this purpose.
2. This model is quite useful when there is no trust relationship between the SA and CA. It will be complementary to the model peer-SA-CA-AAA which requires   the anticipated trust relationship between the serving network and candidate network. In other words, the model peer-SA-CA-AAA has some limitation.
3. The key management is a integral part of pre-authentication. All existing key management mechanism can be reused here
4. In the section 4 of RFC 5247, EAP pre-authentication and Proactive key distribution are addressed as two mechanisms. However it does not restrict to apply similar mechanism as proactive key distribution in the EAP pre-authentication procedure. The details can be seen in the section 4.1 of RFC5247.
5. In the section 4.1 of RFC 5247, it mentions the unnecessary pre-authentication can be avoided . I wonder How to avoid unnecssary pre-authentication? But if we ask the peer carry candidate authenticator information in the EAP message to the AAA server, upon the peer attaches to the serving authenticator,the extra pre-authentication maybe can be avoided.
6. In the section 4.1 of RFC 5247, we can see EAP pre-authentication can not be completed before the peer loss connectivity and multiple times pre-authentication is needed, why? 
However if we consider the model Peer-SA-AAA-CA, firstly pre-establish keying material in the candidate authenticator through the EAP exchange between the SA and AAA, and then one more pre-authentication is needed to validate the keying materials and authenticate the peer via the candidate authenticator. We can get the right answer.
7. the RFC5247 fall short and handover vulnerabilites will occur when it covers inter-authenticators handover scenarios. Also the limitation of RFC5247 is that it only examplify the normal authentication for one peer, one authenticator and one AAA server. However in the pre-authentication scenario, i..e., inter-authentication handoff scenarios, more than one authenticators are involved.
8. In the section 1.3, AAA key transporation is optional ,So the authenticator who involves in the EAP exchange is not mandatory to receive the keying materials shared between the peer and this authenticator from the AAA server. Also there are no clear texts to restrict the AAA to pre-establish the keying materials shared between the peer and the other authenticator on the other authenticator. 
9. The EAP protocol is two parties protocol that involves EAP peer and AAA server. The EAP exchange happening between the peer and the AAA server is not affected by the mode of authenticator. In other words, the EAP exchange has nothing to do with the specific mode of authenticator. 
10. The pre-authentication is not limited to intra-technology handover whin the 802.11 domain, the inter-technology handover and inter-domain handover is what the pre-authentication ps draft intends to develop. e.g., handover between 3GPP access network and WLAN access network. In the 3G acces network, the AAA server is usually seprated from the authenticator. So it is more generic to focus on pass through mode for the authenticator. 

Secondly,As regarding your debate on my justification, Please, see my replies inline.
Regards!
-Qin
----- Original Message ----- 
From: "Rafa Marin Lopez" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, March 16, 2009 5:34 PM
Subject: Re: [HOKEY] I-D Action:draft-ietf-hokey-preauth-ps-06.txt

> authenticator involved in the phase 1a :) and NOT other. (see also a 

[Qin]: I don't deny your reasons on why the phase 1b is optional . However besides your reasons you mentioned above, I can
give you one more reason to refute you. This couterexmaple is:
During intra-authenticator handover scenarios, i.e., the peer moves between different APs within the same authenticator. In this scenario, the phase 1b, even the phase 1a is not necessary. Because the peer does not change the authenticator. So the AAA key transport is not necessary too.
 
On the other hand, there are no texts in the RFC5247 to support your reason. It is only your subjective inference. Also as I said before, there are no texts in the RFC5247 to restrict the AAA to pre-establish the keying materials shared between the peer and the other authenticator on the other authenticator.

> described in Section 1.3, other than the introduction of a delay between 

[Qin] I can not understand why you quote this sentence here. It does not demonstate anything.

[Qin] I agree.

> The reason is that it is simply wrong.

[Qin] This is what I am difficult to agree with.:)

> But, please, let's maintain the EAP pre-authentication PS I-D as it was 

[Qin] As I summarized before, The editorial changes is mainly based on the agreement in the mailist discussion, especially the discussion with Yoshi.
However the most controversial non-editorial change is whether we should consider the model(Peer-SA-AAA-CA) in the draft, I have casted this issue in the maillist for open discussion until now. More clarifications, examplifications and justifications have been made. I am sorry you have not changed your mind with your obsolete perspective. As regarding whether the model (Peer-SA-AAA-CA) is qualified as pre-authentication, I have said before. Let's leave it to the working group chair to make decision.

> to know if the EAP server is in the AAA server or the EAP authenticator :).

[Qin] Don't distort what the mode independence means in the section 1.6.1 of RFC5247. What the mode independence actually means is EAP exchange happening between the peer and the AAA server can not be affected by the mode of authenticator.
Please see the third paragraph in the section 1.6.1 of RFC5247.
"
It is a fundamental property of EAP that at the EAP method layer, the
conversation between the EAP peer and server is unaffected by whether
the EAP authenticator is operating in "pass-through" mode.  EAP
methods operate identically in all aspects, including key derivation
and parameter import/export, regardless of whether or not the
authenticator is operating as a pass-through.
"

> EAP signaling as EAP authenticator and NOT other to maintain mode 

[Qin] Your understanding is wrong. Because the last paragraph in the section 1.6.1 only implies that the EAP exchange between the peer and the EAP authenticator in pass through mode is totally same as the EAP exchange between the peer and the authenticator in the standalone mode. It does not imply anything else. In other words, the EAP exchange has nothing to do with the specific mode of authenticator.

Since your understanding on the paragraph you mentioned  above is wrong, you conclusion also does not stand. My point is for the normal authenticator, you can say that, but for the pre-authencation, we should case by case. Just as I examplify it before, the model(Peer-SA-AAA-CA) does not require the trust relationship between the serving network and candidate network and is complimentary to the model(Peer-SA-CA-AAA) which is limited to the use case where there exists trust relationship between the serving network and candidate network.

Also I have to emphasize the limitation of RFC5247 is that it only examplifies the normal authentication for one peer, one authenticator and one AAA server. But it falls short and handoff vulnarbilites occur when it covers the inter-authenticator handover scenarios. That's what the pre-authentication draft want to find out and developed.

> [Rafa] I don't understand this.

[Qin] I am sorry you negelct my example and all the clarifications in this thread.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 16 Mar 2009 14:59:24 -0400

Qin,

Let's be careful when stating someone's statement is wrong.

In the last paragraph of RFC 5247, Section 1.6.1:

"
   Within EAP, the primary function of the AAA protocol is to maintain
   the principle of mode independence.  As far as the EAP peer is
   concerned, its conversation with the EAP authenticator, and all
   consequences of that conversation, are identical, regardless of the
   authenticator mode of operation.
"

It is not only the conversation with the authenticator but also *all*
*consequences* of that conversation are identical regardless of the
authenticator mode of operation.  The consequences definitely include
the consequence as to which entity will receive the EAP keying
material from the EAP server, because the RFC is about EAP key
management.

On the other hand what Rafa stated is : "Due to this, the key
management in EAP implies that if pass-through mode is used the AAA
server sends a key to the authenticator involved in the EAP signaling
as EAP authenticator and NOT other to maintain mode independence."

I don't see anything wrong in Rafa's statement, but do you?

Yoshihiro Ohba

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 17 Mar 2009 04:54:34 +0200

Hi Tom,

> understanding" you mean to work on protocol for the following

We are just discussing the "problem statement" I-D now. If and when this WG
decides to work on the "protocol design" (solution space), it needs to be
scoped out and the WG needs to be re-chartered to do so.

>   -- CA to AAA (content and transport).

The current problem statement refers to the above interfaces, and also to
the Peer to CA interface. Whether the solution requires work on content or
the encapsulation or both is for the "solution space" discussions.

Alper

> >>>> charter" they are afraid that progress will slow; however, you
> have
> >>>> pretty
> >>> Tell me you are joking..... "You" are inhibiting the progress
> because
> >>> Qin
> >> Yes, finally someone read & analyzed the draft & found it lacking.
> Why
> >> is
> >> the idea out of scope?  Because Yoshi's draft says so?  Because you
> say
> >> so?
> >> Because an RFC doesn't mention it?  Are you seriously trying to
> claim
> >> that
> >>> now seeing that it is not getting included you are even suggesting
> we
> >>> drop
> >>> this work item......
> >>> Qin's idea, there are so many other ideas that fall under that
> scope,
> >>> you'd
> >>> be amazed.
> >> What scope is that?  It is certainly not "proactive key
> distribution"
> >> as I
> >> have shown repeatedly.  Authentication is taking place before the
> peer
> >> moves
> >> & the right key is arriving at the right destination at the right
> time
> >> (or

---

From: Qin Wu <[email-masked]>
Date: Tue, 17 Mar 2009 21:06:44 +0800

Hi, Yoshi and Rafa:
I have to say this principle on being careful to state someone wrong is not only applicable to to me, but also to Rafa and anyone else. :)
Let me make some clarifications according to RFC5247 again.
In the section 1.6.1, it said:
 "
   Within EAP, the primary function of the AAA protocol is to maintain
   the principle of mode independence.  As far as the EAP peer is
   concerned, its conversation with the EAP authenticator, and all
   consequences of that conversation, are identical, regardless of the
   authenticator mode of operation.
 "
If my understanding is correct, the above text in the section 1.6.1 only demonstrates that:
For the regular EAP authentication in which only one peer, one authenticator and one AAA server are involved, 
Upon usage model is chosen, EAP exchange between the peer and EAP authenticator for the pass through mode is quite similar to the one for the standalone mode. In other words, , the EAP exchange between the peer and the EAP authenticator has nothing to do with the mode of authenticator.
e.g., we choose the model (Peer-CA-AAA),
ONLY in this model (Peer-CA-AAA), EAP exchange between the peer and the EAP authenticator for the pass through mode is exactly same as the one for the standalone mode. 
another example, if we choose the model(Peer-SA-AAA), ONLY in this model , Pass through mode case is same as the standalone mode case, as regarding to the EAP exchange between the peer and the EAP authenticator.

However as Rafa stated:
"
Due to mode independence the peer does not need 
to know if the EAP server is in the AAA server or the EAP authenticator :).

"
Which is not reflected anywhere in the RFC5247. This is not what the section 1.6.1 of RFC5247 originally said. 
Also I can't see any relationship between Rafa's statement about
"the peer does not need to know if the EAP server is AAA server"
And
Rafa's conclusion about
"
the AAA server sends a key to the authenticator involved in the EAP signaling
 as EAP authenticator and NOT other to maintain mode independence
"
Can you?

Furthermore, as Yoshi you said:
"
 The consequences definitely include
the consequence as to which entity will receive the EAP keying
 material from the EAP server,
"
Which I can not see any supporting text in the section 1.6.1 according to the RFC5247. Because in the orginal text of section 1.6.1, the conversation only happens between the peer and the authenticator. Definitely the conversation between the peer and the authenticator is same regardless of mode of authenticators. e.g., 4 way handshake to generate the PMK shared between the peer and authenticator,  this mechanism for pass through mode is same as the one for the standalone mode.
So May I suggest not to exaggerate the real meaning of any reference and observer what it should be in  any occasion? :)

Regards!
-Qin

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 17 Mar 2009 13:59:41 -0400

Qin,

> Which is not reflected anywhere in the RFC5247. This is not what the section 1.6.1 of RFC5247 originally said. 

Please see this in section 1.6.1:

"

Since the conversation is *identical* between the EAP peer and server
regardless of the mode of operation, it means that the peer does not
need to distinguish if the EAP server is on the AAA server
(pass-through mode) or on the authenticator (standalone mode).

>  as EAP authenticator and NOT other to maintain mode independence

If the AAA server sends a key to an authenticator that was not
actually involved in the EAP conversation, then it can violate mode
independence because the EAP server on a *standalone* EAP
authenticator is not supposed to give out the key to other
authenticator by definition of *standalone*.

> Which I can not see any supporting text in the section 1.6.1 according to the RFC5247. Because in the orginal text of section 1.6.1, the conversation only happens between the peer and the authentic…

You are missing the fact that the quoted text in Section 1.6.1 applies
not only for the conversation with the EAP authenticator, but also
*all consequences* of that conversation.  The consequences include the
successful completion of an EAP method that supports key derivation
results in the export of EAP keying material and parameters on the EAP
peer and server, and transpoting the EAP keying material to the
authenticator.  Without including such consequences, "4 way handshake
to generate the PMK shared between the peer and authenticator" is not
possible regardless of the mode of operation.

> So May I suggest not to exaggerate the real meaning of any reference and observer what it should be in  any occasion? :)

Thank you for the suggestion, but I think I am not exaggerating
anything.

Thanks,
Yoshihiro Ohba

---

From: Qin Wu <[email-masked]>
Date: Wed, 18 Mar 2009 20:17:11 +0800

Yoshi,
----- Original Message ----- 
From: "Yoshihiro Ohba" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: "Rafa Marin Lopez" <[email-masked]>; <[email-masked]>
Sent: Wednesday, March 18, 2009 1:59 AM
Subject: Re: [HOKEY] I-D Action:draft-ietf-hokey-preauth-ps-06.txt

>   authenticator is operating as a pass-through.

[Qin] I have already quoted this paragraph in the section 1.6.1 of RFC5247 in the earlier emails to convince Rafa.
I don't mind making clarification again according to this paragraph.
What this paragraph said only demonstrates that:
Because the EAP protocol is two parties protocol, so it is obvious that converstation between the EAP peer and server is not affected by man in the middle, e.g. authenticator, In other words, EAP method for the pass through mode can also be used in the standalone mode. Key derivation for the pass through can also be used in the standalone mode. Also one thing I need to emphasize here is, the key derivation is totally different from the key transport. The key management consists of key derivation  part and key transport part. Since the key derivation is not affected by the model of authentication, then the key materials on the Peer for the pass through can use the identical  key materials on the peer for the standalone mode.

> (pass-through mode) or on the authenticator (standalone mode).

[Qin] This is still not what the section 1.6.1 of RFC5247 originally said. 
What the section 1.6.1 of RFC5247 originally said is no matter what the mode is, the EAP method, key generation can not be affected by the mode of authenticator. The EAP method and key generation between the peer and the AAA for the pass through mode can be also used in the standalone mode. In other words, the EAP protocol is agnostic to the mode of authenticator. This is what the section 1.6.1 of RFC5247 intend to deliver.

> authenticator by definition of *standalone*.

[Qin] This is not what the section 1.6.1 of RFC5247 said. What the section of 1.6.1 of RFC5247 want to deliver is
a. EAP conversation is agnostic to the mode of authenticator. 
b. EAP protocol is two parties protocol.
On the other hand, we don't restrict the authenticator into the standalone mode.
Also it is more generic to separate the AAA functionality from the Authenticators in the standalone mode. 

> authenticator. 

[Qin] Firstly I can not see any text in the section 1.6.1 to show it is mandatory for the AAA server to transport the EAP keying materials to one specific authenticator after completion of EAP method. From my understanding, all consequence of that conversation concerned only means the EAP exchange is not affected by the mode of authenticator, nothing else.

> Without including such consequences, "4 way handshake

[Qin] As I said before, according to the section 1.6.1, we only can concluded that:
the 4 way handshake for the pass through mode is same as the 4 ways handshake for the standalone mode, nothing else.
On the other hand, If you think "all consequence of that conversation" means everything is same, I can give you one couterexample to convice you.That is:
If every step is same, every operation is same according to your understanding, it seems we need not distinguish between the model(Peer-CA-AAA) and the model(Peer-SA-CA-AAA). However that does not happen. It is neccessary for us to distinguish between the model (Peer-CA-AAA) and the model (Peer-SA-CA-AAA).

---

From: Rafa Marin Lopez <[email-masked]>
Date: Thu, 19 Mar 2009 02:58:05 +0100

Hi Qin,
>>> For the regular EAP authentication in which only one peer, one authenticator and one AAA server are involved, 
[Rafa] In standalone mode an AAA server is NOT involved.
> Because the EAP protocol is two parties protocol, so it is obvious that converstation between the EAP peer and server is not affected by man in the middle, e.g. authenticator, In other words, EAP m…
[Rafa] If an EAP authenticator is working in standalone mode, and the 
EAP peer initiates an EAP conversation with that EAP authenticator, the 
key material will be exported to that EAP authenticator and NOT other, 
because the EAP methods are performed in that EAP authenticator and NOT 
other and export the key material to that EAP authenticator.

"The successful completion of an EAP method that supports key
   derivation results in the export of EAP keying material and
   parameters on the EAP peer and server. "

However If I interpret correctly, according to your comments, even in standalone mode it seems that we cannot really know
where the key material should go: maybe to that EAP authenticator,
maybe to other..., who knows?. Let's follow anyway.

As per mode independence the conversation and ALL consequences of that conversation, 
are identical, regardless of the authenticator mode of operation. That is:

If the EAP peer is involved in a conversation with an EAP authenticator, the peer expects the same independently if the EAP authenticator is working in standalone or pass-through. If EAP authenticator is working in standalone the key
material certainly will be that EAP authenticator and NOT other. In the pass-through mode the peer expects the same: the key material in that EAP authenticator and NOT other. 

Having said this, what is your interpretation of "Within EAP, the primary function of the AAA protocol is to maintain the principle of mode independence."?. How does the AAA protocol maintain the principle of mode independence under your understanding of EAP mode independence?.

On the other hand, I have to say that I fully agree with Yoshi's arguments. In fact, I still maintain what I said regarding section 1.3 (and the rest of my arguments)

"If the authenticator is working in pass-through mode, the
authenticator that acts as EAP authenticator receives the 
key material and NOT other. The figure 1 is clear: if 
the phase 1b happens, it happens with the
same authenticator involved in the phase 1a :) and NOT other."

Thus, in my opinion, I must say that the peer-SA-AAA-CA model DOES NOT follow the model in section 1.3. In fact, the SA which is acting as the EAP authenticator DOES NOT receive the key material but the CA, which is NOT acting as EAP authenticator. However EAP pre-authentication DOES follow that model in section 1.3.

But I already explained this before...

Best Regards.

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 18 Mar 2009 19:19:11 -0700

...

> other and export the key material to that EAP authenticator.

Nonsense.  Once authentication is complete & the method exports keying
material (if any) it (the keying material) is out of the scope of EAP
altogether.

> However If I interpret correctly, according to your comments, even in
> standalone mode it seems that we cannot really know

Neither.  The keying material is exported & EAP ends.  That's all.  Where
the keying material goes is no affair of the authenticator; in fact, a
well-designed method will use the same interface for export no matter what
the destination may be.  Key transport (if any) and utilization is not the
function of the EAP authenticator (as opposed to the (as it turns out,
ill-named)) 802.11 authenticator.

> If the EAP peer is involved in a conversation with an EAP
> authenticator, the peer expects the same independently if the EAP
> authenticator is working in standalone or pass-through. If EAP
> authenticator is working in standalone the key
> material certainly will be that EAP authenticator and NOT other. In the
> pass-through mode the peer expects the same: the key material in that
> EAP authenticator and NOT other.

More nonsense: when the EAP run ends, the EAP authenticator is no more.
Perhaps you're confusing EAP w/PANA, which appears to hang around
interminably?

> 
> Having said this, what is your interpretation of "Within EAP, the
> primary function of the AAA protocol is to maintain the principle of
> mode independence."?. How does the AAA protocol maintain the principle
> of mode independence under your understanding of EAP mode
> independence?.
> 
> On the other hand, I have to say that I fully agree with Yoshi's
> arguments. In fact, I still maintain what I said regarding section 1.3
> (and the rest of my arguments)
> 

So now we're reduced to taking illustrative figures as normative?

> 
> Thus, in my opinion, I must say that the peer-SA-AAA-CA model DOES NOT
> follow the model in section 1.3. In fact, the SA which is acting as the
> EAP authenticator DOES NOT receive the key material but the CA, which
> is NOT acting as EAP authenticator. However EAP pre-authentication DOES
> follow that model in section 1.3.
> 

Which would have been helpful, had your explanation had anything to do with
EAP...

...

---

From: Qin Wu <[email-masked]>
Date: Thu, 19 Mar 2009 11:18:55 +0800

Rafa,
----- Original Message ----- 
From: "Rafa Marin Lopez" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, March 19, 2009 9:58 AM
Subject: Re: [HOKEY] I-D Action:draft-ietf-hokey-preauth-ps-06.txt

> [Rafa] In standalone mode an AAA server is NOT involved.

[Qin]: For general case, the AAA functionality can be separated from the authenticator, in this way, regardless of mode of authentication, there are
one peer, one authenticator and one AAA functionality located in some entity.
On the other hand, Pass through mode allow one peer, one authenticator and AAA server indpendently involved.

> other and export the key material to that EAP authenticator.

[Qin] Whether the AAA functionality is collocated with authenticator or separated from authenticator, we can not deny the EAP conversation only happens between the peer and AAA funcationality. What's the difference is for the standalone mode, the key materials export happens using interal interface between authenticator functionality and AAA functiality. Please remember the EAP exchange happens between the peer and the AAA server which can be seen in the section 1.6.1:
"
The successful completion of an EAP method that supports key
 derivation results in the export of EAP keying material and
  parameters on the EAP peer and server.
"
> maybe to other..., who knows?. Let's follow anyway.

[Qin]: I have never said that. Let me interpret for you according the above quoted sentence:
What the above sentence intends to convey is that:
Firstly this sentence has never said that the EAP key materials should go to this authenticator, shouldn't go to that authenticator. Never.
Secondly: the EAP method negotiation only happens between the peer and the AAA, after successful negotiation of EAP method, the AAA server
will generate keying materials shared betweeen the peer and the AAA, e.g., MSK, EMSK. Since the keying materials is shared between the peer and AAA, 
the AAA server should distribute this keying materials to the peer via EAP exchange. EAP is carried over the AAA protocol.
As regarding when to distribute the keying materials to the authentication, this sentence does not mention it. 
Also the AAA server can know where to distribute the keying materials if the peer or the SA can tell the AAA the CA's location. It is not a problem.

> material certainly will be that EAP authenticator and NOT other. In the pass-through mode the peer expects the same: the key material in that EAP authenticator and NOT other. 
[Qin]: I have to point out again, the EAP is two parties protocol which can be seen in the second paragraph in the section 1 of RFC5247:
"
EAP is a two-party protocol spoken between the EAP peer and server.
"
Key materials  management also happen between the EAP peer and server, no matter what the mode of authenticator is, the key materials is distributed from the AAA functionality to the peer.

> Having said this, what is your interpretation of "Within EAP, the primary function of the AAA protocol is to maintain the principle of mode independence."?. How does the AAA protocol maintain the p…

[Qin]: The primary function of AAA protocol is the AAA funcationality. That's to say, the AAA functionality is not affected by the mode of authenticator or man in the middle. No matter what the mode of authenticator is, the AAA functionality should perform EAP exchange with the peer, the EAP exchange between the peer and the AAA for the pass through mode should be same as the one for the standalone mode.  This is what I have stated for couple of times in the earlier emails.

> same authenticator involved in the phase 1a :) and NOT other."

[Qin] I have also explained to you and others who are interested in it for couples of time.
Firstly the figure1 mainly focus on the regualr EAP authentication in which one peer ,one authenticator, one AAA funcationality are involved.
It seems not qualified as an authority to judge whether the authentication for the inter-authenticator handover fit in the figure1, in which more than one authenticators  
are involved, regardless of their role in the authentication.
Secondly on the other hand, the phase1b is optional not mandatory, There are no texts to show it is mandaroty to require the AAA server to distribute the keying materials to the same authenticator A after the EAP exchange between the peer and the AAA server through the authenticator A. There are many exceptional case
I can give you one counterexample:
When the peer moves between different APs within the same authenticator, since the peer does not change the authenticator, the phase1b is not necessary.
So we have gone into the loop again, :), Rafa?
May I suggest to hold on this question to the IETF74 meeting for open discussion? I have said that we need a offical discussion face to face, do you agree? I don't intend to refute your opinion any more, It is only purely technical discussion. I respect everybody's opinon from what I listen here. I will summarize all our issues on debate and find the way to resolve it in this meeting. Your suggestions about separation the model from the draft will be highly appreicated. Thanks!.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 18 Mar 2009 23:23:04 -0400

Qin,

> What the section 1.6.1 of RFC5247 originally said is no matter what the mode is, the EAP method, key generation can not be affected by the mode of authenticator. The EAP method and key generation b…

That's fine.  But if you say it is obvious that converstation between
the EAP peer and server is not affected by authenticator, then it is
equally obvious to say that the peer does not need to distinguish if
the EAP server is on the AAA server or on the authenticator.

> Also it is more generic to separate the AAA functionality from the Authenticators in the standalone mode. 

Here again you miss the fact that the quoted text in Section 1.6.1
applies not only for the conversation with the EAP authenticator, but
also *all consequences* of that conversation.

> [Qin] Firstly I can not see any text in the section 1.6.1 to show it is mandatory for the AAA server to transport the EAP keying materials to one specific authenticator after completion of EAP meth…

Let me clarify that I never mentioned that it is mandatory for the AAA
server to transport the EAP keying material!!  Also, your
understanding that "all consequence of that conversation concerned
only means the EAP exchange is not affected by the mode of
authenticator" is wrong, because the "EAP exchange" is the
conversation, not the consequences of the conversation.

> If every step is same, every operation is same according to your understanding, it seems we need not distinguish between the model(Peer-CA-AAA) and the model(Peer-SA-CA-AAA). However that does not…

Don't worry about it.  Because SA in Peer-SA-CA-AAA model does not
acts as EAP authenticator for EAP pre-authentication (as Alper and I
mentioned before), the peer will always is running EAP
pre-authentication with the CA for both models, and the CA can be a
standalone or pass-through authenticator, and therefore mode
independence is maintained.  Distinguishing the two models may be
needed by EAP pre-authentication transport, but that is orthogonal to
mode independence.

Thanks,
Yoshihiro Ohba

---

From: Qin Wu <[email-masked]>
Date: Thu, 19 Mar 2009 17:31:31 +0800

Yoshi,
----- Original Message ----- 
From: "Yoshihiro Ohba" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: "Rafa Marin Lopez" <[email-masked]>; <[email-masked]>
Sent: Thursday, March 19, 2009 11:23 AM
Subject: Re: [HOKEY] I-D Action:draft-ietf-hokey-preauth-ps-06.txt

> the EAP server is on the AAA server or on the authenticator.

[Qin] That's okay. But I want to point out it is not the authenticator but the EAP server whom the peer want to talk.

> also *all consequences* of that conversation.

[Qin]: I have to say what the section 1.6.1 tries to convery is the key materials derived from AAA server in the pass through mode is same as the key materials derived from the same AAA server in the standalone mode.
Since the conversation happens only between the peer and the authenticator, e.g., establish unicast security association,
establish multicast or broadcast security association, setup TEK,TSK and so on, I don't think there is any problem. 

> conversation, not the consequences of the conversation.

[Qin]: Thank for your correcting me here, I misunderstand the consequence as EAP exchange. The consequnce really means results.

> needed by EAP pre-authentication transport, but that is orthogonal to

[Qin] I am quite confusing here, The main difference between the model Peer-CA-AAA and model Peer-SA-CA-AAA is
1.EAP conversation between the peer and the CA in the Peer-CA-AAA is performed over L3
2. EAP conversation between the peer and the SA in the Peer-SA-CA-AAA is performed over L2.
    EAP exchange between the SA and CA is performed over L3.

So in the model Peer-SA-CA-AAA, SA should play part of role of authenticator to translate the L2 EAP sigaling into L3 EAP signaling or the other way around.
Otherwise, When the credentials shared between the peer and the AAA are transported from the CA to the SA via the L3 EAP signaling, Why the SA can intercept the L3 EAP signaling and translated into L2 EAP signaling.

On the other hand ,if we assume the model(Peer-CA-AAA) totally fits in the figure 1, However according to the RFC5247, only lower layer operation is allowed between the peer and authenticator which can be seen in the section 2 of RFC5247:
"
   On the EAP server, keying material and parameters requested by and
   passed down to the AAA layer MAY be replicated to the AAA layer on
   the authenticator (with the exception of the EMSK).  On the
   authenticator, the AAA layer provides the replicated keying material
   and parameters to the lower layer over which the EAP authentication
   conversation took place
"
However in the current model(Peer-CA-AAA) of draft, the key materials is transported to the peer over the L3 signaling , I wonder Does it conflict with the RFC5247? So does the model(Peer-SA-CA-AAA).

---

From: Rafa Marin Lopez <[email-masked]>
Date: Thu, 19 Mar 2009 15:38:42 +0100

Glen,
> material (if any) it (the keying material) is out of the scope of EAP
[Rafa] See the title of RFC 5247: Extensible Authentication Protocol 
*(EAP) Key Management* Framework.

It seems you have not found text like this in RFC 5247:

"EAP keying material provided to a lower layer MUST NOT be transported
   to another entity.  For example, EAP keying material passed down to
   the EAP peer lower layer MUST NOT leave the peer;  EAP keying
   material passed down or transported to the EAP authenticator lower
   layer MUST NOT leave the authenticator.
"

This is only one example where it is explicitly mentioned about the keys 
exported to lower-layers , and elaborate some explanation and give even 
some detail. So basically I don't know what document you read to write 
these comments.

> ill-named)) 802.11 authenticator.
[Rafa] Take a look to RFC 5247, unless you don't consider this RFC as 
something related to EAP.

On the other hand, it seems from your comments that you have also the 
opinion that we cannot really know where the key material should go: 
maybe to the lower-layer of that EAP authenticator, maybe to other..., 
who knows?. Interesting uncertainty.
> Perhaps you're confusing EAP w/PANA, which appears to hang around
[Rafa] Thanks for your interest, but fortunately I am not confusing 
anything.

> So now we're reduced to taking illustrative figures as normative?
[Rafa] I have been following RFC 5247. Didn't I mention it?
> Which would have been helpful, had your explanation had anything to do with
[Rafa] Did I say that my explanation is based on RFC 5247: Extensible 
Authentication Protocol *(EAP)* *Key Management* Framework? Although, as 
said, it seems that you don't consider RFC 5247 related to EAP...

---

From: Rafa Marin Lopez <[email-masked]>
Date: Thu, 19 Mar 2009 15:42:19 +0100

Qin,
> [Qin]: For general case, the AAA functionality can be separated from 
> the authenticator, in this way, regardless of mode of authentication, 
> there are
[Rafa] Where have you read that in RFC 5247?. When the EAP authenticator 
in standalone mode, no AAA server or AAA functionality is involved.
> [Qin] Whether the AAA functionality is collocated with authenticator 
> or separated from authenticator, we can not deny the EAP conversation 
> only happens between the peer and AAA funcationality.
[Rafa] In standalone mode, there is no AAA functionality. For example, 
see Fig.4 in RFC 4137.
> What's the difference is for the standalone mode, the key materials 
> export happens using interal interface between authenticator 
> functionality and AAA functiality. Please remember the EAP exchange 
> happens between the peer and the AAA server which can be seen in the 
> section 1.6.1:
> "
[Rafa] Maybe here there is a confusion: "on the EAP peer and server" it 
is the EAP server, no the AAA server.
> > However If I interpret correctly, according to your comments, even 
> in standalone mode it seems that we cannot really know
> Firstly this sentence has never said that the EAP key materials should 
> go to this authenticator, shouldn't go to that authenticator. Never.
[Rafa] Never?. If no key material goes to that authenticator, how it is 
supposed to perform for example a security association protocol with the 
peer?.
> Secondly: the EAP method negotiation only happens between the peer and 
> the AAA, after successful negotiation of EAP method, the AAA server
> will generate keying materials shared betweeen the peer and the AAA, 
> e.g., MSK, EMSK.
[Rafa] In standalone mode, there is neither AAA functionality nor AAA 
server participates.
> Since the keying materials is shared between the peer and AAA,
> the AAA server should distribute this keying materials to the peer via 
> EAP exchange.
[Rafa] via EAP exchange?. The AAA protocol transports key material to 
the EAP authenticator in pass-through mode. In standalone mode the key 
material stays in the EAP authenticator.
> EAP is carried over the AAA protocol.
[Rafa] Correct, in pass-through mode. But No in standalone mode.
> As regarding when to distribute the keying materials to the 
> authentication, this sentence does not mention it.
> Also the AAA server can know where to distribute the keying materials 
> if the peer or the SA can tell the AAA the CA's location. It is not a 
> problem.
>
> > material certainly will be that EAP authenticator and NOT other. In 
> the pass-through mode the peer expects the same: the key material in 
> that EAP authenticator and NOT other.
> [Qin]: I have to point out again, the EAP is two parties protocol 
> which can be seen in the second paragraph in the section 1 of RFC5247:
> "
[Rafa] Let me say that "spoken between the EAP peer and (EAP) server."

EAP Server
      The entity that terminates the EAP authentication method with the
      peer.  In the case where no backend authentication server is used,
      the EAP server is part of the authenticator.  In the case where
      the authenticator operates in pass-through mode, the EAP server is
      located on the backend authentication server.

> "
> Key materials  management also happen between the EAP peer and server, 
> no matter what the mode of authenticator is, the key materials is 
> distributed from the AAA functionality to the peer.
[Rafa] There is no AAA functionality in standalone mode.
> of mode independence under your understanding of EAP mode independence?.
>
> [Qin]: The primary function of AAA protocol is the AAA funcationality.
[Rafa] According to RFC 5247 "the primary function of the AAA protocol 
is to maintain the principle of mode independence"
> That's to say, the AAA functionality is not affected by the mode of 
> authenticator or man in the middle. No matter what the mode of 
> authenticator is, the AAA functionality should perform EAP exchange 
> with the peer, the EAP exchange between the peer and the AAA for the 
> pass through mode should be same as the one for the standalone mode.  
> This is what I have stated for couple of times in the earlier emails.
[Rafa] Where is defined AAA functionality in standalone mode?
> Firstly the figure1 mainly focus on the regualr EAP authentication in 
> which one peer ,one authenticator, one AAA funcationality are involved.
> It seems not qualified as an authority to judge whether the 
> authentication for the inter-authenticator handover fit in the 
> figure1, in which more than one authenticators 
> Secondly on the other hand, the phase1b is optional not mandatory, 
> There are no texts to show it is mandaroty to require the AAA server 
> to distribute the keying materials to the same authenticator A after 
> the EAP exchange between the peer and the AAA server through the 
> authenticator A. There are many exceptional case
> When the peer moves between different APs within the same 
> authenticator, since the peer does not change the authenticator, the 
> phase1b is not necessary.
[Rafa] But this is not any counter example. You describe an 
intra-authenticator handoff. So the EAP authenticator already performed 
the phase 1a and (in the pass-through mode) the phase 1b to bring a key 
to the EAP authenticator. After this, EAP is not involved in any manner 
in each intra-authenticator handoff, so basically Figure 1 does not apply.
> *May I suggest to hold on this question to the IETF74 meeting for open 
> discussion? I have said that we need a offical discussion face to 
> face, do you agree? **I don't intend to refute your opinion any more, 
> It is only purely technical discussion. I respect everybody's opinon 
> from what I listen here. I will summarize all our issues on debate and 
> find the way to resolve it in this meeting. Your suggestions about 
> separation the model from the draft will be highly appreicated. Thanks!.*
[Rafa] I appreciate your respect. I also respect and appreciate your 
comments.

Thanks Qin.
>
> > Thus, in my opinion, I must say that the peer-SA-AAA-CA model DOES 
> NOT follow the model in section 1.3. In fact, the SA which is acting 
> as the EAP authenticator DOES NOT receive the key material but the CA, 
> which is NOT acting as EAP authenticator. However EAP 
> pre-authentication DOES follow that model in section 1.3.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 19 Mar 2009 12:21:58 -0400

Qin,

> [Qin]: I have to say what the section 1.6.1 tries to convery is the key materials derived from AAA server in the pass through mode is same as the key materials derived from the same AAA server in t…

I realized that you mention AAA functionality in the standalone mode.
This is not generic.  In general standalone mode does not require AAA
functionality.  

> establish multicast or broadcast security association, setup TEK,TSK and so on, I don't think there is any problem. 

It does break mode independence if a stanalone authenticator/server
exports keys to another authenticator to establish the 2nd
authenticator's lower layer security association, i.e., the
consequences of the conversation is different from what is expected by
the 1st authenticator which is standalone.  More specifically, the
peer expects that the EAP conversation that took place between the
peer and the 1st authenticator is to establish a security association
at the 1st authenticator's lower-layer, not at the 2nd authenticator's
lower-layer.  

This problem remains the same even if the 1st authenticator is a
pass-through authenticator because RFC 5247 also says in Section 2
(you also quoted it in your response below):

"   
   On the authenticator, the AAA layer provides the replicated keying
   material and parameters to the lower layer over which the EAP
   authentication conversation took place.  This enables mode
   independence to be maintained.
"

So basicaly a model that AAA/EAP server hands out key to an
authenticator (i.e., CA) without having done an EAP conversation with
that authenticator does not follow Figure 1 unlike EAP
pre-authentication.  So you can only qualify your model as proactive
key distribtution.

> 2. EAP conversation between the peer and the SA in the Peer-SA-CA-AAA is performed over L2.

Peer-SA signaling can be L3 as described in preauth-ps draft.

> So in the model Peer-SA-CA-AAA, SA should play part of role of authenticator to translate the L2 EAP sigaling into L3 EAP signaling or the other way around.

No, SA does not act as authenticator for pre-authentication. The
preauth-ps draft clearly says:

"
   The role of the serving authenticator in this pre-authentication
   model 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.
"

(You added the text based on agreement, didn't you?)

If you care calliing it SA, then we can call it entity F (e.g.,
Peer-F-CA-AAA model).

> Otherwise, When the credentials shared between the peer and the AAA are transported from the CA to the SA via the L3 EAP signaling, Why the SA can intercept the L3 EAP signaling and translated into…

SA is just forwarding EAP messages between peer and CA as a
lower-layer.  Lower-layers can encapsulate and transport EAP messages
by using any methods as long as they statisfies EAP lower-layer
requirements described in Section 3.1 of RFC 3748.

> However in the current model(Peer-CA-AAA) of draft, the key materials is transported to the peer over the L3 signaling , I wonder Does it conflict with the RFC5247? So does the model(Peer-SA-CA-AAA…

No.  The AAA layer in both Peer-CA-AAA and Peer-SA-CA-AAA EAP
pre-authentication models transports the EAP keying material from the
EAP/AAA server to CA.  Therefore, there is no conflict with RFC 5247.

Regards,
Yoshihiro Ohba

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 19 Mar 2009 11:54:56 -0700

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

...

> *(EAP) Key Management* Framework.

Just the first of the many technical errors in this pitiful document.

> some detail. So basically I don't know what document you read to write

You just quoted one (although you may, perhaps, be forgiven for
misunderstanding it since the authors often use the same terms to refer to
two entirely different things).  The terms "peer" and "authenticator" in the
above quotation refer to the _box_ on which the EAP peer and authenticator
run, not the EAP protocol entities (unless, of course you are claiming that
the cryptographic protestation of lower layer frames/packets is also within
the province of EAP).

> in

Only slightly, since cryptographic keys are a side-effect of some EAP
methods and not a part of EAP itself.

> who knows?. Interesting uncertainty.

It depends upon who "we" are.  In the case of a "standalone" authenticator
or an EAP peer, the key is delivered to the OS of the box upon which the EAP
authenticator is running; in the case of a "pass-through" authenticator, it
is delivered to a (usually but not necessarily) AAA client also typically
but not necessarily running on the same box as the EAP authenticator.  In
either case, the EAP entity has nothing to do with the key after it is
exported.  802.11 is a perfect example of this: a major purpose of the 4-way
handshake is to allow the 802.11 authenticator and peer to convince
themselves that a successful EAP authentication really occurred because the
actual EAP conversation takes place in (a variant of) 802.1X.  The only
indication that the 802.11 authenticator receives is a AAA message signaling
success and containing a key; the 4-way handshake is used to verify the
validity and freshness of the key.

...

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 19 Mar 2009 13:07:53 -0700

Yoshihiro Ohba [mailto:[email-masked]] writes:

...

> at the 1st authenticator's lower-layer, not at the 2nd authenticator's

More nonsense: EAP authenticators don't "expect" anything about what will
happen after the EAP protocol exchange completes.  How can you claim
otherwise?

> that authenticator does not follow Figure 1 unlike EAP

That's what your "erratum" to the RFC said, but that's not what the RFC
says.

> So you can only qualify your model as proactive
> key distribtution.

Except for the minor problem that authentication is required by the
P->SA->AAA->CA model, while the definition of proactive key distribution in
RFC 5247 specifically precludes authentication.  I know that this is
revolutionary, but has it occurred to you that perhaps the authors of 5247
were not omniscient, that there might be a type of preauthentication that
they hadn't thought of?

...

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 19 Mar 2009 17:04:00 -0400

> happen after the EAP protocol exchange completes.  How can you claim

Phase 2a for unicast secure association and optional phase 2b for
multicast secure association are expected after the EAP protocol
exchange.  That's what is described in RFC 5247, whether you accept it
or not.

> That's what your "erratum" to the RFC said, but that's not what the RFC

How can you interpret the above quoted text otherwise?

> were not omniscient, that there might be a type of preauthentication that

As I claimed that the new model is qualified as mobile-assisted
proactive key distribution, it's a small improvement, but not
revolutionally at all (sorry about that), to proactive key
distribution.  The assistance from mobile can help the AAA server to
distribute keys to appropriate CAs without relying on guessing about
the mobile's movement patterns.  I don't think peer authentication is
really required for the model.  Instead, just message authentication
to protect mobile-assisted messaging should be sufficient for that
purpose.  On the other hand, even with peer or message authentication
is used in the model, the security vulnerability of proactive key
distribution still remains the same, i.e., if one authenticator is
comprimized, it can collrupt the neighbor graph to distribute keys to
arbitrary authenticators, in the absence of spoofing detection within
the AAA infrastructure.

Regards,
Yoshihiro Ohba

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 19 Mar 2009 14:22:23 -0700

> exchange.  That's what is described in RFC 5247, whether you accept it

This is the definition:

   Secure Association Protocol
      An exchange that occurs between the EAP peer and authenticator in
      order to manage security associations derived from EAP exchanges.
      The protocol establishes unicast and (optionally) multicast
      security associations, which include symmetric keys and a context
      for the use of the keys.  An example of a Secure Association
      Protocol is the 4-way handshake defined within [IEEE-802.11].

It's clear that the secure association protocol takes place between the
_machines_ upon which the EAP entities run, not the EAP entities themselves,
unless you are claiming that the 4-way handshake is also part of EAP.

> How can you interpret the above quoted text otherwise?

It only makes sense that the keys are supplied to the lower layer, since
that's the only place they can be used, and further to the _same_ lower
layer (as opposed to some other).  What your quote doesn't say is where that
lower layer resides.  In the P->SA->AAA->CA model, the key(s) would go where
the peer specified.

...

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 19 Mar 2009 18:14:22 -0400

> unless you are claiming that the 4-way handshake is also part of EAP.

That's clear, but how does it change the point of debate based on RFC
5247?

> lower layer resides.  In the P->SA->AAA->CA model, the key(s) would go where

In the quoted text of RFC 5247 that, whichever lower-layer the key is
supplied to, it is *the lower layer over which the EAP authentication
conversation took place*.  Figure 1 and associated explanation in RFC
5247 is consistent in this regard.  On the contrary, in the
P->SA->AAA->CA model this is not the case if the key is supplied to
the lower layer of CA over which EAP conversation did not take place
prior to supplying the key to the CA.

Yoshihiro Ohba

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 19 Mar 2009 17:29:55 -0700

...

> That's clear, but how does it change the point of debate based on RFC

Ah, a light is beginning to dawn for me here: so it doesn't really matter
that the holy book uses precisely the same terminology for two entirely
different things because right-thinking people will interpret it the right
(your) way.  This would explain why it can be claimed that the keys must be
delivered to the lower layer on the CA even though no link between the MN &
NAP exists (in any of the models) & may never exist, according to the draft.
It's all becoming clear to me now & you're right: debate is utterly
fruitless, since it doesn't matter what the words actually say, what matters
is the right interpretation which I (having an incomprehensible addiction to
literalism) will never have.

> > > > > authenticator (i.e., CA) without having done an EAP
> conversation
> > > with
> > > > That's what your "erratum" to the RFC said, but that's not what
> the
> > > RFC
> > > > says.
> > >

So, tell me: which "lower layer" would that be in the case of the other 2
models?

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 20 Mar 2009 10:05:11 -0400

> So, tell me: which "lower layer" would that be in the case of the other 2

I see your point.  My answer is that the lower layer in the above text
is the one where the supplied key will be used.  So, in any of
P->SA->AAA->CA model and the other 2 models EAP conversation does not
happen over that lower layer.  However, in the other 2 models EAP
conversation does happen over other lower layer between peer and CA.

There is text in Section 4.1 of RFC 5247 that explains lower layer
difference in EAP pre-authentication:

"
   EAP pre-authentication differs from a normal EAP conversation
   primarily with respect to the lower-layer encapsulation.  For
   example, in [IEEE-802.11], EAP pre-authentication frames utilize a
   distinct Ethertype, but otherwise conforms to the encapsulation
   described in [IEEE-802.1X].  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.
"

So, in EAP pre-authentication, EAP conversation still needs to happen
between peer and CA prior to supplying the key to the CA's lower layer
that will use the key, but over a different lower-layer.

Yoshihiro Ohba

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 20 Mar 2009 12:17:21 -0700

Yoshihiro Ohba [mailto:[email-masked]] writes:

> > > > > exchange.  That's what is described in RFC 5247, whether you
> accept
> > > it
> > > > > or not.
> > > >
> > > > This is the definition:
> > > >
> > > >       An exchange that occurs between the EAP peer and
> authenticator
> > > in
> > > > It's clear that the secure association protocol takes place
> between
> > > the

First, let me apologize for my possibly overly sarcastic tone in the above;
my only excuse is that frustration overcame me.  In any case, the point is
not only that RFC 5247 is self-contradictory & consistently uses technical
terms inconsistently ;-), but that the establishment of a security
association (if any), along with key transport (if any) are outside the
scope of EAP & therefore irrelevant to the usage of EAP for
preauthentication.

> >
> > >
> > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > > This problem remains the same even if the 1st authenticator
> is
> > > a
> > > > > > >    On the authenticator, the AAA layer provides the
> replicated
> > > > > keying
> > > > > > >    material and parameters to the lower layer over which
> the
> > > EAP
> > > > It only makes sense that the keys are supplied to the lower
> layer,
> > > since
> > > > lower layer resides.  In the P->SA->AAA->CA model, the key(s)
> would
> > > go where
> > > > the peer specified.
> > >
> is the one where the supplied key will be used.  

I see.  So "same" means "same" unless it means "different"
So, in any of
> that will use the key, but over a different lower-layer.

It shouldn't be necessary to point out that in the quote above the term "EAP
preauthentication" is being used to identify a specific implementation of
preauthentication, rather than EAP preauthentication in general (much as
"EAP peer" and "EAP authenticator" are used to identify both EAP protocol
entities and the machines hosting those entities (sometimes in the same
sentence!).  This may not be an error, however, since section 4.1 also says:

   Since only the absence of an SSID in the Called-Station-Id attribute
   distinguishes an EAP pre-authentication attempt, if the authenticator
   does not always include the SSID for a normal EAP authentication
   attempt, it is possible that the backend authentication server will
   not be able to determine whether a session constitutes an EAP
   pre-authentication attempt, potentially resulting in authorization or
   accounting problems.  Where the number of simultaneous sessions is
   limited, the backend authentication server can refuse to authorize a
   valid EAP pre-authentication attempt or can enable the peer to engage
   in more simultaneous sessions than they are authorized for.  Where
   EAP pre-authentication occurs with an authenticator which the peer
   never attaches to, it is possible that the backend accounting server
   will not be able to determine whether the absence of an
   Accounting-Request was due to packet loss or a session that never
   started.

The statement that "only the absence of an SSID in the Called-Station-Id
attribute distinguishes an EAP pre-authentication attempt" in a RADIUS
accounting packet would seem to say that EAP preauthentication is synonymous
with 802.11 preauthentication (& that RAIDIUS is synonymous with AAA!); I
hope that the silliness of that proposition is self-evident.  In fact, it
just serves to highlight again the sloppy use of language that is prevalent
in the document.

I will point out, though, that one could state that the P->SA->AAA->CA model
"differs little from the model described in Section 1.3, other than in the
destination of the (optional) AAA key transport in phase 1b." but that would
be incorrect, since it actually differs not at all.

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 20 Mar 2009 12:40:03 -0700

...

> scope of EAP & therefore irrelevant to the usage of EAP for

Which, by the way, the RFC says itself in section 1.3.

...

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 20 Mar 2009 16:13:05 -0400

> scope of EAP & therefore irrelevant to the usage of EAP for

As you know, RFC 5247 is all about EAP *key management framework*
which includes all of those.

> be incorrect, since it actually differs not at all.

Ah, it is totally pointless of you to use optional phase 1b to justify
the P->SA->AAA->CA model!!  My original point has been that, in Figure
1 of RFC 5247, the phase 1a and phase 2b are not optional and happen
with the *same* authenticator (i.e., CA) in the case of EAP
pre-authentication.  In P->SA->AAA->CA, the phase 1a happens with SA
and phase 2a happens with CA, which is significantly different from
the model described in Figure 1 and its associated text described in
Section 1.3.

Thanks,
Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 20 Mar 2009 16:40:48 -0400

> the model described in Figure 1 and its associated text described in

s/phase 2b/phase 2a/.

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 20 Mar 2009 14:39:13 -0700

...

> > I will point out, though, that one could state that the P->SA->AAA-
> >CA model

That's what you say, but that's not what RFC 5247 says (actually, it's
really hard to tell _what_ it says except that its only model seems to be
taken from 802.11).

> In P->SA->AAA->CA, the phase 1a happens with SA

It seems that the major problem here is that I'm proposing a method of
preauthentication that didn't occur to the  (apparently not so omniscient)
authors of 5247.  I really don't understand why that should be a problem for
the hokey WG, though.

...

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sat, 21 Mar 2009 23:13:25 -0400

> really hard to tell _what_ it says except that its only model seems to be

It is clear from Figure 1.

> authors of 5247.  I really don't understand why that should be a problem for

The major problem is that you are trying to sell cats as dogs.

---

From: "Glen Zorn" <[email-masked]>
Date: Sat, 21 Mar 2009 21:45:09 -0700

> The major problem is that you are trying to sell cats as dogs.

Cute.  I don't know how much simpler it can be:  EAP authentication takes
place.  The authentication takes place before the MN arrives at its
destination, as does explicit authorization for the move & appropriate
keying material.  If that's not EAP preauthentication, what is?  Your entire
argument seems to be a) that it doesn't match the description of 802.11
preauthentication given in RFC 5247 (OK, fine, it doesn't) AND b) (this is
where the nonsense begins) that the model of EAP preauthentication described
in RFC 5247 is the ONLY acceptable model of EAP preauthentication that
exists now or ever will.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 22 Mar 2009 13:03:31 -0400

> keying material.  If that's not EAP preauthentication, what is?  Your entire

It is proactive key distribution, because EAP conversation does not
take place via the authenticator where secure association related to
the EAP conversation happens.  That's what Figure 1 of RFC 5247
clearly shows, and you keep ignoring it.  If you sell cat as cat then
no one will complain.  It's not even a hybrid of cat and dog, as EAP
authentication via SA is essentially unnecessarily in your model as I
pointed out previously.
 
Yoshihiro Ohba

---

From: Rafa Marin Lopez <[email-masked]>
Date: Sun, 22 Mar 2009 20:29:02 +0100

Hi Glen, sorry for my delayed answer. Please see below.
> the cryptographic protestation of lower layer frames/packets is also within
[Rafa] Actually, this does not change the question too much.

"EAP keying material provided to a lower layer MUST NOT be transported
   to another entity.  For example, EAP keying material passed down to
   the EAP peer lower layer MUST NOT leave the peer;  *EAP keying
   material passed down or transported to the EAP authenticator lower
   layer MUST NOT leave the authenticator*.
"

This text is clear. If you consider EAP authenticator "standalone", phase 2a happens with that authenticator (the one who participated in the EAP conversation as EAP authenticator) and NOT other; unless you consider the possibility that the key material (e.g. MSK) exported to that authenticator "standalone" is transferred to another different authenticator. However, this is *explicitly prohibited* from the above text.

Moreover, to preserve the EAP mode independence invariant, in the pass-through mode the same must happen. So phase 2a occurs with the authenticator that was involved in the EAP authentication and NOT other. As a consequence, phase 1b must also happen with the same authenticator that was involved in the EAP authentication and NOT other, to deliver a key to that authenticator in pass-through. This must happen in this way, unless you consider to break the EAP mode independence invariant in RFC 5247.

The Fig. 1 in RFC 5247 clearly reflects this.

Best Regards.

>>> Neither.  The keying material is exported & EAP ends.  That's all.
>>>       
>> Where
>>     
>>> the keying material goes is no affair of the authenticator; in fact,
>>>       
>> a
>>     
>>> well-designed method will use the same interface for export no matter
>>>       
>> what
>>     
>>> the destination may be.  Key transport (if any) and utilization is
>>>       
>> not the
>>     
>>> function of the EAP authenticator (as opposed to the (as it turns
>>>       
>> out,
>>     
> authenticator is running; 
> in the case of a "pass-through" authenticator, it