> Hi. Over in PCP we've been attempting to apply EAP to the application > authentication problem. My personal opinion is that GSS-EAP brings more > complexity than PCP needs. Three solutions are being considered: two > PANA-based solutions and one solution tuned for PCP. > > A few issues have come up where the requirements of EAP are unclear at > least to some participants.
Draft draft-ietf-abfab-eapapplicability updates only the EAP applicability statement (i.e. section 1.3 of RFC3748). I have the impression that the clarifications regarding retransmission which you describe below are certainly related to RFC3748, but are not something that should be mentioned in section 1.3, i.e. the applicability statement. > It seems to me like the EAP applicability update would be a great place > to cover these issues. If my suspicion in the paragraph above is true, the *applicability update* seems like the wrong place IMHO. An update to (or if the issue is seen as small enough: an erratum pertinent to) RFC3748 as a whole would be a more logical approach. Also, we have earlier been discussing the scope of draft-ietf-abfab-eapapplicability - whether it should cover all present-day uses of EAP, or just abfab-related uses. Back then we concluded that its scope should be narrowed down to just abfab. Since your issue is occuring in pcp, not abfab, that agreed course of action would mean that the issue is out of scope for draft-ietf-abfab-eapapplicability, even if it should indeed relate to section 1.3 of RFC3748. > The first is retransmission. > > As specified in RFC 3748, EAP handles retransmissions, and the EAP > authenticator is responsible for the retransmission. > > However, the EAP RFC allows a lower layer to set the retransmission > timeout to infinite. > > In terms of an applicability statement, I believe that applications > MUST choose one of the following options: > > 1) Have authenticator-initiated retransmissions at the EAP layer. > > 2) Set the timeout to infinite and require retransmissions at a lower > layer that is application specific. > > For example, since GSS-API provides reliability, we chose option 2 in > draft-ietf-abfab-gss-eap. This is particularly true because GSS-API > doesn't support the idea of unsolicited messages from server to client. > The applicability statement should point out that if applications choose > option 1 they need to be able to transmit messages from server to client > at any time during the authentication phase. Is there a second one? Greetings, Stefan > > If the WG agrees with this proposal I'll propose specific text. > _______________________________________________ > abfab mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/abfab > -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473
signature.asc
Description: OpenPGP digital signature
_______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
