Sorry for replying to my own message. I meant to add this to the top... I think there's an interesting philosophical discussion of whether it would have been better to have split identities. My point in the previous reply is not that split identities wouldn't work, I just don't think there is anything they support that can't be done with the existing protocol. So I'm OK having a conversation about how they would work. But when you say you don't believe that clients (virtual or not) provide the same functionality, I have to disagree with that---the protocol was designed to support clients, and there is no problem with the functionality they receive that I am aware of.
I have mixed feelings about whether using split identities would be good or bad. So much the security of p2p algorithms depends on the inability of an attacker to chose a location within the overlay. It makes me a bit paranoid to decouple identity in that way---although I'm not sure that in practice managing pure node id certificates would be that much harder---in the end, you still need to identify what certificates are attacking the network. The biggest difference that I can see is that with split identities you would almost double the number of certificates on the wire/being stored. I think there would have to be a significant feature advantage to justify that, and right now I'm not seeing it. Bruce On Sat, Jul 16, 2011 at 9:27 PM, Bruce Lowekamp <[email protected]> wrote: > On Sat, Jul 9, 2011 at 1:25 PM, Diego Suarez <[email protected]> wrote: >> 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 only requirement is that no two nodes can be trying to use the > same nodeid at the same time. Otherwise, it doesn't make any > difference to the protocol if two physical devices use the same nodeid > at different times. The draft doesn't say much about managing this > because outside of this requirement, it's really up to the > implementation. > >> >> 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? > > I don't see that it would be that useful. It certainly doesn't give > you any additional security, since you can't enforce it at a protocol > level. If you're interested in logging information about hardware or > software configuration nodes are using, you can certainly do > that---and if you do that, you've solved the problem. > > >> >> 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. > > This can all be done with the existing protocol. And, as I said in my > earlier responses, I don't believe there are any interop issues with > SIP, I think a reload cert could be 6072 compatible, though I don't > claim to be an expert on that or to have tested it. > >> >> 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? > > The idea is at most one device on the overlay at any given time with > the same node id. The ability to act as a particular node id is > controlled by the certificate mechanism. No other assumptions. > > >> >> >>> 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. >> > > Exactly. If you use the same nodeid for that person, you don't need > to worry about stale entries. > > > >> >>> >>> > 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. > > I really lost you on this point. Reload is an overlay and key-based > storage protocol. The only functionality it gives you are those > abilities, there's nothing about "seems to be offline" that would come > out of the core protocol. A usage, such as the sip usage, specifies > how to use it to deliver functionality to the user. In the sip-usage > case, it stores destination lists indexed by AORs---so it doesn't > matter whether the users are using the nodeid of a peer or a client. > They are reachable via the destination list they specify. I guess you > could specify a usage that only stored the peer's nodeid and so didn't > support clients, but that would be broken. Any information in reload > on how to contact a node needs to be a destination list. > > > Bruce > > >> >> >> 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
