2) As has been pointed out the 4096 limit is on RADIUS messages *not* on
SAML assertions. Also, it's not a limit: it is a minimum size
implementations must handle. So, I think a better way of phrasing this
is that if your SAML assertion makes a RADIUS PDE greater than 4k it
very likely will not be carried in its entirety.
The text from RFC 2865 says, regarding the Length field o a RADIUS
message, the following:
The minimum length is 20 and maximum length
is 4096
Hence, IMHO it is a limit.
4) I prefer attribute query as a way to get larger/more attributes over
URL references or artifacts.
I agree, but if attribute queries are performed using SOAP (for
example), you would need to rely in certificate-based trust, and
AAA-based trust would not be enough, right?
5) We need more discussion on the size issue.
I'll note several things.
First: the protocol may be useful even if it does have limitations. If
it happens that most of the things people want to do with it are
possible, but some are not, it may have sufficient utilitiy. Compression
increases the utility. It doesn't help if you want a 10k photo with
FreeRADIUS, but it does help if you're close to the boundary.
Right. Actually, we are using compression in our prototype.
So, I
don't view it as a valid objection that is a size limit or that some use
cases are precluded by the size limit. I do view it as an objection
that the size limit does not permit enough use cases. I don't know
whether that's true. However my personal opinion is that I don't agree
with a message complaining about a size limit unless it explains both
things that are prohibited and makes an argument about why prohibiting
those things is a bad tradeoff.
Maybe I did not explain myself well. I was not postulating myself
against the use of RADIUS, or complaining about it. On the contrary, I
was just raising an issue we found in our prototype, in the aim to find
out a consensual solution for the specific (and probably infrequent)
cases where the size limit may appear. Of course, one can use Diameter
instead. But I would like to have a solution for RADIUS.
Second: We can explore whether it's operationally viable to raise the
limit. I'm a little dubious about this. The RADIUS world seems to have
hard-coded the 4k limit in servers and proxies. That is not how I would
have done things. I'm told it's a simple constant that can be increased
and rebuilt in several popular implementations.
I am skeptical of the viability of doing that or how well it works if
you do. Still we should consider.
I think they did that way because that limit is specified in the RADIUS
spec. I would guess that, as you say, it will be a simple constant
easily increseable for the servers you control. But it would be needed
to rebuild all the RADIUS servers that take part in the federation, so
they do not strip messages when acting as proxies. Anyway, increasing
that number would be against RADIUS specification, if I did not
understand it wrong.
Best regards,
Alejandro
However I do believe the length limitation is the big thing to consider
for saml-aaa.
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
