From internet-drafts@ietf.org Wed Jan 1 09:40:58 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3E931AE563; Wed, 1 Jan 2014 09:40:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jszM3uuPqmmp; Wed, 1 Jan 2014 09:40:57 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4CB1AE1DA; Wed, 1 Jan 2014 09:40:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140101174057.13310.83765.idtracker@ietfa.amsl.com> Date: Wed, 01 Jan 2014 09:40:57 -0800 Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-digest-01.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jan 2014 17:40:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Hypertext Transfer Protocol Authenticatio= n Working Group of the IETF. Title : HTTP Digest Access Authentication Authors : Rifaat Shekh-Yusef David Ahrens Sophie Bremer Filename : draft-ietf-httpauth-digest-01.txt Pages : 30 Date : 2014-01-01 Abstract: HTTP provides a simple challenge-response authentication mechanism that may be used by a server to challenge a client request and by a client to provide authentication information. This document defines the HTTP Digest Authentication scheme that may be used with the authentication mechanism. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-httpauth-digest-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-httpauth-digest-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rifaat.ietf@gmail.com Wed Jan 1 09:45:46 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45C001AE364 for ; Wed, 1 Jan 2014 09:45:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5grp91yVFIe for ; Wed, 1 Jan 2014 09:45:44 -0800 (PST) Received: from mail-ee0-x22d.google.com (mail-ee0-x22d.google.com [IPv6:2a00:1450:4013:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id E2EEC1AE30D for ; Wed, 1 Jan 2014 09:45:43 -0800 (PST) Received: by mail-ee0-f45.google.com with SMTP id d49so5925070eek.32 for ; Wed, 01 Jan 2014 09:45:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=ZMSO1zPy4sJ9R/IKdbgLMmhoVqip/HYYXbyS4DdxnB8=; b=hlMC+0ziPvZfM6IxTuudPWK+dewKl8VX7rmOR3FnArVoRrO3hFfmlW9gZ6Rj9qsNRx k0GVX0/CaOZZ+I2n5yRFDTTsFhw6t2gQtEqF8/S6Xj/QzDKi7UL8q+bQQ3QGCoSGx1PX vJ02ukbNBPQ+mRDnX24orFIWSm9++y7z9Fl0v4Td3x2Y0Ya8Tomu/Kivptcxvt3UA5r0 QEiYdrB4Zzfa4HWIQNxNTAlTP6+Jr86jvBS6wf0PEYdn8Ryk5z1sS4zfsbJDnlB2hlfn ASv7Vn2Unw4UpOfmUqrV+wrSCaLunD6dpUl9uVCUXCRh2GWJX0rsPZxhtfUAeO0lMycY v4/Q== MIME-Version: 1.0 X-Received: by 10.14.246.202 with SMTP id q50mr11980275eer.58.1388598336639; Wed, 01 Jan 2014 09:45:36 -0800 (PST) Received: by 10.14.53.78 with HTTP; Wed, 1 Jan 2014 09:45:36 -0800 (PST) In-Reply-To: <20140101174057.13310.83765.idtracker@ietfa.amsl.com> References: <20140101174057.13310.83765.idtracker@ietfa.amsl.com> Date: Wed, 1 Jan 2014 12:45:36 -0500 Message-ID: From: Rifaat Shekh-Yusef To: "http-auth@ietf.org" Content-Type: multipart/alternative; boundary=001a1132ebd69754c604eeec3ed6 Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-01.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jan 2014 17:45:46 -0000 --001a1132ebd69754c604eeec3ed6 Content-Type: text/plain; charset=ISO-8859-1 This new version includes two changes: 1. Incorporates the Hashed Username proposal. 2. Adds a new registry in the IANA section to register the hash algorithms. Please, take a look and let us know if you have any comments. Regards, Rifaat On Wed, Jan 1, 2014 at 12:40 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Hypertext Transfer Protocol > Authentication Working Group of the IETF. > > Title : HTTP Digest Access Authentication > Authors : Rifaat Shekh-Yusef > David Ahrens > Sophie Bremer > Filename : draft-ietf-httpauth-digest-01.txt > Pages : 30 > Date : 2014-01-01 > > Abstract: > HTTP provides a simple challenge-response authentication mechanism > that may be used by a server to challenge a client request and by a > client to provide authentication information. This document defines > the HTTP Digest Authentication scheme that may be used with the > authentication mechanism. > > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-httpauth-digest-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-digest-01 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > --001a1132ebd69754c604eeec3ed6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This new version includes two changes:
1. I= ncorporates the Hashed Username proposal.
2. Adds a new registry = in the IANA section to register the hash algorithms.

Please, take a look and let us know if you have any comments.
Regards,
=A0Rifaat



On Wed, Jan 1, 2014 at 12:4= 0 PM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0This draft is a work item of the Hypertext Transfer Protocol Authenticat= ion Working Group of the IETF.

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : HTTP Digest Access Authenticati= on
=A0 =A0 =A0 =A0 Authors =A0 =A0 =A0 =A0 : Rifaat Shekh-Yusef
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 David Ahrens
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Sophie Bremer
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-httpauth-digest-01.txt=
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 30
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2014-01-01

Abstract:
=A0 =A0HTTP provides a simple challenge-response authentication mechanism =A0 =A0that may be used by a server to challenge a client request and by a<= br> =A0 =A0client to provide authentication information. This document defines<= br> =A0 =A0the HTTP Digest Authentication scheme that may be used with the
=A0 =A0authentication mechanism.




The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest= /

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-httpauth-digest-01
A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-httpauth-= digest-01


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
http-auth mailing list
http-auth@ietf.org
https://www.ietf.org/mailman/listinfo/http-auth

--001a1132ebd69754c604eeec3ed6-- From msweet@apple.com Mon Jan 6 07:28:20 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11BAB1AE042 for ; Mon, 6 Jan 2014 07:28:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.439 X-Spam-Level: X-Spam-Status: No, score=-7.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tM081lJTupL9 for ; Mon, 6 Jan 2014 07:28:17 -0800 (PST) Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 1B51E1AE043 for ; Mon, 6 Jan 2014 07:28:17 -0800 (PST) MIME-version: 1.0 Received: from relay6.apple.com ([17.128.113.90]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MYZ00DF3K91HJI1@mail-out.apple.com> for http-auth@ietf.org; Mon, 06 Jan 2014 07:27:05 -0800 (PST) X-AuditID: 1180715a-b7f3c6d00000020e-f3-52cacb4859be Received: from chive.apple.com (chive.apple.com [17.128.115.15]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id 33.C1.00526.84BCAC25; Mon, 06 Jan 2014 07:27:04 -0800 (PST) Received: from [17.153.59.72] by chive.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MYZ00KZYK92TS10@chive.apple.com> for http-auth@ietf.org; Mon, 06 Jan 2014 07:27:04 -0800 (PST) Content-type: multipart/signed; boundary="Apple-Mail=_22CF0AF8-9ECF-45C3-BD10-02A37E413DE6"; protocol="application/pkcs7-signature"; micalg=sha1 From: Michael Sweet In-reply-to: Date: Mon, 06 Jan 2014 10:27:06 -0500 Message-id: <6A343EB6-C228-47E0-8757-259C3B487736@apple.com> References: <20140101174057.13310.83765.idtracker@ietfa.amsl.com> To: Rifaat Shekh-Yusef X-Mailer: Apple Mail (2.1859) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUi2FDMr+tx+lSQwYdfihYf9s9hcmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtQbrgUfTzNW3H5v0sD4aSNjFyMHh4SAicTyv+FdjJxAppjE hXvr2boYuTiEBLqZJF7tOsUIkhASaGCSOPZTFcQWFnCTaGi+wgZi8wroSaw7voQdxGYWmMIo cWtaEYjNJqAm8XtSHyvIfE6BYImJ8/hAwiwCqhL/2peyQJTrSiw92c0IMcZG4saLk1B7Oxgl lv2ZDDZfBGh++9+FTBDHyUr8uLSAcQIj/ywkq2chWQ1hJ0kc/P4bKq4tsWzha2YIW0/iZdM7 LOK6EhfXTWKEsE0lnrzdzgZhW0v8nPMIKq4oMaX7IfsCRq5VjAJFqTmJlWZ6iQUFOal6yfm5 mxjBcVAYtYOxYbnVIUYBDkYlHt4Ju08FCbEmlhVX5h5iVAEa8WjD6guMUix5+XmpSiK8LvuB 0rwpiZVVqUX58UWlOanFhxilOViUxHkbD20JEhJITyxJzU5NLUgtgskycXBKNTAmxm942Wnp LC074c6qUzZlAtOe7L6wXKowQ+El19NFsZIP5/39uWn9/Mmvvx76uIHp9AYn68Vv1icki/Zs WXVqG4/qQeFVdVHL+Q3K+ZK+6PqXn3n4X6/xyYlfUjs9NLhyT0n+Fv0cbOVZz8cudiTKaI3Q U/k/rptXaRyziJRSyl06a8+tHxL9SizFGYmGWsxFxYkAytSbe4sCAAA= Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-01.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 15:28:20 -0000 --Apple-Mail=_22CF0AF8-9ECF-45C3-BD10-02A37E413DE6 Content-Type: multipart/alternative; boundary="Apple-Mail=_ADEED2BD-6F47-4D03-A171-4D2DB2BEDAC8" --Apple-Mail=_ADEED2BD-6F47-4D03-A171-4D2DB2BEDAC8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Some quick comments... In section 3.3 you use "that could be used by the server..." for the = definitions of charset and userhash - that seems a bit too wishy-washy = for a standards-track RFC. Instead I would use "that is used by the = server ...", along with making OPTIONAL all-caps, per RFC 2119: charset This is an OPTIONAL parameter that is used by the server to indicate the character encoding it supports for the username and password. userhash This is an OPTIONAL parameter that is used by the server to indicate that it supports username hashing. 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.: qop-options This RECOMMENDED directive is a quoted string of one or more tokens indicating the "quality of protection" values supported by the server. The value "auth" indicates authentication; the value "auth-int" indicates authentication with integrity protection; see the descriptions below for calculating the response directive value for the application of this choice. If not present, the client MUST assume the server only supports the obsolete form of Digest authentication [RFC2069]. Unrecognized options MUST be ignored. In section 3.4, there is still the same legacy wording for qop, and = there is an extra space between "WWW-" and "Authenticate"; how about: qop Indicates what "quality of protection" the client has applied to the message. If present, its value MUST be one of the alternatives the server indicated it supports in the WWW-Authenticate header. These values affect the computation of the request-digest. Note that this is a single token, not a quoted list of alternatives as in WWW-Authenticate. This directive SHOULD be used if the server provided a qop directive in the WWW-Authenticate header field. If = not present, the server MUST assume that the client only supports the obsolete form of Digest authentication [RFC2069]. Also, charset and userhash use "optional" and "that could be used by ... = that it supports". Since the client and server are not negotiating these = things and the client is telling the server what it used, I would change = them to: charset This OPTIONAL parameter is used by the client to indicate the character encoding used for the username and password. userhash This OPTIONAL parameter is used by the client to indicate that the username has been hashed. In section 3.4.4, I'd prefer to make this conditionally required for the = client (if it supports username hashing) rather than leaving it a = recommendation - after all, if you actually go to the trouble of = implementing userhash support, why wouldn't you use it? In section 4, did we ever decide what to say about the Unicode = normalization form? RFC 5198 (network unicode) is often referenced and = uses NFC. In section 5.1, the word "recommended" is used when talking about HTTPS, = but there is no reference. How about: Digest authentication SHOULD be used over a secure channel like = HTTPS [RFC2818]. (the reference will need to be updated soon, see my comment about = HTTP/1.1 references) In section 5.2, you don't mention username protection. Simple change: Digest Authentication offers no confidentiality protection beyond protecting the actual username and password. All of the rest of the request and response are available to an eavesdropper. Also, there is a "should" in the last sentence that either needs = capitalization, rewording, or removal: Any service in present use that uses Basic SHOULD be switched to Digest as soon as practical. or: Digest can be used as a more secure alternative to Basic = in existing services. General: there are a bunch of RFC 2616 references that will need to be = updated for the soon-to-be-published HTTP/1.1 RFCs. On Jan 1, 2014, at 12:45 PM, Rifaat Shekh-Yusef = wrote: > This new version includes two changes: > 1. Incorporates the Hashed Username proposal. > 2. Adds a new registry in the IANA section to register the hash = algorithms. >=20 > Please, take a look and let us know if you have any comments. >=20 > Regards, > Rifaat >=20 >=20 >=20 > On Wed, Jan 1, 2014 at 12:40 PM, wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Hypertext Transfer Protocol = Authentication Working Group of the IETF. >=20 > Title : HTTP Digest Access Authentication > Authors : Rifaat Shekh-Yusef > David Ahrens > Sophie Bremer > Filename : draft-ietf-httpauth-digest-01.txt > Pages : 30 > Date : 2014-01-01 >=20 > Abstract: > HTTP provides a simple challenge-response authentication mechanism > that may be used by a server to challenge a client request and by a > client to provide authentication information. This document defines > the HTTP Digest Authentication scheme that may be used with the > authentication mechanism. >=20 >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-httpauth-digest-01 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-httpauth-digest-01 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth >=20 > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Apple-Mail=_ADEED2BD-6F47-4D03-A171-4D2DB2BEDAC8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Some = quick comments...

In section 3.3 you use "that could = be used by the server..." for the definitions of charset and userhash - = that seems a bit too wishy-washy for a standards-track RFC. =  Instead I would use "that is used by the server ...", along with = making OPTIONAL all-caps, per RFC = 2119:

  =  charset
      This is an OPTIONAL = parameter that is used by the server to
      = indicate the character encoding it supports for the username = and
      = password.

  =  userhash
      This is an OPTIONAL = parameter that is used by the server to
      = indicate that it supports username hashing.

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.:

   =
qop-options
     This RECOMMENDED directive is a quoted string of one or =
more
     tokens indicating =
the "quality of protection" values supported
     by the server.  The value "auth" indicates =
authentication; the
     value =
"auth-int" indicates authentication with integrity
     protection; see the descriptions =
below for calculating the
     response =
directive value for the application of this choice.
     If not present, the client MUST assume =
the server only supports
     the obsolete =
form of Digest authentication [RFC2069]. Unrecognized
     options MUST be =
ignored.

In section 3.4, there is still the = same legacy wording for qop, and there is an extra space between "WWW-" = and "Authenticate"; how = about:

 qop
    =   Indicates what "quality of protection" the client has applied = to
      the message. If present, its value = MUST be one of the alternatives
      the = server indicated it supports in the WWW-Authenticate = header.
      These values affect the = computation of the request-digest. Note
      = that this is a single token, not a quoted list of alternatives = as
      in WWW-Authenticate.  This = directive SHOULD be used if the server
      = provided a qop directive in the WWW-Authenticate header field. If = not
      present, the server MUST assume that = the client only supports the
      obsolete = form of Digest authentication [RFC2069].

Also, charset and userhash use = "optional" and "that could be used by ... that it supports". Since the = client and server are not negotiating these things and the client is = telling the server what it used, I would change them = to:

   charset
  =     This OPTIONAL parameter is used by the client to indicate = the
      character encoding used for the = username and password.

  =  userhash
      This OPTIONAL parameter is = used by the client to indicate that
      the = username has been hashed.


In section = 3.4.4, I'd prefer to make this conditionally required for the client (if = it supports username hashing) rather than leaving it a recommendation - = after all, if you actually go to the trouble of implementing userhash = support, why wouldn't you use = it?


In section 4, did we ever = decide what to say about the Unicode normalization form? RFC 5198 = (network unicode) is often referenced and uses = NFC.


In section 5.1, the word = "recommended" is used when talking about HTTPS, but there is no = reference. How about:

    Digest = authentication SHOULD be used over a secure channel like HTTPS = [RFC2818].

(the reference will need to be = updated soon, see my comment about HTTP/1.1 = references)


In section 5.2, you = don't mention username protection. Simple = change:

   Digest Authentication = offers no confidentiality protection beyond
  =  protecting the actual username and password. All of the rest of = the
   request and response are available to an = eavesdropper.

Also, there = is a "should" in the last sentence that either needs capitalization, = rewording, or removal:

    =            Any service in present use that = uses Basic SHOULD be
   switched to Digest as soon = as = practical.

or:

&nbs= p;              Digest can be used as = a more secure alternative to Basic in
   existing = services.


General: = there are a bunch of RFC 2616 references that will need to be updated = for the soon-to-be-published HTTP/1.1 = RFCs.



On Jan = 1, 2014, at 12:45 PM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> = wrote:

This new version includes two = changes:
1. Incorporates the Hashed Username = proposal.
2. Adds a new registry in the IANA section to = register the hash algorithms.

Please, take a look and let us know if you have any = comments.

Regards,
 Rifaat



On Wed, Jan 1, 2014 at 12:40 PM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts = directories.
 This draft is a work item of the Hypertext Transfer Protocol = Authentication Working Group of the IETF.

        Title           : = HTTP Digest Access Authentication
        Authors         : Rifaat = Shekh-Yusef
                    =       David Ahrens
                    =       Sophie Bremer
        Filename        : = draft-ietf-httpauth-digest-01.txt
        Pages           : = 30
        Date           =  : 2014-01-01

Abstract:
   HTTP provides a simple challenge-response authentication = mechanism
   that may be used by a server to challenge a client request = and by a
   client to provide authentication information. This document = defines
   the HTTP Digest Authentication scheme that may be used with = the
   authentication mechanism.




The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-httpauth-dig= est/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-httpauth-digest-01=

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-httpauth-d= igest-01


Please note that it may take a couple of minutes from the time of = submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
http-auth mailing list
http-auth@ietf.org
https://www.ietf.org/mailman/listinfo/http-auth

_______________________________________________
http-auth mailing = list
http-auth@ietf.org
https://www.i= etf.org/mailman/listinfo/http-auth

_________________________________________________________
Michael = Sweet, Senior Printing System Engineer, PWG = Chair

= --Apple-Mail=_ADEED2BD-6F47-4D03-A171-4D2DB2BEDAC8-- --Apple-Mail=_22CF0AF8-9ECF-45C3-BD10-02A37E413DE6 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPJTCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBSIwggQKoAMC AQICEQDlB7dXxclLEedquPvGX8CGMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBMB4XDTEzMTIxNzAwMDAwMFoXDTE0MTIxNzIzNTk1OVowITEfMB0GCSqG SIb3DQEJARYQbXN3ZWV0QGFwcGxlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ANdvQYZRCVzc0wIYvIOn/0Pv7zUwuIvbAfM/W3FyemqZx3fdKxX4WxN2x5NC3hhBHGrUWirJH7rl 6It12bGQ61uHAK5jsJikV5k+mOYjZaKNIKxj0uYIk3MKQmsmM8t3nddq5mp2mxwV/U7AFPTz1fgh dkqTb/NkHY5eA8KqksaeqwfMgoaiGVeCUhptWnXosca8PAkb+i9u5rEok5zgY+QP0IuWLJENfA4q dEMsH+OAwMGOv9fNCgcdapFnjeSYaj70m6qUiq446+8a2rhUsEUKQayOMgjnm2bgUuNx7pOvs/Jg zIlZoTz/llmE1HWREGzSjRnLWwQ98fspfeZWA+8CAwEAAaOCAeAwggHcMB8GA1UdIwQYMBaAFHoT TgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTtKBJoG9kxZisTqJg4+wr12l4stjAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIw EQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUH AgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6 Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1h aWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9j YS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggr BgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMBsGA1UdEQQUMBKBEG1zd2VldEBhcHBs ZS5jb20wDQYJKoZIhvcNAQEFBQADggEBABg5KLQK5u9gGI75u+vYH/i6uMDKlpTILO/r/FpN2ibq pwAB2ln9oKvPIA1/r3o+DBC87TqnlJAiPW4ADFHpRmqlprb0Tu9p98nP/wl5tBZjEP8dY4iH0TB3 B2r9JHwRwwJQ20CqJpuCn9dmvL215sZSqvJfluVlIcAQCLxp3ZKMIC2pNKitswdjjHduaKuj2TMe xrzMtrRGRtFF9pcMcnsqE2QtJUqXPV7/M4WT2yRUmI4ThPt9O9fmPH2ku52hdb6t4qXvwdQSkDHt xo3J/Vc/jDR2/feedDhQmG0V9j6tHsuG6bVVhcGiWnSmSoPfg13FlQwlxZTyFtiMZ2jILyoxggOu MIIDqgIBATCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAOUHt1fFyUsR 52q4+8ZfwIYwCQYFKw4DAhoFAKCCAdkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTQwMTA2MTUyNzA3WjAjBgkqhkiG9w0BCQQxFgQUv9PFsB/mdY4+zcYK6pvIDKfb QEMwgboGCSsGAQQBgjcQBDGBrDCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx OTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIRAOUHt1fFyUsR52q4+8ZfwIYwgbwGCyqGSIb3DQEJEAILMYGsoIGpMIGTMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgU2VjdXJlIEVtYWlsIENBAhEA5Qe3V8XJSxHnarj7xl/AhjANBgkqhkiG9w0BAQEFAASC AQBUyejmywXMj2Rm89c6O/f71cPy0iYl8/blGaepBCHj6qQdWPKcmeevW/XiJ8ThBXg88Eat9bQr L/oetYDXW45j38m9NfnaIcdH6aNcFGnFaOMGiey8fas82YRTZ690pMF8ldh07WjSILE2Qm4LeScG x6Hjg5TjdcHIH4Wgwh9/DXPz6cDRC2sp980egAzVrJJIPoME32eh0VeGHEvIEizcOjKW1Y9pXKHD 6Ut9J0ZKHRbnb3cos93kLrGmylvzqqtOjeUThsWTxnySJiB3hVyEoud4PobyJxSvoJ/9ipMTFY4I VhTKuJsen235+s0pnXUcAR68KJixQvf9RpKrWgIHAAAAAAAA --Apple-Mail=_22CF0AF8-9ECF-45C3-BD10-02A37E413DE6-- From rifaat.ietf@gmail.com Tue Jan 7 05:32:18 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC7281ADF67 for ; Tue, 7 Jan 2014 05:32:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNWFI93hVz5r for ; Tue, 7 Jan 2014 05:32:15 -0800 (PST) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by ietfa.amsl.com (Postfix) with ESMTP id 38F351ADF9A for ; Tue, 7 Jan 2014 05:32:15 -0800 (PST) Received: by mail-ee0-f54.google.com with SMTP id e51so62713eek.13 for ; Tue, 07 Jan 2014 05:31:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Wu/XPCY7RlT5It5sUluXBEzOjUthYEW+2b3sjrmdcnU=; b=kS9cePd57ABKAuF1F9Vn/rGcBg2soSbV/aOZbbYBdGT0Go+XDBLV9/+S+4QjSN7rZ7 rlaW4c46zJ189jDpD1QtKdJcVlLq08zmyZJOXvCbjbmZM3QgpsnjpHJin45rdx9YvIYD LrO67s/1hz704MqN6xbTPmAGotey64GP4WOedRLxTfNSa6zkJ+fou08ZamCYUpmCRrVV OiLE3vG6Gqd7FAATqRM4pV0S0rwAcwkBrtwc0JH19tuwxPirWTxm/pFBK4Kfxs74xStE 13zGy5eBU9by2b1u1U4C1ZH0nBoDjeaszwMP5Ks4vV7PRj8ycz9GmZ0Q4CF/OYGHRRV2 vl4g== MIME-Version: 1.0 X-Received: by 10.15.77.134 with SMTP id p6mr94407782eey.0.1389101490949; Tue, 07 Jan 2014 05:31:30 -0800 (PST) Received: by 10.14.53.78 with HTTP; Tue, 7 Jan 2014 05:31:30 -0800 (PST) In-Reply-To: <6A343EB6-C228-47E0-8757-259C3B487736@apple.com> References: <20140101174057.13310.83765.idtracker@ietfa.amsl.com> <6A343EB6-C228-47E0-8757-259C3B487736@apple.com> Date: Tue, 7 Jan 2014 08:31:30 -0500 Message-ID: From: Rifaat Shekh-Yusef To: Michael Sweet Content-Type: multipart/alternative; boundary=001a11c34386ecd5cb04ef6164a1 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-01.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 13:32:18 -0000 --001a11c34386ecd5cb04ef6164a1 Content-Type: text/plain; charset=ISO-8859-1 Hi Michael, Thanks for your thorough review and for these useful comments. Please, take a look at my responses inline... Regards, Rifaat On Mon, Jan 6, 2014 at 10:27 AM, Michael Sweet wrote: > Some quick comments... > > In section 3.3 you use "that could be used by the server..." for the > definitions of charset and userhash - that seems a bit too wishy-washy for > a standards-track RFC. Instead I would use "that is used by the server > ...", along with making OPTIONAL all-caps, per RFC 2119: > > charset > This is an OPTIONAL parameter that is used by the server to > indicate the character encoding it supports for the username and > password. > > userhash > This is an OPTIONAL parameter that is used by the server to > indicate that it supports username hashing. > > Ok. > 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? > > qop-options > This RECOMMENDED directive is a quoted string of one or more > > tokens indicating the "quality of protection" values supported > > by the server. The value "auth" indicates authentication; the > > value "auth-int" indicates authentication with integrity > > protection; see the descriptions below for calculating the > > response directive value for the application of this choice. > > If not present, the client MUST assume the server only supports > > the obsolete form of Digest authentication [RFC2069]. Unrecognized > > options MUST be ignored. > > > In section 3.4, there is still the same legacy wording for qop, and there > is an extra space between "WWW-" and "Authenticate"; how about: > > qop > Indicates what "quality of protection" the client has applied to > the message. If present, its value MUST be one of the alternatives > the server indicated it supports in the WWW-Authenticate header. > These values affect the computation of the request-digest. Note > that this is a single token, not a quoted list of alternatives as > in WWW-Authenticate. This directive SHOULD be used if the server > provided a qop directive in the WWW-Authenticate header field. If not > present, the server MUST assume that the client only supports the > obsolete form of Digest authentication [RFC2069]. > > Also, charset and userhash use "optional" and "that could be used by ... > that it supports". Since the client and server are not negotiating these > things and the client is telling the server what it used, I would change > them to: > > charset > This OPTIONAL parameter is used by the client to indicate the > character encoding used for the username and password. > > userhash > This OPTIONAL parameter is used by the client to indicate that > the username has been hashed. > > Ok > > In section 3.4.4, I'd prefer to make this conditionally required for the > client (if it supports username hashing) rather than leaving it a > recommendation - after all, if you actually go to the trouble of > implementing userhash support, why wouldn't you use it? > > Good point. I will change it to MUST. > > In section 4, did we ever decide what to say about the Unicode > normalization form? RFC 5198 (network unicode) is often referenced and uses > NFC. > > I remember some discussion on the mailing list, but if I remember correctly I do not think that there was any conclusion to that discussion. > > In section 5.1, the word "recommended" is used when talking about HTTPS, > but there is no reference. How about: > > Digest authentication SHOULD be used over a secure channel like HTTPS > [RFC2818]. > > (the reference will need to be updated soon, see my comment about HTTP/1.1 > references) > > Ok > > In section 5.2, you don't mention username protection. Simple change: > > Digest Authentication offers no confidentiality protection beyond > protecting the actual username and password. All of the rest of the > request and response are available to an eavesdropper. > > Good catch. > Also, there is a "should" in the last sentence that either needs > capitalization, rewording, or removal: > > Any service in present use that uses Basic SHOULD be > switched to Digest as soon as practical. > > or: > > Digest can be used as a more secure alternative to Basic in > existing services. > > > I would probably remove that sentence. > General: there are a bunch of RFC 2616 references that will need to be > updated for the soon-to-be-published HTTP/1.1 RFCs. > > Ok. > > > On Jan 1, 2014, at 12:45 PM, Rifaat Shekh-Yusef > wrote: > > This new version includes two changes: > 1. Incorporates the Hashed Username proposal. > 2. Adds a new registry in the IANA section to register the hash algorithms. > > Please, take a look and let us know if you have any comments. > > Regards, > Rifaat > > > > On Wed, Jan 1, 2014 at 12:40 PM, wrote: > >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Hypertext Transfer Protocol >> Authentication Working Group of the IETF. >> >> Title : HTTP Digest Access Authentication >> Authors : Rifaat Shekh-Yusef >> David Ahrens >> Sophie Bremer >> Filename : draft-ietf-httpauth-digest-01.txt >> Pages : 30 >> Date : 2014-01-01 >> >> Abstract: >> HTTP provides a simple challenge-response authentication mechanism >> that may be used by a server to challenge a client request and by a >> client to provide authentication information. This document defines >> the HTTP Digest Authentication scheme that may be used with the >> authentication mechanism. >> >> >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-httpauth-digest-01 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-digest-01 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> http-auth mailing list >> http-auth@ietf.org >> https://www.ietf.org/mailman/listinfo/http-auth >> > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > > > _________________________________________________________ > Michael Sweet, Senior Printing System Engineer, PWG Chair > > --001a11c34386ecd5cb04ef6164a1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Michael,

Thanks for your thorough re= view and for these useful comments.
Please, take a look at my res= ponses inline...

Regards,
=A0Rifaat



On Mon, Jan 6, 2014 at 10:27 AM, Michael Sweet <msweet@apple.com><= /span> wrote:
Some quick comments...=

In section 3.3 you use "that could be used by the serve= r..." for the definitions of charset and userhash - that seems a bit t= oo wishy-washy for a standards-track RFC. =A0Instead I would use "that= is used by the server ...", along with making OPTIONAL all-caps, per = RFC 2119:

=A0 =A0charset
=A0 =A0 =A0 This is an OP= TIONAL parameter that is used by the server to
=A0 =A0 =A0 indica= te the character encoding it supports for the username and
=A0 = =A0 =A0 password.

=A0 =A0userhash
=A0 =A0 =A0 This is an OPTION= AL parameter that is used by the server to
=A0 =A0 =A0 indicate t= hat it supports username hashing.

Ok.

=A0
Also, qop-options still has the RFC 2617 mix of optional an= d SHOULD. =A0Since RFC 2069 is long dead, it is probably better to simply s= ay it is now RECOMMENDED and that the absence of values is for backwards co= mpatibility with RFC 2069, e.g.:

I meant to send a separate emai= l 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 co= nsideration for backward compatibility with it?

=A0

   qop-options
     This RECOMMENDED directive is a quoted string of one or more
     tokens indicating t=
he "quality of protection" values supported
     by the server. =A0The=A0value "auth" indicates authenticatio=
n; the
     value &quo=
t;auth-int"=A0indicates authentication with integrity
     protection; see the=A0descriptions below for calculating the
     response directive value f=
or the application of this choice.
     If not present, the client MUST assume the server only supports
<= pre style=3D"margin-top:0px;margin-bottom:0px"> the obsolete form of Di= gest authentication [RFC2069]. Unrecognized
     options MUST be ignored.

In section 3.4, ther= e is still the same legacy wording for qop, and there is an extra space bet= ween "WWW-" and "Authenticate"; how about:

=A0qop
=A0 =A0 =A0 Indicates what "quality of= protection" the client has applied to
=A0 =A0 =A0 the message. If present, its value MUST be one of the alte= rnatives
=A0 =A0 =A0 the server indicated it supports in the WWW-= Authenticate header.
=A0 =A0 =A0 These values affect the computat= ion of the request-digest. Note
=A0 =A0 =A0 that this is a single token, not a quoted list of alternat= ives as
=A0 =A0 =A0 in WWW-Authenticate. =A0This directive SHOULD= be used if the server
=A0 =A0 =A0 provided a qop directive in th= e WWW-Authenticate header field. If not
=A0 =A0 =A0 present, the server MUST assume that the client only suppo= rts the
=A0 =A0 =A0 obsolete form of Digest authentication [RFC20= 69].

Also, charset and userhash use "optional" and "= ;that could be used by ... that it supports". Since the client and ser= ver are not negotiating these things and the client is telling the server w= hat it used, I would change them to:

=A0 =A0charset
=A0 =A0 =A0 This OPTIONAL= parameter is used by the client to indicate the
=A0 =A0 =A0 char= acter encoding used for the username and password.

=A0 =A0userhash
=A0 =A0 =A0 This OPTIONAL parameter is used by the client to indicate = that
=A0 =A0 =A0 the username has been hashed.

Ok

=A0

In = section 3.4.4, I'd prefer to make this conditionally required for the c= lient (if it supports username hashing) rather than leaving it a recommenda= tion - after all, if you actually go to the trouble of implementing userhas= h support, why wouldn't you use it?

Good point. I will change it t= o MUST.
=A0

In section 4, did we ever decide what t= o say about the Unicode normalization form? RFC 5198 (network unicode) is o= ften referenced and uses NFC.

I remember some discussion on the mailing list, but if I remember corr= ectly I do not think that there was any conclusion to that discussion.

=A0

In section 5.1, the word "recommended" is used when talking = about HTTPS, but there is no reference. How about:

=A0 =A0 Digest authentication SHOULD be used over a secure channel like HT= TPS [RFC2818].

(the reference will need to be updated soon, see my com= ment about HTTP/1.1 references)

Ok
=A0

In = section 5.2, you don't mention username protection. Simple change:

=A0 =A0Digest Authentication offers no confidenti= ality protection beyond
=A0 =A0protecting the actual username and password. All of the rest of= the
=A0 =A0request and response are available to an eavesdropper= .

Good catch.


=A0
Also, there is a "should" in the last sentence that eit= her needs capitalization, rewording, or removal:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Any service in pres= ent use that uses Basic SHOULD be
=A0 =A0switched to Digest as so= on as practical.

or:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Digest can be used as a more secure alterna= tive to Basic in
=A0 =A0existing services.


I would probably remove that sentence.

=A0
General: there are= a bunch of RFC 2616 references that will need to be updated for the soon-t= o-be-published HTTP/1.1 RFCs.

Ok.

=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex">


On Jan 1, 2014, at 12:45= PM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

This new version includes two changes:
1. I= ncorporates the Hashed Username proposal.
2. Adds a new registry = in the IANA section to register the hash algorithms.

Please, take a look and let us know if you have any comments.
Regards,
=A0Rifaat



On Wed, Jan 1, 2014 at 12:4= 0 PM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0This draft is a work item of the Hypertext Transfer Protocol Authenticat= ion Working Group of the IETF.

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : HTTP Digest Access Authenticati= on
=A0 =A0 =A0 =A0 Authors =A0 =A0 =A0 =A0 : Rifaat Shekh-Yusef
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 David Ahrens
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Sophie Bremer
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-httpauth-digest-01.txt=
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 30
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2014-01-01

Abstract:
=A0 =A0HTTP provides a simple challenge-response authentication mechanism =A0 =A0that may be used by a server to challenge a client request and by a<= br> =A0 =A0client to provide authentication information. This document defines<= br> =A0 =A0the HTTP Digest Authentication scheme that may be used with the
=A0 =A0authentication mechanism.




The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest= /

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-httpauth-digest-01
A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-httpauth-= digest-01


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
http-auth mailing list
http-auth@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/http-auth

_______________________________________________
http-auth mailing listhttp-auth@ietf.or= g
https://www.ietf.org/mailman/listinfo/http-auth

_________________________________________________________
Michael Sweet,= Senior Printing System=A0Engineer, PWG Chair


--001a11c34386ecd5cb04ef6164a1-- From msweet@apple.com Tue Jan 7 07:36:41 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E0181ADF61 for ; Tue, 7 Jan 2014 07:36:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.439 X-Spam-Level: X-Spam-Status: No, score=-7.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BpU-c0sEL2bn for ; Tue, 7 Jan 2014 07:36:39 -0800 (PST) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 5294B1ADF80 for ; Tue, 7 Jan 2014 07:36:38 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_TRxzFS9vg7u4T+NHmwoTkQ)" Received: from relay3.apple.com ([17.128.113.83]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MZ100E9ZFBY87V1@mail-out.apple.com> for http-auth@ietf.org; Tue, 07 Jan 2014 07:35:58 -0800 (PST) X-AuditID: 11807153-b7f396d00000722b-f9-52cc1edcf4db Received: from [17.153.98.226] (Unknown_Domain [17.153.98.226]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay3.apple.com (Apple SCV relay) with SMTP id F2.91.29227.DDE1CC25; Tue, 07 Jan 2014 07:35:58 -0800 (PST) From: Michael Sweet In-reply-to: Date: Tue, 07 Jan 2014 10:35:59 -0500 Message-id: <84C71A2D-E085-4C3C-8C2F-CD59FB9D9A2D@apple.com> References: <20140101174057.13310.83765.idtracker@ietfa.amsl.com> <6A343EB6-C228-47E0-8757-259C3B487736@apple.com> To: Rifaat Shekh-Yusef X-Mailer: Apple Mail (2.1827) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUiODPpke49uTNBBsuOSVl82D+HyeLIt1iL nS9a2RyYPbae/MHmsXPWXXaPJUt+MgUwR3HZpKTmZJalFunbJXBlPFi9l73gnEnF5XMTmBsY J+l2MXJySAiYSHSv2cIEYYtJXLi3ng3EFhLoZZJobHEHsYUF3CQamq8AxTk4eAX0JPavSgUJ MwskSLzubWMFsdkE1CR+T+oDszkFAiVevJjLDGKzCKhILFx4kgmiXldi6cluRhCbV8BGYv77 r0A1XECr/jBK/O3oZAdJiADNb/+7kAlkl4SArMT806UTGPlmIWyehWQzhK0tsWzha2YIW0/i ZdM7dkxxXYmL6yYxLmBkW8UoUJSak1hprJdYUJCTqpecn7uJERSwDYXBOxj/LLM6xCjAwajE w/ti76kgIdbEsuLK3EOMEhzMSiK896TPBAnxpiRWVqUW5ccXleakFh9ilOZgURLnrT+0JUhI ID2xJDU7NbUgtQgmy8TBKdXAuMzkrfG2dAHWt4G7n+mpPTRfErNt78/nkkoaM1yr5CqUtwcw LXG0f6KldT/638zilR/rVyUvP3xsg5uVMfMLQ8+MDTO7JN7Md9vbLrfIru89r+9WjWl5L++/ /nz6lN/BuWHv5LimKT/Ur9264LRmf0qnhivv/J35f3p3xL2OXiin1rI52LE8XYmlOCPRUIu5 qDgRANobgwBUAgAA Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-01.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 15:36:41 -0000 --Boundary_(ID_TRxzFS9vg7u4T+NHmwoTkQ) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Rifaat, My responses are inline... On Jan 7, 2014, at 8:31 AM, Rifaat Shekh-Yusef 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. > > In section 4, did we ever decide what to say about the Unicode normalization form? RFC 5198 (network unicode) is often referenced and uses NFC. > > I remember some discussion on the mailing list, but if I remember correctly I do not think that there was any conclusion to that discussion. It is very important that we say something here, otherwise Unicode names and passwords will not be reliable. If we don't want to standardize on a single normalization form for the protocol, we need to say something about requiring the server to do normalization and why. _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Boundary_(ID_TRxzFS9vg7u4T+NHmwoTkQ) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable Rifaat,

My responses are = inline...

On Jan 7, 2014, at 8:31 AM, Rifaat = Shekh-Yusef <rifaat.ietf@gmail.com> = 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.


In section 4, = did we ever decide what to say about the Unicode normalization form? RFC = 5198 (network unicode) is often referenced and uses = NFC.

I remember some discussion on the mailing list, but if I remember = correctly I do not think that there was any conclusion to that = discussion.

It is = very important that we say something here, otherwise Unicode names and = passwords will not be reliable.  If we don't want to standardize on = a single normalization form for the protocol, we need to say something = about requiring the server to do normalization and = why.

_________________________________________________________
Michael = Sweet, Senior Printing System Engineer, PWG = Chair

= --Boundary_(ID_TRxzFS9vg7u4T+NHmwoTkQ)-- From ietf-ipr@ietf.org Tue Jan 7 13:42:44 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93B1B1AE204; Tue, 7 Jan 2014 13:42:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBR3RoVQyWyw; Tue, 7 Jan 2014 13:42:43 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 69AAB1AE1F5; Tue, 7 Jan 2014 13:42:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: mutual-auth-contact-ml@aist.go.jp X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140107214243.26666.28702.idtracker@ietfa.amsl.com> Date: Tue, 07 Jan 2014 13:42:43 -0800 Cc: http-auth@ietf.org, ipr-announce@ietf.org Subject: [http-auth] IPR Disclosure: National Institute of Advanced Industrial Science and Technology (AIST) AND Yahoo! Japan, Inc.'s Statement about IPR related to draft-ietf-httpauth-mutual-00 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2014 21:42:44 -0000 Dear Yutaka Oiwa, Hajime Watanabe, Hiromitsu Takagi, Tatsuya Hayashi, Yuich= i Ioku: An IPR disclosure that pertains to your Internet-Draft entitled "Mutual Authentication Protocol for HTTP" (draft-ietf-httpauth-mutual) was submitte= d to the IETF Secretariat on 2013-10-21 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2220/). The title of the IPR disclosure is "National Institute of Advanced Industrial Science and Technology (AIST) AND Yahoo! Japan, Inc.'s Statement about IPR related to draft-ietf-httpauth- mutual-00.""); The IETF Secretariat From rifaat.ietf@gmail.com Tue Jan 7 16:44:33 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B04F1AE25F for ; Tue, 7 Jan 2014 16:44:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gg9T2kXvhOET for ; Tue, 7 Jan 2014 16:44:31 -0800 (PST) Received: from mail-ee0-x231.google.com (mail-ee0-x231.google.com [IPv6:2a00:1450:4013:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 42ECA1AE25C for ; Tue, 7 Jan 2014 16:44:31 -0800 (PST) Received: by mail-ee0-f49.google.com with SMTP id c41so370892eek.36 for ; Tue, 07 Jan 2014 16:44:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=SXigVqUPBeL9iRyPALp68dRM9gce4DO44vc6kKcVJvc=; b=G7Ef4fZkE0KZiqotrMSsAGTa84x0976jdYxmFNRGr/y+8LV8YUIVRlXUIXgtY/h4NV EV8FSMKSX8fJea26WZnjnnIQe75IFOPXis42bxsB2WyiviBe54AjOOisurikXITMcNev FTxRJ/srMas4GG/UW3cFw4H+vNZzZUVVc3ahHRqPPIcXYdh/6igtNItVwB5agseFA/9c +L+8F4DJuT9S0gvjV9wa6VngU3Rmyoi0BlupN/+ZxlSMWjAxid1Uj8ziPzV8Ap5lXC5X gGq9TzQENyAbqNFyXOZCZTnag7b5WlSn4tS240AU5fXhwixN9KTNTzE42hnogwGeyAop GlEw== MIME-Version: 1.0 X-Received: by 10.15.34.197 with SMTP id e45mr43084425eev.61.1389141861859; Tue, 07 Jan 2014 16:44:21 -0800 (PST) Received: by 10.14.53.78 with HTTP; Tue, 7 Jan 2014 16:44:21 -0800 (PST) Date: Tue, 7 Jan 2014 19:44:21 -0500 Message-ID: From: Rifaat Shekh-Yusef To: Michael Sweet Content-Type: multipart/alternative; boundary=089e016353ca38082f04ef6acbf9 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] HTTP Digest - RFC2069 Backward Compatibility? X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 00:44:33 -0000 --089e016353ca38082f04ef6acbf9 Content-Type: text/plain; charset=ISO-8859-1 I have changed the Subject to reflect this discussion. See my reply below. On Tue, Jan 7, 2014 at 10:35 AM, Michael Sweet wrote: > Rifaat, > > My responses are inline... > > On Jan 7, 2014, at 8:31 AM, Rifaat Shekh-Yusef > 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 --089e016353ca38082f04ef6acbf9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have changed the Subject to reflect this discussion. See= my reply below.


On Tue, Jan 7, 2014 at 10:35 AM, Michael Sweet <= ;msweet@apple.com= > wrote:
Rifaat,<= div>
My responses are inline...

On Ja= n 7, 2014, at 8:31 AM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:
...=A0
<= div class=3D"im">
Also, qop-options still has the RFC 2617 mix of optional an= d SHOULD. =A0Since RFC 2069 is long dead, it is probably better to simply s= ay it is now RECOMMENDED and that the absence of values is for backwards co= mpatibility with RFC 2069, e.g.:

I meant to send a separate emai= l 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 co= nsideration for backward compatibility with it?

RFC 2069 wa= s/is standards-track, obsoleted by 2617. I'm not sure what the IETF rul= es are for deprecation/breaking backwards compatibility with prior standard= s 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. =A0That preserves backwards com= patibility with RFC 2069-based servers while requiring the new form in curr= ent servers.

=A0
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 happe= ning, we need to stop that backward compatibility with this old and obsolet= e RFC.

Regards,
=A0Rifaat

=
--089e016353ca38082f04ef6acbf9-- From msweet@apple.com Tue Jan 7 17:12:23 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD1EF1AE275 for ; Tue, 7 Jan 2014 17:12:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.439 X-Spam-Level: X-Spam-Status: No, score=-7.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N9mQlxowTFiB for ; Tue, 7 Jan 2014 17:12:21 -0800 (PST) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 5F2BB1AE270 for ; Tue, 7 Jan 2014 17:12:21 -0800 (PST) MIME-version: 1.0 Received: from relay7.apple.com ([17.128.113.101]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MZ20095G603FMM1@mail-out.apple.com> for http-auth@ietf.org; Tue, 07 Jan 2014 17:12:12 -0800 (PST) X-AuditID: 11807165-b7f8e6d000004de8-a5-52cca5ecf4b7 Received: from marigold.apple.com (marigold.apple.com [17.128.115.132]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay7.apple.com (Apple SCV relay) with SMTP id DB.FC.19944.CE5ACC25; Tue, 07 Jan 2014 17:12:12 -0800 (PST) Received: from [17.153.35.66] by marigold.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MZ200N3I60A1670@marigold.apple.com> for http-auth@ietf.org; Tue, 07 Jan 2014 17:12:11 -0800 (PST) Content-type: multipart/signed; boundary="Apple-Mail=_15912C75-3732-4A0A-86A7-1ABC9906306B"; protocol="application/pkcs7-signature"; micalg=sha1 From: Michael Sweet In-reply-to: Date: Tue, 07 Jan 2014 20:12:09 -0500 Message-id: References: To: Rifaat Shekh-Yusef X-Mailer: Apple Mail (2.1859) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUi2FDcovtm6Zkgg4eTBCw+7J/D5MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujLP3+pkLDuZXTPu5j72B8U9qFyMHh4SAiURTo0sXIyeQKSZx 4d56ti5GLg4hgUlMEntOHGMFSQgJtDFJPFubBWILC7hJdE96wgZi8wroSaw7voQdpIFZYAqj xJ2Zt8ESbAJqEr8n9YE1cwoES7y7/gwsziKgKtH//AAziM0soCux9GQ3I8QgG4l5V9YzQywL kLh4fz5YXARoQfvfhUwQ18lK/Li0gHECI/8sJLtnIds9C+ghZoEkidXPfGaBrdCWWLbwNTOE rSfxsukdO6a4rsTFdZMYIWxTiSdvt7NB2NYSP+c8goorSkzpfsi+gJFrFaNAUWpOYqW5XmJB QU6qXnJ+7iZGcCQUpu5gbFxudYhRgINRiYe3QeVMkBBrYllxZe4hRhWgEY82rL7AKMWSl5+X qiTCe6wbKM2bklhZlVqUH19UmpNafIhRmoNFSZy36dCWICGB9MSS1OzU1ILUIpgsEwenVAOj wkYW/iP3Nnu+LhAyvlaukc179peB+cJff+dvFknb4q1bFeTXo5x7dhPXofA7UbN/J64WyFzQ M3W7au6cgt1uD3OuZE7YyPq6ePmquaeXFulMENsvHnNF5eOdj2oP1qfyXV0kfeSOebpP7gPD 8ufPv8RZv3z+Kuy7i7vbzDe+n+v/pJ4oeHj3txJLcUaioRZzUXEiAAzgm0CMAgAA Cc: "http-auth@ietf.org" Subject: Re: [http-auth] HTTP Digest - RFC2069 Backward Compatibility? X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 01:12:23 -0000 --Apple-Mail=_15912C75-3732-4A0A-86A7-1ABC9906306B Content-Type: multipart/alternative; boundary="Apple-Mail=_1818E1DD-0A34-4E65-8E01-1CFFD3A3A994" --Apple-Mail=_1818E1DD-0A34-4E65-8E01-1CFFD3A3A994 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 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 = wrote: > I have changed the Subject to reflect this discussion. See my reply = below. >=20 >=20 > On Tue, Jan 7, 2014 at 10:35 AM, Michael Sweet = wrote: > Rifaat, >=20 > My responses are inline... >=20 > On Jan 7, 2014, at 8:31 AM, Rifaat Shekh-Yusef = wrote: >> ...=20 >> 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.: >>=20 >> 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? >=20 > 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. >=20 > 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. >=20 > =20 > 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. >=20 > Regards, > Rifaat >=20 _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Apple-Mail=_1818E1DD-0A34-4E65-8E01-1CFFD3A3A994 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 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 <rifaat.ietf@gmail.com> = wrote:

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


On Tue, Jan 7, = 2014 at 10:35 AM, Michael Sweet <msweet@apple.com> wrote:
Rifaat,

My responses = are inline...

On Jan 7, 2014, at 8:31 AM, Rifaat = Shekh-Yusef <rifaat.ietf@gmail.com> 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

= --Apple-Mail=_1818E1DD-0A34-4E65-8E01-1CFFD3A3A994-- --Apple-Mail=_15912C75-3732-4A0A-86A7-1ABC9906306B Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPJTCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBSIwggQKoAMC AQICEQDlB7dXxclLEedquPvGX8CGMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBMB4XDTEzMTIxNzAwMDAwMFoXDTE0MTIxNzIzNTk1OVowITEfMB0GCSqG SIb3DQEJARYQbXN3ZWV0QGFwcGxlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ANdvQYZRCVzc0wIYvIOn/0Pv7zUwuIvbAfM/W3FyemqZx3fdKxX4WxN2x5NC3hhBHGrUWirJH7rl 6It12bGQ61uHAK5jsJikV5k+mOYjZaKNIKxj0uYIk3MKQmsmM8t3nddq5mp2mxwV/U7AFPTz1fgh dkqTb/NkHY5eA8KqksaeqwfMgoaiGVeCUhptWnXosca8PAkb+i9u5rEok5zgY+QP0IuWLJENfA4q dEMsH+OAwMGOv9fNCgcdapFnjeSYaj70m6qUiq446+8a2rhUsEUKQayOMgjnm2bgUuNx7pOvs/Jg zIlZoTz/llmE1HWREGzSjRnLWwQ98fspfeZWA+8CAwEAAaOCAeAwggHcMB8GA1UdIwQYMBaAFHoT TgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTtKBJoG9kxZisTqJg4+wr12l4stjAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIw EQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUH AgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6 Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1h aWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9j YS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggr BgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMBsGA1UdEQQUMBKBEG1zd2VldEBhcHBs ZS5jb20wDQYJKoZIhvcNAQEFBQADggEBABg5KLQK5u9gGI75u+vYH/i6uMDKlpTILO/r/FpN2ibq pwAB2ln9oKvPIA1/r3o+DBC87TqnlJAiPW4ADFHpRmqlprb0Tu9p98nP/wl5tBZjEP8dY4iH0TB3 B2r9JHwRwwJQ20CqJpuCn9dmvL215sZSqvJfluVlIcAQCLxp3ZKMIC2pNKitswdjjHduaKuj2TMe xrzMtrRGRtFF9pcMcnsqE2QtJUqXPV7/M4WT2yRUmI4ThPt9O9fmPH2ku52hdb6t4qXvwdQSkDHt xo3J/Vc/jDR2/feedDhQmG0V9j6tHsuG6bVVhcGiWnSmSoPfg13FlQwlxZTyFtiMZ2jILyoxggOu MIIDqgIBATCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAOUHt1fFyUsR 52q4+8ZfwIYwCQYFKw4DAhoFAKCCAdkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTQwMTA4MDExMjEwWjAjBgkqhkiG9w0BCQQxFgQUTbTbZ7vpMb+4nIyXskqH5uUc fLgwgboGCSsGAQQBgjcQBDGBrDCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx OTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIRAOUHt1fFyUsR52q4+8ZfwIYwgbwGCyqGSIb3DQEJEAILMYGsoIGpMIGTMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgU2VjdXJlIEVtYWlsIENBAhEA5Qe3V8XJSxHnarj7xl/AhjANBgkqhkiG9w0BAQEFAASC AQBzFaqENF1zq8TfDlRwt23M8wDdhZz616KDDqldSZEbsfKVxu/vD/OHcGufxvYr5f2tkA2bEwYb kk7kxAzHSBD29kDBXP9NUJRjAKnvv4UwnlR7u0HQVf9kdkkbmwhvGL9Ia8lPbZKtQ7BzGeAsm2KP TwHAaEey2cTEKLbe2nGrXdOyfKaSguYuHE+wsKlb70eD59zyJi4wgnI1Itooa7W66YIhXwxhws34 I/mNhyEjdQZdbRLV8kvp5P8SP+yPoibV6vJgN5zansrCkDUiliktIvXMslGebgojeBfu3nqxegEN 4SaUBa1/2kU3a/fgU0gbT5ntoByesXuEX0ksO/59AAAAAAAA --Apple-Mail=_15912C75-3732-4A0A-86A7-1ABC9906306B-- From ynir@checkpoint.com Wed Jan 8 00:15:49 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D49A61AE330 for ; Wed, 8 Jan 2014 00:15:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.438 X-Spam-Level: X-Spam-Status: No, score=-7.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id keTCvjLF33lI for ; Wed, 8 Jan 2014 00:15:46 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 23F741AD0F0 for ; Wed, 8 Jan 2014 00:15:44 -0800 (PST) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id s088FT7o026162; Wed, 8 Jan 2014 10:15:29 +0200 X-CheckPoint: {52CD03ED-0-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.110]) by IL-EX10.ad.checkpoint.com ([169.254.2.120]) with mapi id 14.03.0123.003; Wed, 8 Jan 2014 10:15:29 +0200 From: Yoav Nir To: Michael Sweet , Rifaat Shekh-Yusef Thread-Topic: [http-auth] HTTP Digest - RFC2069 Backward Compatibility? Thread-Index: AQHPDArQj4i2tUsIkkSyz0a4Ol7IgZp547GAgACQWLA= Date: Wed, 8 Jan 2014 08:15:28 +0000 Message-ID: <4613980CFC78314ABFD7F85CC302772121B8457F@DAG-EX10.ad.checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [91.90.139.27] x-kse-antivirus-interceptor-info: protection disabled Content-Type: multipart/alternative; boundary="_000_4613980CFC78314ABFD7F85CC302772121B8457FDAGEX10adcheckp_" MIME-Version: 1.0 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] HTTP Digest - RFC2069 Backward Compatibility? X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 08:15:50 -0000 --_000_4613980CFC78314ABFD7F85CC302772121B8457FDAGEX10adcheckp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 implem= entations of RFC 2617 but not RFC 2069. So if the server sends it and the c= lient does not, it means that the client is old and supports only 2069. OTO= H 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 do= cument) 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]; it SHOULD be used by all implementations compliant with this versio= n of the Digest scheme.". I don't like the lower-case "optional" either, bu= t 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 ve= ry 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-op= tions. Question is, does anyone on this list have the data to tell us this? Yoav From: http-auth [mailto:http-auth-bounces@ietf.org] On Behalf Of Michael Sw= eet Sent: Wednesday, January 08, 2014 3:12 AM To: Rifaat Shekh-Yusef Cc: http-auth@ietf.org Subject: Re: [http-auth] HTTP Digest - RFC2069 Backward Compatibility? 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. T= here is clearly an incentive to do so... On Jan 7, 2014, at 7:44 PM, Rifaat Shekh-Yusef > wrote: I have changed the Subject to reflect this discussion. See my reply below. On Tue, Jan 7, 2014 at 10:35 AM, Michael Sweet > wrote: Rifaat, My responses are inline... On Jan 7, 2014, at 8:31 AM, Rifaat Shekh-Yusef > 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 RECOM= MENDED and that the absence of values is for backwards compatibility with R= FC 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 bac= kward compatibility with it? RFC 2069 was/is standards-track, obsoleted by 2617. I'm not sure what the I= ETF rules are for deprecation/breaking backwards compatibility with prior s= tandards track work. The "safe" path is to REQUIRE qop-options on the server and make qop condit= ionally required based on the presence of the qop-options parameter in WWW-= Authenticate. That preserves backwards compatibility with RFC 2069-based s= ervers 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 thi= s 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 --_000_4613980CFC78314ABFD7F85CC302772121B8457FDAGEX10adcheckp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi

 <= /p>

There are no hard and fas= t rules for compatibility with obsoleted RFCs, and we should make our decis= ions based on “what’s out there”.

 <= /p>

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.

 <= /p>

Michael’s suggestio= n 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 req= uire qop-options and for the client to refuse authentication if they’= re missing.

 <= /p> 

I would =
be all for the alternative, but RFC 2617 says this: “This directive is optional, but is made so only for backwar=
d compatibility with RFC 206=
9 [6]; it SHOUL=
D be used by all implementations compliant with this version of the Digest =
scheme.”. I don’t like the lo=
wer-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 requ=
ire the client to enforce that MUST, we need to make sure of a few things:<=
o:p>
·=
   &n=
bsp;     That RFC 2069 servers that are not com=
pliant with RFC 2617 are very very rare.
·=
   &n=
bsp;     That RFC 2617 that don’t send qo=
p-options (because it’s “just” a SHOULD) are also very ra=
re.
IOW we h=
ave to first make sure that all (or nearly all) servers send qop-options.
&nb=
sp;
Question=
 is, does anyone on this list have the data to tell us this?
&nb=
sp;
Yoav

 <= /p>

From: http-aut= h [mailto:http-auth-bounces@ietf.org] On Behalf Of Michael Sweet
Sent: Wednesday, January 08, 2014 3:12 AM
To: Rifaat Shekh-Yusef
Cc: http-auth@ietf.org
Subject: Re: [http-auth] HTTP Digest - RFC2069 Backward Compatibilit= y?

 

Just to be clear, I am OK with getting rid of backwa= rds 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 <<= a href=3D"mailto:rifaat.ietf@gmail.com">rifaat.ietf@gmail.com> wrote= :



I have changed the Subject to reflect this discussio= n. See my reply below.

 

On Tue, Jan 7, 2014 at 10:35 AM, Michael Sweet <<= a href=3D"mailto:msweet@apple.com" target=3D"_blank">msweet@apple.com&g= t; wrote:

Rifaat,

 

My responses are inline...

 

On Jan 7, 2014, at 8:31 AM, Rifaat Shekh-Yusef <<= a href=3D"mailto:rifaat.ietf@gmail.com" target=3D"_blank">rifaat.ietf@gmail= .com> wrote:

... 

Also, qop-options still has the RFC 2617 mix of opti= onal and SHOULD.  Since RFC 2069 is long dead, it is probably better t= o simply say it is now RECOMMENDED and that the absence of values is for ba= ckwards compatibility with RFC 2069, e.g.:

 

I meant to send a separate email to discuss the issu= e of RFC2069, but since you raised it, I will discuss it here.

Should we just not worry about RFC2069 and remove an= y 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 com= patibility 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 backwar= ds compatibility with RFC 2069-based servers while requiring the new form in current servers.

 

 

The problem with this approach is that it would allo= w any MITM to downgrade the quality of the security to the RFC2069 level. I= f we want o prevent this from happening, we need to stop that backward comp= atibility with this old and obsolete RFC.

 

Regards,

 Rifaat

 

 

_____________________________________________= ____________
Michael Sweet, Senior Printing System Engineer, PWG Chair

 

--_000_4613980CFC78314ABFD7F85CC302772121B8457FDAGEX10adcheckp_-- From msweet@apple.com Wed Jan 8 05:58:05 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE041AE3D8 for ; Wed, 8 Jan 2014 05:58:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.439 X-Spam-Level: X-Spam-Status: No, score=-7.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQnMbsufFvcX for ; Wed, 8 Jan 2014 05:58:02 -0800 (PST) Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 04F211AE3A6 for ; Wed, 8 Jan 2014 05:58:02 -0800 (PST) MIME-version: 1.0 Received: from relay5.apple.com ([17.128.113.88]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MZ3008445FEXUP1@mail-out.apple.com> for http-auth@ietf.org; Wed, 08 Jan 2014 05:57:18 -0800 (PST) X-AuditID: 11807158-b7efa6d000002d28-8f-52cd593d2434 Received: from marigold.apple.com (marigold.apple.com [17.128.115.132]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id 6E.C6.11560.D395DC25; Wed, 08 Jan 2014 05:57:17 -0800 (PST) Received: from [17.153.35.66] by marigold.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MZ3007F65FFEF40@marigold.apple.com> for http-auth@ietf.org; Wed, 08 Jan 2014 05:57:17 -0800 (PST) Content-type: multipart/signed; boundary="Apple-Mail=_86E173F8-4D2D-4C56-BC39-A79387318F42"; protocol="application/pkcs7-signature"; micalg=sha1 From: Michael Sweet In-reply-to: <4613980CFC78314ABFD7F85CC302772121B8457F@DAG-EX10.ad.checkpoint.com> Date: Wed, 08 Jan 2014 08:57:14 -0500 Message-id: References: <4613980CFC78314ABFD7F85CC302772121B8457F@DAG-EX10.ad.checkpoint.com> To: Yoav Nir X-Mailer: Apple Mail (2.1859) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPLMWRmVeSWpSXmKPExsUi2FDcomsbeTbI4P81FYsP++cwOTB6LFny kymAMYrLJiU1J7MstUjfLoEr4+qzA8wF558xVrT/6mFtYNx/lrGLkZNDQsBE4uSMSywQtpjE hXvr2boYuTiEBCYxSeze+RHKaWOSuHD7O1iVsICbRPekJ2wgNq+AnsS640vYQYqYBaYwSuw8 18QKkmATUJP4PakPzOYUCJG4uaoNbB2LgKrEwaczwQYxC0RL3F39gxlikI1E/8Y/TBDbzjJK TLq2BKxBREBJ4sfVmawQ98lK/Li0gHECI/8sJMtnIVs+C2xwkkTvq6vsELa2xLKFr5khbAOJ p52vWDHF9SXevJvDBGGbSjx5u50NwraW+DnnESOErSgxpfsh+wJGrlWMAkWpOYmVpnqJBQU5 qXrJ+bmbGMFRURixg/H/MqtDjAIcjEo8vDfUzgQJsSaWFVfmHmJUARrxaMPqC4xSLHn5ealK Irx6ymeDhHhTEiurUovy44tKc1KLDzFKc7AoifM2HtoSJCSQnliSmp2aWpBaBJNl4uCUamAM +zI/tdt1dfrawN2a11l1qq5xlgtoJ6h9OqhULqXB2pxV6FT1MMFckVeJbbIu5xGLw7dusnJO k/l657Leit1S3O4aHFueM4cmdSfuvfrD94XfrhkrN68+uPfdh6Szi78GPz509dJ7rdOCt312 mS5tnC9Yk31YWXvOlBeisuczuZzndhxr22qnxFKckWioxVxUnAgAHMUDKpICAAA= Cc: "http-auth@ietf.org" Subject: Re: [http-auth] HTTP Digest - RFC2069 Backward Compatibility? X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 13:58:05 -0000 --Apple-Mail=_86E173F8-4D2D-4C56-BC39-A79387318F42 Content-Type: multipart/alternative; boundary="Apple-Mail=_803CDB94-FDC2-45F0-844E-2D935C1F1308" --Apple-Mail=_803CDB94-FDC2-45F0-844E-2D935C1F1308 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 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 wrote: > Hi > =20 > There are no hard and fast rules for compatibility with obsoleted = RFCs, and we should make our decisions based on =93what=92s out there=94. > =20 > 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. > =20 > Michael=92s 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=92re missing. > =20 > I would be all for the alternative, but RFC 2617 says this: =93This = 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.=94. I don=92t like the = lower-case =93optional=94 either, but the thing is, it=92s 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: > =B7 That RFC 2069 servers that are not compliant with RFC 2617 = are very very rare. > =B7 That RFC 2617 that don=92t send qop-options (because it=92s = =93just=94 a SHOULD) are also very rare. > IOW we have to first make sure that all (or nearly all) servers send = qop-options. > =20 > Question is, does anyone on this list have the data to tell us this? > =20 > Yoav > =20 > From: http-auth [mailto:http-auth-bounces@ietf.org] On Behalf Of = Michael Sweet > Sent: Wednesday, January 08, 2014 3:12 AM > To: Rifaat Shekh-Yusef > Cc: http-auth@ietf.org > Subject: Re: [http-auth] HTTP Digest - RFC2069 Backward Compatibility? > =20 > 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... > =20 > =20 > On Jan 7, 2014, at 7:44 PM, Rifaat Shekh-Yusef = wrote: >=20 >=20 > I have changed the Subject to reflect this discussion. See my reply = below. > =20 >=20 > On Tue, Jan 7, 2014 at 10:35 AM, Michael Sweet = wrote: > Rifaat, > =20 > My responses are inline... > =20 > On Jan 7, 2014, at 8:31 AM, Rifaat Shekh-Yusef = wrote: > ...=20 > 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.: > =20 > 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? > =20 > 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. > =20 > 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. > =20 > =20 > 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. > =20 > Regards, > Rifaat > =20 > =20 > _________________________________________________________ > Michael Sweet, Senior Printing System Engineer, PWG Chair > =20 _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Apple-Mail=_803CDB94-FDC2-45F0-844E-2D935C1F1308 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 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 <ynir@checkpoint.com> = wrote:

Hi

 

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

 

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=92s 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=92re missing.

 

I would be all for the alternative, but RFC 2617 =
says this: =93This 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.=94. I don=92t like the lower-case =93optional=94 =
either, but the thing is, it=92s 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:
=B7         =
That RFC 2069 servers that are not compliant with =
RFC 2617 are very very rare.
=B7         =
That RFC 2617 that don=92t send qop-options =
(because it=92s =93just=94 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:http-auth-bounces@ietf.o= rg] On Behalf Of Michael Sweet
Sent: Wednesday, January 08, 2014 3:12 AM
To: Rifaat Shekh-Yusef
Cc: http-auth@ietf.org
Subject: Re: [http-auth] HTTP Digest - RFC2069 Backward = Compatibility?

 

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 <rifaat.ietf@gmail.com> = wrote:



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

 

On Tue, Jan 7, 2014 at 10:35 AM, Michael = Sweet <msweet@apple.com> wrote:

Rifaat,

 

My responses are inline...

 

On Jan 7, 2014, at 8:31 AM, Rifaat = Shekh-Yusef <rifaat.ietf@gmail.com> 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

 


_________________________________________________________
Michael = Sweet, Senior Printing System Engineer, PWG = Chair

= --Apple-Mail=_803CDB94-FDC2-45F0-844E-2D935C1F1308-- --Apple-Mail=_86E173F8-4D2D-4C56-BC39-A79387318F42 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPJTCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBSIwggQKoAMC AQICEQDlB7dXxclLEedquPvGX8CGMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBMB4XDTEzMTIxNzAwMDAwMFoXDTE0MTIxNzIzNTk1OVowITEfMB0GCSqG SIb3DQEJARYQbXN3ZWV0QGFwcGxlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ANdvQYZRCVzc0wIYvIOn/0Pv7zUwuIvbAfM/W3FyemqZx3fdKxX4WxN2x5NC3hhBHGrUWirJH7rl 6It12bGQ61uHAK5jsJikV5k+mOYjZaKNIKxj0uYIk3MKQmsmM8t3nddq5mp2mxwV/U7AFPTz1fgh dkqTb/NkHY5eA8KqksaeqwfMgoaiGVeCUhptWnXosca8PAkb+i9u5rEok5zgY+QP0IuWLJENfA4q dEMsH+OAwMGOv9fNCgcdapFnjeSYaj70m6qUiq446+8a2rhUsEUKQayOMgjnm2bgUuNx7pOvs/Jg zIlZoTz/llmE1HWREGzSjRnLWwQ98fspfeZWA+8CAwEAAaOCAeAwggHcMB8GA1UdIwQYMBaAFHoT TgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBTtKBJoG9kxZisTqJg4+wr12l4stjAOBgNVHQ8B Af8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIw EQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUH AgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6 Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1h aWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9j YS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggr BgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMBsGA1UdEQQUMBKBEG1zd2VldEBhcHBs ZS5jb20wDQYJKoZIhvcNAQEFBQADggEBABg5KLQK5u9gGI75u+vYH/i6uMDKlpTILO/r/FpN2ibq pwAB2ln9oKvPIA1/r3o+DBC87TqnlJAiPW4ADFHpRmqlprb0Tu9p98nP/wl5tBZjEP8dY4iH0TB3 B2r9JHwRwwJQ20CqJpuCn9dmvL215sZSqvJfluVlIcAQCLxp3ZKMIC2pNKitswdjjHduaKuj2TMe xrzMtrRGRtFF9pcMcnsqE2QtJUqXPV7/M4WT2yRUmI4ThPt9O9fmPH2ku52hdb6t4qXvwdQSkDHt xo3J/Vc/jDR2/feedDhQmG0V9j6tHsuG6bVVhcGiWnSmSoPfg13FlQwlxZTyFtiMZ2jILyoxggOu MIIDqgIBATCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQ MA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAOUHt1fFyUsR 52q4+8ZfwIYwCQYFKw4DAhoFAKCCAdkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTQwMTA4MTM1NzE1WjAjBgkqhkiG9w0BCQQxFgQUOZr7l+YroqOgbkcF3Bsos1Lw gfYwgboGCSsGAQQBgjcQBDGBrDCBqTCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIg TWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx OTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIRAOUHt1fFyUsR52q4+8ZfwIYwgbwGCyqGSIb3DQEJEAILMYGsoIGpMIGTMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgU2VjdXJlIEVtYWlsIENBAhEA5Qe3V8XJSxHnarj7xl/AhjANBgkqhkiG9w0BAQEFAASC AQBAJe18dvoQclUSFuSxYS+Pp7OP545OzCXNXFY7XxX9NljM7x+VKj/Q1AV/VL2XOmlu5pAF5qyJ eRcBJas5meW6Nav16KfSL4jBcas9oBLp+xY7n+euuCC0VA9vvx9Miw4ATNp0pXNksoNrgOMSKHcR cqUj3W2k0Q1gzvaG12j4KcWBkdYDEGTRi6f4e22EnmnZwuoiK41BzlKo5mq07HOJVphhY7yA4Y4W T3Lp6kbdz+CJm9YPfpoTdsVntI9uY2ozjX1CsULCx1N+oHlqEh10COnfSjolo1rLef7Uniah0GIO GGskZpih3TEg3ZMnfZJwGwkNj1zAM2skrDRwZpkUAAAAAAAA --Apple-Mail=_86E173F8-4D2D-4C56-BC39-A79387318F42-- From sophie.bremer@netzkonform.de Wed Jan 8 12:29:36 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E1411AE181 for ; Wed, 8 Jan 2014 12:29:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RxGFaexFkjnl for ; Wed, 8 Jan 2014 12:29:34 -0800 (PST) Received: from wp072.webpack.hosteurope.de (wp399.xfer.webpack.hosteurope.de [IPv6:2a01:488:42::523:e524]) by ietfa.amsl.com (Postfix) with ESMTP id 291411AE174 for ; Wed, 8 Jan 2014 12:29:33 -0800 (PST) Received: from [82.113.121.181] (helo=[10.70.196.181]); authenticated by wp072.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) id 1W0zke-0007ay-1w; Wed, 08 Jan 2014 21:29:22 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Sophie Bremer In-Reply-To: <4613980CFC78314ABFD7F85CC302772121B8457F@DAG-EX10.ad.checkpoint.com> Date: Wed, 8 Jan 2014 21:29:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4613980CFC78314ABFD7F85CC302772121B8457F@DAG-EX10.ad.checkpoint.com> To: Yoav Nir X-Mailer: Apple Mail (2.1827) X-bounce-key: webpack.hosteurope.de; sophie.bremer@netzkonform.de; 1389212965; d0d1b92c; Cc: "http-auth@ietf.org" Subject: Re: [http-auth] HTTP Digest - RFC2069 Backward Compatibility? X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 20:29:36 -0000 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 Am 08.01.2014 um 09:15 schrieb Yoav Nir : > Hi > =20 > There are no hard and fast rules for compatibility with obsoleted = RFCs, and we should make our decisions based on =93what=92s out there=94. > =20 > 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. > =20 > Michael=92s 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=92re missing. > =20 > I would be all for the alternative, but RFC 2617 says this: =93This = 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.=94. I don=92t like the = lower-case =93optional=94 either, but the thing is, it=92s 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: > =B7 That RFC 2069 servers that are not compliant with RFC 2617 = are very very rare. > =B7 That RFC 2617 that don=92t send qop-options (because it=92s = =93just=94 a SHOULD) are also very rare. > IOW we have to first make sure that all (or nearly all) servers send = qop-options. > =20 > Question is, does anyone on this list have the data to tell us this? > =20 > Yoav >=20 From ynir@checkpoint.com Thu Jan 9 07:24:49 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3EFD1ADEB7 for ; Thu, 9 Jan 2014 07:24:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.438 X-Spam-Level: X-Spam-Status: No, score=-7.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8OaSycWHEfh for ; Thu, 9 Jan 2014 07:24:48 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 778131AE3E6 for ; Thu, 9 Jan 2014 07:24:47 -0800 (PST) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id s09FObg4008598 for ; Thu, 9 Jan 2014 17:24:37 +0200 X-CheckPoint: {52CEB9ED-B-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.110]) by IL-EX10.ad.checkpoint.com ([169.254.2.228]) with mapi id 14.03.0123.003; Thu, 9 Jan 2014 17:24:36 +0200 From: Yoav Nir To: "http-auth@ietf.org" Thread-Topic: [Cfrg] Another PAKE question Thread-Index: AQHPDQFcMPcnbhPjVUeB5uP0j163gA== Date: Thu, 9 Jan 2014 15:24:36 +0000 Message-ID: References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.122] x-kse-antivirus-interceptor-info: protection disabled Content-Type: multipart/alternative; boundary="_000_A4A326BF6C6B482F85FB36880BF315DAcheckpointcom_" MIME-Version: 1.0 Subject: [http-auth] Fwd: [Cfrg] Another PAKE question X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 15:24:49 -0000 --_000_A4A326BF6C6B482F85FB36880BF315DAcheckpointcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi. CFRG has recently had some discussion about PAKEs in general. I have asked = them to take a look at MutualAuth. This is one of the replies that we got. Yoav Begin forwarded message: From: Watson Ladd > Subject: Re: [Cfrg] Another PAKE question Date: January 9, 2014 4:57:19 PM GMT+02:00 To: Yoav Nir > Why is this protocol secure? I would recommend taking the z, and computing a hash of z and the transcript of the protocol. In this way under the ROM, the computed value doesn't reveal information. It ensures that any manipulation of the messages leads to different z values. I'll try to think of ways to make a proof given that change. Sincerely, Watson Ladd On Wed, Jan 8, 2014 at 10:09 PM, Yoav Nir > wrote: Hi I almost feel like I'm asking for trouble after the roast that Dan went thr= ough, but some on this list might want to consider another PAKE going throu= gh an IETF working group. HTTP-Auth is making experimental authentication mechanisms for the HTTP lay= er. One of those is a PAKE. If people here on the CFRG list would like to c= omment on it, that would be great. We can have some discussion here, but ul= timately, comments criticisms and suggestions should go to the HTTP-auth li= st (details below). The draft in question is called "Mutual Authentication Protocol for HTTP". Link: http://tools.ietf.org/html/draft-ietf-httpauth-mutual-01 Yoav co-chair of HTTP-Auth Mailing list details: * http-auth List Information: https://www.ietf.org/mailman/listinfo/http-au= th * http-auth List Archives: http://www.ietf.org/mail-archive/web/http-auth/c= urrent/maillist.html * http-auth Posting Address (requires registration): http-auth@ietf.org _______________________________________________ Cfrg mailing list Cfrg@irtf.org http://www.irtf.org/mailman/listinfo/cfrg -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin Email secured by Check Point --_000_A4A326BF6C6B482F85FB36880BF315DAcheckpointcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Hi.

