Subject: [http-auth] Alexey Melnikov's Discuss on draft-ietf-httpauth-mutual-10: (with DISCUSS and COMMENT)

From: "Alexey Melnikov" <[email-masked]>
Date: Thu, 03 Nov 2016 05:07:45 -0700

Alexey Melnikov has entered the following ballot position for
draft-ietf-httpauth-mutual-10: Discuss

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/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This is generally a well written document. I have a couple of important
comments that I would like to see addressed and several less significant
comments.

1) As Mirja pointed out, this spec needs need to register "Mutual" HTTP
Authentication Schemes with IANA

2) In Section 7:

   If HTTP is used on a non-encrypted channel (TCP and SCTP, for
   example), the validation type MUST be "host".  If HTTP/TLS [RFC2818]
   (HTTPS) is used with a server certificate, the validation type MUST
   be "tls-server-end-point".  If HTTP/TLS is used with an anonymous
   Diffie-Hellman key exchange, the validation type MUST be "tls-unique"
   (see the note below).

   Implementations supporting Mutual authentication over HTTPS SHOULD
   support the "tls-server-end-point" validation.  Support for
   "tls-unique" validation is OPTIONAL for both servers and clients.

I think the two paragraphs are in conflict. For example, the first one
says that if TLS with server certificate is used, then
"tls-server-end-point"
MUST be supported. But the second says that it is SHOULD be supported.

If the intent of the first paragraph is to say what should appear
syntactically,
while the second paragraph explains what kind of validation is actually
required,
I think this still can be made clearer.

I suggest you either delete the second of these 2 paragraphs, or you
need to reword text in the first (and possibly the second) to specify
a non conflicting set of requirements.

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

I agree that the Introduction section might need an editing pass.

In Section 1, next to the last paragraph:

   The Mutual authentication protocol proposed in this document is a
   strong cryptographic solution for password authentications.  It
   mainly provides the two key features:

Exactly the same paragraph appears earlier in the same section. Did you
forget to delete this instance?

3.2.  Values

   The parameter values contained in challenge/credentials MUST be
   parsed strictly conforming to the HTTP semantics (especially un-
   quoting of the string parameter values).  In this protocol, those
   values are further categorized into the following value types: tokens
   (bare-token and extensive-token), string, integer, hex-fixed-number,
   and base64-fixed-number.

   For clarity, implementations are RECOMMENDED to use the canonical
   representations specified in the following subsections for sending
   values.  Recipients SHOULD accept both quoted and unquoted
   representations interchangeably as specified in HTTP.

I think the last SHOULD must be a MUST, because clients that generate
these values
might be using libraries that automatically quote values. So this is
really not
under sender's control.

3.2.2.  Strings

   All character strings MUST be encoded to octet strings using the
   UTF-8 encoding [RFC3629] for the ISO 10646-1 character set
   [ISO.10646-1.1993].

This is the same as Unicode 1.1. Unicode now released version 9.0! I
suggest you use a Unicode reference.

In 3.2.3:

I think you are overusing SHOULDs instead of MUSTs in many
places in the document (not just just in this section). For example:

   When
   these values are generated from any cryptographic values, they SHOULD
   have their "natural length"; if these are generated from a hash
   function, these lengths SHOULD correspond to the hash size;

Why not a MUST here?

   if these
   are representing elements of a mathematical set (or group), its
   lengths SHOULD be the shortest for representing all the elements in

Again, why not a MUST? Having a unique encoding will improve
interoperability.

   the set.

   The numbers represented as base64-fixed-number SHALL be generated as
   follows: first, the number is converted to a big-endian radix-256
   binary representation as an octet string.  The length of the
   representation is determined in the same way as mentioned above.
   Then, the string is encoded using the Base 64 encoding [RFC4648]

I assume you meant Section 4 alphabet and not Section 5 alphabet from
this
RFC. Please add section reference to the above.

   without any spaces and newlines.  Implementations decoding base64-
   fixed-number SHOULD reject any input data with invalid characters,
   excess/insufficient padding, or non-canonical pad bits (See Sections
   3.1 to 3.5 of [RFC4648]).

7.1.  Applicability notes

   When the client is a Web browser with any scripting capabilities, the

Can you explain why scripting capabilities are important here?

   underlying TLS channel used with HTTP/TLS MUST provide server
   identity verification.  This means (1) anonymous Diffie-Hellman key
   exchange cipher suites MUST NOT be used, and (2) verification of the
   server certificate provided by the server MUST be performed.

In Section 9:

   In both cases, it is the sender's duty to correctly prepare the
   character strings.  If any non-normalized character string is
   received from the other peer of the communication, recipients MAY
   either use it as a bare UTF-8 string without any preparation, perform
   any appropriate preparations (which may cause authentication
   failure), or reject any ill-prepared inputs from the sender and
   respond as a communication error.

