Subject: WG Review: Peer-to-Peer Session Initiation Protocol (p2psip)

From: IESG Secretary <[email-masked]>
Date: Mon, 15 Jan 2007 18:50:01 -0500

A new IETF working group has been proposed in the Real-time Applications
and Infrastructure Area Area. The IESG has not made any determination as 
yet. The following draft charter was submitted, and is provided for 
informational purposes only. Please send your comments to the IESG 
mailing list ([email-masked]) by January 22nd.

+++

Peer-to-Peer Session Initiation Protocol (p2psip)
=================================================

Current Status: Proposed Working Group

Chairs: TBD

RAI Area Director(s): Cullen Jennings and Jon Peterson

RAI Area Advisor: Cullen Jennings

Mailing Lists: General Discussion: [email-masked]
Subscribe at: http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip
Archive at: http://lists.cs.columbia.edu/pipermail/p2p-sip/
(Note: mailing list will be moving to ietf)

Description of the Working Group:

The Peer-to-Peer (P2P) Session Initiation Protocol working group
(P2PSIP WG) is chartered to develop protocols and mechanisms for the
use of the Session Initiation Protocol (SIP) in settings where the
service of establishing and managing sessions is principally handled
by a collection of intelligent endpoints, rather than centralized
servers as in SIP as currently deployed. A number of cases where such
an architecture is desirable have been documented.

The work focuses on collections of nodes called "P2PSIP peers" and
"P2PSIP clients". P2PSIP peers manifest a distributFrom [email-masked] Mon Jan 15 18:56:53 2007
To: [email-masked]
From: IESG Secretary <[email-masked]>
Date: Mon, 15 Jan 2007 18:50:01 -0500
Cc: [email-masked]
Subject: WG Review: Provisioning of Symmetric Keys (keyprov) 
Reply-To: [email-masked]

A new IETF working group has been proposed in the Security Area.  
The IESG has not made any determination as yet. The following draft 
charter was submitted, and is provided for informational purposes only.  
Please send your comments to the IESG mailing list ([email-masked]) by 
January 22nd.

+++

Provisioning of Symmetric Keys (keyprov)
=========================================

Current Status: Proposed Working Group

Chair(s):
TBD

Security Area Director(s):
Russ Housley <[email-masked]>
Sam Hartman <[email-masked]>

Security Area Advisor:
Russ Housley <[email-masked]>

Mailing Lists:
General Discussion: [email-masked]
To Subscribe: http://www.safehaus.org/mailman/listinfo/ietf-keyprov
Archive: http://www.safehaus.org/pipermail/ietf-keyprov/

Background
----------

Current developments in deployment of Shared Symmetric Key (SSK) 
tokens have highlighted the need for a standard protocol for 
provisioning symmetric keys.

The need for provisioning protocols in PKI architectures has been 
recognized for some time. Although the existence and architecture of 
these protocols provides a feasibility proof for the KEYPROV work 
assumptions built into these protocols mean that it is not possible 
to apply them to symmetric key architectures without substantial
modification.

In particular the ability to provision symmetric keys and associated 
attributes dynamically to already issued devices such as cell phones 
and USB drives is highly desirable. The working group will develop 
the necessary protocols and data formats required to support 
provisioning and management of symmetric key authentication tokens, 
both proprietary and standards based.

Input Documents
---------------

The following Internet drafts have been proposed by their authors as 
input documents:

* Dynamic Symmetric Key Provisioning Protocol (M. Pei, S. Machani)
* Portable Symmetric Key Container (A. Vassilev, J. Martinsson, M. 
Pei, P. Hoyer, S. Machani)
* Extensions to CT-KIP to support one- and two-pass key 
initialization (M. Nystroem, S. Machani)

Scope and Deliverables
----------------------

The scope of the working group shall be to define protocols and data 
formats necessary for provisioning of symmetric cryptographic keys 
and associated attributes.

