WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [RFC][PATCH] Secure XML-RPC for Xend

To: Ewan Mellor <ewan@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [RFC][PATCH] Secure XML-RPC for Xend
From: Anthony Liguori <aliguori@xxxxxxxxxx>
Date: Wed, 14 Jun 2006 12:34:26 -0500
Cc: Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 14 Jun 2006 10:34:58 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20060614084348.GF5840@xxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <A95E2296287EAD4EB592B5DEEFCE0E9D4BAA21@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <4489652F.7040702@xxxxxxxxxx> <20060614084348.GF5840@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 1.5.0.4 (X11/20060612)
Ewan Mellor wrote:
On Fri, Jun 09, 2006 at 07:10:23AM -0500, Anthony Liguori wrote:
It's tempting to use https/basic auth since it seems like it ought to just work with existing clients. However, that doesn't appear to be the case.

Python doesn't seem to provide any real support for authentication out-of-the-box. It wouldn't be that hard to add but neither was an SSH transport.

Personally, I'd use SSL to secure the connection and authenticate the server
to the client, but I'd not use HTTP's basic auth -- I'd add a "login" message
that checked the username/password using PAM, in other words, have the
authentication of the user handled at Xend's level, rather than relying on the
transport/session layer to do it.  Like you say, HTTP's authentication stuff
doesn't seem to be well supported.

I see three ways of making this work.

1) Have a login message that returns some sort of random key. This key would have to be passed to all other RPCs. The key would have to come from a good random source and be sufficiently large that a brute-force attack wasn't likely. We would have to introduce some sort of way to expire these keys though (to prevent a user from reusing a key from a previous authentication after the root user password has changed).

2) Pass the credentials to every RPC (this is essentially what HTTP Basic auth does). The good thing about this is that it solves the above key expiration problem but PAM authentication can be pretty heavy weight depending on how your PAM is configured. This could prove rather nasty.

3) Make sure the client uses Keep-Alive and have the login RPC authentication the rest of the session. I like this approach the most since it avoids the problems with both of the above. Of course, it assumes your client library is capable of doing XML-RPC over a Keep-Alive session which probably isn't a good assumption.

What do you think?  Is there another way of doing this that I'm missing?

The plus side of using the login RPC is that with stunnel it will be pretty easy to implement on the server end.

The other problem is that Python doesn't provide support for certificate verification. That's okay if you're just using Python to screen scrap but if you're in an enterprise environment it's not a very good thing.

The other problem I'm concerned about is certificate management on our end. The average user is going have to end up using snake oil certs and I've always found configuring these things to be a real pain.

It's only not a pain with SSH because your distro has set it up for you to
generate a key at install time.  Hopefully, we could arrange or rely upon the
distros to arrange a similar thing for Xend.

It's worse because SSL assumes that there is a single root-of-trust (namely Verisign). Properly signed certs are expensive. Managing snake oils certs becomes a PITA.

I still think HTTPS is worth doing because it will be useful to an awful lot of clients.

Regards,

Anthony Liguori

Ewan.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel