Subject: [P2PSIP] Roles

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 21 Mar 2007 05:17:34 -0400

As I mentioned at the P2PSIP microphone, I believe there are (at  
least) three roles that subsets of peer nodes can play:

(1) admission

Kind of like a bouncer at a bar, that role checks the bona fides of a  
new candidate peer and stamps its palm if admitted.

(2) discovery/beacon/rendezvous/portal/ambassador/travel agency/ 
usher/...

This is role where a peer advertises itself to a larger population of  
(candidate peer) nodes, in a variety of ways, as discussed in the  
bootstrap draft. It may not admit the candidate peer and may just  
forward the candidate to the nearest bouncer.

(3) insertion point/new neighbor

This is the node that becomes the new neighbor of the new node.

As always, logical roles can be combined on a single box, but it may  
be advantageous, for example, to restrict admission rights to a  
smaller set of more trusted nodes.

Henning

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

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Wed, 21 Mar 2007 10:56:43 +0100

> new candidate peer and stamps its palm if admitted.

I think this is a bit confusing, in that it seems to merge two roles.
Previous versions of the draft had an "enrollment process" that was
responsible for issuing a certificate to a new entity.   I guess
that's stamping the palm.  After that, you have the certificate, but
pretty much every peer needs to be "checking the palm" in terms of
checking the credentials.

So this was previously the enrollment process.

> forward the candidate to the nearest bouncer.

This is a bootstrap service.  The concepts drafts also allows for this
service to be provided by a mechanism that is not a peer.  I think
discovery service is probably a better term for this.

> This is the node that becomes the new neighbor of the new node.

This was previously insertion in the concepts draft, but a good number
of people preferred admission to insertion because they found the term
insertion to have more unrelated meanings that made extensive use of
the term to be unfortunate.

Bruce

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 21 Mar 2007 06:03:22 -0400

> the term to be unfortunate.

I agree insertion is a term that's already overloaded. New neighbor  
might be better. Admission is not a good term, as it implies some  
kind of permission or authorization.

---

From: "David A. Bryan" <[email-masked]>
Date: Wed, 21 Mar 2007 11:57:56 +0100

Actually, that implication of permission or authentication is what I *do* like.

I didn't like insertion because it implies I can force myself into a
network. There are number of reasons a potential new joining entity
could be rejected -- wrong protocol, no security credentials, etc.

I also think that in practice, breaking this into a peer that lets you
join and a peer that authenticates is impractical. Since no peer is
really any more trustworthy, implying some peer says you are ok and
then another lets you in seems like a big security nightmare. Every
peer should be security checking things, so seperating that out to me
seems wrong.

I see two roles, here not three. Security admission (the bouncer role)
should be done all the time, not as a seperate role/transaction. The
two roles seem to be discovery (what is currently called called
bootstrap), and admission, which I think is the right word. Insertion
seems wrong for the reasons I mention above, and new neighbor, while
ok, seems uneeded since this should be security checking, so the need
for a seperate term other than admission seems unclear.

Cullen had some objection that I didn't really follow to the current
scheme....what was it again?

-- 
David A. Bryan
[email-masked]
+1.757.565.0101 x101
+1.757.565.0088 (fax)
www.SIPeerior.com

---

From: Philip Matthews <[email-masked]>
Date: Thu, 22 Mar 2007 11:38:33 +0100

