Subject: Re: [Cfrg] [http-auth] Fwd: Another PAKE question

From: Yutaka OIWA <[email-masked]>
Date: Thu, 6 Mar 2014 03:30:26 +0900

Watson, Sorry, I completely missed this mail in the pile of unread mails.

# Thanks Yoav, your comment in WG reminds me and help finding out of this.

AFAIK, putting the transaction history into the calculation is
already embedded as the values t_1 and t_2 described in
the algorithm in
<https://tools.ietf.org/html/draft-oiwa-httpauth-mutual-algo-01>,
Sections 2.2 and 2.3.
Isn't this t_1 and t_2 (put into the calculation of z) suffice for the purpose?

My understanding is that the functionality what Watson mentioned is a
fundamental requirements for all PAKE primitives, and
is already embedded in the specification of such primitives' layer.
If this assumption is not, or if we need to protect more values than
the values appear in the cryptographic primitives, I agree that the
functionality
should be again implemented in the layer of the "HTTP Mutual authentication".
In such case I will do it with our cryptographer colleagues.

Sorry for the very late reply, but I'm very happy if you can help me
better understanding of this issue.

2014-01-10 0:24 GMT+09:00 Yoav Nir <[email-masked]>:
> Hi.
>
> CFRG has recently had some discussion about PAKEs in general. I have asked
> them to take a look at MutualAuth. This is one of the replies that we got.
>
> Yoav
>
> Begin forwarded message:
>
> From: Watson Ladd <[email-masked]>
> Subject: Re: [Cfrg] Another PAKE question
> Date: January 9, 2014 4:57:19 PM GMT+02:00
> To: Yoav Nir <[email-masked]>
>
> Why is this protocol secure?
> I would recommend taking the z, and computing a hash of z and the
> transcript of the protocol. In
> this way under the ROM, the computed value doesn't reveal information.
> It ensures that any
> manipulation of the messages leads to different z values.
>
> I'll try to think of ways to make a proof given that change.
> Sincerely,
> Watson Ladd
>
>
> On Wed, Jan 8, 2014 at 10:09 PM, Yoav Nir <[email-masked]> 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.
>
> 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]
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/cfrg
>
>
>
>
> --
> "Those who would give up Essential Liberty to purchase a little
> Temporary Safety deserve neither  Liberty nor Safety."
> -- Benjamin Franklin
>
>
> Email secured by Check Point
>
>
>
> _______________________________________________
> http-auth mailing list
> [email-masked]
> 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: <[email-masked]>, <[email-masked]>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]

---

From: Yutaka OIWA <[email-masked]>
Date: Fri, 7 Mar 2014 13:56:42 +0900

Dear Watson and all,

I received a private communication from internal colleagues
and would like to update my description.

What Watson has mentioned seems to be the one in
Section 11.2 of the main draft
<http://tools.ietf.org/html/draft-ietf-httpauth-mutual-01#section-11.2>.
VK_c and VK_s contain the log of the transactions
K_c1 and K_s1 into the calculation.
These values were already included in the original
cryptographic primitives, and is treated as a
"common" structure among primitives in the drafts
(that's why it is in the main draft, instead of the algo draft).

# Do you think we need more to be embedded, such as
# session IDs into consideration?

I think this makes a correct answer to the question, and
I'd like to update the specs so that it becomes more
clearer to the readers in the cryptographic community and
future designers of additional algorithms.
Thank you very much again for informative comments.