First of all, I would like to introduce the motivation of the idea of split certification, since I think it is an important point in this discussion and would help to clarify why I think that virtual clients do not really allow several users to be connected from the same device. Also, it could help to clarify if I taking a false premise to support split certification when I should not.
As far as I understood, the idea of nodeIDs in RELOAD is to represent devices, despite usernames and nodeIDs are included in the same certificate. Draft says: "If a user has more than one device, typically they would get one certificate for each device. This allows each device to act as a separate peer." However, it also exist the possibility of having a single certificate with several nodeIDs. In this case, a user with two devices ( for example a mobile and a fixed phone ) would have a certificate with a username and two nodeIDs, one for each device; being able to be connected to network and contactable in both devices at the same time. Regarding the first alternative, there is something I have not clear: If a user has a different certificate for each device she has, would these certificates have the same username and different nodeIDs? and if so, would the PK be the same in all the certificates or a different PK in each one?; or would the user have a different username, a different nodeID and a different PK in each certificate?. Said this, if we want each device to have its own certificate, why don't make it simpler a split device's identity from the user's identity? The second alternative (several nodeIDs in a single cert) works well for me if the user if using the same devices all the time, for example a user with one cert with a nodeID for her mobile phone and another nodeID for her office fixed phone; but has some limitations. What happens if the user is out for one week in another office and wants to be connected from there ? The simple answer seems to be "use the nodeID she was using in the other office". But, is it not weird to bother in the first place to give a different nodeID to each user's device and now use the same nodeID for two different ones? Also, won't be useful to have each device identified by a unique nodeID within the network for security reasons or to have permanent statistics about its past behavior for network maintenance or routing purposes? With this in mind, it came to me the idea of a split certification. With split certification, users would be identified always by the same certificate independently of the device they are using (something that does not happen in the first alternative). Also, devices would be always identified by the same and unique cert (something that does not happen in the second). Besides, users could be connected to as many devices as they want without have to been re-certified to get more nodeIDs. I think this would simplify the certification of the system and improve its maintenance. Also, extra improvements come with this alternative, like greater interoperability with SIP ( as I've already commented in previous mails ) or the easy deployment of more secure networks formed by hard coded (including a certificate with a nodeID) devices. The comments to the other improvement I see of this alternative, related to several users connected to the same device, are inline. On Fri, 2011-07-08 at 19:06 -0400, Bruce Lowekamp wrote: > inline > > On Fri, Jul 8, 2011 at 12:53 PM, Diego Suarez <[email protected]> wrote: > > 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. > > why? It works as designed when they use their client nodeid. Well, I've said before, if the idea of RELOAD is to have each device be identified by a different nodeID, from my point of view two users operating from the same device should be using the same nodeID. Two users connected to the same device, using different nodeIDs, that also reuse later with another devices are not actually breaking the certification idea of 1device = 1nodeID? > In > fact, using the host's nodeid here gives the exact opposite behavior > of what you would want---if one of the multiple users switches to a > different device, they may wind up with a stale entry pointing to the > device they are no longer at, whereas if the user uses their own > certificate&nodeid, when they register their route to the new host the > old one is automatically removed because they're using the same client > nodeid. I think this would be a fail of the implementation not of the proposal and that can also happen with the actual model of RELOAD. Imagine a user with a cert (including a username and two nodeIDs ) connected to two different devices. If she disconnects from one of the devices but forgets to remove that entry point, she may also wind up with a stale entry pointing to a device she is no longer at. > > > Because, if not, we are not really implementing > > this functionality. > > what 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. > > could you clarify what you're referring to here? I don't know what > functionality I would expect multiple users signed into the same > device to have that wouldn't be provided using their own nodeids. > I would try to clarify what I mean with an example that presents three possible cases that can occur in RELOAD: case 1: User1 with cert ( user = user1, nodeID = 100 ) is connected to the network using a device. Therefore she can perform any access related to her user( USER-MATCH = user1 ), nodeID ( NODE-MATCH = 100 ) or the combination of both (USER-NODE-MATCH = user1-100). case 2: The same User1 with the same cert is connected to the network using the same device. But now, also User2 ( user = user2, nodeID = 200 ) and User3 ( user = user3, nodeID = 300 ) are connected to that device as virtual clients. User1 can perform the same kind of accesses than in case 1. User2 can perform accesses related her user( USER-MATCH = user2 ), virtual nodeID ( NODE-MATCH = 200 ) or the combination of both (USER-NODE-MATCH = user2-200). User3 is ( USER-MATCH = user3 ), virtual nodeID ( NODE-MATCH = 300 ) or the combination of both (USER-NODE-MATCH = user3-300). case 3: A "non-user" device ( user = lab1, nodeID = 100 ) is connected to the network. Two users, User2 and User3 (with the same credentials that in the previous case) are connected to that device. So, User2 and User3 can perform the same accesses than in case 3. In this three examples, taking a look a the accesses related to NODE, the important thing here, we see different cases of users presumably connected to the same device, that should have the same functionalities over that device but actually they have not. Precisely, User1 can perform accesses on behalf of the device, while user2 and user3 cannot. I would expect for all the cases the same rights for a user, either she has full control over the device ( to perform accesses like NODE-MATCH = 100 ) or she does not have any control at all over it. But not these different possibilities depending on how the user is connected to the device. This is what I wanted to mean with no having full functionalities. Furthermore, in case 2 we are forcing User1 to be connected to the network while User2 and User3 wish to continue using the device. It would be possible here that User1 entered in an ‘invisible mode’ by removing her contact information from the network. In such case, User1 seemed to be offline for the other users of the network (neither they could have the knowledge that she is online or access to her contact information) but she would be actually online since she could access to all the resources of the network, like her voicemail or the contact information of other users to initiate media calls. cheers > Bruce > > > > > > 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