CFRG has recently had some discussion about PAKEs in general. I have a= sked them to take a look at MutualAuth. This is one of the replies that we = got. 

Yoav

Begin forwarded message:

From: Watso= n Ladd <watsonbladd@gmail.com>
Subject: Re= : [Cfrg] Another PAKE question
Date: Janua= ry 9, 2014 4:57:19 PM GMT+02:00
Why is this protocol secure?
I would recommend taking the z, and computing a hash of z and the
transcript of the protocol. In
this way under the ROM, the computed value doesn't reveal information.
It ensures that any
manipulation of the messages leads to different z values.

I'll try to think of ways to make a proof given that change.
Sincerely,
Watson Ladd

On Wed, Jan 8, 2014 at 10:09 PM, Yoav Nir <ynir@checkpoint.com> wrote:
Hi

I almost feel like I'm asking for trouble after the roast that Dan went thr= ough, but some on this list might want to consider another PAKE going throu= gh an IETF working group.

HTTP-Auth is making experimental authentication mechanisms for the HTTP lay= er. One of those is a PAKE. If people here on the CFRG list would like to c= omment on it, that would be great. We can have some discussion here, but ul= timately, comments criticisms and suggestions should go to the HTTP-auth list (details below).

The draft in question is called "Mutual Authentication Protocol for HT= TP".

Link: = http://tools.ietf.org/html/draft-ietf-httpauth-mutual-01

Yoav
co-chair of HTTP-Auth

Mailing list details:
* http-auth List Information: https://www.ietf.org/mailman/listinfo/http-auth
* http-auth List Archives: http://www.ietf.org/mail-archive/web/http-auth/current/maillist.html * http-auth Posting Address (requires registration): http-auth@ietf.org
_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
http://www.irtf.org/mailman/listinfo/cfrg



--
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

Email secured by Check Point

--_000_A4A326BF6C6B482F85FB36880BF315DAcheckpointcom_-- From ynir@checkpoint.com Thu Jan 9 10:58:02 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 688931AE531 for ; Thu, 9 Jan 2014 10:58:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.439 X-Spam-Level: X-Spam-Status: No, score=-7.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNGzGnDOvZt2 for ; Thu, 9 Jan 2014 10:58:01 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD4F1AE512 for ; Thu, 9 Jan 2014 10:58:00 -0800 (PST) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id s09IvoXr031979 for ; Thu, 9 Jan 2014 20:57:50 +0200 X-CheckPoint: {52CEEBE4-0-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.110]) by IL-EX10.ad.checkpoint.com ([169.254.2.228]) with mapi id 14.03.0123.003; Thu, 9 Jan 2014 20:57:50 +0200 From: Yoav Nir To: "http-auth@ietf.org" Thread-Topic: [Cfrg] Another PAKE question Thread-Index: AQHPDQFcMPcnbhPjVUeB5uP0j163gJp73FEAgADBhQA= Date: Thu, 9 Jan 2014 18:57:49 +0000 Message-ID: <7D278CFE-3EF1-4274-A1B8-3F0E8A0B74CE@checkpoint.com> References: <53bf7ac99fb17e4f9333d42fea20505c.squirrel@www.trepanning.net> In-Reply-To: <53bf7ac99fb17e4f9333d42fea20505c.squirrel@www.trepanning.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.148] x-kse-antivirus-interceptor-info: protection disabled Content-Type: text/plain; charset="iso-8859-1" Content-ID: <44C924DA61D4E345B5BB1F8CCF1BD0F2@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [http-auth] [Cfrg] Another PAKE question X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 18:58:02 -0000 Another reply On Jan 9, 2014, at 9:25 AM, Dan Harkins wrote: [snipped a question about where the algorithm draft was] >=20 > Also, figure 5 seems almost like a joke. Is this protocol _really_ > that complicated? A security protocol that complicated seems like > a recipe for disaster. >=20 > regards, >=20 > Dan. From brett@broadsoft.com Mon Jan 13 03:53:55 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2D91AE131 for ; Mon, 13 Jan 2014 03:53:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBtWKGN1FD8s for ; Mon, 13 Jan 2014 03:53:53 -0800 (PST) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.21]) by ietfa.amsl.com (Postfix) with ESMTP id E1EF71AE12F for ; Mon, 13 Jan 2014 03:53:51 -0800 (PST) Received: from CASUMHUB05.citservers.local (172.16.98.229) by smtpedge.partnerhosted.com (172.16.98.248) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 13 Jan 2014 03:53:59 -0800 Received: from MBX08.citservers.local ([fe80::2564:652:8dc8:caae]) by casumhub05.citservers.local ([::1]) with mapi id 14.02.0247.003; Mon, 13 Jan 2014 03:53:59 -0800 From: Brett Tate To: "draft-ietf-httpauth-digest@tools.ietf.org" , "http-auth@ietf.org" Thread-Topic: draft-ietf-httpauth-digest-01: realm missing quotes Thread-Index: Ac8QVhlGA8f9+63xTsCJDV9T4dkq5A== Date: Mon, 13 Jan 2014 11:53:59 +0000 Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B881A06FA9F@MBX08.citservers.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.98.77] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 13 Jan 2014 04:32:23 -0800 Subject: [http-auth] draft-ietf-httpauth-digest-01: realm missing quotes X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 11:53:55 -0000 Hi, Concerning draft-ietf-httpauth-digest-01 section 3.4.5 example, the realm v= alue should be within quotes: realm=3D"myhost@testrealm.com". Thanks, Brett This email is intended solely for the person or entity to which it is addre= ssed and may contain confidential and/or privileged information. If you are= not the intended recipient and have received this email in error, please n= otify BroadSoft, Inc. immediately by replying to this message, and destroy = all copies of this message, along with any attachment, prior to reading, di= stributing or copying it. From brett@broadsoft.com Mon Jan 13 04:32:43 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 725001AE158 for ; Mon, 13 Jan 2014 04:32:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G8JYy50VtHm2 for ; Mon, 13 Jan 2014 04:32:42 -0800 (PST) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.203]) by ietfa.amsl.com (Postfix) with ESMTP id 6D8CE1AE156 for ; Mon, 13 Jan 2014 04:32:42 -0800 (PST) Received: from CASUMHUB05.citservers.local (172.16.98.229) by smtpedge.partnerhosted.com (172.16.98.247) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 13 Jan 2014 04:32:50 -0800 Received: from MBX08.citservers.local ([fe80::2564:652:8dc8:caae]) by casumhub05.citservers.local ([::1]) with mapi id 14.02.0247.003; Mon, 13 Jan 2014 04:32:46 -0800 From: Brett Tate To: "draft-ietf-httpauth-digest@tools.ietf.org" , "http-auth@ietf.org" Thread-Topic: draft-ietf-httpauth-digest-01: quoting issues Thread-Index: Ac8QW4Og57l6i4Z2Ql2kRUP+p/pYsg== Date: Mon, 13 Jan 2014 12:32:45 +0000 Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B881A06FAB3@MBX08.citservers.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.98.77] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 13 Jan 2014 04:33:34 -0800 Subject: [http-auth] draft-ietf-httpauth-digest-01: quoting issues X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 12:32:43 -0000 Hi, Concerning draft-ietf-httpauth-digest-01, the section 3.9 examples have som= e quoting issues. - The algorithm values within the examples should not be within quotes. - The qop values within Authorization examples should not be within quotes. Thanks, Brett This email is intended solely for the person or entity to which it is addre= ssed and may contain confidential and/or privileged information. If you are= not the intended recipient and have received this email in error, please n= otify BroadSoft, Inc. immediately by replying to this message, and destroy = all copies of this message, along with any attachment, prior to reading, di= stributing or copying it. From brett@broadsoft.com Mon Jan 13 04:59:26 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66D901AE152 for ; Mon, 13 Jan 2014 04:59:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9qmYKbWdSkp for ; Mon, 13 Jan 2014 04:59:25 -0800 (PST) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.21]) by ietfa.amsl.com (Postfix) with ESMTP id 275451ADEDC for ; Mon, 13 Jan 2014 04:59:25 -0800 (PST) Received: from CASUMHUB03.citservers.local (172.16.98.219) by smtpedge.partnerhosted.com (172.16.98.248) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 13 Jan 2014 04:59:31 -0800 Received: from MBX08.citservers.local ([fe80::2564:652:8dc8:caae]) by CASUMHUB03.citservers.local ([::1]) with mapi id 14.02.0247.003; Mon, 13 Jan 2014 04:59:30 -0800 From: Brett Tate To: "draft-ietf-httpauth-digest-update@tools.ietf.org" , "http-auth@ietf.org" Thread-Topic: draft-ietf-httpauth-digest-update-05: quoting issues Thread-Index: Ac8QXz/O5FhuqUoaTK2IsuZ+v25+YQ== Date: Mon, 13 Jan 2014 12:59:29 +0000 Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B881A06FAE1@MBX08.citservers.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.98.77] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [http-auth] draft-ietf-httpauth-digest-update-05: quoting issues X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 12:59:26 -0000 Hi, Concerning draft-ietf-httpauth-digest-update-05, the section 3.5 examples h= ave some quoting issues. - The algorithm values within the examples should not be within quotes. - The qop values within Authorization examples should not be within quotes. Thanks, Brett This email is intended solely for the person or entity to which it is addre= ssed and may contain confidential and/or privileged information. If you are= not the intended recipient and have received this email in error, please n= otify BroadSoft, Inc. immediately by replying to this message, and destroy = all copies of this message, along with any attachment, prior to reading, di= stributing or copying it. From julian.reschke@gmx.de Mon Jan 13 05:14:12 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D55FE1AE156 for ; Mon, 13 Jan 2014 05:14:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTJdoXAoakoJ for ; Mon, 13 Jan 2014 05:14:11 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 207CF1ADEDC for ; Mon, 13 Jan 2014 05:14:11 -0800 (PST) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0Lu7a2-1VL0Hh1T66-011VKn for ; Mon, 13 Jan 2014 14:13:59 +0100 Message-ID: <52D3E692.9030101@gmx.de> Date: Mon, 13 Jan 2014 14:13:54 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Brett Tate , "draft-ietf-httpauth-digest@tools.ietf.org" , "http-auth@ietf.org" References: <576A8B541C219D4E9CEB1DF8C19C7B881A06FA9F@MBX08.citservers.local> In-Reply-To: <576A8B541C219D4E9CEB1DF8C19C7B881A06FA9F@MBX08.citservers.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:sdRlDHKAvM3QNwxK0yh3vLQlf3ft1Sa0oI+bVIxvjPE5ZVhTpVp Hn51FlwOkbY00K/hsMcmLEupxYrTO9PJqb+qhC2Kqpb4yXL954uHkeQeoQsP9oy7oW1PBrb C7OZ+D/K8cNRyZRymvUJabz0vSnHOeO7cUj5toRAyaXm6hNFrc3X5dn8gPL7rqrcrfpjNVl kkEB9Lr6C7Dhwjrba653w== Subject: Re: [http-auth] draft-ietf-httpauth-digest-01: realm missing quotes X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 13:14:13 -0000 On 2014-01-13 12:53, Brett Tate wrote: > Hi, > > Concerning draft-ietf-httpauth-digest-01 section 3.4.5 example, the realm value should be within quotes: realm="myhost@testrealm.com". > > Thanks, > Brett Nope. First of all, the Digest spec shouldn't try to have an ABNF for the "Digest" challenge *at all*. The format for that header field is defined in : auth-scheme = token auth-param = token BWS "=" BWS ( token / quoted-string ) token68 = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" ) *"=" challenge = auth-scheme [ 1*SP ( token68 / #auth-param ) ] What the spec should define is the set of defined auth-params. The generic ABNF allows both "token" and "quoted-string" values, and this should be the default for all new parameters. For existing parameters, when it is known that certain syntax variants are not (yet?) interoperable, it should just state that in prose. Best regards, Julian From brett@broadsoft.com Mon Jan 13 06:02:48 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF181AE148 for ; Mon, 13 Jan 2014 06:02:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XQ745pmPVNAr for ; Mon, 13 Jan 2014 06:02:47 -0800 (PST) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.21]) by ietfa.amsl.com (Postfix) with ESMTP id 536191AE115 for ; Mon, 13 Jan 2014 06:02:47 -0800 (PST) Received: from CASUMHUB05.citservers.local (172.16.98.229) by smtpedge.partnerhosted.com (172.16.98.248) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 13 Jan 2014 06:02:55 -0800 Received: from MBX08.citservers.local ([fe80::2564:652:8dc8:caae]) by casumhub05.citservers.local ([::1]) with mapi id 14.02.0247.003; Mon, 13 Jan 2014 06:02:50 -0800 From: Brett Tate To: Julian Reschke , "draft-ietf-httpauth-digest@tools.ietf.org" , "http-auth@ietf.org" Thread-Topic: [http-auth] draft-ietf-httpauth-digest-01: realm missing quotes Thread-Index: AQHPEGF6Qc37n62GLEup/LixR/9md5qCoqJg Date: Mon, 13 Jan 2014 14:02:46 +0000 Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B881A06FB0E@MBX08.citservers.local> References: <576A8B541C219D4E9CEB1DF8C19C7B881A06FA9F@MBX08.citservers.local> <52D3E692.9030101@gmx.de> In-Reply-To: <52D3E692.9030101@gmx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.98.77] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [http-auth] draft-ietf-httpauth-digest-01: realm missing quotes X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 14:02:48 -0000 > > Concerning draft-ietf-httpauth-digest-01 section=20 > > 3.4.5 example, the realm value should be within=20 > > quotes: realm=3D"myhost@testrealm.com". >=20 > Nope. >=20 > First of all, the Digest spec shouldn't try to have=20 > an ABNF for the "Digest" challenge *at all*.=20 My comment was based upon the ABNF within draft-ietf-httpauth-digest-01 sec= tion 1. realm =3D "realm" "=3D" realm-value realm-value =3D quoted-string If the ABNF changes and there is no reason to show the example as backward = compatible with RFC 2617 (Errata ID 3720 reported same issue), then I agree= that the example does not need modification. Thanks, Brett From julian.reschke@gmx.de Mon Jan 13 06:22:19 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 883681ACCDF for ; Mon, 13 Jan 2014 06:22:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRszn_w-Jml9 for ; Mon, 13 Jan 2014 06:22:18 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id D11791ACCE6 for ; Mon, 13 Jan 2014 06:22:17 -0800 (PST) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MNIAz-1W0EUu3lUn-006zbx for ; Mon, 13 Jan 2014 15:22:06 +0100 Message-ID: <52D3F68B.2020706@gmx.de> Date: Mon, 13 Jan 2014 15:22:03 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Brett Tate , "draft-ietf-httpauth-digest@tools.ietf.org" , "http-auth@ietf.org" References: <576A8B541C219D4E9CEB1DF8C19C7B881A06FA9F@MBX08.citservers.local> <52D3E692.9030101@gmx.de> <576A8B541C219D4E9CEB1DF8C19C7B881A06FB0E@MBX08.citservers.local> In-Reply-To: <576A8B541C219D4E9CEB1DF8C19C7B881A06FB0E@MBX08.citservers.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:7mcj0Y1n0Ju6tbeUzzloBXvT0C2rWGWgwxhn4vNfwWO+YPFetLn J/fl2gUeQbQSve19ajzpTDCee4vzQKU9WQin1yMljF++TLrHolPn7urt3bYvPziKur1Ew9U vq55/EkDFtJfSIMlfpmvNpytwjrzaOX4CRUAaY5HuJIorgHzaiPbj62wDo1WyTpjzSBzReM pDl2wdGqaY+dQUJVeSAOw== Subject: Re: [http-auth] draft-ietf-httpauth-digest-01: realm missing quotes X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 14:22:19 -0000 On 2014-01-13 15:02, Brett Tate wrote: >>> Concerning draft-ietf-httpauth-digest-01 section >>> 3.4.5 example, the realm value should be within >>> quotes: realm="myhost@testrealm.com". >> >> Nope. >> >> First of all, the Digest spec shouldn't try to have >> an ABNF for the "Digest" challenge *at all*. > > My comment was based upon the ABNF within draft-ietf-httpauth-digest-01 section 1. > > realm = "realm" "=" realm-value > realm-value = quoted-string > > If the ABNF changes and there is no reason to show the example as backward compatible with RFC 2617 (Errata ID 3720 reported same issue), then I agree that the example does not need modification. The ABNF needs to change; any update to RFC 2617 needs to conform to the requirements in . Best regards, Julian From rifaat.ietf@gmail.com Mon Jan 13 06:33:26 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB381ADF92 for ; Mon, 13 Jan 2014 06:33:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lpp-UTPGwhNb for ; Mon, 13 Jan 2014 06:33:24 -0800 (PST) Received: from mail-ea0-x22d.google.com (mail-ea0-x22d.google.com [IPv6:2a00:1450:4013:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 9394C1ADFB6 for ; Mon, 13 Jan 2014 06:33:24 -0800 (PST) Received: by mail-ea0-f173.google.com with SMTP id o10so3303063eaj.18 for ; Mon, 13 Jan 2014 06:33:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=coX/CTZblJzPKniyrO17S1JCQ+DnpaswFFhwdVtrkfw=; b=h4JuRuhznhtcO1uv7W92b5y/1jSebJi9W7QYeyZUw/E2ot45oJSZ1FnS7JyUSqRAaE LmnNKUJlQ+WAyguOA4BdzdPJy4lBo0vhofrMx+RcOM6KS+BlNqNDBMN2WWpm/Pd1heXv OKHJ9ds5I4+8RHuGdM+QheMVHDYwyN1XxQNyeNGr1+Tp809k01A13EAp8DMPYXwBStux /DRDwNMlWkWLyzfoMnT5pLF+JkQUfYHKbMfRZkG8ykHZSZsqmgHGJk7/Lt0ke/HMVV/B WwWaVQMnE18wkDOrWNrZoDkJnUalKHUqVGQN/UCeWHBlWsQRVQFzvmmeXpGHpFaFPJ3p SnjQ== MIME-Version: 1.0 X-Received: by 10.14.122.5 with SMTP id s5mr28049052eeh.28.1389623591285; Mon, 13 Jan 2014 06:33:11 -0800 (PST) Received: by 10.14.53.78 with HTTP; Mon, 13 Jan 2014 06:33:11 -0800 (PST) In-Reply-To: <52D3F68B.2020706@gmx.de> References: <576A8B541C219D4E9CEB1DF8C19C7B881A06FA9F@MBX08.citservers.local> <52D3E692.9030101@gmx.de> <576A8B541C219D4E9CEB1DF8C19C7B881A06FB0E@MBX08.citservers.local> <52D3F68B.2020706@gmx.de> Date: Mon, 13 Jan 2014 09:33:11 -0500 Message-ID: From: Rifaat Shekh-Yusef To: Julian Reschke Content-Type: multipart/alternative; boundary=001a11c1b83887ba4004efdaf4e6 Cc: "http-auth@ietf.org" , "draft-ietf-httpauth-digest@tools.ietf.org" Subject: Re: [http-auth] draft-ietf-httpauth-digest-01: realm missing quotes X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 14:33:26 -0000 --001a11c1b83887ba4004efdaf4e6 Content-Type: text/plain; charset=ISO-8859-1 Thanks Julian, The ABNF in the draft was copied from RFC2617. I will fix it in the next version of the draft. Regards, Rifaat On Mon, Jan 13, 2014 at 9:22 AM, Julian Reschke wrote: > On 2014-01-13 15:02, Brett Tate wrote: > >> Concerning draft-ietf-httpauth-digest-01 section >>>> 3.4.5 example, the realm value should be within >>>> quotes: realm="myhost@testrealm.com". >>>> >>> >>> Nope. >>> >>> First of all, the Digest spec shouldn't try to have >>> an ABNF for the "Digest" challenge *at all*. >>> >> >> My comment was based upon the ABNF within draft-ietf-httpauth-digest-01 >> section 1. >> >> realm = "realm" "=" realm-value >> realm-value = quoted-string >> >> If the ABNF changes and there is no reason to show the example as >> backward compatible with RFC 2617 (Errata ID 3720 reported same issue), >> then I agree that the example does not need modification. >> > > The ABNF needs to change; any update to RFC 2617 needs to conform to the > requirements in auth-25.html#considerations.for.new.authentication.schemes>. > > Best regards, Julian > > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > --001a11c1b83887ba4004efdaf4e6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks Julian,

