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

[David M. Lloyd]

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


-- 
- DML