Subject: [Cfrg] Another PAKE question

From: Yoav Nir <[email-masked]>
Date: Thu, 9 Jan 2014 06:09:32 +0000

Hi

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

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

The draft in question is called "Mutual Authentication Protocol for HTTP".

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

Yoav
co-chair of HTTP-Auth

Mailing list details:
 * http-auth List Information: https://www.ietf.org/mailman/listinfo/http-auth
 * http-auth List Archives: http://www.ietf.org/mail-archive/web/http-auth/current/maillist.html
 * http-auth Posting Address (requires registration): [email-masked]

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 8 Jan 2014 23:25:10 -0800 (PST)

Hi Yoav,

On Wed, January 8, 2014 10:09 pm, Yoav Nir wrote:
> Hi
>
> I almost feel like I'm asking for trouble after the roast that Dan went
> through, but some on this list might want to consider another PAKE going
> through an IETF working group.

  While I think you are definitely asking for trouble, it's good that you do.
Trying to fly under the radar would not be a good thing.

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

  It doesn't look like that draft specifies a PAKE. It seems to specify the
exchange of data that can be used by a PAKE, but not necessarily. Section
11 states:

    Cryptographic authentication algorithms which are used with this
    protocol will be defined separately….

    All algorithm used with this protocol SHOULD provide secure mutual
    authentication between client and servers, and generate a
    cryptographically strong shared secret value z, equivalently strong
    to or stronger than the hash function H. If any passwords (or pass-
    phrases or any equivalents, i.e. weak secrets) are involved, these
    SHOULD NOT be guessable from any data transmitted in the protocol,
    even if an attacker (either an eavesdropper or an active server)
    knows the possible thoroughly-searchable candidate list of the
    passwords.

That SHOULD and SHOULD NOT mean that it could actually use an
authentication algorithm that doesn't provide mutual authentication
and that is susceptible to an off-line dictionary attack. You might
want to make those a MUST and MUST NOT.

  So where is the separately defined protocol that this draft uses?

  Also, figure 5 seems almost like a joke. Is this protocol _really_
that complicated? A security protocol that complicated seems like
a recipe for disaster.

  regards,

  Dan.

> Yoav
> co-chair of HTTP-Auth
>
> Mailing list details:
>  * http-auth List Information:
> https://www.ietf.org/mailman/listinfo/http-auth
>  * http-auth List Archives:
> http://www.ietf.org/mail-archive/web/http-auth/current/maillist.html
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/cfrg
>

---

From: Yoav Nir <[email-masked]>
Date: Thu, 9 Jan 2014 08:00:22 +0000

On Jan 9, 2014, at 9:25 AM, Dan Harkins <[email-masked]>
 wrote:

> exchange of data that can be used by a PAKE, but not necessarily.

Right. I forgot to link to the auxiliary algorithm draft:
http://tools.ietf.org/html/draft-oiwa-httpauth-mutual-algo-01

> Section
>    protocol will be defined separately..
> 
> Email secured by Check Point