The ABNF in the draft wa= s copied from RFC2617. I will fix it in the next version of the draft.

Regards,
=A0Rifaat



On Mon, Jan 1= 3, 2014 at 9:22 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
On 2014-01-13 15:02, Brett= Tate wrote:
Concerning draft-ietf-httpauth-digest-01 section
3.4.5 example, the realm value should be within
quotes: realm=3D"myhost@testrealm.com".

Nope.

First of all, the Digest spec shouldn't try to have
an ABNF for the "Digest" challenge *at all*.

My comment was based upon the ABNF within draft-ietf-httpauth-digest-01 sec= tion 1.

=A0 =A0 realm =A0 =A0 =A0 =3D "realm" "=3D" realm-value=
=A0 =A0 realm-value =3D quoted-string

If the ABNF changes and there is no reason to show the example as backward = compatible with RFC 2617 (Errata ID 3720 reported same issue), then I agree= that the example does not need modification.

The ABNF needs to change; any update to RFC 2617 needs to conform to the re= quirements in <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p7-<= u>auth-25.html#considerations.for.new.authentication.schemes= >.

Best regards, Julian


_______________________________________________
http-auth mailing list
http-auth@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/http-auth

--001a11c1b83887ba4004efdaf4e6-- From rifaat.ietf@gmail.com Mon Jan 13 06:34:56 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D60051AE11B for ; Mon, 13 Jan 2014 06:34:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z977mIaomyBT for ; Mon, 13 Jan 2014 06:34:55 -0800 (PST) Received: from mail-ea0-x235.google.com (mail-ea0-x235.google.com [IPv6:2a00:1450:4013:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6221ADFB6 for ; Mon, 13 Jan 2014 06:34:51 -0800 (PST) Received: by mail-ea0-f181.google.com with SMTP id m10so3383926eaj.12 for ; Mon, 13 Jan 2014 06:34:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GP1a6IElvL0kEd1ei/TbOXFnZhjqmBSE+bL0JWKfZAo=; b=PJejyUivp82y7NpQyJFQg4OL5vj0lBY/UXszZ7mMt7cVHXQEmKuWx22L4DiNLVswM9 jS33FJTs2iZToF38bFz5yLHaLvJ5HAugyctnMBV3ymf6grq6Wgsn4T3dnPt4THzenwaY vkaHfA4t5rUzdtxxfaTKSd8vC3y7e5S2HARwogV78gf6VIzQo9VctjHW1zJwr09duihF 1crSyw8TdhxyVhVg9Q4Ff96zCHhQgQH7UCQUr5xlIkbpFpPgfL58ZPW6oBPVdnk/e2QF YT3T15Ot8QxWylehT/lDKrLX3i/iF0+lQcnkh8n89LClnKDuOImkBBM6wMn+3/wvUTQB tliA== MIME-Version: 1.0 X-Received: by 10.14.122.5 with SMTP id s5mr28056639eeh.28.1389623679749; Mon, 13 Jan 2014 06:34:39 -0800 (PST) Received: by 10.14.53.78 with HTTP; Mon, 13 Jan 2014 06:34:39 -0800 (PST) In-Reply-To: <576A8B541C219D4E9CEB1DF8C19C7B881A06FAE1@MBX08.citservers.local> References: <576A8B541C219D4E9CEB1DF8C19C7B881A06FAE1@MBX08.citservers.local> Date: Mon, 13 Jan 2014 09:34:39 -0500 Message-ID: From: Rifaat Shekh-Yusef To: Brett Tate Content-Type: multipart/alternative; boundary=001a11c1b838cd942e04efdaf93c Cc: "http-auth@ietf.org" , "draft-ietf-httpauth-digest-update@tools.ietf.org" Subject: Re: [http-auth] draft-ietf-httpauth-digest-update-05: quoting issues X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 14:34:57 -0000 --001a11c1b838cd942e04efdaf93c Content-Type: text/plain; charset=ISO-8859-1 Thanks Brett, This draft was obsoleted by the following draft: https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ Regards, Rifaat On Mon, Jan 13, 2014 at 7:59 AM, Brett Tate wrote: > Hi, > > Concerning draft-ietf-httpauth-digest-update-05, the section 3.5 examples > have some quoting issues. > > - The algorithm values within the examples should not be within quotes. > > - The qop values within Authorization examples should not be within quotes. > > Thanks, > Brett > > This email is intended solely for the person or entity to which it is > addressed and may contain confidential and/or privileged information. If > you are not the intended recipient and have received this email in error, > please notify BroadSoft, Inc. immediately by replying to this message, and > destroy all copies of this message, along with any attachment, prior to > reading, distributing or copying it. > --001a11c1b838cd942e04efdaf93c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks Brett,

This draft was obsoleted = by the following draft:

Regards,
=A0Rifaat

=


On Mon,= Jan 13, 2014 at 7:59 AM, Brett Tate <brett@broadsoft.com>= wrote:
Hi,

Concerning draft-ietf-httpauth-digest-update-05, the section 3.5 examples h= ave some quoting issues.

- The algorithm values within the examples should not be within quotes.

- The qop values within Authorization examples should not be within quotes.=

Thanks,
Brett

This email is intended solely for the person or entity to which it is addre= ssed and may contain confidential and/or privileged information. If you are= not the intended recipient and have received this email in error, please n= otify BroadSoft, Inc. immediately by replying to this message, and destroy = all copies of this message, along with any attachment, prior to reading, di= stributing or copying it.

--001a11c1b838cd942e04efdaf93c-- From brett@broadsoft.com Mon Jan 13 06:41:25 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 725AE1AE190 for ; Mon, 13 Jan 2014 06:41:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iz3xT7ZeU23r for ; Mon, 13 Jan 2014 06:41:23 -0800 (PST) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.203]) by ietfa.amsl.com (Postfix) with ESMTP id B0FB01AE09C for ; Mon, 13 Jan 2014 06:41:23 -0800 (PST) Received: from CASUMHUB04.citservers.local (172.16.98.225) by smtpedge.partnerhosted.com (172.16.98.247) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 13 Jan 2014 06:41:31 -0800 Received: from MBX08.citservers.local ([fe80::2564:652:8dc8:caae]) by CASUMHUB04.citservers.local ([::1]) with mapi id 14.02.0247.003; Mon, 13 Jan 2014 06:41:31 -0800 From: Brett Tate To: Julian Reschke , "draft-ietf-httpauth-digest@tools.ietf.org" , "http-auth@ietf.org" Thread-Topic: [http-auth] draft-ietf-httpauth-digest-01: realm missing quotes Thread-Index: AQHPEGryF7mlwv+HO0CCbr7kRG95PJqCtuFQ Date: Mon, 13 Jan 2014 14:41:31 +0000 Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B881A06FB35@MBX08.citservers.local> References: <576A8B541C219D4E9CEB1DF8C19C7B881A06FA9F@MBX08.citservers.local> <52D3E692.9030101@gmx.de> <576A8B541C219D4E9CEB1DF8C19C7B881A06FB0E@MBX08.citservers.local> <52D3F68B.2020706@gmx.de> In-Reply-To: <52D3F68B.2020706@gmx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.98.77] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [http-auth] draft-ietf-httpauth-digest-01: realm missing quotes X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2014 14:41:25 -0000 > >>> Concerning draft-ietf-httpauth-digest-01 section > >>> 3.4.5 example, the realm value should be within > >>> quotes: realm=3D"myhost@testrealm.com". > >> > >> Nope. > >> > >> First of all, the Digest spec shouldn't try to have > >> an ABNF for the "Digest" challenge *at all*. > > > > My comment was based upon the ABNF within draft-ietf-httpauth-digest- > 01 section 1. > > > > realm =3D "realm" "=3D" realm-value > > realm-value =3D quoted-string > > > > If the ABNF changes and there is no reason to show the example as > backward compatible with RFC 2617 (Errata ID 3720 reported same issue), > then I agree that the example does not need modification. >=20 > The ABNF needs to change; any update to RFC 2617 needs to conform to > the > requirements in > 25.html#considerations.for.new.authentication.schemes>. Based upon draft-ietf-httpbis-p7-auth-25 section 2.2 Protection Space (Real= m), the example does not appear compliant to the following MUST. "For historical reasons, a sender MUST only generate the quoted-string synt= ax." Thanks, Brett From internet-drafts@ietf.org Sat Jan 18 05:27:14 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B45C1ACCEB; Sat, 18 Jan 2014 05:27:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWYGceX7rOxW; Sat, 18 Jan 2014 05:27:13 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1681C1AC421; Sat, 18 Jan 2014 05:27:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140118132712.27418.53563.idtracker@ietfa.amsl.com> Date: Sat, 18 Jan 2014 05:27:12 -0800 Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-digest-02.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2014 13:27:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Hypertext Transfer Protocol Authenticatio= n Working Group of the IETF. Title : HTTP Digest Access Authentication Authors : Rifaat Shekh-Yusef David Ahrens Sophie Bremer Filename : draft-ietf-httpauth-digest-02.txt Pages : 28 Date : 2014-01-18 Abstract: HTTP provides a simple challenge-response authentication mechanism that may be used by a server to challenge a client request and by a client to provide authentication information. This document defines the HTTP Digest Authentication scheme that may be used with the authentication mechanism. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-httpauth-digest-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-httpauth-digest-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rifaat.ietf@gmail.com Sat Jan 18 05:30:53 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B1E61ACCEC; Sat, 18 Jan 2014 05:30:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfV8o1HuYkF5; Sat, 18 Jan 2014 05:30:51 -0800 (PST) Received: from mail-ee0-x235.google.com (mail-ee0-x235.google.com [IPv6:2a00:1450:4013:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB111ACCE5; Sat, 18 Jan 2014 05:30:51 -0800 (PST) Received: by mail-ee0-f53.google.com with SMTP id t10so2557324eei.26 for ; Sat, 18 Jan 2014 05:30:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=E0e3gIJOcyaB/7tRgTcWVa0ozRTy9Ip7X3hcL/ZM3aA=; b=Oxrjrq0czkBYoc2tE9ieqMu5d5raYS2bvPy2uXT/l7PzO1iixoCzM+EvKf4ijdXt9h K6ee12rR1mFjP98ysXnWqttq69FnIJ3nfWeBqMQRdumjy+kJOS6ReI/19cnD85PvN2YL OfkVnWzO0cLGeix16iG8PlTwGmtGhNJxbOSRX/ZwPjBvNfJnFRlUdNLt1fgKZU0wF+w2 8/Vy2H3s+XuEvwXuI7SrakaMPGASJxzreLo/X8QbCscm4J/6Vjv5EHobYP/oo12yjm7j jDiPkVJg5bhpx//dKHA1CQxR7HAJdJPW6C+AXqyPgCvrmYfccvqXFjiHvWkms8zgICjB 8JQA== MIME-Version: 1.0 X-Received: by 10.15.43.10 with SMTP id w10mr8110101eev.13.1390051838018; Sat, 18 Jan 2014 05:30:38 -0800 (PST) Received: by 10.14.53.78 with HTTP; Sat, 18 Jan 2014 05:30:37 -0800 (PST) In-Reply-To: <20140118132712.27418.53563.idtracker@ietfa.amsl.com> References: <20140118132712.27418.53563.idtracker@ietfa.amsl.com> Date: Sat, 18 Jan 2014 08:30:37 -0500 Message-ID: From: Rifaat Shekh-Yusef To: internet-drafts@ietf.org Content-Type: multipart/alternative; boundary=089e0168164406487404f03eaa37 Cc: "http-auth@ietf.org" , i-d-announce@ietf.org Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-02.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2014 13:30:53 -0000 --089e0168164406487404f03eaa37 Content-Type: text/plain; charset=ISO-8859-1 Hi, With this new version, I think that I have addressed all the comments that I received on the mailing list. I also made some changes to the IANA registry section. Please, let us know if you have any comments. Regards, Rifaat On Sat, Jan 18, 2014 at 8:27 AM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Hypertext Transfer Protocol > Authentication Working Group of the IETF. > > Title : HTTP Digest Access Authentication > Authors : Rifaat Shekh-Yusef > David Ahrens > Sophie Bremer > Filename : draft-ietf-httpauth-digest-02.txt > Pages : 28 > Date : 2014-01-18 > > Abstract: > HTTP provides a simple challenge-response authentication mechanism > that may be used by a server to challenge a client request and by a > client to provide authentication information. This document defines > the HTTP Digest Authentication scheme that may be used with the > authentication mechanism. > > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-httpauth-digest-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-digest-02 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > --089e0168164406487404f03eaa37 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

