With the current definition of the protocol, split routing IDs and
user IDs can be achieved by having the host node participate as a peer
(or as a client, honestly) using its own cert and the attached users
represented as virtual clients, i.e. generate messages as if they are
on separate nodes attached to the host node as a client.
If you wanted to implement it "natively," other than the
USER-NODE-MATCH, as mentioned before, I can only find two changes that
would need to be made to support split identities.
For processing StoreReq:
o For original (non-replica) stores, the StoreReq is signed by a
credential which is authorized to write this kind at this
Resource-Id. If this check fails, the request MUST be rejected
with an Error_Forbidden error.
and the definition of credential in beginning of 10.3.
Assuming that there is not something I'm missing with using virtual
clients, I'd rather not make any changes. This is a complicated
enough protocol, and I think adding special cases for something like
split identities just makes it more complicated. If any changes were
made, I would think it should be something to make it possible for an
extension to specify the change, but as long as the current protocol
is capable of handling the functional goals, I'd rather no changes be
made.
Bruce
On Sat, Jul 2, 2011 at 1:04 PM, Marc Petit-Huguenin <[email protected]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 07/02/2011 09:28 AM, Diego Suarez wrote:
>> Hi,
>>
>>>From my point of view, in this case the user has to both prove she is in
>> possession of the PKC that includes the required username and also prove
>> she is operating from the required node. However, modifying the
>> SignerIdentity to include multiple identities ( the user and the
>> device ) would not really prove that since only one signature could be
>> included (either the user's signature or the device's one).
>>
>> Therefore, I'd modify the SecurityBlock instead to allow the inclusion
>> of more than only one signature.
>>
>> For this case, the securityBlock would include two signatures. One with
>> the SignerIdentity of the user and the signature of the user's PKC
>> (including the username ) and another with the SignerIdentity of the
>> device and the signature of the device's PKC ( including the nodeID).
>
> Right, something like this:
>
> struct {
> GenericCertificate certificates<0..2^16-1>;
> Signature signatures<0..2^16-1>;
> } SecurityBlock;
>
> Note that StoredData also needs to be modified:
>
> struct {
> uint32 length;
> uint64 storage_time;
> uint32 lifetime;
> StoredDataValue value;
> Signature signatures<0..2^16-1>;
> } StoredData;
>
>>
>> cheers
>>
>>
>> On Fri, 2011-07-01 at 15:44 -0700, Marc Petit-Huguenin wrote:
>> Hi Diego,
>>
>> How does this work with an access control policy like USER-NODE-MATCH, which
>> requires both a Node-ID and a username in the SignerIdentity? If the Node-ID
>> and the username are in separate certificates, wouldn't that require to
>> extend
>> the SignerIdentity structure to store multiple identities?
>>
>> Thanks.
>>
>> 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. 879 889, 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.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> David (as chair)
>
> - --
> Marc Petit-Huguenin
> Personal email: [email protected]
> Professional email: [email protected]
> Blog: http://blog.marc.petit-huguenin.org
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iEYEARECAAYFAk4PT4sACgkQ9RoMZyVa61dPvACeITly6/Zqumz4e4ZrAn1yGI4x
> ay4AoJ11vmCRDkL8pXuN71qaZXhw5JTZ
> =Tp+D
> -----END PGP SIGNATURE-----
> _______________________________________________
> P2PSIP mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/p2psip
>
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
