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

I guess I don't really care what we do out of the box. It doesn't really change the options on the table.

For example using a key-based mechanism for host-controller-to-domain-controller authentication would be much more convenient than certificate authentication.

On 11/14/2011 09:21 AM, Darran Lofthouse wrote: > If you don't keep the two in synch out of the box we are going to end up > with two completely different set ups one for HTTP and one for Native - > if tools like the CLI are ever going to be updated to support both > transports then the authentication configuration will be completely > different depending which approach is being used. > > Regards, > Darran Lofthouse. > > > On 11/14/2011 03:17 PM, David M. Lloyd wrote: >> 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/ >>>> >> >>