[Pana] FW: Gen-ART review of draft-ietf-pana-framework-08.txt

["Alper Yegin" <[e-mail]>]

My response to David Black's e-mail.


-----Original Message-----
From: Alper Yegin [mailto:[e-mail]] 
Sent: Thursday, June 07, 2007 12:35 AM
To: '[e-mail]'
Cc: '[e-mail]'; 'Rafa Marin Lopez'; 'Yoshihiro Ohba';
'Mohan Parthasarathy'; '[e-mail]'; 'Mark Townsley'; 'Jari Arkko';
'Basavaraj Patil'
Subject: Gen-ART review of draft-ietf-pana-framework-08.txt

David,

Thank you again for the review.

>   Section 3 could use a discussion about the relationship of the
>   access network to the network that PANA controls access to.
>   Figure 1 ought to show the latter (accessed) network as connected
>   to the EP, and a two-cloud ASCII diagram would be very useful.
>   Among other things, this would make it clear that the access
>   network is in general a shared access network

Application of that concept to Figure 1 is tricky. The reason is, PAA may be
on either side of the boundary between the "access network" and "accessed
network." The only certain thing is that EP is on the border between the
two.

Unless anyone has a creative way to capture that in the figure, how about if
we make the following change to capture your feedback?

Change from:
 
      An EP must be located strategically in a local area network to
      minimize the access of unauthorized clients to the network.  It is
      recommended but not mandated that the EP be on-path between the
      PaC and the PAA for the aforementioned reason.  For example, the
      EP can be hosted on the switch that is directly connected to the
      clients in a wired network.  That way the EP can drop unauthorized
      packets before they reach any other client node or beyond the
      local area network.


To:

	An EP is located between the access network (the topology within
reach 
	of any client) and the accessed network (the topology within reach
of 
	only authorized clients). It must be located strategically in a
local 
	area network to minimize the access of unauthorized clients. It is
      recommended but not mandated that the EP be on-path between the
      PaC and the PAA for the aforementioned reason.  For example, the
      EP can be hosted on the switch that is directly connected to the
      clients in a wired network.  That way the EP can drop unauthorized
      packets before they reach any other client node or beyond the
      local area network.


>   Section 4 talks about authentication at two levels - the lower
>   level (link native or IPsec) and EAP over PANA.  It needs to
>   describe the recommended or required relationships between the
>   identities used for these authentications.  If there is no
>   relationship, there is a potential vulnerability (particularly
>   in the IPsec scenario) to a man-in-the-middle attack where the
>   secure channel ends are not at the PaC and EP.
> 
> The latter concern needs to be noted in the Security Considerations
> section, even if it is addressed elsewhere - the solution need
> not be in this draft, but the identity correspondence problem
> is an aspect of the PANA framework and needs to be noted as a
> security consideration.

How about if we modify the following paragraph

   In case cryptographic access control needs to be enabled after the
   PANA authentication, a secure association protocol runs between the
   PaC and the EP.  The PaC should already have the input parameters to
   this process as a result of the successful PANA exchange.  Similarly,
   the EP should have obtained them from the PAA during the service
   provisioning.  The secure association protocol exchange produces the
   required security associations between the PaC and the EP to enable
   cryptographic data traffic protection.  Per-packet cryptographic data
   traffic protection introduces additional per-packet overhead but the
   overhead exists only between the PaC and EP and will not affect
   communications beyond the EP.

To:

   In case cryptographic access control needs to be enabled after the
   PANA authentication, a secure association protocol runs between the
   PaC and the EP.  Dynamic parameters required for that
   protocol (e.g., endpoint identity, shared secret) are derived from
   successful PANA authentication. For example, see [I-D.ietf-pana-ipsec] 
   for how it is done with IKE. The secure association protocol exchange 
   produces the required security associations between the PaC and the EP to

   enable cryptographic data traffic protection.  Per-packet cryptographic 
   data traffic protection introduces additional per-packet overhead but the
   overhead exists only between the PaC and EP and will not affect
   communications beyond the EP.


Security consideration related text is distributed all across, due to the
subject of this document. That's why I prefer to handle this discussion
around the relevant text (as in above). 

Please let us know if these make sense.

Regards,

Alper




_______________________________________________
Pana mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/pana