Subject: [Sipping] Consent Framework Issue

From: "Andrew Allen" <[email-masked]>
Date: Thu, 13 Jul 2006 19:31:04 -0400

Further to my comments the other day during the SIPPING session on
draft-ietf-sipping-consent-framework I believe having discussed this
with Jonathan Rosenberg that there is an issue that negatively impacts
the ability of users to switch service providers if consent is deployed
as currently defined. 

Alice has Biloxi as her Service Provider and she has a buddy list with
25 of her friends Bob, Colin,.....Zac. This buddy list was built over
time by Alice and she has obtained permissions over time from each of
her buddies to send Messages to them and has a permissions list
established on her Relay. Now Alice decides to switch service providers
from Biloxi to Columbia. This changes both her URI from [email-masked]
to [email-masked] and the location of her Resource List and
Permissions Relay servers to Columbia.net domain. Alice copies her Buddy
list that was previously stored at Biloxi to Columbia using XCAP however
she cannot now communicate with any of her friends since she cannot
transfer her permissions list. Alice now has to manually add each one of
her friends (one at a time) to her permissions list and wait for each
one of them to manually grant her permissions again.

With only 25 friends Alice would I am sure find this extremely annoying
and frustrating and a major disincentive to ever changing service
providers. However it is quite possible that Alice has 250 or more
contacts in her buddy list and obtaining permissions manually for all of
these is basically impractical in my opinion.

Alice's friends also will get frustrated having to regrant permissions
to Alice and other friends when ever a buddy changes their service
provider. It is even more than a frustration since Alice's domain
changed from [email-masked] to [email-masked] and her friends
probably don't have anyway of knowing for sure if this is really the
same Alice that used to be at Biloxi or a spammer ([email-masked])
attempting to spoof them to add the [email-masked] to their list.

It seems to me that we need some way of ensuring that permissions are
somehow automatically transferable or re-creatable and also that some
trait or signature is used to identify that [email-masked] is the same
person as [email-masked]. It seems to me that the Permission Server
in the domains of the permission grantor may need to store the
permissions granted and be able to automatically re-grant permissions
based on the trait or signature of an already allowed user when that
user re-requests permissions after changing domains - this would mean
the Publish of the granting of permissions would need to go back to the
Relay via the Permissions Server and the Permission Server would also
maintain a permission list of who their user had granted permission to. 

Also this manually adding requests for permission is problematic and we
need a way of adding the list in one step while preventing the
amplification problem. Maybe if the Relay instead of requesting
permissions for a list in parallel instead sequentially requested one at
a time for each permission when there was a list the amplification
attack wouldn't be such a problem.

Andrew

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Dean Willis <[email-masked]>
Date: Mon, 17 Jul 2006 15:33:11 -0500

On Jul 13, 2006, at 6:31 PM, Andrew Allen wrote:

> It seems to me that we need some way of ensuring that permissions  
> are somehow automatically transferable or re-creatable and also  
> that some trait or signature is used to identify that  
> [email-masked] is the same person as [email-masked]. It seems  
> to me that the Permission Server in the domains of the permission  
> grantor may need to store the permissions granted and be able to  
> automatically re-grant permissions based on the trait or signature  
> of an already allowed user when that user re-requests permissions  
> after changing domains – this would mean the Publish of the  
> granting of permissions would need to go back to the Relay via the  
> Permissions Server and the Permission Server would also maintain a  
> permission list of who their user had granted permission to.

You've posited a requirement that makes the problem isomorphic to the  
general identity problem, which puts it into the class of "currently  
unsolved and believed by many to be not solvable in the general case".

The problem is the "some trait or signature is used to identify that  
[email-masked] is the same person as [email-masked]" part. In  
the absence of a PKI or some other authentication anchor that is  
external to both biloxi and columbia, there's no known way to make  
this work.

Sure, we could have one PGP key for Alice and make both   
Alice@columbia-net and [email-masked] subkeys, but then we're back  
to the PGP-trusted-introducer problem, which (while mathematically  
tractable) hasn't seemed to catch on for people without nerd-genes.

--
Dean