Subject: Re: [http-auth] Fwd: New Version Notification for draft-yusef-httpauth-srp-scheme-00.txt

From: Yutaka OIWA <[email-masked]>
Date: Mon, 20 Jul 2015 17:32:08 +0900

Dear Rifaat,

I'm happy on seeing some interest on using strong PAKE-based
cryptography on HTTP authentication, but I also have several
questions/concerns about your current proposal.
I'll first express my general questions and suggestions,
followed by my technical reviews and suggestions in a separate email.

Could you tell us why do you think this proposal is needed?
Is there any specific request for this technology in this form, or
is it just a general motivation for PAKE to be used in HTTP?

I have been designing Mutual auth as a general framework for
augmented PAKE-based HTTP authentication, and implemented
several mechanisms to let it working effectively.
For example, the session key caching and replay-preventing
nonce-counter is a key mechanism to avoid heavy public-key
cryptographic operations in every request-response pair.

If you have no specific reasons for implementing SRP in that specific form,
I recommend to try writing it as an additional authentication algorithm
for the Mutual scheme.  It will avoid re-inventing many required wheels
for effective use of heavy PAKE mechanisms which your draft currently lacks.

# After finishing (significant portion of) my own work for Mutual auth,
# I could possibly be able to volunteer writing SRP-based auth algorithm
# for Mutual scheme, to find out whether it will work successfully or not.

Also, I have to mention that we've submitted our drafts first
to httpbis WG in 2012 as a chairs' requirement for including
it as chartered discussion candidates.  That's how the current
HTTPAUTH WG was formed with current candidates.
I'm little bit surprised to see this proposal on this time period.
If we've seen it long before, I could be working more on considering
your specific requirements merged into Mutual proposal.
# I also have asked several times for comments on the choice of
# PAKE variants for basic Mutual uses, without any strong
# suggestions for changing it from the current form.

Regards,

Yutaka

On 2015/06/01 0:53, Rifaat Shekh-Yusef wrote:
> 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: <[email-masked]>
> 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 <[email-masked]>, Yaron Sheffer <
> [email-masked]>
> 
> 
> 
> 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
> 
> 
> 
> _______________________________________________
> http-auth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-auth
> 

-- 
Yutaka OIWA, Ph.D.               Cyber Physical Architecture Research Group
                                  Information Technology Research Institute
    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: Mon, 20 Jul 2015 17:53:31 +0900

Dear HTTPAUTH WG,

the following is my technical comments for the submitted draft.

1. The authentication exchange of the HTTP should be carefully reconsidered.
   It will usually start with unauthenticated request to the server, and
   the response can contain "realm", without any specific discovery mechanisms.

2. The final response for the successful authentication should use
   Authentication-Info header instead of WWW-Authenticate, whose
   spec is under clarification by Julian.
   It's also better that the normal response codes (200 or 401) is
   shown in the exchange examples for easier understanding.

3. Please clarify explicitly how the six-message exchange can be shorten
   on what cases.
   Especially, avoiding re-computation of "public keys" is critical for
   any effective use of public-key-based cryptography (including any
   known PAKE algorithms) on stateless HTTP.
   It will require introduction of something similar to (next-)nonce
   in Digest or "sid" in Mutual and SCRAM, along with replay-preventing
   mechanisms.  It should be clarified how replay attacks can be prevented
   when public keys are reused.

4. There are distinct kinds of responses with different semantics but
   sharing the same "WWW-Authentication: SRP" header, and so kinds of
   requests sharing "Authorization: SRP".
   It should be clarified how each peer will distinguish those kinds of
   messages (e.g. existence or non-existence of client-pop field).
   It will be important for handling (or rejection)
   of malformed messages without any ambiguity (or possible cheating with it).

-- 
Yutaka OIWA, Ph.D.               Planning Officer, Research Planning Office
                     Department of Information Technology and Human Factors
    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: Rifaat Shekh-Yusef <[email-masked]>
Date: Mon, 20 Jul 2015 13:53:37 +0200

Hi Yutaka,

Please, see my reply inline...

Regards,
 Rifaat

> is it just a general motivation for PAKE to be used in HTTP?
It is a general motivation to use PAKE-based solution not only for HTTP,
but also for other protocols, e.g. SIP.

> several mechanisms to let it working effectively.

Unfortunately, I am personally not that familiar with your work.

In general, we would like to utilize the *existing *HTTP Framework and add
support for SRP on top of that.
SRP is a protocol that is already used by other RFCs and it has many
implementations out there, and is royalty free.

> cryptographic operations in every request-response pair.
I am assuming that this is related to the subsequent requests utilizing the
session keys.
We left this out of this document because we think it is out of scope.

Regards,
 Rifaat

>                       Mail addresses: <[email-masked]>, <[email-masked]
> >

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Mon, 20 Jul 2015 14:09:50 +0200

Hi Yutaka,

Thanks for your comments.
Please, see my reply inline...

Regards,
 Rifaat

>    the response can contain "realm", without any specific discovery
That is the intention; if that was not clear then we will try to clarify it.
Is the confusing part the fact that we called it "discovery"?

>    spec is under clarification by Julian.

Yes, and that is already specified in section 6.
We will fix the flow diagram in section 2; it was a copy&paste error.

>    shown in the exchange examples for easier understanding.
Agree.

>    when public keys are reused.
Is this related to subsequent requests in the context of the same session?

>    of malformed messages without any ambiguity (or possible cheating with
For this, we expect the client to send the server-public-key it received
from the server to allow the server the ability to distinguish between the
various requests.

Regards,
 Rifaat

---

From: Yutaka OIWA <[email-masked]>
Date: Mon, 20 Jul 2015 21:22:12 +0900

Thanks Rifaat,
I'll go inline, too.

> but also for other protocols, e.g. SIP.

Understood.

> implementations out there, and is royalty free.

What I'm doing is that I *do* use the existing HTTP Framework,
and add generic support for PAKE on top of that (draft-ietf-httpauth-mutual).
Then, I put some specific PAKE on top of it (draft-ietf-httpauth-mutual-algo).
Please look at my work.

> We left this out of this document because we think it is out of scope.

If your word "utilizing" means something outside of HTTP auth,
it seems to be a wrong assumption.  My assumption is simply that
one authentication will generally serve much more than
one document sequentially or in parallel.  This is true for
both Web and API-based non-Web (REST-like) accesses.
As you know, the PAKE computation is quite heavy operation
and number of it should be minimized as small as possible.
A few hundreds of milliseconds for each resource is quite
unacceptable.
It's completely within the scope of HTTP authentication design,
and is in align with the base design concept of HTTP/2.0.

I think SIP might be an exception for this assumption, but
it's quite a special case for HTTP.

And, if you think generic HTTP authentication mechanism can be
used for SIP as well, my proposal can go as well, quite easily.

---

From: Yutaka OIWA <[email-masked]>
Date: Mon, 20 Jul 2015 21:43:55 +0900

Dear Rifaat,

> Is the confusing part the fact that we called it "discovery"?

I just could not understand why there is a request with
empty "Authorization: SRP".  That can simply be omitted.

> We will fix the flow diagram in section 2; it was a copy&paste error.
I understand it.

> Is this related to subsequent requests in the context of the same session?

The term "session" is not defined in HTTP, but I think probably true.
Related to the subsequent to-be-authenticated requests for the same realm.

> from the server to allow the server the ability to distinguish between the

I guessed so. What happens if the server receives server-public-key and
username but no client-pop, for example?
Also, I found one mistake: Authentication-Info does not contain any scheme;
it is implied by the scheme in the Authorization header received from the client.