Subject: Re: [Emu] Some proposed error conditions for TEAP

From: Josh Howlett <[email-masked]>
Date: Mon, 2 Sep 2013 10:39:35 +0000

Apologies for the delayed response.

>>>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.
>>>
>> 
>> [Joe] I tend to agree that we shouldn't try to address errors that are
>>specific to inner methods.  We should stick to things that are TEAP
>>specific. 
>
>Sam's point is also valid though; even if we don't care protocol-wise
>about what inner EAP methods are doing, an implementation might be lucky
>and learn about inner method failures via unspecified means. It could
>then communicate those failures on the TEAP layer; if only our
>dictionary is flexible enough to be useful for these cases.

Agreed. My view is that we should make the dictionary as expressive as
reasonably possible, while taking care not to impose unnecessary
complexity on EAP server implementations (for whatever reason) where these
might be unattractive to implement. For these new error conditions, I
think it would be sufficient to define the dictionary, and allow
implementors to decide what to implement. From the supplicant's
perspective, any information is better than none.

>>>> 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.
>>>
>> 
>> [Joe] So I would prefer to address this in a separate document.  I can
>>see some issues here.  How does one access the URL if they fail to get
>>network access?  I imagine there are some security considerations around
>>connecting to some URL specified by the server.  I suppose it would be
>>OK if the client can authenticate and trust the server.
>
>The suggestion was to send this URL only after a *success*. Then the URL
>comes from a trusted source, and it can reasonably be expected that the
>user will have network access.
>
>If he still doesn't have network access, it's not TEAP's problem IMHO
>whether the user can click on the URL and get content. TEAP is just the
>messenger; the client device needs to take care about acting on the
>message.

Agreed.

(It is worth noting that PPPoE provides similar functionality using the
PADM tag. I am not sure how much use this actually gets, but it does seem
to be implemented in various products. In this case the PADM is provided
by the other PPP peer, not the EAP server).

>>>> 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
>>>
>> 
>> [Joe] I think these or some subset of these are OK.

I agree that "authentication server" is confusing. Functionally what I had
in mind was the entity that is ultimately authoritative for the user's
credentials. Your proposal nearly works for me, but I think I would prefer
something a bit more specific if possible.

>> 
>> 
>>>> - 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.
>>>
>> 
>> [Joe] agree with Stefan

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.

>> 
>>>> - 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.
>>>
>> 
>> [Joe] Agree with Stefan

Again this was meant to signal a clock skew between the EAP server and the
ID Management System.

>> 
>>>> - 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
>>>
>> 
>> 
>> [Joe] I think these are good
>> 
>>>> 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).
>> 
>> [Joe] I'm not in favor of adding these.  In general they go against
>>security guidelines about providing too much information on failed
>>authentication. 
>
>That would be too prescriptive in the spec IMHO. If there are
>hesitations regarding information leakage, a deployment could configure
>that these messages are withheld by the server. Other deployments might
>want to take the risk and send the information for more user convenience.
>
>IMHO, we should define these, but (as all the others actually) make
>their *usage* optional.

Agreed.

>>>> Challenge-Response errors
>>>>
>>>> - Challenge expired
>>>> - Challenge algorithm mismatch
>>>>
>> 
>> [Joe]  I don't think we should deal with these kinds of errors as they
>>don't involve TEAP.
>> 
>>>>
>>>> One time password errors
>>>>
>>>> - Token out of sync: administrator intervention required
>>>> - Token out of sync: PIN change required
>>>> - Token revoked
>>>> - Tokens exhausted
>>>>
>> 
>> [Joe]  These may be OK, however could these be better handled with the
>>password authentication TLVs?
>> 
>>>> 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".
>>>
>> 
>> [Joe] I tend to agree

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.

>> 
>>>> 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.
>>>
>> 
>> [Joe] Aren't these already covered by the messaging from RFC 6677?
>
>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.

>>>> Successful outcomes
>>>>
>>>> - User account expires soon
>>>> - User account credential expires soon
>>>> - User account authorisations change soon
>>>> - Clock skew detected
>>>>
>>>> - Contact administrator for unspecified reason
>>>
>>> Again something we can do for password auth, but not if inner EAP is
>>>used.
>>>
>> 
>> [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?

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

---

From: Stefan Winter <[email-masked]>
Date: Mon, 02 Sep 2013 15:54:23 +0200

Hi,

> an EAP server trying to authenticate Kerberos against a remote KDC for

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

Okay.

> 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 :-)

> binding used by the inner method, and not between the TEAP's tunnel and

I'll let the CB gurus pick up that one. :-)

> 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

-- 
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

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 9 Sep 2013 03:05:23 +0000

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

---

From: Josh Howlett <[email-masked]>
Date: Mon, 9 Sep 2013 08:44:22 +0000

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.

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 9 Sep 2013 14:57:51 +0000

> - User account credentials change required

[Joe] I am concerned that these error messages reveal too much information to an attacker. 

> - 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.

---

From: Josh Howlett <[email-masked]>
Date: Mon, 9 Sep 2013 15:10:48 +0000

>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.

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 10 Sep 2013 16:44:44 +0000

> 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.

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Sun, 29 Sep 2013 23:41:58 +0000

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) <[email-masked]> wrote:

> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu

---

From: Josh Howlett <[email-masked]>
Date: Mon, 30 Sep 2013 09:18:00 +0000

Looks good to me -- thanks for accommodating this.

Josh.

On 30/09/2013 00:41, "Joseph Salowey (jsalowey)" <[email-masked]>
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
>
>> [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.
>>> 
>>> 
>>>