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
