Subject: Re: [saag] Error Handling & Security

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 3 Jul 2012 09:26:25 +0300

Hi David, 

On Jun 19, 2012, at 11:08 PM, David McGrew wrote:

> Hi Hannes,
> 
> On Jun 19, 2012, at 3:33 PM, Hannes Tschofenig wrote:
> 
>> 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. 
>> 
> 
> 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?
> 
The document I was specially referring to was an OAuth assertion draft: 
http://tools.ietf.org/html/draft-ietf-oauth-assertions-04

It re-uses error from the base OAuth specification but does not define new error codes. I suggested to the authors that they should define additional error codes that are specific to the assertion processing (since many things can go wrong with the processing of the content of the assertion). Here was my review:
http://www.ietf.org/mail-archive/web/oauth/current/msg09086.html

Ciao
Hannes

> David
> 
>> 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.
>> 
>> _______________________________________________
>> saag mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/saag
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 3 Jul 2012 09:28:40 +0300

Hi Yaron, 

the destinction between end user presented error and errors that are only shown to the developer certain makes a big difference. 

In OAuth we decided that all errors in the protocol are only processed by the developer. The developer then has to decide what, when and how to show an error (and the error resolution mechanism) to the end user. I don't think that any of the errors in OAuth will easily help end users to resolve the issue given that multi-party protocols are typically to understand (even for developers). 

Ciao
Hannes

On Jun 20, 2012, at 7:40 AM, Yaron Sheffer wrote:

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