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

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 1 Jul 2011 14:47:56 +0300

Hi,

please, let me know whether or not these modifications will be included
in the base draft at this point.

Thanks,

Gonzalo

On 21/06/2011 10:58 PM, Marc Petit-Huguenin wrote:
> I read the paper and this modification makes sense to me (for example without
> this modification a peer that is purely used for routing and storage purpose,
> like a bootstrap peer, had to invent a valid, unique, and useless username just
> to acquire a certificate).
> 
> So I support its inclusion in draft-ietf-p2psip-base.
> 
> 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. 879889, 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)
>>>>>> _______________________________________________
>>>>>> P2PSIP mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/p2psip
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> P2PSIP mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/p2psip
> 
> 
> 
_______________________________________________
P2PSIP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2psip

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 01 Jul 2011 15:44:14 -0700

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.

>>>>> comments since then), please send them to the list ASAP.

- -- 
Marc Petit-Huguenin
Personal email: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org

---

From: Diego Suarez <[email-masked]>
Date: Sat, 02 Jul 2011 18:28:19 +0200

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).

cheers

On Fri, 2011-07-01 at 15:44 -0700, Marc Petit-Huguenin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi Diego,
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> 
> iEYEARECAAYFAk4OTbsACgkQ9RoMZyVa61fT2wCgqvIOHjARLO47zfHLRTYFrgt7
> XYYAn1tF6/fhwO0bfttpuy4ELx3c0kjC
> =NS7V
> -----END PGP SIGNATURE-----

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sat, 02 Jul 2011 10:04:13 -0700

> 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;

- -- 
Marc Petit-Huguenin

---

From: Bruce Lowekamp <[email-masked]>
Date: Sat, 2 Jul 2011 16:53:59 -0400

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-masked]> wrote:
>>>>>>>> IET, vol. 5, pp. 879 889, Apr. 2011.
>>>>>>>>
>>>>>>>>
> iEYEARECAAYFAk4PT4sACgkQ9RoMZyVa61dPvACeITly6/Zqumz4e4ZrAn1yGI4x
> ay4AoJ11vmCRDkL8pXuN71qaZXhw5JTZ
> =Tp+D

---

From: Diego Suarez <[email-masked]>
Date: Mon, 04 Jul 2011 11:51:29 +0200

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

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 7 Jul 2011 16:34:12 -0600

This would break all the current deployments and implementation and not just in a way where some new software would need to be pushed out - all new certificates would need to be issues. From my point of view, this is too late for this change and instead it could be addressed with an extension.

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 07 Jul 2011 16:17:19 -0700

On 07/07/2011 03:34 PM, Cullen Jennings wrote:
> 
> This would break all the current deployments and implementation and not just
> in a way where some new software would need to be pushed out - all new
> certificates would need to be issues. From my point of view, this is too late
> for this change and instead it could be addressed with an extension.

I agree that it is probably too late, but I am concerned that this modification
is not really possible in an extension, but instead requires a new version of
the protocol because it needs two signatures in SecureBlock and StoredData.

>> please, let me know whether or not these modifications will be included in
>> the base draft at this point.
>> 
>> Thanks,
>> 
>> Gonzalo
>> 
>>> I read the paper and this modification makes sense to me (for example
>>> without this modification a peer that is purely used for routing and
>>> storage purpose, like a bootstrap peer, had to invent a valid, unique,
>>> and useless username just to acquire a certificate).
>>> 
>>>> 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).
>>> 
>>>>>>> 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. 879889, 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.
>>>>>>> 
>>>>>>> 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.
>>>>>>> 
>>>>>>> - Interoperability with SIP. SIP certificates are not valid in
>>>>>>> actual P2PSIP since they don't include a nodeID.
>>>>>>> 
>>>>>>> cheers
>>>>>>> 
>>>>>>> Diego Suárez
>>>>>>> 
>>>>>>> 
>>>>>>>> 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.

- -- 
Marc Petit-Huguenin

---

From: Bruce Lowekamp <[email-masked]>
Date: Thu, 7 Jul 2011 22:24:05 -0400

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 don't see a real problem with a host node having an
"[email-masked]" or "[email-masked]" 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.

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.

