Joe, Thanks for this. This looks good, but I am missing:
- User account credentials incorrect - User account credentials change required And also (using "Inner method" to disambiguate inner method CB from TEAP's own CB): - Inner method's channel binding data required but not supplied - Inner method's channel binding data did not include required information - Inner method's channel binding failed Finally, what of the "Information-URL" TLV proposal? Thanks again, Josh. On 09/09/2013 04:05, "Joseph Salowey (jsalowey)" <[email protected]> wrote: >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 <[email protected]> >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 >> > 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 [email protected] https://www.ietf.org/mailman/listinfo/emu
