Hi, Actually, I see this "virtual client" method more complicated and confusing than splitting the identities of users and devices.
With this model, you are gonna have a device identified by a PKC that includes a username and a nodeID acting as a peer, but only using its nodeID. And several users connected to the device as virtual clients identified by PKCs including a username and a nodeID, but only using their usernames. One of the more confusing things I see here is the access control. Imagine we have a device, with PKC ( # user = device1, nodeID = 100 # ) and two users ( # user = user1, nodeID = 200 # and # user = user2, nodeID = 300 # ) connected to that device acting as virtual clients. If user1 wants to perform a USER-NODE-MATCH access control related to the peer she is operating from ( actually the nodeID = 100 nor the virtual one with nodeID = 200 ) and her username ( user = user1 ), she is gonna have to create a request signed with her PKC and the PKC of the device. This request need to be doubled signed ( by the peer to grant the nodeID = 100 and by the user to grant the user = user 1 ). However, this double signed request intended for nodeID = 100 and user = user1 is gonna include two users = device1 and user1 and two nodeID = 100 and 200. This is confusing for me. Therefore, from my point of view, it makes sense to me to remove the username from the device and the node from the users since we are not using them and confuse the access control. Also, splitting identities have another advantages like greater interoperability with traditional SIP systems. Imagine a company running a SIP system, where users are identified by a PKC including a SIP username, that wants to extend its coverage interconnecting it with a P2PSIP system. With the actual certification model, SIP PKCs are not valid for the new P2PSIP side of the system. All the users have to be re-certificated to have a PKC including the old SIP username and a nodeID. However, with the split proposal SIP certificates are still valid in the P2PSIP side of the system and interoperable within the two networks, and only the devices intended to be used in the P2PSIP side have to be certified with a nodeID. cheers On Sat, 2011-07-02 at 16:53 -0400, Bruce Lowekamp wrote: > 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
