Re: [Emu] Some proposed error conditions for TEAP
Looks good to me -- thanks for accommodating this. Josh. On 30/09/2013 00:41, Joseph Salowey (jsalowey) jsalo...@cisco.com wrote: Below is the text for the Error TLV. This should have the error messages we discussed. I also move the CSR related error messages to warnings. Cheers, Joe 4.2.6. Error TLV The Error TLV allows an EAP peer or server to indicate errors to the other party. A TEAP packet can contain 0 or more Error TLVs. The Error-Code field describes the type of error. Error Codes 1-999 represent successful outcomes (informative messages), 1000-1999 represent warnings, and codes 2000-2999 represent fatal errors. A fatal Error TLV MUST be accompanied by a Result TLV indicating failure and the conversation is terminated as described in Section 3.6.3. Many of the error codes below refer to errors in inner method processing that may be retrieved if made available by the inner method. Implementations MUST take care that error messages do not reveal too much information to an attacker. For example, the usage of error message 1031 (User account credentials incorrect) is NOT RECOMMENDED, because it allows an attacker to determine valid usernames by differentiating this response from other responses. It should only be used for troubleshooting purposes. The Error TLV is defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|R| TLV Type |Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error-Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ M Mandatory, set to one (1) R Reserved, set to zero (0) TLV Type 5 for Error TLV Length 4 Error-Code The Error-Code field is four octets. Currently defined values for Error-Code include: 1 User account expires soon 2 User account credential expires soon 3 User account authorisations change soon 4 Clock skew detected 5 Contact administrator 6 User account credentials change required 1001 Inner Method Error 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 1022 Unsupported Algorithm In Certificate Signing Request 1023 Unsupported Extension In Certificate Signing Request 1024 Bad Identity In Certificate Signing Request 1025 Bad Certificate Signing Request 1026 Internal CA Error 1027 General PKI Error 1028 Inner method's channel binding data required but not supplied 1029 Inner method's channel binding data did not include required information 1030 Inner method's channel binding failed 1031 User account credentials incorrect [USAGE NOT RECOMMENDED] 2001 Tunnel Compromise Error 2002 Unexpected TLVs Exchanged On Sep 10, 2013, at 9:44 AM, Joseph Salowey (jsalowey) jsalo...@cisco.com wrote: On Sep 9, 2013, at 8:10 AM, Josh Howlett josh.howl...@ja.net wrote: - User account credentials incorrect - User account credentials change required [Joe] I am concerned that these error messages reveal too much information to an attacker. I agree there are risks if used inappropriately, but nonetheless there are reasonable uses for these (for example, switching it on temporarily when debugging)
Re: [Emu] Some proposed error conditions for TEAP
Below is the text for the Error TLV. This should have the error messages we discussed. I also move the CSR related error messages to warnings. Cheers, Joe 4.2.6. Error TLV The Error TLV allows an EAP peer or server to indicate errors to the other party. A TEAP packet can contain 0 or more Error TLVs. The Error-Code field describes the type of error. Error Codes 1-999 represent successful outcomes (informative messages), 1000-1999 represent warnings, and codes 2000-2999 represent fatal errors. A fatal Error TLV MUST be accompanied by a Result TLV indicating failure and the conversation is terminated as described in Section 3.6.3. Many of the error codes below refer to errors in inner method processing that may be retrieved if made available by the inner method. Implementations MUST take care that error messages do not reveal too much information to an attacker. For example, the usage of error message 1031 (User account credentials incorrect) is NOT RECOMMENDED, because it allows an attacker to determine valid usernames by differentiating this response from other responses. It should only be used for troubleshooting purposes. The Error TLV is defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|R| TLV Type |Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error-Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ M Mandatory, set to one (1) R Reserved, set to zero (0) TLV Type 5 for Error TLV Length 4 Error-Code The Error-Code field is four octets. Currently defined values for Error-Code include: 1 User account expires soon 2 User account credential expires soon 3 User account authorisations change soon 4 Clock skew detected 5 Contact administrator 6 User account credentials change required 1001 Inner Method Error 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 1022 Unsupported Algorithm In Certificate Signing Request 1023 Unsupported Extension In Certificate Signing Request 1024 Bad Identity In Certificate Signing Request 1025 Bad Certificate Signing Request 1026 Internal CA Error 1027 General PKI Error 1028 Inner method's channel binding data required but not supplied 1029 Inner method's channel binding data did not include required information 1030 Inner method's channel binding failed 1031 User account credentials incorrect [USAGE NOT RECOMMENDED] 2001 Tunnel Compromise Error 2002 Unexpected TLVs Exchanged On Sep 10, 2013, at 9:44 AM, Joseph Salowey (jsalowey) jsalo...@cisco.com wrote: On Sep 9, 2013, at 8:10 AM, Josh Howlett josh.howl...@ja.net wrote: - User account credentials incorrect - User account credentials change required [Joe] I am concerned that these error messages reveal too much information to an attacker. I agree there are risks if used inappropriately, but nonetheless there are reasonable uses for these (for example, switching it on temporarily when debugging) as these are very common error conditions. I suggest that these be optional to implement and use, and that we have security
Re: [Emu] Some proposed error conditions for TEAP
On Sep 9, 2013, at 8:10 AM, Josh Howlett josh.howl...@ja.net wrote: - User account credentials incorrect - User account credentials change required [Joe] I am concerned that these error messages reveal too much information to an attacker. I agree there are risks if used inappropriately, but nonetheless there are reasonable uses for these (for example, switching it on temporarily when debugging) as these are very common error conditions. I suggest that these be optional to implement and use, and that we have security considerations text that highlights the issue. Happy to propose some text. [Joe] I'm not really in favor of including things in standards that should not be used. I am concerned that this could delay the document. If you provide some sample text and no-one objects then I will include this in the document. 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 ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Some proposed error conditions for TEAP
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) 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
Re: [Emu] Some proposed error conditions for TEAP
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
Re: [Emu] Some proposed error conditions for TEAP
- User account credentials incorrect - User account credentials change required [Joe] I am concerned that these error messages reveal too much information to an attacker. I agree there are risks if used inappropriately, but nonetheless there are reasonable uses for these (for example, switching it on temporarily when debugging) as these are very common error conditions. I suggest that these be optional to implement and use, and that we have security considerations text that highlights the issue. Happy to propose some text. 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 ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Some proposed error conditions for TEAP
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
Re: [Emu] Some proposed error conditions for TEAP
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
Re: [Emu] Some proposed error conditions for TEAP
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
