Internet DRAFT - draft-farrell-pkng-swig
draft-farrell-pkng-swig
Internet Research Task Force S. Farrell
Internet-Draft Trinity College Dublin
Intended status: Experimental L. Johansson
Expires: May 12, 2011 SUNET/NORDUnet
November 8, 2010
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
Farrell & Johansson Expires May 12, 2011 [Page 1]
Internet-Draft PKNG SWIG November 2010
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. SWIG Service Overview . . . . . . . . . . . . . . . . . . . . . 3
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. X.509-like Infrastructure . . . . . . . . . . . . . . . . . 4
3.2. Application Layer Signing . . . . . . . . . . . . . . . . . 5
3.3. Privacy Enhancing SWIGs . . . . . . . . . . . . . . . . . . 5
3.4. SAML Metadata Publisher . . . . . . . . . . . . . . . . . . 5
4. SWIG Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. REST . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1.1. SWIG HTTP Headers . . . . . . . . . . . . . . . . . . . 6
5. SWIG Standard Transformations . . . . . . . . . . . . . . . . . 6
5.1. Capabilities . . . . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
8. Normative References . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Farrell & Johansson Expires May 12, 2011 [Page 2]
Internet-Draft PKNG SWIG November 2010
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:
o How can we build a trust-model for the Internet that takes
multiple overlapping rings-of-trust into account?
o How can applications become involved with and informed about
trust-related decisions made by lower layers?
o 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?
o 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 [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.
Farrell & Johansson Expires May 12, 2011 [Page 3]
Internet-Draft PKNG SWIG November 2010
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.
Farrell & Johansson Expires May 12, 2011 [Page 4]
Internet-Draft PKNG SWIG November 2010
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-
Farrell & Johansson Expires May 12, 2011 [Page 5]
Internet-Draft PKNG SWIG November 2010
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
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Farrell & Johansson Expires May 12, 2011 [Page 6]
Internet-Draft PKNG SWIG November 2010
Authors' Addresses
Stephen Farrell
Trinity College Dublin
Trinity College
Dublin, 2
Ireland
Phone: +353-1-896-2354
Email: stephen.farrell@cs.tcd.ie
Leif Johansson
SUNET/NORDUnet
Tulegatan 11
Stockholm,
Sweden
Phone: +46703419886
Fax:
Email: leifj@sunet.se
URI:
Farrell & Johansson Expires May 12, 2011 [Page 7]
