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

[Darran Lofthouse]

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/
>