[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Freeipa-devel] SSL



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).

Simo.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]