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

Thanks Rifaat,
I'll go inline, too.

On 2015/07/20 20:53, Rifaat Shekh-Yusef wrote:
> Hi Yutaka,
> 
> Please, see my reply inline...
> 
> Regards,
>  Rifaat
> 
> 
> On Mon, Jul 20, 2015 at 10:32 AM, Yutaka OIWA <y.oiwa@aist.go.jp> wrote:
> 
>> 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?
>>
>>
> It is a general motivation to use PAKE-based solution not only for HTTP,
> but also for other protocols, e.g. SIP.

Understood.

>> 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.
>>
> 
> 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.

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.

>> 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.
>>
>>
> 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.

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.

> Regards,
>  Rifaat
> 
> 
> 
>> 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: <internet-drafts@ietf.org>
>>> 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 <rifaat.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:           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
>>> http-auth@ietf.org
>>> 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: <y.oiwa@aist.go.jp>, <yutaka@oiwa.jp
>>>
>> OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405
>> 46B5]
>>
> 

-- 
Yutaka OIWA, Ph.D.               Cyber Physical Architecture Research Group
                                  Information Technology Research Institute
    National Institute of Advanced Industrial Science and Technology (AIST)
                      Mail addresses: <y.oiwa@aist.go.jp>, <yutaka@oiwa.jp>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]