Subject: [abfab] Trust router work

From: Alan DeKok <[email-masked]>
Date: Thu, 29 Mar 2012 12:58:34 +0200

My take-away from the meeting today is this:

- the documents talk about solutions instead of problems.

- perhaps this is because they use terms from a particular design,
  rather than generic terms

- knowing WHO to talk to is a separate problem from HOW to talk to them

  My comments were that the "how" portion should be relatively simple.
I assume a base set of interconnections done via RadSec.  These
connections are provisioned off-line (contracts, legal, phone calls, etc.)

  If A has provisioned a RadSec connection to B, then they share a TLS
session key.  That key can be used to derive additional credentials.

  e.g. A connects to B, and B to C.  If A wants an introduction to C, it
asks B how to find C.  B responds, and gives A and identity based on the
A->B TLS data.  A then connects to C, using the credentials derived from
B.  C can then use it's connection to B in order to validate those
credentials.

  The process can be chained, to allow A to connect to B, then C, then
D, etc.  Each node can decide whether or not it provides an introduction
to another one.  This means that B (above) and be a "registrar", with a
list of members.  It will introduce the members to each other, but not
to anyone else.

  This design is simple, and flat.  It means that each system is nearly
identical.  There are no central registration authorities, except by
prior convention.

  Alan DeKok.

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Fri, 30 Mar 2012 19:49:41 +0200

> identical.  There are no central registration authorities, except by

That's precisely my take as well. You can dynamically build trust links out
of a few previously established ones, that come from what we could call
natural external conventions.

Shall the problem statement go in that way?

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

---

From: Alan DeKok <[email-masked]>
Date: Sat, 31 Mar 2012 10:27:30 +0200

> Shall the problem statement go in that way?

  I talked with Josh && Sam a bit more.  I think we're converging, but
there is still some difference.

  I think the dynamic trust links are the best way to do the
introductions.  I think the RADIUS routing protocol needs more
definition before I understand it.

  Alan DeKok.