Web-of-Things and Services Security

Unrestricted © Siemens AG 2015. All rights reserved
Lecture, University of Passau, November 17, 2015
Web-of-Things and Services:
Security
Siemens Corporate Technology | November 2015

Unrestricted © Siemens AG 2015. All rights reservedPage 2 Nov. 2015 Corporate Technology
What to Expect?
• Off-the-beaten-track vs. folklore:
• This lecture walks off-the-beaten-track: expect storylines and aspects that are not easily
found elsewhere
• It skips folklore where possible: otherwise this slide-deck would explode
• Self-contained vs. 3rd party sources:
• This lecture is eager to be self-contained along its path off-the-beaten-tracks
• It relies on 3rd party sources on other matters
• General IT audience vs. IT-security specialists:
• This lecture aims at a general audience in IT: system/software architects and developers,
product owners, managers, administrators etc. (or those who what to become…)
• It does not assume domain knowledge in IT-security beyond common sense

Security you use –
every day!
Security you will use
The underpinnings
Overview of the Lecture
• Part#1 - Setting-the-Scene
• Security building blocks
• Part#2 - Classic
• Traditional Web security
• Part#3 - New
• Web services security
• Part#4 - Future
• Web-of-Things security

Lecture, University of Passau, 17 November 2015
Web-of-Things and Services Security
Part#1: Building Blocks

Focus of this lecture:
security building blocks and
their utilization for securing the Web
Holistic Approach to IT-Security
Integrate security in
solutions and services
Measure and assure
adequate security level
Design, implement
and select security
building blocks
Operate securely, detect
and handle security
threats and incidents
Enable an organization to
adequately address
security

Securing Distributed Systems
• The Web is a distributed system invented in the 90ies. Most people use the Internet through
Web resp. by means of Web-based technologies (HTTP, URIs/URLs, HTML/XML/JSON)
• Distributed computing resp. systems appeared in the 60/70iers
• The study of distributed systems security started soon after their invention
• Corresponding work falls into following disciplines (examples for an online banking scenario):
• Privacy: understand/control the dissemination/use of personal information
• E.g. “John Doe happened to transfer 1000$“
• Authorization: decide whether to execute an instruction
• E.g. “transfer 1000$ from John Doe’s bank account”
• Authentication: establish confidence in claims that are made by system actors
• E.g. “This is bank24.example” and “I am John Doe” or “I am over 18”
• Secure communications and storage: assure that data is not eavesdropped or
manipulated (e.g. 1000->10000) in exchange or storage
• Credentialing and provisioning: establish/manage the underpinnings for most of above
• E.g. registering John Doe as a user of the online banking and supplying John with means
for transaction approval such as TANs

Characteristics/Dependencies of the Disciplines
• Privacy
• May utilize authorization, secure communications and storage for its enablement
• Is human-centric by definition
• Is an end in itself
• Authorization
• Builds upon authentication
• Authentication
• Builds upon credentialing and (metadata) provisioning
• Is not an end in itself – enables authorization, secure communications and storage as
well as personalization features
• Secure communications and storage
• Employs cryptographic mechanisms
• Builds upon credentialing and authentication (keying associations)
• Credentialing and provisioning
• Uses random number generation, unique identifiers, persistence…
• Is not an end in itself – enables authentication, secure communications and storage

Security Building Blocks
 Cryptographic primitives: algorithms to
transform data
 Encryption vs. signing
• Cryptographic objects: representations of
transformed data along with metadata
• Self-contained vs. raw
• Security tokens: cryptographic objects that
make assessments about system actors
• Versatile vs. static contents
• PoP/HoK vs. bearer security
• Security protocols: multi-party algorithms
specifying how to exchange cryptographic
objects or security tokens
• Synchronous vs. asynchronous

Plain
text
Cipher
text
Plain
text
Private key,
secret key
Public key,
secret key
Encryption Decryption
• Trick: use specific algorithms allowing to
substitute the protection of large amounts
of data (plaintext) by small amounts (keys)
• Steps:
• Encryption: conceal the semantic
meaning of data using encryption keys
• Decryption: reestablish its semantic
meaning using decryption keys
• Types:
• Asymmetric/symmetric encryption
schemes e.g. RSA/AES
• Block/stream ciphers e.g. AES/RC-4
• Playground (for AES)
• Plaintext: Cool
• Key: QNo3n!2§
• Ciphertext:67d0JOhOgY09lVKRkYy3
27xS2TQr6yLrl0eP4c8w0e3nSuo7
DFUJdKW02a3nXdgX
Cryptographic Primitives:
Confidentiality
At risk
(eavesdropping)
Exposable
Public
(algorithm)

Check
sum
OK?
Private key,
secret key
Public key,
secret key
Pay
load
Pay
load
Signing Verifying
• Trick: as above (with a focus on detection)
• Steps:
• Signing: create checksums that bind
contents of data objects to signing keys
• Verifying: validate data contents using
validation keys
• Types:
• Asymmetric/symmetric signing
schemes e.g. RSA/HMAC
• Playground (for HMAC)
• Payload: Cool
• Key: QNo3n!2§
• Check sum:
90ba2f00cffe24cd42c1c9bff595e
cb4aba52444
Cryptographic Primitives:
Message Authentication
At risk
(manipulation)
Exposable
Public
(algorithm)

Reallife
happens
here
Category Property Examples
1. Perfect
cipher
2. ‘Provably
secure cipher‘
3. ‘Provably
strong cipher‘
4. ‘Practical
cipher‘
5. ‘Broken cipher‘
No information gained
by eavesdropping
Cryptoanalysis only by
key exhaustion
Lower bound for
cryptoanalysis provable
Known cryptoanalyses
sufficiently complex
One-time-pad/
Vernam cipher
-
-
AES,
RSA/ECC
FEAL,...
Characteristic
Random keys of
the same length
as messages
Random keys of
limited, pre-
defined length
Cryptoanalysis feasible
Caution:
Nothing Is Perfect!

