Jim,
In the context of EAP, GSS-EAP solely cannot be considered as EAP
lower-layer because GSS-EAP itself does not provide in-order delivery of
EAP messages. GSS-EAP requires applications to provide in-order
delivery. Therefore, GSS-EAP applications must be considered as part of
EAP lower layer.
Yoshihiro Ohba
(2012/11/20 13:48), Jim Schaad wrote:
I would be against this replacement.
The application and the lower-layer may not be the same thing for a number
of reasons. Looking specifically at the GSS-EAP case, the lower layer
consists of both RADIUS and GSS-API. Neither of these is really the
application layer. If EAP is directly built into the application, then yes
the application and the lower layer are going to be the same. If there is
some type of wrapper that is going on in the middle, such as using GSS-API,
then they are no longer the same. The application becomes one layer lower
than the lower-layer.
If you look at RADIUS, RADIUS is the lower-layer independent of transport
that RADIUS is operating on top of. It does not mapper if you are doing
RADIUS over UDP, DTLS or TLS/IP, RADIUS is the lower-layer. At some point
you say everything below this point is below the lower-layer.
Jim
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Yoshihiro Ohba
Sent: Thursday, November 15, 2012 11:58 AM
To: [email protected]
Subject: Re: [abfab] Retransmission Text for EAP applicability
Sam,
The provided text looks good, except that the text is generally
applicable to any EAP lower-layer inclucing applications. Said that my
suggestion is to replace "application" with "lower-layer".
Thanks,
Yoshihiro Ohba
(2012/11/15 4:37), Sam Hartman wrote:
In EAP, the authenticator is responsible for retransmission. By
default EAP assumes that the lower layer (the application in this
context) is unreliable. The authenticator can send a packet whenever
its retransmission timer triggers. In this mode, applications need to
process EAP messages at any time during the authentication conversation.
Alternatively, EAP permits a lower layer to set the retransmission
timer to infinite. In this case, the lower layer is responsible for
reliable delivery of EAP messages. Applications that use a lock-step
or client-driven authentication protocol might benefit from this
approach.
In addition to retransmission behavior applications need to deal with
discarded EAP messages. Whenever some EAP methods receive
erroneous
input, these methods discard the input rather than generating an error
response. If the erroneous input was generated by an attacker,
legitimate input can sometimes be received after the erroneous input.
Applications MUST handle an EAP method discarding a message, although
the specific way in which discarded messages will be handled depend on
the characteristics of the application. Options include failing the
authentication at the application level and waiting for additional EAP
input, possibly after an EAP retransmit.
Specifications of how EAP is used for application authentication
SHOULD document how retransmission and message discards are handled.
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
