On Jan 10, 2015, at 8:21 PM, Dmitry Anipko <dmitry.ani...@gmail.com> wrote:
> >>The ORO just lists options. There's no way to name a PvD. I vaguely
> >>recall that the idea here was to provide a per-PvD ORO, not list PvDs in
> >>the ORO.
> I’m leaving this item open for in this update, and suggest that the
> contributors who have suggested this text would comment.
OK. Does anybody know what the intent was behind this text:
One way to
restrict the propagation of information which is of no use to a
specific host is for the host to indicate the PvD information they
require within their configuration request. One way this could be
accomplished is by using a DHCPv6 ORO containing the PvDs that are of
interest. The configuration source can then respond with only the
requested information.
As I said above, this wouldn't actually be possible with DHCP OROs, but what's
being proposed here could in principle be done by providing separate OROs per
PvD.
> >>This would mean that any node that can authenticate the assertion of the
> >>PvD identity can also spoof it:
> What would be the change you propose?
I would just not mention shared-secret authentication. The way authentication
happens is really out of scope for this document anyway.
> >>What prevents this attack is not the provision of authentication
> >>information, but an explicit configuration on the client to reject this PvD
> >>if it is _not_ authenticated. The way you've stated it, it's fairly
> >>obvious that that's the case, but you don't actually say so.
>
> I’ve added a sentence, let me know if it doesn’t address your comment.
No, this change isn't quite capturing the point I was making. How about this:
Rogue configuration source: A compromised configuration source, such
as a router or a DHCPv6 server, may advertise information about
PvDs that it is not authorized to advertise. e.g. A coffee shop
WLAN may advertise configuration information purporting to be from
an enterprise and may try to attract enterprise related traffic.
This may also occur accidentally if two sites choose the same
identifier (e.g., "linsky").
In order to detect and prevent this, the client must be able to
authenticate the identifier provided by the network. This means
that the client must have configuration information that maps the
PvD identifier to an authenticable identity, and must be able to
authenticate that identity.
In addition, the network must provide
information the client can use to authenticate the identity. This
could take the form of a PKI-based or DNSSEC-based trust anchor, or
a key remembered from a previous leap-of-faith authentication of
the identifier.
Because the PvD-specific information may come to the network
infrastructure with which the client is actually communicating
from some upstream provider, it is necessary in this case that
the PvD container and its contents be relayed to the client
unchanged, leaving the upstream provider's signature intact.
_______________________________________________
mif mailing list
mif@ietf.org
https://www.ietf.org/mailman/listinfo/mif
