Subject: [Emu] Updates to channel bindings document

From: Sam Hartman <[email-masked]>
Date: Tue, 13 Jul 2010 15:42:05 -0400

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.

---

From: "Hoeper Katrin-QWKN37" <[email-masked]>
Date: Tue, 20 Jul 2010 18:08:49 -0400

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-masked] [mailto:[email-masked]] On Behalf Of
Sam
> Hartman
> Sent: Tuesday, July 13, 2010 2:42 PM
> To: [email-masked]
> Subject: [Emu] Updates to channel bindings document
> 
> 
> 
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu