Hi, > As discussed in Berlin, to get the ball rolling here is an initial > proposal for some inner method error conditions.
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. > 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. > 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 > - 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. > - 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. > - 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 > 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). > Challenge-Response errors > > - Challenge expired > - Challenge algorithm mismatch > > > One time password errors > > - Token out of sync: administrator intervention required > - Token out of sync: PIN change required > - Token revoked > - Tokens exhausted > > 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". > 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. > 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. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
