Subject: RE: Concerns about draft-ietf-pana-requirements-00

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 7 Feb 2002 18:59:32 +0100

> Yes.  Think IPv4.  Or is PANA only a solution for IPv6 problems?

=> For PANA we have to think IPv6 as well as 
IPv4. That is the foundation of the WG.

  > > => Clearly ? Some people don't see the point 
  > > of associating address allocation with authorisation.
  > > I don't think the association is so clear.
  > 
  > Yes.  Clearly.
  > 
  > For example, suppose an IPv4 ISP wants to grant differing sorts of
  > access to its customers, based on some sort of prior arrangement
  > (i.e., $$).  Some customers are given arbitrary addresses 
  > (IP address
  > pools, back-end DHCP allocation, per-port static addresses, et
  > cetera).  Some are given static addresses.  Some are given entire
  > subnets.
  > 
  > If authentication is divorced from address allocation, then how are
  > addresses properly allocated for customers of such an ISP?
  > 
  > Is this an unlikely usage scenario?

=> No, but clearly the entire business model
is based on lack of addresses. Think IPv6 as
well :)

  > > 1. I've got an address and I'm here
  > > 2. Do pana
  > > 3. PANA done 
  > > 4. I've got access.
  > 
  > As above, this seems to assume (at a minimum) an ISP that's 
  > willing to
  > hand out IP addresses to all users without bothering with
  > authentication at all.  

=> Yes. Having an address does not mean you have
access to anything except what the ISP
wants you to have access to. 

Perhaps that works in the infinite IPv6
  > address space (I count myself as no IPv6 expert), but I fail to see
  > how it works in the IPv4 address space.

=> I haven't been spending a lot of time 
thinking about how to solve it for IPv4, 
but can't you allocate the address for a short
period and refuse renewal unless the request
is authenticated ?
So: 

- get address for short period (20 seconds maybe)
- Do PANA: get LSA that can be used with DHCP servers
- renew address lease.

I do admit that people might still lump it
all into the DHCP server, but:

1. The architecture does not need to assume that.
   You can put all the processes in the network
   on one machine if you want
2. Most wide deployment of IPv4 nowadays seems 
   to be based on private addresses (don't know 
   about the US though) and there are lots of them.  

  > Sure, though without DHCP, you have to manually configure 
  > such things
  > as DNS server addresses.  Quite annoying.

=> Think IPv6: we need a generic solution.
If people don't want to deploy it for IPv4
fine. But we don't need to restrict the scope
just because we 'think' this will happen.

  > > => Of course it does! why is it a high hurdle 
  > > to install an application on my laptop, phone ...etc ?
  > > Or do you mean for network operators.
  > 
  > The oft-quoted zillions of PCs running out-of-date software 
  > is usually
  > an issue for new protocols.  This is the issue for 
  > obsoleting existing
  > link-layer authentication and replacing it with PANA.

=> Except for installing PANA on my laptop
and having my WLAN driver (which doesn't need 
PPP) what else needs to be obsoleted?

  > 
  > Are you referring to the 802.1X issue?  I still don't see how the
  > existing mechanisms fail in a way that cannot be fixed.

=> Then please do write a proposal on how to
fix them, and if that meets the requirements
then you will save us a lot of time.

  > > => No we will not use DHCP in all
  > > cases. UMTS allows stateless configuration,
  > > and proud of it :)
  > 
  > DHCP is not incompatible with stateless autoconfiguration.  It's a
  > matter of policy rules, not protocol.

=> Ah, you mean I can still buy a server
and keep it my network anyway, even though
I will not actually use it ?
Sure DHCP can co-exist in this case :)

  > > => Why is PPP there again ? this might be 
  > > a WLAN right?
  > > I don't mind the EAP part though.
  > 
  > Wrong.  I'm showing what the access situation looks like with a
  > point-to-point link in it, not a WLAN.  This is a perfectly 
  > reasonable
  > case, and has to be considered if the goal of the working 
  > group is to
  > unify the authentication mechanisms used for network access.

=> Well The scenario I'm thinking off involves roaming
between link X and link Y (different technologies). 
This means that PPP can not be assumed.

  > 
  > I have never said (nor will I say) that broadcast-type media should
  > use PPP.  They should not.

=> Sure.

  > 
  > Thus, we end up with PPP carrying EAP and, in other cases, PANA
  > carrying EAP.  Isn't this precisely the problem that PANA 
  > was supposed
  > to fix?  I'm arguing that this is a non-problem and doesn't 
  > need to be
  > fixed.

