[Freeipa-devel] SSL

[Rob Crittenden]

Simo Sorce wrote:
> On Thu, 2007-07-12 at 10:44 -0400, Rob Crittenden wrote:
>> Simo Sorce wrote:
>>> On Thu, 2007-07-12 at 10:23 -0400, Rob Crittenden wrote:
>>>> Simo Sorce wrote:
>>>>> On Tue, 2007-07-10 at 17:11 -0400, Rob Crittenden wrote:
>>>>>> So I was thinking about the XML-RPC portion of this.
>>>>>>
>>>>>> One thing we'll be doing is setting and resetting user passwords. So we 
>>>>>> should use SSL to protect them, if for no other reaosn.
>>>>>>
>>>>>> So:
>>>>>>
>>>>>> 1. I assume we'll have to use OpenSSL. If there are Python NSS bindings 
>>>>>> I couldn't find them. OLPC may do this work for us 
>>>>>> (http://dev.laptop.org/ticket/855)
>>>>>>
>>>>>> 2. How will we manage trust between the gui and command-line clients and 
>>>>>> XML-RPC server?
>>>>> IF we are going to use kerberos, can't we just use GSSAPI to encrypt
>>>>> traffic?
>>>> I can't find any information on how to do this (GSSAPI over HTTP). Do 
>>>> you have any pointers?
>>> IIRC RFC4559.
>>>
>>> Simo.
>>>
>> Thanks
>>
>> This RFC defines authentication (the Negotiate mechanism).
>>
>> Further in the document is this:
>>
>> 6.  Security Considerations
>>
>>     The SPNEGO HTTP authentication facility is only used to provide
>>     authentication of a user to a server.  It provides no facilities for
>>     protecting the HTTP headers or data including the Authorization and
>>     WWW-Authenticate headers that are used to implement this mechanism.
>>
>>     Alternate mechanisms such as TLS can be used to provide
>>     confidentiality.
>>
>> I did find an expired draft (from 2001) that added SASL support to 
>> HTTP/1.1 via the Upgrade header but then any clients that wanted to use 
>> this would need to add this feature as well.
> 
> Yeah, I remembered there was something but didn't know how far it got,
> not much it seem. That said we could still do encapsulation ourselves,
> but that would probably require modifying too much code and won't be
> xml-rpc compliant, too bad, maybe we can think of something for v2/v3.
> 
>> I wonder if there is a way to have our clients automatically download 
>> the CA certificate after authenticating. It won't impede others from 
>> using our XML-RPC server, they will just need to manually install the 
>> CA. That or we install the CA on client machines as part of our client 
>> configuration mechanism.
>>
>> The on-the-fly method might look something like:
>>
>> Make SSL connection
>> If fail due to lack-of-trust:
>>    Authenticate to HTTP listener using Kerberos
>>    If auth-fails:
>>      print nice error message
>>    else:
>>      download CA cert
>>      Restart request over HTTPS
>> Continue
>>
>> The downside is that this adds a fair bit of complexity and requires 2 
>> listeners.
> 
> My take is this:
> Normal case: During client configuration use the admin credentials to
> connect to the LDAP server and download a CA certificate from there
> (LDAP may also contain the CRL while we are at that), and put it on the
> machine. I guess we can make it available to all browsers somehow ?
> 
> Other cases: let people know where to download the certificate which
> will be published in a standard location on an unprotected page. Also
> let them just use self-signed certificates (take the signature at the
> first connection and save it somewhere and trust it).

Yes, providing a pointer would probably be helpful. The trick would be 
in getting the server to tell the location.

I think we need to revisit the resistance to Apache here. It already 
provides kerberos authentication with ticket forwarding. It seems like 
reinventing the wheel doing it in Python instead. koji/brew use Apache 
as the front-end and it seems to work ok.

rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20070712/50911e54/attachment.bin>