Sam,
(2012/10/20 3:28), Sam Hartman wrote:
"Yoshihiro" == Yoshihiro Ohba <[email protected]> writes:
Yoshihiro> RFC 3748 also says: " When run over a reliable lower
Yoshihiro> layer (e.g., EAP over ISAKMP/TCP, as within [PIC]), the
Yoshihiro> authenticator retransmission timer SHOULD be set to an
Yoshihiro> infinite value, so that retransmissions do not occur at
Yoshihiro> the EAP layer. "
Yoshihiro> This allows double-layer retransmissions in some cases.
Yoshihiro> For example, EAP peer may be temporally busy and may have
Yoshihiro> to discard received requests. In such a case, EAP-layer
Yoshihiro> retransmissions on top of reliable lower layer can be
Yoshihiro> useful.
But would not actually happen if you set the timer to infinite.
Yoshihiro> EAP retransmissions can be useful in some cases even with
Yoshihiro> GSS-API, and I am wondering why GSS-EAP mandates option 2
Yoshihiro> (I am sorry for noticing this late).
Because GSS-API requires each round trip be started by the initiator and
receive at most one response from the acceptor. I.E. until the
initiator sends another message, the acceptor cannot send anything.
I am rather seeing an issue here. What happens if an initiator has to
discard a received EAP request
for some reasons, e.g., lack of processing resource, the request is
invalid due to message modification attack, etc.? How the request is
retransmitted?
Yoshihiro> Having said that I don't think we need to add text on
Yoshihiro> this matter.
I actually think text on this point is quite important. It's easy to
read RFC 3748 and assume that things need to be server-initiated in EAP.
I think it's important to point out to people considering using EAP for
their applications that if they take responsibility for retransmissions
that the EAP messages can be client-driven.
I think client-driven retransmission needs to be carefully designed. I
am interested in
seeing an answer for my question above.
Yoshihiro Ohba
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
