On 25 Nov 2011, at 16:17 , Alan DeKok wrote:
>  It involves some serious changes to RADIUS servers and clients.
>
>  For this to work at *all*, it would have to be done via
> Access-Challenge.  These will pass through intermediate proxies.  Any
> new RADIUS packet code will be dropped by nearly everyone.

That's a good point to make the decision for a type of packet. Access-Challenge 
would be.

>> 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.
>
>  You'll have to pass it by radext.  That review traditionally takes a
> while.

I did not hope it to be a quick process anyway. If we decide to go this way 
there are some partial solutions (like requesting the SAML message to be 
compressed in the RADIUS attribute) that would buy us some time.

>  An alternative that's been discussed has been to relax the 4K packet
> size limit for RADIUS over TCP.  TCP doesn't have fragmentation issues
> like UDP, which makes it easier to increase the packet size.

This alternative would be ideal, as long as
(1) It is likely to be accepted and implemented.
(2) We are talking about not having any packet size limit, what I'd say would 
match with "TCP style"
What's you opinion on this? Would ABFAB help in building the case for it?

>  Another alternative is to stop using RADIUS for bulk data transfer. :)
> Instead, put the data somewhere..., and have the client somehow... get
> it via another protocol.

This has been suggested as one of the alternatives, since SAML provides this 
capability through so-called artifacts, But the ABFAB authentication mechanism 
is intended (as far as I can tell) to avoid the need of a second trust 
framework out of the AAA. An additional protocol to get attributes would 
require this second trust framework.

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

Reply via email to