> -----Original Message----- > From: Alejandro Perez Mendez [mailto:[email protected]] > Sent: Friday, March 09, 2012 3:56 AM > To: Jim Schaad > Cc: 'Alan DeKok'; [email protected]; [email protected] > Subject: Re: [abfab] FYI: New Version Notification for draft-perez-radext- > radius-fragmentation-01.txt > > > > El 09/03/12 05:55, Jim Schaad escribi : > > > >> -----Original Message----- > >> From: Alejandro Perez Mendez [mailto:[email protected]] > >> Sent: Monday, March 05, 2012 12:03 AM > >> To: Alan DeKok > >> Cc: Jim Schaad; [email protected]; [email protected] > >> Subject: Re: [abfab] FYI: New Version Notification for > >> draft-perez-radext- radius-fragmentation-01.txt > >> > >> > >> > >> El 04/03/12 08:10, Alan DeKok escribi : > >>> Jim Schaad wrote: > >>>> I have some comments on the draft. However first let me say that I > >>>> know > >> next to nothing about RADIX having only briefly read it a couple of > >> times and having not yet worked with it to any extent. > >>> Reviews are always welcome. > >>> > >>>> 1. I think a discussion is in order about the issues of packing a > >>>> radius > >> message full in the presence of proxy intermediaries which might need > >> room for adding and removing routing materials. I don't know how > >> many proxies are keep local state as oppose to just filling up the > >> message with Proxy-State items and thus need space on the way back. > >> Also a discussion of removal and re-insertion of the T flag might be > >> needed if the proxy fully assembles the message and then relays it in > pieces. > >>> The simplest way to address that is to artificially lower the > >>> RADIUS maximum packet size, as seen by the client. > >> Additionally, regarding the T flag removal/re-insertion comment, > >> proxies are not allowed to perform RADIUS fragmentation on forwarded > >> packets. It is a process performed end-to-end the RADIUS client and > server. > >> > > What happens for proxies that, for some reason - want to re-write the > contents of packets. For ABFAB I am specifically thinking of changing or > mapping attributes in SAML assertions. > > I don't think a RADIUS proxy should change anything at a SAML level, but I > may be wrong. Specially, if the assertion is singed by the IdP, that would be > impossible at it would invalidate the signature.
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. 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. 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
