Subject: Solutions ...

From: Erik Nordmark <[email-masked]>
Date: Mon, 14 Jan 2002 10:01:56 +0100 (CET)

Folks,

Given the work items in the charter it seems quite early to start discussing
solutions.
I'd much prefer if the WG woulf focus their energy on the scenarios and 
requirements to make sure we can produce the minimum set of useful stuff.
For instance, the model seems to be that the PAA can be either in the
first-hop router or further into the network. It would be useful for
us to understand the tradeoffs between those two approaches and
determine whether both are indeed required. (The generality might be
"useful" which is not the same as it being "required".)

Oh - and for those that can't stay away from thinking about solutions
even though it is a bit too early: 
As far as I understand the solutions that are being discussed
they don't talk about a way to detect when the client has been disconnected,
dealing with multiple access routers on the link, etc.
(Of course, I could be wrong.) 

   Erik

---

From: John Angelmo <[email-masked]>
Date: Mon, 14 Jan 2002 16:06:57 +0100

> (Of course, I could be wrong.)

First I'm not a guy creating protocols but more of a network/serveradmin
and user.

The latest problem that I had adding secure 802.11b access. 802.1X or
PPPoE was the two solutions I was looking at.
but since that access project is nationwide and auth traffic had to go
over diffrent ISPs to once central auth server, well radius was not an
option sice it's sent in plain text and secure radius options har vendor
dependent.
PPPoE seems to still be the best solution but still I can't sync all the
server configs in a good way and pppoe isn't so secure since anyone can
spoof PADT.
802.1X isn't that an option yet since it isn't implemented at a large
scale nad theres no free clients for FreeBSD or Linux.

Well that's what I hope that PANA can solve in a few years

/John

---

From: "Alper Yegin" <[email-masked]>
Date: Mon, 14 Jan 2002 11:44:39 -0800

Hi Erik,

> they don't talk about a way to detect when the client has been
disconnected,

I understand that for a network access architecture, we definitely need a
way
to detect client has disconnected. So that the network can cancel the access
granted to the disconnected client (for security, resource management
reasons..).

But, doesn't this go beyond "carrying authentication" that PANA is about?
I'm under the impression that client sending a message like "authenticate me
for
network access" is in the scope, but "stop the network access for me" is not
so (?)

Or, maybe we can see it like this:

- the initial PANA exchange can also be seen as both "authenticate me"
  and "provide me network access".
- another message can say "authenticate me and terminate my network
  access".

Is what you are suggesting this second type of message?

> (Of course, I could be wrong.)

Regards,

alper

---

From: John Angelmo <[email-masked]>
Date: Mon, 14 Jan 2002 21:01:31 +0100

> > (Of course, I could be wrong.)

If PANA handles both authentication and "deauthentication" we are
handeling one solution/protocol but if PANA only handles authentication
then we might end up with one solution from Microsoft one from Cisco one
for linux and so on and then we have to invent the wheel again with
"PANA 2.0"

I'm just a newbie here so I don't have the experience that you all got.

Regards,

John

---

From: Reinaldo Penno <[email-masked]>
Date: Mon, 14 Jan 2002 12:46:17 -0800 (PST)

I think Erik had a good point.

We should think about the deauthentication also,
otherwise we will end up with different solutions from
different companies (as pointed out) and/or a "new"
protocol to sync state between PPP/DHCP/Radius and
PANA to know when a user has disconnected.

regards,

-Reinaldo

--- John Angelmo <[email-masked]> wrote:
> > > they don't talk about a way to detect when the
> client has been
> > disconnected,
> > 

__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 15 Jan 2002 14:33:46 +0100 (CET)

> Well that's what I hope that PANA can solve in a few years

Fixing the security and reliability of Radius is what Diameter is doing - not 
PANA.
So clearly the best long-term solution is to use either 802.1X and/or PANA
from the client and then use diameter from there to the actual authentication
server.

One issue which isn't clearly understood (and is one of the deliverables
from the PANA working group) is what to do when 802.1X (or PPP) exists
and is usable - does it make sense to use PANA on top of that
(e.g. for authenticating a different notion of "user" than what 802.1X
would authenticate.)

But using PANA over the wide area has never been the intent.

  Erik

---

From: John Angelmo <[email-masked]>
Date: Tue, 15 Jan 2002 15:03:44 +0100

> But using PANA over the wide area has never been the intent.

So this is how it "should" "work": Client--(PANA)-->Server--->Diameter

PANA on top of PPP or 802.1X could make some sense.
PPP for link access and on top of that PANA to access services (ie
Internet)
OK not a good solution but putting PANA on top could create new
opertunities for poorly designed networks (Perhaps my network?)

Well as I said before I'm just a newbie here trying to help with what I
can

/John

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 15 Jan 2002 15:36:57 +0100 (CET)

> network access" is in the scope, but "stop the network access for me" is not

In scope - read the charter.
(Even though we tried we couldn't fit the whole scope description into 
the name of the WG :-) :-)

> Is what you are suggesting this second type of message?

That would be one approach (an explicit disconnect).
But if there is concern that a device might "disappear" (become unreachable)
and an attacker could continue to use the authenticated session somehow
then there would be a need to do rather frequent local reauthenticating (local
as in not involing the AAA).
If such frequent local reauthentication is there then the "disconnect"
could be implicit in the failure to send the reauthenticate message(s).
So that would be another possible approach.

  Erik