Bruce

---

From: Diego Suarez <[email-masked]>
Date: Fri, 08 Jul 2011 13:15:12 +0200

Hi Bruce,

Answers inline.

> clients use their own nodeids, not the host's nodeid.  It all works

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.

> where they are to admins, even though routing protocols don't require

Neither do I except for cases, like the presented before, of several
users in the same device.

> 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

---

From: Diego Suarez <[email-masked]>
Date: Fri, 08 Jul 2011 13:30:21 +0200

Hi,

The last I would like is to stop, break or delay the actual
deployments. 
If you find split certification useful, it is fine with me to address it
with an extension. However, as Marc's said, in order to be possible it
would need a change in the actual draft anyway to allow multiple
signatures in SecureBlock and StoredData. 

cheers

On Thu, 2011-07-07 at 16:17 -0700, Marc Petit-Huguenin wrote:
> iEYEARECAAYFAk4WPn0ACgkQ9RoMZyVa61eLNQCgi614Bs6sdoajQ+ASRC/36JWk
> 5y8An1wyr5TbRVqZ6VTCEnfUfz0GIKud
> =viZ4

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 8 Jul 2011 14:37:33 +0300

Hi,

I have just requested an IETF LC for this draft. Therefore, these
comments will be considered as IETF LC comments.

Cheers,

Gonzalo

---

From: Bruce Lowekamp <[email-masked]>
Date: Fri, 8 Jul 2011 09:40:29 -0400

> 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.

---

From: Diego Suarez <[email-masked]>
Date: Fri, 08 Jul 2011 18:53:02 +0200

Hi, 

I have the impression I am not explaining myself well. I am not saying
that clients in RELOAD do not work well, I am just saying that I do not
see how they can be used to allow several users to be connected to the
same the device; at least not with full functionalities.

