Design-Time Security&Privacy Means

From Web of Things Interest Group

Note: current contents present a draft (work-in-progress). They serve the discussion in the WoT IG

This page surveys mechanisms and frameworks which may help to realize the security&privacy architecture for WoT solutions/projects/products. It identifies and assesses security and privacy means specified by eligible bodies (e.g. IETF) with respect to their fitness to deliver security&privacy functionality for WoT

Mechanisms

This chapter surveys mechanisms that support the realization of security&privacy architectures for WoT. The survey utilizes the following set of criteria to assess selected security&privacy mechanisms:

  • Synopsis to capture the trick(s) it does
  • Evolution Stage to identify the heritage of a mechanism (see below)
  • Specification Authority to report the body that is responsible for the mechanism
  • Specification Maturity to reflect its stage of elaboration
  • System Model to identify the entities/actors recognized by the mechanism and their interactions
  • Architectural Pattern to highlight major properties from an overall perspective
  • Benefits to collect the delivered features
  • Innovation to assess the level of novelty
  • Impact to reflect its ease-of-utilization/integration
  • Limitations to capture tricks a mechanism cannot do resp. situations it cannot serve

Note that this survey uses following short-hand terms to distinguish evolution stages in security and privacy technologies:

  • Classic:
  • Invented <2010
  • Native to enterprise/office IT and the Web - possibly no or only a partial fit for IoT/WoT
  • Examples: Kerberos, LDAP, P3P, PKIX, S/MIME, SAML, SSL, TLS
  • New:
  • Invented 2010-2015
  • Addressing new Web application styles (Web/REST APIs, mobile/browser-based apps), not native to IoT/WoT - possibly no or only a partial fit for IoT/WoT
  • Examples: DTLS, FIDO, JOSE, OAuth, OIDC, SCIM
  • Future:
  • Invented >2015
  • Native to IoT/WoT
  • Examples: ACE (not an individual mechanism but a container for many mechanisms), COSE, DICE

It is structured according the security&privacy requirements identified by the WoT IG. Some mechanisms address or support multiple security&privacy requirements and use cases. Such mechanisms are associated to a primary requirement according their typical usage.

Note: the mechanisms that appear here are candidates for WoT security&privacy. These candidates are assessed and the assessment could be (partially) negative i.e. appearance in the list of WoT security&privacy candidates does not imply any recommendation or endorsement.

Privacy

This section surveys mechanisms with a focus on privacy. Following classic mechanisms also address privacy but are not surveyed:

UMA

  • Synopsis: defines an OAuth-based authorization protocol/mechanism allowing resource owners to control who has access to their resources including information about them (this trick is called O-to-* authorization). Note: UMA could also be listed in the Authorization section
  • Evolution Stage: new
  • Specification Authority: Kantara (UMA work group) and IETF (OAuth working group)
  • Specification Maturity: Work-in-progress, individual drafts particularly
  • System Model: as in OAuth plus differentiation of user actors according the roles of requestor and resource owner (these roles coincide in OAuth) i.e. 5 entities altogether - requestor plus the OAuth-defined entities (resource owner, resource server, authorization server, and client). These entities belong to 2 main domains:
  • Resource owner domain: actual owner (an individual user) and OAuth/UMA authorization server representing her/him plus resource provider entities comprising the OAuth resource server
  • Requesting party domain: actual requestor (another individual user), OAuth/UMA client
  • Architectural Pattern: as in OAuth
  • Benefits: addresses the O-to-* authorization problem where an individual resource owner authorizes others to access her resources
  • Innovation: profiles access token contents. Decouples OAuth resource from authorization server (by introducing new protocol primitives as well as remote APIs). In UMA the resource and authorization servers may be operated by different providers/organizations. Since requestor and resource owner may be different subjects, UMA cannot assume presence of the resource owner during the processing of an access request. Hence the resource owner needs to supply the authorization server with a priori information about granted authorizations (this is not needed in OAuth exchanges that involve the resource owner: since resource owner and requestor are assumed to coincide in such OAuth exchanges, the resource owner is always present and can be asked).
  • Impact: as in OAuth
  • Limitations:
  • Addresses HTTP (resp. HTTP-over-SSL/TLS) only
  • Currently limited to bearer tokens
  • Clients can only request tokens for themselves, not for other entities i.e. the roles of an authorization server and a resource server clients are co-located
  • Somewhat biased towards individually-owned resources resp. consumer goods/scenarios.

Authentication

This section surveys mechanisms with a focus on entity authentication. Following classic mechanisms also address entity authentication but are not surveyed

OATH

