Sam Hartman wrote: > So, I'd like to better understand the reasons for this change. > If it's DOS concerns, I would prefer to revert the change and simply > note the concern in security considerations.
It's partly DoS. The issue of the NAS sending large amounts of data to the home server is an issue. If it's for a trusted user, OK. If it's for an unknown user, it's not OK. i.e. even if the NAS only sends 10K of data, attackers can open up thousands of unauthenticated connections, and potentially DoS the server. > Also, from a DOS standpoint, since the entity being authenticated is the > user, not the NAS, I'd like to understand how you're better off from a > DOS standpoint after authentication. It reduces the attack profile. The issue of large volumes of authentication data is limited to (a) trusted NASes, and (b) known users. The other issues are packet size, and changes to existing EAP processing. EAP already largely fills RADIUS packets. Adding SAML data means that any UDP packet will be fragmented. It will then fail to cross the wider net. TCP / TLS doesn't have this problem, of course. The EAP processing issue is about synchronization. The EAP-Success needs to be in the Access-Accept. If the NAS is sending large amounts of data, it may overflow the initial sequence of packets. So... does the data get fragmented to the post-authentication stage? Will the NAS continue trying to send more data after EAP-Success? Will the server send EAP-Success in an Access-Challenge, and continue asking for the data? It's not clear what's best here. Alan DeKok. _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
