Hi Sam: >From what I recall, I suggested to move to the subtoken option because >synthesizing an EAP response/id was not a good idea.
The reasons were explained here http://www.ietf.org/mail-archive/web/abfab/current/msg00947.html Nevertheless I am still wondering what is the benefit. Let me explain. Fast re-authentication is generally important but we are just saving a round trip between initiator and acceptor, which are not too much in comparison with the number of messages involved during a whole EAP authentication and the travel the messages have to do all the way to the home AAA/EAP server. So basically I believe reducing that part does not help too much if we do not reduce the real critic parts as the number of EAP messages or the fact they have to reach the home AAA/EAP server. Not only that. I also made some additional comments about some situation that may happen, but I believe there were not any comments after my e-mail. My last e-mail was in http://www.ietf.org/mail-archive/web/abfab/current/msg00950.html But let me paste what I wrote: "Definitely, designing a subtoken seems the most standard way of defining this optimization. Nevertheless, we may need to think about something I just realized. It may happen that when the acceptor sends the EAP-Start in the RADIUS Access-Request that the RADIUS EAP/AAA server decides to start the EAP request/identity instead the first EAP request of the chosen EAP method. The reason is the text about that RFC 3579 I pasted in my previous e-mail where it is said: "The RADIUS server will typically respond with an Access-Challenge containing EAP-Message attribute(s) encapsulating an EAP-Request/Identity (Type 1). However, an EAP-Request for an authentication method (Type 4 or greater) can also be sent by the server." It means that RADIUS EAP/AAA server implementation is not obligated (there is no MUST in the text) to start an EAP method instead of sending an EAP request/identity. This means that RADIUS EAP/AAA should be correctly configured to allow this optimization. Otherwise, the RADIUS EAP/AAA server will send the EAP request/identity that has to travel all the way to the authenticator. Although the solution does not violate any standard, in certain cases it may not help to achieve the optimization if the home EAP/AAA is not configured to select directly the EAP method for that peer. Even I would say that it is more problematic than sending the EAP request/identity from the authenticator (The EAP request/identity sent from the home EAP/AAA will add more latency and the same number of messages than the current not optimized case). So the question would be : can we be sure that all home EAP/AAA servers will act to allow the optimization?" NOTE: If the subtoken carries the same identity as it should be included in the EAP response/id, it may work. However, I am not completely sure what will be the default behavior of existing RADIUS servers when they receive a User-Name without any EAP packet or with the "EAP-Start" packet. Potentially, it seems they may initiate EAP Request/Id in some cases. It is for sure that RADIUS experts may provide some good insight about it. Best regards. El 06/03/2012, a las 22:24, Sam Hartman escribió: > > Hi. > > we had a long discussion on the list and in the meeting about whether we > want to continue wasting a round trip on eap request/identity or > whether we want to introduce a new subtoken type to carry the identity > from the initiator to the acceptor. > > If I were making a consensus call I'd say we were going to drop the > round trip and add the subtoken. However it was not entirely clear and > I'd sure appreciate any comments from the chairs or others. > _______________________________________________ > abfab mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/abfab ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: [email protected] ------------------------------------------------------- _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
