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

From: "Glen Zorn" <[email-masked]>
Date: Fri, 19 Dec 2008 11:58:19 +0700

-----Original Message-----
From: Glen Zorn [mailto:[email-masked]] 
Sent: Friday, December 19, 2008 11:52 AM
To: 'Yoshihiro Ohba'
Cc: 'Qin Wu'; [email-masked]'
Subject: RE: [HOKEY] I-D Action:draft-ietf-hokey-preauth-ps-05.txt

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

> Glen,
> 
> This is a WG scope issue, isn't it?  We are working on EAP
> pre-authentication problem statement that is a work item of the WG.
> Qin's scenario is EAP-based proactive key distribution not EAP
> pre-authentication.  

That's your claim, but as I mentioned below I disagree.

> Since proactive key distribution is not in the
> scope of the WG, I don't see a point to including the scenario or even
> discussing it in this thread, so I will refrain from commenting on the
> scenario in this thread.

>From draft-ietf-hokey-preauth-ps-05.txt:

Abstract

   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.

The scheme I outlined previously does exactly this, so if it is out of scope
so is your draft.

> 
> Responding to your last comment bolow, I meant redirect case where AAA
> client can directly communicate with AAA server.

This is only possible if the AAA client and server are members of the same
realm, so your statement makes no sense.
.
> 
> I'll send a separate email for summary of the discussion based on your
> request.

Thanks!

...

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

---

From: Rafa Marin Lopez <[email-masked]>
Date: Fri, 19 Dec 2008 17:55:51 +0100

Hi Glen,

I was wondering whether it would not be easier a scenario where ERP is 
used between the CA (acting as authenticator) and the peer, through the 
SA. It would follow a known model for EAP pre-authentication as happens 
in 802.11i and it uses ERP to reduce the EAP authentication involved in 
the pre-authentication. As consequence, the distributed rMSK would be 
installed in the CA, so when the peer moves to the CA, it has to perform 
the security association protocol. In this way, ERP fits in the EAP 
pre-authentication problem statement as it is.

The scenario you mention requires to push a key to the CA (as proactive 
key distribution does), doesn't it?. To me, that might complicate things.

Best Regards.

-- 
------------------------------------------------------
Rafael Marin Lopez
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34968398501    e-mail: [email-masked]
------------------------------------------------------

---

From: "Glen Zorn" <[email-masked]>
Date: Sat, 20 Dec 2008 15:56:11 +0700

> pre-authentication problem statement as it is.

I'm sorry, I guess I wasn't really clear: my mention of ERP was purely
illustrative.  The point is that the model of peer<->SA<->[hokey
server]<->CA communication seems to me to be a perfectly viable one for
preauthentication (and actually compatible with the stuff we've already
standardized (i.e., a hokey server)).  As it stands, however, that model is
not included in the problem statement draft while the model you mention
explicitly is.

> key distribution does), doesn't it?. To me, that might complicate

I don't really want to discuss solutions (let alone implementation!) right
now, but I find it hard to believe that it would be more complicated than
requiring a many-to-many PANA infrastructure (esp. since AFAIK virtually no
one is shipping PANA).  That said, I'm not suggesting that the discussion of
the peer<->SA<->CA<->AAA model be removed from the draft, merely that the
set of models discussed is incomplete.

...

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 22 Dec 2008 00:19:18 +0200

> one is shipping PANA). 

Glen, you are not only talking about solutions, but even talking about
availability of commercial implementations! A far jump from a problem
statement document discussion :) I don't even understand what many-to-many
infra you are talking about. If you care to explain, we can better
understand the assumptions you have.

Alper

 That said, I'm not suggesting that the
> discussion of

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 22 Dec 2008 11:53:47 +0700

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

> statement document discussion :) 

Like I said, I don't want to talk about it (note that I didn't bring it up).
My point was (& continues to be) that the

SA <-> AAA (or hokey server) <-> CA

communication model is a valid one for preauthentication.

> I don't even understand what many-to-
> many

I don't care to, thanks -- maybe later :-).

...

---

From: Rafa Marin Lopez <[email-masked]>
Date: Tue, 23 Dec 2008 21:09:19 +0100

Hi Glen,

thanks for you answer and sorry for my delay. Please see my comments 
just below.

When I proposed the alternative of using ERP (also as an illustrative 
example) between the peer and the CA (acting as authenticator) through 
SA is because that is what I understood that EAP pre-authentication 
does. On the other hand, I always thought that, the type of scenario you 
propose (even before you mentioned it in the ML) was proactive key 
distribution and not EAP pre-authentication. But let me explain the 
technical motives of my reasoning.

RFC 5247 states

      In EAP pre-authentication, an EAP peer pre-establishes EAP keying
      material with an authenticator prior to arrival.  EAP
      pre-authentication only affects the timing of EAP authentication,
      but does not shorten or eliminate EAP (phase 1a) or AAA (phase 1b)
      exchanges;  Discovery (phase 0) and Secure Association Protocol
      (phase 2) exchanges occur as described in Section 1.3.  As a
      result, the primary benefit is to enable EAP authentication to be
      removed from the handoff critical path, thereby reducing latency.
      Use of EAP pre-authentication within IEEE 802.11 is described in
      [IEEE-802.11] and [8021XPreAuth].

Mmmm... it seems your scenario might fit in here. But let's "ask" to the 
candidate authenticator CA. The CA sees a key coming from the server 
without even running EAP. At least, we should agree that CA does not 
perform the EAP authenticator state machine at all, shouldn't we?. So, 
the CA "suddenly" receives a key for some particular peer without even 
running EAP. Mmmm... interesting. Let's take a look to the text of 
proactive key distribution in RFC 5247

Proactive key distribution
      In proactive key distribution, keying material and authorizations
      are transported from the backend authentication server to a
      candidate authenticator in advance of a handoff.

 >>Right, the candidate authenticator "feels" precisely this. In fact, 
