RFC 3748 also says:
" When run over a reliable lower layer (e.g., EAP over ISAKMP/TCP, as
within [PIC]), the authenticator retransmission timer SHOULD be set to
an infinite value, so that retransmissions do not occur at the EAP layer. "
This allows double-layer retransmissions in some cases. For example,
EAP peer may be temporally busy and may have to discard received
requests. In such a case, EAP-layer retransmissions on top of reliable
lower layer can be useful.
EAP retransmissions can be useful in some cases even with GSS-API, and I
am wondering why GSS-EAP mandates option 2 (I am sorry for noticing
this late).
Having said that I don't think we need to add text on this matter.
Thanks,
Yoshihiro Ohba
(2012/10/19 22:28), Sam Hartman wrote:
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.
It seems to me like the EAP applicability update would be a great place
to cover these issues.
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.
If the WG agrees with this proposal I'll propose specific text.
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
