Return to draft-day-svrloc-signature-00-nr.txt CVS log | Up to [Pegasus] / pegasus / src / slp / slp_client / doc |
File: [Pegasus] / pegasus / src / slp / slp_client / doc / draft-day-svrloc-signature-00-nr.txt
(download)
Revision: 1.1, Wed Dec 17 18:05:31 2003 UTC (20 years, 6 months ago) by tony Branch: MAIN CVS Tags: pegasus25BeforeLicenseUpdate, local, TASK_PEP328_SOLARIS_NEVADA_PORT, TASK_PEP233_EmbeddedInstSupport-merge_out_trunk, TASK_BUG_5314_IPC_REFACTORING_ROOT, TASK_BUG_5314_IPC_REFACTORING_BRANCH, TASK_BUG_5314_IPC_REFACTORING-V1, TASK_BUG_5191_QUEUE_CONSOLIDATION_ROOT, TASK_BUG_5191_QUEUE_CONSOLIDATION_BRANCH, TASK-TASK-BUG4011_WinLocalConnect-branch-New-root, TASK-TASK-BUG4011_WinLocalConnect-branch-New-merged_out_to_branch, TASK-TASK-BUG4011_WinLocalConnect-branch-New-merged_out_from_trunk, TASK-TASK-BUG4011_WinLocalConnect-branch-New-merged_in_to_trunk, TASK-TASK-BUG4011_WinLocalConnect-branch-New-merged_in_from_branch, TASK-TASK-BUG4011_WinLocalConnect-branch-New-branch, TASK-PEP328_SOLARIS_NEVADA_PORT_v2-root, TASK-PEP328_SOLARIS_NEVADA_PORT_v2-branch, TASK-PEP328_SOLARIS_NEVADA_PORT-root, TASK-PEP328_SOLARIS_NEVADA_PORT-branch, TASK-PEP328_SOLARIS_IX86_CC_PORT-root, TASK-PEP328_SOLARIS_IX86_CC_PORT-branch-v2, TASK-PEP328_SOLARIS_IX86_CC_PORT-branch, TASK-PEP311_WSMan-root, TASK-PEP311_WSMan-branch, TASK-PEP305_VXWORKS-root, TASK-PEP305_VXWORKS-branch-pre-solaris-port, TASK-PEP305_VXWORKS-branch-post-solaris-port, TASK-PEP305_VXWORKS-branch-beta2, TASK-PEP305_VXWORKS-branch, TASK-PEP305_VXWORKS-2008-10-23, TASK-PEP291_IPV6-root, TASK-PEP291_IPV6-branch, TASK-PEP286_PRIVILEGE_SEPARATION-root, TASK-PEP286_PRIVILEGE_SEPARATION-branch, TASK-PEP274_dacim-root, TASK-PEP274_dacim-merged_out_to_branch, TASK-PEP274_dacim-merged_out_from_trunk, TASK-PEP274_dacim-merged_in_to_trunk, TASK-PEP274_dacim-merged_in_from_branch, TASK-PEP274_dacim-branch, TASK-PEP268_SSLClientCertificatePropagation-root, TASK-PEP268_SSLClientCertificatePropagation-merged_out_to_branch, TASK-PEP268_SSLClientCertificatePropagation-merged_out_from_trunk, TASK-PEP268_SSLClientCertificatePropagation-merged_in_to_trunk, TASK-PEP268_SSLClientCertificatePropagation-merged_in_from_branch, TASK-PEP268_SSLClientCertificatePropagation-branch, TASK-PEP267_SLPReregistrationSupport-root, TASK-PEP267_SLPReregistrationSupport-merging_out_to_branch, TASK-PEP267_SLPReregistrationSupport-merging_out_from_trunk, TASK-PEP267_SLPReregistrationSupport-merged_out_to_branch, TASK-PEP267_SLPReregistrationSupport-merged_out_from_trunk, TASK-PEP267_SLPReregistrationSupport-merged_in_to_trunk, TASK-PEP267_SLPReregistrationSupport-merged_in_from_branch, TASK-PEP267_SLPReregistrationSupport-branch, TASK-PEP250_RPMProvider-root, TASK-PEP250_RPMProvider-merged_out_to_branch, TASK-PEP250_RPMProvider-merged_out_from_trunk, TASK-PEP250_RPMProvider-merged_in_to_trunk, TASK-PEP250_RPMProvider-merged_in_from_branch, TASK-PEP250_RPMProvider-branch, TASK-PEP245_CimErrorInfrastructure-root, TASK-PEP245_CimErrorInfrastructure-merged_out_to_branch, TASK-PEP245_CimErrorInfrastructure-merged_out_from_trunk, TASK-PEP245_CimErrorInfrastructure-merged_in_to_trunk, TASK-PEP245_CimErrorInfrastructure-merged_in_from_branch, TASK-PEP245_CimErrorInfrastructure-branch, TASK-PEP241_OpenPegasusStressTests-root, TASK-PEP241_OpenPegasusStressTests-merged_out_to_branch, TASK-PEP241_OpenPegasusStressTests-merged_out_from_trunk, TASK-PEP241_OpenPegasusStressTests-merged_in_to_trunk, TASK-PEP241_OpenPegasusStressTests-merged_in_from_branch, TASK-PEP241_OpenPegasusStressTests-branch, TASK-Bugs5690_3913_RemoteCMPI-root, TASK-Bugs5690_3913_RemoteCMPI-merged_out_to_branch, TASK-Bugs5690_3913_RemoteCMPI-merged_out_from_trunk, TASK-Bugs5690_3913_RemoteCMPI-merged_in_to_trunk, TASK-Bugs5690_3913_RemoteCMPI-merged_in_from_branch, TASK-Bugs5690_3913_RemoteCMPI-branch, TASK-Bug2102_RCMPIWindows-root, TASK-Bug2102_RCMPIWindows-merged_out_to_branch, TASK-Bug2102_RCMPIWindows-merged_out_from_trunk, TASK-Bug2102_RCMPIWindows-merged_in_to_trunk, TASK-Bug2102_RCMPIWindows-merged_in_from_branch, TASK-Bug2102_RCMPIWindows-branch, TASK-Bug2102Final-root, TASK-Bug2102Final-merged_out_to_branch, TASK-Bug2102Final-merged_out_from_trunk, TASK-Bug2102Final-merged_in_to_trunk, TASK-Bug2102Final-merged_in_from_branch, TASK-Bug2102Final-branch, TASK-Bug2021_RemoteCMPIonWindows-root, TASK-Bug2021_RemoteCMPIonWindows-merged_out_to_branch, TASK-Bug2021_RemoteCMPIonWindows-merged_out_from_trunk, TASK-Bug2021_RemoteCMPIonWindows-merged_in_to_trunk, TASK-Bug2021_RemoteCMPIonWindows-merged_in_from_branch, TASK-Bug2021_RemoteCMPIonWindows-branch, TASK-Bug2021_RCMPIonWindows-root, TASK-Bug2021_RCMPIonWindows-merged_out_to_branch, TASK-Bug2021_RCMPIonWindows-merged_out_from_trunk, TASK-Bug2021_RCMPIonWindows-merged_in_to_trunk, TASK-Bug2021_RCMPIonWindows-merged_in_from_branch, TASK-Bug2021_RCMPIonWindows-branch, TASK-BUG7240-root, TASK-BUG7240-branch, TASK-BUG7146_SqlRepositoryPrototype-root, TASK-BUG7146_SqlRepositoryPrototype-merged_out_to_branch, TASK-BUG7146_SqlRepositoryPrototype-merged_out_from_trunk, TASK-BUG7146_SqlRepositoryPrototype-merged_in_to_trunk, TASK-BUG7146_SqlRepositoryPrototype-merged_in_from_branch, TASK-BUG7146_SqlRepositoryPrototype-branch, TASK-BUG4011_WinLocalConnect-root, TASK-BUG4011_WinLocalConnect-merged_out_to_branch, TASK-BUG4011_WinLocalConnect-merged_out_from_trunk, TASK-BUG4011_WinLocalConnect-merged_in_to_trunk, TASK-BUG4011_WinLocalConnect-merged_in_from_branch, TASK-BUG4011_WinLocalConnect-branch-New, TASK-BUG4011_WinLocalConnect-branch, STABLE, SLPPERFINST-root, SLPPERFINST-branch, RELEASE_2_9_0-FC, RELEASE_2_8_2-RC1, RELEASE_2_8_2, RELEASE_2_8_1-RC1, RELEASE_2_8_1, RELEASE_2_8_0_BETA, RELEASE_2_8_0-RC2, RELEASE_2_8_0-RC1, RELEASE_2_8_0-FC, RELEASE_2_8_0, RELEASE_2_8-root, RELEASE_2_8-branch, RELEASE_2_7_3-RC1, RELEASE_2_7_3, RELEASE_2_7_2-RC1, RELEASE_2_7_2, RELEASE_2_7_1-RC1, RELEASE_2_7_1, RELEASE_2_7_0-RC1, RELEASE_2_7_0-BETA, RELEASE_2_7_0, RELEASE_2_7-root, RELEASE_2_7-branch, RELEASE_2_6_3-RC2, RELEASE_2_6_3-RC1, RELEASE_2_6_3, RELEASE_2_6_2-RC1, RELEASE_2_6_2, RELEASE_2_6_1-RC1, RELEASE_2_6_1, RELEASE_2_6_0-RC1, RELEASE_2_6_0-FC, RELEASE_2_6_0, RELEASE_2_6-root, RELEASE_2_6-branch-clean, RELEASE_2_6-branch, RELEASE_2_5_5-RC2, RELEASE_2_5_5-RC1, RELEASE_2_5_5, RELEASE_2_5_4-RC2, RELEASE_2_5_4-RC1, RELEASE_2_5_4, RELEASE_2_5_3-RC1, RELEASE_2_5_3, RELEASE_2_5_2-RC1, RELEASE_2_5_2, RELEASE_2_5_1-RC1, RELEASE_2_5_1, RELEASE_2_5_0-RC1, RELEASE_2_5_0, RELEASE_2_5-root, RELEASE_2_5-branch, RELEASE_2_4_FC_CANDIDATE_1, RELEASE_2_4_3, RELEASE_2_4_2, RELEASE_2_4_1-BETA3, RELEASE_2_4_1-BETA2, RELEASE_2_4_1-BETA1, RELEASE_2_4_1, RELEASE_2_4_0-RC3, RELEASE_2_4_0-RC2, RELEASE_2_4_0, RELEASE_2_4-root, RELEASE_2_4-branch, RELEASE_2_3_2-testfreeze, RELEASE_2_3_2-root, RELEASE_2_3_2-releasesnapshot, RELEASE_2_3_2-branch-freeze, RELEASE_2_3_2-branch, PEP286_PRIVILEGE_SEPARATION_ROOT, PEP286_PRIVILEGE_SEPARATION_CODE_FREEZE, PEP286_PRIVILEGE_SEPARATION_BRANCH, PEP286_PRIVILEGE_SEPARATION_1, PEP244_ServerProfile-root, PEP244_ServerProfile-branch, PEP233_EmbeddedInstSupport-root, PEP233_EmbeddedInstSupport-branch, PEP217_PRE_BRANCH, PEP217_POST_BRANCH, PEP217_BRANCH, PEP214ROOT, PEP214BRANCH, PEP214-root, PEP214-branch, PEP213_SIZE_OPTIMIZATIONS, PEP-214B-root, PEGASUS_2_5_0_PerformanceDev-string-end, PEGASUS_2_5_0_PerformanceDev-rootlt, PEGASUS_2_5_0_PerformanceDev-root, PEGASUS_2_5_0_PerformanceDev-r2, PEGASUS_2_5_0_PerformanceDev-r1, PEGASUS_2_5_0_PerformanceDev-lit-end, PEGASUS_2_5_0_PerformanceDev-buffer-end, PEGASUS_2_5_0_PerformanceDev-branch, PEGASUS_2_5_0_PerformanceDev-AtomicInt-branch, PEG25_IBM_5_16_05, NPEGASUS_2_5_0_PerformanceDev-String-root, NNPEGASUS_2_5_0_PerformanceDev-String-branch, MONITOR_CONSOLIDATION_2_5_BRANCH, IBM_241_April1405, CQL_2_5_BRANCH, CHUNKTESTDONE_PEP140, BUG_4225_PERFORMANCE_VERSION_1_DONE Integrate slp_client using pegasus standard make environment |
\"----------------------------------------------------------------- .\" 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
No CVS admin address has been configured |
Powered by ViewCVS 0.9.2 |