Hi. I wanted to jump in with a couple of items.
first, our radsec library does check the hostname in the certificate.
There is a option to turn off this check which was used at the workshop.
This option is appropriate when you have very narrowly scoped CAs, for
example a CA only used to sign RADSEC certificates within a single
organization.
turning this off in the workshop was not strictly appropriate from a
security standpoint, but makes things easier to deploy.
You've made a claim that a CA cannot mount a man-in-the-middle attack.
In many federations, I think it will be relatively easy for an attacker
to get some credential.
In that case, I think you'll need to do a bit more than use a PKI that
identifies the hostname of the IDP endpoint in order to defeat
man-in-the-middle attacks.
In particular, an attacker who can compromise the routing can route a
given realm to an endpoint that the attacker legitimately controls.
I think a SIDR-like approach where the route is signed would be
necessary to add PKI-like trust to the trust router.
An alternative would be to avoid the trust router completely and name
IDP realms in the PKI certificates directly.
Neither of these gives you full separation between routing and
identification, but at least when attackers can obtain legitimate
credentials the security problems cannot be completely separated.
The disadvantage of both of these approaches are that they additional
centralized trust that is not present in the system today. I understand
that you see the trust router as a central trusted component. However,
as Josh is explaining, by controlling what routes you're willing to
import and by permitting sites to bypass the middle, there are senses in
which trust router significantly decentralizes trust decisions. That
architecture is valuable to JANET and to several of the project
participants. Clearly, though, there are communities that are going to
value the sort of PKI-like trust you're looking for. If we can find
sufficient development resources it would be great to support all these
approaches.
Sam hartman
Painless Security, LLC
|