Re: [P2PSIP] Identity certificate segregation [was Re: draft-ietf-p2psip-base publication to be requested]

Marc Petit-Huguenin <petithug@acm.org> Thu, 07 July 2011 23:17 UTC

Return-Path: <petithug@acm.org>
X-Original-To: p2psip@ietfa.amsl.com
Delivered-To: p2psip@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0170D21F8854 for <p2psip@ietfa.amsl.com>; Thu, 7 Jul 2011 16:17:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.479
X-Spam-Level:
X-Spam-Status: No, score=-102.479 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bF-7el1Zjl52 for <p2psip@ietfa.amsl.com>; Thu, 7 Jul 2011 16:17:26 -0700 (PDT)
Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id E8CFC21F8853 for <p2psip@ietf.org>; Thu, 7 Jul 2011 16:17:25 -0700 (PDT)
Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) by implementers.org (Postfix) with ESMTPS id 5BBCB2199E; Fri, 8 Jul 2011 01:16:17 +0200 (CEST)
Message-ID: <4E163E7F.1000209@acm.org>
Date: Thu, 07 Jul 2011 16:17:19 -0700
From: Marc Petit-Huguenin <petithug@acm.org>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110626 Iceowl/1.0b2 Icedove/3.1.11
MIME-Version: 1.0
To: Cullen Jennings <fluffy@cisco.com>
References: <BANLkTikuy8qpZ42Zod1YK2+iYv1ib6=Yag@mail.gmail.com> <1307629878.30919.87.camel@toedo> <4DF0FD49.3020505@acm.org> <1307641649.5184.17.camel@santeles> <4E00F7CE.7080402@acm.org> <4E0DB3EC.1040705@ericsson.com> <B3E5E380-1759-4B9A-9556-CEC4E6383D59@cisco.com>
In-Reply-To: <B3E5E380-1759-4B9A-9556-CEC4E6383D59@cisco.com>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Cc: P2PSIP WG <p2psip@ietf.org>
Subject: Re: [P2PSIP] Identity certificate segregation [was Re: draft-ietf-p2psip-base publication to be requested]
X-BeenThere: p2psip@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Peer-to-Peer SIP working group discussion list <p2psip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/p2psip>, <mailto:p2psip-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/p2psip>
List-Post: <mailto:p2psip@ietf.org>
List-Help: <mailto:p2psip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Jul 2011 23:17:27 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/07/2011 03:34 PM, Cullen Jennings wrote:
> 
> This would break all the current deployments and implementation and not just
> in a way where some new software would need to be pushed out - all new
> certificates would need to be issues. From my point of view, this is too late
> for this change and instead it could be addressed with an extension.

I agree that it is probably too late, but I am concerned that this modification
is not really possible in an extension, but instead requires a new version of
the protocol because it needs two signatures in SecureBlock and StoredData.

