One document matched: draft-petithuguenin-p2psip-reload-bis-00.xml

<?xml version="1.0" encoding="US-ASCII"?>
<?rfc compact="yes" ?>

<?rfc strict="no" ?>

<?rfc symrefs="yes" ?>

<?rfc toc="yes" ?>

<rfc category="std" docName="draft-petithuguenin-p2psip-reload-bis-00" ipr="noDerivativesTrust200902">
	<front>
		<title abbrev="RELOAD Bis">Proposed Improvements for REsource LOcation And Discovery (RELOAD)</title>

		<author fullname="Marc Petit-Huguenin" initials="M." surname="Petit-Huguenin">
			<organization>Stonyfish</organization>

			<address>
				<email>marc@stonyfish.com</email>
			</address>
		</author>

		<date day="21" month="June" year="2011"/>
		<area>RAI</area>
		<workgroup>P2PSIP</workgroup>

		<abstract>
			<t>
				This document proposes some improvements for <xref target="RELOAD"/>.
			</t>
		</abstract>
	</front>

	<middle>
		<section title="Introduction">
			<t>
				This document presents some extensions to RELOAD.
				The RELOAD authors are free to take whatever they want in this document.
				Anything else will be either proposed as separate extensions or in reload-bis after RELOAD is published as an RFC.
			</t>
		</section>

		<section title="Terminology">
			<t>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 <xref target="RFC2119"/>.</t>
		</section>

		<section title="Client connected to bootstrap node">
			<t>Section 3.2.1 of <xref target="RELOAD"/> describes how a client can connect to an overlay, either to its responsible peer or to an arbitrary peer, but does not describes the case where the client just wants to connect to a bootstrap node with a certificate containing multiple Node-IDs.</t>

			<t>This documents permits this, by having the client immediately sending a Ping with a wildcard Node-ID, and the bootstrap node waiting for receiving the Ping if the (D)TLS connection contains a remote certificate with multiple Node-IDs.</t>
		</section>

		<section title="Service Name and Path">
			<t>Section 10.2 of <xref target="RELOAD"/> uses a Service Name of "p2psip-enroll" and a path of "/.well-known/p2psip-enroll".</t>

			<t>RELOAD is now a generic P2P protocol, no longer tied to SIP so this document defines the Service Name "p2p-enroll" as an alias for "p2psip-enroll" and "/.well-known/p2p-enroll" as an alias for "/.well-known/p2psip-enroll".</t>
		</section>

		<section title="Multiple Node-IDs for self-signed certificates">
			<t>Section 10.3.1 does not define an algorithm to create self-signed certificates that contain multiple Node-IDs.</t>

			<t>This document permits to create self-signed certificates by prepending the index (from 1 to the number of Node-IDs needed) as a 4 bytes big endian integer to the public key of the user before applying the digest.</t>
		</section>

		<section title="Re-sign certificates">
			<t>Section 10.5 explains that the enrollment server must return certificates that contain Node-IDs that are cryptographically random, preventing the possibility to provide new certificates for Node-IDs already assigned, for example because a certificate will expire soon.</t>

			<t>
				This documents permits to extend the lifetime of a Node-ID by reissuing new certificates.
				This is done by sending the old certificate in the request to the enrollment server instead of the certificate signing request.
				The enrollment server MUST still check that the username and password are consistent with the certificate.
				If the nodeids parameter is different from the value used when issuing the previous certificate, then the number of Node-IDs in the new certificate must be adjusted, by either removing Node-IDs or by assigning new Node-IDs.
			</t>

			<t>This mechanism does not permit to change the RSA keys and keep the same Node-ID(s), but this is consistent with the self-signed certificates mechanism that does not permit this either.</t>
		</section>

		<section title="Security Considerations">
			<t>TBD</t>
		</section>

		<section title="IANA Considerations">
			<t>TBD</t>
		</section>

		<section title="Acknowledgements">
			<t>This document was written with the xml2rfc tool described in <xref target="RFC2629"/>.</t>
		</section>
	</middle>

	<back>
		<references title="Normative References">
			<reference anchor="RFC2119">

