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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