the CA receives authorization information and keying material. Let's follow:

 As a result, EAP (phase 1a) is not needed,

 >>Right, at least under CA standpoint, it does not even perform the EAP 
authentication. That is, it received a key without even running EAP. 
Let's go on:

 but the Discovery (phase 0), and Secure
      Association Protocol exchanges (phase 2) are still necessary.
      Within the AAA exchange (phase 1b), authorization and key
      distribution functions are typically supported, but not
      authentication.

 >>Right. The CA sees AAA exchanges for authorization and key 
distribution functions but not for authentication. Thus, for the CA, it 
seems that everything is a consequence of a proactive key distribution 
process.

Ok, let's analyze the case I mention (and that you also agreed that 
should be considered as EAP pre-authentication). The case clearly 
involves an EAP authentication (phase 1a), in this case with the CA. 
This happens before movement to bring a key to the CA. The CA is 
involved in the authentication signalling and it clearly performs the 
EAP state machine, apart from receiving authorization and keys from the 
server. So it fits in the term EAP pre-authentication. Moreover, the 
involved parties, even the CA, know (without any doubt) that this is 
clearly not a proactive key distribution process.

Therefore, my conclusion is that, in the scenario you mention, the CA 
really believes that it is part of a proactive key distribution process 
(according to the definitions in RFC 5247) whereas in the scenario I 
mention, without any doubt,
CA can know it is taking part in an EAP pre-authentication process. To 
me, this is an indication that the scenario you propose is not EAP 
pre-authentication but a proactive key distribution process, where 
particularly the peer requests the server to proactively distribute a 
key to the CA.

---

From: Rafa Marin Lopez <[email-masked]>
Date: Fri, 26 Dec 2008 10:53:25 +0100

Hi Glen, all

It seems my previous e-mail has gone unnoticed. Probably because I used 
the same subject of a very long thread :). Let me change the subject to 
focus the technical discussion and copy my previous e-mail with some 
refinement.

When I proposed the alternative of using ERP (also as an illustrative 
example) between the peer and the CA (acting as authenticator) through 
SA is because that is what I understood that EAP pre-authentication does 
(peer-SA-CA-AAA). On the other hand, I always thought that, the type of 
scenario you propose (peer-SA-AAA-CA) (even before you mentioned it in 
the ML) was proactive key distribution and not EAP pre-authentication. 
But let me explain the technical motives of my reasoning.

RFC 5247 states

 >>Right, the candidate authenticator "feels" precisely this. In fact, 
the CA receives authorization information and keying material. Let's 
follow:

Therefore, my conclusion is that, in the scenario you mention, the CA 
really believes that it is part of a proactive key distribution process 
(according to the definitions in RFC 5247) whereas in the scenario I 
mention, without any doubt, CA can know it is taking part in an EAP 
pre-authentication process. To me, this is an indication that the 
scenario you propose is not EAP pre-authentication but a proactive key 
distribution process, where particularly the peer requests the server to 
proactively distribute a key to the CA. Therefore, I believe that the 
set of models already discussed in EAP pre-authentication PS is complete 
as it is right now.

---

From: Qin Wu <[email-masked]>
Date: Sat, 27 Dec 2008 11:18:59 +0800

Hi folks:
May I interrupt in? Comments in line!
-Qin
----- Original Message ----- 
From: "Rafa Marin Lopez" <[email-masked]>
To: "Glen Zorn" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, December 26, 2008 5:53 PM
Subject: [HOKEY] Is peer-SA-AAA-CA model EAP pre-authentication?

> (peer-SA-CA-AAA). 

[Qin]I think it works. In the model of (peer-SA-CA-AAA), the CA can be activated by the SA-CA signalling
and interact with the AAA/EAP server to obtain the keying materials.

>On the other hand, I always thought that, the type of 

[Qin] Actually EAP pre-authentication comprises of two parts:
1. Authentication between the peer and AAA/EAP server
2. Keying materials derivation and distribution.
What you conern here is whether the keying derivation and distribution in Pre-authentication can be viewed as proactive key distribution if the model of (peer-SA-AAA-CA) is applied for pre-authentication, am I right?

> perform the EAP authenticator state machine at all, shouldn't we?. 
[Qin] Let me try to understand the above paraghraph. In the model (Peer-SA-CA-model),
CA can be activated by the request from CA/Peer and run the EAP authenticator state machine for CA.
However in the model (Peer-SA-AAA-CA), there is no trigger from SA to activate the EAP authenticatior state machine of CA?
Is that your understanding?
So my question is 
Do you think only the SA can activate the EAP authenticator state machine of CA, is it possible for AAA to activate the EAP authenticator state machine of CA if we think state machine of CA must run before authentication?

>So, the CA "suddenly" receives a key for some particular peer without even 
[Qin] I am confused, Actually there are no solution for pre-authentication , only pre-authentication problem statement is ongoing.
Is it Proactive key distribution? What's the relationship between pre-authentication and proactive key distribution in your understanding?
What you explain here is if we use proactive key distrituion for pre-authentication, what will happen to pre-authentication?
Do you imply that if we does not change proactive key distribution to adapt to pre-authentiction, the proactive key distribution is not applicable to pre-authentication? 

> EAP state machine, apart from receiving authorization and keys from the 
[Qin]Do you think we can not make the CA involve in the authentication signaling if we apply the model (peer-SA-AAA-CA)?
Do you think the AAA can not help the CA to activate the state machine for EAP authentication?
> set of models already discussed in EAP pre-authentication PS is complete 
[Qin] I can not understand how could you get this conclusion? From my understanding,  your conlusion is that
the proactive key distribution is not applicable to Pre-authenticaion.

---

From: Rafa Marin Lopez <[email-masked]>
Date: Sun, 28 Dec 2008 02:01:36 +0100

Hi Qin,

