hi. I was very surprised to hear Rhys's presentation on draft-ietf-abfab-aaa-saml today, because Josh proposed to solve a different problem than we've been working on over the last year. Also, I do not feel very comfortable about the proposed solution.
As I understand it, in the case where we're not using SAML metadata, and where we're relying on the AA trust fabric, we make the requirement that the AAA entities correspond to the SAML entities. So, we don't need to constrain the SAML naming because the AAA entities are making the assertions that the SAML names also correspond to the AAA names. In the case where we're trusting SAML metadata or policy, the issue is that we need to avoid a cut&paste attack where a SAML message intended for one party is intended for another party. The issue we are trying to solve is how to indicate in SAML messages or metadata that a particular AAA endpoint was a valid destination for a binding or entity. This issue is handled in the web profile by having the IDP redirect back to the service provider. We have more complexity because rather than sending the message directly over HTTPS, the home AAA server sends the message back over AAA. we need to make sure that the home AAA server is not man-in-the-middling the IDP--being a legitimate SP towards the IDP, getting an assertion, and then using that assertion to give one of its users access. We've had a lot of discussion on this already, and I am fairly sure we already rejected the approach of constraining the entity identifiers of the SAML endpoints. The approach proposed today is one that I prefer less well than approaches Josh, Rhys and I have discussed offline. _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