<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Requirement Levels</title>
<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>
<date month="March" year="1997"/>
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>
   In many standards track documents several words are used to signify
   the requirements in the specification.  These words are often
   capitalized.  This document defines these words as they should be
   interpreted in IETF documents.  Authors who follow these guidelines
   should incorporate this phrase near the beginning of their document:

<list>
<t>
      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.
</t>
</list>
</t>
<t>
   Note that the force of these words is modified by the requirement
   level of the document in which they are used.
</t>
</abstract>
</front>

<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<format octets="4723" target="http://www.rfc-editor.org/rfc/rfc2119.txt" type="TXT"/>
<format octets="17491" target="http://xml.resource.org/public/rfc/html/rfc2119.html" type="HTML"/>
<format octets="5777" target="http://xml.resource.org/public/rfc/xml/rfc2119.xml" type="XML"/>
</reference>
			<reference anchor="RELOAD">
<front>
<title>REsource LOcation And Discovery (RELOAD) Base Protocol</title>

<author fullname="Cullen Jennings" initials="C" surname="Jennings">
    <organization/>
</author>

<author fullname="Bruce Lowekamp" initials="B" surname="Lowekamp">
    <organization/>
</author>

<author fullname="Eric Rescorla" initials="E" surname="Rescorla">
    <organization/>
</author>

<author fullname="Salman Baset" initials="S" surname="Baset">
    <organization/>
</author>

<author fullname="Henning Schulzrinne" initials="H" surname="Schulzrinne">
    <organization/>
</author>

<date day="27" month="May" year="2011"/>

<abstract>
<t>This specification defines REsource LOcation And Discovery (RELOAD), a peer-to-peer (P2P) signaling protocol for use on the Internet.  A P2P signaling protocol provides its clients with an abstract storage and messaging service between a set of cooperating peers that form the overlay network.  RELOAD is designed to support a P2P Session Initiation Protocol (P2PSIP) network, but can be utilized by other applications with similar requirements by defining new usages that specify the kinds of data that must be stored for a particular application.  RELOAD defines a security model based on a certificate enrollment service that provides unique identities.  NAT traversal is a fundamental service of the protocol.  RELOAD also allows access from "client" nodes that do not need to route traffic or store data for others.</t>
</abstract>

</front>

<seriesInfo name="Internet-Draft" value="draft-ietf-p2psip-base-15"/>
<format target="http://www.ietf.org/internet-drafts/draft-ietf-p2psip-base-15.txt" type="TXT"/>
</reference>
		</references>

		<references title="Informative References">
			<reference anchor="RFC2629">

<front>
<title>Writing I-Ds and RFCs using XML</title>
<author fullname="Marshall T. Rose" initials="M.T." surname="Rose">
<organization>Invisible Worlds, Inc.</organization>
<address>
<postal>
<street>660 York Street</street>
<city>San Francisco</city>
<region>CA</region>
<code>94110</code>
<country>US</country>
</postal>
<phone>+1 415 695 3975</phone>
<email>mrose@not.invisible.net</email>
<uri>http://invisible.net/</uri>
</address>
</author>
<date month="June" year="1999"/>
<area>General</area>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>XML</keyword>
<keyword>Extensible Markup Language</keyword>
<abstract>
<t>This memo presents a technique for using XML
(Extensible Markup Language)
as a source format for documents in the Internet-Drafts (I-Ds) and
Request for Comments (RFC) series.</t>
</abstract>
</front>

<seriesInfo name="RFC" value="2629"/>
<format octets="48677" target="http://www.rfc-editor.org/rfc/rfc2629.txt" type="TXT"/>
<format octets="71741" target="http://xml.resource.org/public/rfc/html/rfc2629.html" type="HTML"/>
<format octets="53481" target="http://xml.resource.org/public/rfc/xml/rfc2629.xml" type="XML"/>
</reference>
		</references>

		<section title="Release notes">
			<t>This section must be removed before publication as an RFC.</t>

			

			

			

			
		</section>
	</back>
</rfc>