Mutual Authentication Protocol for HTTP: Cryptographic Algorithms Based on the Key Agreement Mechanism 3 (KAM3)
draft-ietf-httpauth-mutual-algo-07

Received changes through RFC Editor sync (created alias RFC 8121, changed title to 'Mutual Authentication Protocol for HTTP: Cryptographic Algorithms Based on the Key Agreement Mechanism 3 (KAM3)', changed abstract to 'This document specifies cryptographic algorithms for use with the Mutual user authentication method for the Hypertext Transfer Protocol (HTTP).', changed pages to 17, changed standardization level to Experimental, changed state to RFC, added RFC published event at 2017-04-11, changed IESG state to RFC Published)

[Ballot comment]
I agree with Mirja that the IPR section in this draft seems misplaced, and applies more to the mutual-auth mechanism draft. If it needs to stay in this draft, please see my comment about the similar section in the mutual-auth draft.

[Ballot comment]
Some editorial comments from our OPS-DIR reviewer, Qin Wu.

This document defines four HTTP Mutual authentication algorithms which use with Mutual authentication protocol for HTTP, two for Discrete Logarithm settings, two for elliptic curve settings. In addition, the security of this algorithm is well analyzed.

There is no major issue. I believe this document is ready for publication. Here are a few editorial comments I like to ask authors to consider:

Minor issues:

1.      Section 1.1 said:

“

When a natural

  number output is required, the notation INT(H(s)) is used.



”

I will see INT(H(s)) as a formula to convert H(s) into natural number

2.      Section 2, 1st paragraph:

What is DL-based notations? Can you expand DL? Is it Description Logic or something else?

You can consider to add acronym and abbreviation section.

3.Section 2, 2nd paragraph and the figure that describe protocol exchange for four value

Where you define the first two messages in this draft? Are you referred to the first messages that contain ID, K_c1 and K_s1 respectively in the figure? I don’t see you specify message format or give a message name? I don’t see you related text with the message shown in the figure?



In addition, where the last two message defined in [I-D.ietf-httpauth-mutual]? Can you provide section number?

By reading [[I-D.ietf-httpauth-mutual], I see K_c1, K_s1, VK_c,VK_s has already been defined in [[I-D.ietf-httpauth-mutual], I feel confused and am wondering if this draft really defines the first two messages? Or four message shown in the figure are all defined in the [[I-D.ietf-httpauth-mutual].



4.Section 3.1, 3rd paragraph said:

“

The functions named octet(), OCTETS(), and INT() are those defined in

the core specification [I-D.ietf-httpauth-mutual].

“

Is the core specification [I-D.ietf-httpauth-mutual]the core document mentioned in section 3? If yes, please make them consistent.



5.Section 3.3, symbol “G”

g: for "the generator" associated with the group.

How the symobol “G” is different from symbol “g”in the section 3.2? Does G stand for the generator associated with the defined group? What do you mean “the defined point”? Would be great to clarify the difference between G and g.



6.Section 5.2 said:

“

In the EC setting, r has to be

prime.  Defining a variation of this algorithm using a different

domain parameter SHOULD be attentive to these conditions.

“

What is EC setting? Please expand EC? Elliptic Curve? Please make this clear or add this abbreviation into abbreviation section.



Nites:

1.Section 1,1st paragraph

s/ use withMutual authentication protocol/ use with Mutual authentication protocol

2.Section 5.2

s/ mixing values from from two/ mixing values from two



-Qin

[Ballot comment]
In relation to Alvaro's comment on draft-ietf-httpauth-mutual, the first part of the Intellectual Properties Notice does not seem to apply here and the note is probably not needed at all.

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-httpauth-mutual-algo-06.txt. If any part of this review is inaccurate, please let us know.

Upon approval of this document, we understand that there is a single registry action to complete.

We understand that some of the actions requested in the IANA Considerations section of this document are dependent upon the approval of and completion of IANA Actions in another document:

https://tools.ietf.org/html/draft-ietf-httpauth-mutual-09

In that document a HTTP authentication algorithms registry is to be created.

In the current document, upon approval of draft-ietf-httpauth-mutual, four new tokens will be added to the new registry as follows:

+-------------------------+-------------------------+---------------+
| Token | Description | Reference |
+-------------------------+-------------------------+---------------+
| iso-kam3-dl-2048-sha256 | ISO-11770-4 KAM3, | [ RFC-to-be ] |
| | 2048-bit DL | |
| iso-kam3-dl-4096-sha512 | ISO-11770-4 KAM3, | [ RFC-to-be ] |
| | 4096-bit DL | |
| iso-kam3-ec-p256-sha256 | ISO-11770-4 KAM3, | [ RFC-to-be ] |
| | 256-bit EC | |
| iso-kam3-ec-p521-sha512 | ISO-11770-4 KAM3, | [ RFC-to-be ] |
| | 521-bit EC | |
+-------------------------+-------------------------+---------------+

We understand that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: "Yoav Nir" , ynir.ietf@gmail.com, httpauth-chairs@ietf.org, Kathleen.Moriarty.ietf@gmail.com, http-auth@ietf.org, draft-ietf-httpauth-mutual-algo@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Mutual Authentication Protocol for HTTP: KAM3-based Cryptographic Algorithms) to Experimental RFC


The IESG has received a request from the Hypertext Transfer Protocol
Authentication WG (httpauth) to consider the following document:
- 'Mutual Authentication Protocol for HTTP: KAM3-based Cryptographic
  Algorithms'
  as Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-10-25. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document specifies cryptographic algorithms for use with the
  Mutual user authentication method for the Hyper-text Transport
  Protocol (HTTP).




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-httpauth-mutual-algo/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-httpauth-mutual-algo/ballot/


No IPR declarations have been submitted directly on this I-D.

Authors are Yutaka Oiwa, Hajime Watanabe, Hiromitsu Takagi, Kaoru Maeda,
Tatsuya Hayashi and Yuichi Ioku. Kathleen Moriarty is the responsible
Area Director. Yoav Nir is the document shepherd.

Summary
  This document specifies cryptographic algorithms for use with the
  Mutual user authentication method for the Hyper-text Transport
  Protocol (HTTP).
 
Review and Consensus
  This document is one in a three-part set of documents describing the
  Mutual-Auth authentication method for HTTP. This part describes the
  cryptographic algorithms for use with MutualAuth. The algorithms are
  based on Augmented Password-based Authenticated Key Exchange
  (Augmented PAKE) techniques.

  With version -05 it is the consensus of the HTTP-Auth working group
  that this document is fit to be published as an experimental RFC.
  The document received a moderate amount of review from the working
  group. In addition we solicited and received a review from Melinda
  Shore.
 
  There are implementations of this protocol written by the authors.
  They take the form of a modified web server and a fork of the Firefox
  browser that include this functionality.
 
Intellectual Property
  All authors have confirmed that they are not aware of any undisclosed
  IPR associated with this document. There have been no IPR disclosures.
 
Other Issues
  None