[http-auth] Terry Manderson's No Objection on draft-ietf-httpauth-mutual-10: (with COMMENT)

"Terry Manderson" <terry.manderson@icann.org> Tue, 01 November 2016 23:57 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Terry Manderson <terry.manderson@icann.org>
To: The IESG <iesg@ietf.org>
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <147804465351.23964.4743241573285672461.idtracker@ietfa.amsl.com>
Date: Tue, 01 Nov 2016 16:57:33 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/http-auth/BKphn_h3TUbwQZ_WnlEz3ypFyNs>
Cc: http-auth@ietf.org, draft-ietf-httpauth-mutual@ietf.org, httpauth-chairs@ietf.org
Subject: [http-auth] Terry Manderson's No Objection on draft-ietf-httpauth-mutual-10: (with COMMENT)

Terry Manderson has entered the following ballot position for
draft-ietf-httpauth-mutual-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-httpauth-mutual/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for writing a very detailed document. 

A few minor comments.

1) Please review the introduction, there are several grammatical errors
in there. Meaning still came through just fine, but they were a little
distracting.

2) The state machine diagram of the client is quite complex. A candidate
for the new RFC format?

3) I agree with Alvaro's comment on the IPR. Thank you for making it
royalty free, however not sure you need to add the text in the RFC.

4) This to me seems as it is essentially a shared secret construct, one
sentence from RFC 2361 (security considerations) seems applicable here.
"All the security in this system is provided by the secrecy of the
private keying material." If this the case, please provide ample warning
that (as one would expect) loss of the password from either the client or
the server results in a complete compromise.

[http-auth] Terry Manderson's No Objection on dra… Terry Manderson
Re: [http-auth] Terry Manderson's No Objection on… 大岩寛
Re: [http-auth] Terry Manderson's No Objection on… Yutaka OIWA