>
>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.
>
>>
>> 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).
>> 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.
Oh ok, sounds reasonable to me.
>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.
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.
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.
Josh.
Janet(UK) is a trading name of Jisc Collections and Janet Limited, a
not-for-profit company which is registered in England under No. 2881024
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238
|
