From: Daniel C. <dc...@po...> - 2007-03-30 18:29:16
|
About 2 years and 9 months ago (tempis fugit and all that) I posted to the mailing list w.r.t. the Security Model of STAF [1]. At that time it didn't look like the model would support use on production machines, since the security looked worse than rsh .rhosts, whereas I try to steer my site towards Kerberos/SSL/SSH, due to reasons such as those mentioned in Abe Singer's excellent "no plaintext passwords" [2] article. My site is again looking at STAF/STAX, so I am again doing a security evaluation. This is what I have gathered via some research: R1. When using IP-based authentication, STAF now does "a reverse name lookup and look for trust matches against it and the IP address (with the IP address taking precedence)." (Charles Rankin); so this would seem to imply that that type of security is now equivalent to rsh .rhosts, and if box "a" is trusted by box "b" in this way, box "c" couldn't just tell box "b" that it is box "a", it would also have to have box "a"'s IP address (and presumably have knocked box "a" off of the network somehow). R2. There is a new INTERFACE [3] feature that allows different methods of computer-to-computer communication as plugins; however unencrypted TCPIP is still the default, and there are no other plugins (such as SSL) currently available; this might change in the next few months (presumably if IBM Legal decides that OpenSSL's license is compatible with the CPL or something like that). R3. There is a new AUTHENTICATOR [4,5] feature that allows for the definition of new authentication schemes, however besides an example there are no authenticators currently available other than the default IP-based security, and possibly user/password based security. (BTW could someone give me a pointer to how this user/password database is maintained? So far I've been unable to find that doc). So my overall view is that it looks like: * There is now a decent one-way only (although plain-text-password based) trust model when using user/password security; this security would seem to be approx. equivalent to telnet. * The infrastructure has been improved to allow for security that isn't relatively easy to crack. * In general the plugins to make use of that infrastructure either have not been written or are not available yet for bureaucratic/legal reasons. A few questions: Q1. Has anyone done any work to wrap STAF's network communication using another tool for security, such as stunnel [6]? Unless I am wrong on some of my above research, I think this is what I will look into next. Q2. Does the SSL plugin I've seen mentioned do encryption, or encryption and certificate verification (e.g. if a SSL Cert is generated for each machine, can those certs be used as the basis of a bidirectional trust relationship / authentication / to defeat man in the middle attacks)? Q3. Am I correct in thinking that if I used an AUTHENTICATOR with username/password authentication, this would be in a single direction only (i.e. the machine I am connecting to now has a good reason to trust me, but I have no reason to believe the machine I connected to is the machine I think it is other than IP "security", so man-in-the-middle attacks are still possible)? [1] [staf-users] Security model of STAF? http://tinyurl.com/yp5a5m [2] no plaintext passwords http://www.usenix.org/publications/login/2001-11/pdfs/singer.pdf [3] [ 550251 ] Communication Interface Enhancements http://tinyurl.com/2nhrwv [4] [ 627135 ] Enhanced security http://tinyurl.com/2o9xcl [5] Re: [staf-devel] Authenticator Service http://tinyurl.com/2k2dn8 [6] Stunnel -- Universal SSL Wrapper http://www.stunnel.org/ Thanks, -- Daniel Clark # http://dclark.us # http://opensysadmin.com |