Subject: [P2PSIP] comments on draft-matuszewski-p2psip-security-requirements-00.txt

From: Jie Yang <[email-masked]>
Date: Wed, 16 May 2007 09:49:34 +0800

hi, Matuszewski:

I'm very interested in your draft and found it included most of the
requirements on security. Furthermore, I found some other requirements. 

Users may be most care about the availability of the resources on the
overlay. So do the overlay operators. 

But unfortunately, attacker can deny the existence of resources it was
responsible for. This kind of attacks can be referred as "deny of
responsibility" attacks and these will compromise the availability of
resource. 

Maybe this issue should be addressed by distributed database algorithm.
However, it has some relations with security. So my suggestion is whether we
add the requirements of resource availability and "deny of responsibility"
attacks to your draft or not.

_______________________________________________
P2PSIP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/p2psip

---

From: <[email-masked]>
Date: Thu, 17 May 2007 15:53:02 +0300

Hi Jie,
 
Thank you for your comments. The attack you mentioned is partly covered
in the Denial of Service section. I agree with you this is a serious
problem in open distributed systems. This type of attack can be
mitigated by storing user records in more then one randomly chosen peer
(adding indexes to a user ID: UserID_1, UserID_2, UserID_3). 
 
We will try to emphasize this problem in the next version of the
document.
 
Marcin   

________________________________

	From: ext Jie Yang [mailto:[email-masked]] 
	Sent: 16 May, 2007 04:50
	To: Matuszewski Marcin (Nokia-NRC/Helsinki)
	Cc: [email-masked]
	Subject: comments on
draft-matuszewski-p2psip-security-requirements-00.txt

	hi, Matuszewski:

	I'm very interested in your draft and found it included most of
the requirements on security. Furthermore, I found some other
requirements. 

	Users may be most care about the availability of the resources
on the overlay. So do the overlay operators. 

	But unfortunately, attacker can deny the existence of resources
it was responsible for. This kind of attacks can be referred as "deny of
responsibility" attacks and these will compromise the availability of
resource. 

	Maybe this issue should be addressed by distributed database
algorithm. However, it has some relations with security. So my
suggestion is whether we add the requirements of resource availability
and "deny of responsibility" attacks to your draft or not.

---

From: Jie Yang <[email-masked]>
Date: Fri, 18 May 2007 17:11:33 +0800

Hi Marcin,

I'm happy that you accepted my suggestion. Today, I read your draft again
and I found some other issues that I didn't get very clear.

In section 

3.2.1           Data access

"First and foremost, the data stored in the P2PSIP system must be

         authentic, i.e., only authorized users are able to insert and
modify

         their the P2PSIP resource (user) records in the P2PSIP system."

You mentioned that only "authorized" users can have the privilege to insert
and modify records. Do the "authorized" users means only the records' owners
or they include some other people?  If  the records' owner is the only
person have the privilege, we just need to check the owner's identity to see
if he has the privilege.  However, if the authorized users are more than
one, we should have a table to list all the users' different privileges.
That is to say we need an access control mechanism such as ACL. This is the
case in some situations. E.g. Bob has some data that just his friends can
read and modify.

So, should we make clear that we need an access control mechanism in P2P
overlay to avoid abusing users' data?

Hive a nice day!

Jie

----------------------------------------------------------------------------
---------------------------------------------

Hi Jie,

Thank you for your comments. The attack you mentioned is partly covered in
the Denial of Service section. I agree with you this is a serious problem in
open distributed systems. This type of attack can be mitigated by storing
user records in more then one randomly chosen peer (adding indexes to a user
ID: UserID_1, UserID_2, UserID_3). 

We will try to emphasize this problem in the next version of the document.

Marcin   

  _____  

From: ext Jie Yang [mailto:[email-masked]] 
Sent: 16 May, 2007 04:50
To: Matuszewski Marcin (Nokia-NRC/Helsinki)
Cc: [email-masked]
Subject: comments on draft-matuszewski-p2psip-security-requirements-00.txt

hi, Matuszewski:

---

From: <[email-masked]>
Date: Tue, 22 May 2007 14:13:55 +0300

Hi Jie,
 
By authorized users we mean a record owner and other users that are
authorized to modify/access the record. 
 
Access lists do not work well in a distributed environment. In a P2PSIP
overlay authentication data can be distributed among peers. There are
other methods that can be used to authorize other network entities
(P2PSIP Users/Peers) to modify and access P2PSIP User/Peer records. 
 
For example network entities could issue each other tokens that are
digitally signed by them. The token would contain at least:
- issuer ID, and its public key (or certificate)
- target ID, and its public key (or certificate)
- authorizing data (e.g., allow target to see issuer's current
availability)
- validity period
 
Network entities would store all tokens that have been issued to them.
When a P2PSIP Client/Peer queries (GET method) status of a user, it
appends the request with a token that has the corresponding user as a
issuer. P2PSIP Peer validates the token using the issuer's public key,
and if it is valid, the relevant status data is released to this P2PSIP
Client/Peer. Similarly a P2PSIP Client/Peer may modify records of other
users/peers. P2PSIP User/Peer can revocate issued tokens by including
revocation data to its DATA entry (during PUT method).
 
Best regards,
Marcin Matuszewski 

	From: ext Jie Yang [mailto:[email-masked]] 
	Sent: 18 May, 2007 12:12
	To: Matuszewski Marcin (Nokia-NRC/Helsinki)
	Cc: [email-masked]; Ekberg Jan-Erik (Nokia-NRC/Helsinki);
Laitinen Pekka (Nokia-NRC/Helsinki)
	Subject: re: comments on
draft-matuszewski-p2psip-security-requirements-00.txt

	Hi Marcin,

	I'm happy that you accepted my suggestion. Today, I read your
draft again and I found some other issues that I didn't get very clear.

	In section 

	3.2.1           Data access

	"First and foremost, the data stored in the P2PSIP system must
be

	         authentic, i.e., only authorized users are able to
insert and modify

	         their the P2PSIP resource (user) records in the P2PSIP
system."

	You mentioned that only "authorized" users can have the
privilege to insert and modify records. Do the "authorized" users means
only the records' owners or they include some other people?  If  the
records' owner is the only person have the privilege, we just need to
check the owner's identity to see if he has the privilege.  However, if
the authorized users are more than one, we should have a table to list
all the users' different privileges. That is to say we need an access
control mechanism such as ACL. This is the case in some situations. E.g.
Bob has some data that just his friends can read and modify.

	So, should we make clear that we need an access control
mechanism in P2P overlay to avoid abusing users' data?

	Hive a nice day!

	Jie

------------------------------------------------------------------------
-------------------------------------------------

	Hi Jie,

	Thank you for your comments. The attack you mentioned is partly
covered in the Denial of Service section. I agree with you this is a
serious problem in open distributed systems. This type of attack can be
mitigated by storing user records in more then one randomly chosen peer
(adding indexes to a user ID: UserID_1, UserID_2, UserID_3). 

	Marcin   

		hi, Matuszewski:

		I'm very interested in your draft and found it included
most of the requirements on security. Furthermore, I found some other
requirements. 

		Users may be most care about the availability of the
resources on the overlay. So do the overlay operators. 

		But unfortunately, attacker can deny the existence of
resources it was responsible for. This kind of attacks can be referred
as "deny of responsibility" attacks and these will compromise the
availability of resource. 

		Maybe this issue should be addressed by distributed
database algorithm. However, it has some relations with security. So my
suggestion is whether we add the requirements of resource availability
and "deny of responsibility" attacks to your draft or not.