Internet DRAFT - draft-petithuguenin-p2psip-reload-bis
draft-petithuguenin-p2psip-reload-bis
P2PSIP M. Petit-Huguenin
Internet-Draft Stonyfish
Intended status: Standards Track October 31, 2011
Expires: May 3, 2012
Proposed Improvements for REsource LOcation And Discovery (RELOAD)
draft-petithuguenin-p2psip-reload-bis-01
Abstract
This document proposes some improvements for [RELOAD].
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, and it may not be
published except as an Internet-Draft.
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 3, 2012.
Copyright Notice
Copyright (c) 2011 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
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.
Petit-Huguenin Expires May 3, 2012 [Page 1]
Internet-Draft RELOAD Bis October 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Client connected to bootstrap node . . . . . . . . . . . . . . 3
4. Service Name and Path . . . . . . . . . . . . . . . . . . . . . 3
5. Multiple Node-IDs for self-signed certificates . . . . . . . . 3
6. Re-sign certificates . . . . . . . . . . . . . . . . . . . . . 4
7. Resource Name in StoreReq and FetchAns . . . . . . . . . . . . 4
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
11.1. Normative References . . . . . . . . . . . . . . . . . . . 5
11.2. Informative References . . . . . . . . . . . . . . . . . . 5
Appendix A. Release notes . . . . . . . . . . . . . . . . . . . . 6
A.1. Modifications between -01 and -00 . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6
Petit-Huguenin Expires May 3, 2012 [Page 2]
Internet-Draft RELOAD Bis October 2011
1. Introduction
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.
2. Terminology
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 [RFC2119].
3. Client connected to bootstrap node
Section 3.2.1 of [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.
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.
4. Service Name and Path
Section 10.2 of [RELOAD] uses a Service Name of "p2psip-enroll" and a
path of "/.well-known/p2psip-enroll".
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".
5. Multiple Node-IDs for self-signed certificates
Section 10.3.1 does not define an algorithm to create self-signed
certificates that contain multiple Node-IDs.
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.
Petit-Huguenin Expires May 3, 2012 [Page 3]
Internet-Draft RELOAD Bis October 2011
6. Re-sign certificates
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.
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.
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.
7. Resource Name in StoreReq and FetchAns
Some of the data structures defined by new Kinds contains on one form
or another the Resource Name that is used to generate the Resource-ID
used to store this kind. This is because the information in the
Resource Name is lost during this convertion. Examples of this are
the TURN-SERVICE Kind, the REDIR [I-D.ietf-p2psip-service-discovery]
Kind and all Kinds implementing the shared resource mechanism in
ShaRe [I-D.knauf-p2psip-share].
This document modifies the StoreReq structure by adding the Resource
Name:
struct {
KindId resource;
opaque resource_name<0..2^16-1>;
uint8 replica_number;
StoreKindData kind_data<0..2^16-1>;
} StoreReq;
This document also modifies the FetchAns structure by adding the
Resource Name:
Petit-Huguenin Expires May 3, 2012 [Page 4]
Internet-Draft RELOAD Bis October 2011
struct {
opaque resource_name<0..2^16-1>;
uint8 replica_number;
StoreKindData kind_data<0..2^16-1>;
} StoreReq;
8. Security Considerations
TBD
9. IANA Considerations
TBD
10. Acknowledgements
This document was written with the xml2rfc tool described in
[RFC2629].
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RELOAD] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)
Base Protocol", draft-ietf-p2psip-base-19 (work in
progress), October 2011.
11.2. Informative References
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[I-D.ietf-p2psip-service-discovery]
Maenpaa, J. and G. Camarillo, "Service Discovery Usage for
REsource LOcation And Discovery (RELOAD)",
draft-ietf-p2psip-service-discovery-03 (work in progress),
July 2011.
[I-D.knauf-p2psip-share]
Knauf, A., Hege, G., Schmidt, T., and M. Waehlisch, "A
Petit-Huguenin Expires May 3, 2012 [Page 5]
Internet-Draft RELOAD Bis October 2011
Usage for Shared Resources in RELOAD (ShaRe)",
draft-knauf-p2psip-share-02 (work in progress),
October 2011.
Appendix A. Release notes
This section must be removed before publication as an RFC.
A.1. Modifications between -01 and -00
o Added section about storage of Resource Name.
Author's Address
Marc Petit-Huguenin
Stonyfish
Email: marc@stonyfish.com
Petit-Huguenin Expires May 3, 2012 [Page 6]
