On 28/06/14 15:03, Josh Howlett wrote:
> Hi Wilco,
>
> Thanks for your perceptive questions.
>
>> 1. Client <-> IdP trust relationship
>> Right now there is a moonshot identity selector. This allows for
>> supplying usernames and passwords without a trust anchor. This should
>> *never* be allowed. Any malicious RP implementing GSS+EAP can grab hold
>> of the password. In the XML there is a possibility to set a fingerprint,
>> but this is not mandatory.
> This is certainly true for EAP-TTLS, and so I do have sympathy for your
> view. However personally I feel that auto-configuration should be
> sufficient to prevent issues, unless the user is really determined to
> shoot his/her foot. This is one of those cases where I'd prefer to see how
> users and deployers behave in practice.

Well, autoconfiguration on Windows (>= 7) for EAP pins the CA and
subject name *if* a locally trusted CA is used. On Apple devices the
fingerprint is used by default, but this leads to messages or failure
(configurable) when the certificate is replaced, even if replaced by a
valid one.

When using autoconfiguration, a user dialog with information about the
server (valid CA chain, server name, Geo IP information) should be
presented to the user for acceptance and the identity selector should
autoconfigure the server name and pin the specified CA when the user
clicks okay.

Though asking the user for a host to connect to is not too much to ask..
Using system CAs and specifying "moonshot.nikhef.nl" would be all that's
required for a proper trust anchor, of which the certificates can be
renewed.

>
> 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. For EAP-TLS, EAP-TTLS and PEAP a trust anchor in the
form of CA+subject is required.

> It is also interesting to consider how wireless devices supporting EAP
> authentication handle this issue today. My Windows phone, for example,
> requires a deliberate choice to validate against a trust anchor; the
> default is not to require one. My previous Symbian handset was the
> opposite. Its a bit of a UX headache!

Yes. It is definitely true that lots of EAPoL client devices do not
understand the trust model of EAP+TLS very well. That doesn't mean
moonshot should model its trust model after those devices. These are the
devices that the Pineapple access point was created to attack, using
freeradius-wpe.

>> 3. RP proxy <-> RP trust relationship
>> In the moonshot workshop, following the Wiki, we had to create
>> certificates on the RP Proxy, with a free form text string CN. Can this
>> be configured to use subject to hostname checking for client and server
>> certificates?
> Sorry, I don't follow the Q...

Probably more of a radsec question. CN/altsubjectname on certificate
should match the host name for certificates for this trust relationship.

>
>> 5. RP proxy <-> IdP trust relationship
>> This trust relationship and key material depend entirely on the online
>> benevolent behaviour of the Trust router. A Diffie-Hellman key exchange
>> is used over the trust router to agree on a PSK and the RP proxy will
>> happily connect to any IP specified by the Trust Router Network with the
>> key it just agreed on using Diffie-Hellman. There is no trust
>> verification between IdP and RP proxy. This means that the Trust Router
>> Network can perform a Man-in-the-Middle attack on the entire federation
>> and is a 100% fully trusted component that can attack the entire
>> federation trust.
> The TR is a trusted third party, and not much different in this sense from
> a CA, KDC, proxy RADIUS, or SAML federation. They all require that the
> operator acts in the interests of their users. If you don't trust an
> operator of one of these technologies to act in your interests, don't use
> them. No technology can impose benevolence.
>
> What sets Trust Router apart from these other technologies, in this
> context, is that it is a single platform for managing your trust links to
> the folks that you would prefer to connect to directly, and those folks
> that you trust to make trust connectivity decisions on your behalf,
> without imposing a material increase in configuration or operational
> complexity, even as the policy environment becomes more complex (and, of
> course, you can use it for establishing trust for pretty much any kind of
> application). As such each actor within the Trust Router network is able
> to tune their trust connectivity graph to their needs, rather than having
> a large graph imposed on them.

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.

Then the steps would look like this, assuming proper verification by the
client using TLS-based EAP with the subject hostname check:
1. RP proxy uses trust router to find an IdP in the same community
2. Diffie Hellman handshake starts as part of
ECDHE-RSA-AES-256-GCM-SHA384 in TLSv1.2
3. The client's expected host name would be used by the RP Proxy to
match the information from the Trust Router
4. A trust chain CA verification can be done on that host name.

In this setup there is no single point of failure from a security
standpoint. The CA is used to verify the identity of the IdP, but the CA
is offline and is not in the routing chain (as opposed to the Trust
Router). Hacking the offline CA *and* the trust router is necessary to
perform a MitM-attack.

>> There is also no infrastructure for verifying signed
>> SAML statements coming from the IdP.
> We don't by default sign SAML assertions. The trust in an assertion is
> derived from the AAA security context.

Okay. Makes sense *if* the IdP connection trust is solid.

>> It seems to me that the trust
>> router may be better replaced with a signed list of realm <-> hostname
>> mapping per community and let DNS + PKI fix this trust problem.
> What problem does that fix? I don't see why a PKI operator is necessarily
> any more trustable than a Trust Router operator.

PKI operators indeed.. but online systems that are in the connectivity
path are different from the operators. I may trust you, but your
systems may be compromised..

In the PKI-world the identity problem is separate from the routing
problem, requiring both to be compromised before the system is exploitable.

In this case, I basically propose that the Trust Router gives
information about realm/IdP mapping for communities and is limited to
that. The RP Proxy can verify the IdP trust by combining the host name
requested by the client with the Trust Router response and/or the pinned
information in the database of what was previously the keys file.

The Trust Router does exactly what it is described as: It introduces the
RP proxy to the IdP by giving back a host name for the trust path.

This requires very few changes to the existing model as far as I see,
and has several security benefits as well as it does not complicate the
trust question based in the trust router: The Trust Router tells you
about communities and where to find the IdP for a given realm in the
community.

The changes would be, as far as I can see:
- Adding hostname-based trust anchors in the identity selector
- Remove the keying system from the Trust Router protocol
- Use normal TLSv1.2 negotiation with PFS ciphers using standard
libraries with host name checking in the TIDS.

Regards,

Wilco Baan Hofman