From nobody Tue May 5 16:13:17 2015 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 A1B3F1A8986 for ; Tue, 5 May 2015 16:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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, J_CHICKENPOX_26=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uB94SycnLLpH for ; Tue, 5 May 2015 16:13:12 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 753351A8982 for ; Tue, 5 May 2015 16:13:12 -0700 (PDT) Received: by oica37 with SMTP id a37so159378264oic.0 for ; Tue, 05 May 2015 16:13:12 -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:content-type; bh=Sj5M7jUtRLRjWiD4knS8EBRiRvCDU9dPmMwCpx6zSR4=; b=YNKLoLUZCqMhPkGZQ7vN4qkYAHJTlRmtpT7VKDbED8Q9nmPSLv1xLurvX6rpXUSHjx /wxDTGs1g1FuvpW98NkDrMZWasbEe9ZsV/FwOOcXn5Za+iQIjqdAMaILZCUlqp+JzG2J FzjdFp6stYmUm0q68tEMlGlOZgpwSBiGi3hdMXqM66o7Ec/xh+pGCdjx/SRJ34ttdURg dY/p9uexxSfjGtennzLVLaKT7KMYdPWUcib4mDL7m/6dfGmhX9eKDb01hSDuKhxJJ3GH EEg5XmzkiIOdtwOBqvQkoWTvI+U213DF+Y2XHTsUHufSgcDfCTia2zZftLYn1BU45pi5 gkZw== MIME-Version: 1.0 X-Received: by 10.182.234.19 with SMTP id ua19mr2323669obc.17.1430867591997; Tue, 05 May 2015 16:13:11 -0700 (PDT) Received: by 10.202.75.149 with HTTP; Tue, 5 May 2015 16:13:11 -0700 (PDT) Date: Tue, 5 May 2015 19:13:11 -0400 Message-ID: From: Rifaat Shekh-Yusef To: "http-auth@ietf.org" Content-Type: multipart/alternative; boundary=e89a8f923c168ab40805155dd296 Archived-At: Subject: [http-auth] HTTP Digest - HMAC & Salted Hash 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, 05 May 2015 23:13:13 -0000 --e89a8f923c168ab40805155dd296 Content-Type: text/plain; charset=ISO-8859-1 Hi, During the Gen-Art and SecDir reviews of the HTTP Digest draft, HMAC support was suggested by both reviewers. Also, the STUNbis team asked to add support for salted hash. Based on the discussion with the ADs it was decided that, if there is interest, that these two issues be addressed in a separate draft. Here is an initial proposal for adding HMAC and salted hash support that I would like to discuss: Definitions ----------- H(data) = Hash(data) KD(secret, data) = HMAC-Hash(secret, data) A1 Calculation -------------- If the solution is able to provide only system wide salt, then: A1 = username:realm:password:salt If the solution is able to provide a per user salt, then: A1 = password:realm:salt Example ------- Using HMAC-SHA256 and per user salt calculation: A1 = password:realm:salt H(A1) = SHA256(password:realm:salt) Response = KD( H(A1), nonce:nc:cnonce:qop:H(A2) ) = HMAC-SHA256( H(A1), nonce:nc:cnonce:qop:H(A2) ) Is there any objection to starting a new document to define HMAC and salted hash support? Any thoughts about the proposal above? Thanks, Rifaat --e89a8f923c168ab40805155dd296 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
<= div>
During the Gen-Art and SecDir reviews of the HTTP Di= gest draft, HMAC support was suggested by both reviewers.
= Also, the STUNbis team asked to add sup= port for salted hash.
= Based on the discussion with the ADs it was decided that, if there is inter= est, that these two issues be addressed in a separate draft.


Here is an initial proposal for adding HMAC and salted hash support th= at I would like to discuss:


=
Definitions
-----------

H(data) =3D Hash(data)
KD(secret, data) =3D HMAC-Hash(secret, data)


= A1 Calculation
-------= -------

If the solution is able to prov= ide only system wide salt, then:
A1 =3D username:realm:password:salt

If the solution is able to provide a per user salt, then:
A1 =3D password:realm:salt


Example

<= /div>
Using HMAC-SHA256 and per use= r salt calculation:
A1 =3D password:rea= lm:salt
H(A1) =3D SHA2= 56(password:realm:salt)


Is there any objection to= starting a new document to define HMAC and salted hash support?
Any thoughts about the proposal = above?

Thanks,
=A0Rifaat

