draft-day-svrloc-signature-00-nr.txt

Pegasus is an open-source implementationof the DMTF CIM and WBEM standards. It is designed to be por

\"-----------------------------------------------------------------
.\" Registers to store heading levels as variables
.\"-----------------------------------------------------------------
.nr head1 0 1
.nr head2 0 1
.nr head3 0 1 
.nr head4 0 1
.nr head5 0 1
.nr head6 0 1

.\"-----------------------------------------------------------------
.\" Return to header level 1, 2, etc. 
.\" resets the level registers and indent
.\"-----------------------------------------------------------------
.de RETURN_HDR_1
.nr head2 0 1
.nr head3 0 1 
.nr head4 0 1
.nr head5 0 1
.nr head6 0 1
.in 0 
\.HDR_1 \\$1 
..

.de RETURN_HDR_2
.nr head3 0 1 
.nr head4 0 1
.nr head5 0 1
.nr head6 0 1
.in 0 
\.HDR_2 \\$1
..
 
.de RETURN_HDR_3
.nr head4 0 1
.nr head5 0 1
.nr head6 0 1
.in 0 
\.HDR_3 \\$1
..

.de RETURN_HDR_4
.nr head5 0 1
.nr head6 0 1
.in 0 
\.HDR_4 \\$1
..

.de RETURN_HDR_5
.nr head6 0 1
.in 0 
\.HDR_5 \\$1
..

.\"-----------------------------------------------------------------
.\" Create a level 1, 2, etc,.  heading 
.\" resets indent, creates a TOC entry
.\" Parameter is the title of the heading
.\"-----------------------------------------------------------------
.de HDR_1
.sp 1
.in 0 
\\n+[head1]\\  \\$1
.XS
\\n[head1]\\  \\$1
.XE
.in 3
.. 


.de HDR_2
.sp 1
.in 0 
\\n[head1]\\.\\n+[head2]\\ \\$1
.XS
\\n[head1]\\.\\n[head2]\\ \\$1
.XE
.in 3
.. 

.de HDR_3
.sp 1
.in 0 
\\n[head1]\\.\\n[head2]\\.\\n+[head3]\\ \\$1
.XS
\\n[head1]\\.\\n[head2]\\.\\n[head3]\\ \\$1
.XE
.in 3
.. 

.de HDR_4
.sp 1
.in 0 
\\n[head1]\\.\\n[head2]\\.\\n[head3]\\.\\n+[head4]\\ \\$1
.XS
\\n[head1]\\.\\n[head2]\\.\\n[head3]\\.\\n[head4]\\ \\$1
.XE
.in 3
.. 

.de HDR_5
.sp 1
.in 0 
\\n[head1]\\.\\n[head2]\\.\\n[head3]\\.\\n[head4]\\.\\n+[head5]\\ \\$1
.XS
\\n[head1]\\.\\n[head2]\\.\\n[head3]\\.\\n[head4]\\.\\n[head5]\\ \\$1
.XE
.in 3
.. 

.de HDR_6
.sp 1
.in 0 
\\n[head1]\\.\\n[head2]\\.\\n[head3]\\.\\n[head4]\\.\\n[head5]\\.\\n+[head6]\\ \\$1
.XS
\\n[head1]\\.\\n[head2]\\.\\n[head3]\\.\\n[head4]\\.\\n[head5]\\.\\n[head6]\\ \\$1
.in 3
.XE
.. 

.\"-----------------------------------------------------------------
.\" END MACRO DEFINITIONS
.\"-----------------------------------------------------------------

