Subject: IP Header Compression over PPP - Working Group Last Call

From: Karl Fox <[email-masked]>
Date: Sun, 06 Jan 2002 22:59:10 -0500

This is last call.  I will advise the area directors that we want to take IP 
Header Compression over PPP (draft-koren-pppext-rfc2509bis-00.txt) to 
Proposed Standard on January 21, 2002 unless there is substantive comment 
raised on the list.

---

From: Luca Salgarelli <[email-masked]>
Date: 07 Jan 2002 12:16:41 -0500

Hello Karl.

I was wondering if there were any news on how to proceed with several of
the personal drafts that were presented at the 52nd IETF meeting, of
course including EAP-SKE.

My understanding was that there were no objections in taking on this and
other works as working group items.

How do we proceed?

Thanks
Luca

---

From: Thomas Narten <[email-masked]>
Date: Mon, 07 Jan 2002 16:51:51 -0500

> other works as working group items.

The IESG and some others have been discussing what to do about EAP. It
is far from clear that the PPPEXT should take on the work. Although
EAP has its origins in PPP (e.g., RFC 2284), the EAP-related IDS that
are being discussed now are pretty far removed from PPP. It is not
clear that the PPP WG has the desire or expertise to do these
documents justice (at least, that's what I think I heard Karl
saying!).

Stay tuned.

Thomas

---

From: Luca Salgarelli <[email-masked]>
Date: 07 Jan 2002 17:57:08 -0500

Hello Thomas.