With this new version, I think that= I have addressed all the comments that I received on the mailing list.
I also made some changes to the IANA registry section.
Please, let us know if you have any comments.

Regards,
=A0Rifaat



On Sat, Jan 18, 2014 at 8:= 27 AM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0This draft is a work item of the Hypertext Transfer Protocol Authenticat= ion Working Group of the IETF.

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : HTTP Digest Access Authenticati= on
=A0 =A0 =A0 =A0 Authors =A0 =A0 =A0 =A0 : Rifaat Shekh-Yusef
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 David Ahrens
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Sophie Bremer
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-httpauth-digest-02.txt=
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 28
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2014-01-18

Abstract:
=A0 =A0HTTP provides a simple challenge-response authentication mechanism =A0 =A0that may be used by a server to challenge a client request and by a<= br> =A0 =A0client to provide authentication information. This document defines<= br> =A0 =A0the HTTP Digest Authentication scheme that may be used with the
=A0 =A0authentication mechanism.




The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest= /

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-httpauth-digest-02
A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-httpauth-= digest-02


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
http-auth mailing list
http-auth@ietf.org
https://www.ietf.org/mailman/listinfo/http-auth

--089e0168164406487404f03eaa37-- From julian.reschke@gmx.de Sat Jan 18 07:35:05 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B20E1ADF4F for ; Sat, 18 Jan 2014 07:35:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LMO7tnt4jHAU for ; Sat, 18 Jan 2014 07:35:03 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 974761ADF46 for ; Sat, 18 Jan 2014 07:35:03 -0800 (PST) Received: from [192.168.2.117] ([84.187.53.93]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MYcJi-1Vqsgt2tVa-00VTv0 for ; Sat, 18 Jan 2014 16:34:50 +0100 Message-ID: <52DA9F13.6050908@gmx.de> Date: Sat, 18 Jan 2014 16:34:43 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Rifaat Shekh-Yusef , internet-drafts@ietf.org References: <20140118132712.27418.53563.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:tJDCvHnUQXPNG2Ig3XxGznJR5x08vGC7L0Gw1zf9AwOoc2X4Z60 ouV+Tkqr/zlq4Av9gWVlH7J65D9pT7kNPgCaDHXkZafuYMFrapqVYWl7OZFxaBO64LrcYdQ iLz2hjGt2GS9orOpSeSF5gpfQNXqFwF3Ojtm4e4OMXtqIuBh5OPGf1VbBDhWSb6d8i65edw EsTOInN3OcSoSeGOaKa9A== Cc: "http-auth@ietf.org" , i-d-announce@ietf.org Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-02.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2014 15:35:05 -0000 On 2014-01-18 14:30, Rifaat Shekh-Yusef wrote: > Hi, > > With this new version, I think that I have addressed all the comments > that I received on the mailing list. > I also made some changes to the IANA registry section. > > Please, let us know if you have any comments. > > Regards, > Rifaat 1) Again: there shouldn't be an ABNF for challenge or credentials. The syntax is fully defined by HTTPbis, Part 7. What you should define is the set of individual auth-params defined in challenges and credentials. 2) There shouldn't be any references to 2616 (or 2617) except for discussions of history. 3) Your reference section is empty. 4) In the IANA considerations, the registration of the scheme in the auth scheme registry is missing. Best regards, Julian From rifaat.ietf@gmail.com Sat Jan 18 12:18:29 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47B651ADFA1; Sat, 18 Jan 2014 12:18:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BheGrcc4AhLB; Sat, 18 Jan 2014 12:18:27 -0800 (PST) Received: from mail-ea0-x236.google.com (mail-ea0-x236.google.com [IPv6:2a00:1450:4013:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 05BB81ADFA4; Sat, 18 Jan 2014 12:18:26 -0800 (PST) Received: by mail-ea0-f182.google.com with SMTP id r15so1499185ead.41 for ; Sat, 18 Jan 2014 12:18:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=F2/lRQt9Sf2T5HXIdxxuPvgIw53HT3n3SI1MDsWBcVM=; b=peoM02KsPi/QAuj2A9xaeJ8qn6RbvtCmiklr4NqyIl1b1Dmw08wkAKQ5H/nSZqFHpR an37ghS7W0Q+UlVKlCE8C4wiXRGZegQNW5ZnGB8ZZqbggZAn5Aj6BR/UMO3vQn/AegsD irvTEqRPnwJH0yYO+Y+qirEVSaQReHQMxUaIMbPle8LyCCL/BtRWO+MKpFsJSo7WV+BW lYg6ZsOq+0yKT5MGtLcH10ZNGhfnWCLk3HgSNmzkuPdOOXfObyxNLqpQWc6/0Q5xKilX RKQW4u9FYQVZHHxIGxt0h0Lhkzh4l3pXXQeL5CjS7LZc9qR57Q9U6LWCh3QU5LujGsNG d43w== MIME-Version: 1.0 X-Received: by 10.14.148.138 with SMTP id v10mr9390430eej.37.1390076293658; Sat, 18 Jan 2014 12:18:13 -0800 (PST) Received: by 10.14.53.78 with HTTP; Sat, 18 Jan 2014 12:18:13 -0800 (PST) In-Reply-To: <52DA9F13.6050908@gmx.de> References: <20140118132712.27418.53563.idtracker@ietfa.amsl.com> <52DA9F13.6050908@gmx.de> Date: Sat, 18 Jan 2014 15:18:13 -0500 Message-ID: From: Rifaat Shekh-Yusef To: Julian Reschke Content-Type: multipart/alternative; boundary=089e0160cdb4b1bd3904f0445b0f Cc: "http-auth@ietf.org" , internet-drafts@ietf.org, i-d-announce@ietf.org Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-02.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2014 20:18:29 -0000 --089e0160cdb4b1bd3904f0445b0f Content-Type: text/plain; charset=ISO-8859-1 On Sat, Jan 18, 2014 at 10:34 AM, Julian Reschke wrote: > On 2014-01-18 14:30, Rifaat Shekh-Yusef wrote: > >> Hi, >> >> With this new version, I think that I have addressed all the comments >> that I received on the mailing list. >> I also made some changes to the IANA registry section. >> >> Please, let us know if you have any comments. >> >> Regards, >> Rifaat >> > > 1) Again: there shouldn't be an ABNF for challenge or credentials. > > The syntax is fully defined by HTTPbis, Part 7. > > What you should define is the set of individual auth-params defined in > challenges and credentials. > > Just to make sure I understand your point, what you are looking for is, for example, to replace what I have in section 3.3 with the following auth-scheme = "Digest" domain = "domain" "=" <"> URI ( 1*SP URI ) <"> URI = absoluteURI | abs_path nonce = "nonce" "=" nonce-value nonce-value = quoted-string opaque = "opaque" "=" quoted-string stale = "stale" "=" ( "true" | "false" ) algorithm = "algorithm" "=" ( "MD5" | "MD5-sess" | "SHA2-256" | "SHA2-256-sess" | "SHA2-512-256" | "SHA2-512-256-sess" | token) qop-options = "qop" "=" <"> 1#qop-value <"> qop-value = "auth" | "auth-int" | token charset = "charset" "=" ("UTF-8" | token) userhash = "userhash" "=" ( "true" | "false" ) Is that correct? > 2) There shouldn't be any references to 2616 (or 2617) except for > discussions of history. > > 3) Your reference section is empty. > > 4) In the IANA considerations, the registration of the scheme in the auth > scheme registry is missing. > > > Best regards, Julian > > --089e0160cdb4b1bd3904f0445b0f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sat, Jan 18, 2014 at 10:34 AM, Julian Reschke = <julian.resch= ke@gmx.de> wrote:
On 2014-01-18 14:30, Rifaat Shekh-Yusef = wrote:
Hi,

With this new version, I think that I have addressed all the comments
that I received on the mailing list.
I also made some changes to the IANA registry section.

Please, let us know if you have any comments.

Regards,
=A0 Rifaat

1) Again: there shouldn't be an ABNF for challenge or credentials.

The syntax is fully defined by HTTPbis, Part 7.

What you should define is the set of individual auth-params defined in chal= lenges and credentials.


Just to make sure I understand your po= int, what you are looking for is, for example, to replace what I have in se= ction 3.3 with the following

=A0 =A0 =A0 auth= -scheme =A0 =A0=3D =A0"Digest"

=A0 =A0 =A0 domain =A0 =A0 =A0 =A0 =A0 =A0=3D "dom= ain" "=3D" <"> URI ( 1*SP URI ) <">
=A0 =A0 =A0 URI =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D absoluteURI= | abs_path
=A0 =A0 =A0 nonce =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D &quo= t;nonce" "=3D" nonce-value
=A0 =A0 =A0 nonce-value =A0 =A0 =A0=3D quoted-string
=A0 =A0= =A0 opaque =A0 =A0 =A0 =A0 =A0 =A0=3D "opaque" "=3D" q= uoted-string
=A0 =A0 =A0 stale =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D &q= uot;stale" "=3D" ( "true" | "false" )
=A0 =A0 =A0 algorithm =A0 =A0 =A0 =A0 =3D "algorithm" "= =3D" (
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 &= quot;MD5" | "MD5-sess" |
=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 "SHA2-256" | "SHA2-256-sess"= ; |
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "SHA2-512-256= " | "SHA2-512-256-sess" |=A0
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 token)
=A0 =A0 =A0 qop-options = =A0 =A0=3D "qop" "=3D" <"> 1#qop-value <&= quot;>
=A0 =A0 =A0 qop-value =A0 =A0 =A0 =3D "auth" | "auth-in= t" | token
=A0 =A0 =A0 charset =A0 =A0 =A0 =A0 =A0=3D "= charset" "=3D" ("UTF-8" | token)
=A0 =A0= =A0 userhash =A0 =A0 =A0 =3D "userhash" "=3D" ( "= true" | "false" )


Is that correct?



=A0
2) There shouldn't be any references to 2616 (or 2617) except for discu= ssions of history.

3) Your reference section is empty.

4) In the IANA considerations, the registration of the scheme in the auth s= cheme registry is missing.


Best regards, Julian


