The Internet of Things, as distinct from the internet of people, requires communication between devices which enable tracking, monitoring and metering etc… This intercommunication is dependent upon semantically structured and shared data for enabling functions such as identification, authentication, authorisation, bootstrapping and provisioning. Standardising both the semantically structured data and the enabling functions across M2M applications and devices would reduce the cost and extend the life of M2M devices. Standardisation for the Internet of Things is the aim of a common service layer for M2M.
The oneM2M group aims to develop technical specifications that address the need for a common M2M Service Layer that can be readily embedded within various hardware and software, and relied upon to connect the myriad of devices in the field with M2M application servers worldwide. The common M2M Service Layer should be agnostic to underlying network technology (yet leveraging the unique features of these underlying networks), and it will use network layer services (such as security (encryption and authentication), QoS, policy, provisioning, etc.) through an adaptation layer/APIs.
In order for an embedded common M2M service layer to operate it must support AAA (authN, authZ & accounting) for smart devices that is agreeable between multiple device manufacturers and network operators. The Telecommunications Industry Association (http://www.tiaonline.org) are defining a functional standard for Authentication, Authorization and Accounting for Smart Device (AAA-SD TIA) The functions proposed by the common M2M service layer that include Policy & Resource Management
- Authentication and Registration (Identity Management)
- Establish communications session (Add/Delete/Modify)
- QoS/SLA for communication session
- Billing, Charging, and Rating rules
- Group Management
- Security Management (Data confidentiality, integrity, abuse prevention, privacy)
TIA TR-50 Functional architecture for M2M Smart Device Communication System Architecture describes AAA-SD as ” provide authentication, authorization and accounting services to other entities in the network to establish and enforce security policies. The services may include generation of keys, generation and validation of certificates, validation of signatures, etc”
This blog is part of a series comparing the implementation of identity management patterns in SAML and OpenID Connect:
JSON Web Token (JWT)
OpenID Connect uses the JSON Web Token (JWT)
The OpenID Connect protocol [OpenID.Core] is a simple, REST/JSON- based identity federation protocol layered on OAuth 2.0. It uses the JWT and JOSE formats both to represent security tokens and to provide security for other protocol messages (performing signing and optionally encryption). OpenID Connect negotiates the algorithms to be used and distributes information about the keys to be used using protocol elements that are not part of the JWT and JOSE header parameters.
iss REQUIRED. Issuer Identifier for the Issuer of the response
sub REQUIRED. Subject Identifier
aud REQUIRED. Audience(s) that this ID Token is intended for. It MUST contain the OAuth 2.0 client_id of the Relying Party as an audience value
- exp REQUIRED. Expiration time on or after which the ID Token MUST NOT be accepted for processing
- iat REQUIRED. Time at which the JWT was issued
- auth_time Time when the End-User authentication occurred
- nonce String value used to associate a Client session with an ID Token, and to mitigate replay attacks
- acr OPTIONAL. Authentication Context Class Reference. String specifying an Authentication Context Class Reference value that identifies the Authentication Context Class that the authentication performed satisfied
- omr OPTIONAL. Authentication Methods References. JSON array of strings that are identifiers for authentication methods used in the authentication. For instance, values might indicate that both password and OTP authentication methods were used
- azp OPTIONAL. Authorized party – the party to which the ID Token was issued. If present, it MUST contain the OAuth 2.0 Client ID of this party
JSON Object Signing and Encryption (JOSE)
JSON Object Signing and Encryption (JOSE) specifications
In the OpenID Connect context, it is possible for the recipient of a
JWT to accept it without integrity protection in the JWT itself. In
such cases, the recipient chooses to rely on transport security rather than object security.
For example, if the payload is
delivered over a TLS-protected channel, the recipient may regard the
protections provided by TLS as sufficient, so JOSE protection would
not be required.
However, even in this case, it is desirable to associate some
metadata with the JWT payload (claim set), such as the content type,
or other application-specific metadata. In a signed or encrypted
object, these metadata values could be carried in a header with other
metadata required for signing or encryption. It would thus simplify
the design of OpenID Connect if there could be a JOSE object format
that does not apply cryptographic protections to its payload, but
allows a header to be attached to the payload in the same way as a
signed or encrypted object.
Is Daft Punk’s Get Lucky a simile for a brute force attack?
Is your authentication system vulnerable to this risk and its implication?
Have you considered Risk Based Access Management systems and Password Management systems?
Or have you considered not going to nightclubs that play Daft Punk?
The Data Protection Directive (officially Directive 95/46/EC on the protection of individuals with regard to the processing of personal data and on the free movement of such data is a European Union directive which regulates the processing of personal data within the European Union.
The Criteria for Safe Harbour privacy are incorporated into the Directive and subsequently companies operating in the European Union are not allowed to send personal data to countries outside the European Economic Area unless there is a guarantee that it will receive adequate levels of protection.
Various news reports from Manuel Barroso, President of the European Commission, have suggested that Scotland may find it difficult to join the EU. This may by corollary make it difficult for Scotland to immediately remain as part of the European Economic Area.
What does this mean for private data hosted in Scotland?
It is highly likely that hosting providers with physical infrastructure in Scotland will need to determine which customers are EU customers and migrate all of these users to an EU safe harbour before the independence referendum. If Directive 95/46/EC were enforced with strict liability then this preparatory migration (before the independence vote) would be the only sensible risk mitigation.
It would be impossible to move all data from Scottish physical hosting infrastructure before the 18th September 2014. Therefore organisations should consider what data they have hosted in Scotland and which data is most critical for migration following the seven principles of Safe Harbour law.
Guidance on this subject from the UK Information Commissioner’s Office has so far been missing.