Re: Working Group Last Call: draft-ietf-httpbis-auth-info

[Julian Reschke <[e-mail]>]

On 2015-02-11 02:37, Amos Jeffries wrote:
> On 11/02/2015 11:59 a.m., Mark Nottingham wrote:
>> Everyone,
>>
>> Julian believes (with his editor hat on) that this is ready. As discussed, this is a simple document to pull the Authentication-Info and Proxy-Authentication-Info header fields out of 2617, so that they’re not associated with a particular authentication scheme (thereby avoiding lots of scheme-specific headers).
>>
>> Therefore, this is the announcement of WGLC for:
>>   https://tools.ietf.org/html/draft-ietf-httpbis-auth-info-02
>>
>> Please review the document carefully, and comment on this list.
>>
>
>
> Section 3 paragraph 3 says "
>   Intermediaries are not allowed to modify the field value in any way.
> "
>
> RFC 7235 uses wording in the form:
>    A proxy forwarding ... MUST NOT modify ...
>
> I believe the Authentication-Info should share both normative MUST NOT,
> and term "proxy" instead of intermediary. Since there are legitimate

Right now the spec doesn't use any RFC 2119 terms, so if we do this, 
we'd need to apply it in more places.

> cases where gateways and/or other intermediaries may need to change it
> per the relevant auth scheme.

Can you give an example?

In any case, I agree that this ought to be consistent with RFC7235.


> Section 4 uses the term "proxy authentication" referencing RFC 7235.
>
> In RFC 7235 there is no definition, and only a vague implied explanation
> of that term via explaining what the 407 status means.

That's a problem of RFC 7235. This spec would be the wrong place to 
address this.

I think proposed text for rfc7235bis would be great.

> I believe the text in section 4 should be re-written to match the
> per-header descriptions found in RFC 7235 sectio 4.3/4.3 paragraph 2.

Not sure how that would improve things.

> With mention specifically about how it differs from Authentication-Info
> by being hop-by-hop.

Hmm, why is it hop-by-hop?

> Under security considerations I believe it would be good to mention that
> recipients of the Authentication-Info header in any response should
> (ought to or SHOULD?) treat the transaction as if it were authenticated
> even if the RFC7235 headers are not present.

Why?

(Remember that the intent of the spec was simply to extract the 
definition from RFC 2617; so if we make additional changes they need to 
be, well, understood)

>   Some of the use-cases I see for this header include out-of-band
> authentication. If the server is treating the reply as authenticated it
> may inadvertently include private information in the payload or other
> headers.
>
>
>
> Also, Yutaka brought up the issue of association between selected scheme
> and Authentication-Info contents. I believe this document is the right
> place to reserve a parameter scheme= which takes the auth-scheme as its
> value for the purpose in the same way RFC 7235 reserves the realm=
> parameter for use across schemes.

That was already answered. There can only be one authentication 
happening at a single time (plus one proxy authentication).

Best regards, Julian