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

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"?

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

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

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

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