Subject: Re: [http-auth] HTTP Digest - RFC2069 Backward Compatibility?

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Tue, 7 Jan 2014 19:44:21 -0500

I have changed the Subject to reflect this discussion. See my reply below.

On Tue, Jan 7, 2014 at 10:35 AM, Michael Sweet <[email-masked]> wrote:

> Rifaat,
>
> My responses are inline...
>
> On Jan 7, 2014, at 8:31 AM, Rifaat Shekh-Yusef <[email-masked]>
> wrote:
>
> ...
>
>> Also, qop-options still has the RFC 2617 mix of optional and SHOULD.
>>  Since RFC 2069 is long dead, it is probably better to simply say it is now
>> RECOMMENDED and that the absence of values is for backwards compatibility
>> with RFC 2069, e.g.:
>>
>
> I meant to send a separate email to discuss the issue of RFC2069, but
> since you raised it, I will discuss it here.
> Should we just not worry about RFC2069 and remove any consideration for
> backward compatibility with it?
>
>
> RFC 2069 was/is standards-track, obsoleted by 2617. I'm not sure what the
> IETF rules are for deprecation/breaking backwards compatibility with prior
> standards track work.
>
> The "safe" path is to REQUIRE qop-options on the server and make qop
> conditionally required based on the presence of the qop-options parameter
> in WWW-Authenticate.  That preserves backwards compatibility with RFC
> 2069-based servers while requiring the new form in current servers.
>
>
The problem with this approach is that it would allow any MITM to downgrade
the quality of the security to the RFC2069 level. If we want o prevent this
from happening, we need to stop that backward compatibility with this old
and obsolete RFC.

Regards,
 Rifaat

---

From: Michael Sweet <[email-masked]>
Date: Tue, 07 Jan 2014 20:12:09 -0500

Just to be clear, I am OK with getting rid of backwards compatibility with RFC 2069, but I just don't know what the IETF policy for such things is.  There is clearly an incentive to do so...

On Jan 7, 2014, at 7:44 PM, Rifaat Shekh-Yusef <[email-masked]> wrote:

> On Jan 7, 2014, at 8:31 AM, Rifaat Shekh-Yusef <[email-masked]> wrote:
>> ... 
>> Also, qop-options still has the RFC 2617 mix of optional and SHOULD.  Since RFC 2069 is long dead, it is probably better to simply say it is now RECOMMENDED and that the absence of values is for backwards compatibility with RFC 2069, e.g.:
>> 
>> I meant to send a separate email to discuss the issue of RFC2069, but since you raised it, I will discuss it here.
>> Should we just not worry about RFC2069 and remove any consideration for backward compatibility with it?
> 
> RFC 2069 was/is standards-track, obsoleted by 2617. I'm not sure what the IETF rules are for deprecation/breaking backwards compatibility with prior standards track work.
> 
> The "safe" path is to REQUIRE qop-options on the server and make qop conditionally required based on the presence of the qop-options parameter in WWW-Authenticate.  That preserves backwards compatibility with RFC 2069-based servers while requiring the new form in current servers.
> 
>  
> The problem with this approach is that it would allow any MITM to downgrade the quality of the security to the RFC2069 level. If we want o prevent this from happening, we need to stop that backward compatibility with this old and obsolete RFC.
> 
> Regards,
>  Rifaat
> 

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Yoav Nir <[email-masked]>
Date: Wed, 8 Jan 2014 08:15:28 +0000

Hi

There are no hard and fast rules for compatibility with obsoleted RFCs, and we should make our decisions based on "what's out there".

If I understand correctly, the qop-options directive is supported by implementations of RFC 2617 but not RFC 2069. So if the server sends it and the client does not, it means that the client is old and supports only 2069. OTOH if the server does not send it, it means that *it* is old.

Michael's suggestion is to require the server to send qop-options, and then the client treats the server as either conforming to 2069 of xxxx (this document) based on the presence or absence of qop-options. The alternative is to require qop-options and for the client to refuse authentication if they're missing.