--089e0160cdb4b1bd3904f0445b0f-- From daniel@haxx.se Sat Jan 18 13:24:01 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D19271ADFC0 for ; Sat, 18 Jan 2014 13:24:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJ0ZDR_UDyG6 for ; Sat, 18 Jan 2014 13:23:59 -0800 (PST) Received: from giant.haxx.se (www.haxx.se [IPv6:2a00:1a28:1200:9::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB801ADFBF for ; Sat, 18 Jan 2014 13:23:58 -0800 (PST) Received: from giant.haxx.se (dast@localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-4.1) with ESMTP id s0ILNfve028096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 18 Jan 2014 22:23:41 +0100 Received: from localhost (dast@localhost) by giant.haxx.se (8.14.4/8.14.4/Submit) with ESMTP id s0ILNen5028084; Sat, 18 Jan 2014 22:23:41 +0100 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Sat, 18 Jan 2014 22:23:40 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: Rifaat Shekh-Yusef In-Reply-To: Message-ID: References: <20140118132712.27418.53563.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-02.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2014 21:24:02 -0000 On Sat, 18 Jan 2014, Rifaat Shekh-Yusef wrote: > Please, let us know if you have any comments. I have a question about chapter 4: If the user agent does not support the encoding indicated by the server, it MAY add the "charset" parameter to the Proxy-Authenticate or WWW-Authenticate header fields it sends back to the server, but the value in the parameter should be preceded by an exclamation point (!). What's the purpose of the exclamation point? Surely a server will have to check the charset if it is supported no matter if this symbol is there or not? I don't see how it helps anyone. -- / daniel.haxx.se From rifaat.ietf@gmail.com Sat Jan 18 13:56:50 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 235B41ADFCB for ; Sat, 18 Jan 2014 13:56:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LErpk-1BUWPR for ; Sat, 18 Jan 2014 13:56:48 -0800 (PST) Received: from mail-ee0-x22e.google.com (mail-ee0-x22e.google.com [IPv6:2a00:1450:4013:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id C7B7F1ADFD1 for ; Sat, 18 Jan 2014 13:56:47 -0800 (PST) Received: by mail-ee0-f46.google.com with SMTP id c13so2638839eek.19 for ; Sat, 18 Jan 2014 13:56:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=84GJqE/CPuGv3qS71b3FPoVyZOVHy8jonyKmLD3Cios=; b=hue023vMhfqQgVDUY5bIiW+pHJ5f1VkPhJGEdijQA3RomL9cx/u7Kja0O5J7aUIJaN +zs+4FLRygbKjc6kIA+F6djca7LvFYD+R2Edk6YYloBaH25vU6fwnvTNPmr28zkz/+5Y R4K+qfC7fr89T+Uqm4szxWOMxu54zxT+RDjG/rVXn8L3FYeA9g67dBc6lfOGsZuaTeqM tY6P99uWto6ivXDL5oyK9L+qoVR+kslpcvdgdAp2Lxfe6XA5CWxrquqt41MjE8sNEKAi faEKE5/7iRAKD15KBuBZui9KB29DK5KpQmE2A+1G3xUpfUdBRJAVE1ucTwJ53GnJQKzV iKnA== MIME-Version: 1.0 X-Received: by 10.15.49.193 with SMTP id j41mr9567328eew.10.1390082194406; Sat, 18 Jan 2014 13:56:34 -0800 (PST) Received: by 10.14.53.78 with HTTP; Sat, 18 Jan 2014 13:56:34 -0800 (PST) In-Reply-To: References: <20140118132712.27418.53563.idtracker@ietfa.amsl.com> Date: Sat, 18 Jan 2014 16:56:34 -0500 Message-ID: From: Rifaat Shekh-Yusef To: Daniel Stenberg Content-Type: multipart/alternative; boundary=001a11c34ad868017504f045bb75 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-02.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2014 21:56:50 -0000 --001a11c34ad868017504f045bb75 Content-Type: text/plain; charset=ISO-8859-1 It would allow the server to fail the request without any further processing, as it knows that the authentication will fail. Regards, Rifaat On Sat, Jan 18, 2014 at 4:23 PM, Daniel Stenberg wrote: > On Sat, 18 Jan 2014, Rifaat Shekh-Yusef wrote: > > Please, let us know if you have any comments. >> > > I have a question about chapter 4: > > If the user agent does not support the encoding indicated by the > server, it MAY add the "charset" parameter to the Proxy-Authenticate > or WWW-Authenticate header fields it sends back to the server, but > the value in the parameter should be preceded by an exclamation point > (!). > > What's the purpose of the exclamation point? Surely a server will have to > check the charset if it is supported no matter if this symbol is there or > not? I don't see how it helps anyone. > > -- > > / daniel.haxx.se > --001a11c34ad868017504f045bb75 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
It would allow the server to fail the request without any = further processing, as it knows that the authentication will fail.

=
Regards,
=A0Rifaat



On Sat, Jan 18, 2014 at 4:23 PM, Daniel = Stenberg <daniel@haxx.se> wrote:
On Sat, 18 Jan 2014, Rifaat Shekh-Yusef wrote:

Please, let us know if you have any comments.

I have a question about chapter 4:

=A0 =A0If the user agent does not support the encoding indicated by the
=A0 =A0server, it MAY add the "charset" parameter to the Proxy-Au= thenticate
=A0 =A0or WWW-Authenticate header fields it sends back to the server, but =A0 =A0the value in the parameter should be preceded by an exclamation poin= t
=A0 =A0(!).

What's the purpose of the exclamation point? Surely a server will have = to check the charset if it is supported no matter if this symbol is there o= r not? I don't see how it helps anyone.

--

=A0/ daniel.haxx.se=

--001a11c34ad868017504f045bb75-- From daniel@haxx.se Sat Jan 18 14:38:23 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 170561AD7C2 for ; Sat, 18 Jan 2014 14:38:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jO68zTPsaTrL for ; Sat, 18 Jan 2014 14:38:21 -0800 (PST) Received: from giant.haxx.se (www.haxx.se [IPv6:2a00:1a28:1200:9::2]) by ietfa.amsl.com (Postfix) with ESMTP id 284E41AD1F5 for ; Sat, 18 Jan 2014 14:38:20 -0800 (PST) Received: from giant.haxx.se (dast@localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-4.1) with ESMTP id s0IMc3Rb010330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 18 Jan 2014 23:38:03 +0100 Received: from localhost (dast@localhost) by giant.haxx.se (8.14.4/8.14.4/Submit) with ESMTP id s0IMc3gK010326; Sat, 18 Jan 2014 23:38:03 +0100 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Sat, 18 Jan 2014 23:38:03 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: Rifaat Shekh-Yusef In-Reply-To: Message-ID: References: <20140118132712.27418.53563.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-02.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2014 22:38:23 -0000 On Sat, 18 Jan 2014, Rifaat Shekh-Yusef wrote: > It would allow the server to fail the request without any further > processing, as it knows that the authentication will fail. Why would a client want to send a request that includes an instruction to the server to fail it? Also, you seem to imply then that a server will blindly accept the exclamation point and not check for itself that the charset is indeed not supported? -- / daniel.haxx.se From rifaat.ietf@gmail.com Sat Jan 18 14:50:17 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5151ADFDD for ; Sat, 18 Jan 2014 14:50:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4vRfc2lVBEv for ; Sat, 18 Jan 2014 14:50:15 -0800 (PST) Received: from mail-ea0-x22c.google.com (mail-ea0-x22c.google.com [IPv6:2a00:1450:4013:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8DA1ADFDC for ; Sat, 18 Jan 2014 14:50:15 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id g15so1814037eak.17 for ; Sat, 18 Jan 2014 14:50:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0ghcZ1QiOnINQCmlIe0cJeTRzv/6TZjPnxNrK9s390A=; b=VKjjoyUNfWWqb2DtQatL88TNgribEq1A6tm8d5iMjRm7a1fBCzkAl0Z+2kWyYRmCZE mdY40OrPTR3/NRUwMq9Q2L4gojb3PyWBR/dgrz7BWvd4OPjNt5oayOle+dFJvVuTtqrT tlEez1Dw1QdUPLv/7nA8buyOLJUuORa5O6sc2jdAGzTyfQUzZXc5IY/RQ7zY+4KbOw4V 3Bt1jNBXOj4yiXvpuIjqnboPdXzeHphXQewZAACFZqn8/3VD0+S81IqE6tjlouXOiZTN BtC7hYUMDAD/z40DvascOU1qlfQnuty/XEAItmKlKrWy8R5beEHmRVdbWIhCNvNefJiD oc9g== MIME-Version: 1.0 X-Received: by 10.14.108.6 with SMTP id p6mr9613296eeg.31.1390085402203; Sat, 18 Jan 2014 14:50:02 -0800 (PST) Received: by 10.14.53.78 with HTTP; Sat, 18 Jan 2014 14:50:02 -0800 (PST) In-Reply-To: References: <20140118132712.27418.53563.idtracker@ietfa.amsl.com> Date: Sat, 18 Jan 2014 17:50:02 -0500 Message-ID: From: Rifaat Shekh-Yusef To: Daniel Stenberg Content-Type: multipart/alternative; boundary=001a11c2926e9b18b904f0467a38 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-02.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2014 22:50:17 -0000 --001a11c2926e9b18b904f0467a38 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Jan 18, 2014 at 5:38 PM, Daniel Stenberg wrote: > On Sat, 18 Jan 2014, Rifaat Shekh-Yusef wrote: > > It would allow the server to fail the request without any further >> processing, as it knows that the authentication will fail. >> > > Why would a client want to send a request that includes an instruction to > the server to fail it? > > I see your point. How about changing the last paragraph to say: If the user agent does not support the encoding indicated by the server, the user agent MUST fail the request. Regards, Rifaat > Also, you seem to imply then that a server will blindly accept the > exclamation point and not check for itself that the charset is indeed not > supported? > > -- > > / daniel.haxx.se > --001a11c2926e9b18b904f0467a38 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sat, Jan 18, 2014 at 5:38 PM, Daniel Stenberg = <daniel@haxx.se&= gt; wrote:
On Sat, 18 Jan 2014, Rifaat Shekh-Yusef = wrote:

It would allow the server to fail the request without any further processin= g, as it knows that the authentication will fail.

Why would a client want to send a request that includes an instruction to t= he server to fail it?


I see your point. How about changing t= he last paragraph to say:

   If the user agen=
t does not support the encoding indicated by the server, the user agent MUS=
T fail the request.


Regards,=
=A0Rifaat
=A0
Also, you seem to imply then that a server will blindly accept the exclamat= ion point and not check for itself that the charset is indeed not supported= ?

--

=A0/ daniel.haxx.se=

--001a11c2926e9b18b904f0467a38-- From rifaat.ietf@gmail.com Sat Jan 18 14:55:52 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 149E51ADFDB for ; Sat, 18 Jan 2014 14:55:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmvp0tOCl7F1 for ; Sat, 18 Jan 2014 14:55:50 -0800 (PST) Received: from mail-ee0-x22a.google.com (mail-ee0-x22a.google.com [IPv6:2a00:1450:4013:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id D59C31AD1F5 for ; Sat, 18 Jan 2014 14:55:49 -0800 (PST) Received: by mail-ee0-f42.google.com with SMTP id e49so2718894eek.15 for ; Sat, 18 Jan 2014 14:55:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=d2FtElNcUyvWEym9ws7O/jDIzabofZ8v8voOCFfIh8Q=; b=jC0UgivfZkMKDkKbPDT7sauXl/Xa3Trlyd4I7FoAsa78fW5TZiGJeJLUcvXHmDvm1o V8L3cqp0QjUVf0Slg4kgJKmiPAi/s9Lm2B+yFUBtgya1RZsb36Jm/Ny1RU1yditDS/hb jY5o2kuGLxmHnOtTxzYVq04hjEKs6UJnS1HOQWZqIu/IL+sUO/aUDn3na+o920CkVTBM D/HngmFE+n6w06kIKA7ZisYSnlzewLQtRvK492fHeXkkpv2N1lp+gKL0h85vYj+3K6To bqknl2UPSFC/wjVmDKJRgmSKCEdLbdOccjy0Wz6uS9akzUqr0XLW6iiXR+sfQccbyVSr 6ykQ== MIME-Version: 1.0 X-Received: by 10.14.209.129 with SMTP id s1mr9817658eeo.21.1390085736498; Sat, 18 Jan 2014 14:55:36 -0800 (PST) Received: by 10.14.53.78 with HTTP; Sat, 18 Jan 2014 14:55:36 -0800 (PST) In-Reply-To: References: <20140118132712.27418.53563.idtracker@ietfa.amsl.com> Date: Sat, 18 Jan 2014 17:55:36 -0500 Message-ID: From: Rifaat Shekh-Yusef To: Daniel Stenberg Content-Type: multipart/alternative; boundary=047d7b603a788808d004f0468eac Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-02.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2014 22:55:52 -0000 --047d7b603a788808d004f0468eac Content-Type: text/plain; charset=ISO-8859-1 I think that was introduced back when we considered allowing the server to indicate multiple encoding schemes to the client. I agree with you that it does not add any value with current approach. Regards, Rifaat On Sat, Jan 18, 2014 at 5:50 PM, Rifaat Shekh-Yusef wrote: > > > > On Sat, Jan 18, 2014 at 5:38 PM, Daniel Stenberg wrote: > >> On Sat, 18 Jan 2014, Rifaat Shekh-Yusef wrote: >> >> It would allow the server to fail the request without any further >>> processing, as it knows that the authentication will fail. >>> >> >> Why would a client want to send a request that includes an instruction to >> the server to fail it? >> >> > I see your point. How about changing the last paragraph to say: > > If the user agent does not support the encoding indicated by the server, the user agent MUST fail the request. > > > Regards, > > Rifaat > > >> Also, you seem to imply then that a server will blindly accept the >> exclamation point and not check for itself that the charset is indeed not >> supported? >> >> -- >> >> / daniel.haxx.se >> > > --047d7b603a788808d004f0468eac Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I think that was introduced back when we considered allowi= ng the server to indicate multiple encoding schemes to the client.=A0
I= agree with you that it does not add any value with current approach.
<= br>
Regards,
=A0Rifaat


On Sat, Jan 18, 2014 at 5:50 PM= , Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:



On Sat, Jan 18, 20= 14 at 5:38 PM, Daniel Stenberg <daniel@haxx.se> wrote:
On Sat, 18 Jan 2014, Rifaat Shekh-Yusef wrote:

It would allow the server to fail the request without any further processin= g, as it knows that the authentication will fail.

Why would a client want to send a request that includes an instruction to t= he server to fail it?


I see your point. How about chan= ging the last paragraph to say:

   If the use=
r agent does not support the encoding indicated by the server, the user age=
nt MUST fail the request.


Regards,=
=A0Rifaat
=A0
Also, you seem to imply then that a server will blindly accept the exclamat= ion point and not check for itself that the charset is indeed not supported= ?

--

=A0/ daniel.haxx.se=


--047d7b603a788808d004f0468eac-- From julian.reschke@gmx.de Sat Jan 18 14:56:34 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D3E21AD1F5 for ; Sat, 18 Jan 2014 14:56:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QxNgpwJ7AvCl for ; Sat, 18 Jan 2014 14:56:33 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id AE5351ADFDB for ; Sat, 18 Jan 2014 14:56:32 -0800 (PST) Received: from [192.168.2.117] ([84.187.53.93]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M4TgW-1V8aXn0ZDg-00yiQ5 for ; Sat, 18 Jan 2014 23:56:19 +0100 Message-ID: <52DB068E.10400@gmx.de> Date: Sat, 18 Jan 2014 23:56:14 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Rifaat Shekh-Yusef References: <20140118132712.27418.53563.idtracker@ietfa.amsl.com> <52DA9F13.6050908@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:yOt2t0oKX6P4lVpYyqQO/YsGsIYKk4u4Wml8KTLXDQGD6MVnEco kxWMBST+KuCICZ6Q8ejcCBUcvR9TbBIJd77azbnJgMpQlcjsSE7s8/lDsuPUjX6VJdw0FL1 ykSW6eVpPZBEGdR+Ck+PaHfHAkTsjFs9miowEai3aX17DLg5aVclTFMjEmq+TR3GtgTIEHm 2iFpO/I/5CeF4kJ26bNsA== Cc: "http-auth@ietf.org" , internet-drafts@ietf.org, i-d-announce@ietf.org Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-02.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2014 22:56:34 -0000 On 2014-01-18 21:18, Rifaat Shekh-Yusef wrote: > On Sat, Jan 18, 2014 at 10:34 AM, Julian Reschke > wrote: > > On 2014-01-18 14:30, Rifaat Shekh-Yusef wrote: > > Hi, > > With this new version, I think that I have addressed all the > comments > that I received on the mailing list. > I also made some changes to the IANA registry section. > > Please, let us know if you have any comments. > > Regards, > Rifaat > > > 1) Again: there shouldn't be an ABNF for challenge or credentials. > > The syntax is fully defined by HTTPbis, Part 7. > > What you should define is the set of individual auth-params defined > in challenges and credentials. > > > Just to make sure I understand your point, what you are looking for is, > for example, to replace what I have in section 3.3 with the following > > auth-scheme = "Digest" > > domain = "domain" "=" <"> URI ( 1*SP URI ) <"> > URI = absoluteURI | abs_path > nonce = "nonce" "=" nonce-value > nonce-value = quoted-string > opaque = "opaque" "=" quoted-string > stale = "stale" "=" ( "true" | "false" ) > algorithm = "algorithm" "=" ( > "MD5" | "MD5-sess" | > "SHA2-256" | "SHA2-256-sess" | > "SHA2-512-256" | "SHA2-512-256-sess" | > token) > qop-options = "qop" "=" <"> 1#qop-value <"> > qop-value = "auth" | "auth-int" | token > charset = "charset" "=" ("UTF-8" | token) > userhash = "userhash" "=" ( "true" | "false" ) > > > Is that correct? Nope. Just enumerate the parameters and state what the syntax of their values is. For instance: "algorithm - the algorithm parameter represents the name of the digest algorithm; supported values are ... (to be matched case-insensitively)" > ... Best regards, Julian From daniel@haxx.se Sat Jan 18 15:09:29 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B413A1ACCF0 for ; Sat, 18 Jan 2014 15:09:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dlrdwut2PQjW for ; Sat, 18 Jan 2014 15:09:28 -0800 (PST) Received: from giant.haxx.se (www.haxx.se [IPv6:2a00:1a28:1200:9::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2D0141A16F0 for ; Sat, 18 Jan 2014 15:09:28 -0800 (PST) Received: from giant.haxx.se (dast@localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-4.1) with ESMTP id s0IN9CQk008011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 19 Jan 2014 00:09:12 +0100 Received: from localhost (dast@localhost) by giant.haxx.se (8.14.4/8.14.4/Submit) with ESMTP id s0IN9BPF008008; Sun, 19 Jan 2014 00:09:11 +0100 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Sun, 19 Jan 2014 00:09:11 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: Rifaat Shekh-Yusef In-Reply-To: Message-ID: References: <20140118132712.27418.53563.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-02.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2014 23:09:30 -0000 On Sat, 18 Jan 2014, Rifaat Shekh-Yusef wrote: > I see your point. How about changing the last paragraph to say: > > If the user agent does not support the encoding indicated by the server, the > user agent MUST fail the request. Much better! -- / daniel.haxx.se From rifaat.ietf@gmail.com Sat Jan 18 15:11:19 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CEAD1ADFF7 for ; Sat, 18 Jan 2014 15:11:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kNze1XfgqS-b for ; Sat, 18 Jan 2014 15:11:18 -0800 (PST) Received: from mail-ea0-x22e.google.com (mail-ea0-x22e.google.com [IPv6:2a00:1450:4013:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id B061C1A16F0 for ; Sat, 18 Jan 2014 15:11:17 -0800 (PST) Received: by mail-ea0-f174.google.com with SMTP id b10so2381584eae.19 for ; Sat, 18 Jan 2014 15:11:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CUT/F77QwNVt1TFvjN4Ua312O89BY1dftp4XfStuFgc=; b=z0geA/igQ5Wj3SRAEkBSo82W/7/cBqT/Vj5mxfS2t+q65sFSbAVLoFsOVyps1LgHXo yliKDlR5LLgHvU+Q6c40roz4YV9OVBvlF77ERsaUhZyGEnuG/TsBogqZmjudC3tcsrhs A+3qSiYBcJjspuep3ezfD1fUxzqaJEfZwkFZLxjr+OD9IazGNApf2U0woBT0fuvBiKNd iFb0haKp60OuARF/U89u6BxW42L3YI8gjl9oVUrOx90N2dl9lqXQkgV84Su/BJl7sWgc +G8fC4k1dQDNLHYX6Yrvq2ZzDkT+QHW5vKYBguDc+ZzWtOE7wGverM0ozVU+J6bUj/4i /bow== MIME-Version: 1.0 X-Received: by 10.15.56.132 with SMTP id y4mr4543787eew.61.1390086664145; Sat, 18 Jan 2014 15:11:04 -0800 (PST) Received: by 10.14.53.78 with HTTP; Sat, 18 Jan 2014 15:11:04 -0800 (PST) In-Reply-To: References: <20140118132712.27418.53563.idtracker@ietfa.amsl.com> Date: Sat, 18 Jan 2014 18:11:04 -0500 Message-ID: From: Rifaat Shekh-Yusef To: Daniel Stenberg Content-Type: multipart/alternative; boundary=001a11c3fb70d2cfad04f046c53f Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-02.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2014 23:11:19 -0000 --001a11c3fb70d2cfad04f046c53f Content-Type: text/plain; charset=ISO-8859-1 Thanks Daniel! On Sat, Jan 18, 2014 at 6:09 PM, Daniel Stenberg wrote: > On Sat, 18 Jan 2014, Rifaat Shekh-Yusef wrote: > > I see your point. How about changing the last paragraph to say: >> >> If the user agent does not support the encoding indicated by the server, >> the user agent MUST fail the request. >> > > Much better! > > -- > > / daniel.haxx.se > --001a11c3fb70d2cfad04f046c53f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks Daniel!


On Sat, Jan 18, 2014 at 6:09 PM, Daniel Stenberg <dan= iel@haxx.se> wrote:
On Sat, 18 Jan 2014, Rifaa= t Shekh-Yusef wrote:

I see your point. How about changing the last paragraph to say:

If the user agent does not support the encoding indicated by the server, th= e user agent MUST fail the request.

Much better!

--

=A0/ daniel.haxx.se=

--001a11c3fb70d2cfad04f046c53f-- From rifaat.ietf@gmail.com Sat Jan 18 15:36:15 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9DF41ADFFC for ; Sat, 18 Jan 2014 15:36:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K_221LhjJEXL for ; Sat, 18 Jan 2014 15:36:13 -0800 (PST) Received: from mail-ea0-f179.google.com (mail-ea0-f179.google.com [209.85.215.179]) by ietfa.amsl.com (Postfix) with ESMTP id 93E471ADFFB for ; Sat, 18 Jan 2014 15:36:13 -0800 (PST) Received: by mail-ea0-f179.google.com with SMTP id q10so1539176ead.24 for ; Sat, 18 Jan 2014 15:35:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MXqFeKDEquJxIjaaYxjTY54opDKnZ/11eHQHHfo6cSA=; b=02pXCV6Yg2XinlwfjPwhMY/qHfBNx6vAa7fHetdpwX75EXmMiXHwZmHJRBemOfjlD7 qn0nZjwu5FmHlor9zpuLd7YBIAUptyM2aRkYtjE5+VfmShjH20BnwXqdEbHfrcOKd/YG exE5sbYgCuHaLN/nsDMEy80+HZHtJinFhEVSoLuIcDZG9EF3fhsLP8aX0tf2v9HqvEz3 EW7DMNLVJfx9RAIaWWLJ9KB8XIuXNasiDWr7Mwzd+WB9Q8l/bct6+i59PkYVgSwbGkdj 6zi/8CeZIuOU0J0VZQFKREaJZ4UUhJbOxyf32TI1cGuH3NEg71OmCJAGaUYpIQ+SDezn MHZw== MIME-Version: 1.0 X-Received: by 10.14.69.200 with SMTP id n48mr9999104eed.54.1390088125108; Sat, 18 Jan 2014 15:35:25 -0800 (PST) Received: by 10.14.53.78 with HTTP; Sat, 18 Jan 2014 15:35:25 -0800 (PST) In-Reply-To: <52DB068E.10400@gmx.de> References: <20140118132712.27418.53563.idtracker@ietfa.amsl.com> <52DA9F13.6050908@gmx.de> <52DB068E.10400@gmx.de> Date: Sat, 18 Jan 2014 18:35:25 -0500 Message-ID: From: Rifaat Shekh-Yusef To: Julian Reschke Content-Type: multipart/alternative; boundary=089e0160ce10e7538004f0471c6b Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-02.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jan 2014 23:36:15 -0000 --089e0160ce10e7538004f0471c6b Content-Type: text/plain; charset=ISO-8859-1 Julian, The following is from the *draft-ietf-httpbis-p7-auth-25* draft, section 2.1 Challenge and Response: auth-scheme = token auth-param = token BWS "=" BWS ( token / quoted-string ) Then the auth-scheme will defined in the IANA section, and the auth-param for all the parameters will be defined in the header's section; correct? I do not see Authentication-Info in the above draft; is it defined somewhere else? Regards, Rifaat On Sat, Jan 18, 2014 at 5:56 PM, Julian Reschke wrote: > On 2014-01-18 21:18, Rifaat Shekh-Yusef wrote: > >> On Sat, Jan 18, 2014 at 10:34 AM, Julian Reschke > > wrote: >> >> On 2014-01-18 14:30, Rifaat Shekh-Yusef wrote: >> >> Hi, >> >> With this new version, I think that I have addressed all the >> comments >> that I received on the mailing list. >> I also made some changes to the IANA registry section. >> >> Please, let us know if you have any comments. >> >> Regards, >> Rifaat >> >> >> 1) Again: there shouldn't be an ABNF for challenge or credentials. >> >> The syntax is fully defined by HTTPbis, Part 7. >> >> What you should define is the set of individual auth-params defined >> in challenges and credentials. >> >> >> Just to make sure I understand your point, what you are looking for is, >> for example, to replace what I have in section 3.3 with the following >> >> auth-scheme = "Digest" >> >> domain = "domain" "=" <"> URI ( 1*SP URI ) <"> >> URI = absoluteURI | abs_path >> nonce = "nonce" "=" nonce-value >> nonce-value = quoted-string >> opaque = "opaque" "=" quoted-string >> stale = "stale" "=" ( "true" | "false" ) >> algorithm = "algorithm" "=" ( >> "MD5" | "MD5-sess" | >> "SHA2-256" | "SHA2-256-sess" | >> "SHA2-512-256" | "SHA2-512-256-sess" | >> token) >> qop-options = "qop" "=" <"> 1#qop-value <"> >> qop-value = "auth" | "auth-int" | token >> charset = "charset" "=" ("UTF-8" | token) >> userhash = "userhash" "=" ( "true" | "false" ) >> >> >> Is that correct? >> > > Nope. Just enumerate the parameters and state what the syntax of their > values is. > > For instance: "algorithm - the algorithm parameter represents the name of > the digest algorithm; supported values are ... (to be matched > case-insensitively)" > > ... >> > > Best regards, Julian > --089e0160ce10e7538004f0471c6b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Julian,

The following is fro= m the draft-ietf-httpbis-p7-auth-25 draft, section 2.1 Challenge and= Response:
  auth-scheme    =3D token
 =20
  auth-param     =3D token BWS "=3D" BWS ( token / quoted-s=
tring )

Then the auth-scheme will defined in the IANA sec= tion, and the auth-param for all the parameters will be defined in the head= er's section; correct?

I do not see Authen= tication-Info in the above draft; is it defined somewhere else?

Regards,
=A0Rifaat

<= br>


On Sat, Jan 18, 2014 at 5:56 PM, Julian Reschke <julian.reschke@gmx.= de> wrote:
On 2014-01-18 21:18, Rifaa= t Shekh-Yusef wrote:
On Sat, Jan 18, 2014 at 10:34 AM, Julian Reschke <julian.reschke@gmx.de
<mailto:julia= n.reschke@gmx.de>> wrote:

=A0 =A0 On 2014-01-18 14:30, Rifaat Shekh-Yusef wrote:

=A0 =A0 =A0 =A0 Hi,

=A0 =A0 =A0 =A0 With this new version, I think that I have addressed all th= e
=A0 =A0 =A0 =A0 comments
=A0 =A0 =A0 =A0 that I received on the mailing list.
=A0 =A0 =A0 =A0 I also made some changes to the IANA registry section.

=A0 =A0 =A0 =A0 Please, let us know if you have any comments.

=A0 =A0 =A0 =A0 Regards,
=A0 =A0 =A0 =A0 =A0 =A0Rifaat


=A0 =A0 1) Again: there shouldn't be an ABNF for challenge or credentia= ls.

=A0 =A0 The syntax is fully defined by HTTPbis, Part 7.

=A0 =A0 What you should define is the set of individual auth-params defined=
=A0 =A0 in challenges and credentials.


Just to make sure I understand your point, what you are looking for is,
for example, to replace what I have in section 3.3 with the following

=A0 =A0 =A0 =A0auth-scheme =A0 =A0=3D =A0"Digest"

=A0 =A0 =A0 =A0domain =A0 =A0 =A0 =A0 =A0 =A0=3D "domain" "= =3D" <"> URI ( 1*SP URI ) <">
=A0 =A0 =A0 =A0URI =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D absoluteURI | abs_pa= th
=A0 =A0 =A0 =A0nonce =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D "nonce" "= ;=3D" nonce-value
=A0 =A0 =A0 =A0nonce-value =A0 =A0 =A0=3D quoted-string
=A0 =A0 =A0 =A0opaque =A0 =A0 =A0 =A0 =A0 =A0=3D "opaque" "= =3D" quoted-string
=A0 =A0 =A0 =A0stale =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D "stale" &quo= t;=3D" ( "true" | "false" )
=A0 =A0 =A0 =A0algorithm =A0 =A0 =A0 =A0 =3D "algorithm" "= =3D" (
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"MD5" | &q= uot;MD5-sess" |
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"SHA2-256"= | "SHA2-256-sess" |
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"SHA2-512-256&q= uot; | "SHA2-512-256-sess" |
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0token)
=A0 =A0 =A0 =A0qop-options =A0 =A0=3D "qop" "=3D" <&= quot;> 1#qop-value <">
=A0 =A0 =A0 =A0qop-value =A0 =A0 =A0 =3D "auth" | "auth-int&= quot; | token
=A0 =A0 =A0 =A0charset =A0 =A0 =A0 =A0 =A0=3D "charset" "=3D= " ("UTF-8" | token)
=A0 =A0 =A0 =A0userhash =A0 =A0 =A0 =3D "userhash" "=3D"= ; ( "true" | "false" )


Is that correct?

Nope. Just enumerate the parameters and state what the syntax of their valu= es is.

For instance: "algorithm - the algorithm parameter represents the name= of the digest algorithm; supported values are ... (to be matched case-inse= nsitively)"

...

Best regards, Julian

--089e0160ce10e7538004f0471c6b-- From sophie.bremer@netzkonform.de Sat Jan 18 22:36:53 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6389E1AD94A for ; Sat, 18 Jan 2014 22:36:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JN83XfmW8-5o for ; Sat, 18 Jan 2014 22:36:51 -0800 (PST) Received: from wp072.webpack.hosteurope.de (wp399.xfer.webpack.hosteurope.de [IPv6:2a01:488:42::523:e524]) by ietfa.amsl.com (Postfix) with ESMTP id 3D9061ADBCA for ; Sat, 18 Jan 2014 22:36:45 -0800 (PST) Received: from [89.204.135.172] (helo=[10.45.178.172]); authenticated by wp072.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) id 1W4lzg-0005jN-S1; Sun, 19 Jan 2014 07:36:30 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Sophie Bremer In-Reply-To: <52DB068E.10400@gmx.de> Date: Sun, 19 Jan 2014 07:36:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1ABE4A2E-7490-4308-AAB2-EA6CE566281B@netzkonform.de> References: <20140118132712.27418.53563.idtracker@ietfa.amsl.com> <52DA9F13.6050908@gmx.de> <52DB068E.10400@gmx.de> To: http-auth@ietf.org X-Mailer: Apple Mail (2.1827) X-bounce-key: webpack.hosteurope.de; sophie.bremer@netzkonform.de; 1390113393; 96c1f900; Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-02.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jan 2014 06:36:53 -0000 On 2014-01-18 23:56, Julian Reschke wrote: > On 2014-01-18 21:18, Rifaat Shekh-Yusef wrote: >> On Sat, Jan 18, 2014 at 10:34 AM, Julian Reschke = > > wrote: >>=20 >> On 2014-01-18 14:30, Rifaat Shekh-Yusef wrote: >>=20 >> Hi, >>=20 >> With this new version, I think that I have addressed all the >> comments >> that I received on the mailing list. >> I also made some changes to the IANA registry section. >>=20 >> Please, let us know if you have any comments. >>=20 >> Regards, >> Rifaat >>=20 >>=20 >> 1) Again: there shouldn't be an ABNF for challenge or credentials. >>=20 >> The syntax is fully defined by HTTPbis, Part 7. >>=20 >> What you should define is the set of individual auth-params defined >> in challenges and credentials. >>=20 >>=20 >> Just to make sure I understand your point, what you are looking for = is, >> for example, to replace what I have in section 3.3 with the following >>=20 >> auth-scheme =3D "Digest" >>=20 >> domain =3D "domain" "=3D" <"> URI ( 1*SP URI ) <"> >> URI =3D absoluteURI | abs_path >> nonce =3D "nonce" "=3D" nonce-value >> nonce-value =3D quoted-string >> opaque =3D "opaque" "=3D" quoted-string >> stale =3D "stale" "=3D" ( "true" | "false" ) >> algorithm =3D "algorithm" "=3D" ( >> "MD5" | "MD5-sess" | >> "SHA2-256" | "SHA2-256-sess" | >> "SHA2-512-256" | "SHA2-512-256-sess" | >> token) >> qop-options =3D "qop" "=3D" <"> 1#qop-value <"> >> qop-value =3D "auth" | "auth-int" | token >> charset =3D "charset" "=3D" ("UTF-8" | token) >> userhash =3D "userhash" "=3D" ( "true" | "false" ) >>=20 >>=20 >> Is that correct? >=20 > Nope. Just enumerate the parameters and state what the syntax of their = values is. >=20 > For instance: "algorithm - the algorithm parameter represents the name = of the digest algorithm; supported values are ... (to be matched = case-insensitively)" >=20 >> ... >=20 > Best regards, Julian > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth >=20 Hello Julian, In my opinion this would not help to reach clarity. The BNF form gives a complete and short overview of what is expected in = each parameter, without reading any sentence. Best regards, Sophie= From julian.reschke@gmx.de Sun Jan 19 02:59:41 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7521B1ADDBF for ; Sun, 19 Jan 2014 02:59:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EkWLnL7UVgAN for ; Sun, 19 Jan 2014 02:59:40 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id E7AFE1ADDBD for ; Sun, 19 Jan 2014 02:59:39 -0800 (PST) Received: from [192.168.2.117] ([84.187.53.93]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LhSfM-1VZqwf2zuy-00meuE for ; Sun, 19 Jan 2014 11:59:25 +0100 Message-ID: <52DBB008.1020609@gmx.de> Date: Sun, 19 Jan 2014 11:59:20 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Rifaat Shekh-Yusef References: <20140118132712.27418.53563.idtracker@ietfa.amsl.com> <52DA9F13.6050908@gmx.de> <52DB068E.10400@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:MKedutmwP8Z6pd08bImSxSRQsxfyjxDsmsnhvSna5qew55riAN1 PAANy7CiuDO9QY/2DXLshiDFTrpbEquC9PlMHB0Oq67Wi1u0U6wwjAtNu9kA9HydkBu/3OF ccI4d73YER1seWT/nWvQlSdZUVIZU8rLVttW7QTgH4JuPrvSxv2UcmalGOQm2gr2X8ENcSE P4Zwd3K/wQyGFOZtsfccA== Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-02.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jan 2014 10:59:41 -0000 On 2014-01-19 00:35, Rifaat Shekh-Yusef wrote: > Julian, > > The following is from the *draft-ietf-httpbis-p7-auth-25* draft, section > 2.1 Challenge and Response: > > auth-scheme =token > > auth-param =token BWS "="BWS (token /quoted-string ) > > > Then the auth-scheme will defined in the IANA section, and the > auth-param for all the parameters will be defined in the header's > section; correct? Something like that, yes. > I do not see Authentication-Info in the above draft; is it defined > somewhere else? No, that header field is not part of the framework, thus needs to be defined by the Digest spec. Best regards, Julian From sophie.bremer@netzkonform.de Sun Jan 19 04:42:31 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5454E1ADFE4 for ; Sun, 19 Jan 2014 04:42:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IL8uIUNUS2ch for ; Sun, 19 Jan 2014 04:42:30 -0800 (PST) Received: from wp072.webpack.hosteurope.de (wp399.xfer.webpack.hosteurope.de [IPv6:2a01:488:42::523:e524]) by ietfa.amsl.com (Postfix) with ESMTP id D2DE11ADFD6 for ; Sun, 19 Jan 2014 04:42:29 -0800 (PST) Received: from [89.204.130.181] (helo=[10.144.48.181]); authenticated by wp072.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) id 1W4rhd-00075j-Fo; Sun, 19 Jan 2014 13:42:14 +0100 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Sophie Bremer In-Reply-To: <52DBB0F0.8000102@gmx.de> Date: Sun, 19 Jan 2014 13:42:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140118132712.27418.53563.idtracker@ietfa.amsl.com> <52DA9F13.6050908@gmx.de> <52DB068E.10400@gmx.de> <4ECCC40E-20E2-43C7-870E-6F192AD6DB7C@netzkonform.de> <52DBB0F0.8000102@gmx.de> To: http-auth@ietf.org X-Mailer: Apple Mail (2.1827) X-bounce-key: webpack.hosteurope.de; sophie.bremer@netzkonform.de; 1390135337; e4a024c9; Cc: julian.reschke@gmx.de Subject: [http-auth] Fwd: I-D Action: draft-ietf-httpauth-digest-02.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jan 2014 12:42:31 -0000 For complement the discussion with Julian... On 2014-01-19 12:03, Julian Reschke wrote: > On 2014-01-19 07:35, Sophie Bremer wrote: >> ... >> Hello Julian, >>=20 >> In my opinion this would not help to reach clarity. >> The BNF form gives a complete and short overview of what is expected = in each parameter, without reading any sentence. >> ... >=20 > Complete, short, and incorrect :-). >=20 > A conforming recipient needs to use a *generic* parser (that handles = even unknown authentication schemes). The ABNF that describes this = process is in HTTPbis Part 7. The result of this parsing is a set of = (scheme name + name/value pairs); and that's why each scheme = specification should only define the name of the scheme, the name of = their parameters, and their syntax. >=20 > Best regards, Julian >=20 From julian.reschke@gmx.de Sun Jan 19 06:48:01 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F113B1AD75F for ; Sun, 19 Jan 2014 06:48:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0HSCGXe4Ojs0 for ; Sun, 19 Jan 2014 06:47:59 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE6A1AD7C1 for ; Sun, 19 Jan 2014 06:47:59 -0800 (PST) Received: from [192.168.2.117] ([84.187.52.61]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M8pKi-1WCZB640YG-00CAGZ for ; Sun, 19 Jan 2014 15:47:45 +0100 Message-ID: <52DBE58F.3040200@gmx.de> Date: Sun, 19 Jan 2014 15:47:43 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Sophie Bremer , http-auth@ietf.org References: <20140118132712.27418.53563.idtracker@ietfa.amsl.com> <52DA9F13.6050908@gmx.de> <52DB068E.10400@gmx.de> <4ECCC40E-20E2-43C7-870E-6F192AD6DB7C@netzkonform.de> <52DBB0F0.8000102@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:1luUzi0yjzoQfapLOpwhwX2jabeJ8NijE1tGMt/woLQDT82roYI e5XPYeqR891xvkNu855dryM4N5dgzS0X7i3+ZVCn7BDwTwlozjfheONT5BLqin9vXq5YBZe K71M6kUn3UUlaUUgc4YeHv2jXHdl7+HgcmnmBTCR46d6TWVPDSvUxda80elHJmx8RMVAR3g v9kvA4/qBkmUh7x9RutQw== Subject: Re: [http-auth] Fwd: I-D Action: draft-ietf-httpauth-digest-02.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jan 2014 14:48:01 -0000 On 2014-01-19 13:42, Sophie Bremer wrote: > For complement the discussion with Julian... > > On 2014-01-19 12:03, Julian Reschke wrote: > >> On 2014-01-19 07:35, Sophie Bremer wrote: >>> ... >>> Hello Julian, >>> >>> In my opinion this would not help to reach clarity. >>> The BNF form gives a complete and short overview of what is expected in each parameter, without reading any sentence. >>> ... >> >> Complete, short, and incorrect :-). >> >> A conforming recipient needs to use a *generic* parser (that handles even unknown authentication schemes). The ABNF that describes this process is in HTTPbis Part 7. The result of this parsing is a set of (scheme name + name/value pairs); and that's why each scheme specification should only define the name of the scheme, the name of their parameters, and their syntax. >> >> Best regards, Julian >> > ... A few examples: a) domain = "domain" "=" <"> URI ( 1*SP URI ) <"> - is whitespace allowed between "domain", "=", and the value? - the prose syntax should only be used as "last resort" (RFC 5234) - what happens if the field value contains a "\"? So is the field value to be parsed as quoted-string or not? b) algorithm = "algorithm" "=" ( "MD5" | "MD5-sess" | "SHA2-256" | "SHA2-256-sess" | "SHA2-512-256" | "SHA2-512-256-sess" | token) So according to the ABNF the field value can not be a quoted-string, and is case-insensitive. A later example shows it using quoted-string syntax. Etc. Summary: don't try mix parsing of the HTTP header field value with the parsing of the individual parameter values; these are different layers. Best regards, Julian PS: URI = absoluteURI | abs_path - these are not defined in the document From internet-drafts@ietf.org Sun Jan 19 07:46:17 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D475D1AE006; Sun, 19 Jan 2014 07:46:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pnnCzLiK8-13; Sun, 19 Jan 2014 07:46:16 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 88C321ADF33; Sun, 19 Jan 2014 07:46:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140119154616.17634.28278.idtracker@ietfa.amsl.com> Date: Sun, 19 Jan 2014 07:46:16 -0800 Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-digest-03.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jan 2014 15:46:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Hypertext Transfer Protocol Authenticatio= n Working Group of the IETF. Title : HTTP Digest Access Authentication Authors : Rifaat Shekh-Yusef David Ahrens Sophie Bremer Filename : draft-ietf-httpauth-digest-03.txt Pages : 28 Date : 2014-01-19 Abstract: HTTP provides a simple challenge-response authentication mechanism that may be used by a server to challenge a client request and by a client to provide authentication information. This document defines the HTTP Digest Authentication scheme that may be used with the authentication mechanism. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-httpauth-digest-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-httpauth-digest-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rifaat.ietf@gmail.com Sun Jan 19 07:48:36 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A5F91ADF33 for ; Sun, 19 Jan 2014 07:48:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eyhapzYRihYT for ; Sun, 19 Jan 2014 07:48:34 -0800 (PST) Received: from mail-ea0-x235.google.com (mail-ea0-x235.google.com [IPv6:2a00:1450:4013:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 235FD1ADDD2 for ; Sun, 19 Jan 2014 07:48:33 -0800 (PST) Received: by mail-ea0-f181.google.com with SMTP id m10so2644007eaj.40 for ; Sun, 19 Jan 2014 07:48:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=VQV2Cp/KHAOEfrLyIFkM6hlqYNhvIdT+MwRcayzMhS4=; b=MTPZGfH/DNdVu62hyuv5WghNmzqaRj9QkXJ0TJoTkWKVqHny6FDJNNdZXmEuHj4WQb oSXyf2X0yNE8iEKNGYiXU+K+NGED9eTdfxJDHphlhfrUJfbjNXaVIVK/oLRzJUl2JzDC an5QgbyaZsOA5tCUCkaYxe94Ho+7OwDxHax3ly7MrdO5i6UdUwdhDpMTMjEDWIvF+TOw +o4KRtfS4KEkGja3zHV4U3xi10/PjvsB6Hdx6DcZAHmF8HV/6gMFRHhF8VD+Xr7EkM00 22jcbaR9XJQvhEDhZPk8qH1CTOjH24R2sVvtnnBdslWeTpPuZ9hJkrY36yXGwmP0lKTg 6nxQ== MIME-Version: 1.0 X-Received: by 10.15.32.73 with SMTP id z49mr13183477eeu.27.1390146500328; Sun, 19 Jan 2014 07:48:20 -0800 (PST) Received: by 10.14.53.78 with HTTP; Sun, 19 Jan 2014 07:48:20 -0800 (PST) In-Reply-To: <20140119154616.17634.28278.idtracker@ietfa.amsl.com> References: <20140119154616.17634.28278.idtracker@ietfa.amsl.com> Date: Sun, 19 Jan 2014 10:48:20 -0500 Message-ID: From: Rifaat Shekh-Yusef To: "http-auth@ietf.org" Content-Type: multipart/alternative; boundary=089e0160c5cc5682e404f054b4cb Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-03.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jan 2014 15:48:36 -0000 --089e0160c5cc5682e404f054b4cb Content-Type: text/plain; charset=ISO-8859-1 Hi, I think that I have addressed all the comments that I have received on the mailing list so far. Please, take a look and let us know if you have any further comments. Regards, Rifaat On Sun, Jan 19, 2014 at 10:46 AM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Hypertext Transfer Protocol > Authentication Working Group of the IETF. > > Title : HTTP Digest Access Authentication > Authors : Rifaat Shekh-Yusef > David Ahrens > Sophie Bremer > Filename : draft-ietf-httpauth-digest-03.txt > Pages : 28 > Date : 2014-01-19 > > Abstract: > HTTP provides a simple challenge-response authentication mechanism > that may be used by a server to challenge a client request and by a > client to provide authentication information. This document defines > the HTTP Digest Authentication scheme that may be used with the > authentication mechanism. > > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-httpauth-digest-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-digest-03 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > --089e0160c5cc5682e404f054b4cb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I think that I have addressed all t= he comments that I have received on the mailing list so far.
Plea= se, take a look and let us know if you have any further comments.

Regards,
=A0Rifaat



On Sun, Jan 19, 2014 at= 10:46 AM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0This draft is a work item of the Hypertext Transfer Protocol Authenticat= ion Working Group of the IETF.

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : HTTP Digest Access Authenticati= on
=A0 =A0 =A0 =A0 Authors =A0 =A0 =A0 =A0 : Rifaat Shekh-Yusef
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 David Ahrens
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Sophie Bremer
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-httpauth-digest-03.txt=
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 28
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2014-01-19

Abstract:
=A0 =A0HTTP provides a simple challenge-response authentication mechanism =A0 =A0that may be used by a server to challenge a client request and by a<= br> =A0 =A0client to provide authentication information. This document defines<= br> =A0 =A0the HTTP Digest Authentication scheme that may be used with the
=A0 =A0authentication mechanism.




The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest= /

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-httpauth-digest-03
A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-httpauth-= digest-03


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
http-auth mailing list
http-auth@ietf.org
https://www.ietf.org/mailman/listinfo/http-auth

--089e0160c5cc5682e404f054b4cb-- From julian.reschke@gmx.de Sun Jan 19 08:37:19 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B31A1AE00E for ; Sun, 19 Jan 2014 08:37:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1ggl5HcBVB4 for ; Sun, 19 Jan 2014 08:37:18 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id E5C651AE00B for ; Sun, 19 Jan 2014 08:37:17 -0800 (PST) Received: from [192.168.2.117] ([84.187.52.61]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MBFBB-1WEVbe3sQP-00AH8O for ; Sun, 19 Jan 2014 17:37:04 +0100 Message-ID: <52DBFF2E.8000703@gmx.de> Date: Sun, 19 Jan 2014 17:37:02 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Rifaat Shekh-Yusef , "http-auth@ietf.org" References: <20140119154616.17634.28278.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:VRahhFIOJxRukGK8AQq448zQUu6OIp41mE0DbKknuVCmWN8SbPQ UppZbQE98RdfY276gyHs1vAvkWzYpvGZUl20uakYYvSoyHLcwe13Ppz5BHd0u/3w7XNVe+j bpWFmMUakMH5wL+onWG/g3r7RpmZY7BCWF+xiQdTayf5oxlW2tydAhVvPdYUN+s/13kvVZf 3ceinZrp7iTLVkhW7Uztw== Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-03.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jan 2014 16:37:19 -0000 On 2014-01-19 16:48, Rifaat Shekh-Yusef wrote: > Hi, > > I think that I have addressed all the comments that I have received on > the mailing list so far. > Please, take a look and let us know if you have any further comments. > > Regards, > Rifaat a) The RFC 2617 reference can't be normative (we're replacing parts of it) b) the URI RFC is RFC 3986. Best regards, Julian From ynir@checkpoint.com Sun Jan 19 08:50:00 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C8C91AE01A for ; Sun, 19 Jan 2014 08:50:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.439 X-Spam-Level: X-Spam-Status: No, score=-7.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsn1w3jfBvVR for ; Sun, 19 Jan 2014 08:49:58 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id EA3321AE019 for ; Sun, 19 Jan 2014 08:49:57 -0800 (PST) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id s0JGncki026968; Sun, 19 Jan 2014 18:49:38 +0200 X-CheckPoint: {52DBFC40-9-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.110]) by IL-EX10.ad.checkpoint.com ([169.254.2.228]) with mapi id 14.03.0123.003; Sun, 19 Jan 2014 18:49:38 +0200 From: Yoav Nir To: Rifaat Shekh-Yusef Thread-Topic: [http-auth] I-D Action: draft-ietf-httpauth-digest-03.txt Thread-Index: AQHPFS2XRvpzc7+/pUCDNH9/kru74ZqMD94AgAANmwCAAAOQgA== Date: Sun, 19 Jan 2014 16:49:38 +0000 Message-ID: <17F25A58-4DE7-4160-9CD4-001A3CBC369D@checkpoint.com> References: <20140119154616.17634.28278.idtracker@ietfa.amsl.com> <52DBFF2E.8000703@gmx.de> In-Reply-To: <52DBFF2E.8000703@gmx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.191] x-kse-antivirus-interceptor-info: protection disabled Content-Type: text/plain; charset="us-ascii" Content-ID: <8CBE4A8ACA0AEE4BA61B65EE1D4F50E7@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Julian Reschke , "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-03.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jan 2014 16:50:00 -0000 On Jan 19, 2014, at 6:37 PM, Julian Reschke wrote: > On 2014-01-19 16:48, Rifaat Shekh-Yusef wrote: >> Hi, >>=20 >> I think that I have addressed all the comments that I have received on >> the mailing list so far. >> Please, take a look and let us know if you have any further comments. >>=20 >> Regards, >> Rifaat >=20 > a) The RFC 2617 reference can't be normative (we're replacing parts of it= ) Moreover, we (as in "http-auth") are entirely replacing 2617, so it shouldn= 't be referenced at all. If you look at I-D nits ([1]) this, along with 2195 are unused references. = Please resolve the other nits as well. > b) the URI RFC is RFC 3986. >=20 > Best regards, Julian Yoav [1] http://tools.ietf.org/idnits?url=3Dhttp://tools.ietf.org/id/draft-ietf-= httpauth-digest-03.txt= From ilari.liusvaara@elisanet.fi Sun Jan 19 09:20:27 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61E451ADF8B for ; Sun, 19 Jan 2014 09:20:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2RkV0l_PXlN for ; Sun, 19 Jan 2014 09:20:25 -0800 (PST) Received: from emh07.mail.saunalahti.fi (emh07.mail.saunalahti.fi [62.142.5.117]) by ietfa.amsl.com (Postfix) with ESMTP id 6CAF21ADF73 for ; Sun, 19 Jan 2014 09:20:25 -0800 (PST) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id 297063FEC; Sun, 19 Jan 2014 19:20:10 +0200 (EET) Date: Sun, 19 Jan 2014 19:20:10 +0200 From: Ilari Liusvaara To: Rifaat Shekh-Yusef Message-ID: <20140119172010.GA2248@LK-Perkele-VII> References: <20140119154616.17634.28278.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Ilari Liusvaara Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-03.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jan 2014 17:20:27 -0000 On Sun, Jan 19, 2014 at 10:48:20AM -0500, Rifaat Shekh-Yusef wrote: > Hi, > > I think that I have addressed all the comments that I have received on the > mailing list so far. > Please, take a look and let us know if you have any further comments. Some comments (some are bit nitpicking): - The sections about on-wire format don't say what the actual authscheme name is (Digest), one has to go to IANA considerations for that. - Realm was one of those parameters that had to be quoted? It doesn't say in the description. Also, can't the description just refer to HTTPBIS p7 section 2.2? - Description of userhash doesn't say the valid values (true/false). -Ilari From internet-drafts@ietf.org Sun Jan 19 11:46:23 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 650641ADF31; Sun, 19 Jan 2014 11:46:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mgOjHp0AiCpK; Sun, 19 Jan 2014 11:46:22 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C35E1ADF80; Sun, 19 Jan 2014 11:46:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.90.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140119194621.16691.85278.idtracker@ietfa.amsl.com> Date: Sun, 19 Jan 2014 11:46:21 -0800 Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-digest-04.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jan 2014 19:46:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Hypertext Transfer Protocol Authenticatio= n Working Group of the IETF. Title : HTTP Digest Access Authentication Authors : Rifaat Shekh-Yusef David Ahrens Sophie Bremer Filename : draft-ietf-httpauth-digest-04.txt Pages : 30 Date : 2014-01-19 Abstract: HTTP provides a simple challenge-response authentication mechanism that may be used by a server to challenge a client request and by a client to provide authentication information. This document defines the HTTP Digest Authentication scheme that may be used with the authentication mechanism. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-httpauth-digest-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-httpauth-digest-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rifaat.ietf@gmail.com Sun Jan 19 11:51:05 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50D081ADF92 for ; Sun, 19 Jan 2014 11:51:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M9raoiu0pZzQ for ; Sun, 19 Jan 2014 11:51:03 -0800 (PST) Received: from mail-ee0-x229.google.com (mail-ee0-x229.google.com [IPv6:2a00:1450:4013:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 866B01ADF79 for ; Sun, 19 Jan 2014 11:51:03 -0800 (PST) Received: by mail-ee0-f41.google.com with SMTP id e49so3064669eek.14 for ; Sun, 19 Jan 2014 11:50:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=lHPGgTjZht+izOsUhWWLqKKd0MQxGtOTgzBCK4ZZLMk=; b=rergCMR0WtSeOYba+mYPBDz87xZpNEJpI+p770AdwqcbLPT/eALAX25m6Bnldh2Q69 qLrW5+Z4OBffimZ+2ch+7jYhxQqbk7UJydnilgrd1blyhQ6w6cpbvFEYEAbZ0enTOkv4 GgWQ6SUqeRUGyXFa+BNzJVeZdIFCr4xLpPGx1WkeM1RlFStcAbz2pJe2IygIt2+SjbfX o3zN7NypH1YwmE9d9RvopUYNzNwB7SZYhAJ7PJC0b3Ae0CJzwYk6tFGba5m4WP5Q2Tvz jYDzFqq4V5eQrb21MFWmN3AMXhJMimHNCG43Z/bkBydEwHi8YRcfYS33hq3TOxq6d7fl IDQg== MIME-Version: 1.0 X-Received: by 10.14.203.7 with SMTP id e7mr70565eeo.58.1390161049688; Sun, 19 Jan 2014 11:50:49 -0800 (PST) Received: by 10.14.53.78 with HTTP; Sun, 19 Jan 2014 11:50:49 -0800 (PST) In-Reply-To: <20140119194621.16691.85278.idtracker@ietfa.amsl.com> References: <20140119194621.16691.85278.idtracker@ietfa.amsl.com> Date: Sun, 19 Jan 2014 14:50:49 -0500 Message-ID: From: Rifaat Shekh-Yusef To: "http-auth@ietf.org" Content-Type: multipart/alternative; boundary=047d7b343aae8c204104f05817e5 Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-04.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jan 2014 19:51:05 -0000 --047d7b343aae8c204104f05817e5 Content-Type: text/plain; charset=ISO-8859-1 Hi, Thank you all for great comments; we really appreciate that. We believe that we addresses all the latest comments, and we also expanded the examples section. Please, take a look and let us know if you have any further comments. Regards, Rifaat On Sun, Jan 19, 2014 at 2:46 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Hypertext Transfer Protocol > Authentication Working Group of the IETF. > > Title : HTTP Digest Access Authentication > Authors : Rifaat Shekh-Yusef > David Ahrens > Sophie Bremer > Filename : draft-ietf-httpauth-digest-04.txt > Pages : 30 > Date : 2014-01-19 > > Abstract: > HTTP provides a simple challenge-response authentication mechanism > that may be used by a server to challenge a client request and by a > client to provide authentication information. This document defines > the HTTP Digest Authentication scheme that may be used with the > authentication mechanism. > > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-httpauth-digest-04 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-digest-04 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > --047d7b343aae8c204104f05817e5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

Thank you all for great comme= nts; we really appreciate that.
We believe that we addresses all the la= test comments, and we also expanded the examples section.

Please, take a look and let us know if you have any further comments.<= /div>

Regards,
=A0Rifaat



On Sun, Jan 19, 2014 at 2:46 PM, <internet-drafts@ietf.org>= wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0This draft is a work item of the Hypertext Transfer Protocol Authenticat= ion Working Group of the IETF.

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : HTTP Digest Access Authenticati= on
=A0 =A0 =A0 =A0 Authors =A0 =A0 =A0 =A0 : Rifaat Shekh-Yusef
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 David Ahrens
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Sophie Bremer
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-httpauth-digest-04.txt=
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 30
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2014-01-19

Abstract:
=A0 =A0HTTP provides a simple challenge-response authentication mechanism =A0 =A0that may be used by a server to challenge a client request and by a<= br> =A0 =A0client to provide authentication information. This document defines<= br> =A0 =A0the HTTP Digest Authentication scheme that may be used with the
=A0 =A0authentication mechanism.




The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest= /

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-httpauth-digest-04
A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-httpauth-= digest-04


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
http-auth mailing list
http-auth@ietf.org
https://www.ietf.org/mailman/listinfo/http-auth

--047d7b343aae8c204104f05817e5-- From julian.reschke@gmx.de Sun Jan 19 23:15:05 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 181011A005B for ; Sun, 19 Jan 2014 23:15:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oiXCVb8C2Kx2 for ; Sun, 19 Jan 2014 23:15:03 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 5B8341A005D for ; Sun, 19 Jan 2014 23:15:03 -0800 (PST) Received: from [192.168.2.117] ([84.187.52.61]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Mb31L-1Vm65V0Fjf-00Kik9 for ; Mon, 20 Jan 2014 08:15:02 +0100 Message-ID: <52DCCCF4.8010903@gmx.de> Date: Mon, 20 Jan 2014 08:15:00 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Yoav Nir , Rifaat Shekh-Yusef References: <20140119154616.17634.28278.idtracker@ietfa.amsl.com> <52DBFF2E.8000703@gmx.de> <17F25A58-4DE7-4160-9CD4-001A3CBC369D@checkpoint.com> In-Reply-To: <17F25A58-4DE7-4160-9CD4-001A3CBC369D@checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:YVC4xKQxZP04DqRmFBvnVue7LQ0rEkYIo4N5oT4PBZqXhkCKIzc Io0Y8sBid1t9IqxlxSsgsDqtCA73UFA95LNF6dsuj/ZsXw1xyZH64QjOTbVGI8Hx2QVGuXE H9/oNVyS8868mNLm47fPmMSaiFnABAejuzMsJuHL+mh2MpOuocerLO638G+V/NndwmDLioP 4pPvHAyuDu7laYK3a3cCg== Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-03.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 07:15:05 -0000 On 2014-01-19 17:49, Yoav Nir wrote: > > On Jan 19, 2014, at 6:37 PM, Julian Reschke wrote: > >> On 2014-01-19 16:48, Rifaat Shekh-Yusef wrote: >>> Hi, >>> >>> I think that I have addressed all the comments that I have received on >>> the mailing list so far. >>> Please, take a look and let us know if you have any further comments. >>> >>> Regards, >>> Rifaat >> >> a) The RFC 2617 reference can't be normative (we're replacing parts of it) > > Moreover, we (as in "http-auth") are entirely replacing 2617, so it shouldn't be referenced at all. > ... Yes, it should. This is an update of a (part of a) standards track RFC, so we really need a section summarizing what changed. Related to that: right now the boilerplate says that the document obsoletes RFC 2617. That is incorrect, because the framework is obsoleted by HTTPbis P7, and the bits about the "Basic" scheme are in yet another document. Best regards, Julian From ynir@checkpoint.com Mon Jan 20 00:25:10 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EA5E1A009C for ; Mon, 20 Jan 2014 00:25:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.436 X-Spam-Level: X-Spam-Status: No, score=-7.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDZZd77gULSX for ; Mon, 20 Jan 2014 00:25:09 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id AFE361A009B for ; Mon, 20 Jan 2014 00:25:08 -0800 (PST) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id s0K8OrHB029688; Mon, 20 Jan 2014 10:24:54 +0200 X-CheckPoint: {52DCD76A-4-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.110]) by IL-EX10.ad.checkpoint.com ([169.254.2.228]) with mapi id 14.03.0123.003; Mon, 20 Jan 2014 10:24:53 +0200 From: Yoav Nir To: Julian Reschke Thread-Topic: [http-auth] I-D Action: draft-ietf-httpauth-digest-03.txt Thread-Index: AQHPFS2XRvpzc7+/pUCDNH9/kru74ZqMD94AgAANmwCAAAOQgIAA8b0AgAATiAA= Date: Mon, 20 Jan 2014 08:24:53 +0000 Message-ID: <32014D9E-5D78-4CF0-B860-F2D906A70C87@checkpoint.com> References: <20140119154616.17634.28278.idtracker@ietfa.amsl.com> <52DBFF2E.8000703@gmx.de> <17F25A58-4DE7-4160-9CD4-001A3CBC369D@checkpoint.com> <52DCCCF4.8010903@gmx.de> In-Reply-To: <52DCCCF4.8010903@gmx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [91.90.139.159] x-kse-antivirus-interceptor-info: protection disabled Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-03.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 08:25:10 -0000 On Jan 20, 2014, at 9:15 AM, Julian Reschke wrote: > On 2014-01-19 17:49, Yoav Nir wrote: >>=20 >> On Jan 19, 2014, at 6:37 PM, Julian Reschke wrot= e: >>=20 >>> On 2014-01-19 16:48, Rifaat Shekh-Yusef wrote: >>>> Hi, >>>>=20 >>>> I think that I have addressed all the comments that I have received on >>>> the mailing list so far. >>>> Please, take a look and let us know if you have any further comments. >>>>=20 >>>> Regards, >>>> Rifaat >>>=20 >>> a) The RFC 2617 reference can't be normative (we're replacing parts of = it) >>=20 >> Moreover, we (as in "http-auth") are entirely replacing 2617, so it shou= ldn't be referenced at all. > > ... >=20 > Yes, it should. This is an update of a (part of a) standards track RFC, s= o we really need a section summarizing what changed. >=20 > Related to that: right now the boilerplate says that the document obsolet= es RFC 2617. That is incorrect, because the framework is obsoleted by HTTPb= is P7, and the bits about the "Basic" scheme are in yet another document. But all three documents taken together will obsolete 2617, so it's fine for= each of their boilerplates to carry the "Obsoletes: 2617". I don't know at= what point in time all three will get published (Basic and Digest have to = wait for p7, but not the other way around), but once they are, there will b= e no need to read 2617, which is the definition of "Obsoletes". Yoav From julian.reschke@gmx.de Mon Jan 20 00:45:23 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB9C1A00A3 for ; Mon, 20 Jan 2014 00:45:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWljtrKDXa1E for ; Mon, 20 Jan 2014 00:45:21 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 2D64F1A009F for ; Mon, 20 Jan 2014 00:45:21 -0800 (PST) Received: from [192.168.2.117] ([84.187.52.61]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LsgvV-1VL13C1CNl-012Fkf for ; Mon, 20 Jan 2014 09:45:20 +0100 Message-ID: <52DCE212.50703@gmx.de> Date: Mon, 20 Jan 2014 09:45:06 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Yoav Nir References: <20140119154616.17634.28278.idtracker@ietfa.amsl.com> <52DBFF2E.8000703@gmx.de> <17F25A58-4DE7-4160-9CD4-001A3CBC369D@checkpoint.com> <52DCCCF4.8010903@gmx.de> <32014D9E-5D78-4CF0-B860-F2D906A70C87@checkpoint.com> In-Reply-To: <32014D9E-5D78-4CF0-B860-F2D906A70C87@checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:SkidW1Cv5EsVRbCZzkLJUrP93TZ29JF8D4prxFi4XqADW+6A0qe WM6u27yp22OaykLqe2vua21Tn5/q8vDC8aBNCih42/PiFHD9+NDuKIfCS0JOOcMCgWzIecu 5sC2YQ0KJEXtMEcSjdS7qYHI47TeV1opNkF0WzYv9e8fm6neUYRZCnBade6OwRfXIHqEG+m +soqD7MhnRsVW91glDTNA== Cc: "http-auth@ietf.org" , Barry Leiba Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-03.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 08:45:23 -0000 On 2014-01-20 09:24, Yoav Nir wrote: > > On Jan 20, 2014, at 9:15 AM, Julian Reschke wrote: > >> On 2014-01-19 17:49, Yoav Nir wrote: >>> >>> On Jan 19, 2014, at 6:37 PM, Julian Reschke wrote: >>> >>>> On 2014-01-19 16:48, Rifaat Shekh-Yusef wrote: >>>>> Hi, >>>>> >>>>> I think that I have addressed all the comments that I have received on >>>>> the mailing list so far. >>>>> Please, take a look and let us know if you have any further comments. >>>>> >>>>> Regards, >>>>> Rifaat >>>> >>>> a) The RFC 2617 reference can't be normative (we're replacing parts of it) >>> >>> Moreover, we (as in "http-auth") are entirely replacing 2617, so it shouldn't be referenced at all. >>> ... >> >> Yes, it should. This is an update of a (part of a) standards track RFC, so we really need a section summarizing what changed. >> >> Related to that: right now the boilerplate says that the document obsoletes RFC 2617. That is incorrect, because the framework is obsoleted by HTTPbis P7, and the bits about the "Basic" scheme are in yet another document. > > But all three documents taken together will obsolete 2617, so it's fine for each of their boilerplates to carry the "Obsoletes: 2617". I don't know at what point in time all three will get published (Basic and Digest have to wait for p7, but not the other way around), but once they are, there will be no need to read 2617, which is the definition of "Obsoletes". I'm not sure this is the case. For P7 we have concluded that it can't say "obsoletes" (cc'ing our AD). And no, P7 is past IESG review, so you shouldn't have to wait for it. Best regards Julian From julian.reschke@gmx.de Mon Jan 20 08:00:01 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98BB41A0191 for ; Mon, 20 Jan 2014 08:00:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EOM1wxUybFia for ; Mon, 20 Jan 2014 08:00:00 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id D3EF81A0162 for ; Mon, 20 Jan 2014 07:59:59 -0800 (PST) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MdK8t-1Vnsho1sQd-00IU4G for ; Mon, 20 Jan 2014 16:59:59 +0100 Message-ID: <52DD47FE.4010006@gmx.de> Date: Mon, 20 Jan 2014 16:59:58 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Rifaat Shekh-Yusef , "http-auth@ietf.org" References: <20140119194621.16691.85278.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:Tw22EdjRxMEW54tWEGVWc8aj3M0/J7HKx/Hfsc0icKZQ1li6h7U SCAboc6s0pfK9+jndQ/fxiW3SlTcZY58DOdoCfjYUGh0ogLn6F2fwHEXuqebuhcUPHvYlNE NW6CrE1b17nme3zy4ZaWOl6ANCImxY76Cze6LlBT2sA0mLxRrg6nNP+YHsYS7fVe4GANGFD 5u2CYDOkd474VeMX7KT2g== Subject: [http-auth] ABNF use, was: I-D Action: draft-ietf-httpauth-digest-04.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 16:00:01 -0000 On 2014-01-19 20:50, Rifaat Shekh-Yusef wrote: > Hi, > > Thank you all for great comments; we really appreciate that. > We believe that we addresses all the latest comments, and we also > expanded the examples section. > > Please, take a look and let us know if you have any further comments. > > Regards, > Rifaat > ... In , you have: AuthenticationInfo = "Authentication-Info" ":" auth-info auth-info = 1#(nextnonce | [ message-qop ] | [ response-auth ] | [ cnonce ] | [nonce-count] ) nextnonce = "nextnonce" "=" nonce-value response-auth = "rspauth" "=" response-digest response-digest = <"> *LHEX <"> However the spec never says what ABNF notation it uses. It *should* use RFC 5234, potentially using the extensions in . Please also keep in mind that we don't use implied whitespace anymore, and follow the guidelines in . Finally, you'll need to update the IANA registration for the header field. Best regards, Julian From julian.reschke@gmx.de Mon Jan 20 11:11:48 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1FB41A024D for ; Mon, 20 Jan 2014 11:11:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41U6LWzbP-lq for ; Mon, 20 Jan 2014 11:11:46 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id CADA51A025A for ; Mon, 20 Jan 2014 11:11:45 -0800 (PST) Received: from [192.168.2.117] ([93.217.73.45]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MZfZi-1VkulS2UWc-00LY9n for ; Mon, 20 Jan 2014 20:11:45 +0100 Message-ID: <52DD74EE.6050500@gmx.de> Date: Mon, 20 Jan 2014 20:11:42 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Yoav Nir References: <20140119154616.17634.28278.idtracker@ietfa.amsl.com> <52DBFF2E.8000703@gmx.de> <17F25A58-4DE7-4160-9CD4-001A3CBC369D@checkpoint.com> <52DCCCF4.8010903@gmx.de> <32014D9E-5D78-4CF0-B860-F2D906A70C87@checkpoint.com> <52DCE212.50703@gmx.de> In-Reply-To: <52DCE212.50703@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:noYaU6tEa3TIs9feuBLOZ6AgVdXtqsk/kv8qNMezsRL7VyI3gz3 inCGykkD5ytpFDwQiJ8ol0xIsiRfFYf55YXtkjv6mQfB19MAgU/T3enBwGHbH5s1o8O7+oL y7widX3S1IMpgpH1wmVR+gy+UE7NG6x3TyPpsBH388OlPVdnLX/8vfAWlyxXT1J+sEMHt2T ho2giCK9DPDgIrmZ5O0Cw== Cc: Mark Nottingham , "http-auth@ietf.org" , Barry Leiba Subject: [http-auth] obsoleting RFC 2617, was: I-D Action: draft-ietf-httpauth-digest-03.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 19:11:48 -0000 On 2014-01-20 09:45, Julian Reschke wrote: >> But all three documents taken together will obsolete 2617, so it's >> fine for each of their boilerplates to carry the "Obsoletes: 2617". I >> don't know at what point in time all three will get published (Basic >> and Digest have to wait for p7, but not the other way around), but >> once they are, there will be no need to read 2617, which is the >> definition of "Obsoletes". > > I'm not sure this is the case. For P7 we have concluded that it can't > say "obsoletes" (cc'ing our AD). > > And no, P7 is past IESG review, so you shouldn't have to wait for it. > ... Assuming a) We don't want to make any HTTPbis change that risks a delay in publication, and b) We want the RFC database to contain useful pointers. My proposal would be: 1) Leave P7 as is 2) In the Digest spec, state that the set P7/Basic/Digest obsoletes 2617, and have a normative ref to the Basic spec. 3) In the Basic spec, state that the set P7/Basic/Digest obsoletes 2617, and have a normative ref to the Digest spec. This will make sure that the obsoletion doesn't happen to early, and that the pointers actually lead to the documents that are relevant (although indirectly for P7). And yes, I'll get to Basic once HTTPbis is in the publication queue. Best regards, Julian From rifaat.ietf@gmail.com Mon Jan 20 11:35:24 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 933F01A0216 for ; Mon, 20 Jan 2014 11:35:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5IdVcFwvVmbE for ; Mon, 20 Jan 2014 11:35:22 -0800 (PST) Received: from mail-ee0-x22b.google.com (mail-ee0-x22b.google.com [IPv6:2a00:1450:4013:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id C51751A01F1 for ; Mon, 20 Jan 2014 11:35:21 -0800 (PST) Received: by mail-ee0-f43.google.com with SMTP id c41so3631721eek.16 for ; Mon, 20 Jan 2014 11:35:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0LwL6sV4+ZMvJ7HhjmWVFnXz6ExzcAKnJ1Krrqo6UM4=; b=DfSPkiWO82i6YuTzWbIqM/Uah9CyH2PsuRDasEBj0288nAaEF8ARj5qhVT62ofZE0t dPXac3HCvXTAEDsjOLc+RzZeTj0jNKHvccX3x5Muf3PE13joeUevnYVKo5TbEqi6os6R aokkBDnMZ0PcG1B3OVMcg7XfyRK59lxYVFAFWjynK9SHf59S2EWmUBPS+8ydXM1g1wIb y807yoQ5MYHhKB0clHdGXGALeuEyC8Hw81QNZ+o5eE0vPTy3k/gqMP/oLrwqXHRKvdkg EZbgn68AuyCu7KNIigZQZY/YZ5JueFgbybRI1wvzWxe4o5BSQeWQZKbsdnM9fEQ77yea v/dA== MIME-Version: 1.0 X-Received: by 10.15.56.132 with SMTP id y4mr14184688eew.61.1390246521505; Mon, 20 Jan 2014 11:35:21 -0800 (PST) Received: by 10.14.53.78 with HTTP; Mon, 20 Jan 2014 11:35:21 -0800 (PST) In-Reply-To: <52DD74EE.6050500@gmx.de> References: <20140119154616.17634.28278.idtracker@ietfa.amsl.com> <52DBFF2E.8000703@gmx.de> <17F25A58-4DE7-4160-9CD4-001A3CBC369D@checkpoint.com> <52DCCCF4.8010903@gmx.de> <32014D9E-5D78-4CF0-B860-F2D906A70C87@checkpoint.com> <52DCE212.50703@gmx.de> <52DD74EE.6050500@gmx.de> Date: Mon, 20 Jan 2014 14:35:21 -0500 Message-ID: From: Rifaat Shekh-Yusef To: Julian Reschke Content-Type: multipart/alternative; boundary=001a11c3fb70108b6704f06bfe03 Cc: Mark Nottingham , "http-auth@ietf.org" , Barry Leiba Subject: Re: [http-auth] obsoleting RFC 2617, was: I-D Action: draft-ietf-httpauth-digest-03.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 19:35:24 -0000 --001a11c3fb70108b6704f06bfe03 Content-Type: text/plain; charset=ISO-8859-1 > 2) In the Digest spec, state that the set P7/Basic/Digest obsoletes 2617, and have a normative ref to the Basic spec. Just to make sure I understand your proposal: In the Abstract, we would state that the set P7/Basic/Digest obsoletes 2617, and we would keep the Obsoletes line on the front page? This sounds like a reasonable approach to me. Regards, Rifaat On Mon, Jan 20, 2014 at 2:11 PM, Julian Reschke wrote: > On 2014-01-20 09:45, Julian Reschke wrote: > >> But all three documents taken together will obsolete 2617, so it's >>> fine for each of their boilerplates to carry the "Obsoletes: 2617". I >>> don't know at what point in time all three will get published (Basic >>> and Digest have to wait for p7, but not the other way around), but >>> once they are, there will be no need to read 2617, which is the >>> definition of "Obsoletes". >>> >> >> I'm not sure this is the case. For P7 we have concluded that it can't >> say "obsoletes" (cc'ing our AD). >> >> And no, P7 is past IESG review, so you shouldn't have to wait for it. >> ... >> > > Assuming > > a) We don't want to make any HTTPbis change that risks a delay in > publication, > > and > > b) We want the RFC database to contain useful pointers. > > My proposal would be: > > 1) Leave P7 as is > > 2) In the Digest spec, state that the set P7/Basic/Digest obsoletes 2617, > and have a normative ref to the Basic spec. > > 3) In the Basic spec, state that the set P7/Basic/Digest obsoletes 2617, > and have a normative ref to the Digest spec. > > This will make sure that the obsoletion doesn't happen to early, and that > the pointers actually lead to the documents that are relevant (although > indirectly for P7). > > And yes, I'll get to Basic once HTTPbis is in the publication queue. > > Best regards, Julian > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > --001a11c3fb70108b6704f06bfe03 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
> 2) In the Digest spec, state that the set P7/Basic/Di= gest obsoletes 2617, and have a normative ref to the Basic spec.

Just to make sure = I understand your proposal:
In the Abstract, we would state that the set P7/= Basic/Digest obsoletes 2617, and we would keep the Obsoletes line on the fr= ont page?
This sounds like a reasonable app= roach to me.

Regards,
=A0Rifaat


=
On Mon, Jan 20, 2014 at 2:11 PM, Julian Reschke <julian.reschke@gmx.de= > wrote:
On 2014-01-20 09:45, Julian Reschke wrote:
But all three documents taken together will obsolete 2617, so it's
fine for each of their boilerplates to carry the "Obsoletes: 2617"= ;. I
don't know at what point in time all three will get published (Basic and Digest have to wait for p7, but not the other way around), but
once they are, there will be no need to read 2617, which is the
definition of "Obsoletes".

I'm not sure this is the case. For P7 we have concluded that it can'= ;t
say "obsoletes" (cc'ing our AD).

And no, P7 is past IESG review, so you shouldn't have to wait for it. ...

Assuming

a) We don't want to make any HTTPbis change that risks a delay in publi= cation,

and

b) We want the RFC database to contain useful pointers.

My proposal would be:

1) Leave P7 as is

2) In the Digest spec, state that the set P7/Basic/Digest obsoletes 261= 7, and have a normative ref to the Basic spec.

3) In the Basic spec, state that the set P7/Basic/Digest obsoletes 2617, an= d have a normative ref to the Digest spec.

This will make sure that the obsoletion doesn't happen to early, and th= at the pointers actually lead to the documents that are relevant (although = indirectly for P7).

And yes, I'll get to Basic once HTTPbis is in the publication queue.
Best regards, Julian

_______________________________________________
http-auth mailing list
http-auth@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/http-auth

--001a11c3fb70108b6704f06bfe03-- From julian.reschke@gmx.de Mon Jan 20 12:28:16 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B57BB1A024D for ; Mon, 20 Jan 2014 12:28:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C2gQwS-XZMkV for ; Mon, 20 Jan 2014 12:28:15 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id B94BD1A0169 for ; Mon, 20 Jan 2014 12:28:14 -0800 (PST) Received: from [192.168.2.117] ([93.217.73.45]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Lat5o-1VceTl2B6O-00kRzY for ; Mon, 20 Jan 2014 21:28:13 +0100 Message-ID: <52DD86DA.5090005@gmx.de> Date: Mon, 20 Jan 2014 21:28:10 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Rifaat Shekh-Yusef References: <20140119154616.17634.28278.idtracker@ietfa.amsl.com> <52DBFF2E.8000703@gmx.de> <17F25A58-4DE7-4160-9CD4-001A3CBC369D@checkpoint.com> <52DCCCF4.8010903@gmx.de> <32014D9E-5D78-4CF0-B860-F2D906A70C87@checkpoint.com> <52DCE212.50703@gmx.de> <52DD74EE.6050500@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:6n3g7MtL1Qhle+hNOzkqggJDmVcprtakOuxeFYZzOsE2Ztv0NBE jaNrJuZiTc2VmgBf4T1LQ7HoxtF2d085xUhP+AC6H8D5tf38JsvacZgVL6I7YtgQSMz0UpV z7MK2Nkjqlk9lUD8Hrv1pb5ugZgAzHQxoS9CT7tjXfxaVQ2tipUPvK0OCTnzaVunxLFob6b gtesvZPKDZyfIlXoj0zcg== Cc: Mark Nottingham , "http-auth@ietf.org" , Barry Leiba Subject: Re: [http-auth] obsoleting RFC 2617, was: I-D Action: draft-ietf-httpauth-digest-03.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 20:28:16 -0000 On 2014-01-20 20:35, Rifaat Shekh-Yusef wrote: > > 2) In the Digest spec, state that the set P7/Basic/Digest obsoletes > 2617, and have a normative ref to the Basic spec. > > Just to make sure I understand your proposal: > In the Abstract, we would state that the set P7/Basic/Digest obsoletes > 2617, and we would keep the Obsoletes line on the front page? > This sounds like a reasonable approach to me. > ... Yes, something like that... Best regards, Julian From julian.reschke@gmx.de Tue Jan 21 03:30:55 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 018F31A00B9 for ; Tue, 21 Jan 2014 03:30:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5PPU0pYcFOgW for ; Tue, 21 Jan 2014 03:30:53 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 10FFE1A00B8 for ; Tue, 21 Jan 2014 03:30:53 -0800 (PST) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Ldbqw-1VenIP0r7S-00ijPP for ; Tue, 21 Jan 2014 12:30:51 +0100 Message-ID: <52DE5A67.9070403@gmx.de> Date: Tue, 21 Jan 2014 12:30:47 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Rifaat Shekh-Yusef References: <20140119154616.17634.28278.idtracker@ietfa.amsl.com> <52DBFF2E.8000703@gmx.de> <17F25A58-4DE7-4160-9CD4-001A3CBC369D@checkpoint.com> <52DCCCF4.8010903@gmx.de> <32014D9E-5D78-4CF0-B860-F2D906A70C87@checkpoint.com> <52DCE212.50703@gmx.de> <52DD74EE.6050500@gmx.de> <52DD86DA.5090005@gmx.de> In-Reply-To: <52DD86DA.5090005@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:nDB3369iOpq0cz7l+g38KVEcDbEZ+GHHn6RY6QzIQ3+7GINtM4r 0bqkIK4A9+neLww4jusLRPSqcEuXF+G0cXNPMRxdbbge7yAv8xvktsq8dhZbEjp9r+Uw5IY i2T3E4ZWElgVHkwJ/otEYQDEiJ+CVMXZwqZf9JFJuNkYKaPGK4BRiC36QR7KDlwAa8As1DY KkCYMbDsP9LBDVO5yPWNA== Cc: Mark Nottingham , "http-auth@ietf.org" , Barry Leiba Subject: Re: [http-auth] obsoleting RFC 2617, was: I-D Action: draft-ietf-httpauth-digest-03.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 11:30:55 -0000 On 2014-01-20 21:28, Julian Reschke wrote: > On 2014-01-20 20:35, Rifaat Shekh-Yusef wrote: >> > 2) In the Digest spec, state that the set P7/Basic/Digest obsoletes >> 2617, and have a normative ref to the Basic spec. >> >> Just to make sure I understand your proposal: >> In the Abstract, we would state that the set P7/Basic/Digest obsoletes >> 2617, and we would keep the Obsoletes line on the front page? >> This sounds like a reasonable approach to me. >> ... > > Yes, something like that... See . Best regards, Julian From ynir@checkpoint.com Tue Jan 21 03:49:14 2014 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2430B1A00BE for ; Tue, 21 Jan 2014 03:49:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.436 X-Spam-Level: X-Spam-Status: No, score=-7.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cfwuG_Ch24A7 for ; Tue, 21 Jan 2014 03:49:12 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE1F1A009A for ; Tue, 21 Jan 2014 03:49:12 -0800 (PST) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id s0LBmwOd019471; Tue, 21 Jan 2014 13:48:58 +0200 X-CheckPoint: {52DE58AD-1A-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.110]) by IL-EX10.ad.checkpoint.com ([169.254.2.228]) with mapi id 14.03.0123.003; Tue, 21 Jan 2014 13:48:58 +0200 From: Yoav Nir To: Rifaat Shekh-Yusef Thread-Topic: [http-auth] obsoleting RFC 2617, was: I-D Action: draft-ietf-httpauth-digest-03.txt Thread-Index: AQHPFpxMrdXNpzJ61EmYzHwCjpFsRZqO7sGA Date: Tue, 21 Jan 2014 11:48:57 +0000 Message-ID: <7CC9FE8B-0DCF-4DA7-8988-FC7C60E3CA2D@checkpoint.com> References: <20140119154616.17634.28278.idtracker@ietfa.amsl.com> <52DBFF2E.8000703@gmx.de> <17F25A58-4DE7-4160-9CD4-001A3CBC369D@checkpoint.com> <52DCCCF4.8010903@gmx.de> <32014D9E-5D78-4CF0-B860-F2D906A70C87@checkpoint.com> <52DCE212.50703@gmx.de> <52DD74EE.6050500@gmx.de> <52DD86DA.5090005@gmx.de> <52DE5A67.9070403@gmx.de> In-Reply-To: <52DE5A67.9070403@gmx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.2] x-kse-antivirus-interceptor-info: protection disabled Content-Type: text/plain; charset="us-ascii" Content-ID: <16EE7AAC44E93844ADF7F0B38B574637@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Julian Reschke , Mark Nottingham , "http-auth@ietf.org" , Barry Leiba Subject: Re: [http-auth] obsoleting RFC 2617, was: I-D Action: draft-ietf-httpauth-digest-03.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 11:49:14 -0000 On Jan 21, 2014, at 1:30 PM, Julian Reschke wrote: > On 2014-01-20 21:28, Julian Reschke wrote: >> On 2014-01-20 20:35, Rifaat Shekh-Yusef wrote: >>> > 2) In the Digest spec, state that the set P7/Basic/Digest obsoletes >>> 2617, and have a normative ref to the Basic spec. >>>=20 >>> Just to make sure I understand your proposal: >>> In the Abstract, we would state that the set P7/Basic/Digest obsoletes >>> 2617, and we would keep the Obsoletes line on the front page? >>> This sounds like a reasonable approach to me. >>> ... >>=20 >> Yes, something like that... >=20 > See . >=20 > Best regards, Julian Right. And just as in Julian's example, please state this in the Introducti= on, rather than the Abstract. Yoav