> The case timer was extended to 8/29/2007 during today's meeting due to > outstanding unanswered questions. > > Specifically, the questions I asked on 8/15 have not yet been answered, > and Gary's discussion hadn't converged.
I think the disucssion with Gary has converged. I'm sure Gary will correct me if I've misinterpreted but we seem to be aligned on both the auditing and RBAC requirements. Updated NDMP documents should be out either today or tomorrow. The general opinion seemsed to be that adding two-way encryption to the read-protected password property wasn't worthwhile for this case. I thought this issue was closed. I've been thinking about the separate key discussion and trying to think of a way it would add value for NDMP. The problem is that NDMP clients present a single name/password input dialog box with no reference or indication that there are authentication algorithm options at the protocol level. The general principal of separate keys being appropriate not withstanding, having separate, per algorithm keys in this case may give the perception of added security but, in order to allow clients to negotiate either option, the keys would have to be set to the same value. If the keys are different, each client will either connect or fail to connect based on the client authentication algorithm, because there is no way to instruct a client to specifically use one authentication algorithm or the other. Thus, from an end-user usability perspective, it would seem more straight- forward for the service to provide an 'auth' property rather than options to set multiple keys. Alan
