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

[Amos Jeffries <[e-mail]>]

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
cases where gateways and/or other intermediaries may need to change it
per the relevant auth scheme.



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.

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.
With mention specifically about how it differs from Authentication-Info
by being 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.
 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.


Amos