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

[Darran Lofthouse]

On 11/14/2011 03:28 PM, David M. Lloyd wrote:
> I guess I don't really care what we do out of the box. It doesn't really
> change the options on the table.

This thread is really about the out of the box settings ;-)

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

I agree, this part doesn't have a need to be kept in synch with the HTTP 
interface and does make sense to be different.

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