Bill Sommerfeld wrote: > my apologies for taking so long to get back to this. > > On Tue, 2007-07-31 at 23:35 -0700, Alan Wright wrote: >> To be consistent with the guidance given in the PSARC/2007/177 >> opinion, that software packages must not permit operation using >> placeholder sensitive values, the default password is an empty >> string and the NDMP service will not accept client connections >> if the password is an empty string. In order to initiate NDMP >> protocol services, a non-empty password is required, which would >> typically be set using the ndmpadm(1M) command. >> >> The team acknowledges concerns expressed with respect to NDMP >> protocol security but the protocol is external to this case, >> and, as the project is only delivering an NDMP server, there >> is no scope to influence the negotiated client-server security >> implementation. From the same email discussion mentioned above, >> the way forward seemed to be to write an opinion and try to >> progress the protocol security concerns with the appropriate >> standards groups. > > There's a missing piece here. The opinion for 2007/177 says that the > facilities it provides are not sufficient on their own to comply with > the existing Security SWG Policy for storing sensitive data in the > filesystem. > > The Policy is at: > > http://sac.eng/cgi-bin/bp.cgi?NAME=passwords-storage.bp > > or externally at: > > http://www.opensolaris.org/os/community/arc/bestpractices/passwords-files/ > > It may be used but should be augmented with additional obfuscation or > encryption. If you need the cleartext value of the secret to > authenticate, you'll need to use a reversable encryption or obfuscation > mechanism. It's worth noting that a really lame obfuscation mechanism > meets the letter of the policy, but directly storing the sensitive value > does not. > > It's also worth noting that there is much existing practice which > doesn't meet this standard, but there are also new mechanisms available > that weren't there when much of that prior art landed in Solaris. > > In particular, the cryptographic framework also provides mechanisms for > storing sensitive values which have substantially improved security on > systems which include hardware keystores. (and it's worth noting that > CRAM-MD5 is (just barely) a cryptographic protocol).
I feel I need to point out that using the crypto framework keystore capability (via PKCS#11 here isn't actually going to help at all. To access the keys on hardware keystores (or the simulated software one provided by pkcs11_softtoken) you will still need a PIN (really it is a passphrase don't read that its 4-6 digits in length) to pass to the C_Login() function before the token will give you the data or allow you to use it (in the case it can't be extracted but used). It is also worth noting that there is only currently available hardware device that is still supported that has such a keystore, the CA-6000. Which is an expensive card and not common. In the future there will be a driver for the TPM chips so it can be used as a keystore but it will very likley still have the same C_Login() PIN requirement. in.iked and kssl btoh allow using PKCS#11 tokens for key storage however in both of these cases the PIN to access the token that contains the real key is stored on disk in the clear. With the advent of SMF it is near impossible to interact with the boot process so this either has to wait until an admin is logged in and runs an app specific command or we need to store the PIN in the clear on disk. In summary I don't believe that using the crypto framework token interfaces for storage of keys works well in all cases. It does work well for the in.iked and kssl cases because those keys are highly sensitive strong cryptographic keys (RSA private keys). Back to *this* case, the whole protocol has such weak security and authentication anyway that personally I find either the cleartext in permissions protected file or in SMF as per 2007/177 is sufficient for *this* case (remember that the repository file is 600 root:sys). -- Darren J Moffat
