Subject: RE: List of Open Issues III

From: <[email-masked]>
Date: Thu, 14 Feb 2002 09:40:35 -0600

>List of Issues that are open/need clarification
>===============================================
>
>1 - Authorization (Open)
>
>Should it be in-scope? To what extent? 
>In a real network can we have a pure authentication protocol?

IMO, authorization is a complementary aspect of PANA. While it is true
that PANA provides a carrier for authentication information from the
client(PaC) to the PAA, there needs to be a provision in PANA that
allows the PAA capability for providing authorization for a service or
whatever is being requested by the client. 

>
>(Alper) Requirements draft has a position on this. Regarding more detailed
>authorization, my personal take is "not now, can be done later".
>

The framework for PANA should take into consideration how
authorization is handled. 

-Basavaraj

---

From: Paal Engelstad <[email-masked]>
Date: Fri, 15 Feb 2002 20:17:19 +0100

James,

> > The source IP address (if there's one), or the source mac address
> > can be used as a DI. These are implicitely carried 
> > (no additional payload).
> 
> There's no way that the source MAC address can be carried implicitly
> if there are any routers in the way.  Would that be a requirement that
> all roaming be done within a single bridged subnetwork attached to a
> PAA?

The DI is still a flexible placeholder for information that allows the other party to do packet policing. (PANA WG may put some constraints on type of information included later, though.)

In sitatuations where PAA and PaC are not on-link, link-layer information in DI has no meaning at all, or it is simply not used. The AR will have to police based on higher layer information, such as IP-addresses (and flowlabel, 5 tuples, etc.), which definitely has a meaning in those situations.

How to mandate what information shall be incorporated into DI, and when, is still not clear in my mind, though.

Paal

> There's also no way that any other link-associated information (such
> as switch port number, Calling Party Identification, or other outside
> data) could be carried past the first L2 hop unless it's in an
> explicit DI.  It's that bit that's a problem.
> 
> > > - Why should the PAA trust the end node to insert the right
> > >           DI?  Since this is the 'only' authentication to occur, and
> > 
> > Why do you trust authenticated nodes that they wouldn't
> > respond to arp on someone else's behalf? Same answer...
> 
> ARP security (or lack thereof) isn't really at issue here (though I
> agree it is a broader problem).  The issue at hand is why PANA is
> trusting the DI to be used for authorization decisions without
> authenticating the source of the DI data.  The requirements draft
> says:
> 
>    Device Identifier (DI)
> 
>          The identifier used by the network as a handle to control and  
>          police the network access of a client.
> 
> If this isn't from a trusted source, how can it be used to control or
> police anything?
> 
> And, for the bits that the PaC *cannot* know (such as switch port
> number), how does it work at all?
> 
> > >           succeeding grants full network access to the client,
> > >           couldn't the client lie about the DI in order to get access
> > >           on a "privileged" subnetwork?  (I know; this veers off into
> > 
> > Well, authentication succeeds, authorization fails. (remember the
> > binary result on authorization).
> 
> How is that the case?  The PAA doesn't have any direct knowledge of
> the actual L2 attachment in use.  According to the language in the
> draft, it has to believe that the PaC is telling the truth.  How can
> it validate any of the authorization information?
> 
> > >           authorization territory, but it's fundamental to the
> > >           architecture.)
> > > 
> > > Is the access node expected to augment the DI on the fly?  If it does,
> > 
> > During the PANA authentication, or after the authentication? Which
> > one is the issue here?
> 
> During -- when the first "please grant me access; here's my DI and
> credentials" message is sent by the PaC.
> 
> -- 
> 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
> 
>

---

From: George Tsirtsis <[email-masked]>
Date: Mon, 18 Feb 2002 07:56:05 -0500

All,

I am trying to catch up...have been away for a week.
From what I remember DIs are *optionally* carried in PANA...has anything
changed about this?

Thanks
George

-----Original Message-----
From: Alper Yegin [mailto:[email-masked]]
Sent: Saturday, February 16, 2002 12:54 AM
To: James Carlson
Cc: Pana (E-mail)
Subject: Re: List of Open Issues III

> > > - How does the end-node know the right link-layer information
> > >           to insert?  In some cases it may (its own MAC address,
> > >           perhaps), in other cases it might (its own telephone number
> > >           or E.164 address, though it probably cannot or should not
> > >           guess at the numbering plan at the other end of the link),
> > >           and in others it almost certainly cannot (the switch port).
> >
> > DI might be carried implicitely or explicitely. Requirements
> > draft doesn't say anything on this. Solutions probably have to.
>
> OK.
>

If PAA is one hop away from the PaC, then the MAC address is not a
problem. Depending on where the PAA is located (which can be set by
the PANA solutions) some types of DI might not make sense. I think
solutions have to define the types/families of DIs supported.

> explicit DI.  It's that bit that's a problem.

OK, so this suggests "Either PAA must be one hop away or certain
types of DIs must be carried explicitely". Fine.

> If this isn't from a trusted source, how can it be used to control or

I think you are suggesting that the DI should also be taken into
authentication calculations. So this leads to DI as explicit payload,
I guess.

> number), how does it work at all?

Hmmm, I'm not sure about this one...

> it validate any of the authorization information?

After a successful PANA exchange, PAA sets the access control
by communicating with L2 access devices. This should prevent
potential problems associated with the PaC lying about
its DI.... (if, I understood your concerns correctly :)

Jim, can you give us an example of how can a PaC can gain
benefit by lying about its DI... (for illustration)

> credentials" message is sent by the PaC.

alper

---

From: Paal Engelstad <[email-masked]>
Date: Thu, 21 Feb 2002 20:01:25 +0100

John,

> There was discussion on this list of different ways for the PaC
> to discover the PAA. The way DHCP does it is explicit configuration
> in the access router's relay agent of the address of the DHCP server.
> If the relay-agent approach is taken, this protocol is replaced by
> a required behavior in all access devices. Is there consensus for that?

In terms of discovery, it is far to early to talk about any consensus. I think the outcome of the discovery discussion was that it is too early to discuss it. Apart from that, I would not draw any conclusions. 

We need to work more on with requirements, framework, scenarios, 802.1x/PPP interaction etc. first.

Paal