>>>>> "Jim" == Jim Schaad <[email protected]> writes:
Jim> Would you consider it to be permissible for an intermediate to
Jim> re-write the assertions to change the framework they are being
Jim> made in from the IdP's home network to the federation network's
Jim> framework? This would say that they may not have quite the
Jim> same degree of integrity protection as might be initially
Jim> assumed.
AAA integrity is hop-by-hop.
I don't think we'll have technical mechanisms in some deployments to
prevent this.
In some cases (draft-howlett-radsec-kmp springs to mind) it might be
fairly tricky to do that.
I don't think we've discussed the role of intermediates much.
I can think of several models including:
* Intermediates are good and need to be permitted to muck about.
* When intermediates can muck about it's OK for them to do so.
* Intermediates must not muck about; future deployment and other
mechanisms may restrict their ability to do so more than is restricted
today.
We have not discussed a lot what the answer is.
In some of the work Josh and I did we ran into a number of cases where
having the intermediates be able to examine the information passing
through has been quite valuable.
(We typically found that out when we designed a mechanism to
short-circuit some intermediate and then ended up adding a lot of
complexity to get the intermediate some information.)
Similarly in discussions at the Kerberos Consortium conference this
fall, several people believed that having an organizational policy
intermediate near the RP would be valuable. (In that community they
believed a KDC would be a great place to put such an intermediate.)
>> That is, the RP need not perform any validation of the SAML
>> assertion. The RP still needs to validate whether the IDP is
>> permitted to make the claims
Jim> it
>> does. There's no requirement that these SAML assertions be
>> signed. The IDP MAY sign the assertion; the RP MAY consider any
>> signatures that
Jim> are
>> present. However in the interoperable case, any signatures that
>> are
Jim> present
>> are ignored.
>>
>> If there are multiple assertions from the same IDP it seems
>> reasonable to treat them all the same.
>>
>> Things get a lot more messy when assertions from multiple IDPs
>> are included.
Jim> Are you saying that the principal has multiple names or that
Jim> they are multiple assertions being made about a single name?
Both.
I'm assuming all the assertions are about the same subject/principal,
but that entity may be known by multiple names.
Someone needs to actually make sure that all the assertions are about
the same subject.
That is quite tricky.
>> Another source of complexity surrounds how an IDP links an
>> assertion to a subject. What confidence is the RP asserting that
>> the additional assertion describes the same principal as the
>> access-accept message.
>>
>> Another potential source of complexity is how does the IDP know
>> what information to gather? Does the IDP just know somehow? Does
>> the RP pass information back?
Jim> What happens if the naming space of the claims is different
Jim> between the IDP and the RP?
To the extent that problem exists, I think it is independent of whether
multiple attribute provders or one attribute provider is involved. I
think we're defining the use of NAIs as a way to have a common name
space between the RP and the first IDP.
That is, the AAA federation substrate for abfab needs to provide some
naming services to guarantee that we have a common namespace between the
RP and IDP.
Jim> What happens if the additional attributes need to come from a
Jim> completely different fourth realm? I.e. my name comes from the
Jim> country of issue, the RP is a bank and the attributes need to
Jim> come from a university?
*this* is the first point I was getting at in the paragraph from my
original message.
I consider this situation complicated.
Jim> I completely agree this is a hard problem that we need to start
Jim> writing down, if not answers then at least boundaries of the
Jim> problem.
Yes. I and as I understand it Moonshot don't need to solve this problem
to make forward progress. I think building some walls around the
problem and starting to understand where it is is valuable. However
until someone steps forward and wants to spend (or fund) significant
cycles on this, I don't think we will solve it.
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
