Subject: RE: multiple devices or multiple users ?

From: George Tsirtsis <[email-masked]>
Date: Mon, 7 Jan 2002 07:29:13 -0500

All,

I do not think the distinction between users and devices in the context of
PANA is useful. 

Authentication/security protocols tend to run between *elements* that
identify themselves according to the requirements of the protocol in
question. Users, devices, IP stacks are all *elements* that can use a given
security protocol. Think of IPSEC. Does IPSEC run between devices or between
users? Does it mater? Isn't that an implementation detail and a function of
who or what *element* owns the keys? Why should PANA be different? 

Say for PANA we use NAIs and Keys to identify end points (elements) We can
give these NAIs and Keys to both users and devices and indeed we can require
a device to do PANA on boot up, to get initial access to the network, as
well as require any user of that device to do PANA again to access the
network properly.

Am I missing something?
George

-----Original Message-----
From: Paal Engelstad [mailto:[email-masked]]
Sent: Saturday, January 05, 2002 10:14 PM
To: Hesham Soliman "ERA"; 'Yoshihiro Ohba'; Reinaldo Penno; Patil
Basavaraj "NET/Dallas"; 'PANA'; David Spence
Subject: Re: multiple devices or multiple users ?

Hesham, Yoshihiro Ohba,

These are not the only scenarios of the end system. I can at least see 8
possible scenarios: (1 user, many users) X (1 device, many devices) X (user
is authenticated, device is authenticated). 

Hopefully PANA will not have to come up with a protocol for that is designed
for a number of specific scenarios of how the end-system is organized.
Instead, I think we can abstract away from these details. From the top of my
head:

1) First of all, an ID identifies the user, an IP-address the device, and
KEYS and a security CONTEXT addresses the security of the authentication.
And there must be a binding between these identifiers. So the PAA only need
to deal with a number of:

(ID, IP-address, KEYS, optionally some context)

that is associated with the end-system.

 a) What hides behind an ID (e.g. a user, many users, a device, a software
module, etc) is system specific. I propose that this is out of scope of PAA.

 b) What hides behind an IP-address (e.g. a device, many devices, etc) is
also system specific. I propose that also this is out of scope of PAA. 

 c) What hides behind a key (e.g. one or many software modules for strong
encryption or one or many users for a password, or a combination) is also
system specific. I propose also that is out of scope of PAA.

 d) Since the PAA authenticates an ID, at an IP-address, with some KEYS of
an end-system CONTEXT information should only be concerned with HOW THE END
SYSTEM LOOKS FROM OUTSIDE, i.e. from PAA's perspective. 

Examples of contexts include:
-Home realm of user-ID, or information about Authentication Authority that
issued or administers the ID.
- Through which ARs does the end-system connect to the Access Domain
- How long are authentication-timeouts (e.g. long for passwords over fixed
lines, and short for device-assisted strong key security over wireless
links, etc.) 
- The end-system might want to bind its security association with the Access
Domain to its own set of interface IDs ???
- ...etc...

The same analysis can be done in the reverse direction where it is the
end-system that authenticates the PAA.

2) With this in mind, PAA should not be concerned with the internal
structure of the end system. PAA delivers the IP-packet (e.g. containing the
EAP-over-IP challenge, for example as in
http://search.ietf.org/internet-drafts/draft-engelstad-pana-eap-over-ip-00.t
xt) to the end system, and from then on delivering the packet to the right
place is the system's own problem. It's IP!!! If the packet arrives in the
end-system by a router, a host, a relay agent, or whatever... it is beyond
concern of the PAA and definitely beyond the scope of the PANA WG.

I don't say that my proposals above are the best. What I am saying is that
we can hopefully abstract away from the discussions in this thread in a
similar way as I have outlined above.

Paal

