Loading ...
Sorry, an error occurred while loading the content.

Re: double sorry [bacnet-it-wg] What was all that back there?

Expand Messages
  • Dave Robin
    Ouch! My bad. I m so used to addressing BACnet emails to Frank S.... SORRY CHARLES! (my own father s name!) Dave now-I-owe-two-rounds Robin
    Message 1 of 1 , Sep 23, 2010
    • 0 Attachment
      Ouch! My bad. I'm so used to addressing BACnet emails to Frank S.... SORRY CHARLES! (my own father's name!)

      Dave now-I-owe-two-rounds Robin


      On Sep 23, 2010, at 11:25 AM, Chandrashekhar Appanna wrote:

      > s/Frank/Charles :)
      >
      > Regards,
      > Chandra.
      >
      > ----- Forwarded message from Dave Robin <yahoo@...> -----
      >
      >> Authentication-Results: rtp-iport-1.cisco.com; dkim=hardfail (body hash did not verify [final]) header.i=@yahoogroups.com
      >> DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=lima; d=yahoogroups.com;
      >> b=UwJISPf9cPH0s6P84N8B9EhsreNjZsa27an3MX+Ol3+xPOVk3ZkVx/ZEC3Fk9KZ/UL6QWMZUUeowIOfrebb7kaJiAHvVdmSs+GI94S7IqZCo+fDhspHpKHaLZg9JcJVj;
      >> To: bacnet-it-wg@yahoogroups.com
      >> From: Dave Robin <yahoo@...>
      >> Mailing-List: list bacnet-it-wg@yahoogroups.com; contact bacnet-it-wg-owner@yahoogroups.com
      >> Delivered-To: mailing list bacnet-it-wg@yahoogroups.com
      >> List-Id: <bacnet-it-wg.yahoogroups.com>
      >> Precedence: bulk
      >> List-Unsubscribe: <mailto:bacnet-it-wg-unsubscribe@yahoogroups.com>
      >> Date: Thu, 23 Sep 2010 11:18:36 -0400
      >> Subject: [bacnet-it-wg] What was all that back there?
      >> Reply-To: bacnet-it-wg@yahoogroups.com
      >>
      >> BACnet-IT folks,
      >>
      >> As is so often the case when two people vary familiar with a topic seem to be arguing about a fundamental issue, there is some kind of reference point difference at work. I believe that was all there was to my disagreement with Frank on the call yesterday.
      >>
      >> Ironically, this isn't an argument about TLS at all. But that was actually the source of my concern. I thought it was being portrayed that "TLS", or the "use of certificates" automatically supported the feature of "if one is compromised, only that one is compromised", and that is what I objected to because of possible deployment scenarios where that isn't actually the case.
      >>
      >> The thing to separate here (that wasn't made clear in our discussion, hence the problems), is that the "acceptance" of a certificate is not done by TLS at all. TLS merely establishes the tunnel and then hands whatever client certificate it received to the server *application*. This is why the acceptance criteria, the depth to follow the signing chain, the collection of root certificates, etc., is all done by your web server or your email *application*, not by the TLS code (you don't give a new root certificate to Windows, you give it to IE or Firefox). For example, it's application code in the browser that checks whether the server's CN equals the URL, and application code in the server that checks whether the client's OU has rights to a resource, etc.
      >>
      >> So, in other words, it's up to us, the BACnet *application* as to what to do with these certificates, and since that hasn't been invented yet... Frank and I were happily arguing from different perspectives over something that doesn't exist! And that's a lot more fun to do over a beer.
      >>
      >> The scenario I had in mind is where a large number of mobile clients are deployed. Having to create a unique certificate for every device was not desirable to the deployer since the certificate alone was not sufficient for authentication, anyway. A unique client certificate might identify a client account on a machine, but couldn't actually identify the person at the keyboard. So, if additional identification (username/password/RSAtoken) was needed *anyway*, what's the point of managing unique certificates for every device? So, "wildcard" certificates were used that only identified the organization information and not the CN. Thus, the server knew that it was "one of the family" but didn't know exactly which one. In this case, automated processes running on those devices (without that extra human involvement), could impersonate each other if one was compromised.
      >>
      >> The above is very similar to what was done for the GNA key in Addendum g. Certain non-human processes needed simple "one of the family" security to talk to each other and so the "General Network Access" key was created for those basic operations. Cracking one of those devices would thus allow the attacker to look like "one of the family", and since there's no additional human input, some basic operations could be performed. So this is why the "Application Specific" keys were created to allow specific entities within the device to talk more securely to each other. Thus creating circles of trust.
      >>
      >> To put that division of Addendum g keys into the client certificate scenario above, it may be that the user has two or more client certificates: the common one for general company (or military base) web server access and a very specific one used by a separate client application for access to a highly secured server application (maybe not web-based at all). Again, it's the *application's* choice as to which certificate to use, how to interpret it, and thus what to "accept" for a given use case.
      >>
      >> So, certificates are great, but they are also very flexible. It's up to us, the BACnet application entity that we are creating, to use them wisely.
      >>
      >> Thanks for a great discussion. And my apologies for any misunderstandings. Next round's on me.
      >>
      >> Dave
      >>
      >>
      >
      > ----- End forwarded message -----
    Your message has been successfully submitted and would be delivered to recipients shortly.