>>>>> "Cantor," == Cantor, Scott <[email protected]> writes:
>> I don't want to open a can of worms, but we could consider the
>> idea of more compact coding formats, like JWT
Cantor,> Can you explain how my 5K of data becomes < 4K because I
Cantor,> take out some angle brackets?
I have not read 02. I have some comments based on the discussion.
1) aaa-saml MUST NOT normatively repeat any text about the EAP binding
from the RADIUS eap binding. As an example the quoted description of the
handling of EAP identity is different from the RADIUS EAP spec. We
committed to not changing RADIUS or EAP. While I guess we didn't
strictly commit to not changing RADIUS EAP, I really don't think we want
to go there, especially when we have no good reason for doing so.
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.
3) We have no business forbidding signatures. We SHOULD mandate that
NASes default to not checking signatures. We SHOULD point out that you
can strip/not issue a signature to make your assertion smaller.
4) I prefer attribute query as a way to get larger/more attributes over
URL references or artifacts.
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. 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.
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.
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
