Hi, I have the impression I am not explaining myself well. I am not saying that clients in RELOAD do not work well, I am just saying that I do not see how they can be used to allow several users to be connected to the same the device; at least not with full functionalities.
Lets go back to the example: 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. As you have said, during registration, users store a destination list that start with the device ( nodeID = 100 ) and finishes with the client's nodeID ( nodeID = 200 for user1 and nodeID = 300 for user2). This works well, and allows other peers of the system to reach them. However, the problem is with the access control. Being virtual clients, users can perform NODE-USER-MATCH accesses related to their client's nodeIDs and usernames: 200-user1 for user1 and 300-user2 for user2. Nevertheless, this is not what we want in this case. In this case, where user1 and user2 are supposed to be connected to the same device (nodeID = 100), they should be allowed to perform NODE-USER-MATCH accesses related to this device and their usernames: 100-user1 for user1 and 100-user2 for user2. Because, if not, we are not really implementing this functionality. In order to be fully implemented, several users connected to the same device should have the same functionalities that a single user connected to this device has, and this is not the case using virtual clients. cheers On Fri, 2011-07-08 at 09:40 -0400, Bruce Lowekamp wrote: > On Fri, Jul 8, 2011 at 7:15 AM, Diego Suarez <[email protected]> wrote: > > Hi Bruce, > > > > Answers inline. > > > > > > On Thu, 2011-07-07 at 22:24 -0400, Bruce Lowekamp wrote: > >> Diego, > >> > >> Please take some time understanding how real clients work in reload. > >> Then just have the virtual clients use the same messages. The virtual > >> clients use their own nodeids, not the host's nodeid. It all works > >> fine. > > > > I agree, this works fine for clients, but, from my point of view, it > > does not for several users connected to the same device. The fact that > > clients ( or virtual clients ) use their own nodeIDs and not the host's > > nodeIDs is precisely what I see as the problem of using virtual clients > > to allow several users to be connected to the same device. Since virtual > > clients are not using the device's nodeID, they cannot perform > > operations ( like NODE-MATCH or USER-NODE-MATCH accesses) from that > > device like they should if they were actually connected to the system > > from it. As I've said in my previous mail, they only way I see to allow > > so is the device adding an extra signature to the message, with the > > already commented problem of two users and two nodeIDs in it. > > > > Since a client is using its own nodeid, NODE-MATCH and USER-NODE-MATCH > are performed using the client's nodeid. In the case of the sip > usage, it's done using USER-NODE-MATCH. This is the client's > rfc822Name and the client's nodeid. In that registration, it stores a > destination list that starts with the peer and finishes with the > client's nodeid (in most cases, would be only these two entries). > This is how clients are supported in reload and for the sip usage. > > > > >> I don't see a real problem with a host node having an > >> "[email protected]" or "[email protected]" name attached to it. > >> Routers pretty much always have DNS names that are descriptive of > >> where they are to admins, even though routing protocols don't require > >> it. > > > > Neither do I except for cases, like the presented before, of several > > users in the same device. > > > >> > >> Regarding certs, 6072 has the following text: > >> > >> If the certificate is signed by a trusted certification authority, > >> and one of the names in the SubjectAltName matches the original URI, > >> then this certificate MAY be used, but only for exactly the original > >> > >> It's been awhile since I've looked at that in detail, but it appears > >> to me that a reload cert could be perfectly valid for use with 6072 as > >> long as it has the sip uri in it. Though I'm not immediately > >> convinced that this is that useful, regardless. > > > > The problem is not with RELOAD certs being used in SIP systems, but with > > SIP certs being used in RELOAD systems. Since SIP certs do not have > > nodeIDs, they are not valid in RELOAD. > > > > cheers > > > >> > >> Bruce > >> > >> > >> > >> On Mon, Jul 4, 2011 at 5:51 AM, Diego Suarez <[email protected]> wrote: > >> > 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
