Subject: PANA based on EAP -OR- PANA vs EAP?

From: George Tsirtsis <[email-masked]>
Date: Wed, 6 Mar 2002 17:02:03 -0500

All,

PANA WG has some very significant decisions to make during the coming
meeting of which the MOST important IMO is the following:

              "Is PANA going to be based on EAP or not?"

If the answer is "no" then the reasons will have to be understood and
documented and they better be good ones too. PANA will have a very hard time
convincing people this is the correct answer.

If the answer is "yes", as I also think it should be, then we have an
interesting situation that as a WG we have to accept and face up to; I
explain:

Reading the current set of PANA requirements and trying to apply them to a
solution based on EAP, one will quickly realize that most of the
requirements are covered by EAP already. Here are some examples:
-PANA must support mutual authentication
-PANA must support periodic and on-demand authentication
-PANA must carry success/failure indication
-PANA may use AAA but AAA is not assumed
-PANA should allow different types of identifiers
-PANA must support existing types of authentication (it does not define new
authentication protocols)
...and more
If you look at the list above you will realize that EAP covers all of these
things and more e.g.: session key distribution, replay protection etc etc.
And this is not accidental since EAP was designed with very similar
requirements in mind.

So, provided PANA decides to use EAP, PANA specific requirements that are
NOT covered by EAP are very, very few; the most important of which is a new
"type" field in some network layer protocol e.g.: new type for EAP over
ICMP; in a way similar to how IEEE802 and PPP have defined how EAP runs over
them. 

Additionally, PANA may create a list of requirements to EAP WG (currently
BOF). These new requirements would help EAP (which is still morphing itself)
to become a protocol that covers well the deployment scenarios that PANA is
interested in. The relation between PANA and EAP would then be somewhat
similar to that between NASREQ and AAA i.e.: PANA will provide access
specific requirements to generic EAP, the same way NASREQ provided NAS
specific requirements to generic AAA.

So, I am suggesting that PANA WG will serve the Internet community best if
it accepts EAP as its base, define a simple way to carry EAP over the
network layer (e.g.: ICMP) and then provide scenario specific input to EAP
WG before it wraps itself up. The alternative is that PANA will try to
compete with EAP, will replicate some of the things already done in EAP and
become one of these groups that create work for themselves just so they can
exist....and I am sure no one wants to end up like that :-)

Let me know what you think

Regards
George

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Wed, 6 Mar 2002 18:27:15 -0800

George,

>               "Is PANA going to be based on EAP or not?"

Why do we have to nail this down at the requirements/framework phase?
This is a task for the proposals to pick a "payload", and demonstrate how
it fits the requirements, unless we want to call this WG
"network layer carrier for EAP". Let the proposals address this.

> requirements are covered by EAP already. Here are some examples:

Yes, and that means EAP is a good choice as a payload.

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Wed, 6 Mar 2002 18:55:38 -0800

George,

>               "Is PANA going to be based on EAP or not?"

I think this is a question that needs to be answered by the protocol
proposals. They have to pick a payload, and demonstrate how
it fits the requirements. Are you suggesting we should set the
payload in the requirements draft?

> And this is not accidental since EAP was designed with very similar

So, this shows EAP is a good choice as a "payload".

> network layer (e.g.: ICMP)

Your suggestion is basically a "protocol proposal".

> and then provide scenario specific input to EAP
> WG before it wraps itself up.

I guess the concern is that if we end up with using EAP as the payload
(which you suggest is most likely), we might be too late to provide
requirements to EAP WG? What is the timeline of EAP WG (it's
just a BOF this time around)?

> The alternative is that PANA will try to

Nope :) This shouldn't be the case as PANA is not about defining the
security payload,
so it's not going to create competition for EAP.

> Let me know what you think

alper