[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]

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


-- 
- DML