Subject: [Emu] Some proposed error conditions for TEAP

From: Josh Howlett <[email-masked]>
Date: Sat, 3 Aug 2013 10:53:07 +0000

As discussed in Berlin, to get the ball rolling here is an initial
proposal for some inner method error conditions.

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

Josh.

---

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

- Authentication server not trusted
- Clock skew too great
- Invalid inner realm

Password errors

- User account unknown

- User account password expired

- User account password incorrect

- User account password change required

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

Channel binding errors

- Channel binding data required but not supplied
- Channel binding data did not include required information
- Channel binding failed

Successful outcomes

- User account expires soon
 - User account credential expires soon
- User account authorisations change soon
- Clock skew detected

- Contact administrator for unspecified reason

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: Thu, 08 Aug 2013 12:23:06 +0200

Hi,

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

> where, for example, user notification or action is desirable (e.g.,

I like that one.

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

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

> - 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 data did not include required information

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.

> - Contact administrator for unspecified reason

Again something we can do for password auth, but not if inner EAP is used.

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: Sam Hartman <[email-masked]>
Date: Wed, 14 Aug 2013 16:22:14 -0400

IESG, we seem to have a case where a document is on tomorrow's agenda
but a last-call discussion got left hanging.
Josh Howlett brought forward a last call comment about error handling;
it was discussed in the Berlin session.
There seemed to be general support for adding errors.  Josh proposed a
set of errors  that day.
There was one response, but as best I can tell the discussion kind of
dangled while still active as everyone recovered from the IETF.

I think this issue should be resolved before approval.

>>>>> "Stefan" == Stefan Winter <[email-masked]> writes:

    Stefan> Hi,
    >> As discussed in Berlin, to get the ball rolling here is an
    >> initial proposal for some inner method error conditions.

    Stefan> The question IMHO is: there are many inner EAP methods
    Stefan> specified already, and they don't typically specify or
    Stefan> signal most of the error conditions below to the EAP
    Stefan> peer. The TEAP document can't impose change on all those
    Stefan> inner methods; they are what they are. If they tell neither
    Stefan> the EAP peer nor export that information to the TEAP layer,
    Stefan> then there is nothing we can write in the TEAP document that
    Stefan> will make it happen.

agreed.

    Stefan> This limits the scope of the error conditions to cases where
    Stefan> TEAP has "all in its own hands" - which I believe is limited
    Stefan> to the "Optional Password Authentication" of chapter 3.3.2.

DIsagreed.
AAA servers don't signal all of these up, but AAA servers often signal a
number of these.
For example in Freeradius I could actually figure out a number of these
even across an inner tunnel and could easily expand the server to do
better than that.
However if you have nothing else then  you are left with inner method
error.

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Thu, 15 Aug 2013 21:54:04 +0000

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

>> where, for example, user notification or action is desirable (e.g.,

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

> - ID Management Backend unavailable

[Joe] I think these or some subset of these are OK. 

> TLS fatal alert in the inner method TLS setup phase.

[Joe] agree with Stefan

> nothing TEAP can do about this.

[Joe] Agree with Stefan

> - Realm mismatch between inner and outer identity

[Joe] I think these are good 

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

>> - Challenge algorithm mismatch

[Joe]  I don't think we should deal with these kinds of errors as they don't involve TEAP.  

>> - Token out of sync: PIN change required

[Joe]  These may be OK, however could these be better handled with the password authentication TLVs?

> this is again not TEAP's "business".

[Joe] I tend to agree

> Section 3.8.4 should then specify these error conditions.

[Joe] Aren't these already covered by the messaging from RFC 6677?  

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

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

---

From: Stefan Winter <[email-masked]>
Date: Mon, 19 Aug 2013 12:54:29 +0200

Hi,

> However if you have nothing else then  you are left with inner method

Yes, it occured to me afer sending that my mind model was maybe a bit
too strict: there is no /protocol/ way for things to transpire from
inner to outer; but there may be be other means (like shared memory in
the server process) *if* inner and outer terminate at the same server.
If the inner method is proxied elsewhere, then we're out of luck in
terms of getting specific error conditions from the inner method;
"proper" protocol-based signaling would then be required but doesn't exist.

I guess it comes down to wordsmithing to express this correctly; like
"will work for TEAP's simple password auth, and *may* work for inner
EAP, if inner and outer termination point are co-located, or otherwise
have an unspecified out-of-band protocol of their own for signalling
error conditions between inner and outer termination point."

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Sam Hartman <[email-masked]>
Date: Sat, 24 Aug 2013 09:31:51 -0400

>>>>> "Stefan" == Stefan Winter <[email-masked]> writes:

I think this is too detailed.
The error codes MAY be used.
Full stop.
Whether you can is a complex policy and implementation discussion best
hidden behind a MAY.

---

From: Stefan Winter <[email-masked]>
Date: Mon, 26 Aug 2013 09:44:29 +0200

Hi,

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

> [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 cons…

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.

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

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

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

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473