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

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 6 Mar 2002 17:19:08 -0800

I think that there is one other very important thing that PANA WG should
do:

Define the security requirements for PANA scenarios. 

This has turned out to be a very important issue, because EAP as it
stands is not suitable for use over the Internet or wireless media. This
is because the EAP conversation is not cryptographically protected, and
therefore may be attacked. Back in 1997 at the first EAP BOF, Jeff
Schiller commented on the need for cryptographic protection of the EAP
exchange.

I would also note that EAP key management has never been explicitly
addressed in a standards track document. 

Today we have multiple proposals for cryptographic protection of the EAP
exchange, and key hierarchy definition: PIC, PEAP, EAP TTLS -- but no
requirements to evaluate these proposals against. So fully understanding
the security requirements might enable us to understand the suitability
of these (and other) proposals. 

-----Original Message-----
From: George Tsirtsis [mailto:[email-masked]] 
Sent: Wednesday, March 06, 2002 2:02 PM
To: Pana (E-mail)
Cc: Basavaraj. Patil (E-mail); Alper Yegin (E-mail); 'Erik Nordmark';
Bernard Aboba
Subject: PANA based on EAP -OR- PANA vs EAP?

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: George Tsirtsis <[email-masked]>
Date: Thu, 7 Mar 2002 11:41:53 -0500

That is what I said. PANA can define requirements but most of the protocol
work, apart maybe from some new header type, needs to be done in EAP.

Note that the current PANA requirements document is IMO almost fully
satisfied by EAP. This either means that EAP as it stands is perfect or that
we have not gone far enough. The fact that we did not *assume* an EAP based
solution has something to do with this, since we could not benefit from
EAP's head start.

Also note that PANA is not wireless specific. IMO, from the point of view of
the IETF wireless links should not be different than broadcast links. The
question of "protecting" EAP has to be viewed from different angles:

From one point of view EAP is used as a bootstrap mechanism i.e.: you need
to do authentication and then do key distribution. In this case protecting
EAP is tricky since there are no keys prior to EAP completion! It is mostly
up to the actual *EAP method* used to protect itself and these are the
issues facing EAP when it is used in ways similar to PPP, 802.1X and any
other broadcast environment....On the other hand EAP is also used for
authentication to some remote system while access to internet infrastructure
is already available. In this case *EAP itself* may be protected and I think
IPSRA has produced something along these lines.

George

-----Original Message-----
From: George Tsirtsis [mailto:[email-masked]] 
Sent: Wednesday, March 06, 2002 2:02 PM
To: Pana (E-mail)
Cc: Basavaraj. Patil (E-mail); Alper Yegin (E-mail); 'Erik Nordmark';
Bernard Aboba

All,

Regards
George

---

From: George Tsirtsis <[email-masked]>
Date: Thu, 7 Mar 2002 11:54:23 -0500

Alper,

I am only saying that IMO it is unavoidable that the PANA payload will be
EAP. If most people agree with this we can move forward faster and focus on
how to make EAP the best protocol for our needs. 

The purpose of my e-mail was to test my theory that EAP is the solution. If
no one argues against this then we can use the IETF meeting to re-focus PANA
and thus be more productive.

Regards
George
-----Original Message-----
From: Alper E. YEGIN [mailto:[email-masked]]
Sent: Wednesday, March 06, 2002 9:56 PM
To: George Tsirtsis; Pana (E-mail)
Cc: Basavaraj. Patil (E-mail); 'Erik Nordmark'; [email-masked]
Subject: Re: PANA based on EAP -OR- PANA vs EAP?

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?

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 7 Mar 2002 09:08:00 -0800

The EAP BOF will largely focus on the revision to the EAP specification, RFC 2284bis, with some time set aside for discussion of crytographic protection of EAP and new EAP methods. One of the requirements for RFC 2284bis is that it be backwards compatible with RFC 2284. Therefore the focus of RFC 2284bis is on addressing interoperability issues, clarifying points of confusion for method implementors, and removing features which have not been implemented in at least two implementations, rather than designing an entirely new and incompatible "EAPng". 

There has also been discussion of some backwards-compatible extensions, such as a Vendor-Specific EAP method and Type Space expansion, to relieve some of the pressure off the EAP Method Type space, which is finite (one octet) and is being rapidly allocated by IANA (RFC 2284 did not contain an IANA considerations section). Currently it is not clear if these extensions belong in an RFC 2284bis document, or in a separate "EAP Extensions" document. If PANA has some additional requirements that seem relevant to all uses of EAP (as opposed to just the PANA encapsulation), then it would probably be worth understanding what those are. 

As the PIC, PEAP and EAP TTLS proposals show, it is possible to protect the EAP conversation by creating a protected channel and then conducting the EAP conversation within that channel. PIC does this over IP using ISAKMP; PEAP and EAP TTLS are EAP methods that accomplish this via TLS. One could also conceive of an EAP conversation carried over TCP/TLS as accomplishing the same thing. 

The summary is that there are many different ways to protect the EAP conversation, and in these situations, a logical question to ask is: "Which approach is better for PANA, and why?" This is where having security requirements becomes very helpful, since otherwise, it can be very hard to decide which approach is most appropriate. 

-----Original Message-----
From:	George Tsirtsis [mailto:[email-masked]]
Sent:	Thu 3/7/2002 8:41 AM
To:	Bernard Aboba; Pana (E-mail)
Cc:	
Subject:	RE: PANA based on EAP -OR- PANA vs EAP?

George

-----Original Message-----
From: George Tsirtsis [mailto:[email-masked]] 
Sent: Wednesday, March 06, 2002 2:02 PM
To: Pana (E-mail)
Cc: Basavaraj. Patil (E-mail); Alper Yegin (E-mail); 'Erik Nordmark';
Bernard Aboba

All,

Regards
George

---

From: "Robert Boxall" <[email-masked]>
Date: Thu, 7 Mar 2002 15:15:21 -0600

As with George's statements about EAP as solution. It seems to me that
the several PANA drafts seem to take the point of view that we simply
stick EAP directly on top of a protocol and then change EAP to meet the
needs of PANA. This seems to indicate that EAPbis can easily adopt these
changes and become the PANA solution. This also seems to imply that
security is EAP's own responsibly (I personally have no idea who owns
this).

Another approach (that I took, so its probably wrong :-(), as with
802.1x, is to create an EAP transport protocol that takes care of the
new features while encapsulating standard EAP. This method is more
compatible with 802.1x and the existing RADIUS servers (than the current
PANA drafts, but not a backwards compatible EAPbis). This approach could
also allow for a secure transport to be made between PAA and PaC and
still use all existing EAP methods without change. 

I guess either way is fine, the real goal here is that we must provide
secure EAP messages and also I would insist on mutual authentication as
a minimum. It could be that this is more about deciding whether EAP
security needs to be from end user to the RADIUS server, or from PaC to
PAA. The end to end (EAPbis domain IMHO) has strong merits but requires
RADIUS work. The PAA to PaC solution is good due to the ability to keep
current RADIUS EAP methods untouched.

Robert

ps. I am interested if there has been a discussion on the merits of a
encapsulated EAP transport layer that I missed? It is hard to keep up
with all of the messages and my work (and kids).