Cryptographic Objects
• Decryption resp. signature validation can only be done (efficiently)
by different components if metadata is available esp.:
• Pre-encryption resp. pre-signing data serialization and
transformations
• Encryption resp. signature algorithm and its characteristics/
parameters
• Information about encryption resp. signature keys
• Cryptographic objects represent cryptographically transformed data and express such
metadata
• Standardization is needed for interoperability. Important standards include:
• Self-contained approaches:
• PKCS#7/CMS: representing cryptographic objects in ASN.1 syntax
• XML Signature/Encryption: representing cryptographic objects in XML syntax
• JOSE: representing cryptographic objects in JSON syntax
• Raw approaches:
• SSL/TLS record layer: cryptographic objects in raw syntax

Security Tokens
• Cryptographic objects that use specific contents to describe
system actors comprising information about:
• Subject described in the security token
(0..n identifiers/attributes/affiliations/authorizations)
• Issuer of the security token
• Conditions of security token issuance esp. performed
subject authentications (methods, assurance levels)
• Conditions of security token usage esp. validity period, intended recipient/audience,
security model (bearer vs. PoP/HoK), required proof information (PoP, HoK)
• Versatile approaches (“marital status”, “preferred flavor of ice cream” etc.):
• SAML assertions: security tokens in XML syntax (utilizing XML Signature/Encryption),
PoP/HoK or bearer
• JSON Web Tokens: security tokens in JSON syntax (utilizing JOSE), PoP/HoK or bearer
• Static approaches:
• Kerberos tickets: security tokens in ASN.1 syntax (not using PKCS#7/CMS, doing DIY),
always PoP/HoK (Kerberos authenticator objects)

Caution:
There Is an Achilles' Heel!
• Cryptographic keys require attention and care, as an example:
Alice‘s
signature key
101001010011
0100111...
Verification
key for Alice
01010101001
010010...
Alice
Bob
Love
You!
Love
You!
Check-
sum
Love
You!
Check-
sum
OK?Network
Attackers‘s
verification key
0000000000
000000...
Attacker‘s
signature key
11111111111
1111...
Hate
You!
Hate
You!
Check-
sum
Attacker
000000000
000000...
Replace
key value
Intercept,
exchange
message
Hate
You!
Check-
sum

Important Aspects of Key Management
• Security requirements:
• Key establishment:
• Asymmetric schemes: authenticity
• Symmetric schemes: confidentiality and authenticity
• Local key storage:
• Asymmetric schemes: confidentiality (own private keys) and authenticity (peer
public keys, own private keys)
• Symmetric schemes: confidentiality and authenticity (own/peer secret keys)
• Complexity (distributed system with #n participants where all participants interact):
• Key establishment (overall):
• Asymmetric schemes: O(n2), infrastructure (e.g. CAs/RAs) may help
bootstrapping required keying associations
• Symmetric schemes: O(n2), infrastructure (e.g. KDCs) may help bootstrapping
required keying associations
• Local key storage:
• Asymmetric schemes: O(n)
• Symmetric schemes: O(n)

Security Protocols
• Security protocols deal with:
• Exchange of cryptographic objects and/or security tokens
• Establishment and management of keying associations
• They employ cryptographic primitives and objects, security tokens
• Synchronous:
• Kerberos: entity authentication based on security tokens (Kerberos tickets)
• SSL/TLS: encryption and message authentication for application-layer data exchanges
according the request/response pattern – transport-bound protection (more later)
• SSH: encryption and message authentication for application-layer data exchanges –
transport-bound protection
• IPSec: encryption and message authentication for network-layer data exchanges–
transport-bound protection
• Asynchronous:
• S/MIME: encryption and message authentication for application data exchanges
according the store-and-forward pattern – information-bound protection
• PGP: as for S/MIME

Things that Matter:
Security Technology Impact
• Privacy
• Authorization
• Authentication
• Information-bound (protection of data-
at-rest)
• Transport-bound (protection of data-in-
transit
• Credentialing and provisioning
General interest - all in R&D teams need to
have an understanding
Special interest - not saying goofy/
unimportant just: okay if few do understand

Things that Matter:
Security Technology Generations
• Classic
• Invented <2010
• Native to enterprise/office IT and the traditional Web (“Web-of-Pages”)
• Examples: Kerberos, PKIX, S/MIME, SAML, SSL/TLS, XACML
• New
• Invented 2010-2015
• Addressing new Web application styles: Web/REST APIs, mobile/browser-based apps
• Examples: FIDO, JOSE, OAuth, OIDC, SCIM
• Future
• Invented >2015
• Addressing Web-of-Things and Internet-of-Things
• Examples: ACE (not a single mechanism but a container for many), COSE, DICE

Part#2: Traditional Web

Elevator Pitch
• The Web needs security because

Characterizing the Traditional Web aka
“Web-of-Pages”
• Applications: presentation-oriented
• Clients: Web browsers (agents for human users)
• Protocol: HTTP(-over-SSL/TLS) esp. Get, Post
• Resource structure: data objects for human consumption esp. HTML
• Resource addressing: URIs
Request: URL, headers, keywords/values
Response: HTML
CREATE – HTTP Post
Web UI endpoint
(e.g. JSP, JSF)
Request: URL, headers
Response: HTML
READ – HTTP Get
Web browsers Web applications

The Web Security Recipe:
In Theory
• Privacy: P3P
• Authorization: XACML
• Authentication:
• Server authentication: SSL/TLS
• Client resp. user authentication:
• Initial: SSL/TLS, HTTP Basic/Digest
• Subsequent: SPNEGO, SAML/WS-Federation/OpenID/OIDC
• Information-bound: PKCS#7/CMS, XML Signature/Encryption
• Transport-bound: SSL/TLS
• Credentialing and provisioning: CMP/KeyProv/PKCS

The Web Security Recipe:
In Practice
• Privacy: DIY (ubiquitous)
• Authorization: DIY (ubiquitous)
• Authentication:
• Server authentication: SSL/TLS (ubiquitous)
• Initial: DIY (ubiquitous, “Login forms”)
• Subsequent: DIY (ubiquitous, “SSO cookies”)
• Information-bound: unused
• Transport-bound: SSL/TLS (ubiquitous)
• Credentialing and provisioning: DIY (ubiquitous)

So What?
• There only is a single standardized and ubiquitous Web security mechanism: SSL/TLS
• SSL/TLS delivers secure communications (transport-bound) and server
authentication
• It supports client authentication but user authentication is rarely implemented on SSL/TLS
protocol layer - SSL/TLS is not used in understanding whether the caller is a dog
• It does not support privacy (beyond encrypting data in transit), authorization, provisioning
and credentialing
• But there are lots of security mechanisms in Web-based applications esp. for user
authentication and authorization - of course your bank does implement authorization
features for your bank account
• So real-life security in the traditional Web is DIY to a large extent:
• Not saying this is what it should be in a perfect world
• Just saying it is like this – seems viable for the “Web-of-pages”
• In the following: investigate the as-is, real-life Web security

SSL/TLS Facts and History
• SSL/TLS is a family of security protocols to protect
communications between clients and servers over
reliable transports (esp. TCP)
• HTTP-over-SSL/TLS present the backbone of Web security
• Protocol versions:
• TLSv1.2 (IETF, 2008): extensibility
• TLSv1.1 (IETF, 2006): facelift of TLSv1.0
• TLSv1.0 (IETF, 1999): facelift of SSLv3.0,
not interoperable with SSLv3.0
• SSLv3.0 (IETF, 1996): complete redesign,
deprecated by IETF (2015)
• SSLv2.0 (Netscape, 1994): naïve design,
fundamental weaknesses found
• SSLv1.0 (Netscape, ca. 1994): never published
https://www.trustworthyinternet.org/ssl-pulse/

SSL/TLS Properties
• Security protocols to supply channel-
oriented protection:
• Independent from application protocols
(including HTTP but not limited to it)
• Over reliable transports (esp. TCP)
• Stateful (SSL/TLS sessions)
• Augment arbitrary client/server applications
with transport-bound security providing:
• Protocol version and mechanism (cipher
suites) negotiation
• Entity authentication
• Mutual: client and server authentication
• Unilateral: server authentication-only
• Anonymous: no client or server
authentication
• Key establishment
• Message authentication and encryption
TCP/IP
Application
SSL/TLS
Client
TCP/IP
Application
SSL/TLS
Server
Secure channel
Network

SSL/TLS Record Layer
• Fragments, compresses, authenticates, and encrypts payload - application or handshake
layer data:
Application data (e.g. HTTP) or SSL/TLS handshake data
Fragment
Portion ….
Compress
Compressed data ….
Authenticate
Compressed data
SSL/TLS
MAC
….
Encrypt
SSL/TLS payload ….
Append
SSL/TLS
header
SSL/TLS payload ….
• The SSL/TLS record layer processing utilizes shared state established by the SSL/TLS
handshake layer (see below)

Record layer
data
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished
Client identification*,
key exchange,
and authentication*
[ChangeCipherSpec]
Finished
FullTLShandshake
Server
authentication*
*: indicates optional
primitives and services
ClientHello
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
ServerHelloDone
Initialization,
cipher suite negotiation,
server identification*,
and key exchange*
SSL/TLS Handshake Layer
C
l
i
e
n
t
S
e
r
v
e
r

SSL/TLS Entity Authentication Options
• Public key credentials:
• X.509 according PKIX: server-only or client/server authentication
• OpenPGP: server-only or client/server authentication
• Raw keys: server-only or client/server authentication
• Shared secret key credentials:
• Kerberos: client/server authentication
• Note: integrating Kerberos according PKINIT results in server authentication with
shared secret key credentials and client authentication with public key credentials
(X.509 certificates)
• PSK: client/server or client-only authentication
• Note: server authentication is conducted via public key credentials in case of
doing client-only authentication with PSK (RSA_PSK cipher suites)
• Shared secret credentials:
• SRP: client-only authentication
Common practice - other options rarely used or unused

SSL/TLS Integration with the Web
• Protocol integration:
• HTTP-over-TLS: the HTTP exchanges remain unaware of SSL/TLS. The ‘https’
access scheme in URLs triggers the use of SSL/TLS on client side. The server needs
to expose a specific endpoint (port)
• TLS-in-HTTP: clients and servers negotiate the use of SSL/TLS as part of HTTP
exchanges and dynamically upgrade to TLS
• End-to-end span:
• Between client (usually Web browser) and origin servers (or reverse proxies in front of
them). SSL/TLS may traverse forward proxies by means of the HTTP Connect
operation
• Server identity checking:
• The matching of the server hostname against server certificate contents (authenticated
by means of SSL/TLS) is defined in RFC 2818. It shall use the dNSName type in a
subjectAltName extension of the server certificate
• Attention – false friends:
• “HTTPS” does just not exist
• “https” exists: an access scheme in URLs - capitalization matters!
• “HTTP-over-SSL/TLS” exists: a layering of application and security protocols

TTP application
(e.g. DIY,
SAML/WS-Fed IdP)
User
repository
UserauthentictionandSSOUser Authentication:
Trusted Third Party Pattern
Business
application
(e.g. servlet,
JSP, JSF)
Web browsers Presentation-oriented
Web applications
Server authentication,
HTTP message encryption,
data origin authentication Business
resources
Users
1. HTTP request with authn instructions,
triggered by redirection
3. Make selection (opt.), enter
credentials
4. HTTP request with creds (form post)
5. Validate
credentials e.g.
LDAP Bind
6. Create SSO state
(opt.)
2. HTTP response with login form
7. HTTP response (redirect) with
instructions to set cookie header
(„SSO cookie“) and supplementary
security token (opt.)

User Authentication:
Rationale for Trusted Third Parties
• User experience:
• SSO across multiple Web applications in a domain
• Uniform user registration/login for multiple Web applications in a domain
• Functional excellence:
• Accommodate multiple user populations incl. external populations
• Support dynamic, risk-based, adaptive authentication strategies cf. [5]
• System architecture:
• Shield business applications from authentication strategy/protocol/scheme complexity
• Decouple business applications from user store organization/location

User Authentication Breakdown:
Initial Authentication
• Challenging for initial authentication credentials e.g.
• HTML Forms (ubiquitous): custom login page or pop-up (DIY)
• HTTP Basic (some): HTTP response header WWW-Authenticate: Basic
realm=<realm> according the HTTP authorization framework
• SSL/TLS (some): CertificateRequest
• Supplying initial authentication credentials e.g.
• HTML Forms (ubiquitous): HTTP payload
username=<userID>&password=<password> (DIY)
• HTTP Basic (some): HTTP request header Authorization: Basic
<Base64(password)> according the HTTP authorization framework
• SSL/TLS (some): Certificate and CertificateVerify
• Validating initial authentication credentials e.g.
• LDAP Bind operation for passwords resp. shared secrets (via HTML Forms or HTTP Basic)
• DIY for OTPs aka shared secret keys (via HTML Forms)
• SSL/TLS server-side engine for client certificates (or other credential types trucked via
CertificateRequest, Certificate and CertificateVerify)

User Authentication Breakdown:
Subsequent Authentication
• Sustaining initial authentication for recurring requests to the same server:
• Implicit: HTTP cookie headers or other means to share state e.g. URL query parameters
or hidden form fields, cf. RFC 2965
• Note: whether this results in client or server-side SSO state depends on the contents of
the cookie value (self-contained security tokens vs. references)
• Explicit: n.a.
• Transferring initial authentication to (other) servers in the same domain:
• Implicit: HTTP cookie headers (naïve approach, risky unless all components are trusted)
• Explicit: authentication request/response protocol bound to HTTP: DIY, SAML, WS-
Federation or OIDC
• Note: DIY is no good idea but frequently encountered
• Transferring initial authentication to servers in other domains:
• Implicit: n.a.
• Explicit: authentication request/response protocol bound to HTTP: SAML, WS-Federation
or OIDC

Authorization
Subject to a Continental Divide
• Consumer use cases (you@gmail.com):
• Discretionary authorization models are dominant: the owner can do all
supported functions with own resources, others nothing (banking) or
read/comment (social media) – subject to the discretion of the owner
• Implementations are application-specific.
• For Java:
• Programmatic authorization: getUserPrincipal (JSR 315)
• Declarative security: n.a.
• Enterprise use cases (you@my-company.com):
• Role-based authorization (note: this does not say “RBAC”) models are
dominant: the user can do specific operations if possessing specific
attributes or affiliations (group memberships or role assignments)
• Implementations are application resp. application server-specific.
• For Java:
• Programmatic security: isUserInRole (JSR 315)
• Declarative security: rolesAllowed (JSR 315)
• Note that authorization comes in various flavors – access to application object
instances, service endpoints, networks. The former is considered here.

User Credentialing and Provisioning
Subject to a Continental Divide
• Consumer use cases (you@gmail.com):
• HTML-based user self-registration
• Depending on the required quality of identity data (self-asserted vs.
testified) approval processes are implemented
• Common practice: if mail addresses at external providers are
accepted as user identifiers the applicant needs to prove control of
the corresponding mail account
• In most cases shared secrets (passwords) or shared secrets keys
(OTPs) are used as initial user authentication credentials. They are
pushed to the user or pulled from her/him (may utilize secondary
communication channels)
• Enterprise use cases (you@my-company.com):
• Existing user repositories not specific to Web applications (esp. Active
Directory systems) are re-used directly or as a provisioning source for
Web applications resp. their TTP
• These repositories are managed by background processes. Hence
credentialing and provisioning processes are mostly invisible for the
enterprise users (in contrast to consumer users)

Sidetrack:
SAML
• XML framework for exchanging security-related information about subjects (authentication,
attributes, authorizations). Provides an ecosystem for secure transactions across domain
boundaries. Promotes interoperability
• The main use case is SSO. SAML versions are relevant for the provided SSO-UX:
• SAML 2.0: SSO exchanges are initiated by relying parties (by default)
• SAML 1.x: SSO exchanges are always initiated by asserting parties – an issue when users
surf from bookmarks
• The specifications were created by an OASIS technical committee. SAML specs (2.0, 2005):
• Assertions and protocols: XML-based assertion and request/response protocol syntaxes
• Bindings: HTTP (frontchannel exchanges traversing the user agent i.e. Web browser),
SOAP (backchannel exchanges)
• Profiles: SSO, IdP discovery, single logout, name identifier management, artifact resolution,
assertion query, name identifier mapping
• Metadata: mutual configuration contracts
• SAML distributes complexity evenly over asserting and relying party components - an issue
when relying parties are developed by independent 3rd party developers
• SAML is rooted in the enterprise identity camp

Sidetrack:
XACML
• XML framework for expressing authorization policies and authorization requests/responses:
• XACML policy syntax: expresses authorization policies
• XACML context syntax: expresses authorization decision requests and responses
• The main XACML use case is the externalization of authorization. XACML may be used to
implement backend functionality for resource services
• Caveat: for most practical authorization problems, XACML is over-complex. Hence
adaptation is sparse
• The specifications were created by an OASIS technical committee. XACML specs (3.0, 2013):
• Core: XACML version 3.0
• Profiles (selected subset):
• Multiple Decision Profile
• Hierarchical Resource Profile
• Core and Hierarchical Role Based Access Control (RBAC) Profile
• Privacy Policy Profile
• REST Profile
• JSON Profile
• XACML is rooted in the enterprise identity camp

Sidetrack:
OATH
• OATH initiative: industry consortium with ca. 85 member organizations developing an
ecosystem for OTP-based initial authentication:
• Algorithms to generate resp. validate OTP values
• Supporting mechanisms esp. key provisioning
• The main OATH results are published as Internet standards (2005-2011):
• HOTP: An HMAC-Based One-Time Password Algorithm
• Portable Symmetric Key Container (PSKC)
• Dynamic Symmetric Key Provisioning Protocol (DSKPP)
• TOTP: Time-Based One-Time Password Algorithm
• OCRA: OATH Challenge-Response Algorithm
• Note that OATH does not define security protocols to exchange OTPs between claimants and
verifiers (usually TTPs)
• The industry-best practice for OTP-based user authentication in Web applications is to use
HTML forms with custom parameters. This results in proprietary, DIY authentication
protocols. This limitation is addressed by e.g. FIDO
• Attention: do not confuse with OAuth

IP
TCP
SSL/TLS
HTTP
header
HTTP
body
Protocol stack
Security-Enabling the HTTP Stack:
Standards Emerged 1995-2010
Cryptographic
algorithms
Cryptographic
objects
Security token
Security
protocols
Security
infrastructure
Security building blocks
Meta-information

Part#3: Web Services

Elevator Pitch
1. New Web application styles are concerned with:
• Programmatic access to content and resources on the Web
• Cooperation of 2 or more service providers
• Client components authored by independent, 3rd parties
2. Corresponding needs are not covered by the security tools for the “Web-of-Pages” era
(1995-now)
3. Particular white-spots are:
• Web security technologies with an uneven distribution of complexity between the client
and server side
• Web security protocols capable of reflecting #2 or more actors in #1 request (in a
standardized way)
4. This led to a Tsunami of new security technologies (2010-now)

Web Application Styles:
Traditional and New
Browser-based apps
Web browser
UI
AJAX client
DOM
JavaScript
Mobile apps
Native client
UI
Web server
HTTP server
Web server
HTTP server
HTTP client
JSON,XML
HTTP client
JSON,XML
Request
Request
Response
(JSON, XML)
Response
(JSON, XML)
New (ca. 2005-now, predominant as of today)
Composite applications
Application client
HTTP server
Business logic
Web server
HTTP server
HTTP client
JSON,XML
Request
HTML or
JSON,XML
Response
(JSON, XML)
Traditional (ca. 1995-now)
UI
Web server
HTTP server
Web browser
HTTP client
HTML
Request
Response
(HTML)

White-Spots:
Authorizing 3rd Parties
• The famous use case not covered by ‘classic’ security (ditto for other providers/resources):
I want office24.com to print my photos stored at Google Drive
1. Request authz
Office24
GDrive
3. Present user authz
2. Establish authz

White-Spots:
Persisted Login
• Another use case not covered by ‘classic’ security (ditto for other providers/resources):
I want to access my GMail account with a mobile app on my smart phone/tablet
I do not want to enter my GMail credentials again and again
I want to be able to revoke this access if I loose or sell my device
User
Mobile
app
Resources
Enter
credentials
once
Access one Web
application in subsequent
app sessions
Public-facing endpoint
GMail

Characterizing RESTful Web Services
• Applications: service-oriented
• Clients: browser-based apps (AJAX), mobile apps, composite applications
• Protocol: HTTP(-over-SSL/TLS) esp. Post, Get, Put/Patch, Delete
• Resource structure: data objects for machine consumption esp. JSON/XML
• Resource addressing: URIs
Web API
endpoint
(e.g. JAX-RS)
CREATE – HTTP Post
Response: JSON/XML
Request: URL, headers, JSON/XML
Response: JSON/XML
READ – HTTP Get
UPDATE – HTTP Patch/Put
Request: URL, headers, JSON/XML
Response: JSON/XML
DELETE – HTTP Delete
Response: n.a.
Browser-based/
mobile apps,
composite applications
Web applications

Security APIs
Business APIs
Token
endpoint
Post <user creds>
(or refresh_token)
access/refresh_token
Post,Get,Put/Patch,Delete
with access_token
Resource
refresh_token
Token
store
Revocation
endpoint
TokenInfo
endpoint
Device store
API consumer
API provider
Resource
endpoint
User
store
Solutions:
Persisted Login

Security APIs
Business APIs
Post <client creds,code>
access_token
Resource
endpoint
Post,Get,Put/Patch,Delete
with access_token
Resource
Client
store
Token
store
Redirect
with
clientID,
scope
Authz
endpoint
Get <clientID, scope>
Redirect with code
Get
<code>
User
store
(establish user authn/authz)
Get
API provider
API consumer
TokenInfo
endpoint
Token
endpoint
User
Composite
application
Solutions:
Authorizing 3rd Parties

OAuth
• OAuth is a suite of security protocols to acquire, utilize, manage security tokens. It
intentionally distributes complexity unevenly:
• OAuth authorization servers: complex
• OAuth clients (and OAuth-protection of resources servers): incomplex
• OAuth=Tokens@HTTP, OAuth extends HTTP by specifying:
• Supply of security tokens according bearer and PoP/HoK models
• Various exchanges to acquire security tokens according 3
and 2-party exchanges – meeting needs of various use cases
• Means for managing and trading security tokens
• OAuth standards (2.0, 2012-2015, selected RFCs):
• The OAuth 2.0 Authorization Framework
• The OAuth 2.0 Authorization Framework: Bearer Token Usage
• OAuth 2.0 Threat Model and Security Considerations
• OAuth 2.0 Token Revocation
• OAuth 2.0 Dynamic Client Registration Protocol
• OAuth is rooted in the Internet/consumer identity camp
• Attention: do not confuse with OATH

OAuth Grant Types
3-partyexchanges
…
2-partyexchanges
…

OAuth Token Abstractions
3YotnFZFEjr1zCsicMWpAB
Scopes
Refers to
resources
Identifies
user
Validity
period…
Refers to
metadata
Resource owner
password
credentials grants
Refers to
metadata
Scopes
Refers to
resources
Identifies
client
Identifies
user
Validity
period…
Authorization code,
implicit grants
2XotnFZFEjr1zCsicMWpAA
Refers to
metadata
4ZotnFZFEjr1zCsicMWpAC
Scopes
Refers to
resources
Identifies
client
Validity
period…
Client credentials grant

Caution:
Fasten Your Seatbelt!
• OAuth defines the handling of security tokens and also one flavor of security tokens
(JWT) - but is not normative in defining security token contents
• OAuth is a zoo in itself – a toolbox, not a single tool
• Confusion is omnipresent:
• Derivative work frequently contains flaws – learn by implementing rather than reading
• If you read, revert the order:
1. Start with the OAuth-protected resource endpoint
• Interactions are subject to chosen security model: bearer vs. proof
2. Then the OAuth token endpoint
• Interactions are subject to chosen grant type: authorization code, implicit, ROPC,
client credentials, refresh token…
3. Then the other endpoints (subject to use case details, hence grant types) esp. the
OAuth authorization endpoint

Sidetrack:
AJAX, CORS, XMLHttpRequest
• AJAX is a programming model for
interactive Web applications
• AJAX clients (aka browser-based apps) are
downloaded from Web servers and execute
in Web browsers.
• They utilize the HTTP stack of the browser
via the XMLHttpRequest (short: XHR) API
• Whether AJAX clients call ‘home’ makes a
difference:
• Assume an AJAX client wants to call
https://api.my-company.com/coolstuff
• This is a same-origin request if the AJAX
client was downloaded from
(https,api.my-company.com,443)
• Otherwise this is a cross-origin request
• Cross-origin requests are security-critical and
subject of W3C-defined policies enforced by
Web browser and server implementations
Web browser
Rendering, UI
Web application
HTTP server
HTTP client
AJAX client
Script call
XHR
API
Webapplication
HTTPserver
Download
https://api.my-company.com/coolstuff
https://host:port/path
Calls home
or not?

Sidetrack:
OpenID Connect
• OpenID Connect is a security protocol to offload user authentication from resource
servers (relying party) to a trusted third party (asserting party)
• As OAuth descendant it distributes complexity unevenly across client and server roles -
unlike SAML which is capable of doing about the same tricks
• OIDC=OAuth4Authn, inherits from and extends OAuth (grant types: authorization code
and implicit, JWTs) by specifying:
• OAuth authorization request/response message extensions to trigger/provide
instructions about user authentication and report about it
• JWT-based ID tokens i.e. security tokens making assertions about authenticated users
• OAuth-protected UserInfo endpoints
• OIDC standards (1.0, 2014-2015):
• OpenID Connect Core
• OpenID Connect Discovery
• OpenID Connect Dynamic Registration
• OAuth 2.0 Multiple Response Types
• OAuth 2.0 Form Post Response Mode
• OpenID 2.0 to OpenID Connect Migration 1.0

Sidetrack:
JOSE
• JOSE specifies cryptographic objects in JSON
• JOSE=Crypto@JSON, expresses results of cryptographic operations and keys in JSON:
• JWA: expressing cryptographic algorithms
• JWE: expressing encrypted data
• JWS: expressing signatures (symmetric or
asymmetric checksums)
• JWK: expressing cryptographic keys
• JSON standards (2014-2015):
• Use Cases and Requirements forJOSE
• Examples of Protecting Content Using JOSE
• JSON Web Algorithms (JWA)
• JSON Web Encryption (JWE)
• JSON Web Signature (JWS)
• JSON Web Key (JWK)
• JSON Web Key (JWK) Thumbprint

Sidetrack:
JWT
• JWT specifies security tokens in JSON
• JWT=AuthnEvents@JSON, expresses results of entity authentication events in JSON:
• Versatile, application-defined contents (aka claims)
• Signature by utilizing JWS
• Encryption by utilizing JWE
• JWT standards (2015):
• JSON Web Token (JWT)

Sidetrack:
SCIM
• SCIM is a protocol to provision metadata about users/system components
• Original question: how to keep an organization’s users in
sync with a Cloud service?
• Organization: subscriber of a XaaS offering
• Users: employees/customers/partners/suppliers of the XaaS subscriber
• Sync: provision, update, and de-provision user accounts for the XaaS
• Service: XaaS provided in the Cloud
• SCIM=IdM+REST, SCIM defines RESTful Web services for provisioning:
• SCIM client: asserting party e.g. XaaS subscriber (backed by e.g. corporate directory)
• SCIM service: relying party e.g. XaaS provider
• Note: SCIM originated from the Cloud but is not limited to usages with XaaS
• SCIM standards (2.0, 2015):
• Definitions, Overview, Concepts, and Requirements
• Core Schema
• Protocol

Sidetrack:
FIDO
• FIDO alliance: industry consortium with ca. 200 member organizations developing
specifications for advanced initial user authentication in the HTTP stack
• FIDO specifications (1.0, 2014) comprise the:
• Passwordless UX (UAF) specifications:
• 12 individual documents addressing device registration (incl. a local authentication
mechanism) and the UAF protocol that allows services to select which mechanisms are
used to challenge users
• Second Factor UX (U2F) specifications:
• 9 individual documents allowing services to augment the security of their existing
password infrastructure by adding a strong second factor to user login
• FIDO depends on enabling components (“FIDO client”) on the user device (e.g. smart phone,
tablet, laptop, desktop)
• Out-of-scope:
• Authentication of non-user actors
• Post initial authentication features
• Non HTTP-ecosystems

Sidetrack:
UMA
• Specifies an OAuth-based authorization protocol allowing resource owners to control who has
access to their resources:
• This trick is called O-to-* authorization: owners of resources
e.g. jpegs at GDrive authorize 3rd parties for accessing their
resource(s)
• OAuth itself provides a mechanism for O-to-O authorization: owners of resources e.g.
jpegs at GDrive authorize themselves for accessing their resource(s) with 3rd party Web
applications e.g. office24.example
• UMA is developed by a Kantara working group. Main UMA specs are published as IETF
documents (individual drafts, work-in-progress, 2015):
• User-Managed Access (UMA) Profile of OAuth 2.0
• OAuth 2.0 Resource Set Registration
• Binding Obligations on User-Managed Access (UMA) Participants

The Web Services Security Recipe:
Common Practices
• Privacy: DIY
• Authorization: OAuth with DIY security tokens, discretionary models (consumer use
cases) resp. DIY (enterprise use cases) for security token issuance authorization
• Authentication:
• Server authentication: SSL/TLS
• Initial: DIY (“Login forms”) for users, OAuth (client credentials grant) for clients
• Subsequent: OIDC for users, OAuth for clients
• Information-bound: JOSE
• Transport-bound: SSL/TLS
• Credentialing and provisioning: OAuth for clients (part of dynamic client registration),
SCIM

IP
TCP
SSL/TLS
HTTP
header
HTTP
body
Protocol stack
Security-Enabling the HTTP Stack:
Standards Added 2010-2015
Cryptographic
algorithms
Cryptographic
objects
Security token
Security
protocols
Security
infrastructure
Security building blocks
Meta-information

New
invented 2010-2015
New
2005-now
Downhill battle:
in 2015 do start here!
The New Technologies Change the Matchplan
Classic
invented <2010
Traditional
1995-now
Web application style
Web security generation
Does this trick
Insufficient
Old dogs don‘t
learn new tricks
Does this trickDoes this trick too
Apps live here!
Uphill battle:
in 2015 don‘t start here!

Part#4: Web-of-Things

Elevator Pitch
1. There are lots of items in the security toolbox by 2015
2. But WoT needs new tools
3. New security tools will come in 2 forms:
• New security tools that morph/shrink existing tools (smaller, lighter...) i.e. doing old
tricks in new forms
• New security tools doing new tricks
4. The new tools need to come as standards
5. They do emerge right now

Digital vs. Physical Goods
• The IT industry is used to processing digital goods. It has a ‘digital good’ mindset:
• Digital goods — reproduction, relocation of item instances at almost no cost
• Examples: Web pages, messages, contact/mapping information, mp3 files…
• Aspects:
• Static vs. dynamic objects
• Human vs. machine-readable
• Things are physical:
• Physical goods — reproduction, relocation of item instances at cost
• Examples: lighting devices, smoke sensors, thermostats, controllers…
• Aspects:
• Consumer vs. investment goods
• Individually vs. legal entity-owned

WIoT
2010
Things-backed
applications
Things
TheWebwearefamiliarwith
About the Utilization of Web Technologies
2005
Mobile browsers/apps,
Mobile browser
HTML
Mobile apps
XML,JSON
XML,JSON
,JSON
,JSON
1995
Database-backed
applications, desktop
browsers, read-only
User
Web
application
Web container
HTTP
HTML HTML
Web browser
Database
(or directory…)
SQL (or…)
2000
Read/write aka
Web 2.0, AJAX clients
Browser-based apps
XML
,XML

Characterizing the Web-of-Things
• Variety of components/actors e.g.
• Things/devices
• User agents (opt.)
• Intermediaries (opt.)
• Variety of topologies e.g.
• Direct interactions between (user agents
and) things
• Mediated interactions
• Variety of connectivity styles e.g.
• Near field…wide-area
• Intermittent…undisturbed
• Variety of communication patterns e.g.
• Request/response
• Publish/subscribe
• One-way
• Variety of protocols e.g.
• AMQP, CoAP, HTTP, MQTT, XMPP…
User agent Intermediary
(application in e.g. Cloud)
Thing e.g.
alarm/sensor
Thing e.g.
controller

Web-of-Things Has Specific Needs
• Constrained devices and networks
• Callers resp. callees may have (severe) limitations on power supply. processing power,
volatile/static memory, lack of IO devices/user attention, software/configuration update…
• They may interact across low bandwidth, lossy networks possibly with intermittent
communications…
• Not only human users
• Number of callers that are to-be-authenticated grows by a factor of ca. 10
• Not only IT-applications
• Number of callees that are to-be-authenticated: grows by a factor of ca. 10000
• Connectivity, de-perimeterization
• User agents connect from public networks increasing the attack surface (not WoT-
specific)
• Inclusion of physical goods
• Adds complication for known use cases such as software maintenance/update
• Requires to address new use cases such as change-of-ownership (tends to be
ignored/naively solved in digital goods-only systems)

Constrained Devices/Networks:
Classification According IETF RFC 7228
• Class 2:
• Data size (memory): 50 KB
• Code size (flash, disk): 250 KB
• Can interact with Internet nodes.
• Sample protocol: HTTP-over-SSL/TLS
• Class 1:
• Data size (memory):10 KB
• Code size (flash, disk): 100 KB
• May interact with Internet nodes.
• Sample protocol: CoAP-over-DTLS
• Class 0:
• Data size (memory): <<10 KB
• Code size (flash, disk): <<100 KB
• Depend on intermediaries (e.g. class 1 or 2
components) to interact with Internet nodes

Constrained Devices/Networks:
Innovations Needs
• The well-known security building blocks do not match class 1/0 devices
• Results in a need to optimize/innovate security mechanisms
• Optimization needs include:
• Down-scaling of security system implementations
• Lightweight security mechanisms covering
• Cryptographic primitives e.g. ChaCha
• Cryptographic objects e.g. COSE
• Security tokens e.g. CWT
• Security protocols e.g. DICE

Things/devices as callers
(classes 0/1/2)
Not Only Human Users:
Innovation Needs
• The set of actors increases by 1 order of
magnitude (ca. 7’’’ human users, 50’’’ devices)
• New actors have new characteristics:
• Lack of user interfaces and displays
• Unattended operation
• Difficulties in keeping secrets secret (human
users might have them too): scrutinizing
• The current practices (= username/password) rely
on an anti-pattern:
• Users or providers may leak credentials
• Users forget credentials
• Credentials get overexposed (HTTP Basic)
• 3rd parties that ask users for shared secrets
• Results in a need to re-think mechanisms for the
authentication of callers. Required features include:
• Device authentication
• Device identity bootstrapping, credentialing
Message
exchange

Not Only IT-Applications:
Innovation Needs
• The current application/service authentication
practices do not match
• Kerberos: confined to Windows domains i.e.
office/enterprise IT
• SSL/TLS (PKI-based): ca. 5’’ SSL/TLS server
(leaf) certificates exist worldwide but 50’’’
devices projected to have Internet
connectivity by 2020 - a factor of 10’ for a
technology (PKI) that is known to be tedious
• SSH (public key cryptography with
no/lightweight infrastructure): tailored
according specific use cases in IT
• Results in a need to re-think mechanisms for
the authentication of callees
• Required features: as for caller authentication
Things/devices as callees
(classes 0/1/2)
Message
exchange

Connectivity, De-Perimeterization:
Innovation Needs
• The premise disappears
• Drivers: opening-up is needed to enable
new ecosystems
• Obstacles: invalidates the old security
approach “we are safe - we live on an own
island and rely on own technologies”
• Results in a need to adapt mindsets and
priorities in industrial product development
• Required features include:
• Intrusion detection/prevention
• Block suspicious traffic
• Throttling
• Enforce rate-limits, dynamically
determined
• Risk-based authentication
• Determine authentication schemes in a
context-aware, adaptive way
• Include step-up and re-authentication
Today:
Tomorrow:

Inclusion of Physical Goods:
Innovation Needs
• The current approaches do not reflect the
needs of physical goods.
• Change of ownership is commonplace in
industrial IT. Sample scenarios:
• Produce for an unknown customer, sell it
• Produce for known customer who later
sells it (possibly without informing
manufacturer)
• The digital goods approach to reflect and
manage ownership (clone the item) just
does not do the trick for physical goods
• Support of this use case is mandatory. Its
elaboration must address legal concepts:
• Legal entity-owned goods: proxy actors
(managers/admins…) are commonplace
• Individually-owned goods: proxy actors are
an exception
Message
exchange
Decision
enforcement
Decision
making
Token
supply
Caller
Caller
capabilities
Whom is
Resource1 ... Resourcej ... Resourcem
Subject1
...
Subjecti Actionsi,j
...
Subjectn

Architectural Approach of IETF ACE:
Introduces TTPs at Requesting Party Side
Client
Resource
server
Requests resource
Provides resource
Constrained
level
(RFC 7228 class 1/0)
Authorization
manager
Authorization
server
Authentication and
authorization
Authentication,
authorization
support
Authentication,
authorization
support
Less constrained
level
(RFC 7228 class 2)
Principal level
(individuals,
companies)
Resource owners
security domain
Configures Administers
Requesting
party
Resource
owner
Requesting party‘s
security domain

Maturity, Usage vs. WoT Fitness
• Classic security technologies
• Maturity: very high esp. Kerberos, PKIX, S/MIME, SAML, SSL/TLS
• Usage: large-scale production use esp. Kerberos, LDAP, S/MIME, SSL/TLS
• WoT fitness: little to none
• New security technologies
• Maturity: high esp. JOSE, OAuth, OIDC, SCIM
• Usage: large-scale production use esp. OAuth, OIDC
• WoT fitness: limited
• Future security technologies
• Maturity: low (not meant as compliant, this is plain normal for emerging work)
• Usage: experimental to none
• WoT fitness: high

Wrap-Up
• Classic and new security and privacy technologies (only) not do the trick for WoT
• Different constraints: adaptations and optimizations needed
• White-spots: innovation needed
• Such technologies are in their incubation (called “future” for this reason). IETF ACE takes
a leading position in their development:
• Suggesting a (new) trusted 4th party supporting/representing the requesting party
domain (classical/new approaches consider trusted 3rd parties supporting/representing
the resource owner domain)
• This new component currently focuses on the authentication and authorization enabling
but might also offer help with respect to provisioning and credentialing (not yet explored)
• Focuses on the bits exchanged in the network rather than e.g. APIs or software structure
• Caveats:
• Shake-out is needed: lots of ideas and starting points, many at brainstorming stage
(yellow vs. green bananas)
• After shake-out of the protocol building blocks, things can still be screwed up in
implementation (e.g. accidental implementation/deployment errors). Additional means
such as best practice recommendations, compliance/sanity/penetration tests are
needed in addition

More Information
[1] S. Bellovin: Web Security in the Real World. NIST Workshop on Improving Trust. in the
Online Marketplace, April 2013
[2] V. Bertocci: Authentication Protocols, Web UX and Web API. Blog, April 2014
[3] R. Fielding: Architectural Styles and the Design of Network-based Software Architectures.
PhD Thesis. University of California, Irvine, 2000
[4] K. Fu: Dos and Don’ts of Client Authentication on the Web. Proc. 10th USENIX Security
Symposium August 2001
[5] M. Hearn: An update on our war against account hijackers. Blog Feb 2013
[6] M. Jones: A JSON-Based Identity Protocol Suite. Information Standards Quarterly, vol. 26,
no. 3, 2014, pp. 19–22
[7] S. Kent, L. Millet (eds): Who Goes There? Authentication Through the Lens of Privacy.
The National Academies Press, Washington D.C., 2003
[8] C. Pautasso et al.: RESTful Web Services vs. “Big” Web Services: Making the Right
Architectural Decision. Proc. 17th International World Wide Web Conference, Bejing, 2008
[9] W3C WoT Interest Group: Security & Privacy Landscape for WoT. Wiki 2015 (work-in-
progress)
[10] S. Yegge: Stevey's Google Platforms Rant. Blog Oct. 2011

Abbreviations (1)
ACE Authentication and authorization for
Constrained Environments
AES Advanced Encryption Standard
AJAX Asynchronous JavaScript And XML
API Application Programming Interface
ASN.1 Abstract Syntax Notation One
Authn Authentication
Authz Authorization
CA Certification Authority
CBOR Concise Binary Object Representation
CMS Cryptographic Message Syntax
CORS Cross-origin resource sharing
COSE CBOR Object Signing and Encryption
CWT CBOR Web Token
DICE DTLS In Constrained Environments
DIY Do It Yourself
DOM Document Object Model
DTLS Datagram TLS
FIDO Fast IDentity Online
HMAC Hash-based MAC
HoK Holder-of-Key
HTML HyperText Markup Language
HTTP HyperText Transfer Protocol
IAM Identity and Access Management
ID IDentity
IdM Identity Management
IdP Identity Provider
IETF Internet Engineering Task Force
IoT Internet-of-Things
IP Internet Protocol
JAX-RS Java API for RESTful Web Services
JOSE JavaScript Object Signing and Encryption
JSF Java Server Faces
JSON JavaScript Object Notation
JSP Java Server Pages
JSR Java Standardization Request
JWA/E/K/S JSON Web Algorithms/Encryption/Key/
Signature
JWT JSON Web Token
KDC Key Distribution Center
LDAP Lightweight Directory Access Protocol
LoA Level of Assurance
MAC Message Authentication Code
MIME Multipurpose Internet Mail Extensions

Abbreviations (2)
OATH Open Authentication
OAuth Open Authorization
OIDC OpenID Connect
OTP One Time Password
P3P Platform for Privacy Preferences
PKCS Public-Key Cryptography Standards
PKI Public-Key Infrastructure
PKIX PKI X.509
PKINT Public Key cryptography for INITial
authentication (Kerberos)
PoP Proof-of-Possession
PSK Pre-Shared Key
RA Registration Authority
RBAC Role-Based Access Control
REST REpresentational State Transfer
RFC Request For Comments
ROPC Resource Owner Password Credentials
RP Resource Provider
RSA Rivest, Shamir, Adleman
S/MIME Secure MIME
SAML Security Assertion Markup Language
SCIM System for Cross-domain Identity
Management
SOAP Simple Object Access Protocol
SP Service Provider (SAML)
SRP Secure Remote Password
SSH Secure Shell
SSL Secure Sockets Layer
SSO Single-Sign-On
TCP Transmission Control Protocol
TLS Transport Layer Security
TTP Trusted Third Party
UI User Interface
UMA User-Managed Access
URI Uniform Resource Identifier
URL Uniform Resource Locator
UX User eXperience
W3C World-Wide-Web Consortium
WoT Web-of-Things
XaaS Any <X> as a Service (encompassing
Infrastructure, Platform, Software)
XACML eXtensible Access Control Markup
Language
XHR XMLHttpRequest
XML eXtensible Markup Language

Author
Oliver Pfaff, Siemens AG, CT RTC ITS

Web-of-Things and Services Security

More Related Content

What's hot

Similar to Web-of-Things and Services Security

More from Oliver Pfaff

Recently uploaded

Web-of-Things and Services Security