I am happy with the proposed text. I have made some comments to Alper's issues below.
Josh. On 27/02/2013 21:36, "Alper Yegin" <[email protected]> wrote: >> >> 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. >> > >It'd be useful to explain why so, even briefly. I'm happy with this description. It is somewhat terse, but it meets the need. >> 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. >> > >Are these the only three options for how apps must handle discarded EAP >messages? If so, we should state that clearly. If not, then the "MUST >handle" statement is not meaningful at all. Unless we state specific way >of handling, or provide some general guidelines (e.g., characteristics of >handling), "MUST handle" does not mean anything to implementors. The applicability statement is describing a behaviour that needs to be considered by applications if they want to interoperate. It is reasonable to leave the question of what it means to successfully interoperate as an exercise for the application, because that will vary from application to application. >Also, as I had stated earlier, this requirement implies an interface >between the EAP method layer and the EAP lower-layer. Such an interface >does not exist, there is EAP in between. >This requirement has additional implications on EAP methods too. Existing >EAP methods need to be modified?? I don't follow this logic. While one can argue that such an interface might be useful, that does not imply that one is necessary. There is running code to prove it :-) >> Specifications of how EAP is used for application authentication SHOULD >> document how retransmission and message discards are handled. >> > >Why not MUST? See the first point. >> 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. >> > >There's a bit of a terminology confusion here, I believe. > >I think the intention is to state that we don't need to run EAP again and >again in order to maintain an always-on security association. It is OK to >let EAP sessions expire. We can run EAP again if and when we need a >security association again. One could call this "re-authenticaiton". > >On the other hand, letting the security association expire and having to >run EAP again on-demand can also be called "re-authentication". I regret that I don't understand what point is being made here. The text seems pretty clear to me. >> 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. > >I'd say "MUST" here too. Ditto the first point. Josh. Janet(UK) is a trading name of Jisc Collections and Janet Limited, a not-for-profit company which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
