An XML-Based Data Integrity Service Model for Web Intermediaries

1. An XML-Based Data Integrity Service Model for Web Intermediaries By Chi-Hung Chi and Yin Wu National University of Singapore Email: chich@comp.nus.edu.sg

2. Outline • Observation and Challenge • Related Work • Overview of DISM • Dataflow of DISM • DISM Elements • Manifest • Segment • Permission • Modification • Authorization and Validation • Caching • Conclusion

3. Observation • Popularity of proxy caching and pervasive computing • Trend and needs of selected service migration from servers and clients to network at the application levels • Performance • Cost effectiveness • Appropriateness • Result is intelligent network with web intermedaries – based on real-time content transformation on streaming web data

4. Basic Active Network Proxy Proxy Cache Content Server Web Surfer Transformer Content X-formed Content Active Proxy Cache

5. Challenges • Should real-time content transformation happen in the network proxy, data integrity will be critical to ensure the correctness and appropriateness of the delivered content: • Operations • Ownership • Delegation • Validation • Caching

6. Requirements of Web Data Integrity Model • Secure to ensure the correctness and appropriateness of delivered content • Open and support value-added network services • Lightweight • Comparable to transfer protocols (e.g. HTTP) • Support caching and reuse of data (with validation) Note that data integrity  security data transfer

7. Related Work • Security socket layer (SSL) • Not appropriate in the context of web intermediaries • Data integrity model [Orman 2001] • Fundamental requirements more than formal definition.

8. Overview of DISM (I) • An XML-based solution to address data integrity of web pages during their transfer • Compatible with HTTP protocols • Three main groups of functions • Object content deposition with unique attributes specified to support caching, validation, …, etc. • Modification policies and actions • Authorization and validation model • Use W3C digital signature standard

9. Overview of DISM (II) • A web page is divided into a set of “segments”, each of which possesses its own content, modification rights and modification record • The collection of segments is called “manifest” • “permission” specifies the modification rights and actions of segments • The security policy of DISM: • monotonic in the sense that the number of permissions decreases as messages moves away from the editors. • Owner has the privilege to give new permissions.

10. DISM Data Flow (I)

11. DISM Data Flow (II) • Note that: • A DISM processor is not obliged to execute the permission • It also has freedom to ignore its designated permission if it is either unable or unwilling to execute the permission • It can delegate the permission to other parties if the permission is “delegatable”

12. DISM Message Validation (I) • No explicit encryption of content so as to allow value-added networked services • Editor leaves modification record in the message for any party to validate incoming message • Modification records are secured by editor’s signature. • The modification record indicates when, how, and by whom the content is modified. It contains current modification, authorizing permission, digital signature, and previous modification records.

13. DISM Message Validation (II) • …(Cont’d) • Segments are independent of each other to allow separate validation. • If the validation fails, the receiving party has two options: • Discard the invalid message and make a reply of failure • Mark the invalid part and forward it to the next level • Open question: Should validation take place before modification?

14. Caching in DISM (I) • Allow fine-grain caching of content segment. • Content segments are relatively independent of each other: • Support invalidation of specific segments • Each segment has its own set of life time, storage, and cacheability attributes • DISM invalidation request is submitted by using the HTTP “POST” command and an invalidation form listing the IDs of the expired segments. • As the invalidation form flows all the way to the server, each proxy tries to invalidate the listed segments and pass the remaining one to the next proxy.

15. Caching in DISM (II)

16. Caching in DISM (III) • Note that invalidation of cached information for possible data reuse is still open: • Freshness • Appropriateness • Any rule-based scheme • Factors not understood by the server/proxy are ignored and the default result of invalidation with unknown factor is “content-changed”

17. DISM: Elements in DTD • Manifest – DISM message • Segment – Basic unit of operation • Segment-ID • Content • Conditional Elements • Permission – Content Manipulation • Conditions • Actions • Modification – Content change record • Index – Strict ordering of segments for validation

18. DISM: Manifest

19. DISM: Segment

20. DISM: Permission

21. DISM: Modification

22. DISM Details • Details referred to the paper …

23. Authorization and Validation • Content owner can express his intention, in terms of permission, on how a page content should be presented. • It allows the proxies to execute or delegate the server's permissions. • It allows any party to validate the page content with respect to the server's permissions. • Each modification made to the content must be unambiguously recorded and bound to the editor's identity by his signature. • Message can be validated without requesting the original server. • If the editor's signature is missing or the content and the signature do not match, the corresponding segment must be considered dubious.

24. Actions for Validation Failure • If the validation fails, the receiving party have two options: • Discard the invalid message and make a reply of failure (either HTTP 404 "page not available" or HTTP 500 "server error") • Mark the invalid part and forward it. Both the "segment" element and the "index" element have an attribute named "validity", whose default value is "valid". If the validation fails, this attribute can be set to "invalid", warning the following receivers. • The editor SHOULD not do further modification or delegation after finding the content to be invalid.

25. Conclusion • Data integrity for web intermediaries • Language support • Function support • More challenging aspects: • Protocol: Is HTTP suitable/enough? • Caching: Reuse of data? • Basic questions re-visited: • Homogeneous vs. heterogeneous attributes and headers for segments of the same object • Different meanings for validation due to multiple owners for the same object (Refer to our upcoming “Validation for Web Intermediaries” paper)

26. Q & A

27. Authorization • The server is the only one who has the privilege to make authorization. • Through authorization, the server specifies the policy on how the content should be presented by: • Dividing the content into segments. • Specifying the permissions for each modifiable segment. • Collecting all the segment-IDs to make an index element and attaching it to the end of the manifest. • Both the index and the permissions must to be signed.

28. Execution • The Execution here refers to the execution of the permissions. • A permission can be executed if the following conditions are satisfied: • The permission is valid • The parent segment of the permission is valid • The conditions of the permission evaluate to be true • The proxy is authorized to execute the permission • In the execution a proper editor must: • Perform the action specified by the permission • Remove the permission from the manifest • Update the modification record and sign it • Update the <DISM:index> element and sign it

29. Delegation • A permission can be delegated if the following conditions are satisfied: • The permission is valid • The parent segment of the permission is valid • The proxy is authorized by the permission • The permission is specified to be "delegatable“ • A proper editor must do the following things in the delegation: • Insert a new permission • Migrate the old permission into the source-permission element of the new permission.

30. Validation • A manifest is valid if all of the following conditions are satisfied: • All of its segments are valid • Checked by validating the permissions and the modification records • All of its segments are in the correct order • Checked by validating the index element

31. Validating a Permission • A permission element is valid if the following conditions are satisfied: • The source-permission, if any, is valid and it is delegatable. • The authorizer is either the publisher of the manifest or a member of the editors of the source-permission. • The signature is valid and it is provided by the authorizer.

32. Validating a Modification • A modification record is valid if the following conditions are satisfied: • The new-segment-ID refers to the parent segment correctly • The permission element is valid • The editor is one of the editors authorized by the permission • The modification performed is consistent with the permitted action. E.g. If the permitted action is "Remove", the content element must be empty. • If the editor is not the server himself, the old-segment-ID element and the previous-modification element must present. The old-segment-ID must match the new-segment-ID in the previous-modification element. • The previous-modification, if any, is valid • The signature is valid and it is provided by the editor.

33. Validating an Index • An index element is valid if the following conditions are satisfied: • There is a one-to-one mapping between the segments in the manifest and the segment-IDs in the index. • The segment-IDs and their matching segments are in the same order. • The signature in the index element is valid and it is provided by one of the authorized editors.