> 
> On Jul 1, 2011, at 5:47 AM, Gonzalo Camarillo wrote:
> 
>> Hi,
>> 
>> please, let me know whether or not these modifications will be included in
>> the base draft at this point.
>> 
>> Thanks,
>> 
>> Gonzalo
>> 
>> On 21/06/2011 10:58 PM, Marc Petit-Huguenin wrote:
>>> I read the paper and this modification makes sense to me (for example
>>> without this modification a peer that is purely used for routing and
>>> storage purpose, like a bootstrap peer, had to invent a valid, unique,
>>> and useless username just to acquire a certificate).
>>> 
>>> So I support its inclusion in draft-ietf-p2psip-base.
>>> 
>>> On 06/09/2011 10:47 AM, Diego Suarez wrote:
>>>> I think it would require a (slight) modification in the base document. 
>>>> Current P2PSIP certification model is based on a single PKC (including 
>>>> both usernames and nodeIDs) that uniquely identifies a user and her 
>>>> devices. On the other hand, our model is base on a split
>>>> certification. Devices and users are independent. Each device has its
>>>> own PKC including a nodeID and a PK. Similarly, each user has her own
>>>> PKC including her username and a PK. This approach do not prevent a
>>>> centralized entity (such as an offline CA) to have information related
>>>> to the devices each user (or company, etc.) has registered, but
>>>> permits, among other improvements, a user to be connected to the system
>>>> through devices she has not registered herself such as a phone issued
>>>> by a telco or a fixed phone in a laboratory shared by all the members
>>>> of a research group.
>>> 
>>> 
>>>> On Thu, 2011-06-09 at 10:05 -0700, Marc Petit-Huguenin wrote: Does this
>>>> model really required modifications in the base document, or can it be 
>>>> designed as an extension?  (Unfortunately the paper is not freely
>>>> available, so it is difficult to know really what is needed for this).
>>> 
>>>> On 06/09/2011 07:31 AM, Diego Suarez wrote:
>>>>>>> Hi,
>>>>>>> 
>>>>>>> I had in mind writing a draft about this, but since I'm running
>>>>>>> out of time, I would like to summarize a new certification model
>>>>>>> for P2PSIP I have been working on, in case it is of interest for
>>>>>>> the group. Further details can be found in paper:
>>>>>>> 
>>>>>>> D. Touceda, J. Camara, L. Villalba, and J. Marquez, Advantages
>>>>>>> of identity certificate segregation in P2PSIP systems,
>>>>>>> Communications, IET, vol. 5, pp. 879889, Apr. 2011.
>>>>>>> 
>>>>>>> 
>>>>>>> The idea is to split the certification of users and devices.
>>>>>>> Devices are identified by PKCs including a nodeID and the PK of
>>>>>>> the device, while users are identified by PKCs including a
>>>>>>> username and the PK of the user. Similar models have been used
>>>>>>> before in other communications systems, such as GSM where devices
>>>>>>> and users are separately represented by the international mobile
>>>>>>> equipment identity (IMEI) stored in the phones and the
>>>>>>> international mobile subscriber identity (IMSI) stored in the
>>>>>>> user subscriber identity module (SIM), respectively.
>>>>>>> 
>>>>>>> Motivations of this model are:
>>>>>>> 
>>>>>>> - Users and devices are different entities performing different 
>>>>>>> roles within a P2PSIP system. Devices are nodes of the P2P 
>>>>>>> overlay network (represented by a nodeID) that offer services (to
>>>>>>> route messages, to store data, . . .) to the system, while users
>>>>>>> (represented by an username) utilize these services, usually to
>>>>>>> establish media communications using SIP.
>>>>>>> 
>>>>>>> - Support for mobility scenarios where a user may be logged at
>>>>>>> different devices at the same time using the same PKC.
>>>>>>> 
>>>>>>> - Support several users to be logged in the same device (like a
>>>>>>> fixed phone) at the same time.
>>>>>>> 
>>>>>>> - Support for user independent hard-coded devices.
>>>>>>> 
>>>>>>> - Interoperability with SIP. SIP certificates are not valid in
>>>>>>> actual P2PSIP since they don't include a nodeID.
>>>>>>> 
>>>>>>> cheers
>>>>>>> 
>>>>>>> Diego Suárez
>>>>>>> 
>>>>>>> 
>>>>>>> On Wed, 2011-06-08 at 09:48 -0700, David A. Bryan wrote:
>>>>>>>> Unless something major comes up, we plan to request the newest
>>>>>>>> version of the base draft, draft-ietf-p2psip-base-15, be
>>>>>>>> published. I'll put in the request in a week (June 16th or
>>>>>>>> 17th). If there are any further comments from the last call a
>>>>>>>> while ago (or further comments on the comments since then),
>>>>>>>> please send them to the list ASAP.

- -- 
Marc Petit-Huguenin
Personal email: marc@petit-huguenin.org
Professional email: petithug@acm.org
Blog: http://blog.marc.petit-huguenin.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk4WPn0ACgkQ9RoMZyVa61eLNQCgi614Bs6sdoajQ+ASRC/36JWk
5y8An1wyr5TbRVqZ6VTCEnfUfz0GIKud
=viZ4
-----END PGP SIGNATURE-----