Re: #320: add advice on defining auth scheme parameters

On 2011-11-04 00:23, Yutaka OIWA wrote:
> Dear Julian,
>
> I think you're asserting that
>> Undefined means undefined, so recipients essentially can do whatever
>> they want.
> and that recipients are NOT REQUIRED to reject such undefined inputs.
> I am right on that, but is it really true as blessed by the specification?

Until recently, the spec didn't say anything about it at all. Fact is 
that existing implementations treat invalid header fields in an ad-hoc 
fashion, and there's no interop here, nor is the majority "draconian".

With -17, the spec says:

"Unless noted otherwise, Recipients MAY take steps to recover a usable 
protocol element from an invalid construct. However, HTTP does not 
define specific error handling mechanisms, except in cases where it has 
direct impact on security. This is because different uses of the 
protocol require different error handling strategies; for example, a Web 
browser may wish to transparently recover from a response where the 
Location header field doesn't parse according to the ABNF, whereby in a 
systems control protocol using HTTP, this type of error recovery could 
lead to dangerous consequences."

(as per <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/186>).

> Assuming that, I generally agreeing with the general direction that
> new schemes should not break existing generic parsers (but not only the one
> you're mentioning).  Especially, it is really bad that<<someparam="1">>  and
> <<someparam=1>>  have different meanings.

+1. It would be a terrible idea.

> The summary of my points are:
>
> 1) Allowing, not mandating receivers to accept tokens as
>     strings is enough for "generic parsers" you have mentioned.
>     The original claim "This is necessary so that
>        recipients can use a generic parser that applies to all
>        authentication schemes"
>     seems theoretically unsound (too strong) for me.
>     At least I want to replace this claim with more modest one.

What's the benefit of only allowing to do this?

> 2) It is really meaningful for ABNF to specify
>     what kinds of values are expected.
>     One example is the stale parameter definition in RFC2617, saying
>
>        stale  = "stale" "=" ( "true" | "false" )
>
>     It is clearly saying that either true or false are accepted,
>     and that they are case insensitive.

Yes, I'm not against using ABNF, but it should be restricted to 
constrain the parameter *value* (after potential q-s handling).

So you would just say:

stale-value = "true" / "false"

> # Don't take that I am specifically saying about the stale parameter.
> # It is just a example of the set-limited-tokens parameters.
>
> 3) Then, the rule<<  realm = quoted-string>>  makes sense
>     that it says that arbitrary list of ASCII characters are accepted.
>     At least it is not as "bad design choice" as you said,
>     as receivers are currently not required to reject any token realms.
>     I also want to remove this declaration or replace with more modest one.

All browsers except the token form. To me this indicates that making it 
invalid is pointless.

> I don't want the stale rule to be any of the below:
>
>     "stale" "=" word  # it should be either true or false, case insensitive
>
>     "stale" "=" ( "true" | "false"
>                 | DQUOTE "true" DQUOTE | DQUOTE "false" DQUOTE
>                 | ...<too much more rules for deprecated excess backslashes>  )
>
>     "stale" "=" (<either token or quoted-string representing
>                    case-insensitive name either true or false>  )

Yes, see above - just state the ABNF for the value after parameter parsing.

> The current definition is the most clear and informative for implementors,
> given that RFC2617 currently does not define generic framework for
> the way of parsing you have specified as "ought to be".
> What you are saying specifically for the realm parameter
> seems to be the same class to the above thing, lacking symmetricity.
>
> You're saying that<<"realm" "=" quoted-string>>  is really bad and
> should have been defined as<<"realm" "=" (quoted-string | token)>>  in the past,
> but it also means the stale should have been define as above.
> Is it really a choice?
>
>
> Also, is it too hard "for senders" to require realms to be quoted?

No, it's not. The problem here is that not all programmers read specs, 
and thus do what "works". If it works "everywhere", and it's *harmless*, 
then maybe it should have been valid in the first place.

> Do we really need senders to be allowed for randomly quoting any parameters?
> You really want my parsers (generic in another way) to be rewritten for just
> allowing senders for this capability?

I would want to recommend that for all *new* header fields that take 
param syntax, and for all *new* authentication schemes.

> # Alternatively, I would be happy if we really define the new generic semantics
> # framework for parsing and interpreting the auth-param syntax at this moment, #
> and define the realm parameter *using that* (with a caution that senders
> # SHOULD send realm in quoted-string for backward compatibility, other Digest
> # params SHOULD be cared too), without just saying the previous designers were
> # bad.  This is really consistent, and give a clear straight-forward way for
> # future designers (including me and OAuth-MAC people) that "syntactical
> # constraints ought to be defined on the field value after parsing".

That's my goal :-)

Best regards, Julian

Received on Friday, 4 November 2011 08:44:35 UTC