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

Dear Rifaat,

On 2015/07/20 21:09, Rifaat Shekh-Yusef wrote:
> Hi Yutaka,
> 
> Thanks for your comments.
> Please, see my reply inline...
> 
> Regards,
>  Rifaat
> 
> 
> On Mon, Jul 20, 2015 at 10:53 AM, Yutaka OIWA <y.oiwa@aist.go.jp> wrote:
> 
>> 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.
>>
>>
> 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"?

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

>> 2. The final response for the successful authentication should use
>>    Authentication-Info header instead of WWW-Authenticate, whose
>>    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.
I understand it.

>>    It's also better that the normal response codes (200 or 401) is
>>    shown in the exchange examples for easier understanding.
>>
>>
> Agree.
> 
> 
> 
> 
>> 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.
>>
>>
> 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.

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

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.

> Regards,
>  Rifaat
> 
> 
>>
>> 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.               Planning Officer, Research Planning Office
>>                      Department of Information Technology and Human Factors
>>     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.               Planning Officer, Research Planning Office
                     Department of Information Technology and Human Factors
    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]