On 30/06/14 23:19, Josh Howlett wrote:
>> Well, autoconfiguration on Windows...
> Like I said I'm personally sympathetic to this, although I think it would
> be good to get more community input on the default behaviour.
Fair enough.
>
>>> It is worth bearing in mind that there are other PSK-based EAP methods
>>> that do not require a trust anchor. Our implementation does not
>>> currently
>>> support these methods, but might (and should IMO) in the future.
>> This is certainly true, but these methods don't use username/password
>> authentication, so the trust question (and required fields) will be
>> different anyway.
> Not so -- see for example RFC 5433 (this method, as it happens, isn't
> appropriate for use with Moonshot as it lacks among other things support
> for EAP channel bindings, but in principle it could).
EAP-GPSK doesn't use the username, but sure.. types similar to that
could work. I meant that different EAP types use different fields and
the TLS EAP types do need trust anchor fields, whereas PSK types do not
as it relies on a secret that was previously agreed with the IdP.

>
>> The Trust router does not only introduce peers to eachother, it can
>> influence key material. In this set up it is the core component in both
>> the connectivity and trust, effectively negating benefits of the Diffie
>> Hellman key exchange, the Trust Router can obtain access to the keys
>> anyway, by giving different public pairs to Idp and RP and giving a
>> different hostname/IP to both parties.
>>
>> However, if the Trust Router were to only give out a hostname for a
>> given realm and the client sends which IdP hostname it expects, that
>> would give the RP proxy the opportunity to verify the peer's identity,
>> by matching this to the host name that the client has already specified
>> it will verify the certificate with.
> The assumption here is that the CA operator (or its RAs) can be trusted to
> issue a certificate bearing the peer's true identity more than the Trust
> Router operator can be trusted not to modify the DH exchange.
The problem is slightly more complex than that, but it depends on scale.
Is there 1 trust router operator or is there a network of operators?
If the trust router network is federating internationally, is there 100%
trust in every trust router operator? How far does that trust go?
Does that trust go as far as them knowing the identity and all SAML
attributes of authentication sessions that are initially routed through
that trust router?

By separating identity trust from authorisation within the federation by
simplifying the trust router network these questions boil down to: Can
they be trusted to assert that these realms belong to this community?
Which is precisely the role of the Trust Router Network.

> If we were to simplify the role of the Trust Router along the lines that
> you propose, it would be useful to know why you think this assumption is
> true. Particularly given that well-known CAs are perfectly capable of
> issuing certificates to unexpected peers, either intentionally or as a
> result of a compromise, and that dubious CAs have been distributed using
> channels that were assumed to be trustable.
This is true, but even a compromised CA cannot perform a
man-in-the-middle attack on the system without compromising either the
routing or the trust router itself. False certificates can be issued by
CAs, though this is definitely not common practise, nor is it a feasible
angle of attack without compromising an entire CA. Large scale handing
out of false certificates would mean the end of the CA (Look at what
happened to DigiNotar). Do you trust the certificate your bank issues
and is signed by a 3rd party? Why (not)?

>
> 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.


-- Wilco Baan Hofman