headers
Karp, Alan H | 6 Nov 2009 22:45
Picon
Favicon

Report on the Internet Identity Workshop.

I just returned from the Internet Identity Workshop (IIW), which has a lot of attendees from the OpenID,
OAuth, and CardSpace communities. Notes of the sessions will be posted at
http://www.internetidentityworkshop.com/ shortly. 

The first session I attended was on security issues for OpenID.  The list of vulnerabilities was long, and
the list of possible fixes was much shorter.  The good news is that many of the vulnerabilities come from
poor implementations due to imprecision in the spec, and others come from the need to maintain backward
compatibility, e.g., the current practice of using http for OpenID URLs rather than HTTPS. 
Unfortunately, there are other vulnerabilities that don't appear to have easy solutions.

The most interesting session I attended reported on work being done in the OAuth working group of IETF,
http://www.ietf.org/dyn/wg/charter/oauth-charter.html.  Originally called "Simple OAuth", WRAP
(Web Resource Authorization Protocol) is being developed to address weaknesses in the authorization
process in the original OAuth protocol.  WRAP is supported by Microsoft, Google, and Yahoo.  The key idea of
WRAP is to separate the authorizing component from the resource provider.  Basically, a client
authenticates to the authorization service and gets an authorization token, which is submitted to the
resource along with the request, a ZBAC pattern.  There is a discussion group at http://groups.google.com/group/oauth-WRAP-WG.

________________________
Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
http://www.hpl.hp.com/personal/Alan_Karp
Permalink | Reply | 2 comments |
headers
Ben Kloosterman | 7 Nov 2009 00:10
Picon

Capabilitites and Directories

How would you integrate capabilities into existing organizations using
Active Directory or LDAP ? Should capabilities be persisted in a directory
for a particular user , group or process ?  

or is something like this "Distributed capability-based authorization
architecture" ( http://www.freepatentsonline.com/7404203.html)  more
appropriate ?

or should we go with some of the newer web  based  authorization methods if
so how do these integrate into organizations Directories ?

Regards, 

Ben
Permalink | Reply | 1 comment |
headers
Karp, Alan H | 7 Nov 2009 01:06
Picon
Favicon

Re: Capabilitites and Directories

Ben Kloosterman wrote:
> 
> or is something like this "Distributed capability-based authorization
> architecture" ( http://www.freepatentsonline.com/7404203.html)  more
> appropriate ?
>
I only did a quick scan of the patent, but the paragraph starting on line 4 of column 10 makes it clear that they
built "capabilities as rows."  They even managed to end up with ambient authorities and non-delegation! 
The patent does describe a non-stupid way of deciding which user gets which set of initial capabilities,
but there are better ways to do that, too.

________________________
Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
http://www.hpl.hp.com/personal/Alan_Karp
Permalink | Reply | 0 comments |
headers
Karp, Alan H | 10 Nov 2009 17:47
Picon
Favicon

Bellovin paper that cites Hayek to justify enabling easy delegation

Laissez-faire file sharing: Access control designed for individuals at the endpoints

http://www.cs.columbia.edu/~smb/papers/nspw-use.pdf 

________________________
Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
http://www.hpl.hp.com/personal/Alan_Karp
Permalink | Reply | 4 comments |
headers
Bill Frantz | 11 Nov 2009 03:10
Favicon

Re: Bellovin paper that cites Hayek to justify enabling easy delegation

alan.karp@... (Karp, Alan H) on Tuesday, November 10, 2009 wrote:

>Laissez-faire file sharing: Access control designed for individuals at the endpoints
>
>http://www.cs.columbia.edu/~smb/papers/nspw-use.pdf 

They say:

    While the freedom to restrict access or further delegation 
    may initially seem counter to a laissez-faire philosophy, such 
    restrictions are the foundation of intellectual property law 
    designed to spur innovation. 

    Freedom of delegation is one of the most attractive proper- 
    ties of email attachments, as files can be shared with anyone 
    (or any group) with an email address.

I notice they don't mention that email attachments have no effective
controls on further delegation. :-)

Cheers - Bill

-------------------------------------------------------------------------
Bill Frantz        | Airline peanut bag: "Produced  | Periwinkle
(408)356-8506      | in a facility that processes   | 16345 Englewood Ave
www.pwpconsult.com | peanuts and other nuts." - Duh | Los Gatos, CA 95032
Permalink | Reply | 3 comments |
headers
David-Sarah Hopwood | 11 Nov 2009 06:00
Favicon
Gravatar

Re: Bellovin paper that cites Hayek to justify enabling easy delegation

Bill Frantz wrote:
> alan.karp@... (Karp, Alan H) on Tuesday, November 10, 2009 wrote:
> 
>> Laissez-faire file sharing: Access control designed for individuals at the endpoints
>>
>> http://www.cs.columbia.edu/~smb/papers/nspw-use.pdf 
> 
> They say:
> 
>     While the freedom to restrict access or further delegation 
>     may initially seem counter to a laissez-faire philosophy, such 
>     restrictions are the foundation of intellectual property law 
>     designed to spur innovation.

Well, at least my opinions about both of those are consistent :-)

More seriously, that's pretty much the only questionable sentence in
a paper that generally argues strongly for freedom of delegation. It's
somewhat verbose, but there's very little that I would disagree with.

>     Freedom of delegation is one of the most attractive proper- 
>     ties of email attachments, as files can be shared with anyone 
>     (or any group) with an email address.
>     
> I notice they don't mention that email attachments have no effective
> controls on further delegation. :-)

They do mention that, in section 2:

