Re: [jboss-as7-dev] How hard would it be to support key based auth by default to make life simpler and more secure ?

This I don't buy. Where did this requirement come from? On 11/14/2011 09:13 AM, Darran Lofthouse wrote: > The problem is whatever we can use for the Native interface we also need > to be able to use for the HTTP interface, for the SASL mechanisms we are > using so far there is a corresponding mechanism that can be used with > HTTP. > > Regards, > Darran Lofthouse. > > On 11/14/2011 03:10 PM, David M. Lloyd wrote: >> On 11/14/2011 05:40 AM, Max Rydahl Andersen wrote: >>>>>> >>>>>> These will make all examples that uses maven deploy plugin, cli >>>>>> scripts, arquillian, jboss tools etc. to somehow >>>>>> either tell users to type in their username and full password in >>>>>> clear text in pom.xml and other files. >>>>>> >>>>>> Which sounds worse to me than a default locked down to only >>>>>> localhost…but I'm not a security expert :) >>>>>> >>>>>> I was wondering how hard it would be to make the authentication >>>>>> support key based auth by default and we make >>>>>> the tools use ${user.name} and ${user.home}/.jboss/default.pub and >>>>>> .priv (or some other name) for the public/private keys ? >>>>> >>>>> You would need a key-based SASL authentication mechanism. There >>>>> are no >>>>> standard ones as of right now. If you know of a key-based SASL >>>>> mechanism that you think we should support, let me know and we'll >>>>> evaluate it. >>>> >>>> We would have to do noauth + SSL + trust. I think it's an option >>>> worth considering. The big problem though is that we have to have a >>>> setup process to generate the certs, which is greater complexity >>>> than the user/pass option. We would have to generate a host key pair >>>> and a client key pair. >>> >>> >>> I'm not an expert on these things at all but eclipse uses >>> http://www.jcraft.com/jsch/ to manage and create ssh keys and uses >>> the standard .ssh location's etc. >>> >>> Is something additional needed ? >> >> Yeah, an authentication mechanism that uses SSH keys. There is none >> currently. >> >> Again, we can use any combination of SASL and TLS for authentication. >> Neither spec (to my knowledge) has a simple key-based client >> authentication mechanism (TLS is cert-based; SASL could support such a >> mechanism but none presently exist). If such a mechanism were to be >> defined, we could evaluate using it. If we were to use such a >> mechanism, we would obviously want to have good tooling to back it up. >> Perhaps you might even considering contributing one (though I'd strongly >> recommend consulting with security experts if you do). >> >> As an aside, as far as I can tell SASL has the best shot at supporting >> client key authentication as it has the simplest SPI. JSSE has a >> similar conceptual model but is considerably more complex >> implementation-wise and I'd be very cautious about defining new >> algorithms for it. Yeah this excludes HTTP (unless something like this >> [1] gets resurrected). However I'm quite skeptical that HTTP would be >> expected to use the same mechanism. >> >> Also, even if we did support such an algorithm, the initial server-side >> key generation doesn't necessarily have to impact boot time; in fact it >> should only come into play either (a) when a user explicitly requests >> the server key, or (b) when a user attempts to authenticate using >> key-based authentication. >> >> [1] https://datatracker.ietf.org/doc/draft-nystrom-http-sasl/ >>