On 11/11/13, 7:15 PM, "Josh Howlett" <[email protected]> wrote:
>> >>It's not enough that we claim that SAML entities names are true. >>That's actually not addressed by my reading of 5.3.2.The tricky issue is >>making sure that when SAML entities produce messages, they intend to >>allow the AAA entities discussed in 5.3.1 to use those messages. >>This is more of an issue of GSS-API channel binding than it is SAML >>naming. I haven't yet been able to relate the text there to my understanding (limited that it is) of channel binding. I'll just note that if the requirement is really to carry GSS-API CB data, there's already a slot for that in a SAML protocol extension I defined. But what's the CB data here? All I know of is TLS-based CB. >Yes, you're right. The current text conflates the two issues of the issuer >authorising the presenter, versus the consumer identifying the issuer. I >think the right way to do this is at the binding level using the >response's Recipient attribute, which needs to name the NAS. I thought the goal was to relate the AAA entity sending the message to the SAML entity issuing it, and that wouldn't be Recipient. If you're trying to target the message to a receiving identity that certainly could be Recipient, but if you're not signing, I don't see the relevance of populating that as a security measure. -- Scott _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
