Apologies for the delayed response. >>>The question IMHO is: there are many inner EAP methods specified >>> already, and they don't typically specify or signal most of the error >>> conditions below to the EAP peer. The TEAP document can't impose change >>> on all those inner methods; they are what they are. If they tell >>>neither >>> the EAP peer nor export that information to the TEAP layer, then there >>> is nothing we can write in the TEAP document that will make it happen. >>> >>> This limits the scope of the error conditions to cases where TEAP has >>> "all in its own hands" - which I believe is limited to the "Optional >>> Password Authentication" of chapter 3.3.2. >>> >> >> [Joe] I tend to agree that we shouldn't try to address errors that are >>specific to inner methods. We should stick to things that are TEAP >>specific. > >Sam's point is also valid though; even if we don't care protocol-wise >about what inner EAP methods are doing, an implementation might be lucky >and learn about inner method failures via unspecified means. It could >then communicate those failures on the TEAP layer; if only our >dictionary is flexible enough to be useful for these cases.
Agreed. My view is that we should make the dictionary as expressive as reasonably possible, while taking care not to impose unnecessary complexity on EAP server implementations (for whatever reason) where these might be unattractive to implement. For these new error conditions, I think it would be sufficient to define the dictionary, and allow implementors to decide what to implement. From the supplicant's perspective, any information is better than none. >>>> In addition to these, might there also be some value in an >>>> "Information-URL" TLV? The value could point to a web resource that >>>> provides further information for TEAP connections that are successful >>>>but >>>> where, for example, user notification or action is desirable (e.g., >>>> password change). >>> >>> I like that one. >>> >> >> [Joe] So I would prefer to address this in a separate document. I can >>see some issues here. How does one access the URL if they fail to get >>network access? I imagine there are some security considerations around >>connecting to some URL specified by the server. I suppose it would be >>OK if the client can authenticate and trust the server. > >The suggestion was to send this URL only after a *success*. Then the URL >comes from a trusted source, and it can reasonably be expected that the >user will have network access. > >If he still doesn't have network access, it's not TEAP's problem IMHO >whether the user can click on the URL and get content. TEAP is just the >messenger; the client device needs to take care about acting on the >message. Agreed. (It is worth noting that PPPoE provides similar functionality using the PADM tag. I am not sure how much use this actually gets, but it does seem to be implemented in various products. In this case the PADM is provided by the other PPP peer, not the EAP server). >>>> General errors >>>> >>>> - Unspecified server problem >>>> - Unspecified authentication failure >>>> - Unspecified authorisation failure >>>> - User account credentials unavailable >>>> - User account expired >>>> - User account locked: try again later >>>> - User account locked: admin intervention required >>>> - Authentication server unavailable >>> >>> I'm not sure about terminology here... "authentication server" often >>> refers to RADIUS servers, EAP servers, or maybe the authentication >>> backend that the EAP server consults to do its work. >>> >>> Since we are talking about inner method failures, and we came to a >>>stage >>> where RADIUS is obviously working, because it demonstrated that it can >>> transport messages to the EAP server; and where the EAP server is >>> obviously working, because it did the entire phase 1 exchange, the >>>error >>> conditions above must refer to the "authentication backend" or >>>"identity >>> management backend" (since that backend contains not just >>>authentication >>> details for connecting entities, but also authorisation information). I >>> like that term more than a "server" (the backend could be a flat file >>>in >>> simple deployments). >>> >>> This would mean changing the first and last one to: >>> >>> - Unspecified ID Management Backend problem >>> - ID Management Backend unavailable >>> >> >> [Joe] I think these or some subset of these are OK. I agree that "authentication server" is confusing. Functionally what I had in mind was the entity that is ultimately authoritative for the user's credentials. Your proposal nearly works for me, but I think I would prefer something a bit more specific if possible. >> >> >>>> - Authentication server not trusted >>> >>> In phase 2 with Password Authentication, the server identity is not >>> verified (again). And for Phase 2 being another EAP method, this >>> untrustedness (as in X.509 verify failure?) would be signalled with a >>> TLS fatal alert in the inner method TLS setup phase. >>> >> >> [Joe] agree with Stefan Ok, there is a misunderstanding here. What I mean is the EAP server not trusting the ID Management System. That might seem a bit odd, but imagine an EAP server trying to authenticate Kerberos against a remote KDC for example. >> >>>> - Clock skew too great >>> >>> Same; clock is irrelevant for password auth. If inner is EAP, the >>>method >>> running either already has a way to signal this to the EAP peer or not; >>> nothing TEAP can do about this. >>> >> >> [Joe] Agree with Stefan Again this was meant to signal a clock skew between the EAP server and the ID Management System. >> >>>> - Invalid inner realm >>> >>> That's good. >>> >>> Where outer and inner EAP terminate at the same server, it may also be >>> possible to check if there was a mismatch between inner and outer >>>realm; >>> which may be administratively prohibited. This would add: >>> >>> - Realm mismatch between inner and outer identity >>> >> >> >> [Joe] I think these are good >> >>>> Password errors >>>> >>>> - User account unknown >>>> >>>> - User account password expired >>>> >>>> - User account password incorrect >>>> >>>> - User account password change required >>> >>> All fine (as in: works for TEAP's password auth - and some inner EAP >>> methods even signal this, e.g. MSCHAPv2; others may not and there is >>> nothing TEAP can do if not). >> >> [Joe] I'm not in favor of adding these. In general they go against >>security guidelines about providing too much information on failed >>authentication. > >That would be too prescriptive in the spec IMHO. If there are >hesitations regarding information leakage, a deployment could configure >that these messages are withheld by the server. Other deployments might >want to take the risk and send the information for more user convenience. > >IMHO, we should define these, but (as all the others actually) make >their *usage* optional. Agreed. >>>> Challenge-Response errors >>>> >>>> - Challenge expired >>>> - Challenge algorithm mismatch >>>> >> >> [Joe] I don't think we should deal with these kinds of errors as they >>don't involve TEAP. >> >>>> >>>> One time password errors >>>> >>>> - Token out of sync: administrator intervention required >>>> - Token out of sync: PIN change required >>>> - Token revoked >>>> - Tokens exhausted >>>> >> >> [Joe] These may be OK, however could these be better handled with the >>password authentication TLVs? >> >>>> Certificate errors >>>> >>>> - User certificate not supplied >>>> - User certificate rejected >>>> >>>> - User certificate validation failure >>>> >>>> - User certificate expired >>>> - User certificate revoked >>>> >>>> - User certificate algorithm mismatch >>>> >>>> - Temporary problem validating user certificate >>> >>> All of these refer to specific, existing EAP types which don't usually >>> provide signalling for these error conditions to their EAP peer. We're >>> sort of lost with these IMHO. Except for the certificate errors; there >>> EAP-TLS can signal some of those error conditions with TLS alerts. But >>> this is again not TEAP's "business". >>> >> >> [Joe] I tend to agree Stefan, I would apply the same reasoning that you give in your first response in this message. I.e., it is precisely because EAP doesn't provide the signalling, even though the EAP server is fully aware of the error condition, that we can substitute with TEAP-based signalling. >> >>>> Channel binding errors >>>> >>>> - Channel binding data required but not supplied >>>> - Channel binding data did not include required information >>>> - Channel binding failed >>> >>> People who know more about channel binding would have to take a look at >>> these. Can the inner method detect that its channel binding with outer >>> failed? Or can that only be done by the outer method? In that case, >>>it's >>> indeed TEAPs business to generate appropriate errors inside phase 2, >>>but >>> outside the EAP conversation that is going on inside Phase 2. >>> >>> Section 3.8.4 should then specify these error conditions. >>> >> >> [Joe] Aren't these already covered by the messaging from RFC 6677? > >Probably. Others here besides me are certainly better informed regarding >CBs, but: 5.3.1 has success and failure. The fact that it was requested >but not supplied is information which is local to the EAP peer; it knows >that it requested it, and knows that it didn't get it -> no protocol >signalling involved here. Aren't these orthogonal issues? RFC 6677 signalling only refers to the CB binding used by the inner method, and not between the TEAP's tunnel and inner method. >>>> Successful outcomes >>>> >>>> - User account expires soon >>>> - User account credential expires soon >>>> - User account authorisations change soon >>>> - Clock skew detected >>>> >>>> - Contact administrator for unspecified reason >>> >>> Again something we can do for password auth, but not if inner EAP is >>>used. >>> >> >> [Joe] wouldn't these be better handled using the Password >>authentication TLVs? > >Well, if we are going to specify lots of extended responses as above, >then these messages here would fit into them equally well. > >Also, Basic-Password-Auth-Req TLV and Basic-Password-Auth-Resp TLV don't >seem to have signalling of their own for these things? Sorry, I don't follow this. Could you elaborate please? 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 _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
