Here is my proposed revisions for this thread - Add the following successful outcomes (informative messages)
1 - User account expires soon 2 - User account credential expires soon 3 - User account authorisations change soon 4 - Clock skew detected 5 - Contact administrator for unspecified reason Add the following warnings: 1002 - Unspecified authentication infrastructure problem 1003 - Unspecified authentication failure 1004 - Unspecified authorisation failure 1005 - User account credentials unavailable 1006 - User account expired 1007 - User account locked: try again later 1008 - User account locked: admin intervention required 1009 - Authentication infrastructure unavailable 1010 - Authentication infrastructure not trusted 1011 - Clock skew too great 1012 - Invalid inner realm 1013 - Token out of sync: administrator intervention required 1014 - Token out of sync: PIN change required 1015 - Token revoked 1016 - Tokens exhausted 1017 - Challenge expired 1018 - Challenge algorithm mismatch 1019 - Client certificate not supplied 1020 - Client certificate rejected 1021 - Realm mismatch between inner and outer identity Thanks, Joe On Sep 2, 2013, at 6:54 AM, Stefan Winter <stefan.win...@restena.lu> wrote: > Hi, > >> 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. > > That's indeed a different meaning from what I thought it would be. In > that case, the error message makes a lot more sense. > >> Again this was meant to signal a clock skew between the EAP server and the >> ID Management System. > > Okay. > >> 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. > > ... in the cases where luck has it that we know on the TEAP layer what > happened elsewhere. > > Fine for me :-) > >>> 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. > > I'll let the CB gurus pick up that one. :-) > >>>> [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? > > Joe wants the error messages to be stuffed into the password > authentication TLVs. These are: > > Basic-Password-Auth-Req TLV > Basic-Password-Auth-Resp TLV > > I'm claiming that this can't work, because the server may discover that > its backend is inaccessible only after it has sent its Req. Remember > that Req is sent from the *server* to the *peer* as in: > > Server: Req: "User, what's your username and password?" > Server: Resp: "johndoe/stupidpassword" > Server: ... looking up that combo ... Oh! My backend is gone! > > Since both Req and Resp have already played their part, none of these > two TLVs can carry an error message at this point. The generic Error TLV > that we're discussing in this thread is the only place to put such error > messages in. > > Greetings, > > Stefan Winter > >> >> 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 >> > > > -- > 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 > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
