Subject: Re: [kitten] RFC5802: question about unknown-user error

From: Jehan Pagès <[email-masked]>
Date: Sun, 13 Mar 2011 20:50:05 +0900

Hi,

again I come after so long time. Sorry for the delay.

2011/1/20 Jehan Pagès <[email-masked]>:
> Hi,
>
> On Tue, Dec 7, 2010 at 6:52 AM, Jeffrey Hutzelman <[email-masked]> wrote:
>> --On Saturday, December 04, 2010 01:53:39 AM +0900 Jehan Pagès
>> <[email-masked]> wrote:
>>
>>> I agree about this, but first we can fix this in SCRAM by removing the
>>> unknown-user error
>>
>> No.  Not reporting unknown-user is a policy preference, and one which the
>> protocol already permits.  You now propose to encode your policy preference
>> into the protocol, thereby usurping the operator's authority to set policy.
>>
>> -- Jeff
>>
>
> This is why in the end, I was proposing not to modify the protocol but
> to make it a security note. I quote myself:

The other day, I was rereading through the RFC 4422 (SASL) and I saw
this line, section "3.6 Authentication Outcome". I don't know why it
did not hit me before:
«
   It is also
   important that the server can be configured such that the outcome
   message will not distinguish between a valid user with invalid
   credentials and an invalid user.
»

So that's basically exactly what I propose in SCRAM which, as a SASL
mechanism should then follow its directives! Currently in SCRAM we
drop a list of errors without any security directives on them. And one
of these errors simply tell that the user is invalid (unknown-user)! I
think it is worth to add the security directive for servers to be
configurable for showing or not this error (the finale decision then
later depending on the operator's choice, needs or policy
preferences).

> «
> So I think this would deserve a security note telling implementers
> they can implement this way to avoid data leak. I will try to make a
> proposition later.
> »
>
> Then it is up to the implementers and/or the configuration of the
> server, then to the operators (for instance during installation, you
> may like to test with more informative errors, then once in
> production, you switch on "secure" configuration not to give away
> username's information with errors).
> So at least as a security note, expose this concern, give
> alternatives, and leave implementers/operators decide how they wish to
> do and what they set as higher importance.
>
> Without a security note about this, everybody would probably implement
> it exactly as it is currently, then there will be no different "policy
> preferences" to choose from by the operator.
>
> I will come later with a text proposition exposing both logics and
> their respective advantages as discussed on this thread, then you can
> tell me.
> Thanks.

So here is my proposition:
in section 9. Security Considerations, add the following text:

«
As specified in [RFC4422] (section 3.6), "it is also important that
the server can be configured such that the outcome message will not
distinguish between a valid user with invalid credentials and an
invalid user", hence in particular that the error value "unknown-user"
may be easily replaced by "other-error" if required by an operator's
policy.

More generally a server should be configurable so that any error which
could lead to information disclosure can be replaced by "other-error".
»

And as an additional note now.
Actually when I re-re-read the RFC4422, it says clearly:

«
3.6. Authentication Outcome

At the conclusion of the authentication exchange, the server sends a
   message, the particulars of which are protocol specific, to the
   client indicating the outcome of the exchange.
   [...]
   The protocol may include an optional additional data field in this
   outcome message.  *This field can only include additional data when
   the outcome is successful.*
   [...]
   The outcome message provided by the server can provide a way for the
   client to distinguish between errors [...]
»

What I understand here is that the error should not be dealt on SASL
level but on the higher level protocol. For instance in XMPP, we
indeed give error on XMPP level only.
So I think the whole error list in SCRAM as additional data to be sent
on failed outcome is violating the SASL RFC.

If such an error is to be generated by the authentication module of
the server, it should be meant to be informational for the server
(which after does whatever it wants with it, like forwarding the error
if the protocol allows sending errors on outcome, filtering out
information-disclosure errors, and so on).

Hence I wonder if this list should not be removed from the Formal
Syntax (section 7) because it does not belong to the SASL exchange
itself (as forbidden by RFC4422) and moved to another section as error
information from an authentication module to a server.

And the security consideration I propose still holds here if the
server was to eventually forward this error.
Regards,

Jehan

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 13 Mar 2011 13:03:49 +0100

>    the outcome is successful.*

I believe you are right and that additional error codes aren't
permitted.

> information from an authentication module to a server.

My implementation (GNU SASL) never generates (or parse) error codes.
How do other SCRAM implementations behave?

I always thought of the error codes as an unnecessary complication of
the protocol, but since they are optional I have mentally just ignored
that part of the specification.  I wouldn't oppose removing them from
RFC 5802bis.

/Simon

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 13 Mar 2011 16:22:51 +0000

>How do other SCRAM implementations behave?
My implementation doesn't do that either.
I think Nico wanted to have them for GSS-API implementations.

>that part of the specification.  I wouldn't oppose removing them from
I wouldn't be opposed to that either but I want to hear what Nico has to 
say first.

---

From: Chris Newman <[email-masked]>
Date: Mon, 14 Mar 2011 14:04:14 -0700

--On March 13, 2011 20:50:05 +0900 Jehan Pagès 
<[email-masked]> wrote:
> drop a list of errors without any security directives on them.

Of course to implement SCRAM according to specification, one also has to 
implement RFC 4422 so the above rule applies. Having the error as an option 
is not contradictory to the rule. I'm supportive of repeating the RFC 4422 
security advice in SCRAM or making the reference to it clearer.

> on failed outcome is violating the SASL RFC.

It's not an RFC violation (particularly due to the wording of 5.2-2b in RFC 
5802), one merely has to add an additional round-trip to the SASL exchange 
in order to communicate the error information. If I implement the error 
codes (and I might since I'm a big fan of additional diagnostics and the 
application protocols that use SASL don't always have enough standardized 
authentication diagnostics) then there will be an option to turn the extra 
round trip off.

