Subject: [p2p-sip] Comments on concepts-02

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Wed, 18 Oct 2006 14:48:25 -0700

By "X.509 is rarely seen used with CPEs" I meant that it is rare for server
to authenticate clients, not to mention to verify "realworld identity" of
the clients.

That is why I think in P2P environment "detailed" or realworld identity
(first/last name, common name, organization...) is less essential than
merely ensuring the peer not to be a malicious peer so that we can correctly
fulfill peer-to-peer functionality of a P2P-SIP network.

In such a try-and-error environment full of uninsured attempts, very often
you just want to make sure that the peer you're talking to is indeed
belonging to the network and is helpful; you don't care which of John or
Mary the peer is.

There is "Simple Public Key Infrastructure" (SPKI). Just don't know whether
there is "simple certificate". Duh, I know THERE IS. Skype uses PKI but not
X.509 !!

My point is just: P2P-SIP seems to me not "so simple" in the long run as you
define and implement it  for serious commercial competence. Maybe it is time
to rid of unnecessary code such like ASN.1.  Simplicity or small footprint
(of protocol or code) is always a mercy to others as well as to yourself.
Maybe this is what was exactly in minds of the two authors of the
Touring-Machine awarded PDP-11 UNIX.

Peter
----- Original Message -----
From: "Peter Pan" <huang-ming.pan at comcast.net>
To: "zhuxian" <zhuxian at huawei.com>; "'Dean Willis'"
<dean.willis at softarmor.com>
Cc: <p2p-sip at cs.columbia.edu>
Sent: Wednesday, October 18, 2006 8:59 AM
Subject: Re: [p2p-sip] Comments on concepts-02

> X.509 for P2P-SIP is like butcher knife for tomato.
>
> Even in known C/S deployments X.509 is rarely seen used with CPEs for
> signaling or provisioning.
>
> Peter
> ----- Original Message -----
> From: "zhuxian" <zhuxian at huawei.com>
> To: "'Dean Willis'" <dean.willis at softarmor.com>
> Cc: <p2p-sip at cs.columbia.edu>
> Sent: Wednesday, October 18, 2006 5:55 AM
> Subject: Re: [p2p-sip] Comments on concepts-02
>
>
> > Hi:
> >      As to the peer and user credentials, I think using certificate is a
> > reasonable selection. Because it has already been used in many p2p
> platform
> > design, such as JXTA and microsoft PNRP.  And also, it is a reasonable
> > distributed authentication mechanism for p2p. If we use password, who
know
> > your password, except the centralized user server.
> >       A big question is, whether we use a CA or self-signed certificate.
I
> > think it is related to the security level we want to attain in the p2p
sip
> > world. Just using the self-signed certificate work well in some
situation.
> > But it can not defend the sybil and eclipse attacking, whick may turn
the
> > p2p sip overlay down in some situation. Use a certificate be signed by a
> CA
> > is Ok. But we need to do more in the p2p sip world. Because
> > anonymous-communication is an important character we want to achieve.
And
> > also the revoke problem in CA is more serious in p2p sip as the number
of
> > user may be huge and user may be dynamic.
> >
> >    As for the overlay that requires initial self-organization under
ad-hoc
> > network conditions and lacks a centralized source of authority, we can
not
> > get the security level when the overlay is accompany with a CA. Use the
> > self-signed ceritficate is ok in these scenarios. But i think it's
> > compatible with the CA approach in the peer/client implementation.
> > Peer/client can just downgrade the security level in these sitution.
> >
> >      As to the credential format, why don't we use a standard credential
> > format, such as X.509? Does the standard credential format can't fulfill
> the
> > credential requirement in p2p sip?
> >
> >
> > Xian Zhu
> >
> >  ----- Original Message -----
> > from : p2p-sip-bounces at cs.columbia.edu
> > [mailto:p2p-sip-bounces at cs.columbia.edu]  Dean Willis wrote:
> > send: Oct 18, 2006 5:05 am
> > to: p2p-sip at cs.columbia.edu
> > subject: [p2p-sip] Comments on concepts-02
> >
> >
> > 4.9.  Peer and User Credentials
> >
> >     We believe we need some sort of credentials for authenticating peers
> >     and users of each P2PSIP Overlay.  What should we use for these
> >     credentials?  Certificates?  PGP keys?  Passwords?  If certificates,
> >     should these be signed by a CA associated with the overlay, or can
> >     self-signed certificates work in some or all cases?  Do we need to
> >     specify a standard credential format, or should we allow different
> >     implementations to use different credential formats?
> >
> > Cullen suggested instead something like:
> >
> >     We assume a security model based on the issuance of credentials by
> >     an authority (presumably centralized) for each P2PSIP Overlay. What
> >     form of credential should be used? Do we need to specify a standard
> >     certificate format, or should we allow different implementations to
> >     use different certificate formats?
> >
> > Note that the above doesn't actually work in some of the use cases, such
> as
> > the anonymous-communication scenarios or the overlay that requires
initial
> > self-organization under ad-hoc network conditions and lacks a
centralized
> > source of authority. Under certain circumstances, it might be suitable
to
> do
> > something like generate randomized distinguished names and self-signed
> > certificates for those names. How shall we account for this in the
draft?
> >
> > --
> > Dean
> >
> >
> > _______________________________________________
> > p2p-sip mailing list
> > p2p-sip at cs.columbia.edu
> > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
> >
> >
> > _______________________________________________
> > p2p-sip mailing list
> > p2p-sip at cs.columbia.edu
> > https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>

