>>>>> "Gabriel" == Gabriel López <[log in to unmask]> writes:

    Gabriel> - It is not clear what the Trust Router is. Advanced production routers
    Gabriel> running in institutions? or Is it a new entity every institution should
    Gabriel> deploy?

Every institution must have a trust router announcing its routes and a
trust router that it can use for queries.

It plays the role of SAML metadata in our system.
It could be outsourced.
For example if a SAML federation also wanted to  run ABFAB using AAA
credentials [1]  they could run one trust router that everyone in their
federation used. They'd probably want to make it redundant.

We expect multiple trust routers will esentially be required for
inter-federation use cases.
We expect that some organizations will want to run their own trust
router, so even in the single federation use case it is unlikely that
there will be only one trust router.

However it is not required that every institution needs to deploy a trust router.

    Gabriel> - Does the term Trust Path refer to the AAA path/TRs path/mixed?

Not exactly.  I'm a security person so I think of things in terms of
attacks.  The trust path is an ordered set of realms who are in a
position to man-in-the-middle your communication.  We probably want a
definition that's more positive than that, but I believe that other than
explaining why the set is ordered, my definition is accurate.

Your AAA message goes from something near the RP to the radsec server
near or at the IDP assuming you're actually using RADSEC.
However other realms help set up the technical and policy trust required
to send that message.
    Gabriel> - " 4.  The Relying Party contacts a trust router in Realm B (using its
    Gabriel>        permanent identity in Realm A)" 	

    Gabriel>     So Trust Router in realm B should "delegate" the authentication of
    Gabriel> RP to realm A, an so on ....?

Sometimes.
We're in ABFAB, so we would be delighted if people used
draft-ietf-abfab-gss-eap for this authentication.
In that case, yes, the authentication is delegated.

however, you could also imagine using some other mechanism: TLS with
client certs, Scott's SAML ECP mechanism, etc.
I'd expect that draft-ietf-abfab-gss-eap will be the mandatory to
implement mechanism here.



    Gabriel> Section 4:

    Gabriel>     - The list of security properties required by the Trust Routers
    Gabriel> would help to a better understanding of the protocol :)

* hop-by-hop integrity
* peer entity authentication
* for some deployments confidentiality

We do not plan to provide end-to-end data origin authentication because
one of the assumptions here is that there's no global credential
infrastructure shared by everyone that could be used to validate that.

We also tend to require attribute exchange from the authentication
process; something that can use GSS with naming extensions or use
attribute certificates or SAML assertions ends up being fairly close to
required.

    Gabriel> Sections 5 and 6:

    Gabriel> - Do you have in mind some transport and communication protocols for the
    Gabriel> Trust Path Query and Temporaly Identity Request? I understand this
    Gabriel> document describes the general idea, the questions are just to know if
    Gabriel> you have in mind some answers already thought.

Yes. see draft-howlett-radsec-knp for one approach.
Alan has proposed doing this entirely within RADIUS as well.

    Gabriel>      Why does the RP ask every router in the federation? I mean, if
    Gabriel> requesting TR A, which by means of some "advanced" routing protocol is
    Gabriel> able to know the better path from A to D, after the first request the RP
    Gabriel> knows TR D or even idP.

I don't think it does query every router in the federation.
It does establish an identity with every router it needs to talk to.

    Gabriel> Section 6.
    

    Gabriel> "When a Temporary Identity is requested, a Trust Router
    Gabriel>    will provision a new identity in its local RADIUS infrastructure that
    Gabriel>    can be used by the Relying Party to communicate with the Trust Router
    Gabriel>    or RADIUS/RADSEC server that represents the next step in the Trust
    Gabriel>    Path."


    Gabriel>   Then, every institution hosts a TR and a Radius/RadSec server, this
    Gabriel> should be clarified in the diagram and the introduction.

Every TR needs to be able to provision identities somewhere.
See above for how many TRs you need.

    Gabriel> It is not clear for me the relationship between Trust Path Queries and
    Gabriel> Temporaly Identity Requests. When are they sent from the RP to the TR?
    Gabriel> What is the global number of message exchanged between RP, TRs, RADIUs,
    Gabriel> etc..?

OK, let's take the example  from Margaret's draft.
I'm going to try and enumerate all the traffic .

1) Trust routers exchange and flood routes. I don't know what the order
of messages of this exchange is, but I'm sure people familiar with
routing protocols do. This is amortized across all uses of the trust
infrastructure. Messages are generated when routes change.

2) RP queries Tr A to get the path. Assuming local authentication
probably effectively 2 messages. Not two packets; authentication
protocols and TCP can be chatty, but I'm going to use this as the base
for number of messages.

3) RP asks TR B for identity (2 messages); amortized across all uses of
this identity

3a) TR B proxies eap back to A (2 messages)

4) RP asks TR C for identity (2 messages)

4A) TR C proxies back to B (2 messages)

5) RP asks TR D for radsec ID (2 messages)

5A) proxy back to C for auth (2 messages)


6) Subject authentications to RP (2 messages)

6A) Proxy that from RP to D's radsec server (2 messages)

Caching is important.
You want temporary identities to be reused.  So on the next time the
same user authenticates:

I) RP notices it has a credential cached (0 messages)

II) Subject authentication to RP (2 messages)

II.1) Proxy directly to D RADSEC (2 messages)