Hi,
> 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.
....EAP-PWD is fun :-)
> Probably more of a radsec question. CN/altsubjectname on certificate
> should match the host name for certificates for this trust relationship.
RADSEC can also be configured to only work with particular OIDs present
in the cert... OIDs that typical public CAs, for example, would not put
into a cert asked for by some 3rd party
> 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....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'. 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'
> 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 :/
alan
|