The group shall consided namespace in
which overlay users are identified and provides mechanisms for
locating users or resources within the P2PSIP overlay. P2PSIP clients
differ from P2PSIP peers primarily in that they do not store
information in the overlay, but only use it to locate users and
resources. P2PSIP clients and peers use the resolution services of the
peers as an alternative to the SIP discovery process of RFC 3263. In
this way, P2PSIP offers an alternative mechanism for determining the
correct destination for SIP requests. The working group's initial
charter scope will be to produce protocols to enable this alternate
mechanism for RFC 3263 functionality. Session management, messaging,
and presence functions are performed using conventional SIP.

This group's primary tasks are to produce:

1. An overview document explaining concepts, terminology, rationale,
and illustrative use cases for the remaining work.
2. A proposed standard defining a P2PSIP Peer Protocol. This protocol
is used between P2PSIP overlay peers, some of which may be behind
NATs. This protocol will define how the P2PSIP peers collectively
provide for user and resource location in a SIP environment with no
or minimal centralized servers. This protocol may or may not be
syntactically based on SIP, a decision to be made by the WG. The
group will identify and require one base P2P algorithm (likely a
particular Distributed Hash Table (DHT) algorithm), while allowing
for additional optional algorithms in the future.

3. Optionally, a proposed standard defining a P2PSIP Client Protocol
for use by P2PSIP clients, some of which may be behind NATs. This
protocol will define how the P2PSIP clients query and/or modify,
the resource location information of the overlay. While clearly a
logical subset of the P2PSIP Protocol, the WG will determine if the
P2PSIP Client Protocol is a syntactic subset of the P2PSIP Peer
Protocol, and whether the P2PSIP Client Protocol builds on the SIP
protocol.

4. A usage document. This document will address how the protocols
defined above, along with existing IETF protocols, can be used to
produce systems to locate a P2PSIP peer or client, identify
appropriate resources to facilitate communications (for example
media relays), and establish communications between the users of
these P2PSIP peers or clients, without relying on centralized
servers. Additionally, the document will explain how P2PSIP and
conventional SIP entities can interoperate.

The initial work will assume the existence of some enrollment process
that provides a unique user name, credentials, and an initial set of
bootstrap nodes if that is required by the protocols. Developing a
non-centralized enrollment process is not in scope.

The work planned for the P2PSIP working group is distinct from, but
requires close participation with other IETF WGs, particularly SIP,
SIPPING, SIMPLE, BEHAVE and MMUSIC. The group cannot modify the
baseline SIP behavior, define a new version of SIP, or attempt to
produce a parallel protocol for session establishment. If the group
determines that any capabilities requiring an extension to SIP are
needed, the group will seek to define such extensions within the SIP
working group using the SIP change process (RFC 3427). Similarly,
existing tools developed in the BEHAVE and MMUSIC groups will be used
for NAT traversal, with extensions or changes desired to support
P2PSIP presented to the BEHAVE or MMUSIC working groups.

The working group will assume that NATs and firewalls exist in the
Internet, and will ensure that the protocols produced work in their
presence as much as possible. "Similarly, the WG will avoid making
protocol design decisions that would preclude the creation of
anonymous communications systems using techniques such as onion
routing to conceal the IP addresses of P2PSIP peers.

The following topics are excluded from the Working Group's scope:

1. Issues specific to applications other than locating users and
resources for SIP-based communications and presence.

2. Solving "research" type questions related to P2PSIP or P2P in
general. The er use cases related to use of Shared Symmetric 
Key Tokens. Other use cases may be considered for the purpose of 
avoiding unnecessary restrictions in the design and ensure the 
potential for future extensibility.

The working group will produce the following deliverables:

* Portable Symmetric Key Container
* Dynamic Symmetric Key Provisioning Protocol

Milestones
----------

June 2007 WG Last Call Portable Symmetric Key Container
June 2007 WG Last Call Dynamic Symmetric Key Provisioning Protocol
August 2007 IETF Last Call Portable Symmetric Key Container
August 2007 IETF Last Call Dynamic Symmetric Key Provisioning Protocol
Jan 2008 Complete implementation and interoperability tests
June 2008 WG documents to DRAFT Standard Status

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf-announce