P2PSIP B. Lowekamp
Internet-Draft J. Deverick
Intended status: Standards Track SIPeerior
Expires: August 29, 2007 February 25, 2007
Authenticated Identity Extensions to dSIP
draft-lowekamp-p2psip-dsip-security-00
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 August 29, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document describes mechanisms to authenticate peer and resource
identities within a distributed SIP overlay. It makes use of
existing identity frameworks, modifying them as necessary to
accommodate the specific needs of a peer-to-peer environment.
Lowekamp & Deverick Expires August 29, 2007 [Page 1]
Internet-Draft dSIP Identity February 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Security Models . . . . . . . . . . . . . . . . . . . . . 4
3.2. Security Process . . . . . . . . . . . . . . . . . . . . . 5
3.3. Example Message Flow . . . . . . . . . . . . . . . . . . . 6
4. Peer Behavior . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Changes to RFC4474 . . . . . . . . . . . . . . . . . . . . 9
4.2. Resource Tickets . . . . . . . . . . . . . . . . . . . . . 9
4.3. Sender Behavior . . . . . . . . . . . . . . . . . . . . . 10
4.4. Processing Requests . . . . . . . . . . . . . . . . . . . 10
4.5. Processing Responses . . . . . . . . . . . . . . . . . . . 10
5. Shared Secret . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Validating Messages . . . . . . . . . . . . . . . . . . . 11
6. Certificates . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Selecting the Authenticating Identity for Messages . . . . 12
6.2. Validating Messages . . . . . . . . . . . . . . . . . . . 12
6.3. Fetching Certificates . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7.1. Protecting the ID Namespace . . . . . . . . . . . . . . . 14
7.2. Protecting the resource namespace . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 17
Lowekamp & Deverick Expires August 29, 2007 [Page 2]
Internet-Draft dSIP Identity February 2007
1. Introduction
The distributed Session Initiation Protocol (dSIP) extends
traditional SIP by providing peer-to-peer registration and resource
location. While most security mechanisms for dSIP derive naturally
from its client-server counterpart, certain considerations must be
made for the peer-to-peer extensions provided by the protocol.
Joining peers should only be admitted into an overlay if they are
authorized members of that overlay. Resources should be
authenticated to ensure genuine communication among them.
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 dSIP is to scale gracefully from ad hoc groups of a few
people to an overlay 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 dSIP 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 make use of the Identity digest-string header
presented in RFC 4474. In that specification, this digest over
certain header fields and the message body is signed by an
authentication service for the domain in which the communication is
occurring. Because the concept of a specific, server-based, central
authentication service role is antithetical to the dSIP paradigm,
this approach modifies how the Identity header is signed when
messages are being constructed. Details on the changes as applicable
to each security model are presented in Section 3.1
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
Lowekamp & Deverick Expires August 29, 2007 [Page 3]
Internet-Draft dSIP Identity February 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
dSIP: A P2P Approach to SIP Registration and Resource Location
[I-D.bryan-p2psip-dsip] extensively in this document.
3. Overview
Instead of violating the distributed nature of dSIP by implementing
the RFC 4474 authentication service as central server, the dSIP
Security Extensions require communication endpoints to sign and
validate correspondence directly. The method by which this is done
varies depending on the security model being used. In both models,
the Identity digest-string is generated without modification as
described in P2P Identity, but the protocol by which the digest is
signed (and by extension the verification protocol) changes.
Additionally, we modify the contents of the Identity-Info header as
necessary to provide message recipients required information to
validate incoming messages. For both security models, the details of
key and certificate provisioning are beyond the scope of this
document, and we assume that they are provided by some out of band
mechanism.
3.1. Security Models
The shared secret signature process is straightforward. After the
identity digest-string is generated, the endpoint encrypts it with
the shared secret key for the overlay, and populates the Identity
header with the encrypted value. It also injects a string
identifying the algorithm used to generate the Identity value in the
Identity-Info header. The recipient of the message can then generate
the same digest-string, and encrypt it with the same shared key and
algorithm, comparing the result to the value presented in the
Identity header of the message. If the value generated by the
recipient does not match the value contained in the Identity header,
the message should be considered unauthorized and rejected.
In the public key certificate model, each endpoint has a different
private key and a corresponding public key certificate issued by a
certificate authority for the overlay. When an endpoint prepares an
outbound message, it generates the identity digest-string and signs
it with its unique private key. In addition, it fills the Identity-
Info header with the sip URI of the certificate that the recipient
needs to verify the identity signature. When the recipient receives
Lowekamp & Deverick Expires August 29, 2007 [Page 4]
Internet-Draft dSIP Identity February 2007
the message, it may have a preloaded or cached copy of the necessary
certificate. If not, it can subscribe to the URI indicated in the
Identity-Info header using the SIP event notification extensions
defined in sip-certs [I-D.ietf-sip-certs] to fetch the needed
certificate. When the certificate arrives, the recipient must first
verify that it is signed by the CA for the overlay. Once the
validity of the certificate is confirmed, the recipient can use the
certificate to verify the signed digest-string in the Identity header
of the original message and accept or reject the message
appropriately. The fetched certificate may, as a matter of local
policy, be cached for future verifications.
3.2. Security Process
Generally speaking, there are two processes that are secured by this
approach: DHT maintenance and resource registrations and migrations.
The signatories for DHT maintenance are peers in the system. For
resource registrations, the resources themselves provide signatures.
This distinction is unimportant in the shared secret model, where the
same key is used to create all Identity headers. In the public key
certificate system, however, it is possible for peers and resources
to 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 in general
they are distinct.
DHT maintenance, including peer registrations, authenticate messages
by verifying that the Identity header 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 header was
generated using the key associated with the specified peer ID as
assigned by the certificate authority for the overlay.
Resource registrations are identical to peer registrations in the
shared-secret model. In the certificate-based model, however, the
verification process uses the certificate for the resource indicated
in the From header, rather than the peer ID.
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
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
Lowekamp & Deverick Expires August 29, 2007 [Page 5]
Internet-Draft dSIP Identity February 2007
the original, signed registration be included in responses inhibits
rogue peers' abilities to claim that they host resources not
legitimately migrated to them.
3.3. Example Message Flow
To illustrate the message flow generated by the security extensions,
consider a resource registration and query. Because it is the most
complex scenario, assume that the public key certificate model is
used, and that no certificates have been preloaded or cached by peers
in the system.
Lowekamp & Deverick Expires August 29, 2007 [Page 6]
Internet-Draft dSIP Identity February 2007
Peer 0 Peer 1 Peer 2
| | |
|(1) REGISTER | |
|------------------>| |
| resource r | |
| | |
|(2) SUBSCRIBE | |
|<------------------| |
| cert for r | |
| | |
|(3) NOTIFY | |
|------------------>| |
| cert for r | |
| | |
|(4) 200 | |
|<------------------| |
| | |
| |(5) REGISTER |
| |<------------------|
| | query r from s |
| | |
| |(6) SUBSCRIBE |
| |------------------>|
| | cert for s |
| | |
| |(7) NOTIFY |
| |<------------------|
| | cert for s |
| | |
| |(8) 200 |
| |------------------>|
| | response r |
| | |
|(9) SUBSCRIBE | |
|<--------------------------------------|
| cert for r | |
| | |
|(10) NOTIFY | |
|-------------------------------------->|
| cert for r | |
In (1), resource r is registered at peer 1. Since peer 1 does not
have a copy of r's certificate to verify the Identity header for r's
registration, it subscribes to the URI indicated by the Identity-Info
header of the REGISTER message. In this case, that header contains
the URI of peer 0. Peer 0, on receipt of the certificate
subscription request (2), issues a notification response (3)
containing r's certificate. At this point, peer 1 validates that the
Lowekamp & Deverick Expires August 29, 2007 [Page 7]
Internet-Draft dSIP Identity February 2007
certificate is signed by the overlay's certificate authority, then
uses the certificate to verify the Identity field in the original
registration for resource r. Because the signature is valid, peer 1
issues a 200 OK (4) to peer 0, indicating that r has been registered
successfully.
Later, resource s wishes to query resource r. After locating r as
described in dSIP and omitted from this diagram, s queries peer 1 (5)
for resource r. The REGISTER message used for this query contains a
signed digest-string that peer 1 must validate. Because peer 1 does
not have a copy of s's certificate, it subscribes to peer 2 (6), the
URI provided by resource s in the Identity-Info header. Resource s
at peer 2 responds with its certificate (7), allowing peer 1 to
verify the resource request. Once the verification is complete, peer
1 responds (8) to the resource query. Included in the response to
s's query is a copy of r's original registration at peer 1. In order
to trust that the response is valid, s must verify that the copy of
r's registration actually originated from r and has not yet expired.
It does so by subscribing (9) to peer 0 as indicated in by the
Identity-Info header of the encapsulated registration. Peer 0
responds with a copy of r's certificate (10), which s uses to verify
that the response it received from its query for resource r
ultimately originated from r's valid registration.
Note that the responses in steps (4) or (8) could also be 401
Unauthorized if the certificates received by the corresponding
notifications could not verify the requests in (1) and (5),
respectively. In the first case, this would result in a failed
registration for resource r. In the second, the query for r from
resource s would be refused. Finally, if the certificate retrieved
in (10) fails to verify the encapsulated copy of r's registration
received in (8), then s should treat the response as unauthorized and
discard it.
4. Peer Behavior
This draft applies to all messages sent between peers in a dSIP
overlay. Such messages are identifiable by the presence of the token
'dht' in the message's Require header. The provisions provided by
this document are not applicable to messages that do not satisfy this
prerequisite. If the overlay requires dSIP-identity security to be
used, then all messages sent that perform any dht or resource
maintenance or queries (any message with a Require: p2p) MUST include
the appropriate Identity and Identity-Info headers. Messages
received that do not contain an Identity header MUST be rejected with
a 428 Use Identity Header response code. Extensions defined in this
document MUST NOT appear in any message that does not include a "dht"
Lowekamp & Deverick Expires August 29, 2007 [Page 8]
Internet-Draft dSIP Identity February 2007
token in the Require header.
Because we interpret the Identity and Identity-Info headers from
RFC 4474 differently, we have to prevent implementations of
conventional RFC 4474 from being adversely affected. By requiring
that this specification only apply to messages with the Require
dht header, standard RFC 4474 implementations should not see the
modified messages. Whether or not this is satisfactory to address
the concern remains an open question.
4.1. Changes to RFC4474
dSIP-identity is an extension of RFC 4474 [RFC4474]. Unless this
draft specifies otherwise, all behavior described in RFC 4474 is
followed in generating the dSIP-identity headers. In particular,
digest-string is determined in the same manner. The two major
exceptions are:
Response Authentication: Unlike RFC 4474, responses MUST include an
Identity header used to validate the response. Although the
sender does not always know which peer will ultimately respond to
a request, it can assert that the response it receives originated
from an authorized member of the overlay.
Fetching Certificates: For certificate-based security, RFC 4474
specifies that implementations MUST support HTTP and HTTPS URIs in
the Identity-Info header. All peers compliant with this
specification MUST support HTTP and HTTPS URIs for retrieving
certificates from peers providing such a server. In addition, all
peers compliant with this specification MUST support the
"certificate" SIP Event Package from sip-certs
[I-D.ietf-sip-certs] both as subscriber and notifier. A peer MUST
NOT provide an HTTP or HTTPS URI for its Identity-Info unless it
knows that no NAT traversal techniques will be required to contact
that server (i.e. it knows its server has an unfirewalled port at
an address that is directly routable by all peers in the overlay).
Because this is difficult to know in advance, peers SHOULD rely on
the Event Package technique.
4.2. Resource Tickets
A peer receiving a resource registration for which it is responsible
stores the registration itself and additionally MUST store the
digest-string, Identity, and Identity-Info from the actual request
message used to send the registration. This information stored from
the request message will be known as a resource ticket. The resource
ticket MUST be returned in the body of any 200 OK response the
responsible peer returns in response to a query for the resource it
is responsible for. The ticket allows the querying entity to
validate that the actual resource performed the indicated
registration.
Lowekamp & Deverick Expires August 29, 2007 [Page 9]
Internet-Draft dSIP Identity February 2007
4.3. Sender Behavior
When sending a message, the sender implements the authentication
service described in RFC 4474 [RFC4474].
4.4. Processing Requests
A peer MUST NOT perform any action that changes state or returns
information stored in the overlay without validating the Identity
signature of the request message. A peer MAY proxy or redirect a
request without validation, and it may return error codes indicating
an error in the request, such as 413, 414, 420, etc 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.
An important exception to the above rule is that in certificate-based
security schemes, a peer MUST NOT validate a SUBSCRIBE request for
the peer's certificate if it requires fetching the certificate of the
peer submitting the request. This exception avoids deadlock fetching
certificates.
4.5. Processing Responses
A peer MUST NOT perform any action based on a response without
validating the Identity signature of the response message. This
includes reacting to an error code such as 420 response that may be
generated without validating the corresponding request.
After validating the response message to a resource query, if the
result code is a 200 OK, the peer MUST confirm that the response
contains a resource ticket. The peer MUST then separately validate
the resource ticket. Because resource tickets are longer-lived than
standard messages, the peer SHOULD allow a longer validity period
with respect to the Date header of the message, although not in
excess of the Expires value of the resource ticket.
5. Shared Secret
To secure a small-scale network, perhaps an office environment or
small group of people who wish to communicate together, a shared
secret will suffice. Rather than relying on a domain certificate,
therefore, the Identity field consists of an HMAC-SHA1 [RFC2104] hash
of the digest-string.
Because shared secrets are shared between all peers in the overlay,
Lowekamp & Deverick Expires August 29, 2007 [Page 10]
Internet-Draft dSIP Identity February 2007
there is no need to fetch one, therefore Identity-Info stores only
the name of the algorithm used to sign the message. This requires a
change in the syntax of the Identity-Info header to allow the ident-
info parameter to be omitted:
Identity-Info = "Identity-Info" HCOLON ident-uri-info /
( ident-info-params *( SEMI ident-info-params ) )
ident-uri-info = ident-info *( SEMI ident-info-params )
where ident-uri-info is the definition of Identity-Info from RFC 4474
and ident-info-params is used as the only element of Identity-Info
only when used for a security mechanism such as shared secret where
no certificates must be identified or retrieved.
Messages using shared secrets must contain an "alg" parameter. This
specification defines the value "hmac-sha1" for the "alg" parameter.
Messages MUST additionally contain the token "dSIP" as an ident-info-
extension to indicate the type of processing required to validate the
message. Therefore, the Identity-Info header will be
Identity-Info: alg=hmac-sha1;dSIP
5.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.
When validating a message, the receiver MUST verify that the Identity
header presents the correct 'hmac-sha1' hash obtained by hashing the
message's digest-string using the overlay's shared secret as the key.
Any message that provides incorrect Identity information MUST be
rejected with a 438 Invalid Identity Header response code.
6. Certificates
Certificate-based implementations of dSIP-identity require 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.
Lowekamp & Deverick Expires August 29, 2007 [Page 11]
Internet-Draft dSIP Identity February 2007
Each peer must be provisioned with the CA's certificate as well as
its own private key and certificate, signed by the CA.
For peers providing their certificates to other peers through the
"certificate" SIP Event Package [I-D.ietf-sip-certs], ident-info in
Identity-Info typically will be the P2P URI of the peer. Peers
hosting resources with separate certificates MUST use different URIs
for each certificate, but each URI MUST contain the peerID of the
peer hosting that resource so that SUBSCRIBE messages can be routed
to the correct peer.
Messages sent using certificate-based dSIP-identity MUST include the
tokens 'alg=rsa-sha1' and 'dSIP' in the Identity-Info Header. This
is in addition to the URI from which the sender's certificate can be
retrieved.
6.1. Selecting the Authenticating Identity for Messages
All request messages MUST be signed with the identity specified in
the From header. For DHT maintenance (peer registration and
queries), this will also be the same as the PeerID header, i.e. the
identity of the peer originating the request. For resource
registrations and queries, this will be the identity of the resource
performing the operation. In the typical case, a UA will have a
single certificate that is used for both the user's identity and peer
ID, so these may be the same certificate.
All response messages MUST be signed with the identity specified in
the PeerID header, which identifies the peer generating the response
and authenticates the response as having been generated by an
authorized peer. The requesting peer might also validate that the
responding peer has an appropriate PeerID to be responsible for that
portion of the namespace, but such validation is outside the scope of
this draft and may have negative implications for resource caching or
other optimizations.
Note that a resource migration, which is a third party registration
used to move resources as the peers responsible for those resource
IDs change due to joining or exiting peers, is signed using the key
of the admitting or exiting peer and uses that peer's URI as it's
From address. The resource ticket MUST be included in the body of
that request.
6.2. Validating Messages
To validate a message, a peer first checks its certificate cache to
see whether it has a certificate corresponding to the authenticating
identity used to sign the message. If it does not, it MUST fetch the
Lowekamp & Deverick Expires August 29, 2007 [Page 12]
Internet-Draft dSIP Identity February 2007
certificate using the URI in Identity-Info and defer further
processing of the message until validation can be completed. A peer
MUST NOT validate a "certificate" SIP Event Package SUBSCRIBE request
for the peer's certificate if it does not already possess the
certificate of the subscribing peer. It MUST respond to such
requests without verification.
The peer MUST use the certificate corresponding to the authenticating
identity appropriate for the type of message, as described above in
Section 6.1. The peer MUST NOT use Identity-Info to determine which
certificate to use. If a certificate retrieved from the URI
specified in Identity-Info does not match the appropriate
authenticating identity or is not signed by the certificate authority
for the overlay, the peer MUST reject that message with a 438 Invalid
Identity Header response code.
After confirming that it has the correct certificate, the peer
follows the procedures specified in RFC 4474 [RFC4474] to verify the
signature.
6.3. Fetching Certificates
A peer uses the "certificate" SIP Event Package[I-D.ietf-sip-certs]
to fetch certificates. Because CA-signed certificates are long-
lived, the peer SHOULD issue the SUBSCRIBE with Expires header of 0
to specify only a single NOTIFY response is desired.
After receiving the NOTIFY response, the peer MUST verify that the
certificate received is signed by the overlay's CA. Certificates
that are not signed by the overlay's CA MUST immediately be discarded
and any message validations waiting for the certificates to be
fetched MUST immediately be rejected with a 437 Unsupported
Certificate response code.
7. Security Considerations
No security scheme is stronger than the security with which it is
administered. If the shared-secret passphrase for the HMAC security
scheme is discovered by an attacker, then the security of the entire
scheme is lost. Similarly, for the dSIP-identity security scheme, if
the CA is compromised and an attacker can generate arbitrary
certificates, the security of the scheme is compromised. Although it
is fundamental to the security of both of these schemes, the
provisioning of peers with either the shared secret passphrase or
with an private key and certificate is beyond the scope of this
draft.
Lowekamp & Deverick Expires August 29, 2007 [Page 13]
Internet-Draft dSIP Identity February 2007
The dSIP-identity 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, compromising (not returning) registrations
they are responsible for and possibly subverting routing to other
compromised peers. To defend against such compromised peers, a
resource search must still consist of parallel searches for
replicated registrations. The ultimate reliability of such an
overlay is a statistical question based on the replication factor and
the percentage of compromised peers.
Because this protocol relies on digest-string from RFC 4474
[RFC4474], it provides the same message integrity, authentication,
and defense against replay attacks offered by that specification. It
also shares the same weaknesses, described in Section 13 of RFC 4474.
In particular, because Identity and Identity-Info headers can be
replaced by an attacker, it is up to the recipient to ensure that the
certificate used to sign this message matches the claimed sender of
the message and that the certificate is signed by the proper CA for
the particular overlay.
7.1. Protecting the ID Namespace
When used properly, both schemes sufficiently inhibit attackers
attempting to join the overlay. The dSIP-identity 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.
7.2. Protecting the resource namespace
The shared-secret scheme protects the overlay from unauthorized peers
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 dSIP-identity 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 authenticate such registrations. Therefore parallel searches
for redundant registrations mitigate most of the affects of a
compromised peer.
Once a resource is registered, the corresponding Resource Ticket is
Lowekamp & Deverick Expires August 29, 2007 [Page 14]
Internet-Draft dSIP Identity February 2007
used in 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.
8. IANA Considerations
This document defines the "dSIP" token as an ident-info-extension to
the Identity-Info header.
9. Acknowledgments
A team of people have worked on the various drafts related to the
dSIP protocol and extensions thereof. The team consists of: David
Bryan, Eric Cooper, James Deverick, Cullen Jennings, Bruce Lowekamp,
Philip Matthews, and Marcia Zangrilli.
Thanks to all who have been actively participating in the P2PSIP
efforts. Special thanks to Spencer Dawkins, Enrico Marocco, and
Jean-Francois Wauthy for providing editorial feedback, and Henry
Sinnreich, Eric Rescorla, and Alan Johnston for various discussions
related to this work.
10. References
10.1. Normative References
[I-D.bryan-p2psip-dsip]
Bryan, D., Lowekamp, B., and C. Jennings, "dSIP: A P2P
Approach to SIP Registration and Resource Location",
Internet Draft draft-bryan-p2psip-dsip-00, February 2007.
[I-D.ietf-sip-certs]
Jennings, C., "Certificate Management Service for The
Session Initiation Protocol (SIP)",
draft-ietf-sip-certs-02 (work in progress), October 2006.
[I-D.willis-p2psip-concepts]
Willis, D., "Concepts and Terminology for Peer to Peer
SIP", draft-willis-p2psip-concepts-03 (work in progress),
October 2006.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Lowekamp & Deverick Expires August 29, 2007 [Page 15]
Internet-Draft dSIP Identity February 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.
[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
[Sybil] Douceur, J., "The Sybil Attack", March 2002.
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 August 29, 2007 [Page 16]
Internet-Draft dSIP Identity February 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 August 29, 2007 [Page 17]