New Trends in Web Security

  • 4,229 views
Uploaded on

My 2012 homerun in IT-security: For many years nothing happened in Web security - with respect to security-enabling the HTTP stack. This is not true anymore: game-changing innovations do emerge right …

My 2012 homerun in IT-security: For many years nothing happened in Web security - with respect to security-enabling the HTTP stack. This is not true anymore: game-changing innovations do emerge right now. Their impact will - likely - be pervasive. It is important to understand what exactly is being launched, why this is happening and which forces are driving this. This presentation establishes this context and elaborates on the implications.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
4,229
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
0
Comments
0
Likes
3

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. New Trends in Web Security Oliver Pfaff May 10, 2012
  • 2. A Journey through Time – 2000 to 2012 Authentication Authorization IAM (Identity and IT-security Access Management) Federation ▶ Enterprise camp: identities/resources Has use cases owned by legal entities driving current innovation ▶ Internet camp: identities/resources owned by individual usersMay 2012 2
  • 3. Security-Enabling the HTTP Stack -Until 2010 Protocol stack Security fabric No help - does match target environment WS-*/ Security WS- infrastructure Security HTTP body HTTP Security Security header protocols syntax SSL/TLS Security token TCP Helps - but does not cover given use cases IP Meta-information Cryptographic algorithmsMay 2012 3
  • 4. Driving Forces ▶ Constrained clients:  Smart phones/tablets accessing via mobile networks  Promote native clients: talk HTTP, serve single users – but are no classical Web browsers ▶ API economy:  Content aggregation via mash-ups/composite applications, Web APIs exposing lightweight interfaces, RESTful Web services – no WS-*  Promote application clients: talk HTTP, serve multiple users ▶ Cloud:  Procure IT from the network: applications (SaaS), software (PaaS) or hardware infrastructure (IaaS)  For many organizations "owning iron" is a snail’s pace approach. Holds for the server side (XaaS) and the client side (BYOD) ▶ Disillusion:  Some things did not fly such as PKI to the end-user: • Not handy: people do not understand PKI – even IT pro’s struggle • Compromises: Comodo/DigiNotar/StartTLS CAs, DuQu, Stuxnet • Ramifications of lemon markets (Nobel prize-awarded theory) applyMay 2012 4
  • 5. …Their Constraints/Needs/Use Cases▶ Constrained clients:  Interactions: server-side, no client-side redirections  Compact representations: new formats for security objects, no WS-*▶ API economy:  Authenticate API clients: new authentication schemes for HTTP 3-party scenarios  Manage access to personal resources: new authorization protocols  Move identity data (for self): on-boarding of individual users▶ Cloud:  Externalize user authentication: provide seamless access (i.e. SSO)  Manage identity data (for any): user on-boarding in bulk-style  Manage authorization: govern access control for subscriber resources▶ Disillusion:  Alternate entity authentication schemes: stronger than username/static password, less awkward than public key certificate and private key  Supply meta-information: express to relying parties how authentication and identity creation was doneMay 2012 5
  • 6. Use Cases Requiring 3-Party Exchanges▶ Manage access to personal resources  Prerequisites: user and asserting/relying party authentication▶ Move identity data (for self)  Prerequisites: user and asserting/relying party authentication▶ Externalize user authentication  Prerequisite: user and asserting party authentication Personal App resources Identity HTTP data UI SSL/ User App TLS authentication HTTP TCP/ SSL/ HTTP IP TLS Asserting party TCP/ SSL/ IP TLS TCP/ User agent IP Relying partyMay 2012 6
  • 7. 3-Party Exchange Pattern – Functional Requirements User ▶ Facilitate 3-party overlay: Authn agent  User agent to asserting party - security with Provide endpoint: creds grant • Entitle relying party after authenticating • UI-style: entitlement dialogue with arbitrary Web user authentication Asserting  Relying party to asserting party - party security endpoint:Entitle- Security Resource • Obtain security token afterment endpoint endpoint authenticating • API-style: new protocols with Provide arbitrary Web client authentication token Authn  Relying party to asserting party – with resource endpoint: token • Obtain resource access after authenticating Authn with • API-style: new authentication creds Relying protocols (token-based) party May 2012 7
  • 8. 3-Party Exchange Pattern –Non-Functional Requirements ▶ 3-party exchanges between relying and asserting parties – via user agents esp. 3-party exchanges: constrained clients: Sub- HTTP  Use HTTP 3xx redirects HTTP  Employ URL query parameters for Hdr. Body exchange of security token acquisition N.a. objects and their responses ▶ Subsequent 2-party exchanges between URL N.a. relying and asserting parties: query  Use HTTP Authorization headers for authentication purposes based on security tokens 2-party exchanges: ▶ URL query parameters as well as HTTP Sub- HTTP Authorization headers are space- HTTP constrained: Hdr. Body  Objects to acquire and utilize security SSL/ tokens must match these constraints TLS  Note: SAML assertion/protocol syntax Authn Var. objects are suspect of violating them headerMay 2012 8
  • 9. Identifying the New Entrants▶ Constrained clients:  Interactions: N.a.  Compact representations: JWA, JWE, JWK, JWS (IETF jose WG) and JWT (IETF individual submission)▶ API economy:  Authenticate API clients: HTTP Bearer and MAC authentication (IETF oauth WG)  Manage access to personal resources: OAuth (IETF oauth WG), UMA (Kantara)  Move identity data (for self): OpenID Connect (OpenID)▶ Cloud:  Externalize user authentication: OpenID Connect (OpenID)  Manage identity data (for any): SCIM (IETF WG candidate)  Manage authorization: XACML 3.0 administration and delegation profile (OASIS)▶ Disillusion:  Alternate authentication schemes: TOTP (RFC 6238), HOTP (RFC 4226), callbacks (custom)  Supply meta-information: assurance levels (NIST SP800-63, ITU-T X.1254 | ISO/IEC 29115, Kantara IAF)May 2012 9
  • 10. Layering the New Entrants Use case-specific GenericMay 2012 10
  • 11. Security Fabric for the HTTP Stack –From ca. 2012 Provides request authn JWS IETF Draft HTTP request authn IETF Draft Provides entity JWE IETF Draft authentication Provides service for managing Provides token Security token authn Security token service <Abstract> <Abstract> Provides token Instantiates Instantiates encryption OAuth authz JWT UMA Promotes server IETF individual Kantara IETF Draft submission Draft IncludesOpenID OAuthConnect Extends IETF Draft OpenID DraftMay 2012 11
  • 12. Security Fabric for the SOAP Stack –From ca. 2007 (for reference purposes) Provides msg Allows publishing of authn XML Signature W3C standard SOAP Message Provides msg WS-Policy WS-SecurityPolicy Security encryption W3C OASIS standard OASIS standard standard (WS-SX TC) (WSS TC) Defines Allows profiling of Provides entity XML Encryption security for W3C standard authentication STSs Provides service for managing Provides token Security token authn Security token service <Abstract> <Abstract> Provides token Instantiates Instantiates encryption SAML assertion WS-Trust OASIS standard OASIS standard (SAML TC) (WS-SX TC) Extends WSFED OASIS committee specificationMay 2012 12
  • 13. Security-Enabling the HTTP Stack -From ca. 2012 Protocol stack Security fabric Security infrastructure HTTP body HTTP Security Security header protocols syntax SSL/TLS Security token TCP Meta-information Cryptographic IP algorithmsMay 2012 13
  • 14. Is It Real?▶ 4-party security protocol examples: – UMA: http://kantarainitiative.org/confluence/display/uma/UMA+Implementations▶ 3-party security protocol examples: – OIDC relying party: http://www8322u.sakura.ne.jp/oidconnect/ – OIDC asserting party: http://oauthssodemo.appspot.com/step/1 – OAuth relying party: https://twitter.com/#!/who_to_follow/import/ – OAuth asserting party: https://accounts.google.com/OAuthAuthorizeToken▶ 2-party security protocol examples: – HTTP Bearer authentication: cf. OpenID Connect sample – HTTP MAC authentication: N.a. - current implementations utilize HTTP Bearer.▶ Security infrastructure examples: – OAuth authorization server: cf. OpenID Connect sample▶ Security token examples: – JWT: cf. OpenID Connect sample▶ Meta-information syntax examples: – LoA: N.a.▶ Security syntax examples: – JWA/E/K/S: cf. OpenID Connect sampleMay 2012 14
  • 15. Conclusions▶ It is amazing what is happening right now – security-wise as well as IAM-wise▶ The current innovation is triggered by use cases from the Internet IAM camp. In particular, it addresses needs related to Web 2.0 as well as social networks▶ This does not imply that the emerging mechanisms are limited to these domains: – Other industries have matching use cases e.g. user-managed access to medical data to-be-shared among healthcare providers (ECRs – Electronic Case Records) – Their resolution delivers security mechanisms that can be (re-)used in other use cases – Security functionality for 3-party Web exchanges presents a main focus. Such 3-party exchanges also apply in other industries – probably with some other details but likely requiring similar patterns and approaches.▶ The evolution of specifications, implementation of toolkits (many open source) and supply of services on the Internet happens in parallel▶ This innovation in Web security is still ongoing and not yet concludedMay 2012 15
  • 16. AbbreviationsAJAX Asynchronous JavaScript And XMLAPI Application Programming InterfaceAWS Amazon Web ServicesBYOD Bring Your Own DeviceCA Certification AuthorityCMS Cryptographic Message SyntaxECC Elliptic Curve CryptographyHMAC Hash-based Message Authentication CodeHOTP HMAC-based OTPHTML HyperText Markup LanguageHTTP HyperText Transfer ProtocolIaaS Infrastructure as a ServiceIAF Identity Assurance FrameworkIAM Identity and Access ManagementJOSE JavaScript Object Signing and EncryptionJSON JavaScript Object NotationJWA/E/K/S/T JSON Web Algorithms/Encryption/Key/Signature/TokenLoA Level of AssuranceOATH Open AuthenticationOAuth Open AuthorizationMay 2012 16
  • 17. Abbreviations (cont’d)OIDC OpenID ConnectOTP OneTime PasswordPaaS Platform as a ServicePKCS Public-Key Cryptography StandardsPKI Public Key InfrastructurePoP Proof-of-PossessionREST REpresentational State TransferSaaS Software as a ServiceSAML Security Assertion Markup LanguageSCIM Simple Cloud Identity ManagementSOAP Simple Object Access ProtocolSSL Secure Sockets LayerSTS Security Token ServiceTLS Transport Layer SecurityTOTP Time-based OTPUMA User-Managed AccessURL Uniform Resource LocatorWS Web ServicesXaaS Any X offered ’as-a-Service’XML eXtensible Markup LanguageMay 2012 17
  • 18. Background▶ Fielding, R.: Architectural Styles and the Design of Network-based Software Architectures. PhD Thesis. University of California, Irvine, 2000.▶ Gutmann, P.: PKI: Lemon Markets and Lemonade. RSA Security Conference 2011.▶ Jones, M.: The Emerging JSON-Based Identity Protocol Suite. W3C Workshop on Identity in the Browser, 2011.▶ Machulak, M.P. et al.: User-Managed Access to Web Resources. Proceedings of the 6th ACM Workshop on Digital Identity Management, 2010.▶ Mash-up directory: http://www.programmableweb.com/mashups/directory▶ Pautasso, C.; Zimmermann, O.; Leymann, F.: RESTful Web Services vs. “Big” Web Services: Making the Right Architectural Decision. Proc. of the 17th International World Wide Web Conference, Bejing, 2008.▶ Prins, J.R.: DigiNotar Certificate Authority breach “Operation Black Tulip”. Interim Report: Investigation DigiNotar Certificate Authority Environment, 2011.▶ Rabin, J.; McCathieNevile, C. (eds.): Mobile Web Best Practices 1.0. W3C Recommendation 2008.▶ Rutkowski, M. (ed.): Identity in the Cloud Use Cases Version 1.0. OASIS Committee Note, 2012.▶ Web API directory: http://www.programmableweb.com/apis/directory▶ Yegge, S.: Steveys Google Platforms Rant. 2011May 2012 18
  • 19. AuthorOliver Pfaff, oliver.frank.pfaff@gmail.comMay 2012 19
  • 20. Web Application Styles Traditional AJAX-aware Mobile Mash-up Web browser Web browser Native client Application client UI UI UI HTTP server JavaScript HTML or HTML HTML JSON,XML JSON,XML HTTP client AJAX engine HTTP client Business logicRequest JSON,XML Request JSON,XML HTTP client HTTP client Request Request Response Response Response Response (HTML) (JSON, XML) (JSON, XML) (JSON, XML) HTTP server HTTP server HTTP server HTTP server Web server Web server Web server Web server UI-style IO API-style IOMay 2012 20
  • 21. Characterizing Client-Side Components▶ Web browsers: – HTTP client with address bar, serves resources of arbitrary services – HTML as primary media type (UI-style) – Client-side scripting support – Serves #1 simultaneous user – Examples: Google Chrome, Microsoft Internet Explorer, Mozilla Firefox▶ Native clients: – HTTP client without address bar, serves resources of a specific service – HTML (UI-style) or JSON/XML as primary media type (API-style) – Serves #1 simultaneous user – Example: Android/iPhone Web apps▶ Application clients: – HTTP client and server – JSON/XML as primary media type towards downstream application (API-style) – Provides own application/business functionality (i.e. not only a HTTP proxy) – Serves #n simultaneous users – Example: Amazon & eBay comparison shoppingMay 2012 21
  • 22. Security Fabric for the HTTP Stack –Until 2010▶ Security fabric is broadly absent in the actual HTTP layer: – HTTP Basic authentication: username/password-based authentication • Transfers credentials in plain (to be precise: Base64 encoded) • Unpopular: HTML form-based authentication is preferred – HTTP Digest authentication: shared secret key-based authentication • Not used in practice – Custom HTTP authentication methods: Kerberos/NTLM-based authentication • Used for integrated Windows authentication – HTTP session state mechanisms: • No actual security mechanism but a factor in the security fingerprint▶ Security fabric is present: – Underneath the HTTP layer: SSL/TLS – Above the HTTP layer: WS-Security▶ Caveats: – Underneath the HTTP layer: hard to support complex use cases – Above the HTTP layer: adds significant infrastructural burdenMay 2012 22
  • 23. 4-Party Security Protocols –User-Managed Access - UMA▶ UMA refines OAuth 2.0: – Allows users to manage access to individual resources, residing on any number of OAuth resource servers, through a single OAuth authorization server – Extends OAuth by formalizing interactions between OAuth resource and authorization servers (underspecified in OAuth) – Promotes OAuth authorization servers to independent network services – hence turns the 3-party protocol OAuth into a 4-party protocol – Extends the OAuth notion of scope and hence enhances the granularity of access control – More information: Comparing OAuth and UMA, UMA Frequently Asked Questions▶ The specifications are developed by a Kantara working group: – User-Managed Access (UMA) Core Protocol (Draft 2012 also published as IETF Draft - individual submission) – UMA Trust Model (Draft 2012) – UMA Scenarios and Use Cases (Draft 2010) – UMA User Stories (Draft 2010)▶ Familiar to: -May 2012 23
  • 24. 3-Party Security Protocols –OpenID Connect▶ OpenID Connect defines an identity layer on top of OAuth 2.0: – Exploits and extends OAuth for a specific kind of resources: data specific to user authentication and user identity (e.g. data persisted in user accounts) – Turns a solution for the delegation use case in access management into an approach for the federation use case in identity management▶ The specifications are developed by the OpenID community: – Basic Client Profile (Draft 2012) – Discovery (Draft 2012) – Dynamic Registration (Draft 2012) – Standard (Draft 2012) – Messages (Draft 2012) – Session Management (Draft 2012)▶ Familiar to: SAML, WS-Federation (passive profile), OpenID (note: it’s relation to the original OpenID protocol is loose)▶ More information: OpenID Connect - An Emperor Or Just New Cloths?May 2012 24
  • 25. 3-Party Security Protocols –OpenID Connect Exchange Pattern2. Authn with user credentials, User 1. Redirect user agent to delegate access to identity data agent OAuth authz endpoint, provide oidc:Request object 4. Redirect user agent to relying party with oauth:Grant Asserting party Security UserInfo3. Store entitlement endpoint endpoint6. Respond with 9. Respond with user info oauth:AccessToken, oidc:IdToken5. Authn with client 8. Authn with credentials, supply oauth:AccessToken, oauth:Grant, request request user info oauth:AccessToken, oidc:IdToken Relying7. Consume oidc:IdToken party 10. Process user info May 2012 25
  • 26. 3-Party Security Protocols –OAuth▶ OAuth allows resource owners to delegate resource access rights to third-party consumers (such as composite applications in a mash-up) in a discretionary fashion with a limited scope (functionality, time).▶ The specifications are developed by the IETF oauth working group: – The OAuth 2.0 Authorization Framework (Draft 2012) – The OAuth 1.0 Protocol (RFC 5849, 2010)▶ Familiar to: -▶ More information: Analyzing OAuthMay 2012 26
  • 27. 3-Party Security Protocols –OAuth Exchange Pattern2. Authn with user credentials, User 1. Redirect user agent to delegate access to resource agent OAuth authz endpoint 4. Redirect user agent to relying party with oauth:Grant Asserting party Security Resource3. Store entitlement endpoint endpoint6. Respond with 8. Respond with resource oauth:AccessToken5. Authn with client 7. Authn with credentials, supply oauth:AccessToken, oauth:Grant, request request resource oauth:AccessToken Relying party 9. Process resource May 2012 27
  • 28. 2-Party Security Protocols –HTTP Bearer Authentication▶ OAuth-defined mechanism extending the HTTP access authentication framework (RFC 2616) – may be used independent of OAuth: – WWW-Authenticate response header: specifies the authentication method (Bearer) and allows to specify realm and scope parameters – Authorization request header: transfers a bearer token in Base64 encoding▶ Bearer tokens: – Any party in possession of the token can use it to get access to the associated resources - without demonstrating possession of a cryptographic key – Supported form-factors: • SAML Assertion objects (self-contained security token) • JSON Web tokens (self-contained security token)▶ The specifications are developed by the IETF oauth working group: – The OAuth 2.0 Authorization Protocol: Bearer Tokens (Draft 2012) – SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 (Draft 2012) – JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0 (Draft 2012)▶ Familiar to: -May 2012 28
  • 29. 2-Party Security Protocols –HTTP MAC Authentication▶ OAuth-defined mechanism extending the HTTP access authentication framework (RFC 2616) – may be used independent of OAuth: – WWW-Authenticate response header: specifies the authentication method (MAC) – Authorization request header: transfers a symmetric cryptographic checksum over portions of the HTTP request▶ MAC tokens: – Any party using the token needs to demonstrate possession of a cryptographic key. Keying associations are established out-of-band or employ OAuth access tokens. – Supported form-factor: identifier token▶ The specification is developed by the IETF oauth working group: – HTTP Authentication: MAC Access Authentication (Draft 2012)▶ Familiar to:  HTTP Digest authentication (RFC 2617, does require a user password)  HTTP OAuth authentication (RFC 5849, a predecessor)  HTTP AWS authentication (AWS proprietary)May 2012 29
  • 30. 2-Party Security Protocols –OTP Authentication▶ HOTP, TOTP and OCRA define the exchanges between claimants and verifiers in order to establish shared secret key-based entity authentication - without binding the exchanges to an actual transfer protocol (typical implementations use HTTP through HTML forms): – HOTP: event-based OTPs – TOTP: time-based OTPs – OCRA: challenge/response-based OTPs▶ PSKC and DSKPP define means to establish and manage the underlying keying associations.▶ The specifications are developed by the OATH community and brought into IETF: – HOTP: An HMAC-Based OTP Algorithm (RFC 4226, 2005) – TOTP - Time-based One-time Password Algorithm (RFC 6238, 2011) – OCRA - OATH Challenge/Response Algorithms Specification (RFC 6287, 2011) – PSKC - Portable Symmetric Key Container (RFC 6030, 2010) – DSKPP - Dynamic Symmetric Key Provisioning Protocol (RFC 6063, 2010)▶ Familiar to: RFC 2289, vendor-proprietary solutionsMay 2012 30
  • 31. Security Infrastructure –OAuth Authorization Server▶ To decouple resource server tasks from OAuth-tasks, OAuth 2.0 introduces the authorization server as a distinguished entity with following endpoints: – Authorization endpoint: entitle 3rd-party clients, resource owner-facing – Token endpoint: acquire access tokens (initial, refresh), relying party-facing▶ OpenID Connect extends the OAuth authorization server abstraction by adding: – UserInfo endpoint: query identity data, relying party-facing – CheckID endpoint: query and validate ID token objects, relying party-facing – Refresh session endpoint: refresh ID token objects, relying party-facing – End session endpoint: terminate sessions at IdPs, relying party-facing▶ By extension (further token types, use cases, explicit system interfaces and network protocol), it may evolve towards a security infrastructure service: – It supports the underlying use cases (delegation use case in access management, federation use case in identity management) – But is not limited to them and presents a security infrastructure service nucleus – Kantara UMA is already going this direction▶ The specifications are developed by the IETF oauth working group: – The OAuth 2.0 Authorization Framework (Draft 2012)▶ Familiar to: WS-Trust STSMay 2012 31
  • 32. Security Token –JSON Web Token - JWT▶ JWT defines self-contained security tokens for space-constrained environments: – Uses JSON data structures (RFC 4627) to represent identity-related information about a subject for transfer from an asserting to a relying party. – Embody (name, value)-pairs – called claims - to express identity-related data: • Claim names: o Define some reserved claim names e.g. exp (expiration time) Support IANA-registered public claim names o o Allow private claim names • Claim values: JSON-defined data types esp. literal (string, number, Boolean) or complex (object, array) types – JWT may be signed (JSON Web Signature) and/or encrypted (JSON Web Encryption) – JWT supports the bearer model but does not yet support PoP▶ The specification is currently provided as individual submission to the IETF jose working group: – JSON Web Token (JWT) (Draft 2012)▶ Familiar to: SAML AssertionMay 2012 32
  • 33. Meta-Information Syntax –Level of Assurance - LoA▶ Level of assurance specifications allow asserting parties to express how authentication and identity creation was done: – They establish mutually understood levels along with applicable criteria: • LoA-1: Little or no confidence in the asserted identity e.g. self-asserted identity from OpenId IdP • LoA-2: Some confidence in the asserted identity e.g. third-party asserted identity from SAML IdP (bearer token, single factor initial authentication) • LoA-3: High confidence in the asserted identity e.g. third-party asserted identity from SAML IdP (bearer token, multi-factor initial authentication) • LoA-4: Very high confidence in the asserted identity e.g. third-party asserted identity from SAML IdP (PoP token, multi-factor initial authentication) – The qualification encompasses enrolment, credential management, and entity authentication phases▶ Specifications are developed by NIST, ITU-T | ISO/IEC, and Kantara: – NIST SP800-63 Electronic Authentication Guideline (2006) – ITU-T X.1254 | ISO/IEC 29115 – Entity authentication assurance framework (Draft 2012) – Kantara Identity Assurance Framework (2010)▶ Familiar to: -May 2012 33
  • 34. Security Syntax –JSON Web Signature - JWS▶ JSON Web Signature defines a compact digital signature format addressing space-constrained environments: – Uses JSON data structures to represent signed data of arbitrary type along with validation meta-data – Per JWS object, a single data object can be signed – Supports the enveloping of signed data (JWS object wraps signed data) but does not yet support enveloped and detached signed data – Allows to refer to validation keys by-reference (JSON Web Key URL, X.509 certificate path URL, identifier, thumbprint) or by-value (JSON Web Key object, X.509 certificate path) – Supports symmetric as well as asymmetric checksums e.g. • HMAC-SHA256 • RSA-SHA256 • ECDSA-SHA-256 (NIST P-256)▶ The specification is developed by the IETF jose working group: – JSON Web Signature (JWS) (Draft 2012)▶ Familiar to: XML Signature, PKCS#7/CMSMay 2012 34
  • 35. Security Syntax –JSON Web Key - JWK▶ JSON Web Key defines a compact public key representation format addressing space-constrained environments:  Uses JSON data structures to represent public keys (in plain form, not in form of public key certificates)▶ The specification is developed by the IETF jose working group: – JSON Web Key (JWK) (Draft 2012)▶ Familiar to: XML Signature (ds:KeyInfo portion)May 2012 35
  • 36. Security Syntax –JSON Web Encryption - JWE▶ JSON Web Encryption defines a compact encryption format addressing space- constrained environments: – Uses JSON data structures to represent encrypted data of arbitrary type along with decryption meta-data – Allows to refer to decryption keys by-reference (JSON Web Key URL, X.509 certificate path URL, identifier, thumbprint) or by-value (JSON Web Key object, X.509 certificate path) – Encrypts payload through an indirection (content/key encryption) – Can also integrate HMAC-based message authentication (first-encrypt-then- sign)▶ The specification is developed by the IETF jose working group: – JSON Web Encryption (JWE) (Draft 2012)▶ Familiar to: XML Encryption, PKCS#7/CMSMay 2012 36
  • 37. Security Syntax –JSON Web Algorithms - JWA▶ JSON Web Algorithm defines descriptors for cryptographic algorithms – For use with JSON Web Encryption and Signature▶ The specification is developed by the IETF jose working group: – JSON Web Algorithms (JWA) (Draft 2012)▶ Familiar to: n.a. (handled inline by XML and ASN.1-based security syntax specifications)May 2012 37