On Sep 9, 2013, at 1:44 AM, Josh Howlett <josh.howl...@ja.net> wrote:
> Joe, > > Thanks for this. This looks good, but I am missing: > > - User account credentials incorrect > - User account credentials change required [Joe] I am concerned that these error messages reveal too much information to an attacker. > > > 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 > [Joe] OK thanks, I think I understand your point better now. I'm OK with adding this if there is no objection. > > Finally, what of the "Information-URL" TLV proposal? > [Joe] This seemed to be more of a new feature that I don't feel comfortable adding at this late stage. If there is enough support for it and someone can provide the text then we can try to add it. > Thanks again, Josh. > > On 09/09/2013 04:05, "Joseph Salowey (jsalowey)" <jsalo...@cisco.com> > 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 <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 >>> >> > > > 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
