Hi, Thinking about the 4K limit in the RADIUS payload and the four options outlined by Josh and the discussion we had in Taipei, I guess we could have a fifth option: the use of multi-packet RADIUS sessions to transfer SAML data when the payload limit is reached. This will keep us in RADIUS space and allow for arbitrary long SAML messages. Of course, this would be an optional behavior, keeping the current (one SAML message in one RADIUS packet) as the default, mandatory, one. This approach could even be usable in other potential cases where the 4K payload limit may become an issue.
From the SAML RADIUS binding point of view this would imply to allow the use of several SAML messages. In principle, several AuthN statements related to the same NAI and containing the corresponding attributes.The RADIUS client / SAML RP would have to deal with them as a single statement From the RADIUS protocol point of view I see two possible options: making the server to send successive Access-Challenge responses with the corresponding SAML messages, or defining a new RADIUS packet type. The first option has the advantage of being easier to implement, though it implies stretching (probably too much) the semantics of the challenge loops. There is of course a lot to ellaborate to make this a viable solution and I can volunteer to start writing something more detailed if the group thinks this idea makes any sense. Be goode, -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D e-mail: [email protected] Tel: +34 913 129 041 ----------------------------------------- Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