> May I interrupt in? Comments in line!
Of course you can!. Mine are also inline
> and interact with the AAA/EAP server to obtain the keying materials.
[Rafa] Yeah, that is, without any doubt, EAP pre-authentication where, 
in fact, CA is involved in the EAP authentication signalling with the peer.
> What you conern here is whether the keying derivation and distribution in Pre-authentication can be viewed as proactive key distribution if the model of (peer-SA-AAA-CA) is applied for pre-authenti…
[Rafa] Sorry, but these parts you mention about what EAP 
pre-authentication comprises are too much general for me. I shall 
suggest to go into the details and implications (as you know, I went 
into details in posterior text :) ) in order to determine if simply 1. 
and 2. can be considered as EAP pre-authentication or not. In my 
opinion, that is not enough. For example, could you clarify how these 
steps are performed in which order, and which entities are involved in 
each step?. If you don't mind, could you explain it in base of Fig. 1 in 
RFC 5247?. I believe that could really help.
> Do you think only the SA can activate the EAP authenticator state machine of CA, is it possible for AAA to activate the EAP authenticator state machine of CA if we think state machine of CA must ru…
[Rafa]. The problem here, as I see it, is different.  When CA's EAP 
state machine is activated is with the purpose to perform EAP between 
the peer and the CA as, for example, it is defined in RFC 4137 (Fig.1  
for standalone and Fig.2 for pass-through). What do you achieve by 
activating the CA eap state machine from the AAA? I'm sorry but I don't 
understand it. Could you explain this a little bit more?

> [Qin] I am confused, Actually there are no solution for pre-authentication , only pre-authentication problem statement is ongoing.
[Rafa] To be more precise, "EAP" pre-authentication problem statement is 
ongoing. So we should agree on what EAP pre-authentication is, it 
implies etc... . Also we should agree on what proactive key distribution 
is , it implies, etc... in order to determine if peer-SA-AAA-CA model is 
EAP pre-authentication or not. My personal opinion here is, as I am 
trying to explain, that is not EAP pre-authentication but it is 
proactive key distribution.
> Is it Proactive key distribution? What's the relationship between pre-authentication and proactive key distribution in your understanding?
[Rafa] The relationship to me is that they are two different approaches 
to reduce the handoff latency. To me EAP pre-authentication has 
different implications than proactive key distribution. In fact, RFC 
5247 analyzes them in a separated section, which is completely correct 
to me.
> What you explain here is if we use proactive key distrituion for pre-authentication, what will happen to pre-authentication?
[Rafa] Sorry, but I don't understand the question here.
> Do you imply that if we does not change proactive key distribution to adapt to pre-authentiction, the proactive key distribution is not applicable to pre-authentication? 
[Rafa] I have basically referred to RFC 5247 where there is a clear 
distinction between EAP pre-authentication and proactive key 
distribution (for example, two separated paragraphs that I have copied). 
Let me insist on this, as far as I understand EAP pre-authentication and 
proactive key distribution, they are two different alternatives. I don't 
see the need of any change on none of them, because they work well to 
achieve a common purpose by two different ways.

> [Qin]Do you think we can not make the CA involve in the authentication signaling if we apply the model (peer-SA-AAA-CA)?
[Rafa] To me, definitely no. At least from my understanding of RFC 5247. 
In any case, could you please illustrate and specify how that is 
supposed to work? 
> Do you think the AAA can not help the CA to activate the state machine for EAP authentication?
[Rafa] As I said before, I don't understand this. The problem is not 
merely to activate the EAP state machine. The problem is for what the 
EAP state machine is activated. You activate the EAP state machine to 
perform EAP between the peer and the CA according to the model in RFC 
5247. In the model peer-SA-CA-AAA, clearly peer and CA performs EAP, in 
particular : peer acting as EAP peer :), CA acting as EAP authenticator, 
and AAA server acting as EAP server). Therefore, I cannot see how AAA 
activating the CA's EAP state machine can help in any manner.
> the proactive key distribution is not applicable to Pre-authenticaion. 
[Rafa]. My opinion, (e.g. based on the text of RFC 5247), is that 
proactive key distribution is an very valid alternative to reduce 
handoff latency but it is not EAP pre-authentication (that, btw, it is 
also a very valid solution for the same purpose). In particular, 
proactive key distribution consists of proactively pushing a key from 
the server (e.g. AAA) to a CA, where CA does not perform EAP.

As I said before, in the peer-SA-AAA-CA model: "...the peer requests the 
server to proactively distribute a key to the CA". It does not mean that 
it is EAP pre-authentication.

Therefore, as I see it, they are two different alternatives that try to 
achieve the same goal: reduce handoff latency by reducing authentication 
time. Thus, I don't see a need to "apply" proactive key distribution to 
EAP pre-authentication.

In particular, as far as I know, EAP pre-authentication PS defines the 
problem statement for EAP pre-authentication (if you'll forgive the 
repetition :)) and not for proactive key distribution.

---

From: "Glen Zorn" <[email-masked]>
Date: Sun, 28 Dec 2008 10:29:58 +0700

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

> Hi Glen, all
> 
> It seems my previous e-mail has gone unnoticed. 

Not unnoticed or ignored, but it is Christmas (a) & I have been a little
busy with administrivia.

> Probably because I used
> does
> running EAP. Mmmm... interesting. 

I'm completely confused.  I have no idea why you seem to believe that a
so-called "pass-through" authenticator is ever required to run the EAP state
machine or be at all involved in EAP.

> Let's take a look to the text of
>  >>Right, the candidate authenticator "feels" precisely this. 

How is this different from what happens in the situation you are promoting
as "real" EAP preauthentication?  In that case do the keying material &
authorization data appear after the handoff or appear by magic without the
need for transportation?

> In fact,

