Re: [mif] AD review of MPVD Architecture ***feedback needed from MIF working group participants ***

[Ted Lemon <[e-mail]>]

On Jan 10, 2015, at 8:21 PM, Dmitry Anipko <[e-mail]> 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.