Sam, Thanks for picking up this work and getting the ball rolling again.
I think the added section on the secure association protocol vs EAP methods for transporting channel binding information (Section 4.2) is very useful. In this way, implementers can decide which approach is best for them. In addition, this draft can focus on exchanging channel binding information within an EAP method and a solution utilizing the secure association protocol needs to be defined in a separate document. I guess the biggest question is now, whether this draft should specify the actual protocol messages, e.g. by adopting parts from clancy-emu-aaapay. Please find my detailed comments below. Best regards, Katrin ------------------------------------------------------------------------ ---- General Comments Revisiting the draft my main comment is regarding the protocol flow depicted in Figure 1. I think that one round trip may not be sufficient in all implementations. For example, in some cases, a server may want to inform the peer what information it should include in i1. This would be helpful for reducing the amount of data that needs to be transmitted, especially considering the size constraints imposed by the EAP method. In addition, EAP methods that do not support fragmentation may also require multiple roundtrips in order to exchange all required channel binding information. Some EAP methods support multiple rountrips for exchanging AAA attributes, some don't. This issue has already been discussed for several EAP methods in clancy-emu-aaapay. Section 4.3 What about changing the title from "Channel Bindings Architecture" to "Channel Bindings Scope"? This section discusses the different aspects of channel bindings depending on the use case rather than describing the architecture (which is described in Section 5.1). Section 5.1 Suggest changing the caption for Figure 1 from "Overview of Channel Binding" to "Overview of Channel Binding Protocol", because the figure depicts the protocols flows. TYPOS Section 3, page 7, last bullet Change "... has a roaming agreements with providers..." to "... has roaming agreements with providers..." Section 4.1, page 9, top line Change "...do not have an affect on..." to "...do not have an effect..." Section 4.2 First paragraph Delete one period at the end of the last sentence. Section 4.3, page 11, one before last paragraph. Change "Channel bindings can be important form forming pockets of trust, ..." to "Channel bindings can be important for forming pockets of trust, .." Section 10, page 20, last paragraph Change "The database may exist already exist..." to "The database may already exist". > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of Sam > Hartman > Sent: Tuesday, July 13, 2010 2:42 PM > To: [email protected] > Subject: [Emu] Updates to channel bindings document > > > > Folks, at IETF 77 I volunteered to edit the channel bindings document > and have published a new version for discussion at IETF 78. > > I'd appreciate comments on whether the changes I made to the problem > statement sections include clarity. I'd also appreciate comments on > whether the tradeoffs in the secure association protocol version of > channel bindings are accurately described. > > I've started trying to move this document towards actually being a > protocol spec. In this version, the changes are quite slight. If we > agree that we actually want something to implement from, then the next > version will have more significant updates in this regard and will > hopefully actually be something that we could start to implement from. > > I hope to have a productive discussion of these changes and future > changes for the document at IETF 78. > _______________________________________________ > Emu mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