In actual point of fact, _all_ pass-through authenticators receive keys
without even "running" EAP; in order for the term "running EAP" to have any
meaning at all, the authenticator would need not only to validate the EAP
type in use but also the EAP method data.  In fact, however, as far as a
pass-through authenticator is concerned the contents of EAP packets (aside
from the Code, Identifier and Length fields) are completely opaque -- for
all it knows, it could be forwarding cookie recipes back and forth.  A
pass-through authenticator _never_ receives any indication that actual EAP
authentication has occurred since in some systems (IEEE 802.1Xrev, for
example, network access may be allowed even if EAP authentication fails or
never takes place (e.g., they _were_ cookie recipes ;-).

> seems that everything is a consequence of a proactive key distribution

See above. 

> involves an EAP authentication (phase 1a), in this case with the CA.

So you are saying that the CA MUST be a stand-alone authenticator?  If not,
see above.

> really believes that it is part of a proactive key distribution process

I'd rather not get into discussions about the beliefs of inanimate objects.

> pre-authentication process. 

No, no, no.  Please read RFC 3748.

> To me, this is an indication that the

Your logic is quite good; unfortunately, your initial premise (that an
authenticators somehow "knows" that it is involved in a valid EAP exchange)
is false.

---

From: "Dan Harkins" <[email-masked]>
Date: Sat, 27 Dec 2008 23:53:29 -0800 (PST)

Hi Glen,

> Rafa Marin Lopez [mailto:[email-masked]] writes:
[snip]
> machine or be at all involved in EAP.

  It has to be "involved in EAP" as far as it receives some EAP packet
encapsulated in some data transport protocol and the re-encapsulates
it into a different protocol destined for the AAA server. In fact, it
is the fact that it is "involved in EAP" that causes everyone to say it's
OK for the AAA server to take the key derived from EAP, a 2-party protocol,
and send it to the pass-through authenticator. If the pass-through
authenticator is not "involved in EAP" then it should not get keys created
from running EAP, a 2-party protocol.

  Since EAP pre-authentication "does not shorten or eliminate EAP (phase
1a)" then the scenario you're talking about, while very interesting,
doesn't sound like EAP pre-authentication. It certainly isn't what is
described as pre-authentication in [IEEE-802.11].

  Dan.

---

From: "Alper Yegin" <[email-masked]>
Date: Sun, 28 Dec 2008 23:39:06 +0200

If I'm understanding the proposal right, this is not pre-authentication at
all. 

The CA has nothing to do with EAP. It is not acting as "authenticator". For
that matter, it does not even qualify as being called "candidate
authenticator". It is just an intermediate key holder, which receives
EAP-generated key from "serving authenticator" and it may be generating that
key's children and pushing them to "candidate attachment points." 

You can think of it as another layer of key hierarchy between the MSK and AK
(if we were using IEEE 802.16e hierarchy, as an example).

Note though, this is nothing against the proposed optimization. There are so
many different type of optimizations possible. Each has its pros and cons,
and applicability. This is all about categorizing the optimizations, and I
agree with others that this is not pre-authentication.

Alper

---

From: Ashutosh Dutta <[email-masked]>
Date: Sun, 28 Dec 2008 18:21:05 -0500

I am in agreement with Alper, Dan, Rafa and others as well.

Let us not confuse optimization technique of distributing keys 
pro-actively with EAP pre-authentication technique although it could be 
applicable in some deployment scenarios and has its own complexity.

Thanks
Ashutosh

---

From: Rafa Marin Lopez <[email-masked]>
Date: Mon, 29 Dec 2008 01:31:02 +0100

Hi Glen,
> Not unnoticed or ignored, but it is Christmas (a) & I have been a little
No problem at all!!. Now it is also a nice time to discuss.
> machine or be at all involved in EAP.
[Rafa] Please check RFC 4137 (section 7) (pdf version is quite good: 
http://www.ietf.org/rfc/rfc4137.pdf). As you can see in Fig. 7 there is 
a pretty big picture of an EAP full authenticator state machine. The EAP 
full authenticator state machine represents both cases in EAP : 
standalone authenticator and pass-through authenticator. Here, we are 
talking about pass-through authenticator

Maybe your confusion could come because I didn't say EAP "authenticator" 
state machine but actually it seems  I said it :). If fact, I said that 
in proactive key distribution :"... CA  does not perform the EAP 
authenticator state machine at all".

Therefore,

In EAP pre-authentication, the CA runs the EAP "authenticator" state 
machine in pass-through mode and, as a consecuence of running it and by 
forwarding EAP packets between the peer and the EAP server (in the AAA 
server), receives keys and authorization data (e.g. look at 
aaaEapKeyData and aaaEapKeyAvailable variables in RFC 4137). That 
happens in the peer-SA-CA-AAA model.

In proactive key distribution process, the CA does NOT run anything 
related to EAP (e.g. nothing in RFC 4137) but receives keys and 
authorization data from the server. Thus, the CA is not even involved in 
authentication, as definition in proactive key distribution says. Let me 
copy the text again

Proactive key distribution
      In proactive key distribution, keying material and authorizations
      are transported from the backend authentication server to a
      candidate authenticator in advance of a handoff.  As a result, EAP
      (phase 1a) is not needed, but the Discovery (phase 0), and Secure
      Association Protocol exchanges (phase 2) are still necessary.
      Within the AAA exchange (phase 1b), authorization and key
      distribution functions are typically supported, but not
      authentication.  Proactive key distribution is described in
      [MishraPro], [IEEE-03-084], and [HANDOFF].

Then I will ask a few questions:

Do we agree that, in proactive key distribution, the CA does NOT perform 
the EAP authenticator state machine at all (that is, it does NOT act as 
EAP authenticator) and the CA receives authorization and key 
distribution without even running EAP "authenticator" state machine and, 
therefore, without even being a forwarder of EAP packets between the EAP 
peer and the EAP server?

Do we agree that is precisely what happens with the CA in the 
peer-SA-AAA-CA model?

