[Cosmo-dev] Thoughts on sharing

[Lisa Dusseault]

It's even more than a CalDAV and WebDAV problem, it's a HTTP  
problem.  You can even consider it an Applications problem because  
IMAP is building features that will have this problem (e.g. URLs to  
share messages).

The basic problem is cross-site authentication.  How do I share my  
calendar, my blog, my public email folder or my online pictures  
folder to some people at some sites but not to the world?  How do I  
securely identify blog comments as coming from some blogger that is  
hosted on a different server than me?

This has been a major discussion at the IETF for 5-6 months now,  
including a meeting Friday here in Montreal.  There's two mailing  
lists: <https://www1.ietf.org/mailman/listinfo/dix> and <http:// 
lists.osafoundation.org/mailman/listinfo/ietf-http-auth>.  The latter  
list was actually created a year and a half ago, after discussions  
with various university customers about cross-site sharing of  
calendars and other HTTP authentication weaknesses.  I also gave a  
talk at OSAF on the topic: http://wiki.osafoundation.org/bin/view/ 
Journal/LisaDusseault20060408.

Some of what makes the problem hard is that cross-site authentication  
for the Web intersects deeply with the phishing problem.  Some pointers:
	- http://www.pmw.org/afsbpw06/talks/hartman-webauth.pdf
	- http://www.ietf.org/internet-drafts/draft-hartman-webauth- 
phishing-01.txt
	- http://www.w3.org/2005/Security/usability-ws/, particularly http:// 
www.w3.org/2005/Security/usability-ws/papers/37-google/

Although there's certainly a focus on Web and Web apps like CalDAV,  
WebDAV and Atom, there's also been some consideration whether cross- 
site authentication can be done at the TLS layer.  That would  
slightly help the phishing problem because it would tie clients  
providing their credentials with servers providing their credentials  
at the same layer, but there would still be browser and client GUI  
changes necessary to really deal with phishing and cross-site  
authentication.

More participation in this effort is quite welcome (join the lists,  
read the drafts).  The proposals that have made it as far as Internet- 
Drafts, with the kind of detail that allows you to really evaluate  
the proposed solution, do not even half cover the space of  
possibilities here.  See <http://www.educatedguesswork.org/ 
movabletype/archives/2006/06/notes_on_web_au.html> for an explanation  
of the solution space along two axes: what cryptographic approach is  
taken, and what protocol layer/architecture is chosen.

Lisa

On Jul 10, 2006, at 2:56 PM, Charles Mattair wrote:

> Some (not so) random thoughts on calendar sharing.
>
> The direction I've seen discussed is to a single server, read-only
> sharing model, using RSS or Atom.  I also haven't seen much discussion
> of credentialing and access control (if I know/can guess the URL, it's
> shared to me?).  I see this as a partial solution to a much broader
> requirement.
>
> For example, consider my experience at a previous employer.  We
> had calendars for each of our departmental conference rooms (the
> development conference room was gray so there was a "Gray
> Conference Room" calendar).  This calendar was owned by a psuedo-user
> in HR, shared read-only to everyone in the company and shared read- 
> write
> to all the developers.  All the other conference room calendars were
> shared equivalently except the boardroom which was owned by the CEO's
> secretary and only shared read-only.  Thus, I (as a developer) could
> schedule the gray room, other departments had to go through HR or our
> departmental secretary.
>
> This model also lent itself to executive calendars wherein either
> the calendar owner (executive) or designee (administrative assistant,
> etc.) could update the calendar.
>
> However, in this model, every assessor must be known to and have valid
> authentication credentials with the server.  Thus, I couldn't share my
> personal calendar with anyone on this list (excepting someone who  
> worked
> for the same company I did).  Even if a potential sharee had a  
> calendar
> (or LDAP or Kerberos) server which was capable of validating his/her
> credentials, there was also no mechanism for vectoring those  
> credentials
> from my server to theirs.
>
> I see a need for a sharing RFC which could flesh out these  
> requirements
> and lead to a standardized way of sharing calendars between users at
> disjoint locations.  This RFC needs to address credentialing, calendar
> and cell level protections and probably other things I haven't thought
> of.
>
> Actually, in looking at the problem a little longer, this is less a
> CalDAV problem than a WebDAV one.
>
> Thoughts?
>
> cgm
> _______________________________________________
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev