Re: [secdir] SECDIR review of draft-ietf-httpbis-p7-auth-24

[Stephen Kent <[e-mail]>]

On 10/30/13 9:40 AM, Julian Reschke wrote:
> Stephen,
>
> On 2013-10-29 20:35, Stephen Kent wrote:
>> ...
>> The Security Considerations section (6) is about one page in length. It
>> references the SC sections in two in I-Ds:
>> draft-ietf-httpbis-p1-messaging-24 and
>> draft-ietf-httpbis-p2-semantics-24. Both of these I-Ds have non-trivial
>> SC sections, but one cannot say that this document has an acceptable SC
>> section until those documents are finalized. They are both normative
>> references, so this doc will nor progress independently, but there will
>> still be a need to revisit this SC when those SCs are finalized.
>
> These two other documents are in IETF LC as well.
OK. Then I suggest that whoever reviews them (hopefully not me) do so with
the SC section for this I-D in mind.
>
>> The SC section here addresses only two issues: purging credentials in
>> clients and user agents, and protection spaces. The discussion of the
>> former topic does not discuss how credential purging applies to proxies.
>
> As per httpbis-p1, a proxy is a client as well ('An HTTP "client" is a 
> program that establishes a connection to a server for the purpose of 
> sending one or more HTTP requests.' -- 
> <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-24.html#rfc.section.2.1>). 
> Does this address your comment?
yes, but it might be clearer to note this, parenthetically, in this doc.
For example, page 5 includes the following text:

    The 407 (Proxy Authentication Required) response message is used by a

proxy to challenge the authorization of a client and MUST include a

Proxy-Authenticate header field containing at least one challenge

applicable to the proxy for the requested resource.


The use of the terms "proxy" and "client" here suggest that they are 
distinct notions,
not that a proxy is also considered a client.
>
>> Also, it is not clear that a user control for credential purging will
>> have the desired effect given a potentially complex GUI environment. The
>
> Any proposal for enhancing the text?

User agents that cache credentials are encouraged to provide a

readily accessible mechanism for discarding cached credentials under

user control. *We recognize that this may not be a trivial task.**
**   Designing a UI that will encourage users to purge credentials when**
**   appropriate, but not cause them to prematurely do so may be difficult.*

>
>> discussion of protection spaces provides useful suggestions on how to
>> minimize credential exposure.
>>
>> I was a bit surprised that there was no advice deprecating the use of
>> passwords as credentials, if only to make a statement on this topic.
>
> This document just defines the HTTP authentication framework. It's not 
> intended to give general guidelines about the security of new 
> authentication schemes. But then, if you have some concrete proposal 
> for additional text, we're all ears.

This doc does provide guidance for new auth schemes, in 5.1.2. However, 
I agree that the guidance
there focuses on syntactic issues and compatibility, rather than 
security. So, if you don't want
to address this issue, OK.

Steve