Do we agree that, in the peer-SA-CA-AAA model, the CA performs the EAP 
authenticator state machine because it  is acting as EAP authenticator 
in pass-through mode, unlike what happens in the peer-SA-AAA-CA model?    

> authorization data appear after the handoff or appear by magic without the
[Rafa] As you may know, you do the keying material & authorization data 
appear in the CA after performing EAP through the CA acting as EAP 
authenticator (you know, there is an EAP peer, EAP authenticator and an 
EAP server). In other words, it is a consequence of the involvement of 
the CA in the EAP authentication as EAP authenticator. When I say 
involvement is that, without any doubt to me, in peer-SA-CA-AAA (already 
recognized by you as EAP pre-authentication) the CA performs EAP 
"authenticator" state machine in pass-through mode as described in RFC 4137.

Btw, see Fig. 1 in RFC 5247 about how the authorization and key material 
come to the authenticator after an EAP authentication.

I would like also to mention that text you are referring (and I pasted) 
is coming from RFC 5247 and it is pretty clear for me. However, do you 
see anything wrong in the text of RFC 5247 regarding proactive key 
distribution?

> type in use but also the EAP method data.
[Rafa] Based on my previous comments... is it more correct for you if I 
say (regarding the proactive key distribution) :

>> Right, at least under CA standpoint, it is not involved in EAP in any manner (neither as EAP authenticator). That is, it does not even run the EAP authenticator state machine or see any EAP packets at all.

Is that better?

>   In fact, however, as far as a
> from the Code, Identifier and Length fields)
[Rafa] Yeah!!! , so you recognize the CA has to perform some operations 
related with EAP in peer-SA-CA-AAA scenario (to me EAP 
pre-authentication). However, in peer-SA-AAA-CA (which is proactive key 
distribution to me) it does NOT ever happen in the CA :). In fact, in 
peer-SA-AAA-CA the CA receives directly the keys and authorization data 
without even seeing any code, identifier and length fields of EAP ;).

To me, this is a clear difference. And that is one difference between 
EAP pre-authentication (peer-SA-CA-AAA) and proactive key distribution 
(peer-SA-AAA-CA).

>  are completely opaque -- for
[Rafa] See above :).
> So you are saying that the CA MUST be a stand-alone authenticator?  If not,
[Rafa] No, I am not saying that! :). Please see also all my reasoning 
above. In fact, in the peer-SA-CA-AAA model (EAP pre-authentication), CA 
clearly performs the EAP authenticator state machine in pass-through 
model :).

However in the peer-SA-AAA-CA model you mention, we cannot say the same 
because the CA neither perform EAP authenticator state machine nor 
nothing related to EAP. The CA just only receives authorization and key 
material proactively from the AAA. From RFC 5247, that is proactive key 
distribution.
> I'd rather not get into discussions about the beliefs of inanimate objects.
[Rafa] Sorry but,... what do you mean? :). Discussions are nice to 
clarify things :). I will kindly repeat it again anyway but I will 
change the word "believes" because it seems you didn't like it :). Let 
me rephrase:

"Therefore, my conclusion is that, in the scenario you mention, the CA really believes that it is part of a proactive key distribution process" -->

"Therefore, my conclusion is that, in the scenario you mention, the CA does not run any EAP "authenticator" state machine and receives keys and authorization data from the server without even running the EAP
authenticator state machine which is what happens in proactive key distribution." 

better?

