One document matched: draft-lowekamp-p2psip-reload-security-01.txt
Differences from draft-lowekamp-p2psip-reload-security-00.txt
P2PSIP B. Lowekamp
Internet-Draft J. Deverick
Intended status: Standards Track SIPeerior
Expires: January 9, 2008 July 8, 2007
Security Extensions for RELOAD
draft-lowekamp-p2psip-reload-security-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 9, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
P2PSIP deployments require the ability to authenticate both peers and
resources (users) without the active presence of a trusted entity in
the system. We describe how to use signature attributes in RELOAD
messages to ensure authentication and integrity for communications
between peers and to authenticate resource registrations. We
describe a shared-secret implementation and a public-key
implementation, each intended for a different deployment scenario.
Administrators can be select an implementation as appropriate for an
Lowekamp & Deverick Expires January 9, 2008 [Page 1]
Internet-Draft RELOAD Security July 2007
overlay's security requirements.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Security Properties . . . . . . . . . . . . . . . . . . . 4
3.2. Security Algorithms in RELOAD . . . . . . . . . . . . . . 5
3.3. Security Process . . . . . . . . . . . . . . . . . . . . . 5
3.4. Options for Securing SIP Sessions . . . . . . . . . . . . 6
4. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Peer Behavior . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Sender Behavior . . . . . . . . . . . . . . . . . . . . . 8
5.2. Processing Requests . . . . . . . . . . . . . . . . . . . 9
5.3. Processing Responses . . . . . . . . . . . . . . . . . . . 10
6. HMAC Security Algorithm . . . . . . . . . . . . . . . . . . . 10
6.1. Validating Messages . . . . . . . . . . . . . . . . . . . 10
7. CERTS Security Algorithm . . . . . . . . . . . . . . . . . . . 11
7.1. Validating Messages . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8.1. Protecting the ID Namespace . . . . . . . . . . . . . . . 12
8.2. Protecting the resource namespace . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Lowekamp & Deverick Expires January 9, 2008 [Page 2]
Internet-Draft RELOAD Security July 2007
1. Introduction
RELOAD provides peer-to-peer registration and resource location that
can be used for P2PSIP applications. A secure P2PSIP network
requires protection from a variety of security threats. Joining
peers should only be admitted into an overlay if they are authorized
members of that overlay. Resources (users) should be authenticated
before communication begins. The overlay's links and the data
registered on the peers should be protected from attackers. Without
such security measures in place, attackers can generate false
identities and become peers in the system, where they can interfere
with message routing and maintenance of the overlay structure. They
can also masquerade as other, valid users or resources in the
overlay, possibly generating false responses to resource requests.
The goal of RELOAD is to scale gracefully from ad hoc groups of a few
people to overlays of millions of peers across the globe. As such,
there is no one security model that fits the needs of all envisioned
environments: for the small network establishing a certificate chain
is difficult, while for a global network the unrestricted ability to
insert resources and devise useful Peer IDs is a clear invitation to
insecurity. To address this issue, the RELOAD security extensions
offer two different security models. The first is based on a shared
secret key and is applicable to small environments where deployment
of more complicated schemes is impractical. The second is a public
key certificate system applicable to larger deployments in which the
administrative costs of public key management is preferable to the
scalability issues of shared secret keys. One of these models should
be selected according to the needs of the overlay and the anticipated
deployment scenario.
Both approaches provide an implementation of the SIGNATURE attribute
as defined in RELOAD[I-D.bryan-p2psip-reload]. The essential concept
is that the SIGNATURE attribute encapsulates both a timestamp to
prevent replay and a cryptographic signature over the data to which
it applies. The public key signature also includes the principal
making the signature.
Additional security algorithms may be supported by RELOAD. Each
scheme requires an algorithm identifier for the header and must
define the attributes used by that security algorithm. A portion of
the attribute identifier space is reserved for security algorithms.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
Lowekamp & Deverick Expires January 9, 2008 [Page 3]
Internet-Draft RELOAD Security July 2007
document are to be interpreted as described in RFC 2119 [RFC2119].
Terminology defined in RFC 3261 [RFC3261] is used without definition.
We use also the terminology and definitions from Concepts and
Terminology for Peer to Peer SIP [I-D.willis-p2psip-concepts] and
REsource LOcation And Discovery (RELOAD) [I-D.bryan-p2psip-reload]
extensively in this document.
3. Overview
This section provides an informative overview of the RELOAD security
algorithms.
3.1. Security Properties
P2P overlays are subject to attacks by subversive nodes that may
attempt to disrupt routing, corrupt or remove user registrations, or
eavesdrop on signalling. The security algorithms we describe in this
draft are intended to protect DHT routing and user registration
information in RELOAD messages.
To protect the signaling, the first requirement is to ensure that all
messages are received from authorized members of the overlay. For
this reason, RELOAD provides a SIGNATURE attribute that appears at
the end of each message. This SIGNATURE can be used to authenticate
the message origin as a legitimate member of the overlay.
Beyond that, however, the contents of the message must be
authenticated. For information received from an individual peer, the
end-of-message SIGNATURE ensures that the message was sent by another
authorized peer. However, because a single peer may be compromised,
trusting all content sent by that peer may be unadviseable.
Therefore, RELOAD also applies SIGNATURE attributes to smaller
internal data elements that describe other peers. For example, peer
A may learn from peer B that there is a third peer C that would be a
good fit for its routing table. peer A does not have to trust peer B
that this peer C is trustworthy because the information peer B
forwards to peer A about peer C actually has its own signature from
peer C embedded in that component of the message. This is how RELOAD
avoids the transitive trust problem: any information learned about a
new peer is always learned from data signed by that new peer, not
from a different peer.
RELOAD applies the same SIGNATURE approach to resource registrations.
The message containing the resource registration is signed by the
originating peer, but the contents of the registration itself is
Lowekamp & Deverick Expires January 9, 2008 [Page 4]
Internet-Draft RELOAD Security July 2007
signed by the resource. This registration, with included SIGNATURE,
is returned in response to resource queries and is migrated as the
responsible peer changes. Again, the resource itself is
authenticating its registration, not the responsible peer or other
peers along the path the query takes.
This draft currently does not address message secrecy. Because the
routing header is separate from the attributes in the message, a
cryptographic encapsulation for the message attributes could easily
be devised for messages whose destination is a specific peer, rather
than a search for the responsible peer for a particular ID.
This draft presents a brief discussion and outlines possible
solutions for securing SIP sessions between P2PSIP peers. Additional
work on this issue and on securing sessions between a P2PSIP peer and
a conventional SIP peer or a peer in another overlay is required.
3.2. Security Algorithms in RELOAD
We described three security algorithms for RELOAD. The algorithm
used is identified by the SECURITY octet in the RELOAD header.
Additional security algorithms can be defined and indicated with new
SECURITY octet identifiers.
NONE Running without a security algorithm and no SIGNATURE
attribute. It is a totally unsecured protocol. OPEN ISSUE: It
would be trivial to support a SIGNATURE attribute that merely uses
self-signed certificates for security, possibly relying on another
external mechanism to validate them, or minimally allow the self-
signed certificates to be used to assert repeatable identity.
HMAC Shared secret security relies on a single key that is shared
among all members of the overlay. It is appropriate for small
groups that wish to form a private network without complexity.
HMAC SIGNATUREs contain a timestamp and an HMAC-SHA1 signature of
the data being secured.
CERTS Public key security relies on a public-key system with a CA
that is responsible for issuing certificates to all peers and
resources in the overlay prior to their joining. Because each
peer posesses the CA's certificate, they can verify the
certificates of the other entities in the overlay without further
communication. CERTS SIGNATUREs contain a timestamp, optional
certificate, and an RSA-SHA1 signature of the data being secured.
3.3. Security Process
Generally speaking, there are two processes that are secured by this
approach: DHT maintenance and resource registration. The signatories
for DHT maintenance are peers in the system. For resource
Lowekamp & Deverick Expires January 9, 2008 [Page 5]
Internet-Draft RELOAD Security July 2007
registrations, the resources themselves provide signatures. This
distinction is unimportant in the shared secret model, where the same
key is used to create all SIGNATUREs. In the public key system,
however, peers and resources may be issued different key-certificate
pairs. It is also possible for a resource to be bound to one or more
peers, containing the peer IDs as subjectAltNames in its certificate.
In such a case, the same key may be used to sign, and corresponding
certificate used to validate, both peer and resource communication,
though conceptually they are distinct. Jennings discusses other
possible ways of assigning certificates and
PeerIDs[I-D.jennings-p2psip-security].
DHT maintenance messages, including peer registrations, are
authenticated by verifying that the SIGNATURE attribute at the end of
the message was generated with the overlay key, in the case of the
shared-secret model. In the public-key certificate model, receiving
nodes verify that the signature was generated using the key
associated with the source peer ID as assigned by the certificate
authority for the overlay. The certificate is carried in the SOURCE-
INFO attribute of the message.
Resource registrations are authenticated by the RESOURCE-
INFO.BODY.SIGNATURE included in each RESOURCE-INFO.BODY. Once a
resource is registered in the overlay, its signed registration is
included as a resource ticket in all responses to queries for that
resource. This resource ticket prevents subversive peers from
forging registrations directly, and limits them to attacks on the
overlay routing or a simple DoS by not providing any registration
information to queries. This is particularly important as peers join
and leave the overlay; the resulting changes in the structure of the
DHT commonly result in resource migration among peers. Requiring
that the original, signed registration be included in responses
inhibits rogue peers' abilities to claim that they host resources not
legitimately migrated to them.
3.4. Options for Securing SIP Sessions
This document describes securing the signalling in RELOAD. However,
it does not directly secure the SIP sessions themselves. The
certificates used and distributed by the CERTS security model are
capable of securing the SIP sessions, and simple extensions to SIP
can be implemented to achieve this within a P2PSIP overlay. In
particular, the CERTS model allows a direct implementation of S/MIME
authentication [RFC3261].
Most deployed security models for conventional SIP assume the
existence of a trusted entity that actively participates by providing
keys or signing messages; to support secure communication from a
Lowekamp & Deverick Expires January 9, 2008 [Page 6]
Internet-Draft RELOAD Security July 2007
P2PSIP peer to a conventional SIP peer, one of these techniques must
be used. Many of these models can be used directly if a P2PSIP
overlay has a designated peer responsible for communication with
conventional SIP UAs. For example, sip-certs authentication
[I-D.ietf-sip-certs] can be used directly if an overlay is
provisioned with a credential server. However, requiring centralized
servers is not desireable for P2PSIP.
[I-D.lowekamp-p2psip-dsip-security] also proposed extensions to
[RFC4474] that could be used to secure SIP sessions, but supporting
them outside the overlay would require conventional SIP UAs to
implement those extensions.
4. Syntax
This document defines three identifiers for the security algorithm:
NONE : 0x01
HMAC : 0x02
CERTS : 0x03
Several new attributes are defined. Technically each of the previous
security algorithms can define its own set of attributes in the
attribute space reserved for security algorithms. However, we will
use the same set of attributes for each algorithm for convenience.
A SIGNATURE type (used for SIGNATURE, PEER-SIGNATURE, and RESOURCE-
INFO.BODY.SIGNATURE) can contain the following attributes:
TIMESTAMP : 0x0801
DIGEST : 0x0802
where TIMESTAMP is a 32-bit encoding of seconds since the epoch and
DIGEST is an HMAC-SHA1 or RSA-SHA1 digest byte stream as appropriate.
TIMESTAMP is not used in HMAC.
PEER-CERTIFICATE and RESOURCE-CERTIFICATE contain only the X.509
certificate as its value.
4.1. Example
Below is an example of a resource registration request message
presented in ascii format. It registers a sip contact for
alice@example.com, an email address to forward, and supplies the
certificate for both the resource registration and the source-info.
Lowekamp & Deverick Expires January 9, 2008 [Page 7]
Internet-Draft RELOAD Security July 2007
Version: 0x01
Method: 0x11
DHT: 0x0
Security: 0x03
Hash: 0x0
Source ID: 463ac413c4
Destination ID: a6c5927a45
-------Attributes-------
SOURCE-INFO:
PEER-ID: 463ac413c4
PEER-IP-PORT: 10.4.1.2:5060
PEER-CERT: 23d634...
PEER-EXPIRATION: 300
RESOURCE:
RESOURCE-INFO.KEY: alice@example.com
RESOURCE-INFO.BODY:
RESOURCE-INFO.BODY.ENTRY: sip:alice@10.4.1.2:5060
RESOURCE-INFO.BODY.EXPIRATION: 300
RESOURCE-INFO.BODY.PEER-INFO:
PEER-ID: 463AC413C4
RESOURCE-INFO.BODY.SIGNATURE:
TIMESTAMP: 946702799
DIGEST: 3037e...
RESOURCE-INFO.BODY
RESOURCE-INFO.BODY.ENTRY: mailto:alice@example.com
RESOURCE-INFO.BODY.EXPIRATION: 24000
RESOURCE-INFO.BODY.PARAMETER:
RESOURCE-INFO.BODY.PARAMETER.KEY: type
RESOURCE-INFO.BODY.PARAMETER.OP: 0x1
RESOURCE-INFO.BODY.PARAMETER.VALUE: voicemail
RESOURCE-INFO.BODY.SIGNATURE:
TIMESTAMP: 946702799
DIGEST: 5f271b1...
RESOURCE-INFO.BODY
RESOURCE-INFO.BODY.CERTIFICATE: 23d634...
5. Peer Behavior
This draft applies to all messages sent between peers in a RELOAD
overlay.
5.1. Sender Behavior
When using a security algorithm that requires SIGNATUREs (HMAC and
CERTS in this draft), a sender MUST include a SIGNATURE as the last
attribute of the message. The SIGNATURE applies to all data in the
message from the 8th byte in the header (indicating the protocol
Lowekamp & Deverick Expires January 9, 2008 [Page 8]
Internet-Draft RELOAD Security July 2007
version, etc) to the final byte preceding the DIGEST in the
SIGNATURE. The DIGEST MUST be the last attribute in the SIGNATURE
and all other attributes of the SIGNATURE MUST be generated prior to
calculating the DIGEST. For the CERTS security algorithm, or other
certificate-based algorithm, the sender MUST include a PEER-CERT
attribute in the SOURCE-INFO.
If the DHT algorithm in use requires or allows peers to forward
portions of their routing table in their messages, the sender MUST
provide a SIGNATURE as the last attribute in the SOURCE-INFO
attribute. As a component of SOURCE-INFO, this SIGNATURE applies
only to the data in the SOURCE-INFO. Signing the SOURCE-INFO
separately allows other peers to trust the routing table entries they
receive from their neighbors because that SOURCE-INFO will be
included as part of the routing table entry.
OPEN ISSUE: Optionally the PEER-CERT could be left out of the message
if it is being sent to a peer that has previously received (and
cached) the certificate. However, this requires an error-response
that indicates the certificate must be included. We have gone with
simplicity to simply require the certificate always be included.
A sender must also include a SIGNATURE as the final attribute inside
each RESOURCE-INFO.BODY attribute included in their message. In the
case of a RESOURCE-PUT, the peer is responsible for generating the
SIGNATURE. In other operations, such as the response to a RESOURCE-
GET or in a RESOURCE-TRANSFER, the original RESOURCE-INFO.BODY first
received MUST be transferred as originally sent, including its
SIGNATURE.
For security algorithms requiring certificates, such as CERTS, the
RESOURCE-INFO.BODY.CERTIFICATE is included as the sole entry in a
RESOURCE-INFO.BODY. This RESOURCE-INFO.BODY must always be included
in a message that includes one of the RESOURCE-INFO.BODY.SIGNATURE
fields that uses that signature. In other words, whenever a RESOURCE
attribute is included in a message, it will contain at least two
RESOURCE-INFO.BODY members, one of which will contain the certificate
for the resource. The certificate is included as a separate BODY to
avoid unnecessary duplication. The BODY containing the certificate
does not include a SIGNATURE because the certificate is already
signed by the CA.
5.2. Processing Requests
When using a security algorithm that requires SIGNATUREs, a peer MUST
NOT perform any action in response to a Request that changes its
state or returns information stored in the overlay without validating
the SIGNATURE at the end of the request message. A peer MAY proxy or
Lowekamp & Deverick Expires January 9, 2008 [Page 9]
Internet-Draft RELOAD Security July 2007
redirect a request without validation, and it may return error codes
indicating an error in the request, without validating the request,
however it MUST NOT process a DHT maintenance request or resource
registration that it is responsible for in any way, including
generating a 404, until it has completed validation of the message's
SIGNATURE.
A peer MUST NOT generate a response that contains any RESOURCE-
INFO.BODY that it has not previously verified the SIGNATURE for and
verified that the signing entity matches the RESOURCE-INFO.KEY to
which the RESOURCE-INFO.BODY belongs.
All responses to requests, whether successful or an error response,
MUST contain a SIGNATURE generated by the responding peer.
5.3. Processing Responses
When using a security algorithm that requires SIGNATUREs, a peer MUST
NOT perform any action based on a response without validating the
SIGNATURE of the response message. This includes reacting to an
error code that may be generated without validating the corresponding
request.
After validating the response message to a resource query, the
requesting peer MUST validate the SIGNATURE in each RESOURCE-
INFO.BODY and confirm that the signing entity matches the RESOURCE-
INFO.KEY before storing any information about that resource or
passing knowledge of the response to the application.
6. HMAC Security Algorithm
To secure a small-scale network, perhaps an office environment or
other small group of people who wish to communicate together, a
shared secret will suffice. Rather than relying on a domain
certificate, therefore, the DIGEST field consists of an HMAC-SHA1
[RFC2104] hash of the data being signed. The DIGEST is encoded as a
raw byte array rather than in base64 encoding.
Because shared secrets are shared between all peers in the overlay,
there is no need to fetch one, therefore no PEER-CERT is required.
6.1. Validating Messages
Validating messages signed with a shared secret is simple because all
messages are signed with the same shared secret. Therefore the
message can be validated without fetching any external information.
A request that is received without a SIGNATURE MUST be rejected with
Lowekamp & Deverick Expires January 9, 2008 [Page 10]
Internet-Draft RELOAD Security July 2007
a 401 error code. A request with an incorrect SIGNATURE MUST be
rejected with a 431 error code.
7. CERTS Security Algorithm
The CERTS security algorithm requires the existence of a CA
responsible for the overlay. Typically each user registering for the
overlay will receive a certificate for their identity within the
overlay (AoR) and a small number of PeerIDs as subjectAltNames to
identity peers they intend to use (allowing for multiple PeerIDs for
multiple UAs the user may wish to have on the overlay
simultaneously). The CA SHOULD issue such PeerIDs consecutively to
prevent a single user from controlling multiple portions of the
overlay. Other than consecutive PeerIDs assigned to the same user,
PeerIDs SHOULD be assigned uniformly across the namespace.
For the CERTS security scheme, the DIGEST field consists of an RSA-
SHA1 hash of the data being signed in raw byte-stream encoding. The
PEER-CERT attribute consists of a DER encoded X.509v3
certificate[RFC2585].
Each peer must be provisioned with the CA's certificate as well as
its own private key and certificate, signed by the CA.
When using the CERTS security algorithm, each peer SHOULD be
provisioned with a reliable method for time synchronization.
Each peer MUST calculate its Transaction IDs by dividing the
TransactionID into two 32-bit quantities. The first is the boot-time
of the peer in seconds since the epoch. The second is a counter that
starts at zero and is incremented for each new request that is sent.
This information can be used by a receiving peer to prevent replay
attacks.
7.1. Validating Messages
Before validating a SIGNATURE, the peer must ensure that the
accompanying certificate is signed by the certificate authority for
the overlay. A request that is received without a required SIGNATURE
or CERTIFICATE MUST be rejected with a 401 error code. A request
received with an incorrect SIGNATURE MUST be rejected with a 431
error code.
The receiving peer MUST ensure that the SIGNATURE is the last
attribute of the body except for any ROUTE-LOG attributes that were
added by peers as the message was routed along the overlay. Any
attributes other than ROUTE-LOG that follow the top-level SIGNATURE
Lowekamp & Deverick Expires January 9, 2008 [Page 11]
Internet-Draft RELOAD Security July 2007
MUST be ignored.
8. Security Considerations
No security scheme is stronger than the security with which it is
administered. If the shared secret key for the HMAC security scheme
is discovered by an attacker, then the security of the entire scheme
is lost. Similarly, for the CERTS security scheme, if the CA is
compromised and an attacker can generate arbitrary certificates, the
scheme becomes insecure. Although it is fundamental to the security
of both of these schemes, the provisioning of peers with either the
shared secret key or with a private key and certificate is beyond the
scope of this draft.
The whole-message SIGNATURE provides integrity and authentication for
the message. It includes all fields of the header not modified per-
hop and all attributes originally included in the message. ROUTE-LOG
attributes are added by on-path peers and follow the SIGNATURE in the
message. ROUTE-LOG attributes MUST be appended to the end of the
message because the intermediate peers cannot change any portion of
the body of the message that would cause the SIGNATURE to be invalid.
To prevent replay attacks, the SIGNATURE covers the TransactionID and
includes a timestamp. The timestamp is useful only if all peers have
synchronized clocks. To further prevent replay attacks, the
definition of TransactionID in the CERTS algorithm allows a peer to
identify new transactions by storing only a small amount of state for
each peer.
8.1. Protecting the ID Namespace
When used properly, both schemes sufficiently inhibit attackers
attempting to join the overlay. The CERTS scheme, in particular,
further protects the ID namespace by reducing the impact of
compromising a single authorized peer of the overlay, whereas an
attacker compromising a single peer in the shared-secret scheme can
obtain the shared secret and thus compromise the entire namespace.
The CERTS security scheme secures the namespace, but if an individual
peer is compromised or if an attacker obtains a certificate from the
CA, then a number of subversive peers can still appear in the
overlay. While these peers cannot falsify responses to resource
queries, they can respond with 404 error messages, effecting a DoS
attack on the resource registration. They can also subvert routing
to other compromised peers. To defend against such attacks, a
resource search must still consist of parallel searches for
replicated registrations.
Lowekamp & Deverick Expires January 9, 2008 [Page 12]
Internet-Draft RELOAD Security July 2007
8.2. Protecting the resource namespace
The shared-secret scheme prohibits unauthorized peers from joining
the overlay, but it provides no protection from a compromised peer
inserting arbitrary resource registrations, performing a Sybil
attack[Sybil], or performing other attacks on the resources.
The CERTS scheme prevents an attacker compromising a single peer from
being able to forge the registration for more than that peer's
resources. Furthermore, although a subversive peer can refuse to
return registration entries for resources for which it is responsible
or in response to requests routed through it (404 Not Found
responses), it cannot return forged registrations because it cannot
provide authentication for such registrations. Therefore parallel
searches for redundant registrations mitigate most of the affects of
a compromised peer. The ultimate reliability of such an overlay is a
statistical question based on the replication factor and the
percentage of compromised peers.
Once a resource is registered, the corresponding RESOURCE-INFO.BODY
is used as a response to queries for that resource, migrated between
peers, and generally considered public knowledge. As it is
inherently intended to be replayed, the value selected in the Expires
header of the original registration must be chosen carefully to
ensure that responses to future queries do not direct the querier to
a location over which the resource no longer has control.
9. IANA Considerations
This document will require additions to IANA registries.
10. References
10.1. Normative References
[I-D.bryan-p2psip-reload]
Bryan, D., Zangrilli, M., and B. Lowekamp, "REsource
LOcation And Discovery (RELOAD)", Internet
Draft draft-bryan-p2psip-reload-01, July 2007.
[I-D.ietf-sip-certs]
Jennings, C., "Certificate Management Service for The
Session Initiation Protocol (SIP)",
draft-ietf-sip-certs-03 (work in progress), March 2007.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Lowekamp & Deverick Expires January 9, 2008 [Page 13]
Internet-Draft RELOAD Security July 2007
Hashing for Message Authentication", RFC 2104,
February 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key
Infrastructure Operational Protocols: FTP and HTTP",
RFC 2585, May 1999.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006.
10.2. Informative References
[I-D.jennings-p2psip-security]
Jennings, C., "Security Mechanisms for Peer to Peer SIP",
draft-jennings-p2psip-security-00 (work in progress),
February 2007.
[I-D.lowekamp-p2psip-dsip-security]
Lowekamp, B. and J. Deverick, "Authenticated Identity
Extensions to dSIP", Internet
Draft draft-lowekamp-p2psip-dsip-security-00, March 2007.
[I-D.willis-p2psip-concepts]
Willis, D., "Concepts and Terminology for Peer to Peer
SIP", draft-willis-p2psip-concepts-04 (work in progress),
March 2007.
[Sybil] Douceur, J., "The Sybil Attack", March 2002.
Lowekamp & Deverick Expires January 9, 2008 [Page 14]
Internet-Draft RELOAD Security July 2007
Authors' Addresses
Bruce B. Lowekamp
SIPeerior
3000 Easter Circle
Williamsburg, VA 23188
USA
Phone: +1 757 565 0101
Email: lowekamp@sipeerior.com
James W. Deverick
SIPeerior
3000 Easter Circle
Williamsburg, VA 23188
USA
Phone: +1 757 565 0101
Email: jdeverick@sipeerior.com
Lowekamp & Deverick Expires January 9, 2008 [Page 15]
Internet-Draft RELOAD Security July 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Lowekamp & Deverick Expires January 9, 2008 [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-24 01:21:21 |