I'm not opposed to removing the SCRAM-layer errors in a revision, 
particularly if they fail the multiple interoperable implementation test 
(and there's a good chance they will since SCRAM clients may not handle the 
extra round-trip correctly if they've never been tested against a server to 
does it).

		- Chris

---

From: Jehan Pagès <[email-masked]>
Date: Wed, 16 Mar 2011 03:33:40 +0900

Hi,

On Tue, Mar 15, 2011 at 6:04 AM, Chris Newman <[email-masked]> wrote:
> --On March 13, 2011 20:50:05 +0900 Jehan Pagès <[email-masked]>
> wrote:
>>
>> «
>>   It is also

Good.

> authentication diagnostics) then there will be an option to turn the extra

As for my own, the more I read the SASL RFC, the more I become sure
this is a violation to RFC4422. What I understand from the SASL RFC is
that there is NO error code at the SASL level, but it says that there
can be at the higher protocol level. That's indeed what we do in XMPP
for instance:

<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
        <not-authorized/>
</failure>

The error is an XML tag because it is at XMPP level (oppositely to a
SASL success's additional data which would be an a base64-encoded data
inside the tags, and when decoded, it will be whatever syntax the SASL
mechanism requires).

I think that's also why at least already 3 implementations (Alexey
Melnikov, Simon Josefsson and mine) don't implement them. Obviously we
first implemented SASL as a generic library and over this, we
implemented SCRAM. Then it is how I understood that there is simply
"no place" for errors in a SASL implementation written following the
RFC!

As I said, we can keep the error list, but I think it must be a list
of error that we propose for the protocol above to eventually send it
in its own syntax (with appropriate security warning about information
disclosure as we discussed first), but it cannot be part of the SASL
syntax.

That's how I read this all at least.

Jehan

---

From: Chris Newman <[email-masked]>
Date: Tue, 15 Mar 2011 16:15:48 -0700

--On March 16, 2011 3:33:40 +0900 Jehan Pagès <[email-masked]> 
wrote:
> this is a violation to RFC4422.

Violation is far too strong a word. RFC 4422 reports primary errors in the 
application protocol and not in the security mechanisms. This is obvious 
from the design of the early SASL profiles and mechanisms. But there's 
nothing in the specification forbidding additional diagnostics at the 
mechanism layer and it would be a mistake for SASL to add such a 
restriction as it would reduce the flexibility and adaptability of SASL.

Application protocols have limited diagnostics and it's certainly more 
difficult to add a new helpful diagnostic to every application with a SASL 
profile than it is to include additional diagnostics in a new SASL 
mechanism.

> "no place" for errors in a SASL implementation written following the

A SASL mechanism is encapsulated as a bag of bits with arbitrary round 
trips in an application profile. A mechanism can put anything it wants in 
that bag of bits unless it's explicitly forbidden with a MUST NOT in RFC 
4422.

> disclosure as we discussed first), but it cannot be part of the SASL

Having a "best practice" document of authentication errors that most 
application protocols should implement is something I'd find useful. I find 
the piecemeal approach to improving application error codes (RFC 5530, RFC 
3206, RFC 3463) rather unsatisfactory. It would also be a cleaner design if 
all application protocols had the 20 or so most useful authentication 
diagnostics. But they don't and I don't see volunteers to write specs to 
update all of them. So having a way to provide ancillary diagnostics in a 
mechanism for those profiles with too few authentication diagnostics seems 
pragmatic to me.

I'm not sure any of the diagnostics in SCRAM are compelling so if they get 
removed as part of interop testing for advancement to draft status, I don't 
care (the simplicity improvement is roughly equivalent to the diagnostic 
benefit in my opinion). But I would strongly oppose altering SASL to forbid 
mechanism-layer diagnostics.

		- Chris

---

From: Nico Williams <[email-masked]>
Date: Tue, 22 Mar 2011 16:34:10 -0500

> I think Nico wanted to have them for GSS-API implementations.

Highly informative errors are a security problem.  They are also a debug tool.

I would prefer that by default implementations use only the most
generic error codes that convey the minimum absolutely necessary
information.  But they could/should be configurable to return more
informative error codes.  I would also prefer that implementations of
_applications_ send error messages instead of, say, simply closing a
connection (because in some protocols one may want to retry), but I'd
be fine with application implementations that just close the
connection.