> Your logic is quite good;
[Rafa] Thanks!!.
>  unfortunately, your initial premise (that an
[Rafa] I clearly disagree :) because that is not my initial premise at 
all, as I have explained at the beginning of the e-mail. Sorry, if you 
got wrong about what my premises are. I hope I have clarified my point 
enough in this new e-mail. In fact, so far, I do NOT see how 
peer-SA-AAA-CA model can be EAP pre-authentication in any manner.
>>>> I was wondering whether it would not be easier a scenario where ERP
>>>>         
>> is
>>     
>>>> used between the CA (acting as authenticator) and the peer, through
>>>>         
>> the
>>     
>>>> SA. It would follow a known model for EAP pre-authentication as
>>>>         
>> happens
>>     
>>>> in 802.11i and it uses ERP to reduce the EAP authentication involved
>>>>         
>> in
>>     
>>>> the pre-authentication. As consequence, the distributed rMSK would
>>>>         
>> be
>>     
>>> I'm sorry, I guess I wasn't really clear: my mention of ERP was
>>>       
>> purely
>>     
>>> server]<->CA communication seems to me to be a perfectly viable one
>>>       
>> for
>>     
>>> preauthentication (and actually compatible with the stuff we've
>>>       
>> already
>>     
>>> standardized (i.e., a hokey server)).  As it stands, however, that
>>>       
>> model is
>>     
>>> not included in the problem statement draft while the model you
>>>       
>> mention
>>     
>>> explicitly is.
>>>
>>>
>>>       
>>>> The scenario you mention requires to push a key to the CA (as
>>>>         
>> proactive
>>     
>>> I don't really want to discuss solutions (let alone implementation!)
>>>       
>> right
>>     
>>> now, but I find it hard to believe that it would be more complicated
>>>       
>> than
>>     
>>> requiring a many-to-many PANA infrastructure (esp. since AFAIK
>>>       
>> virtually no
>>     
>>> one is shipping PANA).  That said, I'm not suggesting that the
>>>       
>> discussion of
>>     
>>> the peer<->SA<->CA<->AAA model be removed from the draft, merely that
>>>       
>> the
>>

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 29 Dec 2008 10:32:29 +0700

Ashutosh Dutta [mailto:[email-masked]] writes:

> pro-actively with EAP pre-authentication technique 

I couldn't agree more; as for confusion, please see my response to Alper.  

> although it could be

...

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 29 Dec 2008 10:32:29 +0700

all.

I can't speak for Qin, of course, but you're not understanding _my_ version
of the proposal (see below).

> The CA has nothing to do with EAP. It is not acting as "authenticator".

That depends upon how you define "authenticator".  IEEE 802.1X defines it as
"An entity at one end of a point-to-point LAN segment that facilitates
authentication of
the entity attached to the other end of that link"; RFC 3748 incorporates
this definition by reference but further qualifies it as "[t]he end of the
link initiating EAP authentication", while RFC 5247 (wisely, I think) dumps
the .1X definition but keeps the qualification.
draft-ietf-hokey-preauth-ps-05.txt just references RFC 3748 (a mistake, I
think, since it unnecessarily limits the scope of the document to LANs).  As
it is, it's clear that in none of the scenarios described by
draft-ietf-hokey-preauth-ps-05.txt is the CA acting as an RFC 3748
authenticator since it is assumed that there is no L2 connectivity between
the peer and the CA.  Even if we change the draft to use the least
restrictive definition of those cited ("The entity initiating EAP
authentication", from RFC 5247), it's not at all clear to me that that alone
would fix the problem.  Furthermore, I'm having a hard time understanding
your argument, since the existing draft explicitly states that "The role of
the serving authenticator in indirect pre-authentication is to forward EAP
pre-authentication signaling between the peer and the candidate
authenticator and not to act as an authenticator, while it acts as an
authenticator for normal authentication signaling."  Are you saying that
it's OK for the SA to be called an "authenticator" (although it's not acting
as one) but not for the CA?  If so, it seems to me that that assertion is a
lot more political than technical...

> For that matter, it does not even qualify as being called "candidate
> EAP-generated key from "serving authenticator" and it may be generating
> that key's children and pushing them to "candidate attachment points."

No.  The only real difference between the scheme I am proposing and the
standard EAP/AAA scheme is the target of the affirmative authorization
message from AAA.  There is no transfer of keys between the SA & CA.

> (if we were using IEEE 802.16e hierarchy, as an example).

No.  There are no more layers of key hierarchy needed (thank God! ;-).

> and applicability. This is all about categorizing the optimizations,

I'm not sure that I accept that premise, but even if I did I don't think
that it is possible to categorize things in any kind of valid fashion
without first understanding them.

...

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 29 Dec 2008 11:15:49 +0200

Glen,

> would fix the problem.  

RFC 3748 is clear with respect to what an authenticator is, through its
normative and descriptive text on the expected behavior from an
authenticator, and the diagrams. If your entity is not involved in EAP
messaging following those requirements, it is not an authenticator. I don't
think an unfortunate mention of "L2 connectivity" or "LAN" (which fail even
on well-accepted IKEv2 case) makes any difference.

> Furthermore, I'm having a hard time
> understanding

The I-D says, SA is acting as "authenticator" for EAP that involves access
to the serving network.
SA is not acting as "authenticator" for EAP that involves access to the
target network. In that sense, you can see the functionality of SA as
similar to what a base station does when it forwards the EAP messages to the
authenticator (NAS) sitting behind it. 

Sorry, this couldn't be more technical than that.

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

So you are talking about CA receiving MSK from AAA without being involved in
EAP at all. Right? 
Obviously that CA did not act as "authenticator" for the EAP exchange that
yielded that MSK. 

> without first understanding them.

I agree.

Alper

---

From: wuqin <[email-masked]>
Date: Mon, 29 Dec 2008 21:35:15 +0800

Hi, Rafa:
Thanks for your reply. Comments in line.
-Qin
----- Original Message ----- 
From: "Rafa Marin Lopez" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: "Glen Zorn" <[email-masked]>; <[email-masked]>
Sent: Sunday, December 28, 2008 9:01 AM
Subject: Re: [HOKEY] Is peer-SA-AAA-CA model EAP pre-authentication?

>>> the ML) was proactive key distribution and not EAP pre-authentication. 
[Qin]: I'm confused here. I can understand the CA is involved in EAP authentication with AAA, also I can understand the CA is involved in the SA-CA signaling with the SA, But given the model(Peer-SA-CA-AAA), I can not understand the CA could be invloved in the EAP authentication with the peer. I have to remind you in your model, two authenticator are both invloved in the relevant exchange. There are no direct signaling exchange between the peer and the CA.
> RFC 5247?. I believe that could really help.
[Qin]: Actually I try to figure out what your intention is here. if my understanding is correct, you try to convince folks that the model(Peer-SA-AAA-CA) is not pre-authentication. But your reason is not sufficient. All your proof is described as follows:
First you assume the model(Peer-SA-AAA-CA) applies the proactive key distribution mechanism for pre-authentication, 
And then you further lead us that the proactive key distribution mechnism can not work for pre-authentication for the proactive key distribution can not activate CA to perform EAP authentication signaling, therefore you get your last conclusion: the model(Peer-SA-AAA-CA) is not pre-authentication, Actually your conclusion is not concrete as you expect. The model(Peer-SA-AAA-CA) Glen raised is only a usage scenario, it is not a solution. Any key management mechanism can be considered in this model. Why you try to impose the proactive key distribution  to this model/
> understand it. Could you explain this a little bit more?
[Qin] RFC 4137 only points out authenticator's EAP state machine is required to be activated, not imply it is the CA to activate its state machine.
Also in exsiting RFC4137, it is not the serving Authenticator but the peer to activate the Authenticator to initialize the state machine. Since you extend
RFC4137 to make SA to activate CA, why not extend RFC4137 to make AAA to activate CA. I can not speak more details Because it is the solution scope, not problem statement scope.
> 5247 analyzes them in a separated section, which is completely correct 
[Qin]From my understanding, the proactive key distribution is only a different optimized approach from the different perspecive. It is intended to split the key
managment from authentication. On the other hand, Pre-authentication is intended to integrate key management with authentication. The Re-authentication does the same way. So don't confuse proactive key distribution with the pre-authentication together here.
>> Do you imply that if we does not change proactive key distribution to adapt to pre-authentiction, the proactive key distribution is not applicable to pre-authentication? 
[Qin] The signal you send the folks in hokey woring group is you impose the proactive key  distribution to the pre-authentication and mix them together, then try to
neglect the model(Peer-SA-AAA-CA).   
>>> proactive key distribution in RFC 5247
[Qin] I can not understand why you always link the proactive key distribution to the model(Peer-SA-AAA-CA)Glen suggests He just give us a scenarios. however
you try to mislead us to think the model and the proactive key distribution is the same thing.It is unfair. Why only your model(Peer-SA-CA-model) is possible, is the only choice? RFC4137 does not mention your model(Peer-SA-CA-AAA), RFC 4137 only focus on the general modle(Peer-Authenticator-AAA).
> In any case, could you please illustrate and specify how that is 
[Qin] RFC 5247 only provides two optimized approaches from the different perspective,i.e.,Proactive key distribution does not consider to perform authentication.
Pre-auth and Re-auth should both consider key distribution and authentication.
On the other hand, If my understanding is correct, RFC5247 does not provide the model(Peer-SA-CA-AAA), also does not consider inter-authenticator handover authentication problem. That's what EAP Pre-authentication Problem Statement want to further study. So I don't agree you make conclusion based on
RFC5247.
>>> set of models already discussed in EAP pre-authentication PS is complete 
[Qin]In your model, what's the role of SA? Actually the SA is used to activate CA to run state machine which is not mentioned in RFC 4137.
Also RFC 4137 only applies to the model(peer-authenticator-AAA), not the model(peer-SA-CA-AAA), If you want to conform to RFC 4137, you also need to
extend the model(peer-authenticator-AAA) to support your model, i.e., inter-authenticator handover model.
> repetition :)) and not for proactive key distribution.
[Qin] As I mentioned above, you try to mix the proactive key distribution with Pre-authentication. That's too sad.
Based on the text of RFC4137, your model does not fit in. The reason is RFC4137 does not consider mobility at that time.
Given the inter-authenticator handover scenario, the mechanism for the model (peer-authenticator-AAA)can not be directly used for preauthentication without  any change or extension.e.g., In the model(peer-SA-CA-AAA) two authenticator are involved in, in the model(Peer-SA-AAA-CA),the mechanism to activate CA maybe is needed. So each model has its disadvantage and advantage.:)