=> You mean EAP over PANA is already available ????
You've just proposed a solution for PANA. I think 
you really misunderstand what PANA is aiming at.
Again we do _not_ have to design a new protocol.
If EAP over IP/ICMP/UDP or whatever meets the 
requirement then let's do it. 
This was already said a zillion times.

  > > => Because you used EAP. The rest is not relevant.
  > > As I said (lost count) EAP is a potential
  > > solution.
  > 
  > No, by the requirements document, it cannot be a possible 
  > solution for
  > PANA.  EAP is an authentication protocol.  PANA is merely a carrier
  > for such protocols, as described in section 4.1.1 of the 
  > requirements
  > draft:
  > 
  >    PANA MUST NOT define new security protocols or 
  > mechanisms. Instead 
  >    it must be defined as a "carrier" for such protocols. PANA MUST 
  >    identify which specific security protocol(s) or 
  > mechanism(s) it can 
  >    carry (the "payload").
  > 
  > I agree that carrying EAP over PANA makes sense from many 
  > perspectives
  > and likely helps fix a number of existing problems.  That still
  > doesn't quite answer the question of what PANA really is.

=> OK so you're happy with EAP over PANA provided
that EAP meets the requirements ?
If so then I don't understand why we're
still arguing about this.

  > > => You're making too many deployment assumptions 
  > > that don't seem reasonable to me. Roaming between
  > > different access technologies is 'new' thing that 
  > > is hardly deployed anywhere. Operators want to
  > > spend money to deploy it...voila.
  > 
  > No, I'm not doing any such thing.  What I'm pointing out is 
  > that where
  > there are existing authentication mechanisms, those will have to be
  > supported.

=> We're not planning on twisting operator's 
arms. Let the market decide.

  > 
  > >   > I suspect that analogous situations will continue to be 
  > >   > true on other
  > >   > link layers in the future.  I think PANA should probably 
  > >   > consider the
  > >   > implications of being unable to send *any* IP frames 
  > until a link-
  > >   > layer authentication is performed.
  > > 
  > > => PANA does not eliminate link layer authentication.
  > > The point is that L2 authentication has nothing 
  > > to do with access levels or the user on the 
  > > device.
  > 
  > Yes, that's the crux of the issue.  Does PANA actually have anything
  > more to do with "users" than does existing link layer 
  > authentication?

=> It should.

  > 
  > I'm arguing that it does not.  Mere existence of an IP address on a
  > network does not imply the cardinality of humans behind it: 
  > there may
  > be zero, one, or very many users.  This has always been 
  > true with link
  > layer authentication (though much deployment-related handwaving is
  > done around the problem), and it's just as true for PANA.

=> That's why we want to authenticate based on the 
user identity. What's 'behind' the user's deivce
is their responsibility.

  > 
  > Given that they're really semantically equivalent, why 
  > separate them?

=> I don't get that at all. What is semantically
equivalent to what? user ids and link layer
ids? 
You mean if I have a GSM phone and I lend it 
to you after taking my SIM card out, I will
still pay for your calls ?

  > > We've already learnt from the cellular
  > > experience that this has its limits: works 
  > > on one link layer and does not allow roaming 
  > > without re-authentication AND we end up with
  > > operators having multiple authentication
  > > infrastructures. 
  > 
  > I'm arguing that the issue you're raising is quite separate from L2
  > authentication and PANA: that issue is caused by the use of 
  > disparate
  > authentication protocols ('methods') that run *over* these
  > mechanisms.  A fully agree that unifying these (or at least 
  > minimizing
  > them) is a helpful thing to network operators.

=> Great.

  > 
  > On the other hand, minimizing the transports used solves nothing in
  > particular.  It perhaps helps some implementors and probably hurts a
  > few others.  

=> Why does it hurt others ? Sorry if I'm being 
a bit slow with this.

It does *not* by itself in any way address the multiple
  > authentication infrastructures problem.

=> Well, if you run it over IP and remove 
the independence on the underlying technology
then I don't see how that cannot simplify
the existing infrastructure. The only 
reasons I see for different L2 authentication
schemes are:

1. Authenticating an interface (to make sure it's 
  not stolen perhaps)
 
2. Assuming that a 'special' user identity needs 
   to be associated with the 'special' L2. 

1 is valid 2 is bogus.

  > 
  > The analogy is to IP itself: IP's bits look slightly different on
  > every medium.  On some, it requires extra headers.  On others, it
  > requires manipulation of the data itself.  This isn't a bad thing.

=> Sure, but this has nothing to do with our discussion. 
Of course you need to adadpt the information to
the link being used, but you don't need to adapt
authentication. The point is: user authentication
is a function that has nothing to do with the
underlying link layer.

  > 
  > Perhaps not surprisingly (;-}), I think that PPP's architecture is
  > roughly correct.  Authenticate, then allow IP address allocation.

=> OK, perhaps because you don't consider other
new protocols like IPv6, and the opposite
would probably apply to my opinions. 

Hesham

---

From: James Carlson <[email-masked]>
Date: Thu, 7 Feb 2002 14:00:28 -0500 (EST)

> IPv4. That is the foundation of the WG.

Right.  So solutions that work well only with IPv6 would seem to be
ruled out.  Is that the case?

> is based on lack of addresses. Think IPv6 as

Right.  But does this mean that PANA should not support IPv4?  Or that
it should not work well there?  What exactly are you saying?

