Hewlett Packard Position Paper to the Worldwide Web Consortium Workshop on Web Services, April 11th and 12th

Hewlett Packard Position Paper to the Worldwide Web Consortium Workshop on Web Services, April 11^th and 12^th.

Author: Mike Jerbic, Hewlett Packard Co. email: [email protected]

Abstract:

As XML document exchange models become the de facto standard for users and programs to interoperate with web services across multiple security boundaries, end to end security becomes either meaningless or at best extremely difficult. Today's XML security "solutions" center around document encryption and signature: that is securing the confidentiality and integrity of the XML document itself. Missing from the solution suite is an interoperable standard to authorize access to services and a framework for accountability should one or more components of a service invocation fail to perform. The W3C should initiate an activity to create standards for defining, discovering, and exchanging authorization and accountability information within XML document conversations.

Problem Statement

HP has taken a position that XML document oriented conversations are appropriate and necessary to exchange information needed to discover, exchange necessary information, invoke, and receive electronic services over the Web. For XML conversations to become practical for the exchange of personal information, service invocation authorization, and service participant accountability, security must be designed into the conversation framework from the beginning.

Security services in use today do not satisfactorily address the needs of an open, web-oriented document exchange model for electronic service delivery. They are deficient today in these ways:

Security services are single domain oriented. E-services by design cross multiple domains. Examples include service composition across enterprises and the overall Business to Business electronic commerce problem. Even though PKIs (such as Verisign) appear to span security domains, they by virtue of being a "trusted third party," simply establish their own domain. Service providers and consumers must be able to establish a security context independent of so called trusted third parties.

Security systems require unnecessary information, the exposure of which is a global privacy, public safety, and security issue. Many times names, contact information, and other non-essential personal information is required to support legacy identity oriented security services. Adversaries misuse this information routinely. A global e-services infrastructure must allow for communication of privacy policy, the sharing of sensitive information, and recourse in the event privacy agreements are not kept. Some specific industries that are facing critical privacy problems yet also have the business requirement to exchange private information over the web in the conduct of their e-services are:

United States Health Care delivery (HIPPA regulation requirements).

United States multinational enterprises who must comply with the European Union Privacy Directive for the protection and use of European citizen information

Banking and Financial Services transactions

B2B and B2C service invocation ant payment

And many others…

Privacy and Security expectations must be part of the agreement [XML conversation] between service providers and service consumers. They cannot be ambiguous. XML conversations should have the flexibility of being private conversations.

Security systems do not scale well and may actually prevent service providers from entering markets. Security systems often do not scale in

Cost. Cost can be measured in several ways including legacy system integration or porting costs and the cost of ownership of central security servers or services.

Time. Security servers that map names to authorizations, for example, may require several hours up to days to vet new entries or to make permission or role changes granting authorizations to new services. Open, web based dynamic service providers require much faster, easier to change authorization systems. Real time manageability of security databases is a significant impediment to the dynamic advertising, discovery, and invocation of e-services.

Solution Requirements

Overall HP’s position is that XML documents must be able to include security context information that is discoverable, invocable, and interoperable. The solution needs to include:

Authorization. Computers do not need identities to perform requested services. Computers need authorizations. Authorizations should be embeddable or attachable to XML service requests. Authorizations range from simple payment (credit card number, digital cash...) to a certified, tamper resistant authorization message originating from an authorization authority the service recognizes.

Accountability. While computers only need authorizations, people need methods of determining accountability. Usually this is achieved through an access control list, which maps authorizations to an identity and an audit trail of activity. Other forms of accountability information are possible and should be explored.

Manageability. Multiple methods of authorization management must be supported. Three primary ones are:

Mapping names (identities) to authorizations. This is one of the most common forms of managing Service access to named individuals. Also knows as an Access Control List, mapping names to authorizations works well in small communities where identities are commonly known and used. This method does not scale well for large communities where name collisions can occur. An example is below:

Authorization Access Control list example for three identities.

