>>> >>> 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. >
I don't think readers' understanding can make the jump from 1st+2nd sentences to the 3rd sentence without having followed all the discussions on the list. I'm merely concerned about that. If I'm the only one concerned, then that's fine…. >>> 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. This "MUST" cannot be implemented. It's not clear what an implementor "must" be doing to comply. This is merely telling us "there's a problem, you MUST deal with it". This reads more like recognition of an issue, rather than a solution. We should either have a very clear "MUST do this …", or Define what the problem is, and leave it to the application designers to deal with it in their own terms. (And even in this case not sure if you can use "MUST"… maybe, maybe not.) We have neither of the above. > 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 :-) > So, how do you deal with this in your implementation? If the EAP authentication method (e.g., EAP-TLS, EAP-AKA, etc.) discards a message, who takes what action? >>> 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. > I was suggesting using MUST instead of SHOULD. I didn't understand how your first point addresses my comment here. >>> 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. I'm confused about the terms "re-authenticaiton" and "session". To me, both of the following cases qualify as "re-authentication": - Either the EAP peer or the EAP authenticator initiates new EAP authentication before the current EAP SA expires. One or more EAP authentication sessions live inside the same EAP lower-layer session. - EAP SA can be left to expire. The EAP lower-layer session may or may not expire in response to the EAP SA expiration. Whoever needs EAP SA is responsible for initiating EAP authentication. For example, when the server has some data to transmit but there is no SA available, then it'd trigger authentication. Having said both qualifies as "re-auth" in my understanding, I believe the text is referring to the former type. Maybe we need some additional terminology to distinguish the two type from each other. > >>> 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. > I was suggesting using MUST instead of SHOULD. I didn't understand how your first point addresses my comment here. Alper > 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