> wants you to have access to. 

Agreed; but the implications are probably different between IPv4 and
IPv6.

> - Do PANA: get LSA that can be used with DHCP servers

For IPv4, this has DOS problems, I believe.  The attacker is able to
acquire IP addresses without authentication.

>    about the US though) and there are lots of them.  

This is certainly not true in the US.  All of the ISPs that serve my
location (save one: AOL) supply public IPv4 addresses.  I'd be dead in
the water without that, as I'm using IPsec.  (That private addresses
are popular elsewhere is an interesting issue ...)

> just because we 'think' this will happen.

As I said before, I think that restricting the scope to just those
problems that are known not to be solvable using existing protocols is
likely to be a very good thing.

> PPP) what else needs to be obsoleted?

If unifying the authentication technologies relies on wide deployment
of PANA (which I dispute) and if PANA duplicates the role of
link-layer authentication (which I assert), then it's necessarily the
case that obsoleting the existing link-layer authentication mechanisms
in favor of PANA needs to be a goal, because you're left with
unnecessary duplicate otherwise.

Thus, if obsoleting these mechanisms isn't a goal of PANA, then either
unification doesn't happen or the already-muddied authentication
waters become denser.

It doesn't quite matter that *you* aren't running PPP on your laptop.
The fact of the matter is that providers do have PPP users.

> then you will save us a lot of time.

As posted before:

http://search.ietf.org/internet-drafts/draft-congdon-radius-8021x-17.txt

Does that not address the disparate authentication realms issue?

> Sure DHCP can co-exist in this case :)

No, that's not it.  The handling of IP addresses within a DHCP server
is a matter of policy.  If the client wants a particular address
(perhaps one that it has manually configured or acquired through other
means) and if the server permits it, then it can use that address with
DHCP.  One is *not* required to allocate IP addresses in a DHCP
server; allocation is a matter of policy.

> This means that PPP can not be assumed.

But it can't be assumed away, either.  In cases where PPP is present,
the drawing that I gave is accurate.  EAP can run over PPP, and the
NAS can relay that through AAA to a back-end server.  Once the
authentication data gets to the AAA server does it really matter
whether it was carried over some link-specific mechanism at some
point?

> => You mean EAP over PANA is already available ????

I'm assuming it into existence for the purpose of argument.  If it
exists, then it duplicates EAP on PPP.  This is necessarily true
because PPP doesn't exist on all link layers.

> This was already said a zillion times.

I'm saying that the disagreement occurs in part because the
requirements are _not_ so clear.

> that EAP meets the requirements ?

Sure, I'm happy with that.  PANA is a transport for authentication
protocols.  At this point, it frankly does not matter *what* protocol
runs over it.  Saying right now that EAP is the protocol that happens
to run over PANA doesn't actually solve the problem, but doesn't
obviously hurt anything either.

>   > more to do with "users" than does existing link layer 

How is the abstract notion of a "user" attached to any given IP
address?  It seems that you believe this to be a fundamental
requirement of PANA, and yet the current requirements draft says
something rather different (section 4.1.1 again):

   PANA MUST authenticate a PaC for network access. A PaC can be 
   identified by the credentials (identifier, authenticator) supplied 
   by one of the users of the device or the device itself. PANA MUST 
   only grant network access service to the device identified by the 
   DI, rather than granting separate access to multiple simultaneous 
   users of the device. Once the network access is granted to the 
   device, the methods used by the device on arbitrating which one of 
   its users can access the network is outside the scope of PANA. 

Where is the PANA requirement that "users" be the entities that are
authenticated?

> user identity. What's 'behind' the user's deivce

The draft requirements do not quite support this position.  The
working group charter has this:

  - A device (on behalf of a user) to authenticate to an agent in the
    local network.

In truth, I find that to be a bit vague.  Which user?

> still pay for your calls ?

If you replace the credentials on a link layer authenticator, is it
still the same link?  I argue that it is not the same link: by
replacing the SIM card, you're changing the identity of the link.

This is not the same as changing the identity of the human behind the
phone.  I can lend you my (hypothetical) GSM phone without pulling out
the SIM card.  Or, I can use multiple SIM cards myself (say, one for
work and one for play).

In any event, what's being authenticated there is not the user.  It is
the link.

> => Why does it hurt others ? Sorry if I'm being 

It hurts the ones who are forced to implement multiple mechanisms
(where only one is needed) and it hurts those who have to somehow
disambiguate the conflicts among the multiple mechanisms (what, if
anything, happens if my credentials over PANA are different from those
presented over the link-layer?).

>    to be associated with the 'special' L2. 

Point (1) is essentially it.

> is a function that has nothing to do with the

You do have to do this *if* you want to be able to authenticate before
passing IP packets.

> would probably apply to my opinions. 

No.  I think we need to consider *both*.  Solution that work only in
the context of IPv6 are non-starters, in my opinion.

-- 
James Carlson, Solaris Networking         <[email-masked]>
SUN Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677