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

Update to Web Services Addendum (rev 10)

Expand Messages
  • Dave Robin
    Data Modelers (and IT-WG), Here is an update to the draft based on the last two conference calls. This mostly focussed on the security aspects that we have
    Message 1 of 1 , Apr 22, 2013
    • 0 Attachment
      Data Modelers (and IT-WG),

      Here is an update to the draft based on the last two conference calls.  This mostly focussed on the security aspects that we have been discussing.  I still have some emails containing excellent feedback on other areas of that draft - those are much appreciated and not forgotten, just postponed till we work out the big issues in security.

      I'm including the IT-WG on this because of the foundational aspects of a possible common security model for WS and NTB.

      I look forward to our next call this Thursday.  Feel free to email comments to me or the group before that.


      p.s., for those that are keeping count, there is no released rev 9.  A file named ...-9w was accidentally released (which was equal to rev 8).  So to minimize confusion (I hope), I skipped to 10.  The change tracking in rev 10 therefore shows the changes from rev 8 (so much for minimizing confusion).

      Rev 10:  Proposed changes as a result of conference calls through 2013-04-18:

      Several observations were made about external authorization servers:
      • Multiple addresses for external authentication servers should be explicitely for redundancy, not "for redundancy or separation of scope", as rev 8 said.  However...
      • It was agreed that some server devices indeed have a need for more than one security context (e.g., HVAC & access control) and therefore having more than one authorization server (each with a redundant backup) is desirable.  In OAuth (via RFC 2617), these contexts are known as "realms". A "realm" is independent of, and logically higher than, OAuth's "scope".  The WWW-Authenticate error response header for OAuth provides both the realm and scope.
      • Therefore, the auth servers are separated by realm, and found easily by the client at "/.auth/{realm}/pri" and "/.auth/{realm}/sec".  The public key is at /.auth/{realm}/key (readable, because public)
      • To allow the client to know which realm to use for a given resource without first trying to access it and getting the WWW-Authenticate header,  the "authRealm" attribute is added to the existing "authRead" and authWrite" scope attributes in the metadata.
      • Support for troublesome "addressless tokens" has morphed into support for safer group-address tokens instead. Since group tokens are signed by a particular auth server, they are realm dependent, so are specified under an array at "/.auth/{realm}/groups/..."  Group ids are guids.

      Changes to token signatures:

      • To prevent a compromised server from generating tokens itself, symmetric keys were dropped in favor of public key signatures.  Server devices can retain the last few validated tokens in a cache for comparison upon repeated use so that the PKI signatures are not repeatedly checked.

      Machine to Machine:

      • Instead of using symmetric keys for peer to peer communications, we decided to give have devices use their own individualized credentials (their certificates) to get the PKI signed tokens from the auth server when they need to talk to a peer.  This is an extra step for peer to peer, but puts control of those communications, including destination addresses, duration, and scope, more properly in the hands of the authentication server.

      • More changes to the "factory defaults" section to allow interoperable injection of the TLS certificates rather than leaving that as a "local matter" (i.e. no more vendor specific tools just to get on the network)
      • We decided not to include a standard list of scopes (and now realms) at this time. Examples would have been scopes like "command", "operate", "configure", "program", "install", and realms like "hvac", "lighting", "access".  This was seen as inappropriate for the protocol itself to define, and will be handled later or by other industry groups.

      Other proposed changes (still TBD):

      • Need a section using standard HTTP proxy protocol for cases where there is only one reachable server (e.g. behind a NAT) that is used to reach all the other servers.
      • In the "issue short-lived bearer tokens" cell:  shorten this text, but cover ideas about "client type" elsewhere. Actually, we need a whole clause on requirements for external authorization servers.
      Other possible changes (also TBD):

      • Separation of definition from value, hopefully for the simplification of the server and the implementation flexibility of the client:  
        • Rather than have metadata returned interspersed with data values (and controlled by the "?metadata=xxx" query parameter), instead, return only the tree of values with an optional 'definition' attribute that designates the separate location for the corresponding tree of metadata.  
        • The client therefore thinks in terms of getting a static definition and then either "overlaying" dynamic values, or keeping them separate internally, by its own implementation choice rather than having the protocol assume it wants them overlaid.  
        • This two phase operation was considered a natural process anyway, which is why the metadata was off by default unless the client asked for it (the assumption being that it would only ask for it once).  
        • This is similar to the "XD for Classic Devices" proposal where the metadata is in static XML files and the values are in live BACnet objects.  
        • The issue to consider here is what, if any, metadata is expected to be dynamic, or at least configurable, at runtime by the client (e.g. the displayName for tree nodes, like "Bob's Office").  One possibility is to define the "value" portion as "anything different from its definition".
    Your message has been successfully submitted and would be delivered to recipients shortly.