Open Stack

On Fri, 2013-10-11 at 17:49 +0000, Sangeeta Singh wrote:
> Hi,
> 
> 
> I had some questions about the trusted messaging project.
> 

> >      1. During your design did you consider a kerberos style
> >         ticketing service for KDS? If yes what were the reasons
> >         against it?
> >      2. The Keystone documentation does say that it can support
> >         kerberos style authentication. Are there any know
> >         implementations and deployments?
> >      3. Does the secured messaging framework supports plugging in
> >         one's own key service or is there a plan of going in that
> >         direction. I think that would something that would be useful
> >         to the community giving the flexibility to hook up different
> >         security enforcing agents similar to the higher level
> >         message abstractions to allow multiple message transport in
> >         the oslo messaging library.
> > I am interested to know how can one use the proposed framework and
> > be able to plugin different key distribution mechanism.
> > 

Just to keep the list in the loop, as we had a quick conversation on
IRC.

1. we did consider using Kerberos, however we felt that introducing such
a big dependency point-blank was a bit of a stretch, plus we are trying
to address issues for which Kerberos does not have standard answers
(yet), like for group messages or broadcasts (and the current solution
doesn't work well for this last case either). So in the end I proposed a
simplified system that would allow us to experiment with all the pieces
and introduce the necessary interfaces in more agile way. The aim has
always been to experiment and find out the corner cases and be able to
change the system if needed.

2. KDS is a symmetric key management system exclusively dedicated to the
RPC messaging layer, it has nothing to do with Keystone authentication.
Keystone can use HTTP authentication so you can plug in things like
mod_auth_kerb in apache in front of keystone. Same for x509 certs, but
again these are orthogonal uses.

3. As I explained on IRC, the idea for the secure messaging  code was to
draw a 'template' for the client side. So that additional methods could
be plugged in. The securemessage class is quite abstract and all
self-contained, so that it should be easy to drop in a replacement that
uses a different security mechanism.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York