ietf
[Top] [All Lists]

Re: [Full-disclosure] IPv6 security myths

2010-10-26 17:53:30

"Fred" == Fred Baker <fred(_at_)cisco(_dot_)com> writes:
    Fred> By the way, I don't buy the assertion that the PKI has to be
    Fred> global; if it did have to be global, I suspect one would have
    Fred> come into existence.

Quite a number of ideas and protocols have suffered because of the lack
of such a thing.  They haven't suffered so much as to cause such a thing
to be created, but I do want to point to Microsoft AD and suggest that
this system is pushing towards making such a system possible.  (I'm not
a fan.  Having to run AD to participate in a global PKI is something I
fear...) 

    Fred> If my system is supposed to talk with any system on the
    Fred> planet, then yes, my system's public key needs to be
    Fred> accessible to them and theirs to me, along with information
    Fred> that says what authentications I might have or they might
    Fred> have. The thing is - my system *isn't* supposed to talk with
    Fred> every system on the planet, and as a matter of fact most that
    Fred> want to initiate sessions with mine have no business doing
    Fred> so. So I don't need the keys of every system on the planet,
    Fred> and they don't need mine. Only the ones I want my system
    Fred> talking with.

I mostly agree, but:

    Fred> Consider the Smart Grid example in the appendix to
    Fred> http://datatracker.ietf.org/doc/draft-baker-ietf-core. The
    Fred> questions there include (a) what systems are authorized to
    Fred> communicate with systems in the home (HAN), and (b) what
    Fred> systems are authorized to communicate with systems in the
    Fred> Advanced Metering Infrastructure (AMI), which includes the
    Fred> Neighborhood Area Network (NAN) and related utility
    Fred> networks. It turns out that those are pretty closed

My problem is that the union of all of the people/machines involves is
essentially everyone.  While nothing in my HAN needs to talk to your HAN
in order for each of us to benefit from Smartgrid, the AMI/NAN has to
communicate with both HAN, so the identities asserted inside each HAN
have to be unique.
(A CERT or new RR in IPv6 reverse DNS work work wonderfully. Who signs
it, or whether self-signed is sufficient with return routing checks is
an open question)

    Fred> environments - I don't want the neighbor kid playing with my
    Fred> light switches, and the utility has some ideas about who
    Fred> should be able to play with its infrastructure. The few places
    Fred> where we allow someone to cross that boundary we control
    Fred> pretty tightly. Some utilities want the ability to directly
    Fred> control circuits in the home, to manage water heaters, air
    Fred> conditioners, thermal masses, or other specific things. They
    Fred> are only authorized to do so if there is a supporting
    Fred> contract, and that often (today) implies a separate meter that
    Fred> they can turn on and turn off. Other utilities want to be able

So, to support the utility doing this on a home-by-home basis, then we
need the homes uniquely identified (argues for IPv6 rather than OID
routing over NAT'ed IPv4).  Does the utility need to trust the home
(i.e. does the utility need certificates for the home entities)?
Not if the utility can reach out to the home in an active way.
Perhaps in the IPv4 NAT case where the utility has to be contacted
(polled).

Imagine that: security requirements are different if we assume IPv6 :-)

    Fred> to send price signals, which get interpreted by an energy
    Fred> management system within my home that might do something
    Fred> similar, or might do something less draconian but equally
    Fred> effective. For example, if my thermostat has multiple
    Fred> temperature settings (the ones at my house have morning, day,
    Fred> evening, and night settings), I might have a policy that tells
    Fred> the thermostat to control to a less rigorous (cooler or warmer
    Fred> depending on the time of year, and as a result more likely to
    Fred> be "off") setting when the price is "high". Either way, there
    Fred> are two systems I want accessing my meter - my energy
    Fred> management system and the utility's collector. The meter needs
    Fred> only the certificates that will allow it to talk with those,
    Fred> and anything else is TMI.

If I put two root PKI CAs into my thermostat, and you can put two
different root CAs into your meter, that's okay.  If either of those CAs
are in common, then that entity has to coordinate identities.  If one
collapses the hierarchy and one just inserts self-signed certificates
into the thermostat, most of the problems of coordination go away, but I
don't think the utility is going to like the maintenance issue.

    Fred> If someone isn't allowed to talk with me, there isn't a lot of
    Fred> value in being able to securely identify them. We can infer
    Fred> from the fact that I can't identify them that I'm not supposed
    Fred> to talk with them.

If you visit me as a house guest, your personal computing device is
going to want to reach out to my house system.  You won't be able to
communicate, as you indicate.  However, I want my house to accept and
store your certificate/identity such that I can now authorize you.
Again, does not require a global PKI if done right.  It's very
SPKI-like.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr(_at_)sandelman(_dot_)ottawa(_dot_)on(_dot_)ca 
http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
                       then sign the petition. 




_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>