--e89a8f923c168ab40805155dd296-- From nobody Tue May 5 17:27:07 2015 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 0C3AD1ACE84 for ; Tue, 5 May 2015 17:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_26=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-iJrhccOGmZ for ; Tue, 5 May 2015 17:27:05 -0700 (PDT) Received: from mail.blindspotsecurity.com (mail.blindspotsecurity.com [96.126.98.9]) by ietfa.amsl.com (Postfix) with SMTP id 1CCE21ACD36 for ; Tue, 5 May 2015 17:27:05 -0700 (PDT) Received: (qmail 15577 invoked from network); 6 May 2015 00:27:04 -0000 Received: from unknown (HELO pascal.sentinelchicken.org) (10.81.64.2) by lelantos.sentinelchicken.org with SMTP; 6 May 2015 00:27:04 -0000 Received: (qmail 4873 invoked from network); 6 May 2015 00:27:00 -0000 Received: from unknown (HELO shannon.sentinelchicken.org) (10.81.64.4) by pascal.sentinelchicken.org with SMTP; 6 May 2015 00:27:00 -0000 Received: (nullmailer pid 19096 invoked by uid 1000); Wed, 06 May 2015 00:26:56 -0000 Date: Tue, 5 May 2015 17:26:55 -0700 From: Tim To: Rifaat Shekh-Yusef Message-ID: <20150506002655.GW1109@sentinelchicken.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "http-auth@ietf.org" Subject: Re: [http-auth] HTTP Digest - HMAC & Salted Hash 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, 06 May 2015 00:27:06 -0000 If you're going to go through the effort of offering a salted hash at that level, wouldn't make more sense to use a modern one such as one of: https://tools.ietf.org/html/draft-josefsson-scrypt-kdf-02 https://www.ietf.org/rfc/rfc2898.txt (scrypt being preferred) For more info on the reasoning, see: http://chargen.matasano.com/chargen/2015/3/26/enough-with-the-salts-updates-on-secure-password-schemes.html tim On Tue, May 05, 2015 at 07:13:11PM -0400, Rifaat Shekh-Yusef wrote: > Hi, > > During the Gen-Art and SecDir reviews of the HTTP Digest draft, HMAC > support was suggested by both reviewers. > Also, the STUNbis team asked to add support for salted hash. > Based on the discussion with the ADs it was decided that, if there is > interest, that these two issues be addressed in a separate draft. > > > Here is an initial proposal for adding HMAC and salted hash support that I > would like to discuss: > > > Definitions > ----------- > > H(data) = Hash(data) > KD(secret, data) = HMAC-Hash(secret, data) > > > A1 Calculation > -------------- > > If the solution is able to provide only system wide salt, then: > A1 = username:realm:password:salt > > If the solution is able to provide a per user salt, then: > A1 = password:realm:salt > > > Example > ------- > > Using HMAC-SHA256 and per user salt calculation: > > A1 = password:realm:salt > H(A1) = SHA256(password:realm:salt) > Response = KD( H(A1), nonce:nc:cnonce:qop:H(A2) ) = HMAC-SHA256( H(A1), > nonce:nc:cnonce:qop:H(A2) ) > > > Is there any objection to starting a new document to define HMAC and salted > hash support? > Any thoughts about the proposal above? > > Thanks, > Rifaat > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth From nobody Tue May 5 18:18:53 2015 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 AAFE61B2B38 for ; Tue, 5 May 2015 18:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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, J_CHICKENPOX_26=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HLERD3ImjUsd for ; Tue, 5 May 2015 18:18:51 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97FA21B2ACB for ; Tue, 5 May 2015 18:18:17 -0700 (PDT) Received: by oign205 with SMTP id n205so162179881oig.2 for ; Tue, 05 May 2015 18:18:17 -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=47XSTiLDPaKqDSMmd8XiVi+2OmI1AcVGMLdhuLjK0oQ=; b=ClZxWgxP2TJ98aZ8PacFIX5IYPfK7kVzjn2cxHPBOp3ZpFL/HcMyf5wPLQ914rwpCm fmWdGYWKZnTYP3Jdek1PFPDE97GI0IE2RprsXFP5wE9ztaJU83pAe/fRHgG5tZp0v+wv YwbGC9VuaJ+swiT1rVbF/SfdRxuj+MpM3f+fCYdUURRp933PwLLF6yqQcZH1zgDJ7mkc krrnNhI9hmEPOQI9uICKgAcnFXDfwn7j+2v7SuilewiHoDyKGzdAFcKLZrrbalOuy3rY dunjeBQH9UO4e/kg6gKqlPJIE99HTyQBxTvZ78Q4/ZhHRqjqTvPiqR30tbFN7cmvSlts 4cOQ== MIME-Version: 1.0 X-Received: by 10.202.71.84 with SMTP id u81mr23497653oia.81.1430875097081; Tue, 05 May 2015 18:18:17 -0700 (PDT) Received: by 10.202.75.149 with HTTP; Tue, 5 May 2015 18:18:17 -0700 (PDT) In-Reply-To: <20150506002655.GW1109@sentinelchicken.org> References: <20150506002655.GW1109@sentinelchicken.org> Date: Tue, 5 May 2015 21:18:17 -0400 Message-ID: From: Rifaat Shekh-Yusef To: Tim Content-Type: multipart/alternative; boundary=001a113e4622e12d7c05155f9156 Archived-At: Cc: "http-auth@ietf.org" Subject: Re: [http-auth] HTTP Digest - HMAC & Salted Hash 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, 06 May 2015 01:18:52 -0000 --001a113e4622e12d7c05155f9156 Content-Type: text/plain; charset=ISO-8859-1 This proposal is simple and straightforward, and the change is restricted to the A1 value, and the H and KD functions. KDF-based approach is much more involved, and if we are to go that path I think it would be better to create a new scheme than to overload the Digest scheme. In fact, I have a SIP draft that discusses the idea of creating a new PBKDF2-based scheme: https://www.ietf.org/archive/id/draft-yusef-sipcore-key-derivation-00.txt Regards, Rifaat On Tue, May 5, 2015 at 8:26 PM, Tim wrote: > > If you're going to go through the effort of offering a salted hash at > that level, wouldn't make more sense to use a modern one such as one of: > https://tools.ietf.org/html/draft-josefsson-scrypt-kdf-02 > https://www.ietf.org/rfc/rfc2898.txt > > (scrypt being preferred) > > For more info on the reasoning, see: > > http://chargen.matasano.com/chargen/2015/3/26/enough-with-the-salts-updates-on-secure-password-schemes.html > > > tim > > > > On Tue, May 05, 2015 at 07:13:11PM -0400, Rifaat Shekh-Yusef wrote: > > Hi, > > > > During the Gen-Art and SecDir reviews of the HTTP Digest draft, HMAC > > support was suggested by both reviewers. > > Also, the STUNbis team asked to add support for salted hash. > > Based on the discussion with the ADs it was decided that, if there is > > interest, that these two issues be addressed in a separate draft. > > > > > > Here is an initial proposal for adding HMAC and salted hash support that > I > > would like to discuss: > > > > > > Definitions > > ----------- > > > > H(data) = Hash(data) > > KD(secret, data) = HMAC-Hash(secret, data) > > > > > > A1 Calculation > > -------------- > > > > If the solution is able to provide only system wide salt, then: > > A1 = username:realm:password:salt > > > > If the solution is able to provide a per user salt, then: > > A1 = password:realm:salt > > > > > > Example > > ------- > > > > Using HMAC-SHA256 and per user salt calculation: > > > > A1 = password:realm:salt > > H(A1) = SHA256(password:realm:salt) > > Response = KD( H(A1), nonce:nc:cnonce:qop:H(A2) ) = HMAC-SHA256( H(A1), > > nonce:nc:cnonce:qop:H(A2) ) > > > > > > Is there any objection to starting a new document to define HMAC and > salted > > hash support? > > Any thoughts about the proposal above? > > > > Thanks, > > Rifaat > > > _______________________________________________ > > http-auth mailing list > > http-auth@ietf.org > > https://www.ietf.org/mailman/listinfo/http-auth > > --001a113e4622e12d7c05155f9156 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This proposal is simple and straightforward, and the = change is restricted to the A1 value, and the H and KD functions.

KDF-based approach is much more involved, and if we are to = go that path I think it would be better to create a new scheme than to over= load the Digest scheme.
In fact, I have a SIP draft that disc= usses the idea of creating a new PBKDF2-based scheme:



On Tue, May 5, 2015 at 8:26 PM, Tim <tim-rese= arch@sentinelchicken.org> wrote:

If you're going to go through the effort of offering a salted hash at that level, wouldn't make more sense to use a modern one such as one of= :
=A0 https://tools.ietf.org/html/draft-josefsson-scrypt-kdf-02<= /a>
=A0 http= s://www.ietf.org/rfc/rfc2898.txt

(scrypt being preferred)

