On 30/06/14 22:38, [log in to unmask] wrote:
>
>> 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.
> hmmm... I see... client not only sends their user-name but ALSO what their IDP
> servername must be....
They must do so anyway for TLS. It must match the certificate. Always,
when using TLS, the host name of the server must be known and be verified.
> but in the current world we have many many RADIUS
> authentication servers and add/remove them as we please...the users 
> dont know the RADIUS infrastructure...they dont need to know - their clients
> only know the CN thats in the certificate presented by 'a box'. 
And this CN or subjectAltName must be verified by the user or on behalf
of the user (if the user fills in what he/she expects).
>  the only
> workable way would be if the system started doing some 'RADSEC/DD/DNSROAM'
> style thing where a NAPTR record is looked up for the realm by the RP..
> and if the TR presents a server NOT listed in the NAPTR lookup then
> its 'no thanks'
Adding/removing RADIUS servers is easy enough to do with DNS
round-robin. Realm lookup in DNS could work as well, like in kerberos,
but that would be overkill for this situation.
>> 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.
> ..but all sites must then use servers/CAs that all others know and trust....
> you turn everything into one giant PKI/TLS mess :/
>
>
Moonshot uses TLS in every connection, and that's actually a good thing!
PKI was designed to solve exactly these type of trust issues and does so
pretty well. And yes.. somebody must verify that the host is in fact who
the host says it is. This is what a CA is, no more, no less. Encryption
is not useful if the server is going around sending the data to everyone.

TLSv1.2 is designed around PKI and provides:
- Mutual authentication (identity verification)
Know who you're talking to! Encryption is completely useless if you
don't know who you're encrypting to. This is where asymmetric crypto
comes in, RSA or ECDSA. Now, to make sure this trust can scale up, you
need some party verifying that this key belongs to this host and the
host is in fact who it says it is. This is where signing comes in..
There must be a trusted party attesting to the identity of the host, how
else will you verify somebody's identity in an automated way,
cryptographically?

- Confidentiality (Strong ciphers)
Ciphers like AES-GCM are excellently qualified, fast and confidentials

- Message integrity (Hashes)
SHA384 ensures messages aren't tampered with.

- Protection of historic network data (Perfect Forward Secrecy)
(Elliptic Curve) Diffie-Hellman, applied correctly, ensures forward
secrecy.. meaning that if a node in the network is compromised, captured
earlier network traffic still can't be decrypted. Once the compromise
has been fixed, replace the keys (and thus certificates) and it's secure
again.

With minor tweaks, all this can be gotten for free.. and it is using an
industry standard to do it, using standard libraries.

-- Wilco Baan Hofman