On Tue, Jul 01, 2014 at 10:05:05AM +0200, Gabriel Lopez wrote:
> SAML attributes do not cross the TR, they are exchange directly between
> idP and RP.
The point Wilco was making is that the Trustrouter can put a
man-in-the-middle between the IdP and the RP and hence can get the
attributes.

Furthermore, when there is no check done by the client on the IdP, the
trustrouter could also get in between there and sniff the passwords.

> The discussion about to use a federated PKI or not is not a new topic in
> the list, you can see previous emails. The question is that in Moonshot,
> one of the requirements (and probably the most important one) (please,
> correct me if I'm wrong) is that a federated PKI is not desired.

I wouldn't call the PKI a federated PKI.
The crucial point here is that the TR is a central service in the entire
federation infrastructure. By hacking one internet connected machine, I
can get pretty much everything and when there are interfederation
connections, even that of the neighbours. I think no federation would
approve of such a fragile component.
That's completely different from a compromised CA, which, as Wilco
points out, is still not sufficient, even more so when combined with a
user-supplied or expected hostname. It might compromise part of the
infrastructure, such as a single IdP, but getting username/passwords of
the entire federation is practically impossible.

> >> Of course a Trust Router, as an online system, could be compromised by a
> >> malicious actor more easily than an offline CA. However it is worth noting
> >> that Trust Routers only need to be visible to their immediate clients and
> >> peers unlike, say, an OSCP responder that must be exposed to the Internet
> >> at large. It makes no sense to trust an issuer to verify an identity more
> >> than you trust the same issuer to retract that claim.
> >>
> > Well, sure, but the main problem is that the Trust Router is both in
> > charge of routing and identity verification. This is a single point of
> > failure from a security standpoint and could compromise an entire
> > federation. I do agree that OCSP is not a very good system for
> > revocation, but that does not expose the private key of the signing CA
> > to the internet.

Do be even more clear: faking OCSP responses or CRLs is not at all the
same as faking a certificate itself. It still would need an additional
compromised certificate to actually mis-use it.

Mischa

-- 
Nikhef                      Room  H155
Science Park 105            Tel.  +31-20-592 5102
1098 XG Amsterdam           Fax   +31-20-592 5155
The Netherlands             Email [log in to unmask]
  __ .. ... _._. .... ._  ... ._ ._.. ._.. .._..