Subject: [decade] Work on decade security

From: Tobias Heer <[email-masked]>
Date: Sat, 27 Mar 2010 05:49:46 -0700

Hi everyone,

first I would like to thank the presenters for the nice presentations yesterday. 

I would be interested in contributing to the security architecture / requirements of decade. However, when screening the mailing list and the existing drafts I found little information on this topic. Maybe I was just looking for it in the wrong places, though. I'd be grateful for some pointers or background information about the security requirements and the envisioned architecture or maybe some pointers to previous discussions about it. I'll do some more thorough reading of the documents on the plane to see if I missed something.

Cheers, 

Tobias 

--  

Dipl.-Inform. Tobias Heer, Ph.D. Student
Distributed Systems Group 
RWTH Aachen University, Germany
tel: +49 241 80 207 76
web: http://ds.cs.rwth-aachen.de/members/heer

---

From: Richard Alimi <[email-masked]>
Date: Sat, 27 Mar 2010 12:02:04 -0400

Hi Tobias,

It would be wonderful if you could contribute here. I would agree that
the security considerations had not yet been fully fleshed out, and
are at this point intermingled with normal requirements.  Here are
some specific pointers to the ones we have thus far:

Security Considerations in the problem statement:
 http://tools.ietf.org/html/draft-song-decade-problem-statement-01#section-6

Authorization requirements:
 http://tools.ietf.org/html/draft-gu-decade-reqs-03#section-7

I believe the Resource Control is also related to Security
Considerations in the sense that it can help avoid Denial of Service
attacks:
 http://tools.ietf.org/html/draft-gu-decade-reqs-03#section-6
For a related measurement study on Akamai's infrastructure, see:
 http://www.cs.northwestern.edu/~asu224/doc/streaming-imc.pdf

There are some other items that immediately come to mind that are not
explicitly mentioned in drafts, or deserve to be called out more than
they currently are:
- Encryption of metadata and/or data
- The possibility that (authorized) remote peers may upload (either
intentionally or unintentionally) incorrect data to a user's storage.
Though it may not be preventable, a user should at least be able to
detect this and react accordingly, likely be removing the data.
- A more formal/clarified distinction between "layers" with regards to
authentication.  The P2P application may have its own
application-dependent way of doing authentication for peers in the P2P
overlay. Separate from this (but presumably, though not always, after
establishing connections in the P2P overlay), a DECADE user can grant
authorization one or more of these peers to access its in-network
storage. At the DECADE layer, the authentication is basically the
model used in OAuth.

As far as the architecture goes, we do have some initial thoughts, but
developing the architecture is one of the main work items for the WG
according to the charter (to be sent out for IETF review shortly...).
That said:

The WG has not yet made any concrete decisions about how some of these
security considerations will be addressed, which could certainly
affect the architecture we come up with.  There is some initial
possibilities for an architecture in the Solution Architecture slides:
 http://www.ietf.org/proceedings/10mar/slides/decade-7.pdf
There are some other details about an ongoing research project
detailed in this set of slides presented at the Hiroshima BoF:
 http://www.ietf.org/proceedings/09nov/slides/decade-3.pdf
And of course, there is the disclaimer the WG should in no way be
restricted to such designs, and it would be great to hear input from
others here.

Rich

On Sat, Mar 27, 2010 at 11:53 AM, Richard Alimi <[email-masked]> wrote:
> Hi Tobias,
>
> It would be wonderful if you could contribute here. I would agree that
> the security considerations had not yet been fully fleshed out, and
> are at this point intermingled with normal requirements.  Here are
> some specific pointers to the ones we have thus far:
>
> Security Considerations in the problem statement:
>  http://tools.ietf.org/html/draft-song-decade-problem-statement-01#section-6
>
> Authorization requirements:
>  http://tools.ietf.org/html/draft-gu-decade-reqs-03#section-7
>
> I believe the Resource Control is also related to Security
> Considerations in the sense that it can help avoid Denial of Service
> attacks:
>  http://tools.ietf.org/html/draft-gu-decade-reqs-03#section-6
> For a related measurement study on Akamai's infrastructure, see:
>  http://www.cs.northwestern.edu/~asu224/doc/streaming-imc.pdf
>
> There are some other items that immediately come to mind that are not
> explicitly mentioned in drafts, or deserve to be called out more than
> they currently are:
> - Encryption of metadata and/or data
> - The possibility that (authorized) remote peers may upload (either
> intentionally or unintentionally) incorrect data to a user's storage.
> Though it may not be preventable, a user should at least be able to
> detect this and react accordingly, likely be removing the data.
> - A more formal/clarified distinction between "layers" with regards to
> authentication.  The P2P application may have its own
> application-dependent way of doing authentication for peers in the P2P
> overlay. Separate from this (but presumably, though not always, after
> establishing connections in the P2P overlay), a DECADE user can grant
> authorization one or more of these peers to access its in-network
> storage. At the DECADE layer, the authentication is basically the
> model used in OAuth.
>
> As far as the architecture goes, we do have some initial thoughts, but
> developing the architecture is one of the main work items for the WG
> according to the charter (to be sent out for IETF review shortly...).
> That said:
>
> The WG has not yet made any concrete decisions about how some of these
> security considerations will be addressed, which could certainly
> affect the architecture we come up with.  There is some initial
> possibilities for an architecture in the Solution Architecture slides:
>  http://www.ietf.org/proceedings/10mar/slides/decade-7.pdf
> There are some other details about an ongoing research project
> detailed in this set of slides presented at the Hiroshima BoF:
>  http://www.ietf.org/proceedings/09nov/slides/decade-3.pdf
> And of course, there is the disclaimer the WG should in no way be
> restricted to such designs, and it would be great to hear input from
> others here.
>
> Rich
>
> On Sat, Mar 27, 2010 at 8:49 AM, Tobias Heer <[email-masked]> wrote:
>> Hi everyone,
>>
>> _______________________________________________
>> decade mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/decade
>>
>