Re: AW: AW: RADEXT Milestone revisions

["Alan DeKok" <aland@ox.org>]

"Tschofenig, Hannes" <hannes.tschofenig@siemens.com> wrote:
> This work tried to accomplish a different goal. It tried to develop a
> solution for initial enrollment between the RADIUS client and the RADIUS
> server if they are in the same administrative domain. BUT: The problem
> we are dealing with appears if you consider cases where the RADIUS
> client and the RADIUS server are in different administrative domains.

  I think the problems are related.

  The client has to somehow start a trust session with a server.  It
doesn't really matter if the server is in the same administrative
domain or another one.  The "bootstrap" problem still exists.  And the
bootstrap of the remote trust first depends on bootstrapping local
trust.  So why not use the same process for both?

  Within the same domain, the client kickstart proposal works.  Going
across domains, the "local" admin can get a key from the "remote"
admin, and give it to the client.  The client can then use a procedure
similar to kickstart to initiate a session with the remote
administrative domain.

  The problem then is that the client has to manage trust with a large
number of remote domains, and that trust may not be tied to any one
authentication session.  That's a serious problem.

> In the first place I wanted to better understand the problem that needs
> to be solved.

  Exactly.  If it's end-to-end encryption, Diameter would appear to be
the solution.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>