Hi Anu, Thanks for reviewing the proposal.
Today, any actor joining the Ratis ring has to call an RPC the SCM leader to add to the Raft group. In secure mode (Kerberos enabled), the RPC has a layer to authenticate the client user during connection establishment. This prevents unknown principals from joining the Raft group. Thanks, Duong On Mon, May 22, 2023 at 11:27 AM anu engineer <anu.engin...@gmail.com> wrote: > I had a slightly orthogonal question: Do we need any special > authentication mechanism today to join a Ratis ring ? > It is probably not a significant question -- and the answer is that we > are secure -- it was not obvious for me from reading code. Hence the > question. > > > Here is a possible attack vector: > > 1. Assume that it is possible to join the Ratis ring by simply > pointing to the Ratis group -- say you have a ring, and all I need to > do to join is some config file change -- or kill a machine and do an > ARP spoofing. > 2. At that point, will updateKeys send the keys to an attacker ? > 4. In other words, does putting the Symmetric keys into a replication > mode even make sense. > 5. When SCM fails over, it can simply send its id across or ID in all > packets -- and the clients can negotiate a key ? > > Thanks > Anu > > On Sun, May 21, 2023 at 9:20 PM Sumit Agrawal > <sumitagra...@cloudera.com.invalid> wrote: > > > > Hi Duong, > > > > Thanks for working on this. I have gone to design docs and it looks good. > > > > Few query: > > 1. Upgrade from existing block token with async algo to symmetric > > algorithm: > > - any impact to existing/old clients? > > > > 2. When using block token configuration with HMACWithSha256 and later > > changed to HMACWithSha1, and restart SCM to take config in effect. > > - do this have any impact to existing token and DNs running with old and > > new token? > > Just to know if algorithm is upgraded in system, how do this have impact > or > > do need any further changes to support this. > > > > > > Regards > > Sumit > > > > On Sat, May 20, 2023 at 5:35 AM Duong Nguyen <du...@apache.org> wrote: > > > > > Dear Ozone Devs, > > > > > > I would like to start this discussion thread for the proposal to merge > > > HDDS-7733-Symmetric-Tokens to master. > > > > > > This feature branch contains the implementation to replace the costly > token > > > signature generation using asymmetric (RSA) keys with symmetric key > > > algorithms, like HMAC with SHA256. Symmetric key algorithms bring a > > > much better performance and are the natural fit for Ozone token use > case. > > > Yet, they require building a mechanism to generate, store, distribute, > and > > > renew symmetric secret keys. That requirement is not trivial and has > to be > > > split into smaller tasks that cannot be shipped individually. That is > > > the reason why the implementation of HDDS-7733 > > > <https://issues.apache.org/jira/browse/HDDS-7733> happens in a > separate > > > feature branch. > > > > > > HDDS-7733 is not a new feature but an internal redesign for Ozone > tokens to > > > improve OM performance/Ozone scalability. Apart from the existing > > > integration and acceptance tests which should already cover the usage > of > > > tokens pretty well, we also added E2E test cases to cover the edge > cases > > > related to the symmetric secret keys life-cycle, as per HDDS-8003 > > > <https://issues.apache.org/jira/browse/HDDS-8003>. > > > > > > More information can be found on the wiki page: > > > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=255070328 > > > > > > If there are no objections to the merge, we could start the official > vote. > > > > > > Thanks, > > > Duong > > > > > > > > > -- > > *Sumit Agrawal* | Senior Staff Engineer > > cloudera.com <https://www.cloudera.com> > > [image: Cloudera] <https://www.cloudera.com/> > > [image: Cloudera on Twitter] <https://twitter.com/cloudera> [image: > > Cloudera on Facebook] <https://www.facebook.com/cloudera> [image: > Cloudera > > on LinkedIn] <https://www.linkedin.com/company/cloudera> > > ------------------------------ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@ozone.apache.org > For additional commands, e-mail: dev-h...@ozone.apache.org > >