---

From: bryan at ethernot.org (David A. Bryan)
Date: Wed, 18 Oct 2006 17:54:10 -0400

> belonging to the network and is helpful; you don't care which of John or

If the different John's are just different UAs all associated with the
same user (human), probably true, but if you mean I try call John
Smith and reach John Doe (different human), that scenario seems pretty
useless.

I think just proving you are part of the overlay isn't really that
useful, if people can clobber user names. Even if everyone is well
behaved, it wouldn't even have to be malicious -- could just be that
two people with the same name, intending to play by the rules, both
log on (say at different times, not realizing there is a collision)
and may not even realize they are confusing folks who are trying to
call them and getting different people.

It is really hard to assert identity (as opposed to ensuring it was
the same person you talked to last time, which is easier) in the
absence of some sort of centralized server. Not everyone can be
lonelygirl15.

--David

---

From: hgs at cs.columbia.edu (Henning Schulzrinne)
Date: Wed, 18 Oct 2006 18:04:43 -0400

I think there's a middle ground, namely where one leverages existing 
structures to assert identity uniqueness. In practical terms: it is 
fairly straightforward for a node to ascertain whether somebody new is 
indeed the owner of an email address - just send a message to that 
address and see if the destination agrees. This doesn't really require a 
"centralized server" as such, but does require leveraging some other 
infrastructure and mechanisms of identity generation. There are numerous 
variations on this concept:

- Prove ownership of a bank account by reporting on small deposits made;

- Prove ownership of a DNS domain by adding or modifying a host entry in 
the domain

- Prove ownership of a phone number by getting a call and entering number

- Prove ownership of an IP address by responding to a nonce or random 
identifier sent (e.g., a variation in TCP)

I think that in many practical cases, leveraging such identities will be 
the lowest-cost way to avoiding collisions, both intentional and otherwise.

Henning

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Wed, 18 Oct 2006 15:11:38 -0700

----- Original Message -----
From: "David A. Bryan" <bryan at ethernot.org>
To: "Peter Pan" <huang-ming.pan at comcast.net>
Cc: "zhuxian" <zhuxian at huawei.com>; "Dean Willis"
<dean.willis at softarmor.com>; <p2p-sip at cs.columbia.edu>
Sent: Wednesday, October 18, 2006 2:54 PM
Subject: Re: [p2p-sip] Comments on concepts-02

> Smith and reach John Doe (different human), that scenario seems pretty

You seems out of the condition :) After your initial bootstrap with the
central authority, the certificate associated with you in every later p2p
operation can fully prove who you really are. For example, you might be
assigned a unique 64bit identifier and the certificate proves the identifier
is with you "David A. Bryan". Once the certificate is signed, it is no
possible that you can manipulate the certificate to pretend you're another
David or Mary.

Simpy put, if your concern is valid, Skype is not as safe as it declare.
When I registered "Peter Pan" on Skype, I'm actually not Peter but H.M.Pan.
Actually I could change myself to "David A. Bryan" if I wish.

> call them and getting different people.

As for how to make sure the one you're calling is the one you want to call,
it seems to me not at all an issue of certificate. For example, I dont
identify my wife (she uses Skype too) by inspecting her certificate like we
inspect BofA certificate to not be fished; I'm some sure neither does Skype
program itself. I dentify my wife because Skype presented her correct email
address and that information may/can not be in Skype certificate. Before
presenting my wife to me, Skype server verifies it somwehere else.

> absence of some sort of centralized server. Not everyone can be

This is agreed.

---

From: bryan at ethernot.org (David A. Bryan)
Date: Wed, 18 Oct 2006 18:15:40 -0400

Fully agree that approach could work. We actually proposed using email
based protection just like this as out auth mechanism in the -00
version of draft-bryan-sipping-p2p, but felt it might not be as secure
as we wanted in all scenarios.

