Archive for the ‘Papers’ Category
“Managing Client Initiated Connections in the Session Initiation Protocol (SIP)”, C. Jennings, R. Mahy, October 2005, draft-ietf-sip-outbound-01
- Abstract: Session Initiation Protocol (SIP) allows proxy servers to initiate TCP connections and send asynchronous UDP datagrams to User Agents in order to deliver requests. However, many practical considerations, such as the existence of firewalls and NATs, prevent servers from connecting to User Agents in this way. Even when a proxy server can open a TCP connection to a User Agent, most User Agents lack a certificate suitable to act as a TLS server. This specification defines behaviors for User Agents, registrars and proxy servers that allow requests to be delivered on existing connections established by the User Agent. It also defines keep alive behaviors needed to keep NAT bindings open and specifies the usage of multiple connections for high availability systems.
“Payment for Services in Session Initiation Protocol (SIP)”, C. Jennings, G. Jun, J. Fischl, H. Tschofenig, October 2005, draft-jennings-sipping-pay-03.txt
- Abstract: Service usage might require some form of compensation and this is also true for many communication systems where an entity receiving a call should be able to charge the caller. This is necessary for allowing fair communication between two communicating parties and is a major strategy for reducing the viability of SPAM. This draft proposes an approach for doing this in SIP using the Security Assertion Markup Language (SAML). It relies on a third party to act as a payment provider and is designed for low value transactions. It does not aim to provide the same capability as other authentication, authorization and accounting systems. This draft is in a fairly early state and has many details that are missing. Earlier versions of this document did not use SAML. This version offers a sketch of what the SAML based solution would look like but still lacks many details that would be needed for an actual implementation.
“Remote Call Control in SIP using the REFER method and the session-oriented dialog package”, R. Mahy, C. Jennings, Oct 2005, draft-mahy-sip-remote-cc-02
- Abstract: This document describes how to use the SIP REFER method and the dialog package to manipulate conversations, dialogs, and sessions on remote User Agents. Specifically it extents the REFER mechinims to allow the specificate of a response that a UA should send in a dialog. This functionality is most useful for collections of loosely coupled User Agents that wish to present a coordinated user experience. It does not require a Third-Party Call Control controller to be involved in any of the manipulated dialogs.
“Computational Puzzles for SPAM Reduction in SIP”, C. Jennings, October 2005, draft-jennings-sip-hashcash-03
Abstract: One of the techniques used in SPAM prevention and various solutions for denial of service attacks is to force the SIP client requesting a service to perform a calculation that limits the rate and increases the cost of the request. This draft defines a way to allow a UAS to ask the UAC to compute a computationally expensive hash based function and present the result to the UAS. Although the computation is expensive for the UAC to compute, it is cheap for the UAS to verify. The solution also allows for proxies to compute and check the puzzle on behalf of the UAC or UAS.
“The Internet Assigned Number Authority (IANA) tel Uniform Resource Identifier (URI) Parameter Registry”, C. Jennings, October 2005, draft-jennings-iptel-tel-reg-00
- Abstract: This document creates an Internet Assigned Number Authority (IANA) registry for the tel Uniform Resource Identifier (URI) parameters, and their values. It also lists the already existing parameters to be used as initial values for that registry.
? “NAT Behavioral Requirements for Unicast
UDP”, F. Audet, C. Jennings, July 2005,
UDP”, F. Audet, C. Jennings, July 2005,
?
Abstract: This document defines basic terminology for describing different
types of NAT behavior when handling Unicast UDP and also defines a set of
requirements that would allow many applications, such as multimedia
communications or on-line gaming, to work consistently. Developing NATs that
meet this set of requirements will greatly increase the likelihood that these
applications will function properly.
Abstract: This document defines basic terminology for describing different
types of NAT behavior when handling Unicast UDP and also defines a set of
requirements that would allow many applications, such as multimedia
communications or on-line gaming, to work consistently. Developing NATs that
meet this set of requirements will greatly increase the likelihood that these
applications will function properly.
? “A P2P Approach to SIP Registration and
Resource Location”, D. A. Bryan, C. Jennings, July 2005,
Resource Location”, D. A. Bryan, C. Jennings, July 2005,
?
Abstract: This document outlines the motivation and requirements for a
Peer-to-Peer (P2P) based approach for SIP registration and resource discovery
using distributed hash tables, and presents the architectural design for such a
system. This design removes the need for central servers from SIP, while
offering full backward compatibility with SIP, allowing reuse of existing
clients, and allowing P2P enabled nodes to communicate with conventional SIP
entities. A basic introduction to the concepts of P2P is presented, backward
compatibility issues addressed, and the security considerations are considered.
This is very early work to explore the characteristics that a P2P system might
have. It is less secure in many ways than the traditional approach to SIP but
has certain other interesting characteristics that may make it desirable in some
situations. This work is being discussed on the sipping@ietf.org mailing
list.
Abstract: This document outlines the motivation and requirements for a
Peer-to-Peer (P2P) based approach for SIP registration and resource discovery
using distributed hash tables, and presents the architectural design for such a
system. This design removes the need for central servers from SIP, while
offering full backward compatibility with SIP, allowing reuse of existing
clients, and allowing P2P enabled nodes to communicate with conventional SIP
entities. A basic introduction to the concepts of P2P is presented, backward
compatibility issues addressed, and the security considerations are considered.
This is very early work to explore the characteristics that a P2P system might
have. It is less secure in many ways than the traditional approach to SIP but
has certain other interesting characteristics that may make it desirable in some
situations. This work is being discussed on the sipping@ietf.org mailing
list.
? “The Message Session Relay Protocol”, B.
Campbell, R. Mahy, C. Jennings, July 2005,
Campbell, R. Mahy, C. Jennings, July 2005,
?
Abstract: This document describes the Message Session Relay Protocol, a
protocol for transmitting a series of related instant messages in the context of
a session. Message sessions are treated like any other media stream when setup
via a rendezvous or session setup protocol such as the Session Initiation
Protocol.
Abstract: This document describes the Message Session Relay Protocol, a
protocol for transmitting a series of related instant messages in the context of
a session. Message sessions are treated like any other media stream when setup
via a rendezvous or session setup protocol such as the Session Initiation
Protocol.
? “Relay Extensions for the Message
Sessions Relay Protocol (MSRP)”, C. Jennings, R. Mahy, A. B. Roach, July 2005,
Sessions Relay Protocol (MSRP)”, C. Jennings, R. Mahy, A. B. Roach, July 2005,
?
Abstract: The SIMPLE Working Group uses two separate models for conveying
instant messages. Pager-mode messages stand alone and are not part of a SIP
(Session Initiation Protocol) session, whereas Session-mode messages are set up
as part of a session using the SIP protocol. MSRP (Message Sessions Relay
Protocol) is a protocol for near-real-time, peer-to-peer exchanges of binary
content without intermediaries, which is designed to be signaled using a
separate rendezvous protocol such as SIP. This document introduces the notion of
message relay intermediaries to MSRP and describes the extensions necessary to
use them.
Abstract: The SIMPLE Working Group uses two separate models for conveying
instant messages. Pager-mode messages stand alone and are not part of a SIP
(Session Initiation Protocol) session, whereas Session-mode messages are set up
as part of a session using the SIP protocol. MSRP (Message Sessions Relay
Protocol) is a protocol for near-real-time, peer-to-peer exchanges of binary
content without intermediaries, which is designed to be signaled using a
separate rendezvous protocol such as SIP. This document introduces the notion of
message relay intermediaries to MSRP and describes the extensions necessary to
use them.
? “Response Identity and Authentication in
Session Initiation Protocol”, F. Cao, C. Jennings, July 2005,
Session Initiation Protocol”, F. Cao, C. Jennings, July 2005,
?
Abstract: This draft describes some extensions for verifying SIP response
identity and enhancing SIP response authentication. Some mechanisms are
demonstrated for providing and verifying the identity of SIP responses. In order
to prevent several kinds of security attacks through SIP response, SIP response
authentication should be provided through a chain of trust of the SIP responses.
Some extensions are proposed to enhance the per-hop authentication for handling
SIP response. This draft is an early work in progress and suggests some
approaches but there is still significant discussion needed. Some of the attacks
discussed in this draft can be mitigated by using the sips URL.
Abstract: This draft describes some extensions for verifying SIP response
identity and enhancing SIP response authentication. Some mechanisms are
demonstrated for providing and verifying the identity of SIP responses. In order
to prevent several kinds of security attacks through SIP response, SIP response
authentication should be provided through a chain of trust of the SIP responses.
Some extensions are proposed to enhance the per-hop authentication for handling
SIP response. This draft is an early work in progress and suggests some
approaches but there is still significant discussion needed. Some of the attacks
discussed in this draft can be mitigated by using the sips URL.
? “Managing Client Initiated Connections
in the Session Initiation Protocol (SIP)”, C. Jennings, R. Mahy, July 2005,
in the Session Initiation Protocol (SIP)”, C. Jennings, R. Mahy, July 2005,
?
Abstract: Session Initiation Protocol (SIP) allows proxy servers to initiate
TCP connections and send asynchronous UDP datagrams to User Agents in order to
deliver requests. However, many practical considerations, such as the existence
of firewalls and NATs, prevent servers from connecting to User Agents in this
way. Even when a proxy server can open a TCP connection to a User Agent, most
User Agents lack a certificate suitable to act as a TLS server. This
specification defines behaviors for user agents, registrars and proxy servers
that allow requests to be delivered on existing connections established by the
User Agent. It also defines keep alive behaviors needed to keep NAT bindings
open and specifies the usage of multiple connections for high availability
systems.
Abstract: Session Initiation Protocol (SIP) allows proxy servers to initiate
TCP connections and send asynchronous UDP datagrams to User Agents in order to
deliver requests. However, many practical considerations, such as the existence
of firewalls and NATs, prevent servers from connecting to User Agents in this
way. Even when a proxy server can open a TCP connection to a User Agent, most
User Agents lack a certificate suitable to act as a TLS server. This
specification defines behaviors for user agents, registrars and proxy servers
that allow requests to be delivered on existing connections established by the
User Agent. It also defines keep alive behaviors needed to keep NAT bindings
open and specifies the usage of multiple connections for high availability
systems.
? “Certificate Management Service for The
Session Initiation Protocol (SIP)”, C. Jennings, J. Peterson, July 2005,
Session Initiation Protocol (SIP)”, C. Jennings, J. Peterson, July 2005,
?
Abstract: This draft defines a Credential Service that allows SIP User Agents
to use a SIP package to discover the certificates of other users. This mechanism
allows user agents that want to contact a given Address-of-Record (AOR) to
retrieve that AOR’s certificate by subscribing to the Credential Service. The
Credential Service also allows users to store and retrieve their own
certificates and private keys.
Abstract: This draft defines a Credential Service that allows SIP User Agents
to use a SIP package to discover the certificates of other users. This mechanism
allows user agents that want to contact a given Address-of-Record (AOR) to
retrieve that AOR’s certificate by subscribing to the Credential Service. The
Credential Service also allows users to store and retrieve their own
certificates and private keys.
? “NAT Classification Test Results”, C.
Jennings, July 2005,
Jennings, July 2005,
?
Abstract: IETF has several groups that are considering the impact of NATs on
various protocols. Having a classification of the types of NATs that are being
developed and deployed is useful in gauging the impact of various solutions.
This draft records the results of classifying NATs. This draft is not complete
and has only a few test results but it is worth discussing all the testing we
wish to do before all the test results are collected. The test results here are
very old and work is being done to update them with more current information.
This work is being discussed on the ietf-behave@list.sipfoundry.org mailing
list
Abstract: IETF has several groups that are considering the impact of NATs on
various protocols. Having a classification of the types of NATs that are being
developed and deployed is useful in gauging the impact of various solutions.
This draft records the results of classifying NATs. This draft is not complete
and has only a few test results but it is worth discussing all the testing we
wish to do before all the test results are collected. The test results here are
very old and work is being done to update them with more current information.
This work is being discussed on the ietf-behave@list.sipfoundry.org mailing
list
? “vCard Extensions for Instant Messaging
(IM)”, C. Jennings, July 2005,
(IM)”, C. Jennings, July 2005,
?
Abstract: This document describes an extension to vCard to support Instant
Messaging (IM) and Presence Protocol (PP) applications. IM and PP are becoming
increasingly common ways of communicating, and users want to save this contact
information in their address books. This draft allows a URI that is associated
with IM or PP to be specified inside of a vCard.
Abstract: This document describes an extension to vCard to support Instant
Messaging (IM) and Presence Protocol (PP) applications. IM and PP are becoming
increasingly common ways of communicating, and users want to save this contact
information in their address books. This draft allows a URI that is associated
with IM or PP to be specified inside of a vCard.
? “Using DTLS as a Transport for SIP”, C.
Jennings, N. Modadugu, July 2005,
Jennings, N. Modadugu, July 2005,
?
Abstract: This draft specifies how to use Datagram Transport Layer Security
(DTLS) as a transport for SIP. DTLS is a new protocol for providing TLS security
over a datagram protocol. This draft is being discussed on the sip@ietf.org
mailing list.
Abstract: This draft specifies how to use Datagram Transport Layer Security
(DTLS) as a transport for SIP. DTLS is a new protocol for providing TLS security
over a datagram protocol. This draft is being discussed on the sip@ietf.org
mailing list.
? “Computational Puzzles for SPAM
Reduction in SIP”, C. Jennings, July 2005,
Reduction in SIP”, C. Jennings, July 2005,
?
Abstract: One of the techniques used in SPAM prevention and various solutions
for denial of service attacks is to force the SIP client requesting a service to
perform a calculation that limits the rate and increases the cost of the
request. This draft defines a way to allow a UAS to ask the UAC to compute a
computationally expensive hash based function and present the result to the UAS.
Although the computation is expensive for the UAC to compute, it is cheap for
the UAS to verify. The solution also allows for proxies to compute and check the
puzzle on behalf of the UAC or UAS.
Abstract: One of the techniques used in SPAM prevention and various solutions
for denial of service attacks is to force the SIP client requesting a service to
perform a calculation that limits the rate and increases the cost of the
request. This draft defines a way to allow a UAS to ask the UAC to compute a
computationally expensive hash based function and present the result to the UAS.
Although the computation is expensive for the UAC to compute, it is cheap for
the UAS to verify. The solution also allows for proxies to compute and check the
puzzle on behalf of the UAC or UAS.
? “Example call flows using SIP security
mechanisms”, C. Jennings, K. Ono, July 2005,
mechanisms”, C. Jennings, K. Ono, July 2005,
?
Abstract: This document shows call flows demonstrating the use of SIPS, TLS,
and S/MIME in SIP. This draft provides information that helps implementers build
interoperable SIP software. It is purely informational. To help facilitate
interoperability testing, it includes certificates used in the example call
flows and a CA certificate to create certificates for testing. This work is
being discussed on the sip@ietf.org mailing list.
Abstract: This document shows call flows demonstrating the use of SIPS, TLS,
and S/MIME in SIP. This draft provides information that helps implementers build
interoperable SIP software. It is purely informational. To help facilitate
interoperability testing, it includes certificates used in the example call
flows and a CA certificate to create certificates for testing. This work is
being discussed on the sip@ietf.org mailing list.
? “Conventions for Voicemail URIs in SIP”,
C. Jennings, July 2005,
C. Jennings, July 2005,
?
Abstract: The SIP protocol is often used to initiate connections to voicemail
or unified messaging systems. This specification describes a convention for
forming SIP Service URIs that request particular services from unified messaging
systems.
Abstract: The SIP protocol is often used to initiate connections to voicemail
or unified messaging systems. This specification describes a convention for
forming SIP Service URIs that request particular services from unified messaging
systems.
? “Instance Identifiers for SIP User
Agents”, C. Jennings, July 2005,
Agents”, C. Jennings, July 2005,
?
Abstract: There are circumstances in SIP-based communications systems in which
it is useful to have a long-term, stable identifier for a particular user agent.
This specification outlines requirements and discusses existing standards that
can be used to satisfy this need.
Abstract: There are circumstances in SIP-based communications systems in which
it is useful to have a long-term, stable identifier for a particular user agent.
This specification outlines requirements and discusses existing standards that
can be used to satisfy this need.
? “SIP Offer/Answer with Multipart
Alternative”, C. Jennings, D. Wing, July 2005,
Alternative”, C. Jennings, D. Wing, July 2005,
?
Abstract: SIP needs a mechanism for general backwards compatibility for moving
from SDP to SDPng or moving from non end-to-end encrypted SDP to end-to-end
encrypted SDP. This document specifies how a SIP offer uses
multipart/alternative, and how an answer indicates which part was
selected.
Abstract: SIP needs a mechanism for general backwards compatibility for moving
from SDP to SDPng or moving from non end-to-end encrypted SDP to end-to-end
encrypted SDP. This document specifies how a SIP offer uses
multipart/alternative, and how an answer indicates which part was
selected.
? “Payment for Services in Session
Initiation Protocol (SIP)”, C. Jennings, G. Jun, J. Fischl, July 2005,
Initiation Protocol (SIP)”, C. Jennings, G. Jun, J. Fischl, July 2005,
?
Abstract: Communication systems require that a person receiving a call be able
able to charge the caller when they are from different administrative domains.
This is necessary for making fair exchanges of service between two different
communicating parties and is a major strategy for reducing the viability of
SPAM. This draft proposes an approach for doing this in SIP. The approach relies
on a third party to act as a payment service provider and is optimized for very
simple, low value transactions. It does not provide the full range of services
that are desirable in typical online trading systems. This draft is being
discussed on the sipping@ietf.org mailing list. There is currently work to
substantially change this draft to use SAML.
Abstract: Communication systems require that a person receiving a call be able
able to charge the caller when they are from different administrative domains.
This is necessary for making fair exchanges of service between two different
communicating parties and is a major strategy for reducing the viability of
SPAM. This draft proposes an approach for doing this in SIP. The approach relies
on a third party to act as a payment service provider and is optimized for very
simple, low value transactions. It does not provide the full range of services
that are desirable in typical online trading systems. This draft is being
discussed on the sipping@ietf.org mailing list. There is currently work to
substantially change this draft to use SAML.
? “Conference State Change Protocol
(CSCP)”, C. Jennings, A. B. Roach, July 2005,
(CSCP)”, C. Jennings, A. B. Roach, July 2005,
?
Abstract: Conference State Control Protocol (CSCP) is a means to modify the
state in a conference service. It extends the Binary Floor Control Protocol and
adds commands to get, set, add, and delete fields in the conference
state.
Abstract: Conference State Control Protocol (CSCP) is a means to modify the
state in a conference service. It extends the Binary Floor Control Protocol and
adds commands to get, set, add, and delete fields in the conference
state.
? “Media Conference Server Control for
XCON”, C. Jennings, B. Rosen, July 2005,
XCON”, C. Jennings, B. Rosen, July 2005,
?
Abstract: Conference servers have many controls that change how the media is
combined for the various conference participants. It is necessary to describe
these controls to the clients connected to a centralized conference, so that the
clients can render a user interface and allow the user to manipulate them. This
work is being discussed on the xcon@ietf.org mailing list. This draft has not
changed since the 02 version.
Abstract: Conference servers have many controls that change how the media is
combined for the various conference participants. It is necessary to describe
these controls to the clients connected to a centralized conference, so that the
clients can render a user interface and allow the user to manipulate them. This
work is being discussed on the xcon@ietf.org mailing list. This draft has not
changed since the 02 version.
I think some of the open source code written with security in mind has some of the best security around anywhere.
http://searchenterprisevoice.techtarget.com/qna/0,289202,sid66_gci1103827,00.html