| TOC |
|
To be effective, a framework for establishing trust between parties must be based on agreed protocols to exchange information on which trust decisions may be based. This in turn calls for broadly accepted standards. Obtaining the consensus needed for a technical specification to become a standard is very much easier if existing relevant standards work is used to the maximum extent possible. This note will survey and introduce some established and emerging Internet standards work (from IETF, W3C, OASIS, ISO, ITU) that may be relevant to deliberations about trust based architectures and decision making systems. It will touch on the following protocols: MIME, XML, RDF, HTTP, BEEP, SOAP, instant messaging protocols, XMLDSIG, XMLENC, X.509, XKMS, SAML, XACML.
This memo has been prepared for the first meeting of the Itrust Working Group, a research and technology transfer activity funded under the European Union's 5th Framework. The meeting is hosted by Strathclyde University, and takes place in Glasgow during 2nd to 4th September, 2002.
| TOC |
| TOC |
To be effective, a framework for establishing trust between parties must be based on agreed protocols to exchange information on which trust decisions may be based. This in turn calls for broadly accepted standards. Obtaining the consensus needed for a technical specification to become a standard is very much easier if existing relevant standards work is used to the maximum extent possible. This note will survey and introduce some established and emerging Internet standards work (from IETF, W3C and OASIS) that may be relevant to deliberations about trust based architectures and decision making systems.
The purpose of this paper is not to delve into great detail about these standards, or to present a definitive list of standards to be used, but to stimulate discussion about applicable existing standards work. Also, it is not intended to imply that the standards noted necessarily have a part to play in a trust modelling framework, rather that they represent existing technologies whose functions should not be duplicated by new designs, if possible.
The essence of Internet standards is to achieve interoperability and scalability for data communication services.
For interoperability, it is particularly important that communicating parties do not have to activate some kind of bilateral out-of-band agreement in order to start communicating with each other. This issue is particularly significant for establishing trust: if any form of bilateral already exists then some the biggest difficulties of establishing trust have already been solved. Both interoperability and scalability are served by keeping designs as simple as possible consistent with performing the required functions.
Scalability is further served by minimizing the dependence on a single authority, and restricting any such dependency to purely technical matters. Experience with PKI deployment (or non-deployment) shows that trying to force all users into a single operational model of trust management just does not work at Internet scale. Whatever the participants may wish for, there will be variations in national, corporate and personal policy that a scalable system must accommodate.
Successful Internet standards are generally made up from a number of simple interlocking pieces. This approach seems to permit common implementations of shared technical requirements, while allowing for local policy preferences. But we should not forget that interoperability requires that all of these interlocking pieces can work with each other.
This memo surveys existing standards work in the following areas. Protocols are distinguished from data formats:
Interoperability between trust handling components requires that they employ common protocols and data formats.
Section Generic data formats looks at generic data formats that are likely to be useful for a common trust framework.
Section Trust and security related data formats surveys data formats with particular relevance to security and/or trust management.
Section Generic protocols surveys general purpose protocols that are likely to be useful in a common trust framework.
Section Trust and security related protocols surveys protocols with particular relevance to security and/or trust management.
| TOC |
Formats have been selected for inclusion on the basis that I believe they are likely to play a fundamental role in any trust management deployment. In some cases, their use may be hidden by underlying protocol layers, and does not necessarily impact the trust framework design.
MIME[2] is an IETF standard format for encapsulating and labelling arbitrary application data for transfer using Internet protocols. It has been designed as an extension of the standard Internet mail format [1], and is very widely used, by Internet email [10][11], web access [8] and other Internet application protocols.
Several Internet security mechanisms assume that data is MIME-encapsulated.
XML[17] is a W3C format for encoding arbitrary data. It's design is an evolution of SGML/HTML markup for documents and hypertext, but is now finding widespread use for transferring application specific data across the Internet.
Much current standardization work in security and access control uses XML-based formats.
URIs[6] are an IETF standard for a uniform identifier and network address format. URIs were originally used to indicate the target of World Wide Web network hypertext links in a fashion independent of the network protocol used to access the referenced target. They are now also being used in many applications as general purpose idcentifiers, in a fashion similar to the use of OIDs in ISO protocols [30].
Being so widely used, and inherrently capable of identifying any concept, I think it is very likely that URIs will be used for identifying the principals, resources and other concepts in any large scale deployment of trust management.
RDF[19] is a W3C format for representing metadata and arbitrary information. It is based on an abstract graph model, for which an XML serialization is defined.
It is usually possible to use "home grown" XML for applications where RDF is applicable, but RDF offers the following distinguishing characteristics:
The power and value of using RDF in a trust modelling framework is the integration and sharing of information between applications. For an isolated application, there may be little practical value in using RDF, but when several applications need to exchange information, the common representation thus provided is most valuable. I liken this to the effect that Internet Protocol (IP) had on the deployment of communication services in allowing disparate systems to communicate with each other and enabling the development and deployment of new communication services. RDF fulfils a similar role with respect to information services.
| TOC |
S/MIME[9] is an IETF standard for singing and encrypting MIME content, and providing other related security services. Can be used to provide end-to-end security for arbitrary MIME content.
OpenPGP[7] is another IETF standard for singing and encrypting MIME content, and providing other related security services. Can be used to provide end-to-end security for arbitrary MIME content.
XMLDSIG[14] (also [21]) is a joint IETF/W3C standard for signing XML data.
Unlike S/MIME and OpenPGP, this exploits the internal structure of XML to provide for selective signing and canonicalization of equivalent representations, allowing a message containing signed XML content to be manipulated (within certain bounds) without invalidating the signature.
XMLENC[22] is a W3C standard for encrypting XML data.
X.509[29] is an ITU standard format for public key certificates.
PKIX[15] is an IETF standard profile of X.509 for Internet use.
SAML[27] is an OASIS standard format and protocol binding framework for conveying security assertions. A particular goal of SAML is support for single sign-on, a single user authentication being used to generate sufficient credentials to access resources in different domains.
XACML[28] is an OASIS specification for using XML to expressing policies for information access over the Internet.
| TOC |
HTTP[8] is the primary protocol used to fetch and update documents on the World Wide Web. This protocol is also being used for a range of other purposes which are not always clearly related to Web access -- see RFC3205[13] for discussion of some concerns about using HTTP in this way.
HTTP retrieves and delivers MIME-encapsulated data objects, with some small variations in the formatting details.
SMTP[10] is the main protocol used for delivering Internet mail. A major distinguishing feature of SMTP is its use of relays, which means that the sender and receiver of a message to not need to be similtaneously connected to the Internet.
There are also a few attempts to use SMTP for limited application-to-application data transfers, but SMTP is not especially well suited to this (but see instant messaging).
BEEP[12] is an application protocol framework rather than a single protocol. It can be used as a basis for new application protocols that have a commonly occurring set of characteristics, thus simplifying protocol design and allowing for code re-use.
SOAP[23] is a messaging framework for XML. It evolved from an earlier work for using XML to perform remote procedure calls (XML-RPC), but in its present form the various protocol elements have been separated so that its use is not limited to RPC.
The main part of the SOAP specification defines a message envelope structure that can be used to carry arbitrary message structures. These messages can be transferred using a variety of underlying protocols.
in SOAP version 1.2 [24][25], HTTP bindings are defined for two message exchange patterns, request-response (corresponding to RPC) and response only (corresponding to HTTP GET). For data that is not presented in an XML encoding, a data encoding scheme is defined.
Instant messaging and presence protocols (IMPP) combine the loosely connected delivery features of email with a framework that allows timely and deterministic performance where appropriate. The presence protocol elements provide for asynchronous notifications to be delivered, following a publish-and-subscribe model.
While the immediate use for instant messaging is for person-to-person text messaging, a number of groups are looking at using the infrastructure for efficient application-to-application messaging.
Currently, there are a number of proprietary IMPP offerings (ICQ, AOL, MSN, Yahoo). There are also (at least) three efforts aiming for some kind of standard status: SIMPLE (SIP based) http://www.ietf.org/html.charters/simple-charter.html, APEX [16] (based on the email architecture), and Jabber http://www.jabber.org/.
| TOC |
TLS[5] is a transport level protocol that applications can use to secure (authenticate and/or encrypt) connection based protocols. It provides a hop-by-hop security, which means that intermediate nodes must be trusted. (There are possibilities to tunnel HTTP through proxies, avoiding the need to trust the proxy intermediaries.)
The object security services described above (S/MIME, OpenPGP, XMLDSIG, etc.) can proviode end-to-end security services, which are regarded my many as being superior to channel-based security like TLS, which does not generally apply end-to-end. But, in practice, TLS and similar protocols have been easier to deploy in practice, and arguably provide better security on the basis that some deployed security is better than no deployed security.
SASL[4] is the Simple Authentication and Security Layer protocol framework. This is not a stand-alone protocol, but a framework that can be used by application protocols to negotiate and embed security services within an application protocol.
Like TLS, SASL is not generally used to provide end-to-end security, so intermediary systems must be trusted.
Secure shell can be used to provide channel security for protocols that do not have security designed in. Secure shell is primarily a secure terminal access service, but has been enhanced with tunnelling capabilities that allow an application connection on one machine to be securely connected to an application port on a remote machine. There is an IETF working group to standardize SSH http://www.ietf.org/html.charters/secsh-charter.html.
XKMS[26] is a W3C work in progress to provide key management services to XML applications. Part of the rationale for XKMS is to allow complicated and sensitive certificate processing to be separated from applications, providing a set of simple services that the applications need in order to get their job done in a secure fashion.
| TOC |
I adopt the following working definition of "trust":
The firm expectation that an entity will behave dependably and securely within a specified context.
The whole idea of trust management is intimately bound with security. Most security technologies convey trust in some way, though these alone cannot establish or create trust.
Most of the standards work conducted to data has focused on security mechanisms, and have left the establishment of trust as a "problem for the reader". The difficulty of establishing and describing trust underpins the failure to achieve meaningful large-scale deployment of a public key infrastructure: by simply focusing on the technology to transfer trusted assertions, much needed parts of the larger picture have been left unaddressed.
In focusing on the establishment of trust, I believe it is important that we do not forget that the mechanisms for conveying trust decisions must be reliable: the work that has gone into secure systems design, and the resulting designs and standards, are hightly relevant to our work in trust management. Hence the attention paid in this memo to data formats and protocols for data communication security.
| TOC |
| TOC |
| Graham Klyne | |
| Nine by Nine | |
| 14 Chambrai Close | |
| Appleford | |
| Abingdon, Oxon OX14 4NT | |
| UK | |
| EMail: | GK-Itrust@ninebynine.org |
| URI: | http://www.ninebynine.net/ |
| TOC |
[[[Remove this section on final publication]]]
- 00a 12-Aug-2002:
- Document initially created.