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

What was all that back there?

Expand Messages
  • Dave Robin
    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
    Message 1 of 5 , Sep 23, 2010
    • 0 Attachment
      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


    • Charles Frankston
      Actually Rob, I think you owe me two beers. The one you offered below, and another for mangling my name :-). I ll be travelling to Atlanta soon to collect.
      Message 2 of 5 , Sep 24, 2010
      • 0 Attachment

        Actually Rob, I think you owe me two beers.  The one you offered below, and another for mangling my name :-).  I’ll be travelling to Atlanta soon to collect.

         

        I’m a little concerned that while you and I appear to understand each other now, we may have confused a lot of other people in this discussion.

         

        As you’ve indicated, PKI (Public Key Infrastructure) solutions are very flexible and allow one a great deal of freedom in exactly how to take advantage of this flexibility.  I agree that the use of shared “family” or wildcard certificates the way you describe would mean that a PKI solution using TLS would have the same vulnerability as a shared secret solution – that the compromise of the private part of the public/private key pair on one device would compromise for all the devices sharing the “family” certificate.  Obviously that’s not the mode of usage I had in mind.  I am saying it is cheap and practical to issue unique certificates for every device in your deployment. And it is *not* necessary for each device to store a certificate for every device it wants to talk to.  In fact it’s not even necessary for a device to hold the certificate of a single other device it wants to talk to – as long as all the devices that need to mutually authenticate do so using certificates signed by the same root certificate authority (or a chain of signed certificates that eventually lead back to a common root certificate authority).

         

        You could build a complete network with every device holding only one pre-loaded certificate if you wanted to engineer it that way.  Figuring out which root certificates to preload is a more interesting discussion (i.e. do we arrange something with a company like Verisign so we can ensure certificate trust across vendors, or do we have some other solution), but not one that we have to have now.

         

        Similarly, the question you raise about what exactly we’re validating (i.e. is the certificate in lieu of traditional username/password type credentials, or merely a supplement to them (one factor or two factor)?  Do we use certificates to validate the device’s integrity – i.e. is that really the controls vendor’s code we’re talking to or some malicious code?  Or do we have different certificates for each of those purposes?).  But again, at this stage in the discussion my intention was simply to explore the capabilities and tradeoffs of various technologies, not dive into deep design.

         


        From: bacnet-it-wg@yahoogroups.com [mailto:bacnet-it-wg@yahoogroups.com] On Behalf Of Dave Robin
        Sent: Thursday, September 23, 2010 11:19
        To: bacnet-it-wg@yahoogroups.com
        Subject: [bacnet-it-wg] What was all that back there?

         

         

        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

         

         

      • Dave Robin
        Chuck, (I m glad you have a good sense of humor, but I may be testing your limits with that one. My Dad disliked being called Chuck so much he switched to
        Message 3 of 5 , Sep 24, 2010
        • 0 Attachment
          Chuck,

          (I'm glad you have a good sense of humor, but I may be testing your limits with that one.  My Dad disliked being called Chuck so much he switched to using his middle name).

          I agree with your observation about the the root certificates, but, as every one of our customers has discovered, Verisign is ridiculously expensive.  We may end up storing multiple roots for the different manufactures we talk to, unless we want to create a discount "BACnet CA".  (hmm, I feel a business opportunity here :-)

          Rob

          On Sep 24, 2010, at 6:29 PM, Charles Frankston wrote:

           

          Actually Rob, I think you owe me two beers.  The one you offered below, and another for mangling my name :-).  I’ll be travelling to Atlanta soon to collect.

           

          I’m a little concerned that while you and I appear to understand each other now, we may have confused a lot of other people in this discussion.

           

          As you’ve indicated, PKI (Public Key Infrastructure) solutions are very flexible and allow one a great deal of freedom in exactly how to take advantage of this flexibility.  I agree that the use of shared “family” or wildcard certificates the way you describe would mean that a PKI solution using TLS would have the same vulnerability as a shared secret solution – that the compromise of the private part of the public/private key pair on one device would compromise for all the devices sharing the “family” certificate.  Obviously that’s not the mode of usage I had in mind.  I am saying it is cheap and practical to issue unique certificates for every device in your deployment. And it is *not* necessary for each device to store a certificate for every device it wants to talk to.  In fact it’s not even necessary for a device to hold the certificate of a single other device it wants to talk to – as long as all the devices that need to mutually authenticate do so using certificates signed by the same root certificate authority (or a chain of signed certificates that eventually lead back to a common root certificate authority).

           

          You could build a complete network with every device holding only one pre-loaded certificate if you wanted to engineer it that way.  Figuring out which root certificates to preload is a more interesting discussion (i.e. do we arrange something with a company like Verisign so we can ensure certificate trust across vendors, or do we have some other solution), but not one that we have to have now.

           

          Similarly, the question you raise about what exactly we’re validating (i.e. is the certificate in lieu of traditional username/password type credentials, or merely a supplement to them (one factor or two factor)?  Do we use certificates to validate the device’s integrity – i.e. is that really the controls vendor’s code we’re talking to or some malicious code?  Or do we have different certificates for each of those purposes?).  But again, at this stage in the discussion my intention was simply to explore the capabilities and tradeoffs of various technologies, not dive into deep design.

           


          From: bacnet-it-wg@yahoogroups.com [mailto:bacnet-it-wg@yahoogroups.com] On Behalf Of Dave Robin
          Sent: Thursday, September 23, 2010 11:19
          To: bacnet-it-wg@yahoogroups.com
          Subject: [bacnet-it-wg] What was all that back there?

           

           

          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

           

           



        • Charles Frankston
          I agree with your dad, but unfortunately, I don t have a middle name that could enable me to avoid the dread Chuck moniker. Yes, Verisign is expensive. Many
          Message 4 of 5 , Sep 24, 2010
          • 0 Attachment

            I agree with your dad, but unfortunately, I don’t have a middle name that could enable me to avoid the dread “Chuck” moniker.

             

            Yes, Verisign is expensive.  Many of their competitors are cheaper.  But openssl is cheaper yet!  (A few microjoules per certificate!)  A BACnet CA for this industry might not be a bad idea (imagine a business where all you do is sell numbers to people!), but I think we can figure that out further down the road.

             

            Btw, not really relevant, but below you said that the applications typically have their own trusted root certificate lists and handle certificate authentication themselves.  If you look more closely at what IE does, I think you’ll find that it uses the certificate management built into Windows.  Firefox running under Windows manages its own certificates apart from the OS, but Google Chrome on Windows actually uses the OS certificate management.  So Chrome and IE use the same certificate store.  Not really important or relevant to our discussion, but something I found pretty interesting.


            From: bacnet-it-wg@yahoogroups.com [mailto:bacnet-it-wg@yahoogroups.com] On Behalf Of Dave Robin
            Sent: Friday, September 24, 2010 18:58
            To: bacnet-it-wg@yahoogroups.com
            Subject: Re: [bacnet-it-wg] What was all that back there?

             

             

            Chuck,

             

            (I'm glad you have a good sense of humor, but I may be testing your limits with that one.  My Dad disliked being called Chuck so much he switched to using his middle name).

             

            I agree with your observation about the the root certificates, but, as every one of our customers has discovered, Verisign is ridiculously expensive.  We may end up storing multiple roots for the different manufactures we talk to, unless we want to create a discount " BACnet CA ".  (hmm, I feel a business opportunity here :-)

             

            Rob

             

            On Sep 24, 2010, at 6:29 PM, Charles Frankston wrote:



             

             

            Actually Rob, I think you owe me two beers.  The one you offered below, and another for mangling my name :-).  I’ll be travelling to Atlanta soon to collect.

             

            I’m a little concerned that while you and I appear to understand each other now, we may have confused a lot of other people in this discussion.

             

            As you’ve indicated, PKI (Public Key Infrastructure) solutions are very flexible and allow one a great deal of freedom in exactly how to take advantage of this flexibility.  I agree that the use of shared “family” or wildcard certificates the way you describe would mean that a PKI solution using TLS would have the same vulnerability as a shared secret solution – that the compromise of the private part of the public/private key pair on one device would compromise for all the devices sharing the “family” certificate.  Obviously that’s not the mode of usage I had in mind.  I am saying it is cheap and practical to issue unique certificates for every device in your deployment. And it is *not* necessary for each device to store a certificate for every device it wants to talk to.  In fact it’s not even necessary for a device to hold the certificate of a single other device it wants to talk to – as long as all the devices that need to mutually authenticate do so using certificates signed by the same root certificate authority (or a chain of signed certificates that eventually lead back to a common root certificate authority).

             

            You could build a complete network with every device holding only one pre-loaded certificate if you wanted to engineer it that way.  Figuring out which root certificates to preload is a more interesting discussion (i.e. do we arrange something with a company like Verisign so we can ensure certificate trust across vendors, or do we have some other solution), but not one that we have to have now.

             

            Similarly, the question you raise about what exactly we’re validating (i.e. is the certificate in lieu of traditional username/password type credentials, or merely a supplement to them (one factor or two factor)?  Do we use certificates to validate the device’s integrity – i.e. is that really the controls vendor’s code we’re talking to or some malicious code?  Or do we have different certificates for each of those purposes?).  But again, at this stage in the discussion my intention was simply to explore the capabilities and tradeoffs of various technologies, not dive into deep design.

             


            From: bacnet-it-wg@yahoogroups.com [mailto:bacnet-it-wg@yahoogroups.com] On Behalf Of Dave Robin
            Sent: Thursday, September 23, 2010 11:19
            To: bacnet-it-wg@yahoogroups.com
            Subject: [bacnet-it-wg] What was all that back there?

             

             

            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

             

             

             

             

          • Old, Bob
            I think ZigBee did the same thing as a BACnet CA. Ember encouraged us to use PKI for device authentication. At the time, before Certicom got bought out,
            Message 5 of 5 , Oct 5, 2010
            • 0 Attachment

              I think ZigBee did the same thing as a BACnet CA.  

               

              Ember encouraged us to use PKI for device authentication.  At the time, before Certicom got bought out, numbers like 7 cents per certificate for devices were tossed around.  Presumably Certicom planned to make their profit elsewhere.  Their marketing guy told me they once thought about becoming the Verisign for Elliptic Curve Cryptography, until they found that Verisign was already adding ECC root cert authorities to all the browsers.  And was just waiting for enough browsers to get them before turning on the switch.

               

              Speaking of the popularity of PKI, has anyone else noticed that what used to be a few dozen CA’s in IE (and thus Chrome) has recently become hundreds of CA’s?  I realize there are quite a few internal Siemens CA’s on my work laptop, but still.

               

              Utilities required ECC because the keys and certs could be smaller than RSA—important to them because most have very slow backhaul from the meters.

               

              I always figured that because our operator work stations are Windows crates, we would just use the Windows x.509 Cert Management software that Microsoft sells. 

               

              Another advantage is one can catch the counterfeit devices, if you go back to the BACnet CA.  If you’re not worried about counterfeits, you don’t have to check for them.  It’s a flexible mechanism.

               

              Best,

              B.O.  October 5, 2010

               

              Robert Old

              Siemens Industry, Inc.

              Building Technologies

              1000 Deerfield Pkwy.

              Buffalo Grove, IL 60089-4513

              Tel.: +1 (847) 941-5623

              gv: +1 (224) 444-9123

              bob.old@...

              www.siemens.com

               

              From: bacnet-it-wg@yahoogroups.com [mailto:bacnet-it-wg@yahoogroups.com] On Behalf Of Charles Frankston
              Sent: Friday, September 24, 2010 7:02 PM
              To: 'bacnet-it-wg@yahoogroups.com'
              Subject: RE: [bacnet-it-wg] What was all that back there?

               

               

              I agree with your dad, but unfortunately, I don’t have a middle name that could enable me to avoid the dread “Chuck” moniker.

               

              Yes, Verisign is expensive.  Many of their competitors are cheaper.  But openssl is cheaper yet!  (A few microjoules per certificate!)  A BACnet CA for this industry might not be a bad idea (imagine a business where all you do is sell numbers to people!), but I think we can figure that out further down the road.

               

              Btw, not really relevant, but below you said that the applications typically have their own trusted root certificate lists and handle certificate authentication themselves.  If you look more closely at what IE does, I think you’ll find that it uses the certificate management built into Windows.  Firefox running under Windows manages its own certificates apart from the OS, but Google Chrome on Windows actually uses the OS certificate management.  So Chrome and IE use the same certificate store.  Not really important or relevant to our discussion, but something I found pretty interesting.


              From: bacnet-it-wg@yahoogroups.com [mailto:bacnet-it-wg@yahoogroups.com] On Behalf Of Dave Robin
              Sent: Friday, September 24, 2010 18:58
              [Old, Bob] <snip>

            Your message has been successfully submitted and would be delivered to recipients shortly.