I have no issues with the text as is (when Yoshi's points are included). Rhys. -- Dr Rhys Smith Identity, Access, and Middleware Specialist Cardiff University & Janet - the UK's research and education network
email: [email protected] / [email protected] GPG: 0xDE2F024C On 22 Feb 2013, at 23:37, Joseph Salowey (jsalowey) <[email protected]> wrote: > 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