Technically, as many people pointed out to us, that is still a
"centralized authority" -- in this case the DNS/mail servers. It also
won't work in truly ad-hoc/disconnected scenarios (DNS dependent). The
other problem is who checks the authenticity before admitting a node
(in other words, who prompts by sending email?) You have a bit of a
risk of a malicious node "confirming" that someone is who they say
they are falsely, and the question of how often this check needs to be
performed (each time they start their client and the overlay? If only
once, how do we persist the authentication in the overlay so an email
challenge doesn't have to be resent?)

Some of the other ideas you mentioned make very good sense too, with
the same (possible) problems, but I still believe this kind of
approach could work and is worth exploring a bit more to see if we
tighten up the holes.

David

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Wed, 18 Oct 2006 15:23:38 -0700

I vote for the email approach only for initial identity verification by the
bootstrap server or CA.

I won't, if you're meaning the daily peer-to-peer identity verification.

Peter

---

From: hgs at cs.columbia.edu (Henning Schulzrinne)
Date: Wed, 18 Oct 2006 18:23:22 -0400

> "centralized authority" -- in this case the DNS/mail servers. It also

Not really centralized - there are millions of them. It would be 
centralized if all users for one P2P cloud would have to use a single 
server.

> won't work in truly ad-hoc/disconnected scenarios (DNS dependent). The

I don't see how anything except random (public key) identities and 
ensuring uniqueness is workable in a disconnected environment.

> challenge doesn't have to be resent?)

This problem isn't solved with certs, either, as a malicious node can 
simply pretend that someone presented a valid cert.

> approach could work and is worth exploring a bit more to see if we

This is not ironclad, but I believe this provides sufficient real-world 
security for most usages.

---

From: edpimentl at gmail.com (Ed Pimentel)
Date: Wed, 18 Oct 2006 18:36:08 -0400

CA is fine and HIP (Host Identity Protocol) is better and more  
suitable for P2P and SIP; and or IBE Identity Based Encryption.
-Edpimentl

On Oct 18, 2006, at 6:23 PM, Peter Pan wrote:

>>>>> In such a try-and-error environment full of uninsured attempts,  
>>>>> very
> often
>>>>> belonging to the network and is helpful; you don't care which  
>>>>> of John
> or
>>>>> Mary the peer is.
>>>>

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Wed, 18 Oct 2006 15:45:10 -0700

Seemingly, we discussed HIP approach before and concluded it to be not
working at least "commercially".

To be compatible or interoperate with existing service networks, sometimes
(way of generating) identity is predetermined, for example, Local Number
Portability or One Consolidation (phone) Number. You cannot generate these
"randomly".

Peter
----- Original Message -----
From: "Ed Pimentel" <edpimentl at gmail.com>
To: "Peter Pan" <huang-ming.pan at comcast.net>
Cc: "David A. Bryan" <bryan at ethernot.org>; "Henning Schulzrinne"
<hgs at cs.columbia.edu>; <p2p-sip at cs.columbia.edu>
Sent: Wednesday, October 18, 2006 3:36 PM
Subject: Re: [p2p-sip] Comments on concepts-02

---

From: zhuxian at huawei.com (zhuxian)
Date: Thu, 19 Oct 2006 22:18:29 +0800

>That is why I think in P2P environment "detailed" or realworld identity
(first/last name, 
>common name, organization...) is less essential than merely ensuring the
peer not to be a 
>malicious peer so that we can correctly fulfill peer-to-peer functionality
of a P2P-SIP 
>network.
But in p2p environment, how did you know a peer is not a malicious peer?
Without some third-party mechanism, it's very difficult. 

X.509 is rarely used for server to authenticate clients, because the server
usally keep the user's account information, or deploy some IP filter
mechanisms. But in the P2P environment, peer may need to authenticate each
other and they don't even know before. So we need some distributed
authentication mechanism, such as X.509 authentication.  

Although there are some complex code related to ASN.1 when use the X.509
certificate, but it doesn't mean using X.509 cert is a bad choice.
As to the SPKI, it has many function related to authorization, not only
related to authentication. The author named it as "simple", because it can
provide authorization and authentication service at the same time, and need
not to build a infrastructure from bottom-up. And also, the field and
s-expression is easy to understand. But i think that is not the main point.
And SPKI certificate is also rarely used. 

Does Skype use a PKI? I used to think it just use a centralized user
database. 

Xian Zhu

-----Original Message-----
From: Peter Pan [mailto:huang-ming.pan at comcast.net] 
Send: 10,19, 2006 5:48
To: zhuxian; 'Dean Willis'
Cc: p2p-sip at cs.columbia.edu
Subject: Re: [p2p-sip] Comments on concepts-02

Peter
----- Original Message -----

> >      As to the peer and user credentials, I think using certificate 
> > is a reasonable selection. Because it has already been used in many 
> > p2p
> platform
> > design, such as JXTA and microsoft PNRP.  And also, it is a 
> > reasonable distributed authentication mechanism for p2p. If we use 
> > password, who
know
I
sip
situation.
the
And
of
ad-hoc
not
> > get the security level when the overlay is accompany with a CA. Use 
> > the self-signed ceritficate is ok in these scenarios. But i think 
> > it's compatible with the CA approach in the peer/client implementation.
> >      As to the credential format, why don't we use a standard 
> > credential format, such as X.509? Does the standard credential 
> > format can't fulfill
> the
initial
centralized
to
> do
> > something like generate randomized distinguished names and 
> > self-signed certificates for those names. How shall we account for 
> > this in the
draft?

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Thu, 19 Oct 2006 12:13:31 -0700

Hi, Xian.

> Does Skype use a PKI? I used to think it just use a centralized user

Sometimes saying more confuses more. You could read this report of
four-month code evaluation on Skype security and try to judge whether
simplicity and sophistication can co-exist without compromising
functionality.

http://www.skype.com/security/files/2005-031%20security%20evaluation.pdf

I don't quite understand what it says of ASN.1 Attack. If you do, please
convey your grasp to me at your kindly convenience. Thanks.

Peter