Sign What I'm Given (SWIG)
draft-farrell-pkng-swig-00

Abstract

Current Internet protocols tend to be based on either X.509 based PKI, or Kerberos. Both have limitations and age-related issues. In this draft, we outline a possible approach to providing similar, and additional, functionality based on an abstract device that always signs whatever its given, and that may additionally annotate or modify its input in order to fulfill the security needs of other protocols. This draft describes a SWIG service and how it can be used to conduct research into a number of important problems in Internet trust and identity management today.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

This Internet-Draft will expire on May 12, 2011.

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1.  Introduction
2.  SWIG Service Overview
3.  Use Cases
    3.1.  X.509-like Infrastructure
    3.2.  Application Layer Signing
    3.3.  Privacy Enhancing SWIGs
    3.4.  SAML Metadata Publisher
4.  SWIG Protocol
    4.1.  REST
        4.1.1.  SWIG HTTP Headers
5.  SWIG Standard Transformations
    5.1.  Capabilities
6.  IANA Considerations
7.  Security Considerations
8.  Normative References
§  Authors' Addresses

1.  Introduction

The Internet of today is a low-trust environment. The IRTF has identified a need to support research in this area. This draft attempts to describe a new protocol that is intended as a tool for experimentation and research in this field. While some current protocols (eg X.509 or kerberos) could be adopted to provide similar capabilities as SWIG, here we present a clean-slate approach to some of those problems.

Current protocols and solutions in this space often focuses on the credentials used to perform basic functions (eg signing or encryptions). The operation of signing and returning a signed representation of an object is at the heart of many protocols. SWIG attemts to bring together experience from (arguably) successful security protocols while refocusing on the signing operation rather than on key and credentials formats. The authors hope that this will inspire research into a few problems that we believe are important to the future of the Internet:

• How can we build a trust-model for the Internet that takes multiple overlapping rings-of-trust into account?
• How can applications become involved with and informed about trust-related decisions made by lower layers?
• Internet networking today is driven by the process managing peering relationships in combination with the applicationof local policy. Is there a way to build a trust infrastructure for the Internet that mimics this model?
• How can privacy-protection be supported by default, rather than as an add-on to protocols?

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

2.  SWIG Service Overview

The reader will undoubtedly notice that the SWIG model is conceptually similar to a lot of protocols that have been proposed, implemented and even in some cases widely deployed. That is entierly reasonable and indeed is an important aspect of SWIG: it does not fundamentally break the model for signing that is assumed by applications, but attempts to enhance those models.

Furthermore the authors hope that by providing a simple extensible architecture it will be easier in the future for sites and individuals to consolidate signing operations to use a smaller set of well-managed keys. In a way SWIG can be considered a very simple protocol-version of such ABIs as PKCS#11 or CSP.

A SWIG is an abstract service endpoint that observes a set of simple semantics. An instance of a SWIG service MUST sign what it is given, so the basic mode of interaction is that a client sends some data, and receives in return a signed representation of that data signed by the SWIG instance private key.

The response MAY include additional data or MAY include a transformed version (e.g. encrypted) of the request data. How a given instance handles this is specific to the instance however it is expected that implementations of SWIG allow for easy deployment of new transformations through some form of plugin architecture.

It is important to understand that most common instances of SWIG will not sign a 1-1 representation of the input request. Instead a SWIG instance will probably sign a representation of the request, eg by resolving the request as an identifier referencing some internal datastore.

Every SWIG instance MUST respond to certain specific requests, e.g. to provide its public key, or identifiers for the transformations it supports on input data.

If a requestor wishes a SWIG service to apply a specific transform to its input data, then it identifies that transform in its request, using an identifier, that can be retrieved as described in the previous paragraph. Specific transforms and their identifiers SHOULD be defined in open specifications.

3.  Use Cases

This section explains how various use-cases can be suppored via SWIG.

3.1.  X.509-like Infrastructure

An X.509-like infrastructure could be built from a set of SWIG instances by having SWIG instances issue responses that are simlar to (or contain) public key certificates. Chains of certificate-like things can be built in the same manner, as can OCSP-like responders, and LDAP-like schemes for finding public keys. In ways, SWIG could resemble XKMS, in how it maps to X.509 based PKI.

3.2.  Application Layer Signing

If a message source requires an application-layer signature that can be verified by a relying party, then it can send the application layer message to a SWIG instance, and the SWIG instance's signature can be directly used in the application layer protocol.

3.3.  Privacy Enhancing SWIGs

A SWIG instance could support a transform that enhances privacy, for example, if personally identifying input data is encrypted by the SWIG, using a key known only to the SWIG, and the relying party has to request that from the SWIG (if necessary, for application purposes). The SWIG instance could also provide the RP with a "fuzzed" version of the identiying information, for example, only identifying the country of the original requestor.

3.4.  SAML Metadata Publisher

A SAML Metadata aggregator/publisher can be described as a SWIG instance that accepts requests that contain as input a set of entityID strings and returns a signed <EntityDescriptors/> element containing the corresponding set of metadata as known by the SWIG instance.

4.  SWIG Protocol

There may well turn out to be a need for multiple bindings of the SWIG protocol. This section describes a very simple RESTful HTTP-based approach:

4.1.  REST

A SWIG endpoint is identified by a URI. The URI may contain a public identifier representing the public key used in signing responses (eg a key hash). A SWIG endpoint is an HTTP server that understands the SWIG headers.

A SWIG request is an HTTP request (POST or GET) that contains at least the SWIG-Version header and optionally the SWIG-Transform header. Each SWIG endpoint MUST support the set of standard transformations listed in the following section. A special case is the Capabilities transform: a SWIG endpoint MUST treat the absense of a SWIG-Transform header as if the SWIG-Transform contained only the 'capabilities' string.

A SWIG response is an HTTP response that contains at least the SWIG-Version and optionally (if the 'capabilities' transform was invoked) the SWIG-Transform header. The response will also include a signed representation of the requested data which will be communicated in the HTTP response body.

4.1.1.  SWIG HTTP Headers

SWIG-Transform: each value of this multivalued header identifies a transform that is to be applied in order to produce the result that the SWIG instance will sign and return in the response. This header is also used to return the set of supported transforms for the 'capabilities' transform. TODO: figure out if we need mime-types and/or mime-type options for this.

SWIG-Version: a version identifying the version of the SWIG protocol. This MUST be the literal string "1.0" for this version of the SWIG protocol.

5.  SWIG Standard Transformations

Transformations are identified using strings that are compared as case-insensitive UTF-8 strings.

5.1.  Capabilities

The 'cababilities' transform MUST cause the SWIG endpoint to return a response containing the signer public key (TBD: figure out how to determine which representation to return to the requestor) along with a list of supported transforms.

6.  IANA Considerations

This memo includes no request to IANA so far. But if it doesn't die, we'll want a port, maybe an SRV name and a registry for transform identifiers.

7.  Security Considerations

There will be a bunch, no doubt.

8. Normative References

Authors' Addresses