For more info on the reasoning, see:
=A0 http://c= hargen.matasano.com/chargen/2015/3/26/enough-with-the-salts-updates-on-secu= re-password-schemes.html


tim



On Tue, May 05, 2015 at 07:13:11PM -0400, Rifaat Shekh-Yusef wrote:
> Hi,
>
> During the Gen-Art and SecDir reviews of the HTTP Digest draft, HMAC > support was suggested by both reviewers.
> Also, the STUNbis team asked to add support for salted hash.
> Based on the discussion with the ADs it was decided that, if there is<= br> > interest, that these two issues be addressed in a separate draft.
>
>
> Here is an initial proposal for adding HMAC and salted hash support th= at I
> would like to discuss:
>
>
> Definitions
> -----------
>
> H(data) =3D Hash(data)
> KD(secret, data) =3D HMAC-Hash(secret, data)
>
>
> A1 Calculation
> --------------
>
> If the solution is able to provide only system wide salt, then:
> A1 =3D username:realm:password:salt
>
> If the solution is able to provide a per user salt, then:
> A1 =3D password:realm:salt
>
>
> Example
> -------
>
> Using HMAC-SHA256 and per user salt calculation:
>
> A1 =3D password:realm:salt
> H(A1) =3D SHA256(password:realm:salt)
> Response =3D KD( H(A1), nonce:nc:cnonce:qop:H(A2) ) =3D HMAC-SHA256( H= (A1),
> nonce:nc:cnonce:qop:H(A2) )
>
>
> Is there any objection to starting a new document to define HMAC and s= alted
> hash support?
> Any thoughts about the proposal above?
>
> Thanks,
>=A0 Rifaat

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