Not to be confused with OAuth

  • Synopsis: defines algorithms to generate and validate one-time-passwords and well as supporting mechanisms esp. key provisioning
  • Evolution Stage: classic
  • Specification Authority: Initiative for open authentication and IETF (KeyProv working group [concluded as well as non-WG RFCs)]
  • Specification Maturity: the main OATH results are published as Internet standards
  • System Model: direct authentication with 2 parties - claimant and verifier. The claimant proves her/his/its identity claims by presenting an OATH one-time-password. The verifier verifies the OATH one-time-password in order to check the claimed identity. In most current cases the claimant is a human user resp. her/his user agent. But OATH is not limited to human users as claimants.
  • Architectural Pattern: actual business applications do usually externalize the conduction of user authentication to dedicated components ("login applications"). With OATH mechanisms are used, this common pattern results in an OATH-based initial user authentication scheme between user agent and "login application" (partially defined by OATH [note that OAUTH defines cryptographic algorithms for the purpose of authentication but not how corresponding messages are exchanged between claimants and verifiers]) as well as a security token-based (e.g. JWT) subsequent authentication between user agent and business application (not defined by OATH)
  • Benefits: provides open standard schemes for generating/verifying one-time-passwords. OATH covers the major types of one-time-password-schemes: time-based, event-based, and challenge-based
  • Innovation: delivers standards for generating and validation HMAC-based one-time-passwords. Avoids vendor-locking by allowing a mixture of one-time-password generators and validators from different vendors. Presents the preferred one-time-password scheme(s) for mobile apps (e.g. Google Authenticator)
  • Impact:
  • The algorithmic complexity of OATH schemes is rather small (e.g. a few 100 LoC in Java) and the actual footprint is on the side of the user or entity metadata that has to be available to the verifier (stored in e.g. LDAP repositories). The model of this metadata has to be extended to include new items such as shared secret keys (which implies a need for protection/encryption), number of login failures, number of login events (for event-based schemes). This additional data needs to be managed.
  • One-time-password generators have to be supplied to users. These generators (e.g. mobile apps) can be digital or physical objects. The latter case requires some logistics.
  • Limitations:
  • Does not define actual authentication protocols between claimants and verifiers. Bindings to (application) protocols such as HTTP are needed in addition. Conventions to transfer information about claimed identity are also needed in addition
  • The industry-best practice for one-time-password user authentication to Web applications is to use HTML forms with custom parameters. Note that this results in proprietary authentication protocols. This limitation is addressed (among others) by FIDO]

OpenID Connect

  • Synopsis: defines an OAuth-based protocol for cross-organization SSO utilizing HTTP, JSON and JWT featuring lightweight relying parties that may register dynamically
  • Evolution Stage: new
  • Specification Authority: OpenID Forum (OpenID Connect work group)
  • Specification Maturity: final OpenID Forum specifications as well as drafts (work-in-progress)
  • System Model: federated authentication with 3 parties - claimant, IdP (aka OpenID Provider), RP (Relying Party). The claimant usually is a human user who performs initial authentication against an IdP component. Note that OpenID Connect does (intentionally) not specify or limit the initial authentication schemes, arbitrary ones may be used. The IdP reports about user authentication to the RP. Corresponding objects are called ID tokens. ID tokens take the form of JWT. JWT objects are sent in authentication response messages from IdPs to RPs. This is triggered by authentication request messages which are sent by RPs to IdPs. Note that authentication request and response messages are frontend exchanges which pass the user agent (sent with HTTP redirections). Beware of following terminology pitfall:
  • OpenID Connect 'authentication requests' are extended OAuth 'authorization request' messages
  • OpenID Connect 'authentication responses' are extended OAuth 'authorization response' messages
  • Architectural Pattern: allows business applications to externalize the authentication of users resp. callers as well as the lookup of information (identifiers, attributes, affiliations) associated with that user. The relying party can provide instructions regarding the requested authentication scheme and the requested information about the user that shall be asserted with its authentication requests.
  • Benefits: provides following advantages over classical mechanisms for cross-organization SSO such as SAML or WS-Federation (passive profile):
  • Relying party components become lightweight (not the case for SAML or WS-Federation (passive profile))
  • They register (by default) dynamically at asserting parties (not the case for SAML or WS-Federation (passive profile)). User consent is mandatory by default.
  • Relying parties can provide instructions on to-be-asserted information with each authentication request (not the case for SAML, possible with WS-Federation (passive profile)).
  • Innovation: from a functional point-of-view, OpenID Connect covers about the same use cases as SAML or WS-Federation (passive profile). Hence it rather presents a form-factor innovation (see benefits) than a feature innovation
  • Impact: OpenID Connect components on relying party-side is in-complex and fairly lightweight. The asserting party is a distinguished role that depends on fairly complex software components (OAuth authorization servers with extensions for OpenID Connect). However the latter is true for all approaches to externalize initial user or caller authentication to a dedicated party, the asserting party.
  • Limitations:
  • Addresses HTTP (resp. HTTP-over-SSL/TLS) only
  • As a cross-organization SSO mechanism, OpenID Connect can also deliver same and cross-domain SSO (within the same organization) but comes with some overhead in case of same and cross-domain SSO
  • Does not address client-side SSO i.e. a user experience where a login to a service provider in one provider-app propagates into other apps

