Subject: [http-auth] Mirja Kühlewind's No Objection on draft-ietf-httpauth-mutual-10: (with COMMENT)

From: "Mirja Kuehlewind" <[email-masked]>
Date: Tue, 01 Nov 2016 06:58:10 -0700

Mirja Kühlewind 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 this well written spec!

One important question: 
Doesn't this spec need to register a new HTTP Authentication Schemes
("Mutual") with IANA?

Further minor comments/questions:

1) Somehow I don't understand this:
"For responses, the parameters "reason", any "ks#" (where # stands
      for any decimal integer), and "vks" are mutually exclusive; any
      challenge MUST NOT contain two or more parameters among them.
      They MUST NOT contain any "kc#" or "vkc" parameters."
Who is 'they' in the last sentence?

2) "Typically, clients can ensure the above property by using a
   monotonically-increasing integer counter that counts from zero up to
   the value of nc-max."
Wouldn't it be better to use a randomized number?

3) Nit: s/Even if the request-URI does not have a port part, v will
include the default port number./Even if the request-URI does not have a
port part, vh will include the default port number./

---

From: Julian Reschke <[email-masked]>
Date: Tue, 1 Nov 2016 15:29:51 +0100

On 2016-11-01 14:58, Mirja Kuehlewind wrote:
> ...
> ...

Indeed, it has to.

Best regards, Julian

---

From: 大岩寛 <[email-masked]>
Date: Wed, 2 Nov 2016 08:55:36 +0000

Dear Mirja, thank you very much for the comments.

> Doesn't this spec need to register a new HTTP Authentication Schemes

As Julian suggested, yes.
We'll add one more clause to IANA consideration.

> Who is 'they' in the last sentence?
We'll change it to "the responses".

> Wouldn't it be better to use a randomized number?

This is by design.
Use of an almost-sequential counter makes efficient detection of
replayed challenges be possible with constant memory space.
Using random numbers, the servers must remember all used nonces
to detect replays, which requires memory space proportional to
the lifetime of the "shared key" (z in the specification).
In this algorithm, shared keys are cryptographically generated
"strong secrets", so use of sequential counters will not decrease
the security strength of the whole protocol significantly.
Replay attacks are more important to be prevented.

> 3) Nit: s/Even if the request-URI does not have a port part, v will include
> the default port number./Even if the request-URI does not have a port part,
> vh will include the default port number./

Thank you.

-- 
Yutaka OIWA, Ph.D.       Leader, 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]