--001a113e4622e12d7c05155f9156-- From nobody Tue May 5 19:44:32 2015 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 368BE1B2A49 for ; Tue, 5 May 2015 19:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 knjbH6ljMyBw for ; Tue, 5 May 2015 19:44:30 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D251C1B2A34 for ; Tue, 5 May 2015 19:44:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2074; q=dns/txt; s=iport; t=1430880269; x=1432089869; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=yBGcJLzTREeMqAyCH/envFa9Ww5E+86Ax1f6qRmLlAw=; b=g2F8geuW20Y0Ah1vDES0/4IciPDnE7L5nHfTKH+Bx7E7u9OWbb7m0vTJ M2eZmQxhIbNAprKVyMePPp1tqHZpifShv9QAo6JbBxQqt1tV3V30DB2XA 5qFIz0MgQHKIXDOeTQFXmLoMEs8ldWFr6uPftYSkD+rLcyM6CzDeBQ62k o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ANBQD/fklV/4gNJK1cgwxTYYMYwgWISh6BG0wBAQEBAQGBC4QhAQEDASMRRQUNAQgaAhQMBgIEMBUSBA4giAkIsEWFLI4zAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EhihiFBR+CUC+BFgWGU4tKilaWLyNggSYdgVGCM4EBAQEB X-IronPort-AV: E=Sophos;i="5.13,377,1427760000"; d="scan'208";a="417379173" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-3.cisco.com with ESMTP; 06 May 2015 02:44:29 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t462iSxD019754 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 May 2015 02:44:29 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.45]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Tue, 5 May 2015 21:44:28 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: Rifaat Shekh-Yusef Thread-Topic: [http-auth] HTTP Digest - HMAC & Salted Hash Thread-Index: AQHQh6aSUcjMjuGWLkeK8KUVgO3GDQ== Date: Wed, 6 May 2015 02:44:28 +0000 Message-ID: <26CC875F-98D4-4C77-BD26-72A9CD068E08@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.220.189] Content-Type: text/plain; charset="utf-8" Content-ID: <6A071E2EA1830D4AA2436F1674437640@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "http-auth@ietf.org" Subject: Re: [http-auth] HTTP Digest - HMAC & Salted Hash 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, 06 May 2015 02:44:31 -0000 SGkgUmlmYWF0IC0gDQoNClRoYW5rcyBmb3IgcmFpc2luZyB0aGlzIGlzc3VlLiAgVGhpcyBpcyBv ZiBwYXJ0aWN1bGFyIGltcG9ydGFuY2UgdG8gdGhlIFNUVU5iaXMgZWZmb3J0IGdvaW5nIG9uIGlu IHRoZSBUUkFNIFdHLCBzbyBJIGFtIHZlcnkgaW50ZXJlc3RlZCBpbiBzZWVpbmcgdGhpcyB3b3Jr IHByb2dyZXNzLiAgSeKAmWxsIGFjdGl2ZWx5IHN1cHBvcnQgdGhlIHdvcmsgYW5kLCBpZiBuZWVk ZWQsIHdvdWxkIGFsc28gYmUgd2lsbGluZyB0byBjby1hdXRob3IuDQoNClRoYW5rcywNCg0KR29u emFsbw0KDQo+IEhpLA0KPiANCj4gRHVyaW5nIHRoZSBHZW4tQXJ0IGFuZCBTZWNEaXIgcmV2aWV3 cyBvZiB0aGUgSFRUUCBEaWdlc3QgZHJhZnQsIEhNQUMgc3VwcG9ydCB3YXMgc3VnZ2VzdGVkIGJ5 IGJvdGggcmV2aWV3ZXJzLg0KPiBBbHNvLCB0aGUgU1RVTmJpcyB0ZWFtIGFza2VkIHRvIGFkZCBz dXBwb3J0IGZvciBzYWx0ZWQgaGFzaC4NCj4gQmFzZWQgb24gdGhlIGRpc2N1c3Npb24gd2l0aCB0 aGUgQURzIGl0IHdhcyBkZWNpZGVkIHRoYXQsIGlmIHRoZXJlIGlzIGludGVyZXN0LCB0aGF0IHRo ZXNlIHR3byBpc3N1ZXMgYmUgYWRkcmVzc2VkIGluIGEgc2VwYXJhdGUgZHJhZnQuDQo+IA0KPiAN Cj4gSGVyZSBpcyBhbiBpbml0aWFsIHByb3Bvc2FsIGZvciBhZGRpbmcgSE1BQyBhbmQgc2FsdGVk IGhhc2ggc3VwcG9ydCB0aGF0IEkgd291bGQgbGlrZSB0byBkaXNjdXNzOg0KPiANCj4gDQo+IERl ZmluaXRpb25zDQo+IC0tLS0tLS0tLS0tDQo+IA0KPiBIKGRhdGEpID0gSGFzaChkYXRhKQ0KPiBL RChzZWNyZXQsIGRhdGEpID0gSE1BQy1IYXNoKHNlY3JldCwgZGF0YSkNCj4gDQo+IA0KPiBBMSBD YWxjdWxhdGlvbg0KPiAtLS0tLS0tLS0tLS0tLQ0KPiANCj4gSWYgdGhlIHNvbHV0aW9uIGlzIGFi bGUgdG8gcHJvdmlkZSBvbmx5IHN5c3RlbSB3aWRlIHNhbHQsIHRoZW46DQo+IEExID0gdXNlcm5h bWU6cmVhbG06cGFzc3dvcmQ6c2FsdA0KPiANCj4gSWYgdGhlIHNvbHV0aW9uIGlzIGFibGUgdG8g cHJvdmlkZSBhIHBlciB1c2VyIHNhbHQsIHRoZW46DQo+IEExID0gcGFzc3dvcmQ6cmVhbG06c2Fs dA0KPiANCj4gDQo+IEV4YW1wbGUNCj4gLS0tLS0tLQ0KPiANCj4gVXNpbmcgSE1BQy1TSEEyNTYg YW5kIHBlciB1c2VyIHNhbHQgY2FsY3VsYXRpb246DQo+IA0KPiBBMSA9IHBhc3N3b3JkOnJlYWxt OnNhbHQNCj4gSChBMSkgPSBTSEEyNTYocGFzc3dvcmQ6cmVhbG06c2FsdCkNCj4gUmVzcG9uc2Ug PSBLRCggSChBMSksIG5vbmNlOm5jOmNub25jZTpxb3A6SChBMikgKSA9IEhNQUMtU0hBMjU2KCBI KEExKSwgbm9uY2U6bmM6Y25vbmNlOnFvcDpIKEEyKSApDQo+IA0KPiANCj4gSXMgdGhlcmUgYW55 IG9iamVjdGlvbiB0byBzdGFydGluZyBhIG5ldyBkb2N1bWVudCB0byBkZWZpbmUgSE1BQyBhbmQg c2FsdGVkIGhhc2ggc3VwcG9ydD8NCj4gQW55IHRob3VnaHRzIGFib3V0IHRoZSBwcm9wb3NhbCBh Ym92ZT8NCj4gDQo+IFRoYW5rcywNCj4gIFJpZmFhdA0K From nobody Wed May 6 09:24:40 2015 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 EF2291B2BD4 for ; Wed, 6 May 2015 09:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DcYRjnZ8S446 for ; Wed, 6 May 2015 09:24:37 -0700 (PDT) Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5D491B2BD3 for ; Wed, 6 May 2015 09:24:36 -0700 (PDT) Received: by laat2 with SMTP id t2so11421888laa.1 for ; Wed, 06 May 2015 09:24:35 -0700 (PDT) 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:date :message-id:subject:from:to:cc:content-type; bh=OlP1bG9K8+kwQqObU5erS03Z+wyAAm+wYOWGW0IKepU=; b=YJPtikShKu4t1OC43yCJo/T1Dl5P3cOpyookQwmx1tBPfudIzNZKP/rKJ2sq+882Xi mCIIRR+7DhMW+YQpGcLlsED/LdcdKDDfpDp5lZgoqviEbZBGzAArsNP1iTgD2+i/nAP+ +xwt0zpaysaWsQDO5ZkPEgHE7qq5zJPhGgmYwulc+alkrZkx2igLF0ViacglVpJjT6z7 u8feOSX3nKI8bcpF6xIzb/edZpa3U8HOqSfUDBqR2CdNhn9W6Xxd0ex0hQAIXbWE4LvA 0NgkGxEYlk/LT/6N1Bv0EJ45baKQqJgF3gMhLPcstro3zWZmz6Vp9kAWDDpgfeQwRFBM 5baw== X-Gm-Message-State: ALoCoQlKDq96silolFH7o/H9iEOvA+VwnhshIANN+Q3so7+T80TVTOkrVr2gXslZXR9Xizupkmfj MIME-Version: 1.0 X-Received: by 10.112.173.167 with SMTP id bl7mr29005943lbc.83.1430929475371; Wed, 06 May 2015 09:24:35 -0700 (PDT) Received: by 10.25.141.6 with HTTP; Wed, 6 May 2015 09:24:35 -0700 (PDT) Received: by 10.25.141.6 with HTTP; Wed, 6 May 2015 09:24:35 -0700 (PDT) In-Reply-To: <26CC875F-98D4-4C77-BD26-72A9CD068E08@cisco.com> References: <26CC875F-98D4-4C77-BD26-72A9CD068E08@cisco.com> Date: Wed, 6 May 2015 12:24:35 -0400 Message-ID: From: Simon Perreault To: "Gonzalo Salgueiro (gsalguei)" Content-Type: multipart/alternative; boundary=001a11c33dec141ce105156c3bd1 Archived-At: Cc: "http-auth@ietf.org" Subject: Re: [http-auth] HTTP Digest - HMAC & Salted Hash 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, 06 May 2015 16:24:39 -0000 --001a11c33dec141ce105156c3bd1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Le 2015-05-05 10:44 PM, "Gonzalo Salgueiro (gsalguei)" a =C3=A9crit : > Thanks for raising this issue. This is of particular importance to the STUNbis effort going on in the TRAM WG, so I am very interested in seeing this work progress. I=E2=80=99ll actively support the work and, if needed,= would also be willing to co-author. Same for me! Simon --001a11c33dec141ce105156c3bd1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Le 2015-05-05 10:44 PM, "Gonzalo Salgueiro (gsalguei)" <gsalguei@cisco.com> a =C3=A9crit=C2= =A0:
> Thanks for raising this issue.=C2=A0 This is of particular importance = to the STUNbis effort going on in the TRAM WG, so I am very interested in s= eeing this work progress.=C2=A0 I=E2=80=99ll actively support the work and,= if needed, would also be willing to co-author.

Same for me!

Simon