JWT

  • Synopsis: syntax that allows an authority (called asserting party) to make an assertion about system actor such as a user. Such assertions are consumed by a relying party which uses a protocol to offload processing tasks to the asserting party
  • Evolution Stage: new
  • Specification Authority: IETF (OAuth working group)
  • Specification Maturity: Internet standard
  • System Model: federated authentication with 3 parties - security token producer and consumer plus the system actor whose properties are described in the security token: the security token producer provides information (called 'claims') about a system actor (usually a 3rd entity different from the security token producer and consumer)
  • Architectural Pattern: JWTs allow providing information (called 'claims') about a system actor in an extensible and versatile manner. JWTs may be signed and/or encrypted by means of JOSE. There are 2 main architectural patterns for JWTs:
  • Establishing entity authentication: JWTs (signed and/or encrypted) are passed by-value (or by-reference) are submitted by claimants to relying parties. This provides a subsequent authentication scheme in which claimants use any initial authentication scheme with an identity provider (JWT producer) and submits a JWT as secondary/derived authentication credential to a relying party
  • Forwarding information about entity authentication: JWTs are passed by a relying party to further downstream components. These are backchannel exchanges that do not pass the claimant. In this the downstream component does not authenticate the claimant by itself (it is just being informed about the system actor without interacting directly with the claimant)
  • Benefits: RFC 7519 defines the raw structure of JWTs. Depending on the contents in (extended) JWTs a implementation may use JWTs for establishing and reporting about entity authentication in distributed systems. In this case the JWTs are extended with authentication information contents as well as information about entity attributes/affiliations. The use of JWTs is not limited to entity authentication in distributed systems. They may also be used in authorization contexts - subject to the JWT content extensions chosen by an implementation.
  • Innovation: achieves in the JSON form-factor what SAML assertions achieve in the XML and what KRB tickets achieve in the ASN.1 factor - making tricks known with XML and ASN.1 available with JSON, no new tricks. Note: some small-print applies due to the nuances in the JWT vs. SAML assertion vs. KRB ticket object structure. Their consideration is beyond the scope of this document
  • Impact: JWTs present an application-level security mechanism. They may be exchanged as a part of the payload portion in application protocols, the request URLs or on application protocol header level:
  • Specific services (known as identity providers, asserting parties or authorization servers) are needed for their issuance.
  • Specific components are needed for their consumption/handling. An offloading is possible with the help of upstream enabling/gateway components (implementing the so-called agent sequence shown in figure 3 of RFC 2904) which consume/process JWTs and inform JWT-unaware downstream components by other means
  • Limitations: supplementary specifications extend JWTs to coin fully-fledged authentication statement objects (so-called 'ID token' objects defined in OpenID Connect Core spec) i.e. JWT is a supporting specification for authentication (it allows to report about entity authentication events and defines a data object in the JSON form-factor for this purpose) not an actual authentication protocol
  • No specification is currently known that would extend JWT to present fully-fledged authorization statement objects
  • Supplementary specifications needed to define a request/response protocol for the acquisition of JWT objects (see OpenID Connect Core spec)
  • Mechanism is not native to IoT camp (fitness for class 1/0 devices?)

FIDO

  • Synopsis: specifies a framework (protocols/remote APIs/local APIs) to conduct initial user authentication in Web applications. This aims at schemes beyond username/static password.
  • Evolution Stage: new
  • Specification Authority: FIDO Alliance
  • Specification Maturity: FIDO Alliance Proposed Standards
  • System Model: direct authentication with 2 parties - claimant and verifier. Claimants take the form of HTTP-based user agents (Web browsers, browser-based apps, mobile apps). Verifiers take the form of Web applications that specialize in conducting user authentication (challenging users to present identifier/credentials, validating presented credentials). Such application components are usually parts of IdPs.
  • Architectural Pattern: actual business applications do usually externalize the conduction of user authentication to dedicated components ("login applications"). When FIDO is used, this common pattern results in an FIDO-based initial user authentication scheme between user agent and "login application" (defined by FIDO) as well as a security token-based (e.g. JWT) subsequent authentication between user agent and business application (not defined by FIDO)
  • Benefits: authentication of Web users to Web application with multiple factors resp. environmental information resp. physical devices are not standardized and blurred with proprietary, silo'ed approaches. FIDO proposes an (industry) standard for this purpose.
  • Innovation: specifies a 'first-mile technology' covering the initial authentication between HTTP-based user agents and HTTP-based asserting parties with multi-factor authentication
  • Impact: Requires specific components ("FIDO client") on side of the user agent resp. the system that hosts the user agent. Requires specific Web applications ("login application") that conducts the user agent. These application also comprise specific components ("FIDO server").
  • Limitations:
  • Does not specify means to transfer and sustain initial authentication (SSO, security tokens, SLO etc)
  • Does not specify means to consume initial authentication
  • Addresses HTTP (resp. HTTP-over-SSL/TLS) only
  • The current FIDO specs are user-centric. They assume presence/attention of users and do not address device(-only) authentication. Authentication of non-human user actors is not covered.