> documents justice (at least, that's what I think I heard Karl

I understand. 

> Stay tuned.

Hmmm, would you be able to shed more light on what is going to happen
then? Judging from the number of EAP proposals, I think there is a clear
need for a forum where to do standardization work on EAP. 

In addition, I think that, as usual, time is critical, i.e. we need to
establish industry standards for EAP-XXX mechanisms as soon as possible.

Could you elaborate on what road the IETF will take, and its timeframe
in this field?

Thanks
Luca

---

From: Karl Fox <[email-masked]>
Date: Tue, 08 Jan 2002 07:57:13 -0500

At 04:51 PM 1/7/02, Thomas Narten wrote:
>Although

That's what I said at Salt Lake City, and that's what I intended to say to 
you in two e-mails since, Thomas, but I sent them to an old e-mail address.  
You should have them now--sorry about that.

Karl

---

From: Thomas Narten <[email-masked]>
Date: Mon, 28 Jan 2002 13:36:34 -0500

> need for a forum where to do standardization work on EAP.

Can you please clarify what constituency you represent here? I assume
it is IEEE from your draft. Right?

The reason I ask is that I understand that both IEEE and 3GPP have
expressed a need for the IETF to continue working on EAP.  IEEE 802.11
(Tgi) is in the process of drafting a letter to the IETF that
describes what it actually wants the IETF to do (it is not immediately
clear to some of us). I.e., pick one and standardize it?  Standardize
them all? Do a security review of them?  Etc. This was a topic at last
week's IEEE meeting.

3GPP is in somewhat the same boat, in that they have expressed a need
for the IETF to progress an EAP draft (i.e,
draft-arkko-pppext-eap-aka-01.txt). But some private conversations
that are going on between the IETF and 3GPP have raised the
possibility that a better approach may be acceptable, one that doesn't
rely on EAP. So the need from 3GPP is unclear at present.

Other than IEEE and 3GPP, what other constituencies have a need for
review of new EAP methods?

Thomas

---

From: Jari Arkko <[email-masked]>
Date: Tue, 29 Jan 2002 13:00:58 +0200

> rely on EAP. So the need from 3GPP is unclear at present.

The better approach vs. EAP affects a particular application.
Regardless of the final solution for that one application,
the EAP AKA and propably also EAP GSM drafts are still relevant
for other contexts. EAP AKA would though no longer have 3GPP urgency
requirements, and both drafts would be mostly regular IETF
drafts backed by their vendors, in this case Ericsson and Nokia.
Vendors likely want to ship some products at some not-so-distant
future, so interoperable and standardized solutions would be nice!

In conclusion, I still would like to advance
draft-arkko-pppext-eap-aka-01.txt somehow.

>I.e., pick one and standardize it?  Standardize
>them all? Do a security review of them?  Etc. This was
> a topic at last week's IEEE meeting.

I think the right answer here is standardize them all,
but of course with some review and understanding to
verify their relevance, security, etc. I'm not sure
*all* proposals to date fulfill these requirements, but
definately more than one does.

Jari

---

From: Jacques Caron <[email-masked]>
Date: Tue, 29 Jan 2002 12:13:52 +0100

What about creating a dedicated EAP WG?

Some work items for it:
- EAP methods (SIM, AKA, SRP...)
- EAP implementations (there's a rfc2284bis draft circulating, but also 
EAP/IP, EAP/ICMP (?), and I guess I will be sending EAP/UDP soon, and there 
might be some work needed for other media such as Bluetooth etc.)
- EAP extensions (I'm thinking of an "advice of cost" feature which would 
really need to be inserted in EAP to work)

Comments welcome,

Jacques.

>definately more than one does.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

---

From: Luca Salgarelli <[email-masked]>
Date: 29 Jan 2002 09:06:32 -0500

Hello Thomas.

> it is IEEE from your draft. Right?

No, I am not representing the IEEE in any way.

> them all? Do a security review of them?  Etc. This was a topic at last

Although I do not participate personally to IEEE's Tgi, my understanding
was that the IEEE will not standardize EAP methods. 

Nevertheless, with the rapid introduction of wireless services, it seems
that EAP will be one of the preferred base mechanisms that will be used
to perform authentication in IP wireless networks, particularly to
enable roaming. Given that EAP protocols are terminated between a client
and a AAA server, I would think that the IETF is the right forum to do
standardization on EAP protocols.

Judging from the number of EAP proposals that were submitted lately to
PPPEXT, it also seems that several vendors, included the one I work for,
are interested in these kinds of approach to client authentication.

What is your, and the IETF, opinion on creating a dedicated EAP working
group? I also subscribe to most of Jacques' interpretation on the
contents of such working group, in particular about the work on EAP
methods and EAP implementations.

Thanks
Luca

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 29 Jan 2002 07:52:47 -0800 (PST)

> I'm not sure *all* proposals to date fulfill these requirements, but

What are "these requirements"? Are you just talking about support for
AKA/GSM? Or are there other requirements, too?

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 29 Jan 2002 23:25:35 +0100 (CET)

> What about creating a dedicated EAP WG?

The key question is to determine both what type of deliverables
such a WG would have and also whether or not it will do security work
(defining new schemes for authentication as opposed to defining how to
encapsulate existing authentication schemes in EAP).

> - EAP methods (SIM, AKA, SRP...)

Would the intent be to document any EAP method after some review?
Standardize any proposed EAP method after review?
Or have requirements specifications for specific problems that need
to be solved, e.g. for 802.11 and/or 3GPP, and then find and standardize
one or a few methods.

> might be some work needed for other media such as Bluetooth etc.)

Carrying EAP over foo might be better done in the foo working group.

> really need to be inserted in EAP to work)

To what extent is "cost" an attribute of authentication?

There is also draft-aboba-pppext-key-problem-00.txt which might be a
worth-while problem to address.

   Erik

---

From: Jacques Caron <[email-masked]>
Date: Wed, 30 Jan 2002 23:35:48 +0100

At 23:25 29/01/2002, Erik Nordmark wrote:
>such a WG would have

First of all, I have to admit I am not familiar with the whole organization 
of IETF working groups, and all the formal requirements that go with them, 
which might explain my naïve idea that a simple "EAP WG" would be a cool 
thing :-)

