<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'><div><span style="font-size: 12pt;">(The previous reply used the wrong subject line - my appologies)</span></div><div><span style="font-size: 12pt;"><br></span></div><span style="font-size: 12pt;">Hi Simo,</span><br><div><div dir="ltr"><div dir="ltr"><p class="ecxp1"><br></p><p class="ecxp1">Nice writeup. A couple of comments I have just in case:</p><p class="ecxp1"><br></p><p class="ecxp1">1) Regardless public key or shared key based solution, there's always a need to store the secret key. The difference is with public key based, only the owner has the private key.</p><p class="ecxp1"><br></p><p class="ecxp1"><span style="font-size:12pt;">2) You mentioned that PKI is slow and complex, which is true comparatively but should be ok in this use case. For example, I can do 1034 sign/s and 22829 verify/s on my shabby macbook pro of 2010 and the CPU usage does not seem to be an issue. </span><span style="font-size:12pt;">Compared to the 2 lookups per message in your proposal as you mentioned, it's much much more efficient.</span></p><p class="ecxp1"><span style="font-size:12pt;"><br></span></p><p class="ecxp1">3) It looks like your key server is like Kerberos. There's probably no point to reinvent the wheel. It should easily adapt to this 1:1 use case as you proposal supported.</p><p class="ecxp1"><br></p><p class="ecxp1">4) Arguably, your proposal supports confidentiality, authorization control (via the shared secret) and integrity and anti-replay (via timestamp), but it falls short on non-repudiation due to the nature of shared secret. </p><p class="ecxp1"><br></p><p class="ecxp1">5) The 2 lookups to Key Server per message is way too much with regard to efficiency.</p><p class="ecxp1"><br></p><p class="ecxp1">6) As mentioned, failure to support 1:m, m:n messaging imposes too much restriction to the overall system.</p><p class="ecxp1"><br></p><p class="ecxp1">That said, the following is what I would suggest, which supports 1:1, 1:m and m:n messaging with confidentiality, integrity, authorization, non-repudiation and anti-reply:</p><p class="ecxp1"><br></p><p class="ecxp1"><span style="font-size:12pt;">a) In keystone, for each user add an entry for its public key - only the user itself knows its own private key.</span></p><p class="ecxp1"><span style="font-size:12pt;"><br></span></p><p class="ecxp1"><span style="font-size:12pt;">b) To support 1:m and m:n, each "group/role" of users is provisioned with its group public key - all users of this "group/role" is provisioned with the "group/role" private key. </span></p><p class="ecxp1"><span style="font-size:12pt;"><br></span></p><p class="ecxp1"><font size="3">c) All public keys (via x.509 or bare key) are cacheable. </font>Cautious senders and recipients should check regularly but it's an overkill to check once per message.</p><p class="ecxp1"><br></p><p class="ecxp1">d) On sending the message, the sender does the following:</p><p class="ecxp1"><br></p></div><blockquote style="border:none;padding:0px;"><div dir="ltr"><p class="ecxp1">d.a) looks up (if not cached or to be cautious - assuming there's no revocation in place) for the recipient's or recipients' public key. </p><p class="ecxp1"><br></p><p class="ecxp1">d.b) generate a encryption key (EK) and a signing key (SK) (not necessary if public key signing is used) and decide its lifetime (expiration and) </p><p class="ecxp1"><br></p><p class="ecxp1">d.c) generate a random # of at least 128 bit long, start/current time (e.g. via gettimeofday), EK and SK signature, expiration and and sender-id, concatenate and sign them using its private key</p><p class="ecxp1"><br></p><p class="ecxp1">d.d) Encrypt the message (together necessary meta data, e.g. recipient list and lifetime left, sequence counter) using EK, as BodyE and sign the encrypted BodyE using the sign key as SIGN.</p><p class="ecxp1"><span style="font-size:12pt;"><br></span></p><p class="ecxp1"><span style="font-size:12pt;">d.e) For each recipient, use its public key to encrypt EK, the encryption algo, signing key SK (if needed), signing algo, and EK/SK expiration), then prepend it with the recipient's public key identifier - e.g. uid.</span></p><p class="ecxp1"><br></p><p class="ecxp1">d.f) Send the the outcome of d.c), BodyE and SIGN from d.d) and d.e) over the all recipients.</p><p class="ecxp1"><br></p><p class="ecxp1">Note: d.b), d.c) and d.e) are only done once for the duration of the EK/SK lifetime, so the # of public key calculations (<span style="font-size:12pt;">RSA/EC etc) </span><span style="font-size:12pt;">are minimized. The algos are there for extensibility and the recipient can reject if it's weak.</span></p><p class="ecxp1"><br></p></div></blockquote>e) On receiving the message, the recipient doe the following:<div><br></div><div><blockquote style="border:none;padding:0px;"><div>e.a) looks up )if not cached or to be cautious - assuming there's no revocation in place) for the sender's public key.</div><div><br></div><div>e.b) verify sender signature and time window etc if not previously verified for this "session" (a while ago - time window == expiration).</div><div><br></div><div>e.c) decrypt the block prepared by d.e), gets the EK, SK, expiration and verify the expiration. </div><div><br></div><div>e.d) Using SK to verify signature</div><div><br></div><div>e.e) Decrypt the message using EK, check against replay via verifying the expiration and counter/sequence etc.</div><div><br></div></blockquote></div><div>If more detailes are needed, please let me know. Note that there may be loose ends given the limited time I have spent on this. </div><div><br></div><div><div dir="ltr"><p class="ecxp1">Regards,</p><p class="ecxp1">JZ</p><p class="ecxp1"><br></p><p class="ecxp1">On 4/25/13 5:37 AM, "Simo Sorce" <<a href="mailto:simo@redhat.com"><span class="ecxs1">simo@redhat.com</span></a>> wrote:</p>
<p class="ecxp2"><br></p>
<p class="ecxp1">Hello list,</p>
<p class="ecxp1">at the Summit we had a very interesting and productive discussion about</p>
<p class="ecxp1">Message Signing/Encryption for RPC Messages sent via the Message Queue.</p>
<p class="ecxp2"><br></p>
<p class="ecxp1">I would like to present a proposal that uses symmetric keys and a</p>
<p class="ecxp1">central key server to address the problem:</p>
<p class="ecxp2"><br></p>
<p class="ecxp3"><span class="ecxs2"><a href="https://wiki.openstack.org/wiki/MessageSecurity" target="_blank">https://wiki.openstack.org/wiki/MessageSecurity</a></span></p>
<p class="ecxp2"><br></p>
<p class="ecxp1">I would really like to get feedback on the proposal, especially if there</p>
<p class="ecxp1">are corner cases I have not considered.</p>
<p class="ecxp2"><br></p>
<p class="ecxp1">Simo.</p>
<p class="ecxp2"><br></p>
<p class="ecxp1">--</p>
<p class="ecxp1">Simo Sorce * Red Hat, Inc * New York</p>
<p class="ecxp2"><br></p>
<p class="ecxp2"><br></p>
<p class="ecxp1">_______________________________________________</p>
<p class="ecxp1">OpenStack-dev mailing list</p>
<p class="ecxp3"><span class="ecxs2"><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a></span></p>
<p class="ecxp3"><span class="ecxs2"><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></span></p>
<p class="ecxp2"><br></p></div>
</div> </div></div><style><!--
.ExternalClass .ecxhmmessage P {
padding:0px;
}
.ExternalClass body.ecxhmmessage {
font-size:12pt;
font-family:Calibri;
}
--></style> </div></body>
</html>