Name	Service 1	Service 2	Service 3	Service 4 …	Service n
Mike	Yes	Yes	No	Yes	No
Terry	No	No	Yes	No	No
Eliot	Yes	Yes	Yes	Yes	Yes

Mapping names to roles, mapping roles to authorizations. An extension of the access control list is the creation of roles and privileges. Individual identities are mapped to roles, which in turn are mapped to specific authorizations. This scheme is somewhat more manageable for services that have a large client base (large number of names) or a distributed client base, where individual authorization is delegated. An example is below.

Authorization Access Control list example for three roles.

Role	Service	Service 2 Add User	Service 3 Bill User	Service 4 Credit	Service n
Subscriber	Yes	No	No	No	No
Admin	No	Yes	No	No	No
Back Office	No	No	Yes	Yes	No

Identity to Role Map

Identity	Subscriber	Admin	Back Office
Ted	Yes	No	No
Mike	No	Yes	No
Terry	No	No	Yes

Direct Authorization from the service provider. There are times when a determining authorization does not require checking a map of identity to authorization, as in the two examples described above. A service can simply grant access to an entity. This approach is best documented in the Simple Public Key Infrastructure (SPKI). In this system a service requestor is given an authorization to use the service by the service. When a service is invoked, the requestor presents a tamper resistant message authorizing the access to the service provider. No external authorization database check is required, since the authorization verifier has all the information required in the service invocation request. Direct authorizations may be delegable.

End to End Security. Service invocations and responses should be able to be confidential (encrypted) between the requestor and the service provider, without relying upon any intermediary third party such as a web server, portal, etc. Applications do exist where intermediaries may need to examine the traffic flow between service provider and consumer, and the security architecture should be able to support this.

Support of existing security mechanisms, protection of IT investment already in place. Security contexts need to have the flexibility of using legacy security infrastructure components such as X.509 identity certificates, S2ML, SSL, and integration with web browser security.

Discoverability. XML conversations need to support the exchange of security context information, and the requirements to access a service must be discoverable by the service requestor. A conversation infrastructure must be developed that includes security.

Scalability. The solution must support the service issuing its own authorization to a client without the need of an additional trusted party (such as a CA). Certificate Authority or Authorization Authority oriented solutions such as S2ML, SSL should be supportable as well for those service providers who want/need to leverage them.

Privacy. A method for interoperable exchange of privacy intentions is strongly desired. (Leverage / extend P3P?)

Tamper Resistance. The security architecture must provide for tamper resistance (most likely through digital signatures, XML DSIG?).

Non-Repudiation. Tamper resistance, which is technically feasible, must not be confused with non-repudiation, which is not. Digital signature technology can present some evidence of the signer’s intent, but non repudiation and the legal trustworthyness of exchanged documents must be governed not only by available technology, but also by law and contractual agreements.

Relationship to Other Standards

To address the requirements above, many already proven security standards must be considered and supported in the proposed new standard where they add value. While not intended to be an exhaustive list of standards to consider, the following serves as a starting point. It is important to note that the W3C already has experience in developing and recommending security solutions, and several of the standards have origins in W3C activities.

SSL secures a web browser to a web server. In the case of a portal of many services, confidentiality offered by SSL ends, with the client relying on the web server to end service security outside of the client’s control. SSL is not end to end in a distributed service world.

S2ML provides an authorization authority model that must be queried every time an authorization is required. S2ML is a standard in process at the OASIS standards organization.

XML Encryption provides confidentiality of an XML document, but it does not provide authorization information in a standard, interoperable way.

X.509 PKI – OK if the service provider can use name to authorization maps.

SPKI – OK if the service provider can’t use name to authorization maps.

Session Layer Security (SLS) – While not strictly a standard, HP has invested uniquely in a distributed authorization system to secure end to end Java applications. The security mechanism of HP’s E-Speak, SLS could be extended to XML. HP awaits the opportunity to work with the W3C to propose and extend this technology.

P3P – A description of a site’s privacy policy that can be downloaded and automatically compared to the user’s preferences.

XML DSIG – Provides digital signatures to XML documents. This functionality should be considered for inclusion as part of the XML security standard to support tamper resistance.