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

[Anthony Liguori <aliguori@xxxxxxxxxx>]

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