Subject: Re: Re: List of Open Issues III

From: Paal Engelstad <[email-masked]>
Date: Fri, 15 Feb 2002 0:41:11 +0100

> James Carlson wrote:
> > subir Das writes:
...

> > >   authentication is successful. IMO, PAA trusts on Pac identifier not
> > > the
> > >   DI.
> > 
> > If the DI isn't authenticated, is it of any value at all?

Clearly. Integrity protecting the DI has been the intention all the way from the time DI was first mentioned. 

My initial hope was the DI be conveyed (implecitly or explicitly) to the other party either during Initial Authentication, or in a separate "round" after the Initial Authentication. (I am not saying that this necessarily is easy.)

IMO, you are right. DI must be integrity protected. Otherwise it's of no use!

Paal

> 
>   If you do the device authentication at the lower layer and then trust
> the 
>   Pac who provides you another indentifier for authentication. Is it not 
>   sufficient?
> 
> > 
> > The requirements draft actually states this:
> > 
> >    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.
> > 
> > Note that it includes the identifier as part of the credentials (which
> > is odd, since it's really an identifier, not an authenticator) and
> > that it at least *implies* that DI is part of the PAA's authorization
> > function.
> > 
> > Further, since the communication is between the PaC (which is
> > apparently identically the end-node), this DI value comes from the
> > PaC.  So why is it unauthenticated but trusted?
> 
>   Are you suggesting that we should do both device authentication as
> well 
>   as Pac authentication? 
> 
>   Subir
> 
>

---

From: James Carlson <[email-masked]>
Date: Fri, 15 Feb 2002 07:30:13 -0500 (EST)

Paal Engelstad writes:
> Clearly. Integrity protecting the DI has been the intention all the
> way from the time DI was first mentioned. 

That's good news.  The next question is: what is the source of the
bits inside the DI?  It cannot be the PaC: there are clearly things
intended for the DI (such as switch port number, which even an example
in the requirements draft) that are unknown to the PaC, and if the DI
is spoofed, there seems to be no reasonable way for a PAA to determine
that it's wrong.

There's thus a security relationship between the DI source and the
consumer.  The owner of the PAA doesn't necessarily have that
relationship with the PaC ("yeah, my telephone number really is
Klondike 5-1212"), but, with suitable mechanisms, he might with the L2
access device.

> My initial hope was the DI be conveyed (implecitly or explicitly) to
> the other party either during Initial Authentication, or in a
> separate "round" after the Initial Authentication. (I am not saying
> that this necessarily is easy.)

If the DI is supposed to come from the PaC, I'd argue that it's not
even possible.

-- 
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