Return to draft-day-svrloc-signature-00-nr.txt CVS log

Up to [Pegasus] / pegasus_unsupported / slp_client / doc

BUG#: 4730
TITLE: move slp_client out of Pegasus to Pegasus_Unspported

DESCRIPTION: Commit the entire tree to pegasus_unsupported

\"-----------------------------------------------------------------
.\" 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
srvloc@srvloc.org 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

The Signature Extension comprises an envelope for a Cryptographic
Message Syntax signed-data content type. (See section 5.1 of [CMS].)

.KS
.HDR_2 Signature\ Extension\ Fields

The Signature Extension has the following format: 
.DS L 
   0             1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Extension ID = 0x000?        |Next Ext. Offset (must be zero)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Offset, contd.|               CMS signed-data                 \\
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.DE
.KE 
.HDR_3 CMS\ signed-data\ Field

The CMS signed-data field contains the signature of the SLP message
and accompanying data. The format for the signed-data field is
outlined in section 5.1 of [CMS]. It is a BER-encoded [X.209-88]
buffer that may include at least the following information:

.nr PI 5 
.RS 
.nr step 1 1
.IP \n[step]. 3
Version of the CMS used to sign the message data. 
.IP \n+[step]. 
Algorithms used to generate and sign the message digest. 
.IP \n+[step].
Signed content, which includes a digest of the message data. 
.IP \n+[step].	
Optional Signer information, which may include Public-Key
Certificates. Signer attributes are subject to additional encoding
rules. 
.RE
.in 3 

The list above is generalized. For example, if the signed-data field
contains variable-length attribute data that data must use special
additional rules. See [CMS] for precise details.
.bp
.HDR_3 Size\ of\ signed-data\ Field

There is a paradox involving the size of the signed-data field and the
generation of the signed message digest. 

The SLP header MUST be included in the input for the message digest
contained in the signed-data field. Because the SLP Header includes a
length field, the length of the message including the signature
extension must be part of the input into the message digest contained
in the signature extension.

The message digest and the signature of the message digest are 
fixed-length fields and their length is known prior to generating the
signed digest. This makes it straightforward to calculate the length
of the SLP message, initialize the length field in the SLP header, and
then generate the signed message digest. 

.HDR_2 Contents\ of\ signed-data\ Field

The CMS provides considerable flexibility when generating signed-data
content. For example, it allows multiple signers and multiple
signatures. It also allows a variable number and type of signer
attributes including certificates.

To be consistent with the goals of SLP UAs and SAs SHOULD keep the
signed-data field as simple as possible when generating signature
extensions. A simple signed-data field with only a message digest, a
signature of the message digest, and a subject key identifier makes a
prior calculation of the signed-data length simple and ensures that
generating and verifying signatures of SLP messages requires the
smallest possible overhead.

A signed-data field that contains only a signed message digest and a
subject key identifier can fit easily within the datagram MTU of most
network environments and does not represent an unusual field size relative to
other SLP fields. However, embellishing the signed-data with
additional variable length attributes may quickly cause the SLP
message to exceed the datagram MTU. 

.HDR_2 Omission\ of\ eContent

The CMS referrs to the data being signed for authentication as
"eContent." In this case, the eContent is an SLP Message minus the
signature extension. 

The CMS allows signed content to be either encapsulated within a
signed-data "envelope" or "external." The signature extension requires
the eContent to be "external."
.KS
To quote from section 5.2 of [CMS]: 

.in 5
The optional omission of the eContent within the
EncapsulatedContentInfo field makes it possible to construct
"external signatures."  In the case of external signatures, the
content being signed is absent from the EncapsulatedContentInfo value
included in the signed-data content type.  If the eContent value
within EncapsulatedContentInfo is absent, then the signatureValue is
calculated and the eContentType is assigned as though the eContent
value was present.
.KE
.in 3

In other words, the signed-data field will always contain a signed
digest of the SLP message but not the SLP message itself. 

.RETURN_HDR_1 Use\ of\ the\ Signature\ Extension

Subject to the applicability guidelines in section 2 above, the
Signature extension can provide additional security to SLP by
authenticating the content SLP messages, including other SLP
extensions. It cannot provide privacy and it cannot authenticate the
origin of IP messages. IPSec [AH] is required to authenticate IP headers.

.HDR_2 Input\ to\ signed-data\ Field

When generating a signature extension for an SLP message, the
following data MUST be used as input to the message digest:

