If you look at draft-ietf-abfab-aaa-saml - this is exactly the case that is
imagined. The attributes need to be re-written as they change domains.
I don't see any part of the draft where it is stated the attributes
*need* to be re-written. Indeed, it says nothing about proxies (or I
couldn't find it). Nevertheless, some parts of draft-ietf-abfab-aaa-saml
need to be modified as the fragmentation draft moves forward.
The signature is assumed to be checked by the IdP system and RADIUS is then
responsible for keeping the integrity in transit. There is no reason to
suppose that the relying party is going to know who the signer of the SAML
statement would be and therefore would not be able to establish the trust
without the AAA infrastructure.
Although as you say, trust can be leveraged on the AAA infrastructure,
and the use of signatures can be avoided (using a single trust model),
IMO nothing should preclude using them if desired by the parties. If
intermediate proxies modify assertions, this would be impossible.
Regards,
Alejandro
Jim
Anyway, other alternatives to deliver large authorization data, like providing
a URL where the RP can download the assertion later, have exactly the same
issue: proxies cannot modify the contents of the assertion.
Regards,
Alejandro
2. The Overview in section 2 does not discuss the fact that a new set of
state items might also added to the message. This changes the limit
of how many bytes can be placed into the fragmented packets.
Yes.
3. nit - in para #3 of overview you use the word truncated and
truncation.
I think a better word set might be partitioned and partitioning.
Also ensure that fragmentation is used strictly for the process in
radius-extensions. I have not found any cases yet were it is not but
will try and remember to look.
4. I am not sure if positioning of the more-data-pending packet is
significant. The introduction says it comes last but nothing to that
effect is said in section 3.
5. Section 6 implies that the order of items in a set of fragmented
packets
might need to be changed based on the ability of items to be in the
packet.
For example if the Access-Accept packet had been = Data1[M],
Data2[M]...Data 10, User-Name, Service-Type[X], Framed-IP-Address the
order would need to be changed in the original partitioning. This
should be mentioned someplace other than just in the "examples"
section. It implies that a general use piece of code to do this will
need to have the table built in, and potentially extended as new
items are added, rather than just being coded correctly in the specific
packet type code.
Attribute ordering is explicitly *not* required in RADIUS.
6. What if any indications does a server have that the client will
be able to
deal with the partitioned message other than it will either fail or
get confused depending on what set of attributes are in the first
packet and what it needs and feels it can ignore.
That's an open area for discussion. RADIUS doesn't have
capability negotiation, so it's hard to do.
Alan DeKok.
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
