Hi, As I've said, from my point of view the good thing of split certification is that it makes things more simple and clear. Clients work fine for some scenarios, but for the case of several users in the same device are confusing for me. About the compatibility of the certification model, it is not that P2PSIP certificates are not compatible with SIP, but that SIP certificates are not valid with P2PSIP because they do not have a nodeID.
However, as I've said in my very first mail, I just wanted to introduce the idea of split certification in case the group thought it was useful for RELOAD. But if you think that it is not or that it makes things more complex or that it is too late to change the cert model; I, of course, accept your decision. I have another proposal for RELOAD related to the authorization (use of ACs instead -or as a complement- of ACLs), but since it does not need any change in the main draft I will take a while to write a draft to properly present it. cheers On Sat, 2011-07-16 at 21:41 -0400, Bruce Lowekamp wrote: > 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