.KS
.nr PI 5 
.RS 
.nr step 1 1
.IP \n[step]. 3
SLP Header and message.
.IP \n+[step]. 
Any SLP extension up to but not including the signature extension.
.IP \n+[step].
The Signature extension MUST be the last extension present in an SLP message.
.KE
.RE
.in 3
.KS
.HDR_3 Calculating\ the\ Length\ of\ a\ Signed\ SLP\ Message

The following steps should be used to calculate the length of an SLP
message that includes the signature extension. 

.nr PI 5 
.RS 
.nr step 1 1
.IP \n[step]. 3
Determine the length of the signature extension. The signature
extension will always be 6 bytes larger than the size of the CMS
signed-data field. If the signed-data field will contain any variable
length data such as signer attributes it will be necessary to encode
the signed-data field using a dummy message digest and signature to
obtain its length.
.IP \n+[step]. 
Determine the length of the SLP message, including the length of the
signature extension and all preceeding extensions. 
.IP \n+[step].
Initialize the SLP Header with the length of the message. 
.RE
.in 3
.KE

.RETURN_HDR_2 Signature\ Generation\ Process

The details of generating signatures for a CMS signed-data field are
contained in [CMS] sections 5.4 and 5.5. The following is an overview
for using CMS signed-data in the SLP signature extension. The details
for performing the individual steps are covered in [CMS].

.KS
.nr PI 5
.RS
.nr step 1 1
.IP \n[step]. 3
Generate a message digest of the SLP message beginning with the first
byte of the SLP Header up to and including the last byte of the
message and extensions not including the signature extension. Note that if CMS signed
attributes are to be included in the signed-data field they too must
be input to the message digest. See [CMS] for details. 
.IP \n+[step].
Generate a signature of the digest from step 1. The input to the
signature is the digest and the signer's private key. 
.RE
.KE
.in 3
.KS
.HDR_2 Signature\ Verification\ Process

The details of verifying signatures for a CMS signed-data field are
contained in [CMS] section 5.6. The following is an overview for
verifying signatures in CMS signed-data fields within an SLP signature
extension.

.nr PI 5
.RS
.nr step 1 1
.IP \n[step]. 3
Generate a message digest exactly as in step [1] in section 4.2
above. 
.IP \n+[step]. 
The signer's public key must be obtained separately. 
.IP \n+[step]. 
The input to the signature verification step is the
digest generated in step 1 and the signers public key. The details
depend upon the exact signature algorithm employed but generally include
encrypting the locally generated digest with the signers
public key and comparing the result to the signature contained in the
message. 
.RE
.KE
.in 3

.HDR_1 Acknowledgements

James Kempf was instrumental in the development of this document.
Erik Guttman contributed the basic theory of using
digital signatures with SLP and offered valuable insights 
during the preparation of this document. 
. 
.HDR_1 References

.IP [rfc2608bis] 3
Guttman, E., Kempf, J., Service Location Protocol, Version 2 (work in
progress). draft-guttman-svrloc-rfc2608bis-03.txt, August 2002.

.IP [TLS] 3 
McDonald, Ira, Kempf, J., Day, M., "Upgrading to TLS With
Service Location Protocol", draft-mcdonald-svrloc-tls-00.txt (work in
progress).

.IP [AH] 3
Kent, S., and Atkinson, R., "IP Authentication Header," RFC
2402, November, 1998.
.IP [ESP] 3 
Kent, S., and Atkinson, R., "IP Encapsulating Security Payload
(ESP)," RFC 2406, November, 1998.
.IP [CMS] 3
Housely, R., "Cryptographic Message Syntax", RFC 3369, August, 2002.

.IP [PROFILE] 3
Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
X.509 Public Key Infrastructure: Certificate and CRL
rofile", RFC 3280, April 2002.
.IP [X.209-88] 3 
CCITT.  Recommendation X.209: Specification of Basic
Encoding Rules for Abstract Syntax Notation One (ASN.1).
1988.

.KS
.HDR_1 Author's\ Contact\ Information

Michael Day
IBM
3039 Cornwallis Road
Research Triangle Park, NC 27709
USA
Phone:  +1 919 543-4283
Email:  mdday@us.ibm.com

Ira McDonald
High North Inc
221 Ridge Ave
Grand Marais, MI 49839
USA
Phone: +1 906 494-2434
Email: imcdonald@sharplabs.com
.KE

.HDR_1 Full\ Copyright\ Statement

Copyright (C) The Internet Society (2000-2002).  All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works.  However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights defined
in the Internet Standards process must be followed, or as required to
translate it into languages other than English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."


.TC