Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Web-of-Things and Services Security

1,071 views

Published on

Lecture held at University of Passau on Nov. 17, 2015

Published in: Technology
  • Be the first to comment

Web-of-Things and Services Security

  1. 1. 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
  2. 2. 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
  3. 3. Unrestricted © Siemens AG 2015. All rights reservedPage 3 Nov. 2015 Corporate Technology 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
  4. 4. Unrestricted © Siemens AG 2015. All rights reserved Lecture, University of Passau, 17 November 2015 Web-of-Things and Services Security Part#1: Building Blocks Siemens Corporate Technology | November 2015
  5. 5. Unrestricted © Siemens AG 2015. All rights reservedPage 5 Nov. 2015 Corporate Technology 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
  6. 6. Unrestricted © Siemens AG 2015. All rights reservedPage 6 Nov. 2015 Corporate Technology 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
  7. 7. Unrestricted © Siemens AG 2015. All rights reservedPage 7 Nov. 2015 Corporate Technology 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 • Is an end in itself • 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) • Is an end in itself • Credentialing and provisioning • Uses random number generation, unique identifiers, persistence… • Is not an end in itself – enables authentication, secure communications and storage
  8. 8. Unrestricted © Siemens AG 2015. All rights reservedPage 8 Nov. 2015 Corporate Technology 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
  9. 9. Unrestricted © Siemens AG 2015. All rights reservedPage 9 Nov. 2015 Corporate Technology 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)
  10. 10. Unrestricted © Siemens AG 2015. All rights reservedPage 10 Nov. 2015 Corporate Technology 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)
  11. 11. Unrestricted © Siemens AG 2015. All rights reservedPage 11 Nov. 2015 Corporate Technology 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!
  12. 12. Unrestricted © Siemens AG 2015. All rights reservedPage 12 Nov. 2015 Corporate Technology 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
  13. 13. Unrestricted © Siemens AG 2015. All rights reservedPage 13 Nov. 2015 Corporate Technology 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) • Standardization is needed for interoperability. Important standards include: • 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)
  14. 14. Unrestricted © Siemens AG 2015. All rights reservedPage 14 Nov. 2015 Corporate Technology 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
  15. 15. Unrestricted © Siemens AG 2015. All rights reservedPage 15 Nov. 2015 Corporate Technology 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)
  16. 16. Unrestricted © Siemens AG 2015. All rights reservedPage 16 Nov. 2015 Corporate Technology 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 • Standardization is needed for interoperability. Important standards include: • 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
  17. 17. Unrestricted © Siemens AG 2015. All rights reservedPage 17 Nov. 2015 Corporate Technology Things that Matter: Security Technology Impact • Privacy • Authorization • Authentication • Secure communications and storage • 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
  18. 18. Unrestricted © Siemens AG 2015. All rights reservedPage 18 Nov. 2015 Corporate Technology 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
  19. 19. Unrestricted © Siemens AG 2015. All rights reserved Lecture, University of Passau, 17 November 2015 Web-of-Things and Services Security Part#2: Traditional Web Siemens Corporate Technology | November 2015
  20. 20. Unrestricted © Siemens AG 2015. All rights reservedPage 20 Nov. 2015 Corporate Technology Elevator Pitch • The Web needs security because
  21. 21. Unrestricted © Siemens AG 2015. All rights reservedPage 21 Nov. 2015 Corporate Technology 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
  22. 22. Unrestricted © Siemens AG 2015. All rights reservedPage 22 Nov. 2015 Corporate Technology 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 • Secure communications and storage • Information-bound: PKCS#7/CMS, XML Signature/Encryption • Transport-bound: SSL/TLS • Credentialing and provisioning: CMP/KeyProv/PKCS
  23. 23. Unrestricted © Siemens AG 2015. All rights reservedPage 23 Nov. 2015 Corporate Technology The Web Security Recipe: In Practice • Privacy: DIY (ubiquitous) • Authorization: DIY (ubiquitous) • Authentication: • Server authentication: SSL/TLS (ubiquitous) • Client resp. user authentication: • Initial: DIY (ubiquitous, “Login forms”) • Subsequent: DIY (ubiquitous, “SSO cookies”) • Secure communications and storage • Information-bound: unused • Transport-bound: SSL/TLS (ubiquitous) • Credentialing and provisioning: DIY (ubiquitous)
  24. 24. Unrestricted © Siemens AG 2015. All rights reservedPage 24 Nov. 2015 Corporate Technology 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
  25. 25. Unrestricted © Siemens AG 2015. All rights reservedPage 25 Nov. 2015 Corporate Technology 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/
  26. 26. Unrestricted © Siemens AG 2015. All rights reservedPage 26 Nov. 2015 Corporate Technology 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
  27. 27. Unrestricted © Siemens AG 2015. All rights reservedPage 27 Nov. 2015 Corporate Technology 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)
  28. 28. Unrestricted © Siemens AG 2015. All rights reservedPage 28 Nov. 2015 Corporate Technology 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
  29. 29. Unrestricted © Siemens AG 2015. All rights reservedPage 29 Nov. 2015 Corporate Technology 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
  30. 30. Unrestricted © Siemens AG 2015. All rights reservedPage 30 Nov. 2015 Corporate Technology 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
  31. 31. Unrestricted © Siemens AG 2015. All rights reservedPage 31 Nov. 2015 Corporate Technology 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.)
  32. 32. Unrestricted © Siemens AG 2015. All rights reservedPage 32 Nov. 2015 Corporate Technology 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
  33. 33. Unrestricted © Siemens AG 2015. All rights reservedPage 33 Nov. 2015 Corporate Technology 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)
  34. 34. Unrestricted © Siemens AG 2015. All rights reservedPage 34 Nov. 2015 Corporate Technology 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
  35. 35. Unrestricted © Siemens AG 2015. All rights reservedPage 35 Nov. 2015 Corporate Technology 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.
  36. 36. Unrestricted © Siemens AG 2015. All rights reservedPage 36 Nov. 2015 Corporate Technology 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)
  37. 37. Unrestricted © Siemens AG 2015. All rights reservedPage 37 Nov. 2015 Corporate Technology 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
  38. 38. Unrestricted © Siemens AG 2015. All rights reservedPage 38 Nov. 2015 Corporate Technology 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
  39. 39. Unrestricted © Siemens AG 2015. All rights reservedPage 39 Nov. 2015 Corporate Technology 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
  40. 40. Unrestricted © Siemens AG 2015. All rights reservedPage 40 Nov. 2015 Corporate Technology 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
  41. 41. Unrestricted © Siemens AG 2015. All rights reserved Lecture, University of Passau, 17 November 2015 Web-of-Things and Services Security Part#3: Web Services Siemens Corporate Technology | November 2015
  42. 42. Unrestricted © Siemens AG 2015. All rights reservedPage 42 Nov. 2015 Corporate Technology 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)
  43. 43. Unrestricted © Siemens AG 2015. All rights reservedPage 43 Nov. 2015 Corporate Technology 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)
  44. 44. Unrestricted © Siemens AG 2015. All rights reservedPage 44 Nov. 2015 Corporate Technology 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
  45. 45. Unrestricted © Siemens AG 2015. All rights reservedPage 45 Nov. 2015 Corporate Technology 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
  46. 46. Unrestricted © Siemens AG 2015. All rights reservedPage 46 Nov. 2015 Corporate Technology 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 Request: URL, headers 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 Request: URL, headers Response: n.a. Browser-based/ mobile apps, composite applications Web applications
  47. 47. Unrestricted © Siemens AG 2015. All rights reservedPage 47 Nov. 2015 Corporate Technology 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
  48. 48. Unrestricted © Siemens AG 2015. All rights reservedPage 48 Nov. 2015 Corporate Technology 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
  49. 49. Unrestricted © Siemens AG 2015. All rights reservedPage 49 Nov. 2015 Corporate Technology 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
  50. 50. Unrestricted © Siemens AG 2015. All rights reservedPage 50 Nov. 2015 Corporate Technology OAuth Grant Types 3-partyexchanges … 2-partyexchanges …
  51. 51. Unrestricted © Siemens AG 2015. All rights reservedPage 51 Nov. 2015 Corporate Technology 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
  52. 52. Unrestricted © Siemens AG 2015. All rights reservedPage 52 Nov. 2015 Corporate Technology 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
  53. 53. Unrestricted © Siemens AG 2015. All rights reservedPage 53 Nov. 2015 Corporate Technology 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?
  54. 54. Unrestricted © Siemens AG 2015. All rights reservedPage 54 Nov. 2015 Corporate Technology 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
  55. 55. Unrestricted © Siemens AG 2015. All rights reservedPage 55 Nov. 2015 Corporate Technology 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
  56. 56. Unrestricted © Siemens AG 2015. All rights reservedPage 56 Nov. 2015 Corporate Technology 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)
  57. 57. Unrestricted © Siemens AG 2015. All rights reservedPage 57 Nov. 2015 Corporate Technology 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
  58. 58. Unrestricted © Siemens AG 2015. All rights reservedPage 58 Nov. 2015 Corporate Technology 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
  59. 59. Unrestricted © Siemens AG 2015. All rights reservedPage 59 Nov. 2015 Corporate Technology 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
  60. 60. Unrestricted © Siemens AG 2015. All rights reservedPage 60 Nov. 2015 Corporate Technology 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 • Client resp. user authentication: • Initial: DIY (“Login forms”) for users, OAuth (client credentials grant) for clients • Subsequent: OIDC for users, OAuth for clients • Secure communications and storage • Information-bound: JOSE • Transport-bound: SSL/TLS • Credentialing and provisioning: OAuth for clients (part of dynamic client registration), SCIM
  61. 61. Unrestricted © Siemens AG 2015. All rights reservedPage 61 Nov. 2015 Corporate Technology 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
  62. 62. Unrestricted © Siemens AG 2015. All rights reservedPage 62 Nov. 2015 Corporate Technology 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!
  63. 63. Unrestricted © Siemens AG 2015. All rights reserved Lecture, University of Passau, 17 November 2015 Web-of-Things and Services Security Part#4: Web-of-Things Siemens Corporate Technology | November 2015
  64. 64. Unrestricted © Siemens AG 2015. All rights reservedPage 64 Nov. 2015 Corporate Technology 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
  65. 65. Unrestricted © Siemens AG 2015. All rights reservedPage 65 Nov. 2015 Corporate Technology 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
  66. 66. Unrestricted © Siemens AG 2015. All rights reservedPage 66 Nov. 2015 Corporate Technology WIoT 2010 Things-backed applications Things TheWebwearefamiliarwith About the Utilization of Web Technologies 2005 Mobile browsers/apps, Composite applications Mobile browser HTML Mobile apps XML,JSON Composite applications 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
  67. 67. Unrestricted © Siemens AG 2015. All rights reservedPage 67 Nov. 2015 Corporate Technology 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
  68. 68. Unrestricted © Siemens AG 2015. All rights reservedPage 68 Nov. 2015 Corporate Technology 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)
  69. 69. Unrestricted © Siemens AG 2015. All rights reservedPage 69 Nov. 2015 Corporate Technology 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
  70. 70. Unrestricted © Siemens AG 2015. All rights reservedPage 70 Nov. 2015 Corporate Technology 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
  71. 71. Unrestricted © Siemens AG 2015. All rights reservedPage 71 Nov. 2015 Corporate Technology 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
  72. 72. Unrestricted © Siemens AG 2015. All rights reservedPage 72 Nov. 2015 Corporate Technology 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
  73. 73. Unrestricted © Siemens AG 2015. All rights reservedPage 73 Nov. 2015 Corporate Technology 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:
  74. 74. Unrestricted © Siemens AG 2015. All rights reservedPage 74 Nov. 2015 Corporate Technology 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
  75. 75. Unrestricted © Siemens AG 2015. All rights reservedPage 75 Nov. 2015 Corporate Technology 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
  76. 76. Unrestricted © Siemens AG 2015. All rights reservedPage 76 Nov. 2015 Corporate Technology 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
  77. 77. Unrestricted © Siemens AG 2015. All rights reservedPage 77 Nov. 2015 Corporate Technology 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
  78. 78. Unrestricted © Siemens AG 2015. All rights reservedPage 78 Nov. 2015 Corporate Technology 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
  79. 79. Unrestricted © Siemens AG 2015. All rights reservedPage 79 Nov. 2015 Corporate Technology 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
  80. 80. Unrestricted © Siemens AG 2015. All rights reservedPage 80 Nov. 2015 Corporate Technology 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
  81. 81. Unrestricted © Siemens AG 2015. All rights reservedPage 81 Nov. 2015 Corporate Technology Author Oliver Pfaff, Siemens AG, CT RTC ITS

×