Subject: Re: [saag] Error Handling & Security

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 19 Jun 2012 22:33:42 +0300

I guess I need to provide a bit of additional background for my question. 

In the OAuth working group folks are currently arguing that they do not want to provide more detailed error responses in protocol exchanges or in some cases no error message at all (even an error happened) -- essentially being silent. 

The argument that this is good for security but while I agree that one needs to be careful about the information that is being provided back to the client in case of an error I still see value in providing more detailed error response. 

As such, this is a bit unrelated to the question of what debug level is currently enabled at the client software or what specifically is shown to the user. 

Without any information from the server (in case of an error) the client software can obviously only guess what happens. 

Ciao
Hannes

On Jun 18, 2012, at 3:20 PM, Peter Gutmann wrote:

> Hannes Tschofenig <[email-masked]> writes:
> 
>> Experience or views from others?
> 
> I've been recommending that you make it a debug option that has to be
> explicitly enabled, that adds extra noise to the protocol (e.g. an SSH banner)
> to make it obvious that it's enabled, and that turns itself off again after a
> set time or number of protocol runs.
> 
> Peter.

---

From: David McGrew <[email-masked]>
Date: Tue, 19 Jun 2012 16:08:16 -0400

Hi Hannes,

> Without any information from the server (in case of an error) the client software can obviously only guess what happens. 

this is an interesting question.   As I am sure that you already know, crypto should be "atomic", that is, the error messages returned from cryptographic operations should not give details about what went wrong in the crypto processing (such as padding errors, decoding errors, and the like).   What is less clear are the other error messages that would give out information such as which security options are actually in effect.  Are the (potential) error messages listed/documented somewhere?

David

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

---

From: <[email-masked]>
Date: Tue, 19 Jun 2012 16:10:59 -0400

Hannes,

It's hard to say anything concrete without more details.  For example, it's always
good to report syntax errors detected before security processing (e.g., recipient
can't extract the authentication request arguments/parameters from what was received).
At the other extreme, there are situations where a response is never a good idea -
one example is that IKEv2 specifies that an Informational message sent without
cryptographic protection (e.g., to tell a sender that it needs to forget about an
IKEv2 SA because there's no state for it at the receiver) MUST NOT be responded to.

I think it comes down to looking at the details of "value in providing more
detailed error response" in conjunction with "be careful about the information
that is being provided back to the client", i.e., risk analysis as previously noted.

Thanks,
--David

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Hannes
> Tschofenig
> Sent: Tuesday, June 19, 2012 3:34 PM
> To: Peter Gutmann
> Cc: [email-masked]
> Subject: Re: [saag] Error Handling & Security
> 
> In the OAuth working group folks are currently arguing that they do not want
> to provide more detailed error responses in protocol exchanges or in some
> cases no error message at all (even an error happened) -- essentially being
> silent.
> 
> The argument that this is good for security but while I agree that one needs
> to be careful about the information that is being provided back to the client
> in case of an error I still see value in providing more detailed error
> response.
> 
> As such, this is a bit unrelated to the question of what debug level is
> currently enabled at the client software or what specifically is shown to the
> user.
> 
> Without any information from the server (in case of an error) the client
> software can obviously only guess what happens.
> 
> Ciao
> Hannes
> 
>

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 20 Jun 2012 07:40:36 +0300

Hi Hannes,

One factor in this decision is the distinction between end-user errors 
(these errors that would benefit the end user) vs. developer errors. The 
trade-off between helpfulness and security should be different for the 
two types.

For many protocols the only useful end-user error is "authentication 
failed" (of course with better wording for the intended audience). In 
some case "authorization failed" is also useful - you know then that you 
need to ask your system administrator for additional permissions.

In the case of end-user errors my personal preference is for the most 
informative response possible. For example: "3 more tries before we lock 
you out of your account".

On the other hand, we can be more stingy with indications that are only 
useful to a developer. Presumably the detailed errors are sent to an 
internal log (maybe optionally, to prevent timing attacks and DoS). And 
developers should have the option to approach the service owner directly 
to resolve interoperability issues.

Thanks,
	Yaron

On 06/19/2012 10:33 PM, Hannes Tschofenig wrote:
>> Hannes Tschofenig<[email-masked]>  writes:
>>

---

From: "KIHARA, Boku" <[email-masked]>
Date: Wed, 20 Jun 2012 18:09:57 +0900

Hannes,

I think it depends on the policies of service providers,
but having sandbox environments would be one solution.

In a sandbox environment, verbose messages are returned so that
developers can easily debug their products, without revealing any
information about *real* users. Meanwhile servers in the real
environment provide little or no information about errors to prevent
attackers from getting helps.

This method is somewhat costly, introducing the trade-off axis of cost.

Cheers,
Boku

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 20 Jun 2012 11:55:03 -0400

On Tue, 2012-06-19 at 22:33 +0300, Hannes Tschofenig wrote:
> In the OAuth working group folks are currently arguing that they do not
>  want to provide more detailed error responses in protocol exchanges or
>  in some cases no error message at all (even an error happened) --
>  essentially being silent. 

This seems a bit silly.  This is almost entirely a policy decision, and
you're attempting to inform protocol design by asking what the policy
should be instead of what policies are possible.  The protocol spec
should not mandate a particular level of error reporting (or lack
thereof); that is up to the operator.

My advice: provide a mechanism for reporting errors and for doing so
with the level of detail necessary for actually resolving problems.
Don't mandate that the error-reporting mechanism be used, except in
cases where it is needed to make the protocol work.  But, don't prohibit
reporting detailed error information either, except in cases where doing
so would directly break the security of the protocol.  Finally, _do_
make sure the security considerations include a discussion of the
tradeoffs in error reporting.

-- Jeff

---

From: Michael Richardson <[email-masked]>
Date: Wed, 20 Jun 2012 13:29:16 -0400

>>>>> "Hannes" == Hannes Tschofenig <[email-masked]> writes:
    Hannes> The argument that this is good for security but while I
    Hannes> agree that one needs to be careful about the information
    Hannes> that is being provided back to the client in case of an
    Hannes> error I still see value in providing more detailed error
    Hannes> response.  

It's a bogus argument to me.
Security has to work be secure.

If the protocol is too hard to debug, it will get turned off, and the
result is that an inferior and less secure protocol will be used.

In this case, this means storing access passwords in the clear in
supplicant web servers.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: Michael Richardson <[email-masked]>
Date: Wed, 20 Jun 2012 16:38:20 -0400

---

From: Michael Richardson <[email-masked]>
Date: Wed, 20 Jun 2012 16:38:30 -0400

>>>>> "Jeffrey" == Jeffrey Hutzelman <[email-masked]> writes:
    Jeffrey> This seems a bit silly.  This is almost entirely a policy
    Jeffrey> decision, and you're attempting to inform protocol design
    Jeffrey> by asking what the policy should be instead of what
    Jeffrey> policies are possible.  The protocol spec 
    Jeffrey> should not mandate a particular level of error reporting (or lack
    Jeffrey> thereof); that is up to the operator.

+1