Review

[bernard_aboba@…]

From Yaron Sheffer (see ​http://www.ietf.org/mail-archive/web/emu/current/msg01352.html)

IMHO this document is not ready to be advanced, at least not as Standards Track.

The document is extremely abstract: it defines the problem statement very well, but then keep its options open when describing the solution. The fact that the document has an empty IANA section is a strong hint that it is not really defining a protocol.

This can be resolved either of two ways:

• Change it to Informational, and add text to clarify that the document is *not* defining a protocol (despite the title of Sec. 5), but rather presents the problem and proposes several alternative solution strategies.

• Or extend it to really define a protocol. In which case you need to answer some simple questions like:
  • Is this taking place at the EAP level? The SAP level? Is it a new EAP method? Should it be built into each and every new EAP method?
  • How does it apply to the few existing EAP methods that can accommodate it today?
  • How are the actual TLVs represented/encoded?

BTW, just defining the TLV formats (and IANA numbers) for EAP methods would serve the community well: looking at the IANA registry for EAP-GPSK, there's a "protected payload" defined (​http://www.iana.org/assignments/eap-gpsk-parameters/eap-gpsk-parameters.xhtml#eap-gpsk-parameters-2). But nobody ever bothered defining *any* specific payloads for channel bindings.

Thanks, Yaron

[bernard_aboba@…]

Response from Katrina: ​http://www.ietf.org/mail-archive/web/emu/current/msg01376.html

Yaron,

Thank you for your comments.

The intended status of the draft is "Standards track", i.e., the draft should describe a channel binding solution and not only summarize the problem and possible solution strategies.

The original draft contained both, a channel binding protocol and a definition of containers for carrying the exchanged channel binding information. It was decided early on that for clarity reasons and more universal usage of these containers, it is better to have two separate documents to cover both topics.

This is why we have <draft-ietf-emu-chbind-04> to describe the protocol and <draft-clancy-emu-aaapay-03> to describe the containers. Recently another draft <draft-cam-winget-eap-tlv-00> has been submitted that describes EAP TLV containers.

For these reasons, I believe that such a container does *not* need to be defined in the channel binding draft. It seems to be a much better approach to use more general EAP containers that can carry channel binding as well as other data.

To answer your other comments: "Is this taking place at the EAP level?" Yes "The SAP level?" No "Is it a new EAP method?" No, it is an extension to EAP methods that can be supported by some existing EAP methods and SHOULD be supported by all new EAP methods. "Should it be built into each and every new EAP method?" Yes, at least it is a SHOULD requirement per WG consensus to support channel bindings.

"How does it apply to the few existing EAP methods that can accommodate it today?" EAP methods that already support the exchange of channel binding information can easily implement the protocol.

From your questions, it is obvious that the draft needs to do a better job to clearly answer the above questions.

Best regards, Katrin