(2012/11/20 15:25), Jim Schaad wrote:
It is more correct to say that GSS-API gets its reliability by pushing some
of it down a layer, but that is no different that RADIUS saying it can have
reliable transport if it requires TLS/IP as its underlying transport.
If GSS-API relies on reliability provided by its transport, then GSS-API
combined with the trasnsport is considered as EAP lower layer to meet
EAP lower layer requirements.
Strictly speaking, RADIUS is not considered as EAP lower layer just
because EAP lower layer is defined as the laywer that is responsible for
transmitting and receiving EAP frames *between the peer and
authenticator* (see RFC 3748).
Also the requirements that GSS-API imposes during the authentication phase
are different than those during the normal application processing. For
GSS-EAP it is a lock-step delivery during authentication. That is much
stricter than just saying it is in-order delivery.
Being lock-step solely does not provide in-order delivery. EAP is
lock-step protocol but it does not provide in-order delivery, because it
Identifier fieled is not a sequence number and may be reused during the
same EAP conversation. To provider in-order delivery, at least sequence
number would be needed. Does GSS EAP token carry a sequence number?
This is an important question for you to answer.
Yoshihiro Ohba
However this does not change my opinion that application protocol that is
using GSS-API is not part of the EAP lower-level. The requirements that
GSS-API makes are independent of the use of EAP.
Jim
-----Original Message-----
From: Yoshihiro Ohba [mailto:[email protected]]
Sent: Monday, November 19, 2012 9:33 PM
To: Jim Schaad
Cc: [email protected]
Subject: Re: [abfab] Retransmission Text for EAP applicability
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