> 
> Fra: "Hesham Soliman (ERA)" <[email-masked]>
> Dato: 2002/01/05 Sat PM 02:33:29 CET
> Til: "'Yoshihiro Ohba'" <[email-masked]>, 
>    Reinaldo Penno
> 	 <[email-masked]>, 
>    "Patil Basavaraj (NET/Dallas)"
> 	 <[email-masked]>,
>    "'PANA'" <[email-masked]>,
>    David Spence <[email-masked]>
> Tema: multiple devices or multiple users ?
> 
> Obviously there is a difference between this 
> issue and the service-related discussion
> so I changed the thread. 
> 
> So, I think we can have several scenarios
> and I'll just mention a couple below:
> 
> 1. One device attached to the network and on
>    the other side of it, several devices are attached.
>    This is similar to the DSL case or the mobile 
>    networks case (monet). The devices on the other
>    side of the router can belong to the same user
>    or several. 
> 
> 2. One devices with several users.
> 
> 
> In case (1), there was a discussion on this list
> many months ago between Erik and I, in which Erik
> suggested that it should be the responsibility
> of the router (mobile router or DSL router) to
> authenticate the users attached to it, and that
> the ISP simply bills the owner of that router
> (DSL or mobile). I think this makes a lot of 
> sense. 
> 
> The alternative to that was to have some token
> that is authenticated and consequently authorised
> by the ISP's router to allow access. The idea
> was to allow each user to have his/her own 
> token. In this case the charging can be done per
> user. 
> 
> Protocol wise this would mean something like
> IP in IP tunnelling between the devices and 
> the default router. I'm not sure how realistic
> that would be. 
> 
> So, for case (2) basically, the only solution
> I can see is the token per user. So it is
> possible to do, without separating the port
> number space, but I haven't looked at that 
> in detail yet. 
> 
> Hesham
> 
> 
> 
> 
>   > -----Original Message-----
>   > From: Yoshihiro Ohba [mailto:[email-masked]]
>   > Sent: Friday, January 04, 2002 10:06 PM
>   > To: Reinaldo Penno; Patil Basavaraj (NET/Dallas); 'PANA'; 
>   > David Spence
>   > Subject: Re: DSL Scenario
>   > 
>   > 
>   > On Fri, Jan 04, 2002 at 03:50:48PM -0500, Yoshihiro Ohba wrote:
>   > > On Fri, Jan 04, 2002 at 10:42:22AM -0800, Reinaldo Penno wrote:
>   > > > Hello,
>   > > > 
>   > > > This goes back to the discussion on the meeting if
>   > > > PANA is directed to devices or users (real users). 
>   > > > 
>   > > > It seems that PANA is going to fit properly in a
>   > > > mobile world where you carry your device around and
>   > > > usually do not share it with anyone, but will have a
>   > > > hard time in broadband access if the model assume is
>   > > > 1:1 (one device, one user).
>   > > 
>   > > If my understanding is correct, the most flexible PANA 
>   > model assumes
>   > > m:1 (one or more devices, one user at the same time), but does not
>   > > assume 1:m (one device, one or more users at the same time). The
>   > 
>   > Correction: 1:m (one device, multiple users at the same time)
>   > 
>   > Yoshihiro Ohba
>   > 
>   > > reason for not assuming 1:m was discussed about six month 
>   > ago .  See
>   > > the following (BURP was the old name for PANA) which can 
>   > be also find
>   > > in http://www.toshiba.com/tari/issues.txt.
>   > > 
>   > > 
>   > --------------------------------------------------------------------
>   > > Issue #7: Is it possible to use BURP for sharing a single 
>   > IP address 
>   > >           but separating accounts among multiple users?
>   > > 
>   > > It is difficult for the following reason.  To support such a
>   > > capability, partitioning TCP/UDP source port numbers based on user
>   > > identity would be necessary.  However, this would impose 
>   > significant
>   > > modification in existing OS and application software to 
>   > support that,
>   > > which seems unacceptable.  So in the current requirement 
>   > this should
>   > > be avoided unless we see strong arguments or compelling need.
>   > > 
>   > --------------------------------------------------------------------
>   > > 
>   > > > 
>   > > > The DSL scenario described is very true today and
>   > > > applies to other access methods like cable, Ethernet,
>   > > > etc. In one household people have different needs. You
>   > > > can have for instance content filtering to the kids
>   > > > and not to the parents, and this is tied to the
>   > > > authentication/authorization. Same goes for other
>   > > > services.
>   > > 
>   > > If the above mentioned scenario is possible by using the 
>   > m:1 model, 
>   > > we can add the scenario to the draft.
>   > > 
>   > > > 
>   > > > Although PANA is directed to devices (on behalf of
>   > > > users), we should not assume that a device is owned by
>   > > > a single person. Since the PANA protocol is used for
>   > > > conveying information about the user, and not the
>   > > > device, it doesn't make sense to make a protocol tied
>   > > > to the device since different people using the same
>   > > > device can have very distinct rights and services.
>   > > 
>   > > 
>   > > It depends on the meaning of "different people using the same
>   > > device".  If it means that different people using the same
>   > > device *at the same time*, it is diffucult for PANA to support 
>   > > the model since it is 1:m model.
>   > > 
>   > > On the other hand, it would be easier for multiple users 
>   > to use the
>   > > same device at different times, which is m:1 model 
>   > instead of 1:m, and
>   > > PANA should work with those models.
>   > > 
>   > > 
>   > > Yoshihiro Ohba
>   > > 
>   > > 
>   > > 
>   > 
> 
>