That's a large range of permitted behavior.  I'm not at all opposed to
it, and, indeed, would be happy to see that explicitly allowed in the
erratum.

> I wouldn't be opposed to that either but I want to hear what Nico has to say
> first.

For me they are entirely optional.  I would rather they stay.  Indeed,
we can't really remove them in an erratum -- we can only really add
guidance -- and I'm not willing to do the work of re-publishing this
RFC nor any update, not for this sort of issue.  Others might well be
willing to do that work though.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 22 Mar 2011 16:44:16 -0500

2011/3/15 Chris Newman <[email-masked]>:
> mechanism layer and it would be a mistake for SASL to add such a restriction
> as it would reduce the flexibility and adaptability of SASL.

+1.  It is quite a stretch to say that SCRAM is in violation of SASL
here.  It is NOT a stretch to say that more guidance on when to use
which error code (only one code is mentioned in the text) should have
been provided, so let's do that.

> profile than it is to include additional diagnostics in a new SASL

+1.

And, as Alexey pointed out, there's the GSS-API side of SCRAM.  Unlike
SASL, GSS-API applications don't usually have any sort of free-form
application protocol field via which to transmit any kind of detailed
error information.  (Also, SASL apps that do have such a thing usually
can't localize it, which is another reason for wanting to have
detailed error codes.)  For this reason I'd oppose removal of these
error codes.

> A SASL mechanism is encapsulated as a bag of bits with arbitrary round trips
> in an application profile. A mechanism can put anything it wants in that bag
> of bits unless it's explicitly forbidden with a MUST NOT in RFC 4422.

And via GS2, we also get any bits that any GSS-API mechanism might
want to put in there as well.  That's another side of the coin
mentioned by Alexey.  I am opposed to any language in SASL/GS2 that
says that GSS-API mechanisms (which SCRAM is) MUST NOT send detailed
error information -- that would be a layering violation.

Note that the same rationale that leads one to want SASL mechanisms to
by default provide minimal error information also leads to the same
conclusion in the GSS-API.  But this is not a get-out-of-jail-free
card for the layering violation that would occur if we insisted on
prohibiting detailed error information in SASL itself.

>> disclosure as we discussed first), but it cannot be part of the SASL

Absolutely not.  See above.  I am opposed to any requirements that
entail changes to application protocols in the cases of applications
where detailed error codes are ever desirable.

> mechanism-layer diagnostics.

+1.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 22 Mar 2011 16:48:14 -0500

This thread has gone on long enough.  IMO we do not have consensus on
prohibiting the use of or removing the detailed error codes.  IMO we
do have consensus on adding guidance indicating that by default
implementations should send the most general / least informative error
codes (the one exception, I think would be for the
extensions-not-supported case).

My position, after an already lengthy thread, is not likely to change
materially, so either I end up on the rough side of consensus or we
all settle for adding guidance.  If need be let's have a consensus
call and see what happens.

Nico
--

---

From: Dave Cridland <[email-masked]>
Date: Tue, 22 Mar 2011 22:11:49 +0000

> extensions-not-supported case).
I'd argue that it's already present, by inheritance from §3.6 of RFC  
4422:

[...]
   The outcome message provided by the server can provide a way for  
the
   client to distinguish between errors that are best dealt with by  
re-
   prompting the user for her credentials, errors that are best dealt
   with by telling the user to try again later, and errors where the
   user must contact a system administrator for resolution (see the  
SYS
   and AUTH POP Response Codes [RFC3206] specification for an  
example).
   This distinction is particularly useful during scheduled server
   maintenance periods as it reduces support costs.  It is also
   important that the server can be configured such that the outcome

Melnikov & Zeilenga         Standards Track                    [Page  
11]

RFC 4422                          SASL                         June  
2006

I'd say that was enough, but if a specific reference back to that is  
wanted, I won't stand against that either.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Sam Hartman <[email-masked]>
Date: Tue, 29 Mar 2011 15:53:44 -0400

I've been thinking a lot about error handling lately.
I don't think I've chimed into this thread.
My position with my security geek hat firmly placed on is:

There is significant value to reporting detailed error in the security
mechanism not in the application protocol.  You need the detailed errors
to deal with a number of user interface issues, and in most deployments
it has been my experience that the information an attacker could gain
from detailed errors is already present elsewhere in the environment.
You need the errors in the security mechanism not in the application
protocol when your mechanisms are part of a platform, because a number
of user experience items, such as the appropriate credentials to use for
a given service, may be influenced at a platform level. So, the platform
needs to be able to interpret the error reporting state. It's relatively
easy to pass the error up to the application.  It tends not to be the
case that the error gets passed down effectively from the application to
the platform.  So, better behavior is possible for platforms to
implement when errors are reported at the mechanism level.

I agree there are environments where general error reporting is
desirable.

I suspect that if I reviewed the 4422 guidance I'd think it was too
strong.

I am not an implementor or user of scram: my comments are to the general
issue.