# By attaching a file to an email one may sacrifice the ability to
(Continue reading)

Permalink | Reply | 0 comments |
headers
Karp, Alan H | 11 Nov 2009 17:10
Picon
Favicon

Re: Bellovin paper that cites Hayek to justify enabling easy delegation

Bill Frantz wrote:
> 
> I notice they don't mention that email attachments have no effective
> controls on further delegation. :-)
>
They get it right later in the paper.  Bellovin has long advocated for blocking delegation.  It's just
dawning on him that you can only block delegation of permission, but you can't do anything about
authority.  Of course, he doesn't say it that way.

________________________
Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
http://www.hpl.hp.com/personal/Alan_Karp
Permalink | Reply | 0 comments |
headers
Stiegler, Marc D | 11 Nov 2009 19:15
Picon
Favicon

Re: Bellovin paper that cites Hayek to justify enabling easy delegation


>     Freedom of delegation is one of the most attractive proper- 
>     ties of email attachments, as files can be shared with anyone 
>     (or any group) with an email address.
>     
> I notice they don't mention that email attachments have no 
> effective controls on further delegation. :-)
> 
> Cheers - Bill

While they do explicitly say elsewhere that you cannot prevent delegation, they demonstrate with
statements like this an ambiguous willingness to give the owner the pretention of prevention. They dance
up to the important realization, understand there is an important realization within grasp, but are not
quite willing to step across the boundary of traditional illusion into the light where reality dwells :-)

--marcs
Permalink | Reply | 0 comments |
headers
Mark Seaborn | 19 Nov 2009 08:28

Re: Ambient authority in the Web Geolocation API

On Thu, Oct 29, 2009 at 9:05 PM, I wrote:
The API appears to introduce a new kind of ambient authority.  Tyler Close's paper on clickjacking [2] argues that the root cause of the problem is use of ambient authority via cookies.  Tyler argues that sites should use URLs-as-capabilities instead of cookies so that an attacker cannot guess the URL of a frame to embed.

Though sites can opt not to use cookies as an implementation strategy, they can't opt out of using same-origin authorisation for persistent access to geolocation data.  I suspect DOM storage [3] has a similar issue.

I have been trying to come up with a way that the ambient authority in the geolocation API might get exploited.  I have come up with a hypothetical example but it might be far-fetched.

Suppose FooMaps.com is a mapping site that allows external sites to provide custom image-tile overlays.  It allows you to specify a base URL for the image tiles as a URL parameter.

So, for example, you would visit
http://foomaps.com/map.py?overlay=http://bar.com/image.cgi
and the resulting page would create <img> elements linking back to
http://bar.com/image.cgi?x=1234&y=4567

If an attacking page from mallet.com wishes to determine the user's location, it can create an invisible iframe linking to http://foomaps.com/map.py?overlay=http://mallet.com/user-id/image.cgi, and mallet.com can infer the user's location based on the HTTP requests it receives.

If FooMaps.com requires the user to click on an icon before navigating the map to the user's current position, the attacker must arrange a clickjacking to get the user to click on the icon.  Otherwise, the attacker's job is simpler.

I am assuming that the user has previously visited FooMaps.com and has granted it a persistent authorisation to read geolocation information, and that this grant causes the browser to fulfill geolocation requests from the origin FooMaps.com without further user interaction.


The question is, how likely is it that a site would provide a URL parameter API like this?  For example, it appears that Google Maps doesn't do this; it provides Javascript for other sites to embed instead.  OpenStreetMap has URL parameters for setting longitude and latitude but not apparently for adding custom layers.

Is there a deeper reason why sites do not or should not provide a URL parameter API like this?  It seems that this might be covered by the "Don't Be A Deputy" (DBAD) discipline that Maciej Stachowiak proposed on the w3.org public-webapps mailing list [1] as a way to avoid the Confused Deputy problem in the context of CORS.  One of the options in DBAD discipline is "Never make a request to a site on behalf of a different site".  Is it generally understood to be a bad idea to embed URLs in URL parameters in this way?

Mark

[1] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0481.html

_______________________________________________
cap-talk mailing list
cap-talk@...
http://www.eros-os.org/mailman/listinfo/cap-talk
Permalink | Reply | 1 comment |
headers
Jed Donnelley | 19 Nov 2009 10:22

DARPA Network Challenge

Cap-talk,

I thought some of you might find this DARPA Network (weather balloon) 
Challenge of interest:

http://networkchallenge.darpa.mil/

There is discussion of it in a variety of places, but I found this 
somewhat self serving review of team efforts to win it of interest:

http://cashforredballoons.com/

I somewhat doubt that it will be won - at least this first time around.

One technical aspect that I find interesting is that of providing 
assurance that people who submit data on sightings will actually be 
rewarded (e.g. vs. the site operators pocketing the "win"nings by 
saying that they or their friends actually submitted the sighting earlier).

If anybody has thoughts on how to solve that technical problem (not 
with trust, but with computation) I'd be interested to hear them.  In 
principle it seems to me that a site that would output signed data 
containing the sequence of sightings input would come pretty 
close.  It would seem a bit improbable that a sighting of the balloon 
that I saw would come in seconds before my sighting was submitted 
(the output of the other sighting coming back to me before my own 
sighting came back).

I know I'll be taking a look from our high rise office building on 
Dec 5th to see if I see any red weather balloons flying over San 
Francisco.  ;-)

I'm not sure yet if I'll report any such sightings.

If anybody else is planning to participate, I'd be interested to hear 
your thoughts.

--Jed  http://www.webstart.com/jed-signature.html
Permalink | Reply | 2 comments |

Gmane