I was worried that I did not understand this message from Sam, so I have
done a more detailed walk through that what Sam presented here. This is
appended at the end of this message for any curiosity seekers. Based on the
walk through I ended up with a number of questions that I would like to get
answers to.
In this walk through I have made some "simplifying" assumptions that make
the model cleaner but do not reflect the reality as it was given to me by
Sam and Margaret last week. Specifically, I assume that the trust router
associated with a AAA proxy/server has the ability to fully modify the key
table dynamically. Per Sam this is not a correct statement for Free Radius.
QUESTIONS:
1. To what degree do the trust router components tightly coupled to the AAA
proxy on the Relying Party and the IdP need to get the Trust Route flooding
information?
If the trust router next to the RP needs to talk to different trust
infrastructures based on COI, then it needs to know what COIs are in each
Trust Router.
In a private mail to Sam & Margaret, I suggested a reason why the trust
router next to the IdP might need to get the same information.
2. To what degree does a Trust Router in the system have a special
relationship with the IdP(s) that authenticate the Trust Route
infrastructure.
It is my opinion that there will be one (or more) TRs that are
"privileged" in that they will have a pre-configured existing relationship
with the trust router IDP entity (TR-IDP). If there are multiple TRs in a
web, not all of the TRs may have this "privileged" relationship and if there
are multiple "clones" of TR-IDP or multiple IDPs that can allow access to
the TR COI then 1) every IDP has some TR which is in a privileged
relationship and 2) a single TR may have a privileged relationship with zero
or more IDPs.
3. What information does the RP AAA proxy need for indexing of the temp ids
for a given IdP's AAA proxy server?
At a minimum I think this is the COI, the APC, the IdP Server Realm..
Additionally one would have the keys, the temp id and the lifetime of the
temp id.
Jim
Entities in the walk through:
User - This the person trying to get a service
RP-Service - This is the service provider that the user is trying to get to
RP-AAA - AAA proxy internal to the RP sphere
RP-AAA-TR - Trust router component - tightly coupled to the RP-AAA - also
tightly coupled to TR as it knows the set of trust routers it can talk to
TR - Centralized Trust Router
TR-IDP - IDP which issued credentials to TR, RP-AAA-TR and IDP-AAA-TR
TR-IDP-AAA - AAA proxy associated with TR-IDP
IDP - IDP which issued credentials to User
IDP-AAA - AAA Proxy associated with IDP
IDP-AAA-TR - Trust router component associated with IDP-AAA
Ports:
2083 - TLS/TCP port for RadSec
666 - TLS/TCP port for Trust Router (this port is a figment of my
imagination and is not a religious statement)
COI:
COI-TR - Trust routing COI consists of {"IDPs":["TR-IDP"], "RP":["TR",
"IDP-AAA-TR", "RP-TR"]}
COI-Service - COI that includes the user {"IDPs":["IDP"],
"RP":["RP-Service"]}
In deference to Josh, I am assuming that there are no certificates in this
system. I thus expect that all TLS sessions using GSS-EAP for
authentication are going to be anonymous-anonymous DH and all TLS sessions
for RADIUS will use a PSK or pre-configured public key unless otherwise
stated.
Flow:
1. User opens TLS/TCP:XXX session to RP-Service and start running GSS-EAP -
User name="@example.org"
2. RP-Service sends RADIUS message to RP-AAA - Security on this link is out
of scope as this is internal to the RP cloud
3. RP-Service looks up "example.org" determines that it has no PSK/IDP pair
for that realm name
4. RP-Service requests PKS/IDP information from RP-AAA-TR
5. RP-AAA-TR discovers that it does not know this information
6. RP-AAA-TR opens TLS/TCP:666 session to TR (anonymous) then starts
Moonshot w/ username="[log in to unmask]"
7. TR sends RADIUS message to TR-IDP. Message secured by configured
public/private key pair (or similar). (using TLS/TCP:2083 session)
8. TR-IDP replies w/ Access-Accept - At this point RP-TR is validated to
TR.
9. TR determines that it needs to route the Trust Message to IDP - however
it does not have a relationship now. The trust network has the name of the
IdP pre-configured in TR's database.
10. TR opens a TLS/TCP:666 session to IDP-TR and sends an GSS-EAP request
to the server.
11. IDP-TR has no current path back to TR-IDP and thus cannot do the
validation. At this point there are two options in the protocol. The first
would be to open a separate TCP session back to TR and perform the
validation on that path. The second is to use the current session and
reverse the GSS-EAP entities so that the IDP-TR becomes the initiator and TR
becomes the acceptor. The Trust Router protocol could have a message to say
- "My name is TR. My voice is my passport. Verify Me." (Sneakers) In bound
(i.e. toward the IDP) validation is easy. Out bound (i.e away from the IDP)
is really hard because the GSS-API acceptor has no current path back to the
IDP.
12. TR requests a public-key from IDP-TR which is returned
13. TR returns public key to RP-TR
14. RP-TR returns public key and IDP name to RP-AAA
15. RP-AAA opens TLS/TCP:2083 session directly to IDP-AAA and sends RADIUS
message
16. IDP-AAA sends access-accept back to RP-AAA
17. RP-AAA sends access-accept back to RP-Server
18. RP-Server sends GSS-EAP accept back to User
> -----Original Message-----
> From: Moonshot community list [mailto:MOONSHOT-
> [log in to unmask]] On Behalf Of Sam Hartman
> Sent: Wednesday, February 13, 2013 2:56 AM
> To: [log in to unmask]
> Subject: It's Trust Routers all the way down: obtaining RADSEC credentials
for
> TRs and TIDRs
>
> Well, it's trust routers all the way down until you start mining the
elephant at
> least.
>
> A couple of weeks ago, I noted that we don't currently have a solution
for
> obtaining credentials for RADSEC clients that are trust router entities.
> In particular, a trust router needs a RADSEC credential in order to act as
a
> Moonshot acceptor so other trust routers and TIDCs can connect to it.
> A TIDRS needs to have RADSEC credentials in order to act as a Moonshot
> acceptor so TRs and TIDCs can connect to it.
>
> In that message, I pointed out that we could potentially use the TID
protocol to
> obtain temporary identities in a realm associated with the APC.
>
> Margaret thought that sounded a lot like a special case.
> "How does this work for a normal Moonshot acceptor?"
> "Uh. Hmm. It's not really different at all. That's kind of messy too."
>
> Within a realm we have a couple of options:
>
> 1) You can use self-signed certificates.
>
> 2) You can use that single PSK key that Freeradius supports.
>
> Margaret then asked why we couldn't hook a trust router or TIDRs up to an
> AAA proxy just like we would anything else.
>
> Hmm, I bet that creates a loop of some kind. Let's see if it has a base
case.
>
> Turns out if you configure things right it just works.
>
> Let's take an example.
> RPP1: RP proxy 1
> TR: The single trust router
> IDP1: an IDP realm and AAA server in that realm
> APC: The AAA server and realm associated with the APC
> tid(a,b): TIDR with target_realm a from source b
>
> IDP1, TR and RPP1 all have credentials in APC. In the following we assume
> everything is done in the context of the APC. I'll argue at the end we
probably
> want a COI for trust router internal messaging.
>
> RPP1 gets an authentication from [log in to unmask] It discovers it has no
key
> for IDP1.
>
> SO, RPP1 sends a TIDR for IDP1 to TR. to do that, RPP1 opens a gss
connection
> using its credential in APC1 to TR. TR is run by the same folks as APC1
so it
> shares the PSK or a self signed cert with APC1 and can accept this
connection.
>
> TR attempts to forward the TIDR to IDP1. To do that it opens a GSS
connection
> to IDP1 using its identity within APC1.
>
> IDP1's TIDRS contacts its RP proxy (IDP1). IDP1 discovers it doesn't have
a
> RADSEC key with APC1.
> So, it initiates a TIDR with target_realm APC1 from IDP1.
>
> To do this IDP1 opens a GSS connection with TR. It does have an EAP
> credential in APC1 so it can act as a client.
> TR does have a RADSEc key for APC1 so it can accept the connection.
>
> TR forwards tid(APC1,IDP1) to APC1. To do this, it opens a GSS connection.
TR
> has an EAP credential in APC1 so it can do this. APC1's TIDRs is closely
> associated with APC1 (same machine) so it has a RADSEc key with APC1 and
> can accept the connection.
> A response to TID(APC1,IDP1) is responded.
> This makes its way back to IDP1, which now has a key for APC1.
>
> Now, IDP1 can accept that connection from TR to process tid(IDP1,RPP1).
>
> See, there is a base case! It will "work." This is really nice because
we didn't
> need more must-haves for the upcoming beta or pilot releases.
>
> I'm a bit concerned about the scaling and performance. There's a fair bit
of
> recursion involved that all needs to resolve itself before the client
behind
> RPP1 gives up on RPP1's ability to get an access-request to IDP1. If that
fails,
> then the user behind RP1 will get a timeout and authentication failure.
If they
> try again it will work better, but that provides bad usability, especially
for
> automated authentications.
>
> If the trust router is good about connection caching, holds open TID
> connections to popular TIDRS, etc, then I suspect we can make this work
with
> reasonable performance.
> Currently that sort of caching is not part of the plan.
> So, I expect that things may be a bit slow for the first version.
Especially since
> we don't expire temporary identities right now, I think it will work out
OK.
> However, I think that this will give us some pressure post-April to
improve our
> performance.
>
>
> I had originally hoped that the APC realm would not be routable from the
> normal AAA proxies. My hope was to avoid having normal users be able to
> connect to trust router infrastructure for better isolation of the trust
plane
> than the normal authentication plane. I think we can gain the same
isolation
> by having a COI in which these requests are made. The
> APC1 AAAserver only accepts requests with this orig_coi. Similarly the
trust
> router and TIDRs will make their requests in this COI, and only the APC1
realm
> will be an IDP realm in that COI.
>
> In many ways this ends up being an excellent architectural validation:
>
> 1) I proposed introducing a special case at the protocol level. It turns
out it's
> easier to do it using existing tools treating the recursive authentication
just as
> another case of Moonshot.
>
> 2) I thought the trust router internal infrastructure was "special enough"
that
> it didn't want to use the one APC. It turns out it works better if we do
use the
> APC and just use COIs to provide isolation exactly the way we're asking
people
> to do for their resources.
|