--001a11c33dec141ce105156c3bd1-- From nobody Thu May 14 04:28:07 2015 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 208231A1BBD for ; Thu, 14 May 2015 04:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_26=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QB8-Xq3F51sD for ; Thu, 14 May 2015 04:28:05 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 52C641A3BA4 for ; Thu, 14 May 2015 04:27:50 -0700 (PDT) Received: from [IPv6:2602:43:2d9:4500:ac82:1f0:7676:d6da] (unknown [IPv6:2602:43:2d9:4500:ac82:1f0:7676:d6da]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 893C2200C1; Thu, 14 May 2015 13:27:49 +0200 (CEST) Message-ID: <555486A7.8060103@petit-huguenin.org> Date: Thu, 14 May 2015 05:27:35 -0600 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.6.0 MIME-Version: 1.0 To: Rifaat Shekh-Yusef , "http-auth@ietf.org" References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3oGG6dgEpoJ2DncDBNEAcSew3nA4CP06K" Archived-At: Subject: Re: [http-auth] HTTP Digest - HMAC & Salted Hash 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, 14 May 2015 11:28:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3oGG6dgEpoJ2DncDBNEAcSew3nA4CP06K Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I am also interested in seeing progress for the work, and I am willing to= help. As co-author of stunbis, I am especially interested to discuss ho= w we can coordinate a shared IANA registry for password hash method betwe= en STUN, HTTP and eventually SIP. Thanks. On 05/05/2015 05:13 PM, Rifaat Shekh-Yusef wrote: > Hi, >=20 > During the Gen-Art and SecDir reviews of the HTTP Digest draft, HMAC > support was suggested by both reviewers. > Also, the STUNbis team asked to add support for salted hash. > Based on the discussion with the ADs it was decided that, if there is > interest, that these two issues be addressed in a separate draft. >=20 >=20 > Here is an initial proposal for adding HMAC and salted hash support tha= t I > would like to discuss: >=20 >=20 > Definitions > ----------- >=20 > H(data) =3D Hash(data) > KD(secret, data) =3D HMAC-Hash(secret, data) >=20 >=20 > A1 Calculation > -------------- >=20 > If the solution is able to provide only system wide salt, then: > A1 =3D username:realm:password:salt >=20 > If the solution is able to provide a per user salt, then: > A1 =3D password:realm:salt >=20 >=20 > Example > ------- >=20 > Using HMAC-SHA256 and per user salt calculation: >=20 > A1 =3D password:realm:salt > H(A1) =3D SHA256(password:realm:salt) > Response =3D KD( H(A1), nonce:nc:cnonce:qop:H(A2) ) =3D HMAC-SHA256( H(= A1), > nonce:nc:cnonce:qop:H(A2) ) >=20 >=20 > Is there any objection to starting a new document to define HMAC and sa= lted > hash support? > Any thoughts about the proposal above? >=20 > Thanks, > Rifaat >=20 --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug --3oGG6dgEpoJ2DncDBNEAcSew3nA4CP06K Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVVIayAAoJECnERZXWan7E78AQAIqlv9K9Q2XdAv8w461L6u3E xxkg41laOZjHt6C8xRksSezpkXM1hDSMg5dUA4PimJQLgp3ARYm89C5iZjbjuVpn CVObq1xbhPLwtjkbShLOW1ps7HbjSQ7t8klT5Qb82waNIJueyavNJUijkCWQS84Y 2EtjjfjidHlIsRAoFSLNOtlD9HtcdpSucnWyznLDC0vp1yOePf9Dw0vx81aD8AbK jFAWEmwpmvOu8Ez8WKukaq8Xr7KL+Jh1cCWgaPENLrIzspcAXKWToXQwKCtSgXu2 xkT11MSz+VPJ/oLC4wJjCaTkEVTmoeXpRcjMdSOSqVaic51gRYzxU9m2HINNTec9 Um6d0MeKYZbw7OdUXvpDWiZxblFw0/7z19UhofN7fw+8eTQOQBc1DA767kfnZa4T od9jjIrgKfP2x2tZV6R04UsdrzhW2A3f6QE9H8tWPn6MLmiKPjL98BaJ7yAWHlw2 rGjq9W00bnqJCNkxkoYwH0cZ4ut0ZHto2ImsZ5HHyWjDZGBcSv/bYS0ovD48jR/9 wMkUVe/qyKjcWamAgc++pO14HC5h80jC3tnmNni+OxUUIRxTshvLj8gmLCFqyOwm CGXKb8ms3od3WkqGnXIPd6YUb1QGNXffHN7ISc/N03aoY35+/7fxW3k6ZYrjNWvO 2Ees4kVtO1f4IB4Uzx/K =TWRC -----END PGP SIGNATURE----- --3oGG6dgEpoJ2DncDBNEAcSew3nA4CP06K-- From nobody Mon May 18 11:59:55 2015 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 D17351B2A0D for ; Mon, 18 May 2015 11:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.049 X-Spam-Level: * X-Spam-Status: No, score=1.049 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KA7Q_CfHOM0L for ; Mon, 18 May 2015 11:59:52 -0700 (PDT) Received: from mx02.posteo.de (mx02.posteo.de [89.146.194.165]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA3AF1ACD43 for ; Mon, 18 May 2015 11:59:50 -0700 (PDT) Received: from dovecot03.posteo.de (unknown [185.67.36.28]) by mx02.posteo.de (Postfix) with ESMTPS id 3068122B47CF; Mon, 18 May 2015 20:59:45 +0200 (CEST) Received: from mail.posteo.de (localhost [127.0.0.1]) by dovecot03.posteo.de (Postfix) with ESMTPSA id 3lr8m05zMsz5vN8; Mon, 18 May 2015 20:59:44 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Sophie Bremer In-Reply-To: Date: Mon, 18 May 2015 21:01:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <829125AD-963D-4A80-A827-31080C60DACB@netzkonform.de> References: To: Rifaat Shekh-Yusef X-Mailer: Apple Mail (2.1085) Archived-At: Cc: http-auth@ietf.org Subject: Re: [http-auth] HTTP Digest - HMAC & Salted Hash 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, 18 May 2015 18:59:55 -0000 Hi Rifaat, I am interested in implementing the proposal. Unfortunately this requires a transition over several years, because it = includes a completely new generated A1. Do you expect changes to the new A1s below, or can we start with = calculation? Best Regards, Sophie Am 06.05.2015 um 01:13 schrieb Rifaat Shekh-Yusef: > Hi, >=20 > During the Gen-Art and SecDir reviews of the HTTP Digest draft, HMAC = support was suggested by both reviewers. > Also, the STUNbis team asked to add support for salted hash. > Based on the discussion with the ADs it was decided that, if there is = interest, that these two issues be addressed in a separate draft. >=20 >=20 > Here is an initial proposal for adding HMAC and salted hash support = that I would like to discuss: >=20 >=20 > Definitions > ----------- >=20 > H(data) =3D Hash(data) > KD(secret, data) =3D HMAC-Hash(secret, data) >=20 >=20 > A1 Calculation > -------------- >=20 > If the solution is able to provide only system wide salt, then: > A1 =3D username:realm:password:salt >=20 > If the solution is able to provide a per user salt, then: > A1 =3D password:realm:salt >=20 >=20 > Example > ------- >=20 > Using HMAC-SHA256 and per user salt calculation: >=20 > A1 =3D password:realm:salt > H(A1) =3D SHA256(password:realm:salt) > Response =3D KD( H(A1), nonce:nc:cnonce:qop:H(A2) ) =3D HMAC-SHA256( = H(A1), nonce:nc:cnonce:qop:H(A2) ) >=20 >=20 > Is there any objection to starting a new document to define HMAC and = salted hash support? > Any thoughts about the proposal above? >=20 > Thanks, > Rifaat >=20 > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth From nobody Tue May 19 05:01:59 2015 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 C72CB1A8849 for ; Tue, 19 May 2015 05:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 513P5jvg_Q7N for ; Tue, 19 May 2015 05:01:55 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B28DB1A8846 for ; Tue, 19 May 2015 05:01:52 -0700 (PDT) Received: by oign205 with SMTP id n205so8744168oig.2 for ; Tue, 19 May 2015 05:01:52 -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=nzb4Vd6UjdK2+pO0FWxIIJ8luFjY44DYiuBJHqYNoJk=; b=InpVHw6AFUin9q5NCLmSPDUUIJhVbRTnu+5OIVi8ZZpGn+K1bHMFO0z4d1Jd7Kb6vI hmEBGJvstE/fK3JN/2FcBRSDyNjkJ1EI9r/gV0Ktk3HT1GtbNuQ7ZvnMEiz7BeHryFL3 87NXo3wpRoCiWvVs5eCmpa1/neR21L30rAF+j762eP1zNCgpBgBOt0NUxlKFzPJE2EnX 66FRuQF5mCMMvinm1r/j7D6iVQTncMig+1ieucmZ9zmoO9/XhIy0gYzqx6HFGKPVBQlI Qga6NLCaD/fAx+rq5KnvRnlsXJ7Tz85hvhWT4zYHguIJlABTBofDKF1C9sAgDKWXL/Mn W8mw== MIME-Version: 1.0 X-Received: by 10.182.196.34 with SMTP id ij2mr3728911obc.71.1432036912025; Tue, 19 May 2015 05:01:52 -0700 (PDT) Received: by 10.202.75.149 with HTTP; Tue, 19 May 2015 05:01:51 -0700 (PDT) In-Reply-To: <829125AD-963D-4A80-A827-31080C60DACB@netzkonform.de> References: <829125AD-963D-4A80-A827-31080C60DACB@netzkonform.de> Date: Tue, 19 May 2015 08:01:51 -0400 Message-ID: From: Rifaat Shekh-Yusef To: Sophie Bremer Content-Type: multipart/alternative; boundary=089e0153870c7256e005166e1352 Archived-At: Cc: "http-auth@ietf.org" Subject: Re: [http-auth] HTTP Digest - HMAC & Salted Hash 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, 19 May 2015 12:01:57 -0000 --089e0153870c7256e005166e1352 Content-Type: text/plain; charset=ISO-8859-1 Thank you all for your response and support for this work. Sophie, I think you should hold off on starting implementing this until we have a meaningful discussion, either on the mailing list or during the coming IETF conference in Prague. Regards, Rifaat On Mon, May 18, 2015 at 3:01 PM, Sophie Bremer wrote: > Hi Rifaat, > > I am interested in implementing the proposal. > Unfortunately this requires a transition over several years, because it > includes a completely new generated A1. > Do you expect changes to the new A1s below, or can we start with > calculation? > > Best Regards, > Sophie > > Am 06.05.2015 um 01:13 schrieb Rifaat Shekh-Yusef: > > > Hi, > > > > During the Gen-Art and SecDir reviews of the HTTP Digest draft, HMAC > support was suggested by both reviewers. > > Also, the STUNbis team asked to add support for salted hash. > > Based on the discussion with the ADs it was decided that, if there is > interest, that these two issues be addressed in a separate draft. > > > > > > Here is an initial proposal for adding HMAC and salted hash support that > I would like to discuss: > > > > > > Definitions > > ----------- > > > > H(data) = Hash(data) > > KD(secret, data) = HMAC-Hash(secret, data) > > > > > > A1 Calculation > > -------------- > > > > If the solution is able to provide only system wide salt, then: > > A1 = username:realm:password:salt > > > > If the solution is able to provide a per user salt, then: > > A1 = password:realm:salt > > > > > > Example > > ------- > > > > Using HMAC-SHA256 and per user salt calculation: > > > > A1 = password:realm:salt > > H(A1) = SHA256(password:realm:salt) > > Response = KD( H(A1), nonce:nc:cnonce:qop:H(A2) ) = HMAC-SHA256( H(A1), > nonce:nc:cnonce:qop:H(A2) ) > > > > > > Is there any objection to starting a new document to define HMAC and > salted hash support? > > Any thoughts about the proposal above? > > > > Thanks, > > Rifaat > > > > _______________________________________________ > > http-auth mailing list > > http-auth@ietf.org > > https://www.ietf.org/mailman/listinfo/http-auth > > --089e0153870c7256e005166e1352 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thank you all for your response and support for this work.=


Sophie,

I t= hink you should hold off on starting implementing this until we have a mean= ingful discussion, either on the mailing list or during the coming IETF con= ference in Prague.

Regards,
=A0Rifaa= t





On M= on, May 18, 2015 at 3:01 PM, Sophie Bremer <sophie.bremer@netzk= onform.de> wrote:
Hi Rifaa= t,

I am interested in implementing the proposal.
Unfortunately this requires a transition over several years, because it inc= ludes a completely new generated A1.
Do you expect changes to the new A1s below, or can we start with calculatio= n?

Best Regards,
Sophie

Am 06.05.2015 um 01:13 schrieb Rifaat Shekh-Yusef:

> Hi,
>
> During the Gen-Art and SecDir reviews of the HTTP Digest draft, HMAC s= upport was suggested by both reviewers.
> Also, the STUNbis team asked to add support for salted hash.
> Based on the discussion with the ADs it was decided that, if there is = interest, that these two issues be addressed in a separate draft.
>
>
> Here is an initial proposal for adding HMAC and salted hash support th= at I would like to discuss:
>
>
> Definitions
> -----------
>
> H(data) =3D Hash(data)
> KD(secret, data) =3D HMAC-Hash(secret, data)
>
>
> A1 Calculation
> --------------
>
> If the solution is able to provide only system wide salt, then:
> A1 =3D username:realm:password:salt
>
> If the solution is able to provide a per user salt, then:
> A1 =3D password:realm:salt
>
>
> Example
> -------
>
> Using HMAC-SHA256 and per user salt calculation:
>
> A1 =3D password:realm:salt
> H(A1) =3D SHA256(password:realm:salt)
> Response =3D KD( H(A1), nonce:nc:cnonce:qop:H(A2) ) =3D HMAC-SHA256( H= (A1), nonce:nc:cnonce:qop:H(A2) )
>
>
> Is there any objection to starting a new document to define HMAC and s= alted hash support?
> Any thoughts about the proposal above?
>
> Thanks,
>=A0 Rifaat
>
> __________________= _____________________________
> http-auth mailing list
> http-auth@ietf.org
> https://www.ietf.org/mailman/listinfo/http-auth


--089e0153870c7256e005166e1352-- From nobody Sat May 23 04:04:38 2015 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 186F81A90E2; Fri, 22 May 2015 23:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.56 X-Spam-Level: X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 VmAdDZGomZ4W; Fri, 22 May 2015 23:07:22 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A08A1A90D7; Fri, 22 May 2015 23:07:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.13,480,1427752800"; d="asc'?scan'208";a="126053707" Received: from 178.92.69.86.rev.sfr.net (HELO [192.168.1.44]) ([86.69.92.178]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 23 May 2015 08:07:19 +0200 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_9B5093EF-E174-4DF9-ADCA-F46F42B365D6"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Karthikeyan Bhargavan In-Reply-To: <20150216115457.3c16fdbf@latte.josefsson.org> Date: Sat, 23 May 2015 08:07:17 +0200 Message-Id: References: <54DC00D0.2050900@cs.tcd.ie> <87r3tqqj9y.fsf@latte.josefsson.org> <20150216115457.3c16fdbf@latte.josefsson.org> To: Simon Josefsson X-Mailer: Apple Mail (2.1878.6) Archived-At: X-Mailman-Approved-At: Sat, 23 May 2015 04:04:37 -0700 Cc: "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" Subject: Re: [http-auth] [kitten] [saag] AD sponsoring draft-hansen-scram-sha256 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, 23 May 2015 06:07:27 -0000 --Apple-Mail=_9B5093EF-E174-4DF9-ADCA-F46F42B365D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 >> We have a solution for that: >> https://tools.ietf.org/html/draft-ietf-tls-session-hash If a TLS connection uses the tls-session-hash, the tls-unique channel = binding becomes a good channel identifier for use in SCRAM (avoiding Triple = Handshake-style attacks). So either SCRAM could require tls-session-hash, or we could update = RFC5929 to require it (in the same way that it already requires RFC5746). I have a separate question: would there be value in defining a new = session-level channel binding (updating rfc5929) based on tls-session-hash? The advantage would be to obtain authenticated session resumption. That is, once a client has used SCRAM to authenticate on one connection, = it can reuse that credential on all resumed connections, until a new full handshake is performed. I = don=92t know how commonly we use session resumption in non-web scenarios, but the vast majority of = connections initiated by web browsers use abbreviated handshakes. Best, Karthik >=20 > Then SCRAM-SHA256 should normatively references that and require that > it is implemented for secure use of SCRAM with channel bindings. = There > are drawbacks with that approach: it is not widely implemented, not > published as an RFC that updates earlier TLS versions, and difficult > for SCRAM implementers to validate (usually the TLS stack is opaque to > the SCRAM implementer). I could live with that though, as a way of > pushing the current security problem down from the IETF protocol layer > into the implementation layer. >=20 > Alternatively, use a new channel binding type that use the extended > master secret derivation as described by the document above. I could > update draft-josefsson-sasl-tls-cb to describe this approach. >=20 > /Simon > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten --Apple-Mail=_9B5093EF-E174-4DF9-ADCA-F46F42B365D6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVYBkWAAoJEB/WSo9veuUKybYH+QGJuJL8kTJBHTobgxiPBN2B DNUq+rNQa1ocNHvFUtVsJ/xiPfBOmCtXYlkk09PO2i03vPhJJCAea4hC1PVB51iB W7KPUELMp0o6EYvNnStGKWlOLQ7oUQcsXUNXZxvlpaVsd0WUg8GcfzgL2wEZQiWM LEQ5Ajcwx4rQYnaK/uFxsg8E1Hb+2xlLema2Vu/IKcR9FrxsP+FkYf5GPzOC9O3v lZi3czoWfEWPqiE9MENpddhPpU3eNkLxV6/C1wHPdqOlGLStYqfclpyBSTR7sepP nNTP2jz1mlAfIQUPiHdt2VU9SVVSwPAvzipheM3p8kF2r8qdbS9kQBRVKi5B6Vo= =xpYT -----END PGP SIGNATURE----- --Apple-Mail=_9B5093EF-E174-4DF9-ADCA-F46F42B365D6-- From nobody Sat May 23 07:35:45 2015 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 41A1A1A1B48; Sat, 23 May 2015 07:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TuhBST7vzYxt; Sat, 23 May 2015 07:35:43 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07FD51A1B6B; Sat, 23 May 2015 07:35:42 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t4NEZROp030315 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Sat, 23 May 2015 16:35:29 +0200 Date: Sat, 23 May 2015 16:35:26 +0200 From: Simon Josefsson To: Karthikeyan Bhargavan Message-ID: <20150523163526.7e7d5e14@latte.josefsson.org> In-Reply-To: References: <54DC00D0.2050900@cs.tcd.ie> <87r3tqqj9y.fsf@latte.josefsson.org> <20150216115457.3c16fdbf@latte.josefsson.org> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/.hvmA=uvI9hcR2USMr=tHVP"; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: "kitten@ietf.org" , "http-auth@ietf.org" , "saag@ietf.org" Subject: Re: [http-auth] [kitten] [saag] AD sponsoring draft-hansen-scram-sha256 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, 23 May 2015 14:35:44 -0000 --Sig_/.hvmA=uvI9hcR2USMr=tHVP Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable > I have a separate question: would there be value in defining a new > session-level channel binding (updating rfc5929) based on > tls-session-hash? I offered https://tools.ietf.org/html/draft-josefsson-sasl-tls-cb-03 as an alternative to tls-unique back in the days. The issue with using only the client/server-random (a'la TLS Finished) was discussed back then and for -01 in 2008 I fixed the construct to be more secure (credit to Eric Rescorla and Sam Hartman who made me aware of the concern). My draft derives the channel binding in a way similar to tls-session-hash. I would appreciate if you could take a look and tell me if you believe that it would solve the triple-handshake concern. /Simon --Sig_/.hvmA=uvI9hcR2USMr=tHVP Content-Type: application/pgp-signature Content-Description: OpenPGP digital signatur -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVYJAuAAoJEIYLf7sy+BGdyvoH/jop/Fr3jQP6ceR15F/S6Ac/ bwuPbeNAu8CuRcmTeidjlWKneysggtJQwfun0aNeBgkzYbUXzxZ5PQyKWaLfu+Q5 yrXI9+ZvOeGf3K56E6ztHkr5qsRy1DK+V7ZwwBWbpDQFYeWGtST+vSOQcQ3/bybS 1uDTFBMGW51WL+elo06ype8NOZxKx9rZmPMWICzo19cB0ZvKz0O9twQ3k0IcwDQe cfpxqHhJSPQehu+xCN28iEN+dnTD7YlQgq0K/938zisZY/rtAVh11LuVv9ezfjnb TiYUpcIhEO43gtHcOszeVCTArAbUXIWK7+O+6XmQmvcVd/UwRQAvAQUGdrPIy4c= =PNiz -----END PGP SIGNATURE----- --Sig_/.hvmA=uvI9hcR2USMr=tHVP-- From nobody Sun May 31 08:53:12 2015 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 3B1991A03AB for ; Sun, 31 May 2015 08:53:11 -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 4UQwQt7b5zgA for ; Sun, 31 May 2015 08:53:09 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 799991A0393 for ; Sun, 31 May 2015 08:53:09 -0700 (PDT) Received: by oihd6 with SMTP id d6so86381499oih.2 for ; Sun, 31 May 2015 08:53:09 -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=mu99DoS6FS+1qcANntDFLSoJIBVLiY4hsAtXzGQFgyg=; b=chDezZl2vYfdNu1KQlP/r2GJn4Apoyd2TyRuAic1tExwIxOvHq0Y5va7kQIJfVI8hx A3P5mzcqZ1VW9ucjGwiQU2jD8J+fHl+xUjFis0VUghqzZg43oFyPwO3yp8p6YasM1vaj Otb1lbXpAWijY4rsYgp0DFbSb6vtSTbRoKRIcotNixPCQOwLRi/05B26t8cCTQp3A6pf NMgpSEGF6Iw1tg7Tekb2s3EmCoG3ulRLdx2/jHx+WioHp9CdgMHgMCVmO5I3CUOs70wQ 0PcSQcLPRBdZWZpltWdSkvEb5IUrQ5XE0Ru9ZGDUoDsj5Xy0eL+EwjiRT4ScwhM/uUEJ pnVg== MIME-Version: 1.0 X-Received: by 10.182.148.5 with SMTP id to5mr5607765obb.71.1433087589009; Sun, 31 May 2015 08:53:09 -0700 (PDT) Received: by 10.202.197.142 with HTTP; Sun, 31 May 2015 08:53:08 -0700 (PDT) In-Reply-To: <20150531154835.3639.52041.idtracker@ietfa.amsl.com> References: <20150531154835.3639.52041.idtracker@ietfa.amsl.com> Date: Sun, 31 May 2015 11:53:08 -0400 Message-ID: From: Rifaat Shekh-Yusef To: "http-auth@ietf.org" Content-Type: multipart/alternative; boundary=089e013a010eacdd6d051762b492 Archived-At: Subject: [http-auth] Fwd: New Version Notification for draft-yusef-httpauth-srp-scheme-00.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 May 2015 15:53:11 -0000 --089e013a010eacdd6d051762b492 Content-Type: text/plain; charset=ISO-8859-1 Hi, Yaron and I have just submitted a draft that defines a new authentication scheme based on the SRP protocol, to be used with the HTTP Authentication Framework. We would appreciate any thoughts, reviews, and feedback on this document. Regards, Rifaat ---------- Forwarded message ---------- From: Date: Sun, May 31, 2015 at 11:48 AM Subject: New Version Notification for draft-yusef-httpauth-srp-scheme-00.txt To: Rifaat Shekh-Yusef , Yaron Sheffer < yaronf.ietf@gmail.com> A new version of I-D, draft-yusef-httpauth-srp-scheme-00.txt has been successfully submitted by Rifaat Shekh-Yusef and posted to the IETF repository. Name: draft-yusef-httpauth-srp-scheme Revision: 00 Title: HTTP Secure Remote Password (SRP) Authentication Scheme Document date: 2015-05-31 Group: Individual Submission Pages: 11 URL: https://www.ietf.org/internet-drafts/draft-yusef-httpauth-srp-scheme-00.txt Status: https://datatracker.ietf.org/doc/draft-yusef-httpauth-srp-scheme/ Htmlized: https://tools.ietf.org/html/draft-yusef-httpauth-srp-scheme-00 Abstract: This document defines an HTTP Authentication Scheme that is based on the Secure Remote Password (SRP) protocol. The SRP protocol is an Augmented Password Authenticated Key Exchange (PAKE) protocol suitable for authenticating users and exchanging keys over an untrusted network. 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. The IETF Secretariat --089e013a010eacdd6d051762b492 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

Yaron and I have just su= bmitted a draft that defines a new authentication scheme based on the SRP p= rotocol, to be used with the HTTP Authentication Framework.
We wo= uld appreciate any thoughts, reviews, and feedback on this document.

Regards,
=A0Rifaat




------= ---- Forwarded message ----------
From: <intern= et-drafts@ietf.org>
Date: Sun, May 31, 2015 at 11:48 AMSubject: New Version Notification for draft-yusef-httpauth-srp-scheme-00.t= xt
To: Rifaat Shekh-Yusef <r= ifaat.ietf@gmail.com>, Yaron Sheffer <yaronf.ietf@gmail.com>



A new version of I-D, draft-yusef-httpauth-srp-scheme-00.txt
has been successfully submitted by Rifaat Shekh-Yusef and posted to the
IETF repository.

Name:=A0 =A0 =A0 =A0 =A0 =A0draft-yusef-httpauth-srp-scheme
Revision:=A0 =A0 =A0 =A000
Title:=A0 =A0 =A0 =A0 =A0 HTTP Secure Remote Password (SRP) Authentication = Scheme
Document date:=A0 2015-05-31
Group:=A0 =A0 =A0 =A0 =A0 Individual Submission
Pages:=A0 =A0 =A0 =A0 =A0 11
URL:=A0 =A0 =A0 =A0 =A0 =A0 https://www.ietf= .org/internet-drafts/draft-yusef-httpauth-srp-scheme-00.txt
Status:=A0 =A0 =A0 =A0 =A0https://datatracker.ietf.org= /doc/draft-yusef-httpauth-srp-scheme/
Htmlized:=A0 =A0 =A0 =A0https://tools.ietf.org/html/draft= -yusef-httpauth-srp-scheme-00


Abstract:
=A0 =A0This document defines an HTTP Authentication Scheme that is based on=
=A0 =A0the Secure Remote Password (SRP) protocol.=A0 The SRP protocol is an=
=A0 =A0Augmented Password Authenticated Key Exchange (PAKE) protocol
=A0 =A0suitable for authenticating users and exchanging keys over an
=A0 =A0untrusted network.




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.

The IETF Secretariat


--089e013a010eacdd6d051762b492--