Subject: [decade] Do we have meeting minutes? /N

From: "Y.J. Gu" <[email-masked]>
Date: Fri, 09 Apr 2010 09:32:54 +0800

Regards

Yingjie Gu

---

From: Song Haibin <[email-masked]>
Date: Wed, 14 Apr 2010 16:17:58 +0800

Hi,

It will be very helpful if there is a analysis about the scenarios of
possible security threats within decade. Using in-network storage for
content distribution is still a little vulnerable in case that the
application control messages are using a different way/path than that of the
content. 

BR,
Haibin

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Richard Alimi
> Sent: Sunday, March 28, 2010 12:02 AM
> To: Tobias Heer
> Cc: [email-masked]
> Subject: Re: [decade] Work on decade security
> 
> 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#sect
> > ion-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,
> >>
> >> 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
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> decade mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/decade
> >>
> >
> _______________________________________________
> decade mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/decade
>