TWAI

  • Synopsis: application-level protocol to establish mutual authentication between RFC 7228 class 2 as well as class 1 devices
  • Evolution Stage: future
  • Specification Authority: IETF (ACE working group)
  • Specification Maturity: work-in-progress, individual draft
    Two-way Authentication for IoT
  • System Model: direct authentication with 2 parties - claimant and verifier. See DTLS for more details
  • Architectural Pattern: incarnates DTLS message exchanges in the application space for the main purpose of mutual entity authentication
  • Benefits: mutual entity authentication across intermediaries that terminate DTLS associations
  • Innovation: adaptation of the DTLS spec (RFC 6347) for the application-space
  • Impact: defines a secure communication mechanism on application-level by re-using (and transferring) DTLS messages. As an application-level mechanism TWAI requires additions on side of the actual client and server code.
  • Limitations:
  • Lacks a concrete binding to CoAP request/response messages or other application-protocols
  • Does not cover RFC 7228 class 0 devices. Does not support authentication between a RFC 7228 class 2 and class 1 device
  • Lacks a description of how client and server signalize (the need/wish for) TWAI exchanges (in the native usage of TLS and DTLS this is signalized by the access scheme in the URL resp. negotiated by application-level protocol messages [STARTTLS])

TODO: consider ACE EAP ("CoAP adoption of EAP", https://tools.ietf.org/id/draft-marin-ace-wg-coap-eap-01.txt, expired)
TODO: WebID authentication (user-centric identifiers and authentication) TODO: CBOR Web Token (CWT)

Authorization

This section surveys mechanisms with a focus on authorization aka access control. Following classic mechanisms also address authorization but are not surveyed

OAuth

Not to be confused with OATH

  • Synopsis: a zoo of both, new and old tricks in new syntax. Originally introduced for doing a single, new trick: owners of resources e.g. jpegs at GDrive want to authorize themselves for using their resource(s) with other, 3rd party Web applications e.g. office24.example (this trick is called O-to-O authorization). Evolved to a framework (protocols, APIs) to request/sent/introspect/revoke/transform OAuth (bearer and PoP) tokens via HTTP and can do many tricks now.
  • Evolution Stage: new
  • Specification Authority: IETF (OAuth working group)
  • Specification Maturity: Internet standards as well as some working group plus individual drafts (work-in-progress) particularly
  • System Model: 4 defined entities - resource owner (an individual user), resource server, authorization server, and client that are belonging to 2 main domains:
  • Resource owner domain: actual owner (an individual user) plus resource provider entities comprising the OAuth authorization server and OAuth resource server
  • Requesting party domain: actual owner (again!) matching the requestor role plus OAuth client
These system component implement following functionality:
  • The resource server externalizes security-related processing tasks to an authorization server which is a special-purpose, security-enablement component.
  • The authorization server responds to token issuance requests from a client and issues access tokens (on behalf of the resource owner). The authorization server may interact with the resource owner (an individual user) via her user agent. The access token is issued for the client.
  • The client present the access token to the resource server which processes it and allows/denies resource access according its contents.
Note that OAuth defines various ways of access token acquisition (called grant types). The resource owner appears as an OAuth protocol actor in some but not all of them.
  • Architectural Pattern: incarnates the 'push sequence' pattern according RFC 2904 (see [Vol00]):
  • The "User" corresponds the OAuth client.
  • The "AAA server" corresponds the OAuth authorization server.
  • The "Service Equipment" corresponds the OAuth-protected resource server.
The basic interaction sequence shown in figure 5 of RFC 2904 is generalized with respect to:
  • Clients may initially interact with resource servers which can refer clients to an authorization server by means of HTTP 401 responses
  • Resource servers may interact with an authorization server in order to get help in validating/processing access tokens
  • Benefits: depends on the choice which an implementation makes for the contents of an access token as well as the grant type(s). Depending on that: can also be used for authentication purposes i.e. is not fundamentally limited to authorization purposes.
  • Innovation: facilitates new use cases that emerged with new Web application styles (lightweight RESTful Web services, browser-based/mobile apps) esp.
  • O-to-O authorization problem where a resource owner (e.g. Jane Doe) grants authorization to access her/his resources (e.g. jpeg's stored at GDrive) to another entity (e.g. print service of office24.example) that is utilized by her
  • Persisted login at mobile apps where a user (e.g. Jane Doe) enters credentials once to a mobile app. The mobile app obtains and stores an access token which is used to provide a 'persisted login' user experience
Also introduces the "Security Token Service" concept for lightweight HTTP-based Web services that was originally introduced with/for heavyweight SOAP-based Web services.
  • Impact: OAuth presents an application-level security mechanism. Corresponding access token objects are presented as a part of the payload portion in application protocols, the request URLs or on HTTP header level. They are requested and supplied as part of HTTP payload:
  • Specific components are responsible for OAuth token issuance. These are dedicated security infrastructure components (known as authorization servers) that respond to OAuth token requests via HTTP. They may interact with users resp. their user agents (subject to the chosen OAuth grant type)
  • Specific components are needed for access token request and consumption. These are subcomponents of the actual HTTP (application) clients and servers.
  • Limitations:
  • Access token contents remain undefined
  • Addresses HTTP (resp. HTTP-over-SSL/TLS) only
  • Does not address the O-* authorization problem where a resource owner wants to grant authorization to access her/his resources to another subject
  • Clients can only request tokens for themselves, not for other entities i.e. the roles of an authorization server and a resource server clients are co-located

OAuth-for-CoAP

  • Synopsis: OAuth for CoAP. Defines a framework (protocols/APIs) to request/sent/introspect/observe access tokens via CoAP by adopting OAuth. In contrast to native OAuth which defines many ways of requesting access tokens to support many use cases, OAuth-for-CoAP is currently limited to a single way of doing that (called 'IoT client credentials grant')
  • Evolution Stage: future
  • Specification Authority: IETF (ACE working group)
  • Specification Maturity: work-in-progress, individual draft(s)
  • System Model: 3 entities - resource server, authorization server, client. Note that the authorization server exposes endpoints that interact with clients but are unaware of resource owner components such as user agents. Hence the resource owner is not an actor according the currently defined grant type in OAuth-for-CoAP. These entities belong to 2 main domains:
  • Resource owner domain: OAuth-for-CoAP authorization server, OAuth-for-CoAP resource server
  • Requesting party domain: OAuth-for-CoAP client
  • Architectural Pattern: as for OAuth
  • Benefits: as for OAuth
  • Innovation: straight-forward adaptation of a subset of the OAuth specs (particularly RFC 6749 and 6750) which are natively defined for HTTP - making tricks defined for HTTP available with CoAP, no new tricks. The IoT grant corresponds the original client credential grants (with a spin from client id/secret-authentication on HTTP level to DTLS client authentication)
  • Impact: OAuth-for-CoAP presents an application-level security mechanism. Corresponding access token objects are presented as CoAP options. They are requested and supplied as part of CoAP payload:
  • Specific components are responsible for OAuth token issuance. These are dedicated security infrastructure components (known as authorization servers) that respond to OAuth token requests via CoAP. They do not interact with users resp. their user agents
  • Specific components are needed for access token request and consumption. These are subcomponents of the actual CoAP (application) clients and servers.
  • Limitations: as for OAuth modulo/plus
  • Addresses CoAP (resp. CoAP-over-DTLS) only
  • Is unaware of users as system actors
  • Supports bearer access tokens only
  • A constrained client needs to (be able to) interact with the authz server by itself

UMA-for-CoAP

  • Synopsis: UMA for CoAP
  • Evolution Stage: future
  • Specification Authority: IETF (ACE working group)
  • Specification Maturity: work-in-progress, individual draft (work-in-progress)
  • System Model: as for UMA
  • Architectural Pattern: as for UMA
  • Benefits: as for UMA
  • Innovation: straight-forward adaptation of the UMA specs which are natively defined for HTTP - making tricks defined for HTTP available with CoAP, no new tricks
  • Impact: as for UMA
  • Limitations: as for UMA

DCAF

  • Synopsis: defines means to request/express/present/process authorization information for CoAP resources utilizing a new, from-scratch authorization protocol (embedded with CoAP)
  • Evolution Stage: future
  • Specification Authority: IETF (ACE working group)
  • Specification Maturity: work-in-progress, individual draft (work-in-progress)
  • System Model: as in OAuth plus:
  • Differentiation of user actors according the roles of a requestor and resource owner (these roles coincide in OAuth)
  • Differentiation of the client role into a resource server client and an authorization server client
i.e. 6 entities altogether - requestor and authorization manager plus the OAuth-defined entities (resource owner, resource server, authorization server, and client). These entities belong to 2 main domains:
  • Resource owner domain: actual owner (an individual user or legal entity), DCAF authorization server, DCAF resource server
  • Requesting party domain: actual requestor (individual user or legal entity), DCAF authorization manager, DCAF client
  • Architectural Pattern: as in OAuth
  • Benefits: introduces a new system role ("authorization manager") that allows to decouple resource server from authorization server clients
  • Innovation: introduces a delegation mechanism - the token presenter (client) does not have to acquire the token by itself but can delegate this task to another entity (authorization manager). Note that in OAuth (here: the exchanges known from IETF documents) the client always acquires access tokens for its own usage
  • Impact: DCAF is an application-level security mechanism that also makes use of transport security. Corresponding ticket (aka access token) objects are presented on DTLS-level. The are requested and supplied as a part of the payload portion in CoAP (media type application/dcaf+cbor):
  • Specific components are needed for ticket issuance. These are dedicated security infrastructure components (known as authorization managers and servers) that respond to DCAF ticket requests via CoAP
  • Specific subcomponents are needed for ticket request and consumption. These subcomponents are parts of the CoAP (application) clients and servers.
  • Limitations:
  • Defines a REST-centric authorization model
  • Does not inherit/extend known approaches from the HTTP ecosystem
  • Does not cover the 'pull sequence'

CoRE Authz

  • Synopsis: defines means to request/express/present/process authorization information for CoAP resources utilizing a(nother) new, from-scratch authorization protocol (embedded with CoAP resp. DTLS)
  • Evolution Stage: future
  • Specification Authority: IETF (ACE working group)
  • Specification Maturity: work-in-progress, individual draft (work-in-progress)
  • System Model: as in OAuth-for-CoAP
  • Architectural Pattern: incarnates the 'push sequence' as well as the 'pull sequence' patterns according RFC 2904 (see [Vol00]):
  • The "User" corresponds the CoRE Authz client.
  • The "AAA server" corresponds the CoRE Authz authorization server.
  • The "Service Equipment" corresponds the CoRE Authz-protected resource server.
  • Benefits: adds coverage for the 'pull sequence' pattern (but also adds indication that the 'push sequence' is more constrained device-friendly than the 'pull sequence')
  • Innovation: defines objects to request/express/present/process authorization information (expressed in CBOR or JSON). Uses CoAP or DTLS to transfer such objects.
  • Impact: CoRE Authz is an application-level security mechanism that may also make use of transport security. Corresponding authorization information objects can be presented on CoAP or DTLS-level. The are requested and supplied as a part of the payload portion in CoAP (media type application/cbor or application/json):
  • Specific components are needed for authorization information issuance. These are dedicated security infrastructure components (known as authorization servers) that respond to CoRE Authz information requests via CoAP
  • Specific subcomponents are needed for authorization information request and consumption. These subcomponents are parts of the CoAP (application) clients and servers.
  • Limitations:

TODO: WebAccessControl (ACL objects for Web servers)
TODO: bearer vs. PoP (concerns all candidates above)

Secure Communications and Storage

This section surveys mechanisms with a focus on secure communications and storage. Following classic mechanisms also address secure communications and storage but are not surveyed:

DTLS

  • Synopsis: TLS for unreliable transports. A protocol to protect (encryption, data origin authentication) messages sent between a requestor and responder over UDP or other unreliable transports. Note that DTLS also supports entity authentication
  • Evolution Stage: classic/new
  • Specification Authority: IETF (TLS working group)
  • Specification Maturity: Internet standards as well as some working group plus individual drafts (work-in-progress)
  • System Model: 2 parties - client and server. These parties exchange information according the request/response pattern of interaction. They want to (mutually) establish proof of their identity (esp. the client would like to establish a proof for the entity that responds before sending data to coaps://my-device.home). They want to have encryption to protect the confidentiality of their interactions. They want to have cryptographic checksums aka signatures to protect the authenticity and integrity of their exchanges
  • Architectural Pattern: intermediate layer (underneath application protocol, above transport protocol) to transiently add secure communications to arbitrary application protocols over unreliable transports (TLS does the same trick for reliable transports). Besides the transformation of the actual payload (e.g. CoAP requests/responses) DTLS defines protocol messages to negotiate the details of DTLS protection, opt. perform authentication (mutual or unilateral) and establish keying associations for the protected transfer of payload information
  • Benefits: allows establishing server (and client) authentication as well as data confidentiality/origin authentication and integrity outside the actual application code and independent of the network.
  • Innovation: adapts TLS for unreliable transports e.g. UDP
  • Impact: defines a secure communications mechanism on transport-level. Its addition to client/server components is straight-forward and requires little to no code changes in the application space. Only the addressing scheme changes (e.g. coap vs. coaps)
  • Limitations:
  • Support of secure storage resp. persisted protection
  • Efficient support of multi-party interactions such as 1:n group communication or multicast scenarios
  • Support of constrained devices
  • Network intermediaries limit the end-to-end security span

DICE

  • Synopsis: DTLS (and TLS) for constrained devices. Specifying a DTLS profile for constrained devices as well as group/multicast communications
  • Evolution Stage: future
  • Specification Authority: IETF (DICE working group)
  • Specification Maturity: work-in-progress, working group plus individual drafts
  • System Model: as for DTLS
  • Architectural Pattern: as for DTLS
  • Benefits: as for DTLS
  • Innovation: profiles DTLS (and TLS) for constrained devices by suggesting subsets that ease performance requirements. Also suggests additions for the support of multicast resp. group communications.
  • Impact: as for DTLS
  • Limitations:
  • Support of secure storage resp. persisted protection
  • Network intermediaries limit the end-to-end security span

JOSE

  • Synopsis: syntax to represent the results of cryptographic operations (e.g. encryption, signing) in JSON - along with metadata (e.g. algorithm information, keying association information)
  • Evolution Stage: new
  • Specification Authority: IETF (JOSE working group)
  • Specification Maturity: Internet standards
  • System Model: 2 parties - signer and verifier (for signing use case) or encrypter and decrypter (for encryption use cases).
  • Architectural Pattern: builds upon and re-uses the well-known cryptographic primitives to define cryptographic objects in the JSON form-factor i.e. representations of cryptographically transformed data along with metadata needed for signature validation resp. decryption. The focus is on the specification of data objects not the specification of services or components to process such data
  • Benefits: allows expressing the results of cryptographic transformations (signature values, encrypted data) along with cryptographic keys (or references to them) and other metadata (e.g. algorithm information) in JSON. Enables information-bound, application-level data origin authentication (signature) and data confidentiality (encryption). Supports symmetric as well as asymmeric cryptography. Facilitates enveloping (signature provides an envelope of the object it signs) and detached signatures (signature and signed object are separate data objects)
  • Innovation: achieves for JSON what XML Signature/Encryption/Key Management achieve for XML and what CMS/PKCS achieves for ASN.1 data - making tricks known for XML and ASN.1 available with JSON, no new tricks.
  • Impact: JOSE presents an application-level security mechanism. Corresponding objects may exchanged as a part of the payload portion in application protocols.
  • Limitations
  • Does not define services or service APIs for cryptographic security services
  • Does hardly match the constraints of IETF RFC 7228 class 1/0 devices
  • JWS not support enveloped (signature object a substructure of the object it signs) or detached (signature object and signed object rpresented in separate structures) signatures.

COSE

  • Synopsis: syntax to represent the results of cryptographic operations (e.g. encryption, signing) in CBOR - along with metadata (e.g. algorithm information, keying association information). The same trick as JOSE does for JSON
  • Evolution Stage: future
  • Specification Authority: IETF (COSE working group)
  • Specification Maturity: work-in-progress, working group draft
  • System Model: as for JOSE
  • Architectural Pattern: as for JOSE (with CBOR instead JSON)
  • Benefits: as for JOSE (with CBOR instead JSON)
  • Innovation: as for JOSE (with CBOR instead JSON)
  • Impact: as for JOSE (with CBOR instead JSON)
  • Limitations:
  • Does not define services or service APIs for cryptographic security services
  • Does not support enveloped signatures (signature a substructure of the object it signs)

OSCOAP

  • Synopsis: application-level data encryption and signature for CoAP (utilizing JOSE and/or COSE)
  • Evolution Stage: future
  • Specification Authority: IETF (ACE working group)
  • Specification Maturity: work-in-progress, working group draft
  • System Model: 2 parties - signer and verifier (for signing use case) or encrypter and decrypter (for encryption use cases).
  • Architectural Pattern: supports a mode where only CoAP payload is encrypted/signed as well as a mode where CoAP header/option fields are included when encrypting/signing. For the latter new CoAP option fields are defined i.e. this mode presents a protocol extension. The former mode is transparent to the actual CoAP libraries
  • Benefits: protection of exchanges across intermediaries (note that CoAP lacks a protocol primitive "CONNECT" which allows TLS exchanges to traverse proxy servers) as well as store-and-forward and publish-subscribe exchanges
  • Innovation: introduces and defines the media type 'application/smpayl' allowing CoAP clients and servers to exchange CoAP payload in encrypted and/or signed fashion
  • Impact: defines a secure communication/storage mechanism on application-level. In the CoAP payload protection mode, OSCOAP requires adaptations on side of CoAP client and server code resp. specific protocol conventions on the application layer. In the CoAP message protection mode, OSCOAP requires adaptations on side of the CoAP protocol stacks
  • Limitations: cf. COSE and JOSE

TODO: TinyDTLS

Provisioning, Credentialing

This section surveys mechanisms with a focus on provisioning and credentialing. Following classic mechanisms also address provisioning and credentialing but are not surveyed

SCIM

  • Synopsis: RESTful management of user data - defines a REST-style protocol/API as well as JSON data model for the provisioning and management of user accounts (identifiers, attributes, affiliations, credentials) via HTTP
  • Evolution Stage: new
  • Specification Authority: IETF (SCIM working group)
  • Specification Maturity: Internet standards as well as working group plus individual drafts (work-in-progress) particularly
  • System Model: 2-parties - client and server where the SCIM client usually presents the authoritative source of user identity information (e.g. the home organization of a user) and the SCIM server presents the corresponding sink such as an XaaS offering in the Cloud. The user data sustained on SCIM server side is managed by the SCIM client (subject to SCIM client authentication and authorization)
  • Architectural Pattern: requires specific components - SCIM responder and client. The SCIM client reprents the authoritative source (e.g. home organization) triggering individual or bulk operations at the responder. The SCIM responder sustains or supplements an own repository or directory.
  • Benefits: exposes the classical tricks of the LDAP camp to the HTTP camp and makes them available for the community of HTTP client component developers (orders of magnitudes larger than the camp of LDAP client component developers)
  • Innovation: straight-forward application of the REST architecture principle to the domain of managing user identity data (comprising identifiers/attributes/affiliations/credentials). Originally SCIM covers the representation of (human) users in its data model and APIs. Due to extensibility metadata, of other actors (such as devices/things) can also be addressed under a SCIM umbrella
  • Impact: introduces an option to do identity management in a way that is standards-based, service-oriented and lightweight (esp. for the side of the client)
  • Limitations:
  • Does treat 'identity' only in the form of data that is input to authentication processes, not in the form of data that is output of them
  • Is extensible but does not (yet) define a data model for non-user actors

TODO: ACE draft-kang-ace-secure-configuration-00 (expired), KMIP (OASIS), DNSSEC (IETF) and related such as DKIM, SPF (see http://googleonlinesecurity.blogspot.de/2013/12/internet-wide-efforts-to-fight-email.html), Kantara IDoT (https://kantarainitiative.org/confluence/display/IDoT/Home), OMA LwM2M bootstrap

Frameworks

This section surveys frameworks that support the building of security&privacy architectures for WoT. Note that the framework section is not a priorily limited to initiatives that are native to IoT/WoT: it is also open for pre-IoT/WoT frameworks when there is a likelihood that this work could have a repercussion in IoT/WoT

Initial proposal of security&privacy framework candidates (by Edoardo) for discussion:

Additional proposals:

  • ISO/IEC 29100:2011 Information technology -- Security techniques -- Privacy framework
  • ISO/IEC 27018:2014 — Information technology — Security techniques — Code of practice for protection of Personally Identifiable Information (PII) in public clouds acting as PII processors
  • NIST: Guide to Industrial Control Systems (ICS) Security. NIST Special Publication 800-82 (pre-IoT/WoT but provides suggestions that may carry-on in an IoT/WoT era)
  • Open Data Center Alliance: Identity Management Interoperability Guide rev. 1.0 (another domain that intersects with some IoT/WoT use cases but the actual reason for suggesting is the figure on p.8: I like the mindmap-style taxonomy of IAM-feature => we might wantconsider to create something similar for SP. I think having a mindmap-style visual presentation as a starting point [no details, just SP buzzwords and how they relate] will help us during elaboration and others when consuming our artifacts)
  • P. Gutmann: Performance Characteristics of Application-level Security Protocols (not really a SP framework - just hijack this section here - but a pointer to a potential whitespot: when considering application vs transport-level security it's important to have some understanding of the performance impact of e.g. CoAP-over-DTLS vs. COSE-in-CoAP. Right now I am not aware of a corresponding study => something similar as the quoted document for the IoT/WoT space would be important)
  • NIST IR 8053 De-Identification of Personally Identifiable Information
  • IIC: Security Reference Architecture (not yet available, to-be-expected for Q4/2015)
  • OIC: security spec not yet available. Some outlook: OIC Security
  • Online Trust Alliance: IoT Trust Framework
  • TODO: Security approach taken in OMA 'Generic Open Terminal API Framework' (GotAPI)

Privacy frameworks:

  • GAPP (Generally Accepted Privacy Principles)
  • OCED Guidelines Governing the Protection and Privacy of Transborder Flows of Personal Data
  • FTC FIPPS (Federal Trade Commission’s version of the Fair Information Privacy Principles)
  • European Union Directive EU95/46
Retrieved from "https://www.w3.org/WoT/IG/wiki/index.php?title=Design-Time_Security%26Privacy_Means&oldid=2289"