---

From: John Schnizlein <[email-masked]>
Date: Mon, 07 Jan 2002 07:46:22 -0500

Not missing anything. 

I think this is the same point that Bernard Aboba made (maybe in a
different WG session) when he said that you only get trouble if you
try to specify authentication any more precisely than what/who RADIUS
authenticates.

Maybe including too much.

I thought the consensus was that PANA would not deal with key distribution.

John

---

From: Reinaldo Penno <[email-masked]>
Date: Mon, 7 Jan 2002 07:01:50 -0800 (PST)

Hello,

right, but it should not assume certain topologies or
impose (too many?) network restrictions. 

More philofically speaking, ISP/Carriers already have
PPP, IPsec, DHCP, etc and it's working today (this was
even discussed in the meeting). If we do not give them
a solution that is much better than whatever is out
there, what's the compelling reason to change? 

Do we want to present an alternative solution or a
better solution? IMO this is an important question.

I imagine for instance that with PANA, people will, in
theory, not need PPP authentication. In this case PANA
should cover whatever PPP authentication provides?
I.e. PPP authenticates users and/or devices. 

> who or what *element* owns the keys? Why should PANA

I'm not going to dwell too much here (this seems a
very good rathole) I would just like to point out that
IPsec started out as a method of encrypting packets
between two devices. There was no authentication of
users per se. 

But due to the demand of such a feature every single
IPSec vendor out there has some proprietary extension
to authenticate real users (just like in PPP, you are
presented with a "username" and "password" fields).

This was movement in the direction of "decoupling
users from devices"

thanks,

Reinaldo
 
> >   > -----Original Message-----
=== message truncated ===

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

---

From: John Vollbrecht <[email-masked]>
Date: Mon, 07 Jan 2002 13:31:12 -0500

I am a bit confused I think.   I agree that the distinction between users and
devices is not useful.
Something, (and element) a user or a device, proves it knows something - say an
id and pw.  The authenticator
signals that combination is "ok".

My confusion is - who does the authenticator signal?  What form does the signal
take (e.g. and EAP success or RADIUS Access Accept, or a Kerberos service
ticket).

Normally I would think of an authentication as "binding" a known user (or
device) to a port on an access device, or to a SSL session, or to a WEP key or
to a "ticket".  With the PANA discussion I am confused about this "binding".  I
get the idea that the purpose is to authenticate access to the net, but it is
not clear where the control (permit/deny) of the access will take place.

My impression is that the goal here is to create a generic way to authenticate
access to the network.  A model that includes a description of the "generic
players" in this would help me to think about the issues.  Is there such a
model?

-- John