I think you are giving too many choices which might cause
interoperability issues.
Even reducing the choices from 3 to 2 would help here.

In Section 11:

      *  Otherwise, send a 200-VFY-S response.  If the session was in
         the "key exchanging" state, the session SHOULD be changed to an
         "authenticated" state.  The maximum nc and nc flags of the
         state SHOULD be updated appropriate.

Can you explain why these 2 SHOULDs are not MUSTs? I.e., what are
possible reasons for a server implementation to violate these SHOULDs?

In Section 15:

It would be good to be able to bind extension data to shared secret
constructed by
both parties.

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 7 Nov 2016 20:44:32 -0500

Hello,

I have not seen a response to this discuss (or some of the other comments),
please respond and discuss these questions and comments.  It would be good
to wrap up these last 2 drafts soon.

Thank you,
Kathleen

On Thu, Nov 3, 2016 at 8:07 AM, Alexey Melnikov <[email-masked]>
wrote:

> _______________________________________________
> http-auth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-auth
>

-- 

Best regards,
Kathleen

---

From: 大岩寛 <[email-masked]>
Date: Tue, 8 Nov 2016 08:56:38 +0000

Dear Alexey:

Thank you for really valuable comments.

> This is generally a well written document. I have a couple of important comments
> that I would like to see addressed and several less significant comments.
> 

Yes, we'll do it.

> I think the two paragraphs are in conflict. For example, the first one says
> that if TLS with server certificate is used, then "tls-server-end-point"
> If the intent of the first paragraph is to say what should appear syntactically,
> required, I think this still can be made clearer.
> 
> I suggest you either delete the second of these 2 paragraphs, or you need to
> reword text in the first (and possibly the second) to specify a non conflicting
> set of requirements.

We'll clarify it by replacing the second sentence by a text suggesting
tls-unique is not likely to be required to implement, in most cases.

Thank you for many improvement suggestions.
For so many suggestions replacing SHOULD with MUST, most of these seem
to be correct.  We'll review all of these again to make a final decision.

> This is the same as Unicode 1.1. Unicode now released version 9.0! I suggest
> you use a Unicode reference.

We'll do it.

> I assume you meant Section 4 alphabet and not Section 5 alphabet from this RFC.
> Please add section reference to the above.

Good point to clarify it's a BASE64, not a filesystem-safe variant.
Thank you.

> Can you explain why scripting capabilities are important here?

I'll add some notice about security concern here.
The second paragraph describes possible use of mutual user authentication
as a replacement for host identity verification.

> I think you are giving too many choices which might cause interoperability
> issues.

OK.  The point is that the "recipient" has freedom there:
it MAY accept and it MAY reject.

> In Section 15:
> 
> It would be good to be able to bind extension data to shared secret constructed
> by both parties.
> 

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

---

From: Yutaka OIWA <[email-masked]>
Date: Wed, 9 Nov 2016 16:18:41 +0900

Dear Kathleen,

thank you very much.
I finally looked through all the comments (as far as I noticed),
and reflected for the draft candidate texts in the following location:
https://github.com/yoiwa/httpauth-mutual/blob/master/mutual-auth-protocol.txt
https://github.com/yoiwa/httpauth-mutual/blob/master/mutual-auth-algorithms.txt

Once the IETF draft submission system is reopened on 13 Nov, I'll submit the
revised draft formally to the IETF again.

-- 
大岩 寛   Yutaka OIWA             (国研)産業技術総合研究所 情報技術研究部門
                                     サイバーフィジカルウェア研究グループ長
                                      <[email-masked]>, <[email-masked]>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]

---

From: [email-masked]
Date: Wed, 9 Nov 2016 09:52:39 -0500

Please excuse typos, sent from handheld device 

> On Nov 9, 2016, at 2:18 AM, Yutaka OIWA <[email-masked]> wrote:
> 
> Dear Kathleen,
> 
> thank you very much.

Thank you.  If you'd like to send in the draft via email and copy me, I will approve the publication so we can progress this draft and I believe close the WG.

Thank you,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 15 Nov 2016 00:07:02 -0500

Hi Alexey,

Can you take a look at the updated draft to see if your concerns are
addressed?

Thank you,
Kathleen

On Wed, Nov 9, 2016 at 9:52 AM, <[email-masked]> wrote:

> Thank you.  If you'd like to send in the draft via email and copy me, I
> will approve the publication so we can progress this draft and I believe
> close the WG.
>
> Thank you,
> Kathleen
>
> >
> >> On Thu, Nov 3, 2016 at 8:07 AM, Alexey Melnikov <[email-masked]
> >
> >> wrote:
> >>

-- 

Best regards,
Kathleen