---

From: Rafa Marin Lopez <[email-masked]>
Date: Tue, 30 Dec 2008 18:46:33 +0100

Hi Qin,

many thanks for your answers!!!. Please see my comments inline.
> [Qin]: I'm confused here. I can understand the CA is involved in EAP authentication with AAA, also I can understand the CA is involved in the SA-CA signaling with the SA, But given the model(Peer-S…
[Rafa] First of all, I thought that we had agreed on that, at least, the 
peer-SA-CA-AAA model must be considered EAP pre-authentication no?. Am I 
wrong?.

In any case, in response to your comment, I don't know why you say that 
"I can not understand the CA could be invloved in the EAP 
authentication", referring to the model peer-SA-CA-AAA. In that model it 
seems clear to me that EAP peer is the peer, the CA is the EAP 
authenticator and the EAP server is in the AAA server. I believe you are 
confusing the "transport" (lower-layer) of those EAP packets between the 
peer and the CA, with EAP itself.

> [Qin]: Actually I try to figure out what your intention is here. 
[Rafa] My intention is that you kindly explained us in base of (e.g.) 
Fig. 1 of RFC 5247 how peer-SA-AAA-CA model is supposed to work. Would 
you mind to detail it? (phase 1a, phase 1b, etc...) With details the 
discussion will improve, without them it is going to be very hard to agree.

> if my understanding is correct, you try to convince folks that the model(Peer-SA-AAA-CA) is not pre-authentication.
[Rafa] Btw, I am NOT trying to convince anybody. I am only giving my 
technical (personal) opinion about what I think it is right.

On the other hand, in my opinion, peer-SA-AAA-CA model is not EAP 
pre-authentication but proactive key distribution. And this is what I 
have been trying to explain, my opinion by giving technical comments on 
that.
>  But your reason is not sufficient. All your proof is described as follows:
> And then you further lead us that the proactive key distribution mechnism can not work for pre-authentication for the proactive key distribution can not activate CA to perform EAP authentication signaling, therefore you get your last conclusion: the model(Peer-SA-AAA-CA) is not pre-authentication, 
[Rafa] I don't understand what you mean with "applies the proactive key 
distribution mechanism for pre-authentication". Could you ellaborate?
> Actually your conclusion is not concrete as you expect.
[Rafa] Obviously I disagree as I explained several times before.
>  The model(Peer-SA-AAA-CA) Glen raised is only a usage scenario, it is not a solution. Any key management mechanism can be considered in this model. 
[Rafa]. Any? Could you give us a few examples?
> Why you try to impose the proactive key distribution  to this model/
>   
[Rafa] I am not trying to impose anything. Basically I am saying that  
in peer-SA-AAA-CA model the AAA server is proactively distributing a key 
to the CA, without the involvement of the CA in EAP in any manner. In 
other words, you "push" (or proactively distribute a key) to the CA. 
That is proactive key distribution to me.

> [Qin] RFC 4137 only points out authenticator's EAP state machine is required to be activated, not imply it is the CA to activate its state machine.
[Rafa] Right, the RFC 4137 describes the authenticator's EAP state 
machine. But it seems you got wrong when I referred to RFC 4137. I 
referred to RFC 4137 in order to highlight that, in peer-SA-CA-AAA, the 
CA performs an EAP authenticator state machine because it is involved in 
the EAP authentication as EAP authenticator. In the peer-SA-AAA-CA model 
it does NOT ever happen, so nothing related to the EAP authentication 
happens in the CA where peer is going (potentially) to hand off.