I concur with Brian's two points:
- "admission" implies that a peer may be allowed or rejected from  
joining, AND
- I don't see how the "bouncer" role can be played by a third party.
   Rather, it should be done by all the other boxes.
   For example, in the Bootstrap Server mechanism described in
           draft-matthews-p2psip-bootstrap-mechanisms-00
   some sort of admission control MIGHT be done by the
        - the Bootstrap Server  ("Is this peer allowed to use this  
bootstrap server?")
        - the Bootstrap Peer     ("Does this peer have the  
credentials to join this network?")
        - the Admitting Peer     ("Does this peer have the  
credentials to join this network?")
It is not clear to me right now how the second and third differ, but  
I don't want to rule it
out right now.

- Philip

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 22 Mar 2007 09:51:22 -0400

The notion of separation is that of making a decision and providing a  
token. I used the bouncer model intentionally: The bouncer checks  
your driver's license and makes sure that you are of legal age and  
that you aren't on the establishment's black lists of unwanted  
guests, and then stamps your palm. The bar tender "admits" you to the  
bar by checking the stamp. In a P2P sense, the admission function may  
check a node's reputation, consult black lists, perform return  
routability checks, CAPTCHA/turing tests and other checks, and then  
hands a token, such as a signature, verifying that the new node has  
passed these tests. Naturally, we wouldn't specify any of the details  
of the tests, but they are separable.

On Mar 22, 2007, at 6:38 AM, Philip Matthews wrote:

> It is not clear to me right now how the second and third differ,  
> but I don't want to rule it
> out right now.
>
> - Philip
>
>

---

From: "David A. Bryan" <[email-masked]>
Date: Thu, 22 Mar 2007 15:14:06 +0100

(In think Philip meant David (Bryan) when he said Brian...with "Bryan
and Brian" this is going to be confusing...)

I think either we have some terms wrong or Henning is thinking
Client-Server here. I think what Henning is talking about is what we
previously called "Enrollment" (and I wish that wasn't removed from
the newest concept draft -- we should put it back in). Enrollment is a
one time  issuance of credentials by a trusted by all party. You can't
trust another peer to check the credentials and then have a peer issue
a token to prevent future checks for that session, since if I am a bad
peer but not recognized as such, others might think the tokens I
issued are ok, when in fact I might be colluding with other bad peers
that want to enter the system.

In a peer-to-peer system, all peers must check all credentials at all
times. Allowing some other entity to vouch for security works in CS
since we agree to trust the server, but not in P2P. Using Henning's
analogy, since we assume any peer can be bad, everyone must assume the
bouncer may be buddies with the under aged drinkers trying to get in,
so the bartender (the admitting node) must check the ID himself each
time -- so the role is necessarily not separable as I see it.
Admitting without checking security means one bad peer can admit an
arbitrary number of additional bad peers. The only way Henning's model
works is if we have a mutually trusted (and I would expect
centralized) server that is consulted every time, which becomes client
server. If Henning means that checking the stamp is checking the
credentials themselves, that is ok, but then you are checking when you
admit and again it appears to me the roles are not separable.

Enrolment involves a *trusted and one time* transaction of central
authority to issue the credentials. In this analogy, that is the
government giving the ID that proves your date.

Unless my analysis above is wrong, I think we had the right terms
before (enrollment and admitting) and should leave those unchanged
both in terms of label and meaning, and I think the least confusion is
using the original terms. I am ok with Henning's suggestion of
renaming bootstrap to discovery, however...either term is fine with
me:

Joining Peer: The peer that wants to become a member of the overlay
Enrollment: One time obtaining of credentials from a centralized and
mutually trusted authority
Discovery or Bootstrapping: A peer that helps you locate the peer that
will admit you into the network
Admitting Peer: A peer that checks the credentials issued at
enrollment and either denies entry or accepts entry and performs
admission. The check and admit operations are atomic (I can't say to
another peer that the joining node is ok and they should trust me and
admit him without checking the credentials)

David

-- 
David A. Bryan
[email-masked]
+1.757.565.0101 x101
+1.757.565.0088 (fax)
www.SIPeerior.com

---

From: Philip Matthews <[email-masked]>
Date: Thu, 22 Mar 2007 21:34:35 +0100

> and Brian" this is going to be confusing...)

Whoops! Sorry about that!
Yup, I meant David Bryan, not Brian Rosen (or some other Brian).

- Philip

---

From: zhuxian <[email-masked]>
Date: Fri, 23 Mar 2007 13:45:49 +0800

I fully agree with the following sentence from David:
    In a peer-to-peer system, all peers must check all credentials at all
times.

Even if a centralized authentication server has been deployed in the
hybrid-p2p scenario, every peer should also authenticate each other at all
times. Otherwise, the peer could not confirm whether another peer is admited
by the authentication server, or it just join the overlay through its
colluding peer. 
  
Kurt  Zhu

>-----Original Message-----
>From: David A. Bryan [mailto:[email-masked]] 
>Sent: Thursday, March 22, 2007 10:14 PM
>To: Henning Schulzrinne
>Cc: Philip Matthews; [email-masked]
>Subject: Re: [P2PSIP] Roles
>
>(In think Philip meant David (Bryan) when he said Brian...with 
>"Bryan and Brian" this is going to be confusing...)
>
>Client-Server here. I think what Henning is talking about is 
>what we previously called "Enrollment" (and I wish that wasn't 
>removed from the newest concept draft -- we should put it back 
>in). Enrollment is a one time  issuance of credentials by a 
>trusted by all party. You can't trust another peer to check 
>the credentials and then have a peer issue a token to prevent 
>future checks for that session, since if I am a bad peer but 
>not recognized as such, others might think the tokens I issued 
>are ok, when in fact I might be colluding with other bad peers 
>In a peer-to-peer system, all peers must check all credentials 
>at all times. Allowing some other entity to vouch for security 
>works in CS since we agree to trust the server, but not in 
>P2P. Using Henning's analogy, since we assume any peer can be 
>bad, everyone must assume the bouncer may be buddies with the 
>under aged drinkers trying to get in, so the bartender (the 
>admitting node) must check the ID himself each time -- so the 
>role is necessarily not separable as I see it.
>Admitting without checking security means one bad peer can 
>admit an arbitrary number of additional bad peers. The only 
>way Henning's model works is if we have a mutually trusted 
>(and I would expect
>centralized) server that is consulted every time, which 
>becomes client server. If Henning means that checking the 
>stamp is checking the credentials themselves, that is ok, but 
>then you are checking when you admit and again it appears to 
>me the roles are not separable.
>
>Enrolment involves a *trusted and one time* transaction of 
>central authority to issue the credentials. In this analogy, 
>that is the government giving the ID that proves your date.
>
>Unless my analysis above is wrong, I think we had the right 
>terms before (enrollment and admitting) and should leave those 
>unchanged both in terms of label and meaning, and I think the 
>least confusion is using the original terms. I am ok with 
>Henning's suggestion of renaming bootstrap to discovery, 
>however...either term is fine with
>me:
>
>Enrollment: One time obtaining of credentials from a 
>centralized and mutually trusted authority Discovery or 
>Bootstrapping: A peer that helps you locate the peer that will 
>admit you into the network Admitting Peer: A peer that checks 
>the credentials issued at enrollment and either denies entry 
>or accepts entry and performs admission. The check and admit 
>operations are atomic (I can't say to another peer that the 
>joining node is ok and they should trust me and admit him 
>without checking the credentials)
>
>David
>
>> token. I used the bouncer model intentionally: The bouncer 
>checks your 
>> driver's license and makes sure that you are of legal age 
>and that you 
>> aren't on the establishment's black lists of unwanted 
>guests, and then 
>> stamps your palm. The bar tender "admits" you to the bar by checking 
>> the stamp. In a P2P sense, the admission function may check a node's 
>> reputation, consult black lists, perform return routability checks, 
>> CAPTCHA/turing tests and other checks, and then hands a 
>token, such as 
>> a signature, verifying that the new node has passed these tests. 
>> Naturally, we wouldn't specify any of the details of the tests, but 
>> they are separable.
>>
>> > I don't want to rule it out right now.
>> >
>> > - Philip
>> >
>> >
>> >> Actually, that implication of permission or 
>authentication is what 
>> >> I *do* like.
>> >>
>> >> I didn't like insertion because it implies I can force 
>myself into 
>> >> a network. There are number of reasons a potential new joining 
>> >> entity could be rejected -- wrong protocol, no security 
>credentials, etc.
>> >>
>> >> I also think that in practice, breaking this into a peer 
>that lets 
>> >> you join and a peer that authenticates is impractical. Since no 
>> >> peer is really any more trustworthy, implying some peer says you 
>> >> are ok and then another lets you in seems like a big security 
>> >> nightmare. Every peer should be security checking things, so 
>> >> seperating that out to me seems wrong.
>> >>
>> >> should be done all the time, not as a seperate role/transaction. 
>> >> The two roles seem to be discovery (what is currently 
>called called 
>> >> bootstrap), and admission, which I think is the right word. 
>> >> Insertion seems wrong for the reasons I mention above, and new 
>> >> neighbor, while ok, seems uneeded since this should be security 
>> >> checking, so the need for a seperate term other than 
>admission seems unclear.
>> >>
>> >> Cullen had some objection that I didn't really follow to the 
>> >> current scheme....what was it again?
>> >>
>> >>
>> >>> I agree insertion is a term that's already overloaded. New 
>> >>> neighbor might be better. Admission is not a good term, as it 
>> >>> implies some kind of permission or authorization.
>> >>>
>> >>> > Bruce
>> >>>
>> >>>

---

From: EdPimentl <[email-masked]>
Date: Fri, 23 Mar 2007 13:44:17 -0400

As we explore authentication mechanisms.
It would good to consider one of the following methods for authentication,
authorizations and entitlements such as:
http://dev.inames.net/wiki/Tech_FAQs
http://www.sourceid.org/
http://www.projectliberty.org/

My .02
Best,
-E

-- 
Thanks in advance and best regards,

Ed Pimentel
AgileCO
Founder

Mail:   edpimentl[at]gmail.com
sip:    sip:[email-masked]
IM:     edpimentl [AOL | Jabber | Yahoo | MSN ]
Voip:   edpimentl [SKype | GoogleTalk ]

Mobile Content Marketing/Management/Digital Delivery
http://mobilecentral.ws

Mobile ( Relevant, Ambient Intelligence, Location ) based Social Network
http://TagR.mobi (Alpha)

Mobile Payment - P2P Payment
http://agilepay.ws

Sponsor of P2PSIP  open source [viasip_ng] project
Creating a standards base P2PSIP dSIP infrastructure
https://sourceforge.net/projects/viasip/
Mailing List [email-masked]
_______________________________________________
P2PSIP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/p2psip

---

From: zhuxian <[email-masked]>
Date: Tue, 27 Mar 2007 11:00:43 +0800

EdPimentl,
 
These authentication mechanisms are typical used in the C/S model. In the
P2P model, SAML assertion or identity can be easily replayed, for the peer
receieved the assertion can replay it. But this may not be happened in the
C/S model, as we often believed that the server is trusted enough.  
 
So, even we use the SAML assertion, it also need some authentication
mechanisms to prove the peer sending the SAML assertion is the peer owning
the SAML assertion.
 
This is why I believe that peer should authenticate each other at all times.

Kurt Zhu

  _____  

From: EdPimentl [mailto:[email-masked]] 
Sent: Saturday, March 24, 2007 1:44 AM
To: zhuxian
Cc: David A. Bryan; Henning Schulzrinne; Philip Matthews; [email-masked]
Subject: Re: [P2PSIP] Roles

As we explore authentication mechanisms.
It would good to consider one of the following methods for authentication,
authorizations and entitlements such as:
http://dev.inames.net/wiki/Tech_FAQs  <http://dev.inames.net/wiki/Tech_FAQs>

http://www.sourceid.org/

My .02
Best,
-E

Kurt  Zhu

Ed Pimentel
AgileCO
Founder