Lets go back to the example: 
Imagine we have a device, with PKC ( # user = device1, nodeID = 100 # )
and two users ( # user = user1, nodeID = 200 # and # user = user2,
nodeID = 300 # ) connected to that device acting as virtual clients.

As you have said, during registration, users store a destination list
that start with the device ( nodeID = 100 ) and finishes with the
client's nodeID ( nodeID = 200 for user1 and nodeID = 300 for user2).
This works well, and allows other peers of the system to reach them.

However, the problem is with the access control. Being virtual clients,
users can perform NODE-USER-MATCH accesses related to their client's
nodeIDs and usernames: 200-user1 for user1 and 300-user2 for user2.
Nevertheless, this is not what we want in this case. In this case, where
user1 and user2 are supposed to be connected to the same device (nodeID
= 100), they should be allowed to perform NODE-USER-MATCH accesses
related to this device and their usernames: 100-user1 for user1 and
100-user2 for user2. Because, if not, we are not really implementing
this functionality. In order to be fully implemented, several users
connected to the same device should have the same functionalities that a
single user connected to this device has, and this is not the case using
virtual clients. 

cheers

---

From: Bruce Lowekamp <[email-masked]>
Date: Fri, 8 Jul 2011 19:06:32 -0400

inline

On Fri, Jul 8, 2011 at 12:53 PM, Diego Suarez <[email-masked]> wrote:
> 100-user2 for user2.

why?  It works as designed when they use their client nodeid.   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.

> Because, if not, we are not really implementing
> this functionality.

what functionality?

> In order to be fully implemented, several users

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.

Bruce

---

From: Diego Suarez <[email-masked]>
Date: Sat, 09 Jul 2011 19:25:43 +0200

First of all, I would like to introduce the motivation of the idea of
split certification, since I think it is an important point in this
discussion and would help to clarify why I think that virtual clients do
not really allow several users to be connected from the same device.
Also, it could help to clarify if I taking a false premise to support
split certification when I should not.

As far as I understood, the idea of nodeIDs in RELOAD is to represent
devices, despite usernames and nodeIDs are included in the same
certificate. Draft says: "If a user has more than one device, typically
they would get one certificate for each device.  This allows each device
to act as a separate peer." However, it also exist the possibility of
having a single certificate with several nodeIDs. In this case, a user
with two devices ( for example a mobile and a fixed phone ) would have a
certificate with a username and two nodeIDs, one for each device; being
able to be connected to network and contactable in both devices at the
same time.  

Regarding the first alternative, there is something I have not clear: If
a user has a different certificate for each device she has, would these
certificates have the same username and different nodeIDs? and if so,
would the PK be the same in all the certificates or a different PK in
each one?; or would the user have a different username, a different
nodeID and a different PK in each certificate?. Said this, if we want
each device to have its own certificate, why don't make it simpler a
split device's identity from the user's identity?

The second alternative (several nodeIDs in a single cert) works well for
me if the user if using the same devices all the time, for example a
user with one cert with a nodeID for her mobile phone and another nodeID
for her office fixed phone; but has some limitations. What happens if
the user is out for one week in another office and wants to be connected
from there ? The simple answer seems to be "use the nodeID she was using
in the other office". But, is it not weird to bother in the first place
to give a different nodeID to each user's device and now use the same
nodeID for two different ones? Also, won't be useful to have each device
identified by a unique nodeID within the network for security reasons or
to have permanent statistics about its past behavior for network
maintenance or routing purposes? 

With this in mind, it came to me the idea of a split certification. With
split certification, users would be identified always by the same
certificate independently of the device they are using (something that
does not happen in the first alternative). Also, devices would be always
identified by the same and unique cert (something that does not happen
in the second). Besides, users could be connected to as many devices as
they want without have to been re-certified to get more nodeIDs. I think
this would simplify the certification of the system and improve its
maintenance. Also, extra improvements come with this alternative, like
greater interoperability with SIP ( as I've already commented in
previous mails ) or the easy deployment of more secure networks formed
by hard coded (including a certificate with a nodeID) devices.

The comments to the other improvement I see of this alternative, related
to several users connected to the same device, are inline.

On Fri, 2011-07-08 at 19:06 -0400, Bruce Lowekamp wrote:
> why?  It works as designed when they use their client nodeid.   

Well, I've said before, if the idea of RELOAD is to have each device be
identified by a different nodeID, from my point of view two users
operating from the same device should be using the same nodeID. Two
users connected to the same device, using different nodeIDs, that also
reuse later with another devices are not actually breaking the
certification idea of 1device = 1nodeID?

> In

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.

> device to have that wouldn't be provided using their own nodeids.

I would try to clarify what I mean with an example that presents three
possible cases that can occur in RELOAD:

case 1:

User1 with cert ( user = user1, nodeID = 100 ) is connected to the
network using a device. Therefore she can perform any access related to
her user( USER-MATCH = user1 ), nodeID ( NODE-MATCH = 100 ) or the
combination of both (USER-NODE-MATCH = user1-100).

case 2: 

The same User1 with the same cert is connected to the network using the
same device. But now, also User2 ( user = user2, nodeID = 200 ) and 
User3 ( user = user3, nodeID = 300 ) are connected to that device as
virtual clients. User1 can perform the same kind of accesses than 
in case 1. User2 can perform accesses related her user( USER-MATCH =
user2 ), virtual nodeID ( NODE-MATCH = 200 ) or the combination of both
(USER-NODE-MATCH = user2-200). User3 is ( USER-MATCH = user3 ), virtual
nodeID ( NODE-MATCH = 300 ) or the combination of both (USER-NODE-MATCH
= user3-300).

case 3:

A "non-user" device ( user = lab1, nodeID = 100 ) is connected to the
network. Two users, User2 and User3 (with the same credentials that in
the previous case) are connected to that device. So, User2 and User3 can
perform the same accesses than in case 3.

In this three examples, taking a look a the accesses related to NODE,
the important thing here, we see different cases of users presumably
connected to the same device, that should have the same functionalities
over that device but actually they have not. Precisely, User1 can
perform accesses on behalf of the device, while user2 and user3 cannot.
I would expect for all the cases the same rights for a user, either she
has full control over the device ( to perform accesses like NODE-MATCH =
100 ) or she does not have any control at all over it. But not these
different possibilities depending on how the user is connected to the
device. This is what I wanted to mean with no having full
functionalities. Furthermore, in case 2 we are forcing User1 to be
connected to the network while User2 and User3 wish to continue using
the device. It would be possible here that User1 entered in an
‘invisible mode’ by removing her contact information from the network.
In such case, User1 seemed to be offline for the other users of the
network (neither they could have the knowledge that she is online or
access to her contact information) but she would be actually online
since she could access to all the resources of the network, like her
voicemail or the contact information of other users to initiate media
calls.

cheers

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 15 Jul 2011 10:55:40 -0700

> for this change and instead it could be addressed with an extension.

About this "breaking current deployment" thing, it seems to me that anyway when
RELOAD will be published as an RFC, the version number with be incremented to
1.0 (0x0a), so implementations of the RFC will *not* be compatible with *any* of
the current implementations.  And because of this, I really do not understand
why the authors of RELOAD are fighting so hard to not break things that will be
broken anyway - there was multiple instances of things that could have been
improved in the document but stayed because of this (the fragment bit is one
example of this).  Having been there multiple times I really understand the
plight of early implementers but I would never ever use this as a justification
to keep useless stuff in a protocol.  What should have been done is simply to
increment the version each time a new version of the draft would have broken
interoperability - and we had the possibility to do that 8 times (versions 0.1
to 0.9).

>> the base draft at this point.

[...]

- -- 
Marc Petit-Huguenin

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 16 Jul 2011 09:41:31 -0700

I think all the people that implemented early version know that changes can,  and will,   break backwards compatibility. I don't recall very many places where I used this as augment for one way or another. I recall some places where it was 6 of one of half a dozen of the other and it made no fundamental difference to the protocol so we decided to go which what was already implemented. 

That said some types of changes are very easy to move into a fully operational deployed DHT. Others are not. For example, a change that you can detect the version number and then just have the software do the right things is pretty easy particularly if both the new code and old code can exist in the ring at the same time. A change where every device in the ring needs to get a new certificate and you can' have a mixed ring with the old and new certificates at the same time is not easy to deploy. 

To the point of this specific proposal for change. This fundamentally changes the security model and nearly every part of this protocol that has anything to do with security - which is most of it. The suggestions is several years late - it was many years ago that this WG made the decision about what the general security model was doing to be. If people want this, it seems like a fine thing to do in version 2.0 of the protocol. Thought my previous email suggested that one could look at doing it in an extension, closer examination of that makes me think there would be some real hard problems in trying to do that as it requires all the security component to be re-thought and redesigned. Given the current level of energy in the WG, that would take several years to happen. I have pretty much zero interest in doing that, I'd like to actually have an RFC for this in the next year instead of several years from now. As practical improvement of the protocol, I have not seen a single use case proposed where this improves things so much we can actually do something interesting that we can no do with the current proposal. 

On Jul 15, 2011, at 10:55 , Marc Petit-Huguenin wrote:

> iEYEARECAAYFAk4gfxoACgkQ9RoMZyVa61cxtQCeK9nUyj9XzOp0+8q9Mdhtp9Sg
> 3QoAoJaA4VCBUqtphhjrUMyAiaVmsNRc
> =gx2i

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sat, 16 Jul 2011 11:12:47 -0700

On 07/16/2011 09:41 AM, Cullen Jennings wrote:
> 
> I think all the people that implemented early version know that changes can,
> and will,   break backwards compatibility. I don't recall very many places
> where I used this as augment for one way or another. I recall some places
> where it was 6 of one of half a dozen of the other and it made no fundamental
> difference to the protocol so we decided to go which what was already
> implemented.

Well, I kind of disagree here.  The problem is that *future* implementers will
not have access to the whole history of the development of the RELOAD protocol
when trying to decipher the specification.  The RELOAD specification is *not*
developer friendly (but it is not specific to this spec).  I am still not saying
that a protocol must be developer-friendly, just that the text describing it
should be, and that when it makes no fundamental difference to the protocol,
making it easier for future developers should have priority over not breaking
compatibility.

> 
> That said some types of changes are very easy to move into a fully
> operational deployed DHT. Others are not. For example, a change that you can
> detect the version number and then just have the software do the right things
> is pretty easy particularly if both the new code and old code can exist in
> the ring at the same time. A change where every device in the ring needs to
> get a new certificate and you can' have a mixed ring with the old and new
> certificates at the same time is not easy to deploy.

I still do not see this as a good reason to stop fixing stuff in the protocol.
What is the point of having internet *drafts* if they are to be considered as
standard track RFCs?

> 
> To the point of this specific proposal for change. This fundamentally changes
> the security model and nearly every part of this protocol that has anything
> to do with security - which is most of it. The suggestions is several years
> late - it was many years ago that this WG made the decision about what the
> general security model was doing to be. If people want this, it seems like a
> fine thing to do in version 2.0 of the protocol. Thought my previous email
> suggested that one could look at doing it in an extension, closer examination
> of that makes me think there would be some real hard problems in trying to do
> that as it requires all the security component to be re-thought and
> redesigned. 

OK, now we agree.

> Given the current level of energy in the WG, that would take
> several years to happen. I have pretty much zero interest in doing that, I'd
> like to actually have an RFC for this in the next year instead of several
> years from now. As practical improvement of the protocol, I have not seen a
> single use case proposed where this improves things so much we can actually
> do something interesting that we can no do with the current proposal.
> 
> 
> 
>>>> This would break all the current deployments and implementation and not
>>>> just in a way where some new software would need to be pushed out - all
>>>> new certificates would need to be issues. From my point of view, this
>>>> is too late for this change and instead it could be addressed with an
>>>> extension.
> 
> About this "breaking current deployment" thing, it seems to me that anyway
> when RELOAD will be published as an RFC, the version number with be
> incremented to 1.0 (0x0a), so implementations of the RFC will *not* be
> compatible with *any* of the current implementations.  And because of this, I
> really do not understand why the authors of RELOAD are fighting so hard to
> not break things that will be broken anyway - there was multiple instances of
> things that could have been improved in the document but stayed because of
> this (the fragment bit is one example of this).  Having been there multiple
> times I really understand the plight of early implementers but I would never
> ever use this as a justification to keep useless stuff in a protocol.  What
> should have been done is simply to increment the version each time a new
> version of the draft would have broken interoperability - and we had the
> possibility to do that 8 times (versions 0.1 to 0.9).
> 
>>>> 
>>>>> please, let me know whether or not these modifications will be
>>>>> included in the base draft at this point.
>>>>> 
> 
> [...]
> 
>> 

> Cullen Jennings For corporate legal information go to: 

- -- 
Marc Petit-Huguenin

---

From: Bruce Lowekamp <[email-masked]>
Date: Sat, 16 Jul 2011 21:27:47 -0400

> 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.

> 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.

> 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.

> 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.

> 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.

> voicemail or the contact information of other users to initiate media

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

---

From: Bruce Lowekamp <[email-masked]>
Date: Sat, 16 Jul 2011 21:41:55 -0400

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

---

From: Bruce Lowekamp <[email-masked]>
Date: Sat, 16 Jul 2011 21:47:30 -0400

> making it easier for future developers should have priority over not breaking

While I think we're a bit late in the process for a wholesale rewrite
(we've done it about twice), if you have specific suggestions on
editorial issues that would make it clearer, please make them now
while we might be able to adjust some of the text.

> What is the point of having internet *drafts* if they are to be considered as

There are quite a few people who want to build things on top of it,
and it needs to not be a moving target for that to happen.
Presumably, if a significant amount of practical experience shows
things need to be changed, extensions and/or a v2.0 can be done.  But
right now the lack of a v1.0 is blocking other people's work.

Bruce

> iEYEARECAAYFAk4h1J0ACgkQ9RoMZyVa61cFxQCfTPJuP/YveHmTK4AMZfonQK3m
> Q+IAmgJN8sYZMzfygCqnocSYuosMsJT9
> =o9Rj

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sat, 16 Jul 2011 23:13:55 -0700

This was general remarks about the whole process, which I especially dislike.

- -- 
Marc Petit-Huguenin

---

From: Diego Suarez <[email-masked]>
Date: Mon, 18 Jul 2011 21:02:20 +0200

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