Having said that, I would like to know "what do you achieve by 
activating the CA eap state machine from the AAA?".
> Also in exsiting RFC4137, it is not the serving Authenticator but the peer to activate the Authenticator to initialize the state machine. 
[Rafa] I think we have a different view. For example, in RFC 4137 there 
are a couple of variables that activates the EAP authenticator state machine

portEnabled (boolean)
Indicates that the EAP authenticator state machine should be ready for 
communication. This is set to
TRUE when the EAP conversation is started by the lower layer.

....

eapRestart (boolean)
Indicates that the lower layer would like to restart authentication.

What I see is "lower layer" but not "peer". Obviously in the other side 
of the EAP conversation the EAP peer state machine is also working to 
engage the EAP conversation. But that also happens with peer-SA-CA-AAA. 

> Since you extend
> RFC4137 to make SA to activate CA,
[Rafa]. Why do you mention that it is need to extend RFC 4137? It seems 
you get wrong because I am NOT saying that an extension is needed.
>  why not extend RFC4137 to make AAA to activate CA. 
[Rafa] Are you saying that RFC 4137 needs to be extended for 
peer-SA-AAA-CA model? Again, my question what is the objective of your 
extension? Maybe if you explain details how it may operate and the 
objective of that, I could understand it.
 
> I can not speak more details Because it is the solution scope, not problem statement scope.
>   
[Rafa] No, no, please, I am looking forward to seeing more details.  
That could help a lot to think differently. So , please , could you 
provide some details of it?.
> managment from authentication. On the other hand, Pre-authentication is intended to integrate key management with authentication. The Re-authentication does the same way. So don't confuse proactive…
[Rafa] I think I am not confusing (nor mixing) anything. I believed I 
was clear in my previous paragraph:

"The relationship to me is that they are two different approaches to 
reduce the handoff latency. To me EAP pre-authentication has different 
implications than proactive key distribution. In fact, RFC 5247 analyzes 
them in a separated section, which is completely correct to me".

--> Two different VALID approaches

> neglect the model(Peer-SA-AAA-CA).   
[Rafa] As I said before I am not trying to send any signal. I am only 
expressing my technical (personal) opinion.

Regarding to the other comment, have you seen my previous text? To me, 
they are two different approaches so I don't know how I am mixing 
anything. At least in my mind they are clearly separated: EAP 
pre-authentication and proactive key distribution --> two different and 
VALID alternatives to reduce handoff latency.

> you try to mislead us to think the model and the proactive key distribution is the same thing.It is unfair.
[Rafa] I am NOT trying to mislead anybody. I think I am FAIRLY 
expressing my opinion based on my technical understanding of EAP and key 
management. So, I shall kindly suggest to focus on technical comments, 
specific details and avoid this kind of comments.

>  Why only your model(Peer-SA-CA-model) is possible,
[Rafa] To be fair, it is not "my" model. It has been already designed by 
others and implemented in technologies such as IEEE 802.11. In the IETF, 
you can find also a few references.
>  is the only choice? RFC4137 does not mention your model(Peer-SA-CA-AAA), RFC 4137 only focus on the general modle(Peer-Authenticator-AAA).
>   
[Rafa]. Really, I don't think that RFC 4137 needs to be modified in any 
manner in order to the model peer-SA-CA-AAA operate. If you think so, 
what do you think it is required to modify (adding new states?, or 
variables? etc...).

<snip>
> On the other hand, If my understanding is correct, RFC5247 does not provide the model(Peer-SA-CA-AAA), also does not consider inter-authenticator handover authentication problem. That's what EAP Pr…
[Rafa] I mentioned RFC 5247 because from there (and from the rest of 
related literature) I usually extract my knowledge of EAP :). Taking 
into account that, my conclusions are those.

Btw, I agree that EAP Pre-authentication PS should reflect the problem 
statement of EAP pre-authentication. But it seems we disagree on what 
EAP pre-authentication is and implies.

> [Qin]In your model, what's the role of SA? Actually the SA is used to activate CA to run state machine which is not mentioned in RFC 4137.
[Rafa] To me, the SA is an entity that is carrying EAP between the peer 
and the CA during an EAP authentication that involves the peer (EAP 
peer), the CA (EAP authenticator) and the EAP server (AAA).

I don't know why you say that RFC 4137 needs to mention that. Could you 
ellaborate the reasons that you think RFC 4137 needs to be modified?

> extend the model(peer-authenticator-AAA) to support your model, i.e., inter-authenticator handover model.
[Rafa] To me, that's incorrect. Please see above.
> [Qin] As I mentioned above, you try to mix the proactive key distribution with Pre-authentication. That's too sad.
[Rafa]. As I said above. I don't think I am mixing anything, one thing 
is proactive key distribution (e.g. proactively distribute a key to CA, 
where CA does not even perform EAP) and another thing is EAP 
pre-authentication. I think the distinction is pretty clear.

> Based on the text of RFC4137, your model does not fit in. The reason is RFC4137 does not consider mobility at that time.
[Rafa] How did you get that conclusion based on the text of RFC 4137?.
> Given the inter-authenticator handover scenario, the mechanism for the model (peer-authenticator-AAA)can not be directly used for preauthentication without  any change or extension.e.g.,
[Rafa] What kind of change or extension?.

>  In the model(peer-SA-CA-AAA) two authenticator are involved in, in the model(Peer-SA-AAA-CA),the mechanism to activate CA maybe is needed. 
[Rafa] I disagree with this. In peer-SA-CA-AAA , as far as I can see  
(and under EAP authentication standpoint), there is an EAP peer (peer), 
and EAP authenticator (CA) and EAP server (AAA).

Regarding the the SA, I already defined the role of SA before. (from my 
understanding).

Btw, could you explain with detail what does "activate CA" mean in the 
model peer-SA-AAA-CA and how it would work?

Thanks.

> So each model has its disadvantage and advantage.:)  
>