.pl 10.5i
.po 0
.ll 7.2i
.lt 7.2i
.nr LL 7.2i
.nr LT 7.2i
.ds LH Internet Draft
.ds CH SLP Signature Extension
.ds RH April 2003 
.ds LF Day, McDonald
.ds CF Expires: \n(dy September 2003
.ds RF FORMFEED[Page %]
.hy 0
.ad l
.de NS
.ne 4
.ti 0
..

   
Internet Engineering Task Force                             Michael Day
INTERNET DRAFT                                                      IBM
                                                           Ira McDonald
[Target Category: Experimental]                              High North
\n(dy April 2003                                      Expires in Six Months

.ce 1000
Signature Extension for Service Location Protocol v2
draft-day-svrloc-signature-00.txt
.ce 0
.sp 5

.in 0
Status of This Memo
.in 3
This document is an Internet-Draft and is subject to
all provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups.  Note that
other groups may also distribute working documents as
Internet-Drafts.

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."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html

This document is an individual contribution to the Internet
Engineering Task Force (IETF). Comments should be submitted to the
[e-mail] mailing list.

Distribution of this memo is unlimited.
	
.bp
.HDR_1 Introduction 

The Service Location Protocol [rfc2608bis] provides a scalable
framework for the discovery and selection of network services. Using
this protocol, computers using the Internet need little or no static
configuration of network services for network based applications.

SLP recommends the use of IPSec Authentication Headers [AH] for
authenticating service information. It also recommends the use of
the IPSec Encapsulating Security Payload [ESP] for causing SLP
exchanges to be private.

An addition to [rfc2608bis], the internet-draft "Upgrading to TLS
Within Service Location Protocol" (work in progress) [TLS] also
specifies a method for upgrading TCP connections to be encrypted.

The security discussion in section 15 of [rfcs608bis] enumerates the
security implications of using SLP for the discovery and selection of
network services. IPSec SHOULD be used in the manner described
whenever possible. 

.KS
There are some situations where the use of IPSEC is not an option for
SLP. These include 

.nr PI 5 
.RS 
.nr step 1 1
.IP \n[step]. 3
SLP is being transported by a protocol stack other than IP. This point
includes the case where SLP is publishing information about a service
that is accessible only via non-IP media. 
.IP \n+[step]. 
The SLP agent is running on a platform for which IPSec
has not been implemented, such as an embedded system.
.IP \n+[step].
SLP is being used within an application model that does not have an
affinity with IPSec security associations, such as with a high-latency
store-and-forward protocol or a many-to-one fanout engine. 
.KE 
.RE
.in 3 

When using SLP in environments where IPSec AH is not avialable
it is still desirable to provide a means to authenticate SLP
messages. This document describes an optional SLP protocol extension
for the generation and verification of signatures of SLP messages. It
uses the Crytographic Message Syntax [CMS] as the signature format. 

.HDR_1 Applicability\ Statement
       
This extension SHOULD NOT be used with SLP when IPSec Authentication
Headers [AH] are available for use. IPSec Authentication Headers
SHOULD be used to authenticate SLP messages whenever possible, as
outlined in [rfc2608bis].

When there is an acceptable mechanism for managing public keys in
place and when IPSec Authentication Headers are not available for use,
the signature extension MAY be used to authenticate SLP
messages. 

This extension is based upon the Cryptographic Message Syntax
[CMS]. CMS requires distribution of key material to occur but does not
specify how keys should be distributed. CMS supports different Public
Key algorithms and the use of Public Key Certificates. There are many
ways to distribute Certificates and other key material, and [CMS]
states that "The recipient MAY obtain the correct public key for the
signer by any means." Further, [CMS] states:

.in 5
"[CMS] supports a wide variety of architectures for certificate-based
key management, such as the one defined by the PKIX working group. [PROFILE]."

.in 3
The selection and implementation of a public-key infrastructure is
beyond the scope of this document. 

Assuming private keys are secret, the signature extension can provide
assurance that SLP messages originate from the purported host and that
they have not been modified in transit to the receiving host.

.HDR_2 Use\ with\ DAs 

All SLP message are request-response tuples, even when using
multicast or broadcast. The signature extension works for direct
exchanges between two SLP agents. In such a case, the sender of an SLP
message signs that message and the receiver verifies the signature. 

When using DAs, SLP transactions can involve three SLP agents and two
request-response tuples. For example, an SA registers service
information with a DA. Later, a UA requests that service information
from the DA. 

In this case the UA and SA do not transact directly with each other
and, therefore, cannot derive mutual trust through the direct exchange
of signed messages. Instead, they communicate indirectly through the
DA. 

Through administration of a public key infrastructure associative
trust between the UA and SA may be achieved through the DA. For this
to be achievable, the UA, SA, and DA must be configured with the same
root certificate authority, and must also be configured to reject SLP
signature extensions signed by a public key outside of the root of
trust. When this is the case, a UA and SA can derive associative trust
indirectly through signed messages via the DA. 

.bp
.HDR_2 Use\ with\ SLP\ Messages

The signature extension MAY be used with any SLP message.

.RETURN_HDR_1 Signature\ Extension\ Format