I would be all for the alternative, but RFC 2617 says this: "This directive is optional, but is made so only for backward compatibility with RFC 2069<http://tools.ietf.org/html/rfc2069> [6<http://tools.ietf.org/html/rfc2617#ref-6>]; it SHOULD be used by all implementations compliant with this version of the Digest scheme.". I don't like the lower-case "optional" either, but the thing is, it's only a SHOULD. So upgrading this to a MUST is probably fine. But in order to require the client to enforce that MUST, we need to make sure of a few things:

*         That RFC 2069 servers that are not compliant with RFC 2617 are very very rare.

*         That RFC 2617 that don't send qop-options (because it's "just" a SHOULD) are also very rare.

IOW we have to first make sure that all (or nearly all) servers send qop-options.

Question is, does anyone on this list have the data to tell us this?

Yoav

From: http-auth [mailto:[email-masked]] On Behalf Of Michael Sweet
Sent: Wednesday, January 08, 2014 3:12 AM
To: Rifaat Shekh-Yusef
Cc: [email-masked]
Subject: Re: [http-auth] HTTP Digest - RFC2069 Backward Compatibility?

On Jan 7, 2014, at 7:44 PM, Rifaat Shekh-Yusef <[email-masked]<mailto:[email-masked]>> wrote:

On Tue, Jan 7, 2014 at 10:35 AM, Michael Sweet <[email-masked]<mailto:[email-masked]>> wrote:
Rifaat,

On Jan 7, 2014, at 8:31 AM, Rifaat Shekh-Yusef <[email-masked]<mailto:[email-masked]>> wrote:
...
Also, qop-options still has the RFC 2617 mix of optional and SHOULD.  Since RFC 2069 is long dead, it is probably better to simply say it is now RECOMMENDED and that the absence of values is for backwards compatibility with RFC 2069, e.g.:

Regards,
 Rifaat

---

From: Michael Sweet <[email-masked]>
Date: Wed, 08 Jan 2014 08:57:14 -0500

My (admittedly) small sample:

- CUPS: RFC 2069 only (and we are planning on dropping server-side Digest support in 2.0)
- Apache httpd: RFC 2069 and 2617 (qop auth only)
- Safari: RFC 2069 and 2617 (qop auth only)

(as to why I didn't add RFC 2617 support to CUPS yet, all I can say is that it was an oversight since Digest isn't used much with CUPS anymore - far more flexible to use Basic + TLS and a PAM module...  I will likely update the client-side code to support 2617-style authentication for completeness, but the server code is getting ripped out...)

On Jan 8, 2014, at 3:15 AM, Yoav Nir <[email-masked]> wrote:

> Hi
>  
> There are no hard and fast rules for compatibility with obsoleted RFCs, and we should make our decisions based on “what’s out there”.
>  
> Michael’s suggestion is to require the server to send qop-options, and then the client treats the server as either conforming to 2069 of xxxx (this document) based on the presence or absence of qop-options. The alternative is to require qop-options and for the client to refuse authentication if they’re missing.
>  
> I would be all for the alternative, but RFC 2617 says this: “This directive is optional, but is made so only for backward compatibility with RFC 2069 [6]; it SHOULD be used by all implementations compliant with this version of the Digest scheme.”. I don’t like the lower-case “optional” either, but the thing is, it’s only a SHOULD. So upgrading this to a MUST is probably fine. But in order to require the client to enforce that MUST, we need to make sure of a few things:
> ·         That RFC 2069 servers that are not compliant with RFC 2617 are very very rare.
> ·         That RFC 2617 that don’t send qop-options (because it’s “just” a SHOULD) are also very rare.

---

From: Sophie Bremer <[email-masked]>
Date: Wed, 8 Jan 2014 21:29:16 +0100

Hello,

the new digest scheme describes multiple authentication properties for new and old clients (Page 19, 3.9 Example).
Maybe it is possible to say, that the server may add an authentication property that is in line with RFC 2617 for backward compatibility.
In my opinion qop-options must be a requirement for the new digest scheme.

Best regards,
Sophie