Good catch Yoshi, I will make this change. Thanks,
Joe On Feb 23, 2013, at 8:01 AM, <[email protected]> wrote: > Hi Joe, > > The proposed new Sections "2.1 Retransmission" and "2.2 Re-Authentication" > are intended to be added to draft-ietf-abfab-eapapplicability (and not > intended be added to RFC 3748), right? > > If so, then the following sentence in Section 2.2 should be written from > application perspective in the same way as Section 2.1 for consistency: > > "Lower layers SHOULD describe whether re-authentication is provided and which > parties can initiate it." > > Applications SHOULD describe whether re-authentication is provided and which > parties can initiate it. > > Regards, > Yoshihiro Ohba > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Joseph Salowey (jsalowey) > Sent: Saturday, February 23, 2013 8:37 AM > To: [email protected] > Subject: [abfab] Summary of proposed changes to eat applicability document > > After going through the comments on the list here is where I think we are > with changes to the document: > > 1) Section 3 > > OLD > It is important > for the protocol carrying EAP to prove possession of the EAP MSK > between the EAP Peer and EAP Authenticator. > > NEW > The protocol carrying EAP MUST prove possession of the EAP MSK > between the EAP Peer and EAP Authenticator. > > ADD > > In the context of EAP for Application-Layer Access the application is > providing the EAP Lower Layer. Applications protocols vary so their > specific behavior and transport characteristics needs to be considered when > determining their retransmission and re-authentication behavior as discussed > in section 3. > > > 3) Retransmissions > > ADD > > 2.1 Retransmission > > 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 be able to receive and process > EAP messages at any time during the authentication conversation. > > Alternatively, EAP permits a lower layer to set the retransmission timer to > infinite. When this happens, the lower layer becomes 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. For example, 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 discarded EAP messages, 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, requesting an EAP retransmit and waiting for additional EAP input. > > Specifications of how EAP is used for application authentication SHOULD > document how retransmission and message discards are handled. > > 4) Re-Authentication > > ADD > > 2.2 Re-Authentication > > EAP lower layers MAY provide a mechanism for re-authentication to happen > within an existing session [RFC 3748]. Diameter standardizes a mechanism for > a AAA server to request re-authentication [RFC 4005]. Re-authentication > permits security associations to be updated without establishing a new > session. For network access, this can be important because interrupting > network access can disrupt connections and media. > > Some applications might not need re-authentication support. For example if > sessions are relatively short-lived or if sessions can be replaced without > significant disruption, re-authentication might not provide value. Protocols > like HypertextTransport Protocol (HTTP) and Simple Mail Transport Protocol > (SMTP) are examples of protocols where establishing a new connection to > update security associations is likely to be sufficient. > > Re-authentication is likely to be valuable if sessions or connections are > long-lived or if there is a significant cost to disrupting them. > > Another factor may make re-authentication important. Some protocols only > permit one part in a protocol (for example the client) to establish a new > connection. If another party in the protocol needs the security association > refreshed then re-authentication can provide a mechanism to do so. > > Lower layers SHOULD describe whether re-authentication is provided and which > parties can initiate it. > _______________________________________________ > abfab mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/abfab > _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
