I have no immediate qualms about this text. Jim
> -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Joseph Salowey (jsalowey) > Sent: Friday, February 22, 2013 3:37 PM > 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
