Subject: [abfab] New Internet-Draft on Multihop Federations

From: Margaret Wasserman <[email-masked]>
Date: Tue, 5 Jul 2011 12:15:20 -0400

Hi All,

I posted a new Internet-Draft yesterday on ABFAB Multihop Federations.  

I had to submit the draft via e-mail because of a problem using the ID submission tool, and it doesn't seem to have been posted to the Internet-Drafts archive yet.  I have posted it on the Project Moonshot site, though, and it can be found here:

http://www.project-moonshot.org/sites/default/files/draft-mrw-abfab-multihop-fed-00.txt

The abstract for this draft is:
Abstract

   This document describes a mechanism for establishing trust across a
   multihop federation within the Application Bridging for Federation
   Beyond the Wed (ABFAB) framework.

   This document introduces a new ABFAB entity, the Trust Router.  Trust
   Routers exchange information about the availability of Trust Paths
   across a multiphop federation.  They can be queried by a Relying
   Party to obtain the best Trust Path to reach a RADIUS or RADSEC
   server in a given realm.  They also provide temporary identities that
   can be used by a Relying Party to traverse a Trust Path.

   This document is currently limited to discussing a proposed mechanism
   to achieve a multihop federation in the ABFAB framework.  Later
   versions of this document (or companion documents) will describe the
   protocols and algorithms in more detail.
The document doesn't, yet, contain a full protocol specification,  just a high-level "boxes and
arrows" description of how a multihop federation could work.   This draft intentionally subsumes the role of the Key Negotiation Protocol (KNP) into a new ABFAB entity called a Trust Router.

Hopefully this will serve as a useful starting place for further discussion.  Feedback will be appreciated!

Margaret

---

From: Josh Howlett <[email-masked]>
Date: Tue, 5 Jul 2011 20:18:37 +0000

Hi Margaret,

Some feedback, as requested:

 - Section 1

Sorry if this seems trivial! The term 'federation' is quite overloaded and
means different things to different people. I suggest explicitly calling
out what I think you mean, which is a 'multihop AAA fabric'. It's an ugly
circumlocution, but at least it can't be misunderstood or (worse)
misinterpreted.

 - Section 1.1

Step 3. Substitute 'does not have direct access' with 'does not share a
relationship with'? 'Access' is perhaps too ambiguous.

Steps 4-6. I think it would be useful to explain why the RP is using an
identity to "contact" the trust routers in the consecutive realms. It
might not be obvious to the reader that the RP is building a transitive
chain of trust by walking the trust path. I suggest explaining this right
at the start of section 1.1.

Obviously an understanding of KNP is an essential part of this. I wonder
if it's worth including some discussion of KNP. On a more general note,
what is your opinion as to how this draft and KNP inter-relate - should
they remain distinct documents, or be combined somehow?

(Great ASCII art in that figure BTW)

 - Section 4

Why can't realm names be hierarchal? It's true that the NAI has no concept
of a hierarchal realm component, but couldn't we choose to interpret a
hierarchy here? Trust Path aggregation could be useful.

 - Section 5

Why query (pull) rather than push? One drawback with pull, perhaps, is
that nervous relying parties will tend towards polling as fast as they
can, rather than as regularly as the upstream trust router itself receives
updates from its peers (which would be more efficient).

Hope that helps, Josh.

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG

---

From: Nico Williams <[email-masked]>
Date: Tue, 5 Jul 2011 17:32:27 -0500

> circumlocution, but at least it can't be misunderstood or (worse)

"Federation" is a difficult word.  Would it be fair to say here that
"federation" means "set of trust cross-domain/realm paths"?

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Tue, 05 Jul 2011 18:53:38 -0400

>>>>> "Nico" == Nico Williams <[email-masked]> writes:

    Nico> On Tue, Jul 5, 2011 at 3:18 PM, Josh Howlett <[email-masked]> wrote:
    >> Â - Section 1

    Nico> "Federation" is a difficult word.  Would it be fair to say here that
    Nico> "federation" means "set of trust cross-domain/realm paths"?

I think we should be consistent with the proposed abfab architecture
draft.

That document uses the term federation. I think we should too and refer
back to that document for its meaning.

---

From: Gabriel López <[email-masked]>
Date: Wed, 06 Jul 2011 10:31:57 +0200

Hi,

> they remain distinct documents, or be combined somehow?
A few comments:

Section 1:

- I think this document should include, in section 1 or in a motivation
section, a clear text of why it is necessary this multihop
infrastructure. I mean, What is the target problem or use-case to be
solved? For people who has not read before this idea is very difficult
to catch the motivation.

- It is not clear what the Trust Router is. Advanced production routers
running in institutions? or Is it a new entity every institution should
deploy?
- Does the term Trust Path refer to the AAA path/TRs path/mixed?

Section 1.1.

- I think the RADIUS or RadSec server should be included in the diagram
(even if it is co-located with the idP)

- " 4.  The Relying Party contacts a trust router in Realm B (using its
       permanent identity in Realm A)" 	

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

Section 1.2

    Does the term Trust Router Protocol refer to a "secure" routing
protocol?

Section 4:

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

Sections 5 and 6:

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

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

Section 6.

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

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

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

Sorry, maybe these are fool questions, as said before, I understand this
is the general idea, I just try to understand it :)

