[prev in list] [next in list] [prev in thread] [next in thread]
List: ceph-devel
Subject: [ceph-devel] Authentication Scheme
From: Yehuda Sadeh Weinraub <yehudasa () gmail ! com>
Date: 2009-08-24 20:44:47
Message-ID: a37615150908241344l172e107fx643d51a641ac9db6 () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
We were doing some thinking over what authentication scheme we should be
using. We discovered that we're trying to reinvent kerberos time and time
again. The main two issues with kerberos were that it was going to add major
complexity to the deployment, and implementing it would be something we
didn't really want to invest at this point.
So, we decided on a kerberos-like solution, which is a basically a kerberos
subset, adapted to ceph.
In short, when a principle authenticates itself with a different entity, it
first needs to create a auth-session with the authenticator. Once this has
been done, the principle can request a ticket to connect to another service,
and then initiates a session request to that service using that ticket. The
monitor at this point will serve the authenticator; it will hold the
shared-secrets database for all the different entities. Here's a more
detailed description:
First, the principle has to authenticate with the authenticator. A
shared-secret mechanism is being used, and the negotitaion goes like this:
A = Authenticator
P = Principle
S = Service
1. Obtaining principle/auth session key
P->A : principle_name, principle_addr. authenticate me!
...authenticator does lookup in database...
M->P : A= {principle/auth session key, validity}^principle_secret (*)
B= {principle ticket, validity, principle/auth session
key}^authsecret
(*) annotation: ^ signifies 'encrypted by'
At this point, if is genuine, the principle should have the principle/auth
session key at hand. The next step would be to request an authorization to
use some other service:
2. Obtaining principle/service session key
P->M : B, {principle_addr, timestamp}^principle/auth session key. authorize
me!
M->P : E= {service ticket}^svcsecret
F= {principle/service session key, validity}^principle/auth session
key
Note that steps 1 and 2 are pretty much the same thing; contacting the
authenticator and requesting for a key.
Following this the principle should have a principle/service session key
that could be used later on for creating a session:
3. Opening a session to a service
P->S : E + {principle_addr, timestamp}^principle/service session key
S->P : {timestamp+1}^principle/service/session key
Now, the principle is fully authenticated with the service. So, logically we
have 2 main actions here. The first one would be to obtain a session key to
the service (steps 1 and 2), and the second one would be to authenticate
with the service, using that ticket.
* A problem that we face when dealing with a distributed system such as ceph
is that a single client may need to negotiate with multiple services (e.g.,
many osds). We don't want to have it authenticate itself with each and every
entity that represents the same service. On the other hand, for obvious
reasons we don't want to keep a single shared secret for all of the
entities.
So, the solution we came up with is using different keys for the services to
authenticate themselves (e.g., osd authenticates itself) and different keys
for the users (e.g. clients) to create sessions with the services (e.g.
osds). The latter keys will be temporary and will be regenerated after a
relatively short period of time. The monitor will be responsible for
distributing those secret keys to the services every time T. Due to the fact
that it can take quite a long time for the new keys to propagate through the
system, each service will hold the latest 3 versions of the keys and clients
authentication should be verified using all keys. So, there are always 3
valid keys to use the services: the previous-key, current-key and next-key.
The clients always gets the current key. And the clients and services must
renew and reverify their keys at least once every time T.
As always, questions/remarks are more than welcome.
Yehuda
[Attachment #5 (text/html)]
We were doing some thinking over what authentication scheme we should be using. We \
discovered that we're trying to reinvent kerberos time and time again. The main \
two issues with kerberos were that it was going to add major complexity to the \
deployment, and implementing it would be something we didn't really want to \
invest at this point.<br> So, we decided on a kerberos-like solution, which is a \
basically a kerberos subset, adapted to ceph.<br>In short, when a principle \
authenticates itself with a different entity, it first needs to create a auth-session \
with the authenticator. Once this has been done, the principle can request a ticket \
to connect to another service, and then initiates a session request to that service \
using that ticket. The monitor at this point will serve the authenticator; it will \
hold the shared-secrets database for all the different entities. Here's a more \
detailed description:<br> <br>First, the principle has to authenticate with the \
authenticator. A shared-secret mechanism is being used, and the negotitaion goes like \
this:<br><br>A = Authenticator<br>P = Principle<br>S = Service<br><br>1. Obtaining \
principle/auth session key<br> <br>P->A : principle_name, principle_addr. \
authenticate me!<br><br> ...authenticator does lookup in database...<br><br>M->P : \
A= {principle/auth session key, validity}^principle_secret (*)<br> B= \
{principle ticket, validity, principle/auth session key}^authsecret<br> <br>(*) \
annotation: ^ signifies 'encrypted by'<br><br>At this point, if is genuine, \
the principle should have the principle/auth session key at hand. The next step would \
be to request an authorization to use some other service:<br> <br>2. Obtaining \
principle/service session key<br><br>P->M : B, {principle_addr, \
timestamp}^principle/auth session key. authorize me!<br>M->P : E= {service \
ticket}^svcsecret<br> F= {principle/service session key, \
validity}^principle/auth session key<br> <br>Note that steps 1 and 2 are pretty much \
the same thing; contacting the authenticator and requesting for a \
key.<br><br>Following this the principle should have a principle/service session key \
that could be used later on for creating a session:<br> <br>3. Opening a session to a \
service<br><br>P->S : E + {principle_addr, timestamp}^principle/service session \
key<br>S->P : {timestamp+1}^principle/service/session key<br><br>Now, the \
principle is fully authenticated with the service. So, logically we have 2 main \
actions here. The first one would be to obtain a session key to the service (steps 1 \
and 2), and the second one would be to authenticate with the service, using that \
ticket.<br> <br>* A problem that we face when dealing with a distributed system such \
as ceph is that a single client may need to negotiate with multiple services (e.g., \
many osds). We don't want to have it authenticate itself with each and every \
entity that represents the same service. On the other hand, for obvious reasons we \
don't want to keep a single shared secret for all of the entities.<br> So, the \
solution we came up with is using different keys for the services to authenticate \
themselves (e.g., osd authenticates itself) and different keys for the users (e.g. \
clients) to create sessions with the services (e.g. osds). The latter keys will be \
temporary and will be regenerated after a relatively short period of time. The \
monitor will be responsible for distributing those secret keys to the services every \
time T. Due to the fact that it can take quite a long time for the new keys to \
propagate through the system, each service will hold the latest 3 versions of the \
keys and clients authentication should be verified using all keys. So, there are \
always 3 valid keys to use the services: the previous-key, current-key and next-key. \
The clients always gets the current key. And the clients and services must renew and \
reverify their keys at least once every time T.<br> <br><br>As always, \
questions/remarks are more than welcome.<br><br>Yehuda<br><br>
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Ceph-devel mailing list
Ceph-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ceph-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic