From nobody Sun Apr 6 05:17: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 9BB7E1A03EE for ; Sun, 6 Apr 2014 05:17:55 -0700 (PDT) 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 z-NGaazz9uzO for ; Sun, 6 Apr 2014 05:17:50 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA5A1A03DF for ; Sun, 6 Apr 2014 05:17:50 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hi2so3611737wib.5 for ; Sun, 06 Apr 2014 05:17:44 -0700 (PDT) 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=DcBiAf7lD0vtic9BuSlknmg3akgdSvpIkuNeN/695aM=; b=uf3RvH99OFmDyRbfa/YE/uMlB4JdXDGrqbxCHr+eUbjN1EE5j7WTpzWLH3z99vi1K+ 119RTTMyIDQzOXlVO+AMZQYcqeYrx4qyWSsq18SGlYy+061pJ5OEODZRXXf8x3RI/n6Q OdPujtw/W7YjDJ2tsZvnoyFHoygKiCPp1BDc5b6P4I9mwWX5/62E9qipMtu+g7gw1e5x AZREiWR21QrZDuorSWHeYUfHEp86KeQk+nTzx4eTd/h2qdeKn8eS9VMNWKwPxN+hZAL8 J3g3UpZQZltYE00znQFa2RELGcrssgPO7UoN8Mk3AU/cZtdHJJvkmSXz6oe2WEKXlkOJ UJ8w== MIME-Version: 1.0 X-Received: by 10.194.80.7 with SMTP id n7mr35008381wjx.8.1396786664444; Sun, 06 Apr 2014 05:17:44 -0700 (PDT) Received: by 10.14.149.11 with HTTP; Sun, 6 Apr 2014 05:17:44 -0700 (PDT) Date: Sun, 6 Apr 2014 08:17:44 -0400 Message-ID: From: Rifaat Shekh-Yusef To: Matthew Lepinski Content-Type: multipart/alternative; boundary=047d7beb9c80f6169404f65ebc5e Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/EsApIOCzLXFi39do592pKMcR_d0 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Draft Minutes Posted for IETF 89 - HTTP Digest 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, 06 Apr 2014 12:17:55 -0000 --047d7beb9c80f6169404f65ebc5e Content-Type: text/plain; charset=ISO-8859-1 Here is my reply to the Digest minutes: > ***** Digest Update by Rifaat Shekh-Yusef > draft-ietf-httpauth-digest-01 > Slides: http://www.ietf.org/proceedings/89/slides/slides-89-httpauth-2.pdf > > -- Preference in the IANA registry > > -- For "specification required" seems like a low-bar to set preference > > -- Also, does preference need to change if we come up with attacks against an algorithm > > -- Sean Turner (AD): Destroy Preference from the registry. Put preference into RFCs not registry > Will take the Preference field out of the registry. > -- Question: Is backward compatibility (2069 RFC -- pre 2617) required? > Will remove the backward compatibility with RFC2069. > -- Username hash was added for privacy reasons > ... does the Server have the information it needs to look up the right entry from the password file? > > -- Concern about DoS if the client can force server computation based on a simple query with an arbitrary garbage string > > -- Resolution: We need more discussion about server processing and the trade off between privacy and performance > The current text requires the following calculations: Server: H( username | realm ) Client: H( H( username | realm ) | nonce) If we require client to perform the same calculations done by the server, H( username | realm ), that will reduce the load on the server as the server can use that calculation to directly look up the user without any further hashing operations. Any thoughts? > -- Do we need an optional parameter with only one value? > If we are going to do UTF-8, document UTF-8 and don't put in the parameter > > Chair: Need a flag to distinguish new UTF-8 digest from old digest > > Could we have a flag instead of a parameter? Compatibility with some existing spec (in another organization) used for the same purpose > I am not sure that I understand this comment. What is the problem with the current approach? > -- Normalization > Precis working group is just about finished. > Sean Turner (AD) says that work "Will" be used here > ... Apps ADs will surely require us to use the new work from Precis > > -- Precis chairs are Marc Blanchet and Yoshiro Yoneya > > -- Julian: We need something that is implementable in reality. > > -- Username hiding also has an issue if different browsers encode non-UTF-8 differently > Little Hope of server finding the right username > Can we use the same text provided by Julian for the Basic scheme? "The only allowed value is "UTF-8", to be matched case-insensitively (see [RFC2978], Section 2.3). It indicates that the server expects user name and password to be converted to Unicode Normalization Form C ("NFC", see Section 3 of [RFC5198]) and to be encoded into octets using the UTF-8 character encoding scheme ([RFC3629])." Regards, Rifaat On Mon, Mar 31, 2014 at 5:47 PM, Matthew Lepinski wrote: > The draft minutes for the HTTPAUTH session have been posted to the > proceedings tool. > > The draft minutes can be found here: > http://www.ietf.org/proceedings/89/minutes/minutes-89-httpauth > > If you identify any corrections that need to be made in the minutes, > please send them to the list. > > - Yoav and Matt > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > > --047d7beb9c80f6169404f65ebc5e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Here is my reply to the Digest = minutes:


> ***= ** Digest Update by Rifaat Shekh-Yusef
> draft-ietf-httpauth-digest-01
>=A0
> -- = Preference in the IANA registry
>=A0
> -- For "specification required"= seems like a low-bar to set preference
>=A0
> -- = Also, does preference need to change if we come up with attacks against an = algorithm
>=A0
> -- Sean Turner (AD): Destroy Preference from the registry. Put prefere= nce into RFCs not registry
>=A0

Will take the Preference field out of the regi= stry.

=
> -- Question: Is backward compatibility (206= 9 RFC -- pre 2617) required?
>=A0
<= div class=3D"gmail_extra">
Will remove = the backward compatibility with RFC2069.


<= div class=3D"gmail_extra">
> -- User= name hash was added for privacy reasons
>= ; =A0 =A0... does the Server have the information it needs to look up the r= ight entry from the password file?
>=A0
> -- = Concern about DoS if the client can force server computation based on a sim= ple query with an arbitrary garbage string
= >=A0
> -- Resolution: We need more discussion abou= t server processing and the trade off between privacy and performance
=
>=A0

The current text requires the following calculations:

= =A0 =A0Server:=A0H( username | = realm )
=A0 =A0Client:=A0 H( H( usernam= e | realm ) | nonce)

If we require client to perform the same calculations done= by the server, H( username | realm ), that will reduce the load on the ser= ver as the server can use that calculation to directly look up the user wit= hout any further hashing operations.
Any thoughts?

> -- Do we need = an optional parameter with only one value?
> =A0 =A0If we are going to do UTF-8, document UTF-8 and don't put i= n the parameter=A0
> =A0
> =A0 =A0Chair: Need a flag to distinguish new UTF-8 di= gest from old digest
> =A0 =A0
>= ; =A0 =A0Could we have a flag instead of a parameter? Compatibility with so= me existing spec (in another organization) used for the same purpose
<= div class=3D"gmail_extra"> >=A0

I am not sure that I understand this comment. What is the problem with th= e current approach?


> -- Normalization
> =A0 =A0Precis working group is just about finished.= =A0
> =A0 =A0Sean Turner (AD) says that = work "Will" be used here
> =A0 =A0 =A0 ... Apps ADs will surely requir= e us to use the new work from Precis
>= =A0
> -- Precis chairs are Marc Blanchet= and Yoshiro Yoneya
>=A0
> -- = Julian: We need something that is implementable in reality.=A0
>=A0
> -- Usernam= e hiding also has an issue if different browsers encode non-UTF-8 different= ly
> =A0 =A0Little Hope of server finding the ri= ght username=A0
> =A0 =A0 =A0
=
Can we use the same text provided by Julian for the Basic sc= heme?

=A0 =A0"The only allowed value is "UTF-8", to be matche= d case-insensitively
=A0 =A0(see [RF= C2978], Section 2.3). =A0It indicates that the server expects
=A0 =A0user name and password to be con= verted to Unicode Normalization Form
=A0 =A0C ("= ;NFC", see Section 3 of [RFC5198]) and to be encoded into octets
=A0 =A0using the UTF-8 characte= r encoding scheme ([RFC3629])."


Regards,
=A0Rifaat
=




On Mon, Mar 31, 2014 at 5:47 P= M, Matthew Lepinski <mlepinski.ietf@gmail.com> wrote:=
The draft minutes for the HTTPAUTH sessio= n have been posted to the proceedings tool.=A0

The draft minutes can be found here:=A0
http://www.ietf.org/proceedings/89/minutes/minutes-89-httpauth<= /div>

If you identify any corrections that need to be made in= the minutes, please send them to the list.

- Yoav a= nd Matt

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


--047d7beb9c80f6169404f65ebc5e-- From nobody Wed Apr 9 16:39:45 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 1DFD41A04C5; Wed, 9 Apr 2014 16:39:42 -0700 (PDT) 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 ohpW9_Yu4hOb; Wed, 9 Apr 2014 16:39:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C5E871A0118; Wed, 9 Apr 2014 16:39:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140409233940.29095.70810.idtracker@ietfa.amsl.com> Date: Wed, 09 Apr 2014 16:39:40 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/2WoK__b0kEyepjO3ZL9JAv182lU Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-digest-06.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, 09 Apr 2014 23:39:42 -0000 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-06.txt Pages : 30 Date : 2014-04-09 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-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-digest-06 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 nobody Wed Apr 9 16:42: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 084091A03D3 for ; Wed, 9 Apr 2014 16:42:23 -0700 (PDT) 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 e0es9BJljl09 for ; Wed, 9 Apr 2014 16:42:20 -0700 (PDT) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) by ietfa.amsl.com (Postfix) with ESMTP id C46A41A04A8 for ; Wed, 9 Apr 2014 16:42:19 -0700 (PDT) Received: by mail-lb0-f178.google.com with SMTP id s7so1758112lbd.9 for ; Wed, 09 Apr 2014 16:42:18 -0700 (PDT) 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=dmjxp3gw4rbctVDe1X9+P56EulvirLgX7wITE6MaE5w=; b=rVQidAWM5Af2S8HcAgQ0GygiVHxsGmEv0Zg3wcLGWxQcATEgDQY4GyN7uUs5K6nzBl Wva19ltgXMpVjmuNEDEt1mmXwacSwYrkRcDHnyBBZPfJrkbNxBo7rz1u5BO8aJkeNpqU sUs9ZyAwnRA0oCP22Gfx5SCskh5sEvTYmaJLGEbUPqhjSqu1WAGvDfU7HLO6MRIVLPzN Wvqj89MkmxslTYsXLSVwYnnXwX27OvGFWIqStZBwvRdhOuATw6IF+T8An18NSL3u7Eb4 wsy1ufSEjVrUdAvzAsekeBsvh4BTfwOg61bK6i/CMMwToTDV71gDY419kqCj1kuLA1iS MMrw== MIME-Version: 1.0 X-Received: by 10.152.1.8 with SMTP id 8mr9523953lai.1.1397086938138; Wed, 09 Apr 2014 16:42:18 -0700 (PDT) Received: by 10.114.63.144 with HTTP; Wed, 9 Apr 2014 16:42:18 -0700 (PDT) In-Reply-To: <20140409233940.29095.70810.idtracker@ietfa.amsl.com> References: <20140409233940.29095.70810.idtracker@ietfa.amsl.com> Date: Wed, 9 Apr 2014 19:42:18 -0400 Message-ID: From: Rifaat Shekh-Yusef To: "http-auth@ietf.org" Content-Type: multipart/alternative; boundary=089e01228132ab110c04f6a4a622 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/I3dw_VQskoGWcnjpgthAqjUK0fY Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-06.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, 09 Apr 2014 23:42:23 -0000 --089e01228132ab110c04f6a4a622 Content-Type: text/plain; charset=ISO-8859-1 Hi, This new version of the draft addresses all the comments received during the last IETF meeting and based on my response to the Minutes of the meeting. Please, take a look and let us know if you have any comments. Regards, Rifaat On Wed, Apr 9, 2014 at 7:39 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-06.txt > Pages : 30 > Date : 2014-04-09 > > 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-06 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-digest-06 > > > 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 > --089e01228132ab110c04f6a4a622 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

This new version of the draft addre= sses all the comments received during the last IETF meeting and based on my= response to the Minutes of the meeting.
Please, take a look and = let us know if you have any comments.

Regards,
=A0Rifaat

=


On Wed, Apr 9= , 2014 at 7:39 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-06.txt=
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 30
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2014-04-09

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-06
A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-httpauth-= digest-06


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

--089e01228132ab110c04f6a4a622-- From nobody Wed Apr 9 21:33: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 CFAE41A008B for ; Wed, 9 Apr 2014 21:33:17 -0700 (PDT) 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 ybGHlp_YiyHC for ; Wed, 9 Apr 2014 21:33:14 -0700 (PDT) Received: from mail-ee0-x22f.google.com (mail-ee0-x22f.google.com [IPv6:2a00:1450:4013:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 970551A0439 for ; Wed, 9 Apr 2014 21:33:13 -0700 (PDT) Received: by mail-ee0-f47.google.com with SMTP id b15so2494784eek.20 for ; Wed, 09 Apr 2014 21:33:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=K6byv+SESSmEPgXlKj63ib+2RBoayLG58nrsReNOb+Y=; b=TVd49AbC5p01eEHx5m3NWXKJ/Itp+6v6yOOy044NUAl1cfHC+C/xj2th0cVWtNKK5j PrRxK0Ao3CmtnqpDMOcCBeNtohN2TLZjYgx0tOX4OyIicQ3ROag3dm3v1hrE7hs7lqx6 8d3x4RQsnMkzp9HbrWeGmk/1Wsr9Y1d1tddG2oTI20GqHTriGErYZu25ghIPtoVsIMGq xuBC90vviZW1ZcUcLdW5mOFcUmRSCCjZrZFw2BRsKVJNfEFu9n/7Dk574W7Em0gCy2Gd +S8qUOB1SG8zVP+2Wz0GtzdiZrmBjoRfzvkfI4tJ9MRH4ZiWXsXHR96pRmMnlo+nRWy2 IvUQ== X-Received: by 10.14.105.4 with SMTP id j4mr17810572eeg.41.1397104392392; Wed, 09 Apr 2014 21:33:12 -0700 (PDT) Received: from [192.168.243.52] ([192.116.177.210]) by mx.google.com with ESMTPSA id m44sm6917125eep.14.2014.04.09.21.33.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 09 Apr 2014 21:33:11 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_22FBB7D4-D54D-4E97-B2A4-7064551A0DB5" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Yoav Nir In-Reply-To: Date: Thu, 10 Apr 2014 07:33:09 +0300 Message-Id: <5D03487C-F52C-43B5-ABCD-AE0AA4E9C49F@gmail.com> References: <20140409233940.29095.70810.idtracker@ietfa.amsl.com> To: Rifaat Shekh-Yusef X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/93yc5bbCkoH9HJ5iqnCC9mEApmE Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-06.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: Thu, 10 Apr 2014 04:33:18 -0000 --Apple-Mail=_22FBB7D4-D54D-4E97-B2A4-7064551A0DB5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thanks, Rifaat Two comments: 1. Section 3.7 still lists algorithms in order of preference. While this = refers only to algorithms specified in this specification, and not to = any other algorithms someone might add, I=92m not sure we really need = this. How about this: OLD: This specification defines the following preference list, starting with the most preferred algorithm: * SHA2-256 * SHA2-512/256 * MD5 (for backward compatibility). NEW: This specification defines the following algorithm: * SHA2-256 (mandatory to implement) * SHA2-512/256 (as a backup algorithm) * MD5 (for backward compatibility). 2. In section 6.1 you have the initial registry with a column for = =93Digest Size=94. It took me a moment to figure out what these sizes = mean. They are the length in bytes of the hex-encoded response field in = the Authorization header. That=92s surprising. I would prefer that = digest size (if needed at all) be expressed in bits or bytes of the hash = function result (so 256 or 32 for SHA-256) rather than nibbles. Yoav On Apr 10, 2014, at 2:42 AM, Rifaat Shekh-Yusef = wrote: > Hi, >=20 > This new version of the draft addresses all the comments received = during the last IETF meeting and based on my response to the Minutes of = the meeting. > Please, take a look and let us know if you have any comments. >=20 > Regards, > Rifaat >=20 >=20 >=20 > On Wed, Apr 9, 2014 at 7:39 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-06.txt > Pages : 30 > Date : 2014-04-09 >=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-06 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-httpauth-digest-06 >=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 --Apple-Mail=_22FBB7D4-D54D-4E97-B2A4-7064551A0DB5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Thanks, Rifaat

Two = comments:

1. Section 3.7 still lists algorithms = in order of preference. While this refers only to algorithms specified = in this specification, and not to any other algorithms someone might = add, I=92m not sure we really need this. How about = this:

OLD:
   This specification defines the following =
preference list, starting
   with the most preferred algorithm:

      * SHA2-256
      * SHA2-512/256
      * MD5 (for backward =
compatibility).

NEW:
   This specification =
defines the following algorithm:

      * SHA2-256 (mandatory to implement)
      * SHA2-512/256 (as a backup algorithm)
      * MD5 (for backward =
compatibility).


2. In = section 6.1 you have the initial registry with a column for =93Digest = Size=94. It took me a moment to figure out what these sizes mean. They = are the length in bytes of the hex-encoded response field in the = Authorization header. That=92s surprising. I would prefer that digest = size (if needed at all) be expressed in bits or bytes of the hash = function result (so 256 or 32 for SHA-256) rather than = nibbles.

Yoav

On = Apr 10, 2014, at 2:42 AM, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> = wrote:

Hi,

This new version = of the draft addresses all the comments received during the last IETF = meeting and based on my response to the Minutes of the = meeting.
Please, take a look and let us know if you have any = comments.
=

Regards,
 Rifaat



On = Wed, Apr 9, 2014 at 7:39 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-06.txt
        Pages           : = 30
        Date           =  : 2014-04-09

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-06=

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


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

= = --Apple-Mail=_22FBB7D4-D54D-4E97-B2A4-7064551A0DB5-- From nobody Thu Apr 10 04:45:04 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 BF62E1A0220 for ; Thu, 10 Apr 2014 04:45:01 -0700 (PDT) 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 YPW7EjIU0s53 for ; Thu, 10 Apr 2014 04:44:58 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 348621A01CB for ; Thu, 10 Apr 2014 04:44:58 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id pv20so2199353lab.38 for ; Thu, 10 Apr 2014 04:44:56 -0700 (PDT) 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=jWfMFVhA98/BaBc0TrOZDk1EJj0PquxbRzsxOX/VAzA=; b=oN1sD/oGC8JsKyJdmsE+Bj4q5NQ0KhxiN3P1WqvPrPUq7MA2Y/cBVvAzDwZbzAi5bU ayc64uuV39oe8JLMbF3QcRnwBUdOOGLu0WU2LNUpVXVWTfWZr6zPFWxAZD62/ex88Ki0 q4/SkifQ35tqDaw0WJZW7UCPhE41ikCpKTSjquQduxXr4JwJEW0W7Hv7q/KElCTh+7br NBeHaQ+xjjL4xYzxlBToEBsJtG1BrvOXtpVdo4FdhEclL2j3yOfxC/YtDPFNWpIDqKPg 2U3sBbFxmsCVZYvXiVAX2V/JDXACo5OHiCLjRuKKufzdOkWHOIkSd5JwaqVsspoNLg0i nhRA== MIME-Version: 1.0 X-Received: by 10.152.23.227 with SMTP id p3mr12041872laf.31.1397130296710; Thu, 10 Apr 2014 04:44:56 -0700 (PDT) Received: by 10.114.63.144 with HTTP; Thu, 10 Apr 2014 04:44:56 -0700 (PDT) In-Reply-To: <5D03487C-F52C-43B5-ABCD-AE0AA4E9C49F@gmail.com> References: <20140409233940.29095.70810.idtracker@ietfa.amsl.com> <5D03487C-F52C-43B5-ABCD-AE0AA4E9C49F@gmail.com> Date: Thu, 10 Apr 2014 07:44:56 -0400 Message-ID: From: Rifaat Shekh-Yusef To: Yoav Nir Content-Type: multipart/alternative; boundary=089e0158ab5c0a5b1004f6aebf3f Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/jvtnx0Hc4Ocb2HtAqQFiA1yV7rs Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-06.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: Thu, 10 Apr 2014 11:45:01 -0000 --089e0158ab5c0a5b1004f6aebf3f Content-Type: text/plain; charset=ISO-8859-1 Thanks Yoav, I am fine with both comments. I will fix them in the next version of the draft. Regards, Rifaat On Thu, Apr 10, 2014 at 12:33 AM, Yoav Nir wrote: > Thanks, Rifaat > > Two comments: > > 1. Section 3.7 still lists algorithms in order of preference. While this > refers only to algorithms specified in this specification, and not to any > other algorithms someone might add, I'm not sure we really need this. How > about this: > > OLD: > > This specification defines the following preference list, starting > with the most preferred algorithm: > > * SHA2-256 > * SHA2-512/256 > * MD5 (for backward compatibility). > > > NEW: > > This specification defines the following algorithm: > > * SHA2-256 (mandatory to implement) > * SHA2-512/256 (as a backup algorithm) > * MD5 (for backward compatibility). > > > > 2. In section 6.1 you have the initial registry with a column for "Digest > Size". It took me a moment to figure out what these sizes mean. They are > the length in bytes of the hex-encoded response field in the Authorization > header. That's surprising. I would prefer that digest size (if needed at > all) be expressed in bits or bytes of the hash function result (so 256 or > 32 for SHA-256) rather than nibbles. > > Yoav > > > On Apr 10, 2014, at 2:42 AM, Rifaat Shekh-Yusef > wrote: > > Hi, > > This new version of the draft addresses all the comments received during > the last IETF meeting and based on my response to the Minutes of the > meeting. > Please, take a look and let us know if you have any comments. > > Regards, > Rifaat > > > > On Wed, Apr 9, 2014 at 7:39 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-06.txt >> Pages : 30 >> Date : 2014-04-09 >> >> 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-06 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-digest-06 >> >> >> 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 > > > --089e0158ab5c0a5b1004f6aebf3f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks Yoav,

I am fine with both commen= ts. I will fix them in the next version of the draft.

<= div>Regards,
 Rifaat
<= br>
On Thu, Apr 10, 2014 at 12:33 AM, Yoav Nir <y= nir.ietf@gmail.com> wrote:
Thanks, Rifaat

Two c= omments:

1. Section 3.7 still lists algorithms in = order of preference. While this refers only to algorithms specified in this= specification, and not to any other algorithms someone might add, I’= m not sure we really need this. How about this:

OLD:
   This specification defines the following preference lis=
t, starting
   with the most preferred algorithm:

      * SHA2-256
      * SHA2-512/256
      * MD5 (for backward compatibility).

NEW:
   Thi=
s specification defines the following algorithm:

      * SHA2-256 (mandatory to implement)
      * SHA2-512/256 (as a backup algorithm)
      * MD5 (for backward compatibility).

2. In section 6.1 you have the initial registry with a column = for “Digest Size”. It took me a moment to figure out what these= sizes mean. They are the length in bytes of the hex-encoded response field= in the Authorization header. That’s surprising. I would prefer that = digest size (if needed at all) be expressed in bits or bytes of the hash fu= nction result (so 256 or 32 for SHA-256) rather than nibbles.

Yoav


On Apr 10, 2014, at 2:42 AM= , Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

Hi,

This = new version of the draft addresses all the comments received during the las= t IETF meeting and based on my response to the Minutes of the meeting.
Please, take a look and let us know if you have any comments.

Regards,
 Rifaat



On Wed, Ap= r 9, 2014 at 7:39 PM, <internet-drafts@ietf.org> wro= te:

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 Authenti= cation Working Group of the IETF.

        Title           : HTTP= Digest Access Authentication
        Authors         : Rifaat Sh= ekh-Yusef
                     = ;     David Ahrens
                     = ;     Sophie Bremer
        Filename        : draft-iet= f-httpauth-digest-06.txt
        Pages           : 30         Date            := 2014-04-09

Abstract:
   HTTP provides a simple challenge-response authentication mecha= nism
   that may be used by a server to challenge a client request and= by a
   client to provide authentication information. This document de= fines
   the HTTP Digest Authentication scheme that may be used with th= e
   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-06
A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-httpauth-= digest-06


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


--089e0158ab5c0a5b1004f6aebf3f-- From nobody Thu Apr 10 22:24: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 B634E1A0390 for ; Thu, 10 Apr 2014 22:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.979 X-Spam-Level: X-Spam-Status: No, score=-0.979 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, 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 MH0HixFkjVtH for ; Thu, 10 Apr 2014 22:24:34 -0700 (PDT) Received: from na3sys010aog112.obsmtp.com (na3sys010aog112.obsmtp.com [74.125.245.92]) by ietfa.amsl.com (Postfix) with ESMTP id B39401A0280 for ; Thu, 10 Apr 2014 22:24:33 -0700 (PDT) Received: from mail-vc0-f173.google.com ([209.85.220.173]) (using TLSv1) by na3sys010aob112.postini.com ([74.125.244.12]) with SMTP ID DSNKU0d8kMV81i27hg0+TZamIUWyiARAj+OC@postini.com; Thu, 10 Apr 2014 22:24:33 PDT Received: by mail-vc0-f173.google.com with SMTP id il7so4446544vcb.32 for ; Thu, 10 Apr 2014 22:24:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:from:date:message-id:subject:to:content-type; bh=yZtihsUyLWuKV1WDF6W91mNyUoBZVZQsNQRTVfpxRHA=; b=H/Btbf9BV21JmH/1zfTqTDSse4aUC8gScz0e6SMnq+g93Briq2199WEub+fZFDKqww Yj3SmLp4oUSd4QLvKCUOqXXreO0kWd39LZfnOqrLjx02UJur/FGLumra9ZenYE0hcqGI /37C+4cyZSPGJF44MiUNLQiFV1mUyUvS9Sk1c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=yZtihsUyLWuKV1WDF6W91mNyUoBZVZQsNQRTVfpxRHA=; b=Er1DR3aLFcAMmzysFr9DVuAC1FEUWArEFLd9TDav2YoTpKjsCwF0b+XQwc9tv5R9G5 mCM3EzTnUSJiR1c9fxOuF7t2EpJv5CfP2AQrOJs8Bo06BIAEK2JDmxoETrLo2HVp+Cjb HtmqBiT4srfYrkyz1KgkoLAA+c5zOCwxx756mJZxQeSWU2Ca7o3FXtBBlwYdihwHrOPg qjvcVlXyfekH92UtWecN4spWyYatnnMt830MGjQP3W1mVwdOEnSY6iipUxGt2C5D4AHn 4rLmpbF7LqmSPJnv/q21QAXPs+c80XnQARfdqT5UCg9jsXVCoOnKAZRumIPvyFZa2GRy DiNQ== X-Gm-Message-State: ALoCoQlC1kMJGJCZ4SRwyTk8Q+N4IDyD2cHXn3c3ifXXkdqjlnPRKUKkng7+yxxUhJsaLlNho8Em0prK8lsTiYAOyAjewplN8ILFaq9stCnwJNpBiWzImwlGtU3MuCU2hUjpqi1tdiIS X-Received: by 10.220.59.65 with SMTP id k1mr5140450vch.22.1397193872067; Thu, 10 Apr 2014 22:24:32 -0700 (PDT) X-Received: by 10.220.59.65 with SMTP id k1mr5140439vch.22.1397193871901; Thu, 10 Apr 2014 22:24:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.137.39 with HTTP; Thu, 10 Apr 2014 22:24:11 -0700 (PDT) From: Yutaka OIWA Date: Fri, 11 Apr 2014 14:24:11 +0900 Message-ID: To: "http-auth@ietf.org" , cfrg@irtf.org Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/CLvcdg1-7W2r8tpSyVjlffziQ_U Subject: [http-auth] [Request for comments] revision of state machine specification in draft-ietf-httpauth-mutual 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: Fri, 11 Apr 2014 05:24:38 -0000 Dear readers of http-auth and cfrg, I previously received some concerns about too-complex notion of state machine definitions in my HTTP Mutual Authentication draft [http://tools.ietf.org/html/draft-ietf-httpauth-mutual-01#section-9]. I am really grateful for the important feedbacks for our drafts. Although my intention for using this was to ease non-security programmers to implement a correct algorithm without caring about details of the security designs, it also raised concerns about the difficulty of verifying the algorithm itself by experts. I have written two straw-man expressions for replacing/supplementing the original description in the current draft. The first one is a simplified, equivalent state machine with two boolean "switches" for controlling the behavior. The second one is a further simplified pair of rule itemizations, but here the important side conditions are expressed in more implicit way in English only. I'd like to hear some impressions about these alternative representations attached below, compared with the original notation in the draft above. Even a simple comments like "I like the version 2" is very welcome. I'll consider these for the -03 revision of the draft, hopefully. (I have some plan for -02 revision very soon.) The details of English texts will be further polished before actually incorporated into the future submitted draft. Thanks in advance, Yutaka Possible revision tactic (1) [state-machine with internal flags] ================================================================ Flags: F for "first request". SR for "reusing stored session now". (1) Let (F, SR) = (1, 0). Guess whether the request URI is likely authenticated. * Yes -> Goto (4). * No -> Continue to (2). (2) Try sending a normal request. * Received 401 requesting authentication (401-INIT) -> Continue to (3). (3) F := 0. Determine if you know the user-name and password for the given realm. * Yes -> Continue to (4). * No -> Ask user for it. [status = AUTH-REQUESTED]. (4) Determine whether you have a possibly-valid stored session for the given realm. * Yes -> SR := 1, Goto (6). * No -> Continue to (5). (5) SR := 0. Send key exchange from client (KEX-C1). * Received server key exchange response (401-KEX-S1) -> F := 0, Continue to (6). * Received normal authentication request (401-INIT) -> Authentication Failed [status = AUTH-REQUESTED]. (6) Send client-side key verification (VFY-C). * Received server-side key verification (200-VFY-S) -> Check server verifier token. If OK: Authentication Succeeded [status = AUTH-SUCCEED]. NG: Fatal communication error. * Received normal authentication request (401-INIT) -> Authentication Failed [status = AUTH-REQUESTED]. * Received stale session reply (401-STALE) -> If SR = 1: F := 0, Goto (5). SR = 0: ERROR. Other responses: * Normal response: if F = 1: no authentication provided [status = UNAUTHENTICATED]. F = 0: ERROR. * Authentication request (401-INIT) for a different realm: if F = 1: Goto (3). F = 0: ERROR. ================================================================ Possible revision tactic (2): Highly implicit version. ================================================================ The label "[Continue]" means you should go back to "What to send" and continue sending another request in sequence. The labels "[status = XXX]" means the successful termination of the request/response loop. The label "[Error]" means fatal communication error. * What to send: - If URL is not likely to be authenticated: send a normal request. - Else, authentication is somehow requested or guessed. If user name or password is not known, ask users for it. [status = AUTH-REQUESTED] - Else if there is a possibly-valid stored session, try sending VFY-C directly using that session. - Else, send a key exchange KEX-C1. * What to receive: - You may receive server-side key verification (200-VFY-S) only for VFY-C. -> Check server verifier token. If OK: Authentication has succeeded [status = AUTH-SUCCEED]. NG: Fatal communication error [Error]. - You may receive server key exchange response (401-KEX-S1) only for KEX-C1. -> continue to sending VFY-C [Continue]. - You may receive stale key notification (401-STALE) against VFY-C. -> You may continue to send KEX-C1 [Continue], ONLY IF you have not yet sent KEX-C1 in the request sequence. Otherwise, [Error]. - You may receive non-authenticating response. -> You may accept it [status = UNAUTHENTICATED], ONLY WHEN the request was the "first" one for a request sequence. Otherwise, [Error]. - You may receive authentication request for another realm. -> You may accept it [Continue], ONLY WHEN the request was the "first" one for a request sequence. Otherwise, [Error]. - You may receive an authentication request (400-INIT). -> OK if the request was a normal request. Start authentication [Continue]. -> OK if the request was VFY-C. It means credential was wrong and authentication was failed. [status = AUTH-REQUESTED] -> OK if the request was KEX-C1. It also means authentication was failed, where server is not even accepting trial for authentication. [status = AUTH-REQUESTED] - All other unexpected responses are [Error]. ================================================================ -- Yutaka OIWA, Ph.D. Leader, System Life-cycle Research Group Research Institute for Secure Systems (RISEC) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] From nobody Mon Apr 14 06:59:28 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 96C6D1A04A3 for ; Mon, 14 Apr 2014 06:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 XnCwW3_NZ9u0 for ; Mon, 14 Apr 2014 06:59:25 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 513EC1A049C for ; Mon, 14 Apr 2014 06:59:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8B0E9BE55; Mon, 14 Apr 2014 14:59:22 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvVdcW3SFJ5n; Mon, 14 Apr 2014 14:59:22 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2DB73BE51; Mon, 14 Apr 2014 14:59:22 +0100 (IST) Message-ID: <534BE9BA.6070207@cs.tcd.ie> Date: Mon, 14 Apr 2014 14:59:22 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "http-auth@ietf.org" X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/VGHHN3FM2b8V7ofNaseuhGCCNQA Cc: Richard Barnes , Kathleen Moriarty , Nevil Brownlee , "lionel.morand@orange.com OLNC/OLN" Subject: [http-auth] draft-morand-http-digest-2g-aka 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, 14 Apr 2014 13:59:26 -0000 Hi, I've a question for ya. This [1] draft was previously submitted to the ISE for publication on the independent stream. During the RFC 5742 conflict review we eventually spotted the fact that we needed an IETF stream spec so the the HTTP authentication scheme could be registered, having gotten IETF review, as is required for that registry. So now that this is back in the IETF stream we need to check if this WG wants to do the work. (I am the IESG shepherd for the RFC 5742 review, which is the reason its me sending this mail.) So, the plan now could be: a) this WG wants to take on the work of reviewing the draft and it gets progressed that way, or, b) some AD can sponsor it and start an IETF LC so the scheme can be registered (Richard as one of the RAI ADs has said he's willing to take a look at it since its a 3GPP-like thing), or, c) something else. My assumption is that the WG are likely to prefer (b) since that seemed to be the consensus when Sean asked before. [2] If that has changed, then please say so, otherwise I'll hand this over to Richard and he can take it from there. (So no need to respond if you think (b) is the right process thing to do until someone starts arguing for (a) or (c):-) I'm sure Lionel would also be happy to get any other comments folks would care to send, and/or you will of course be able to comment during an IETF LC which will happen if Richard does decide to AD sponsor this. Regards, Stephen. [1] https://tools.ietf.org/html/draft-morand-http-digest-2g-aka [2] https://www.ietf.org/mail-archive/web/http-auth/current/msg01544.html From nobody Mon Apr 14 10:46: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 D35121A0670 for ; Mon, 14 Apr 2014 10:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.953 X-Spam-Level: * X-Spam-Status: No, score=1.953 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_21=0.6] 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 Emm93-gmvLPB for ; Mon, 14 Apr 2014 10:46:48 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 82BD21A01FB for ; Mon, 14 Apr 2014 10:46:48 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s3EHkVIP093694 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 14 Apr 2014 10:46:33 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: <20131106162706.GA8185@LK-Perkele-VII> Date: Mon, 14 Apr 2014 10:46:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <10B917CE-6A51-4F1D-AB7B-9B5EB8EF9BAA@vpnc.org> References: <20131106162706.GA8185@LK-Perkele-VII> To: Ilari Liusvaara X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/bgDrBQ5uSN2Jz8tIzCm9g3QgLdg Cc: http-auth@ietf.org Subject: Re: [http-auth] Quick review of draft-ietf-httpauth-hoba-02 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, 14 Apr 2014 17:46:53 -0000 Sorry for the *long* delay in getting back to you. I'm about to do the = -03, and kept your message around for doing that. On Nov 6, 2013, at 8:27 AM, Ilari Liusvaara = wrote: >> Abstract >>=20 >> HTTP Origin-Bound Authentication (HOBA) is a design for an HTTP >> authentication method with credentials that are not vulnerable to >> phishing attacks, and that does not require any server-side = password >> database. The design can also be used in Javascript-based >> authentication embedded in HTML. HOBA is an alternative to HTTP >> authentication schemes that require passwords. >=20 > Well, technically whatever the database is resembles some forms of = password > database, albeit with the "passwords" being of much much higher = entropy. If an attacker gets the server-side database, they still are not able to = impersonate users. It's not just "higher entropy": the attacker has to = determine the private keys. > But that's nitpicking. I would say "it's wrong". :-) >> Session management with HOBA is identical to username/password >> session management. Typically, the session management tool (such = as >> PHP, Python CGI, and so on) inserts a session cookie into the = output >> to the browser. HOBA does nothing to help or hurt session cookie >> hijacking; TLS is still required for that. >=20 > If the authentication is not bound to sessions, even TLS can't really > help against all attacks that arise. Added. >=20 >> HOBA also defines some services that are required for modern HTTP >> authentication: >>=20 >> o Since there are always devices and applications in which state = of >> the art digital signature mechanism runtimes are significant, = and >> since HTTP authentication in theory requires that every HTTP >> request to a given realm have a signature in an "Authorization" >> header field, and since HOBA is a challenge response scheme, we >> also define a way in which HTTP servers can indicate the = duration >> for which they will consider a given challenge value to be = valid. >> As a consequence we also define a way for UAs to fetch a fresh >> challenge. >=20 > Hah, I was under impression that state-of-the-art is faster, not = slower. > Of course, there is keylength increases. Right. If they're using RSA, that's completely different than... > Discrete to ECC, ECC to HECC. >=20 > Of course, the usual way to lighten the load without sacrificing much > security is to have symmetric short-term keys. >=20 > But yes, there are more and more devices that have very limited = processing > power. That's our point here. >=20 >> 2. The HOBA Authentication Scheme >>=20 >> HOBA-TBS =3D nonce alg origin [ realm ] kid challenge >> nonce =3D unreserved >> alg =3D 1*2DIGIT >> origin =3D scheme "://" authority ":" port >> realm =3D unreserved >> kid =3D unreserved >> challenge =3D unreserved >=20 > What's unreserved? I can't quickly find it from httpbis p1, p7 nor = from > this document. >=20 > It it includes spaces, there could be multiple ways to take it apart > (or multiple things mapping into the same string). >=20 > Well, given the realm is seemingly the only one that can have spaces, = it > might not be that bad problem. It simply means that it is not defined in the format. I added this. >=20 >> 3. Introduction to the HOBA-http Mechanism >>=20 >> An HTTP server that supports HOBA authentication includes the = "HOBA" >> auth-scheme value in a WWW-Authenticate header field when it wants >> the client to authenticate with HOBA. Note that the HOBA = auth-scheme >> might not be the only one that the server includes in a WWW- >> Authenticate. >>=20 >> o If the "HOBA" scheme is listed, it MUST be followed by two or = more >> auth-param values. The auth-param attributes defined by this >> specification are below. Other auth-param attributes MAY be = used >> as well. Unknown auth-param attributes MUST be ignored by >> clients, if present. >>=20 >> o The "challenge" attribute MUST be included. The challenge is = the >> string made up of the base64url encoded octets that the server >> wants the client to sign in its response. The challenge SHOULD = be >> unique for every HTTP 401 response in order to prevent replay >> attacks from passive observers. >>=20 >> o An "expires" attribute MUST be included that specifies the = number >> of seconds from the time the HTTP response is emitted for which >> responses to this challenge can be accepted. >>=20 >> o A "realm" attribute MAY be included to indicate the scope of >> protection in the manner described in HTTP/1.1, Part 7 >> [I-D.ietf-httpbis-p7-auth]. The "realm" attribute MUST NOT = appear >> more than once. >=20 > The realm attribute must only appear once? What do other parameters do = if > present multiple times (nitpicking)? Nitpicking. HTTP sucks at this, and it is not our job to fix it. >=20 >> The server MUST check the cryptographic correctness of the = signature >> based on a public key it knows for the kid in the signatures, and = if >> the server cannot do that, or if the signature fails cryptographic >> checks, then validation has failed. The server can use any >> additional mechanisms to validate the signature. If the validation >> fails, or if the server chooses reject the signature for any reason >> whatsoever, the server aborts the transaction via a 403 Forbidden >> HTTP response. >=20 > Er, I thought authentication failures trigger 401, authorization = failures > trigger 403 (except if request isn't authenticated). Noted. >=20 >> Note that a HOBA signature is good for however long the expires >> attribute allows. This means that replay is possible within the = time >> window specified by the "expires" value chosen by the server. >> Servers can attempt to detect any such replay and MAY react to such >> replays by responding with a second (or subsequent) 401-status HTTP >> response containing a new challenge. >=20 > How could such detection be done in face of cut-and-paste attacks? >=20 > With TLS, one could include something like TLS-Unique (or what it = was). > That would defeat most cut'n'paste. I'm not sure what cut-and-paste attack you mean here. I put a note in, = but it would be good to hear more. >=20 >> 6.1. Registration >=20 >>=20 >> The registration message sent to server has one mandatory field = (pub) >> and some optional fields that allow the UA to specify the type and >> value of key and device identifiers that the UA wishes to use. >=20 > Again, what if these are duplicated? :-> >=20 >> o kidtype: contains the type of key identifier, this is a numeric >> value intended to contain one of the values from Section 9.4. = If >> this is not present then the mandatory to implement "DANE-hash" >> option MUST be used. >=20 > What's "DANE-hash"? Got it. >=20 >> o curtime: the number of milliseconds since the Unix epoch, >> formatted as [[ not yet specified ]]. This is based on the >> expectation that the synchronization between the browser's and >> server's clocks is sufficiently reliable. This is used to guard >> against the replay of a legitimate registration message. The >> server needs to have a replay cache covering a signature timeout >> window. This might be done using a database table that is keyed >> (in the database sense of the term) using the signature bits. = If >> the signature is in the replay table, the server will reject it. >> If the timestamp in the signature is outside the current replay >> cache window then it also gets rejected. >=20 > Decimal unix timestamp with three decimal digits? Still not yet specified. >=20 >> [[ A comment raised on the list was: how does the UA know that the >> registration process has completed successfully or badly? That's = not >> yet handled. ]] >=20 > You mean if the request was processed as-is, or more data will be = required? >=20 > (For immediate request, there's HTTP status codes, so I presume it is = that > "was this final success?" problem). Noted. >=20 >> 6.2. Associating Additional Keys to an Exiting Account >>=20 >> 6.2.1. Moving private keys >>=20 >> It is common for a user to have multiple UAs, and to want all those >> UAs to be able to authenticate to a single account. One method to >> allow a user who has an existing account to be able to authenticate >> on a second device is to securely transport the private and public >> keys and the origin information from the first device to the = second. >> If this approach is taken, then there is no impact on the HOBA-http >> or HOBA-js so this is a pure UA implementation issue and not >> discussed further. >=20 > There could also be copying private keys between origins/realms. In = certain > cases, the server could even recognize such keys. I'm not sure what you mean here. The origins don't have the users' = private keys. >> 6.2.2. One time password >>=20 >> The one-time password should be easy for a user to type into the = new >> UA, but at the same time needs to have enough randomness to prevent >> an attacker from succeeding if they try to use the password during >> its short lifetime. After the server gets the password in the new >> UA, it verifies the signature and verifies that the password = supplied >> is in a list of unexpired one-time passwords. If so, the server >> knows that the authenticated user is associated with the second = CPK. >> The server can choose to associate the two CPKs with one account. >> Whether to do so is entirely at the server's discretion however, = but >> the server needs make the outcome clear to the user. >=20 > Something like S/Key passwords (might not be the best in mobile = enviroment)=3D Yuck. >=20 >> Alternatively, if an already-enrolled UA is not available to the = user >> when they want to associate a new UA with an existing account, and >> the site has an out-of-band communication mechanism such as email = or >> SMS associated with that account, the user can request that a one- >> time password be sent to the user out of band. The user receives = the >> one-time password and, using the new UA, tells it to the server. = On >> HOBA-http, this is done with the URL ".well-known/hoba/associate- >> from-oob" using a POST message [[ more detail is clearly needed = here >> ]]. >=20 > What's the difference to the first case from server POV (the URL being > different)? None, really. >=20 >> 6.3. Logging Out >>=20 >> The user can tell the server it wishes to log out. With HOBA-http, >> this is done by going to the URL ".well-known/hoba/logout". The UA >> SHOULD also delete or modify session cookies associated with the >> session so that the user's state is no longer "logged in." >=20 > Modify? I don't think cookies are modifiable, so that just leaves = deleting > those. Good catch. >> The server MUST NOT allow TLS session resumption for any logged out >> session. [[ Need to determine if this is needed or even a good = idea. >> ]] >=20 > Eeh? Specify that server MUST destroy TLS session state on HOBA = logout? >=20 > These things run on totally separate layers... Yes, but it is something that people have asked for with connection = latching. >=20 >> 8. Security Considerations >>=20 >> [[ The potential impact on privacy of HOBA needs to be addressed. = If >> a site can use a 401 and a CPK to track users without permission = that >> would be not-so-nice so some guidance on how a UA could indicate to = a >> user that HOBA stuff is going on might be needed. ]] >=20 > Obviously any authentication mechanism allows tracking within account. Noted. >> 9.3. Algorithm Names >>=20 >> TBD, hopefully re-use and existing registry >>=20 >> "0" means RSA-SHA256 >>=20 >> "1" means RSA-SHA1 >=20 > Just RSA? Nothing more modern? Certainly, once people settle on one. Added. >=20 >> 9.4. Key Identifier Types >>=20 >> "0" means a hashed public key, as done in DANE. [RFC6698] >=20 > Er, doesn't that constist of two parts, once all implicit fields are > left out? It is a single blob, the subjectPublicKeyIdentifier. >> "1" means a URI, such as a mailto: or acct: URI, but anything >> conforming to [RFC3986] is ok.i >=20 > "ok.i"? Should be "ok."? Yep. Thanks a zillion for these. We'll turn in the -03 sometime this week = before the document expires. --Paul Hoffman= From nobody Tue Apr 15 06:37: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 2BE4B1A0495 for ; Tue, 15 Apr 2014 06:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 S7kThwOm1mah for ; Tue, 15 Apr 2014 06:37:24 -0700 (PDT) Received: from emh06.mail.saunalahti.fi (emh06.mail.saunalahti.fi [62.142.5.116]) by ietfa.amsl.com (Postfix) with ESMTP id F0C001A0459 for ; Tue, 15 Apr 2014 06:37:23 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh06.mail.saunalahti.fi (Postfix) with ESMTP id 704C2699D3; Tue, 15 Apr 2014 16:37:19 +0300 (EEST) Date: Tue, 15 Apr 2014 16:37:18 +0300 From: Ilari Liusvaara To: Paul Hoffman Message-ID: <20140415133718.GA26478@LK-Perkele-VII> References: <20131106162706.GA8185@LK-Perkele-VII> <10B917CE-6A51-4F1D-AB7B-9B5EB8EF9BAA@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <10B917CE-6A51-4F1D-AB7B-9B5EB8EF9BAA@vpnc.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/inJjlc1kNkKFC8GfjTQcDxVnP2w Cc: http-auth@ietf.org Subject: Re: [http-auth] Quick review of draft-ietf-httpauth-hoba-02 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, 15 Apr 2014 13:37:29 -0000 On Mon, Apr 14, 2014 at 10:46:29AM -0700, Paul Hoffman wrote: > Sorry for the *long* delay in getting back to you. I'm about to do the -03, and kept your message around for doing that. > > On Nov 6, 2013, at 8:27 AM, Ilari Liusvaara wrote: > > >> Note that a HOBA signature is good for however long the expires > >> attribute allows. This means that replay is possible within the time > >> window specified by the "expires" value chosen by the server. > >> Servers can attempt to detect any such replay and MAY react to such > >> replays by responding with a second (or subsequent) 401-status HTTP > >> response containing a new challenge. > > > > How could such detection be done in face of cut-and-paste attacks? > > > > With TLS, one could include something like TLS-Unique (or what it was). > > That would defeat most cut'n'paste. > > I'm not sure what cut-and-paste attack you mean here. I put a note in, but it would be good to hear more. IIRC, what I meant was MITM taking a valid signature, and pasting it to its own request. (Or in case of really badly designed schemes, sometimes even third-party origins can capture valid signatures and use those... Shouldn't be the case here). > >> 6.2.1. Moving private keys > >> > >> It is common for a user to have multiple UAs, and to want all those > >> UAs to be able to authenticate to a single account. One method to > >> allow a user who has an existing account to be able to authenticate > >> on a second device is to securely transport the private and public > >> keys and the origin information from the first device to the second. > >> If this approach is taken, then there is no impact on the HOBA-http > >> or HOBA-js so this is a pure UA implementation issue and not > >> discussed further. > > > > There could also be copying private keys between origins/realms. In certain > > cases, the server could even recognize such keys. > > I'm not sure what you mean here. The origins don't have the users' private keys. Initializing key for origin B from existing key of origin A. Obviously only useful if A and B are tightly coupled (one can argue that such things should be under common domain, but sometimes those aren't). Probably too much needless complexity to implement. -Ilari From nobody Tue Apr 15 07:41: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 5C78D1A0797 for ; Tue, 15 Apr 2014 07:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 4JAxldrRDdSU for ; Tue, 15 Apr 2014 07:41:41 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id C05161A06D1 for ; Tue, 15 Apr 2014 07:41:40 -0700 (PDT) Received: from [192.168.1.103] ([217.91.35.233]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0M1jKo-1Wq6Me1OtW-00toFV; Tue, 15 Apr 2014 16:41:34 +0200 Message-ID: <534D451C.8090301@gmx.de> Date: Tue, 15 Apr 2014 16:41:32 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Tony Hansen , http-auth@ietf.org References: <531B47E4.2090901@att.com> In-Reply-To: <531B47E4.2090901@att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:vULc67XVGhYhbM12Ahw4M0GxIejZ3cPdvcT7S8LVXjbgkS19wTZ KmRekpU/YQwdvUHZsKLi38EgcSWYRjOrSs9jXIsWnh/o5bf58FXyLTgNEqHzHhr0L5ekf46 5PnMxFOC3ScBs7rPUSKYpqLR9QjOrvRat6+05RYAzzdpPJSiMyLQNYlGOfIvfrTk8Xbh8AP 6grUbd3msnoTEF02HNqMA== Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/ZSLojVUpRViGMODx1lRL2BjEUjg Subject: Re: [http-auth] a review of draft-ietf-httpauth-scram-auth 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, 15 Apr 2014 14:41:44 -0000 On 2014-03-08 17:40, Tony Hansen wrote: > ... > 1. What is different in HTTP SCRAM from the original SASL SCRAM > documented in RFC 5802? > ... > Now note: actual differences do exist. In particular, I noted several > specific differences, although I may have missed some: > > a) The specification of the gs2 header is different. It has been > "adjusted" to match the name=value format of www-authenticate's > 1#challenge. In addition, the use of authzid has been lost. For example, > ... > b) The handling of white space and double quotes. > > The consequence of these substantive differences is that existing > implementations of SASL SCRAM can NOT be used to implement HTTP SCRAM. > Personally I think that this is a bad consequence. > > There are two fixes for going forward: > > A) Accept that there are differences. If we do this, I feel that there > MUST MUST MUST be a serious WARNING section added for implementers to > let them know that current SASL SCRAM libraries can NOT be used. > B) Get rid of these differences. See below. > ... As far as I can tell, this change was essential. Historically, auth schemes have defined their own parsing, of challenges, but the problem is that the overall syntax of challenges in HTTP authentication is defined by the framework, not the authentication scheme. Thus, you need a *generic* parser before you even get to the point where you can dispatch to auth-scheme specific code. > Regarding the handling of white space, one of the hardest parts to get > right with SCRAM is getting the inputs into the hash algorithms exactly > right, on BOTH sides. For example, if one side includes a space and the > other side does not, then the hashes will not match. > > If you look at the ABNF for "challenge" (HTTP-P7, HTTP-P1) and the ABNF > for the elements for the name=value pairs in HTTP SCRAM, you will find > that they are not compatible. The HTTP definition is a superset in that > it allows for the use of quoted strings and allows for white space to be It allows quoted-string and token as this reflects reality in parsing header fields like these. > included in various locations, neither of which are allowed by the ABNF > for the SCRAM-specific elements. I don't think that the ABNF for > auth-param is compatible at all with gs2-header p= option because > token68 does not allow an "=". HTTP uses BWS around "=", which is described as: "The BWS rule is used where the grammar allows optional whitespace only for historical reasons. A sender MUST NOT generate BWS in messages. A recipient MUST parse for such bad whitespace and remove it before interpreting the protocol element.". It also allows OWS (optional whitespace) *between* parameters. That's just common in HTTP, and, again, is true for all HTTP auth schemes that use parameters. > ... > 3) method agility > > Unless I'm totally mistaken, the issues with method agility are > associated with the protocol exchange example shown in section 5 is > incorrect with respect to the realm and the description of the original > 401 Unauthorized challenge along with subsequent descriptions of the realm. > > I think it's worth showing a *complete* example 401 challenge exchange, > filling in the "server might have returned 401 Unauthorized first" > comment. THIS is where the server might provide one or more realm names > as part of its challenge. For example, you might see: > > WWW-Authenticate: Basic Digest realm="realm1" > Digest realm="realm2" Digest realm="realm3" > SCRAM-SHA-1 realm="realm3" SCRAM-SHA-1 realm="realm4" Commas are missing here. > ... > It might be worth introducing SOMEWHERE the terms "challenge #0" as the > server challenge that lists the acceptable authentication schemes and > their optional realms, and then the client response is "response #1" > followed by "challenge #1", and counting up from there. In general > terms, challenge #0 always lists the available authentication schemes > and their optional realms (along with any other initial parameters that > need to be passed along with that authentication scheme). Response #1 > specifies the next round of parameters for the given authentication > scheme chosen by the client. Challenge #1 either returns the 200 with an > optional Authorization-Info or another 401 Unauthorized with a > WWW-Authenticate header. If this is an authentication scheme that allows > another round to be used for additional information, Challenge #1 would > also include a sid= parameter (or WWW-Authentication-Sid header as has > been suggested elsewhere). Subsequent Responses (#2 and beyond) then use > the same sid=/WWW-Authentication-Sid value to tie the challenges and > response together. > > I'm not sure where SOMEWHERE should be. Is it too late to get this into > HTTP BIS P7? Yes, it's too late. > ... > Getting Rid of the Differences with SASL SCRAM > > Now I'm going to present an alternative way of fixing some of the > problems above. The basic idea is to say that the SCRAM-SHA-1 payloads > are exactly as specified in RFC 5802, but are base64-encoded for use > within HTTP. This is exactly the SASL authentication split that is used > by all other application protocols that use SASL: the SASL mechanism > specifies what information needs to be included in any given round of > exchange and the application protocol specifies how that information is > wrapped for transmission within the application protocol. For example, > an application protocol could use base64 encoding of that data (as > suggested here), or could use run-length-encoding if it's binary, or > could use quoted-printable or hex or whatever. The important thing is > that is a strict separation of responsibility. The application protocol > doesn't care what the data is and what is included within it; it just > has some mechanism for getting that data across the protocol boundary > safely. The application protocol restores that data back to its octet > form and passes that data into the authentication mechanism. The > response from the authentication mechanism is then encoded for the > application-layer response. > > How does this look for HTTP SCRAM? I'm going to use the word "payload" > to represent the parameter that holds the SCRAM-SHA-1 payload. Each > challenge and response becomes 1) the scram name, 2) either the realm or > sid value, and then 3) the payload value. (I don't care what the > parameter name is called.) In ABNF, this would be something like this: > > challenge-scram = scram-name WS realm-or-sid BWS "," OWS > "payload=" payload-value > credentials-scram = scram-name WS realm-or-sid BWS "," OWS > "payload=" payload-value > realm-or-sid = ( "realm=" realm-value / "sid=" sid-value ) > payload-value = 1*base64 / DQUOTE 1*base64 DQUOTE Note that any parameter value that is in DQUOTEs must use quoted-string syntax. > ... Best regards, Julian From nobody Fri Apr 18 08:57: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 439871A0442; Fri, 18 Apr 2014 08:57:10 -0700 (PDT) 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 9VOUCoXzq6Dm; Fri, 18 Apr 2014 08:57:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A0741A03F7; Fri, 18 Apr 2014 08:57:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140418155708.10482.35698.idtracker@ietfa.amsl.com> Date: Fri, 18 Apr 2014 08:57:08 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/-lREF4n29ItTaId_NBl-doqyY1c Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-hoba-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: Fri, 18 Apr 2014 15:57:10 -0000 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 Origin-Bound Authentication (HOBA) Authors : Stephen Farrell Paul Hoffman Michael Thomas Filename : draft-ietf-httpauth-hoba-03.txt Pages : 21 Date : 2014-04-18 Abstract: HTTP Origin-Bound Authentication (HOBA) is a design for an HTTP authentication method with credentials that are not vulnerable to phishing attacks, and that does not require any server-side password database. The design can also be used in Javascript-based authentication embedded in HTML. HOBA is an alternative to HTTP authentication schemes that require passwords. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-httpauth-hoba-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-hoba-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 nobody Thu Apr 24 03:41: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 625B51A0187; Thu, 24 Apr 2014 03:41:22 -0700 (PDT) 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 lhZ_R6-6wm2K; Thu, 24 Apr 2014 03:41:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E51C1A010F; Thu, 24 Apr 2014 03:41:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140424104120.16036.34946.idtracker@ietfa.amsl.com> Date: Thu, 24 Apr 2014 03:41:20 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/oWXg7lig31XrAl4Ode2fYb1MUAU Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-mutual-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: Thu, 24 Apr 2014 10:41:22 -0000 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 : Mutual Authentication Protocol for HTTP Authors : Yutaka Oiwa Hajime Watanabe Hiromitsu Takagi Kaoru Maeda Tatsuya Hayashi Yuichi Ioku Filename : draft-ietf-httpauth-mutual-02.txt Pages : 52 Date : 2014-04-24 Abstract: This document specifies a mutual authentication method for the Hyper- text Transfer Protocol (HTTP). This method provides a true mutual authentication between an HTTP client and an HTTP server using password-based authentication. Unlike the Basic and Digest authentication methods, the Mutual authentication method specified in this document assures the user that the server truly knows the user's encrypted password. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-mutual/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-httpauth-mutual-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-mutual-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 nobody Thu Apr 24 03:41:35 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 420D71A01A6; Thu, 24 Apr 2014 03:41:30 -0700 (PDT) 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 8E0B_iI5T4_X; Thu, 24 Apr 2014 03:41:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CB72D1A0192; Thu, 24 Apr 2014 03:41:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140424104127.19538.48421.idtracker@ietfa.amsl.com> Date: Thu, 24 Apr 2014 03:41:27 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/Au1pFtwK2n89diPxFDYj7Z1By-o Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-mutual-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: Thu, 24 Apr 2014 10:41:30 -0000 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 : Mutual Authentication Protocol for HTTP Authors : Yutaka Oiwa Hajime Watanabe Hiromitsu Takagi Kaoru Maeda Tatsuya Hayashi Yuichi Ioku Filename : draft-ietf-httpauth-mutual-02.txt Pages : 52 Date : 2014-04-24 Abstract: This document specifies a mutual authentication method for the Hyper- text Transfer Protocol (HTTP). This method provides a true mutual authentication between an HTTP client and an HTTP server using password-based authentication. Unlike the Basic and Digest authentication methods, the Mutual authentication method specified in this document assures the user that the server truly knows the user's encrypted password. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-mutual/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-httpauth-mutual-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-mutual-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 nobody Thu Apr 24 03:41: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 4A2731A01AE; Thu, 24 Apr 2014 03:41:36 -0700 (PDT) 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 XUY4Ls2B6ytP; Thu, 24 Apr 2014 03:41:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EE1FB1A019B; Thu, 24 Apr 2014 03:41:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140424104133.21877.16681.idtracker@ietfa.amsl.com> Date: Thu, 24 Apr 2014 03:41:33 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/btk01ws5AjtW_J2Vaa6T_dFWgzA Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-mutual-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: Thu, 24 Apr 2014 10:41:36 -0000 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 : Mutual Authentication Protocol for HTTP Authors : Yutaka Oiwa Hajime Watanabe Hiromitsu Takagi Kaoru Maeda Tatsuya Hayashi Yuichi Ioku Filename : draft-ietf-httpauth-mutual-02.txt Pages : 52 Date : 2014-04-24 Abstract: This document specifies a mutual authentication method for the Hyper- text Transfer Protocol (HTTP). This method provides a true mutual authentication between an HTTP client and an HTTP server using password-based authentication. Unlike the Basic and Digest authentication methods, the Mutual authentication method specified in this document assures the user that the server truly knows the user's encrypted password. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-mutual/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-httpauth-mutual-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-mutual-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 nobody Thu Apr 24 03:48:59 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 401C91A0176 for ; Thu, 24 Apr 2014 03:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.679 X-Spam-Level: X-Spam-Status: No, score=-3.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, 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 wk4G5Eqt-mAt for ; Thu, 24 Apr 2014 03:48:54 -0700 (PDT) Received: from na3sys010aog114.obsmtp.com (na3sys010aog114.obsmtp.com [74.125.245.96]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3721A0171 for ; Thu, 24 Apr 2014 03:48:54 -0700 (PDT) Received: from mail-vc0-f181.google.com ([209.85.220.181]) (using TLSv1) by na3sys010aob114.postini.com ([74.125.244.12]) with SMTP ID DSNKU1jsECVGzGgaS1wc/w3gkHRG62yPNyQ7@postini.com; Thu, 24 Apr 2014 03:48:48 PDT Received: by mail-vc0-f181.google.com with SMTP id id10so2631863vcb.40 for ; Thu, 24 Apr 2014 03:48:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=WlDXuDefUonXJteDNj4pTRvlaiTY8Bgn3DWikFJM8BI=; b=dpmsHhIsXzMe+6mWfSifcR1Ux2h27iuWer44anVw2X24ln03WDaLMl41vojAWs9quR fGo99GBvh/VIaoePFc0UsSR1YVUh6CVug6ShHtSnSJhdp+BtIeeniYwNQ2TOCxIMdHRB msqVOt+Tr4dxJZlvw3cV/HZdTdKD0E9PR9SW8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=WlDXuDefUonXJteDNj4pTRvlaiTY8Bgn3DWikFJM8BI=; b=Ds9rDVs5LGNn6+syMUmhy6WF5ioKC6Kbe22UjzrAunYFjHbZhd9e/jzBI35EoEvv27 JckzWj+I9IK7by2Axzc1XNimJbwBDiBevcbB+zqn1yuxOhDQn5h9dSiGcbvyBrBYMy70 6VBoQpzgESAX2x8CPQ8b0FJCcKiuN9iamwfDgdd+iZfZHMlAwb0Jh10nmBDBG9XjSwYM aW8yKN1CtFdPcQpwN3B1cuXyGWT6ggJOug66EHR/ERhCmVvOzf41lmswzxVpJgtS9Y0z b1+KiK5gouzHkWqWCzzU+RRwbZJ+I01M4VWzLrqZC3qugHLDmPENjH2w0YNmXs6s55MU i19Q== X-Gm-Message-State: ALoCoQmCcqvQq0pPoxsM2b4yqvdvK6rqV2YfZXWTW+Dc8CcE4smMWSd9FFakii2yIUCYaYyjF5a+2HmgiFg+V2lc/Vlfl3b5vLwwsegAsjAfNqQ7ymoLaVGl+y+lloTInyhBbBHvqXzL X-Received: by 10.58.187.78 with SMTP id fq14mr743519vec.9.1398336527984; Thu, 24 Apr 2014 03:48:47 -0700 (PDT) X-Received: by 10.58.187.78 with SMTP id fq14mr743510vec.9.1398336527858; Thu, 24 Apr 2014 03:48:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.137.39 with HTTP; Thu, 24 Apr 2014 03:48:27 -0700 (PDT) In-Reply-To: <20140424104133.21877.16681.idtracker@ietfa.amsl.com> References: <20140424104133.21877.16681.idtracker@ietfa.amsl.com> From: Yutaka OIWA Date: Thu, 24 Apr 2014 19:48:27 +0900 Message-ID: To: "http-auth@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/h0Yl4CUQjy6KuVADEJ73sd4V-1E Subject: [http-auth] Fwd: I-D Action: draft-ietf-httpauth-mutual-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: Thu, 24 Apr 2014 10:48:56 -0000 Dear all in http-auth, Thank you very much for recent comments, especially on introduction of the password-strengthening features and cryptographic exchanges (transaction verification). I updated the mutual-auth draft to -02 revision, including the following major changes: * Introduction of PKCS #5 PBKDF2 password-strengthening. We have received some more proposals on using more stronger functions which are not yet in the RFC series. If we will go for standardizing those algorithms as well, I really appreciate more discussions. * Changed the client-side behavior description in Section 9, reflecting the comments "too complex!". Now the description is more property or requirement based, and the big state-machine is now informative purpose only. * Note on the transaction verification in cryptographic exchanges is added to the companion "algo" draft. I hope this will clarify the things for cryptographers. ---------- Forwarded message ---------- From: Date: 2014-04-24 19:41 GMT+09:00 Subject: [http-auth] I-D Action: draft-ietf-httpauth-mutual-02.txt To: i-d-announce@ietf.org Cc: http-auth@ietf.org 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 : Mutual Authentication Protocol for HTTP Authors : Yutaka Oiwa Hajime Watanabe Hiromitsu Takagi Kaoru Maeda Tatsuya Hayashi Yuichi Ioku Filename : draft-ietf-httpauth-mutual-02.txt Pages : 52 Date : 2014-04-24 Abstract: This document specifies a mutual authentication method for the Hyper- text Transfer Protocol (HTTP). This method provides a true mutual authentication between an HTTP client and an HTTP server using password-based authentication. Unlike the Basic and Digest authentication methods, the Mutual authentication method specified in this document assures the user that the server truly knows the user's encrypted password. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-mutual/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-httpauth-mutual-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-mutual-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 -- Yutaka OIWA, Ph.D. Leader, System Life-cycle Research Group Research Institute for Secure Systems (RISEC) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] From nobody Thu Apr 24 03:52:32 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 A80871A0171 for ; Thu, 24 Apr 2014 03:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.679 X-Spam-Level: X-Spam-Status: No, score=-3.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, 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 1sAOh5BwUYGS for ; Thu, 24 Apr 2014 03:52:20 -0700 (PDT) Received: from na3sys010aog110.obsmtp.com (na3sys010aog110.obsmtp.com [74.125.245.88]) by ietfa.amsl.com (Postfix) with ESMTP id 764001A010F for ; Thu, 24 Apr 2014 03:52:20 -0700 (PDT) Received: from mail-vc0-f175.google.com ([209.85.220.175]) (using TLSv1) by na3sys010aob110.postini.com ([74.125.244.12]) with SMTP ID DSNKU1js3ouiEx/idIJ3XdGO0QCDNlo9fBJ6@postini.com; Thu, 24 Apr 2014 03:52:14 PDT Received: by mail-vc0-f175.google.com with SMTP id lh14so2693290vcb.6 for ; Thu, 24 Apr 2014 03:52:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=q149U7Y6dSt+LErfxsGT8Uv+3wRIAyChbnHo21SFo84=; b=hGGCMA9SYg7nGK+rhKA4fmKsKecC4pu3z7tkVEqIhibMaCXSYVl59uaF2BKAXwiVml KR4Vs5yxWkehin2FLcJ1w0NL1+uvkAPCnwM0YkKN62uq4yjcxwW0TGPKBuPxacp2+myd IpfbWrhWzEI5tN3kQT6o40WzrxhqKAo5WTtLQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=q149U7Y6dSt+LErfxsGT8Uv+3wRIAyChbnHo21SFo84=; b=RM6ulQijcJbcUlCvAMfO+jm4tJc5Xd4ielcVXWJCYdstpK2khqfcTtcWD45m/biBgi kdTe7mkPBorcdtel2/8PAj4D1vmeE6u7gITosCmPGP2Mxs8AhJ/53/jS9eqKpi8XLapf gv+SGjoB3Jx50rtVp2x3bEZ4sxWdtjv+SJ5MuBrWCFkgcQyw7elSBqIulCAMHed061dh Sl07bcrcj5R6kGyngQLxpVAjL/MMfPbX81JlDeuXDd93ERrQNNaxFa66u4XmWN000+t0 DB+2j3ZeezRglFL5gks30MuZsGnGKhJ8QuiINYRPFV9MuJ3iIgXPx7UXjq3vnXSw1jeL Rbtw== X-Gm-Message-State: ALoCoQmozxXWyefSn26HmcZ2xc5lr9VENrEY5DhHXdxKfyKoloMzxH9f4iNTlelFqA2DrAuR2GfvqX7bnIL2Ykv1Cv5EzOklCeeeoHVV1wplt6ieRa4yOltjPX8NUQcRbfBSSYVav99c X-Received: by 10.58.122.164 with SMTP id lt4mr811071veb.2.1398336734044; Thu, 24 Apr 2014 03:52:14 -0700 (PDT) X-Received: by 10.58.122.164 with SMTP id lt4mr811066veb.2.1398336733972; Thu, 24 Apr 2014 03:52:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.137.39 with HTTP; Thu, 24 Apr 2014 03:51:53 -0700 (PDT) In-Reply-To: References: <20140424104133.21877.16681.idtracker@ietfa.amsl.com> From: Yutaka OIWA Date: Thu, 24 Apr 2014 19:51:53 +0900 Message-ID: To: "http-auth@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/CHVwWWgFF8cE_eh312cL1hTIY7A Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-mutual-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: Thu, 24 Apr 2014 10:52:29 -0000 Additionally, the http-auth-extension draft is now under consideration for thinking with some possible restructure/merger with other drafts. I will keep this draft in the current revision, and if not action is decided before the next meeting, I'll post a small revision before that. So, please do not mind much about its expiration. I'm aware and still active on it :-) 2014-04-24 19:48 GMT+09:00 Yutaka OIWA : > Dear all in http-auth, > > Thank you very much for recent comments, especially on > introduction of the password-strengthening features and > cryptographic exchanges (transaction verification). > > I updated the mutual-auth draft to -02 revision, > including the following major changes: > > * Introduction of PKCS #5 PBKDF2 password-strengthening. > We have received some more proposals on using more > stronger functions which are not yet in the RFC series. > If we will go for standardizing those algorithms as well, > I really appreciate more discussions. > > * Changed the client-side behavior description in Section 9, > reflecting the comments "too complex!". > Now the description is more property or requirement based, > and the big state-machine is now informative purpose only. > > * Note on the transaction verification in cryptographic exchanges > is added to the companion "algo" draft. > I hope this will clarify the things for cryptographers. > > > ---------- Forwarded message ---------- > From: > Date: 2014-04-24 19:41 GMT+09:00 > Subject: [http-auth] I-D Action: draft-ietf-httpauth-mutual-02.txt > To: i-d-announce@ietf.org > Cc: http-auth@ietf.org > > > > 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 : Mutual Authentication Protocol for HTTP > Authors : Yutaka Oiwa > Hajime Watanabe > Hiromitsu Takagi > Kaoru Maeda > Tatsuya Hayashi > Yuichi Ioku > Filename : draft-ietf-httpauth-mutual-02.txt > Pages : 52 > Date : 2014-04-24 > > Abstract: > This document specifies a mutual authentication method for the Hyper- > text Transfer Protocol (HTTP). This method provides a true mutual > authentication between an HTTP client and an HTTP server using > password-based authentication. Unlike the Basic and Digest > authentication methods, the Mutual authentication method specified in > this document assures the user that the server truly knows the user's > encrypted password. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-httpauth-mutual/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-httpauth-mutual-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-mutual-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 > > > -- > Yutaka OIWA, Ph.D. Leader, System Life-cycle Research Group > Research Institute for Secure Systems (RISEC) > National Institute of Advanced Industrial Science and Technology (AIST) > Mail addresses: , > OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] -- Yutaka OIWA, Ph.D. Leader, System Life-cycle Research Group Research Institute for Secure Systems (RISEC) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] From nobody Sat Apr 26 06:17:38 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 407B61A063C; Sat, 26 Apr 2014 06:17:37 -0700 (PDT) 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 h5EaZc6VoEaW; Sat, 26 Apr 2014 06:17:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BFA21A01C9; Sat, 26 Apr 2014 06:17:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140426131735.31801.46668.idtracker@ietfa.amsl.com> Date: Sat, 26 Apr 2014 06:17:35 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/n8s_ijYJ_Isvnpo6YxCLcxpkFPk Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-digest-07.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, 26 Apr 2014 13:17:37 -0000 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-07.txt Pages : 30 Date : 2014-04-26 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-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-digest-07 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 nobody Sat Apr 26 06:21:11 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 090DD1A0191 for ; Sat, 26 Apr 2014 06:21:10 -0700 (PDT) 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 P9VayrE7U-ie for ; Sat, 26 Apr 2014 06:21:07 -0700 (PDT) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) by ietfa.amsl.com (Postfix) with ESMTP id B6EA01A04A3 for ; Sat, 26 Apr 2014 06:21:06 -0700 (PDT) Received: by mail-lb0-f175.google.com with SMTP id p9so878022lbv.6 for ; Sat, 26 Apr 2014 06:20:59 -0700 (PDT) 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=dMYgeqNDMFU56w8brnYV+QnSLj6aQ995t6485OvdOaw=; b=VqC/T1Al/bJE9MzPsY515KQ9jv4ttqUUzh4/gOJg1S/GVXUuYrMzwdbSLhBhD5je4P +0Vp2CHguzpffd6EEzbZjoQJx6jlokTE1Bpz2gE4lM8sptTSa2LKTkuni61R6DXae8AG LqXdMkaP7sFNFeCsXSXC2cC4WLg6OtaT7a4gBkiwRnmyCIMmO3JOQ7PNoJRpkif0sigN uJGFAO+wzW1QQwDzblMjThZy1WN7W5oa/2T0SjkQYbAS8oXAuR/p9C6RE+P8orlCgQ8+ bTOsd/2WAryCOjQbWAFP4ZSdSc3S1/9FZwT7JwctvaJG3nI6802js1AQxPk85XBSSas0 Hrmw== MIME-Version: 1.0 X-Received: by 10.152.1.8 with SMTP id 8mr10145795lai.1.1398518459299; Sat, 26 Apr 2014 06:20:59 -0700 (PDT) Received: by 10.114.63.144 with HTTP; Sat, 26 Apr 2014 06:20:59 -0700 (PDT) In-Reply-To: <20140426131735.31801.46668.idtracker@ietfa.amsl.com> References: <20140426131735.31801.46668.idtracker@ietfa.amsl.com> Date: Sat, 26 Apr 2014 09:20:59 -0400 Message-ID: From: Rifaat Shekh-Yusef To: "http-auth@ietf.org" Content-Type: multipart/alternative; boundary=089e01228132fa7ab804f7f1f3a2 Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/7AwLJckn9mUD776AR7ENbpf8PqQ Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-07.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, 26 Apr 2014 13:21:10 -0000 --089e01228132fa7ab804f7f1f3a2 Content-Type: text/plain; charset=ISO-8859-1 Hi, I have updated the draft based on Yoav's comments. Any other comments? Regards, Rifaat On Sat, Apr 26, 2014 at 9:17 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-07.txt > Pages : 30 > Date : 2014-04-26 > > 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-07 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-httpauth-digest-07 > > > 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 > --089e01228132fa7ab804f7f1f3a2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I have updated the draft base= d on Yoav's comments.
Any other comments?

= Regards,
=A0Rifaat


<= br>
On Sat, Apr 26, 2014 at 9:17 AM, <inter= net-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-07.txt=
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 30
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2014-04-26

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-07
A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-httpauth-= digest-07


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

--089e01228132fa7ab804f7f1f3a2--