Alper,
> 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.
That's good. It would also help to show the traffic authorized by PANA
in figure 1 - it flows from the PaC (must be the endpoint) through the
EP (must be on-path) and onward (down-arrow from EP box). While we're
dealing with this figure, I think the IKE/4-way handshake label on
the Pac-to-EP link needs to be changed to be consistent with Section
4's discussion of the various possible setup scenarios - use of IKE
is possible, but not required.
> > 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..
"are derived from successful PANA authentication" --> "are derived from
successful PANA authentication; these parameters are used to
authenticate
the PaC to the EP and vice-versa as part of creating the security
association."
"for how it is done with IKE" --> "for how it is done for IKE based on
using a key-generating EAP method for PANA between the PaC and PAA".
There are two points I'm clarifying here:
- PANA is the primary authentication. The output of that EAP method
serves to authentication the security association in the context
of that primary authentication (i.e., Pac and EP do not
authenticate
from scratch independent of the PANA authentication).
- Remove any possibility of confusing PANA's use of EAP with the ability
to run EAP between the PaC and EP (e.g., EAP can be embedded in
IKEv2).
> 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).
That's ok.
Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA 01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
[EMAIL PROTECTED] Mobile: +1 (978) 394-7754
----------------------------------------------------
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