Thanks in advance and regards, Gabi.

-- 
----------------------------------------------------------------
Gabriel López Millán
Departamento de Ingeniería de la Información y las Comunicaciones
University of Murcia
Spain
Tel: +34 868888504
Fax: +34 868884151
email: [email-masked]

---

From: Josh Howlett <[email-masked]>
Date: Wed, 6 Jul 2011 08:52:49 +0000

(Adding Abfab to the distribution, on the assumption that Sam accidentally
dropped it in his response)

>    Nico> "federation" means "set of trust cross-domain/realm paths"?

The draft seems to use that meaning and also one of the defined SAML
meanings (from the SAML Glossary):

   This term is used in two senses in SAML:
      a)	The act of establishing a relationship between two entities.
      b)	An association comprising any number of service providers and
identity providers.

BGP has an unambiguous taxonomy (autonomous systems, confederations and so
forth) to describe these kinds of actors and associations in the routing
world, and I suspect we need to develop something similar or we'll have
terrible confusion. It's possible (and I hope) that we may be able to
borrow isomorphic terms from established taxonomies, but this will require
some thought.

>back to that document for its meaning.

Having said all that, I do agree with Sam that consistency trumps
accuracy, at least for now.

Josh.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 06 Jul 2011 16:21:49 -0400

>>>>> "Gabriel" == Gabriel López <[email-masked]> 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)

---

From: Gabriel López <[email-masked]>
Date: Thu, 07 Jul 2011 08:55:07 +0200

Hi Sam,

> It plays the role of SAML metadata in our system.
ok, although it runs federation routing and topology information, and
forwards eap authentications. It plays a lot of roles :)

> However it is not required that every institution needs to deploy a trust router.
ok
> However other realms help set up the technical and policy trust required
I can understand the AAA path in this case, but l think this mixed path
is very complicated. If every realm implements this functionality like a
AAA server it would be more interesting.
> * for some deployments confidentiality
The last comments clarifies this point
> infrastructure. Messages are generated when routes change.
This is an important point that may required another important number of
exchanges, in order to build and exchange the federation topology (I'm
thinking here in something like eduroam) and to query that path by the
RP (although I suppose here only 2 messages are needed)
Have you analysed how this process (I count 18 messages for 4 realms
without routing and attribute request exchanges) could affect specific
services like SIP?
 
Thanks a lot for your comments Sam, I think this explanation (completed
with the routing part) should appear in the next version.

Best regards, Gabi.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 07 Jul 2011 10:56:16 -0400

>>>>> "Gabriel" == Gabriel López <[email-masked]> writes:

    Gabriel> Hi Sam,

    >> It plays the role of SAML metadata in our system.
    Gabriel> ok, although it runs federation routing and topology information, and
    Gabriel> forwards eap authentications. It plays a lot of roles :)

The trust router does *not* forward eap authentications to the end
service or user's IDP, no.  A trust router will act as a service and in
that role may handle authentications the same as any other service.

    >> However it is not required that every institution needs to deploy a trust router.
    Gabriel> ok
    >> However other realms help set up the technical and policy trust required
    Gabriel> I can understand the AAA path in this case, but l think this mixed path
    Gabriel> is very complicated. If every realm implements this functionality like a
    Gabriel> AAA server it would be more interesting.

It would have significantly worse privacy and performance characteristics.
    Gabriel> Have you analysed how this process (I count 18 messages for 4 realms
    Gabriel> without routing and attribute request exchanges) could affect specific
    Gabriel> services like SIP?

So, currently ABFAB does not target SIP.
In general I'd expect you to use the same SIP registration server
regardless of your current location.

However if we did target SIP and you did happen to use a registration
server far away from your IDP, it would mean that you'd need 18 messages
and introduce some delay for your first registration.  In most sip
deployments beyond that, the number of messages would be the same as it
is with some central authentication server after that because the
registration would be cached.

so, it might take a couple of seconds longer the first time your phone
boots in the morning.

---

From: Nico Williams <[email-masked]>
Date: Thu, 7 Jul 2011 10:20:37 -0500

> registration would be cached.

Also, presumably the trust path routes won't change/flap anywhere near
as often as IP routes, right?  So it should be safe to cache these
paths for quite a while.  Also, validation of cached paths could be
done asynchronously, in the background.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Thu, 07 Jul 2011 11:32:52 -0400

>>>>> "Nico" == Nico Williams <[email-masked]> writes:

    Nico> Also, presumably the trust path routes won't change/flap anywhere near
    Nico> as often as IP routes, right?  So it should be safe to cache these
    Nico> paths for quite a while.  Also, validation of cached paths could be
    Nico> done asynchronously, in the background.

Well, I'd just cachec the end-to-end key and what realm it mapped to. No
need to cache the root; caching the key gets you the same effect.  But
yes, you *could* cache the route and validate asynchronously.

    Nico> Nico
    Nico> --

---

From: Alan DeKok <[email-masked]>
Date: Thu, 07 Jul 2011 19:05:01 +0200

Nico Williams wrote:
> as often as IP routes, right? 

  The commercial integrators take *months* to set up a new connection.
So changes should be rare.

> So it should be safe to cache these
> paths for quite a while.

  A TTL of a day or so would probably be fine.

  Alan DeKok.