Re: [P2PSIP] Identity certificate segregation [was Re: draft-ietf-p2psip-base publication to be requested]

[Bruce Lowekamp <[e-mail]>]

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 <[e-mail]> wrote:
> On Sat, Jul 9, 2011 at 1:25 PM, Diego Suarez <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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
>>> >> >> "[e-mail]" or "[e-mail]" 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 <[e-mail]> 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 <[e-mail]> 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: [e-mail]
>>> >> >> >> > Professional email: [e-mail]
>>> >> >> >> > 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
>>> >> >> >> > [e-mail]
>>> >> >> >> > https://www.ietf.org/mailman/listinfo/p2psip
>>> >> >> >> >
>>> >> >> >
>>> >> >> >
>>> >> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >
>>> >
>>> >
>>
>>
>>
>