El 04/02/13 13:39, Alan DeKok escribió:
Alejandro Perez Mendez wrote:
Why? I assumed they will ignore the MDP attribute, and generate a
Challenge if they understand the chunk as a valid Access-Request.
The server might return a challenge. But any response from the server
will *not* implement fragmentation. That's the point.
That's sure.
What if the server wants to send a fragmented Challenge *before* sending
the Access-Accept?
My $0.02 is that it's probably a bad idea. Changing the semantics of
existing authentication methods is hard. For example, most 802.1X
implementations assume that the final EAP-Success is in the
Access-Accept. If it's in an earlier challenge... who knows what will
break.
I think I didn't explained myself correctly. I'm not suggesting
modifying existing authentication methods. EAP-Success will still appear
only in Access-Accept packets. Just imagine the situation where the
Server wants to include an attribute X in one of the Access-Challenge
packets, and that by introducing that attribute X, the packet becomes
too big. That's the case I'm thinking of. Maybe that's an impossible
situation, I don't know.
Let my give an example. A server wants (for whatever reason) to include
an attribute X on every packet it sends to the Client. That includes
every Access-Challenge belonging to a RADIUS-EAP authentication. If this
attribute X is big enough, the packet will need to be fragmented. This
is happening before Access-Accept.
Regards,
Alejandro
Then, it will send the More-Data-Pending attribute,
not the Service-Type = AddAuth. Again, the client may ignore the unknown
attribute and try to decode the chunk as a "regular" Access-Challenge.
Which is likely to contain *no* useful information for the client. So
the client has an Access-Challenge it didn't expect. It can do nothing
but reject the user, and close the session. This is a different error
than "unknown Service-Type Additional-Authorization".
Having the server send an unknown Service-Type is a known quantity.
It is easy to debug, and easy to check.
Alan DeKok.
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
