<HTML>
<HEAD>
<TITLE>Re: Security issues</TITLE>
</HEAD>
<BODY>
<FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><BR>
<BR>
<BR>
On 8/8/08 11:03 AM, "Eric Barton" <<a href="eeb@sun.com">eeb@sun.com</a>> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><FONT COLOR="#0000FF">1. Securing bulk data.<BR>
</FONT> <BR>
<FONT COLOR="#0000FF">It seems to me that it <U>is</U> appropriate to use the GSSAPI to secure the<BR>
transfer of bulk data between client and server since it's effectively just<BR>
another message.  I can see (at least naively) that it would be good to<BR>
avoid double encryption in the case where file contents are actually stored<BR>
encrypted on disk.  <BR>
</FONT></SPAN></FONT></BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><FONT COLOR="#0000FF"><BR>
You are not telling me that we are going through a lot of re-design, that we are encrypting data and that then we are not storing it encrypted on disk?  Come on, adding an EA with a key to decrypt is not so hard and one gets lots of value from it.<BR>
</FONT></SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><FONT COLOR="#0000FF"><BR>
But even in this case, don't we still have to sign the<BR>
(encrypted) bulk so that the receiver can be sure it arrived intact?<BR>
<BR>
</FONT></SPAN></FONT></BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><FONT COLOR="#0000FF">Well, yes, but as I indicated you can sign the hash that is stored on (ZFS) disk for this.  That avoids generating the hash twice.  So I am really not convinced yet.<BR>
</FONT></SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>The issue is not the message mechanism, but is what identity to use for GSS to authenticate and how to manage and revoke that etc.<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'> <BR>
<FONT COLOR="#0000FF">2. Securing Capabilities.<BR>
</FONT> <BR>
<FONT COLOR="#0000FF">If we want to be sure that a Capability given to client A cannot be<BR>
snooped and used by client B we either (a) have to make the Capability <BR>
secret (i.e. never passed in cleartext) or (b) have to make the Capability<BR>
identify which client it is valid for.<BR>
</FONT> <BR>
<FONT COLOR="#0000FF">It seems to me that (b) is preferrable since it ensures that a malicious<BR>
client cannot leak Capabilities to a 3rd party.  The downside is that this<BR>
multiplies the number of unique Capabilities by the number of clients,<BR>
potentially increasing CPU load when 1000s of clients all open the same<BR>
shared file and each require unique Capabilities to access the stripe objects.<BR>
Do we have a feel for how bad this could be?<BR>
</FONT><BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>Yes, very bad, and it is absolutely necessary to have an option that avoids this (also 1000s is out of date – it could be 100x worse).  That option could be to simply not have security on the compute cluster if customers agree with this.<BR>
<BR>
We also need to discuss your proposals with a review committee from LLNL and Sandia, as we did during the PF discussions.<BR>
<BR>
Peter<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><BR>
 <BR>
    Cheers, <BR>
                   Eric <BR>
<BR>
 <BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>