>and also whether or not it will do security work

I think there is a need for a place for both. Don't know if that would fit 
in a single WG or several, though, but if the goal is to move things away 
from pppext since it really grew out of the PPP context, I guess one WG 
that would do "all EAP-related-stuff" would be better than nothing (or 
statu quo).

>Standardize any proposed EAP method after review?

I guess there is a need to at least have some review. Lots of drafts are 
floating out there as "orphans". Some are definitely good and/or needed. 
Others I don't know, but I guess they need to be evaluated.

>to be solved, e.g. for 802.11 and/or 3GPP, and then find and standardize

I was thinking a while back about creating a WG dedicated to public WLAN 
roaming (probably still a good idea), which would indeed define some 
requirements for new standards, among which some EAP-related work, but I 
think some drafts (e.g. EAP SRP, SIM or AKA) are quite evidently needed 
even outside this context (and go way beyond it).

>Carrying EAP over foo might be better done in the foo working group.

Are there IP and ICMP working groups? :-) Some EAP encapsulations might 
just be generic enough to not fit within any other working group. But I 
still have to read all the PANA stuff which might render those redundant :-/

>To what extent is "cost" an attribute of authentication?

It's indeed not an attribute of authentication, but a few things make me 
believe that it might be necessary to integrate it into EAP, for the 
following reasons:
- authentication is just one of the steps of a larger "bring up 
connectivity" process, which also includes authorization, accounting, and 
may indeed include "advice of cost" at an early stage
- cost may be based on the specific user being authenticated (based on the 
relationship between the foreign and home network, the rate plan the user 
subscribed to....).
- so, it needs to be after at least some information about the user is 
communicated (NAI to route it to its home auth server)
- actually preferably after the user is fully authenticated so this 
information is somewhat protected, or even encrypted if the auth allows 
generation of session keys
- EAP is the only end-to-end flow of information at the moment (between the 
user and its home authentication server)
- also, it is necessary that the user be able to actually refuse to start 
the communication if it does not accept the cost, i.e. before L2/L3 
connectivity is actually established (this by itself might cause the 
billing to start)

There are quite a bit of practical (read: backward compatibility) issues 
with this, which might require that this actually happen within an EAP 
method rather than in a generic fashion in EAP, but this is an altogether 
different topic...

Jacques.

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 30 Jan 2002 22:28:15 -0800

Jacques Caron [mailto:[email-masked]] writes:

...

> >to be solved, e.g. for 802.11 and/or 3GPP, and then find and standardize

I would think that a better approach would be to let the other groups tell
_us_ what they need -- otherwise there is the very real danger of starting
another PANA, redefining (or defining out of existence (?!)) the work of
those groups because the IETF has a better idea.

> roaming (probably still a good idea),

Not a bad idea at all -- too bad the roamops WG was killed before its time
;-)

...

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 31 Jan 2002 12:26:53 +0100 (CET)

> even outside this context (and go way beyond it).

Such WGs don't tend to work well.
It isn't the "scenario" that is important, be it satelite communication,
IP over wireless, or public WLANs. When new forms of communication add
new attributes or change the value range for existing attributes it
makes sense to have a WG looking at the problem.

Thus TCP over long delay links with or without packet loss makes sense.
Also, header compression over lossy links.

And looking at security issues for the case when everybody on the same
LAN are not trusted as much as they are in a university or corporate
setting also makes sense.
But whether this LAN is built using 802.11 or IP over avian carriers
doesn't have any bearing on the problem statement.

> still have to read all the PANA stuff which might render those redundant :-/

EAP over ICMP is a potential solution for PANA (even though the WG shouldn't
look at solutions right now).
Is EAP over IP the IPSRA PIC stuff or something else?

> method rather than in a generic fashion in EAP, but this is an altogether 

There has been some discussion of the above on the PANA mailing list, thus
it makes sense reviewed that if you didn't already see it.

  Erik