Subject: [Emu] Comments on section 4 of draft-ietf-emu-chbind-00

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 19 Jan 2009 21:34:02 -0800

Section 4 defines two channel binding options

- Binding channel information into the EAP method key derivation
- Exchanging channel information between peer and authenticator for
validation

These options are not mutually exclusive.  For example a method could
exchange data that is bound into the key derivation.  This would give
the method the option of continuing if it could not fully validate the
parameters.  This is important in cases where a peer or authenticator
may not have access to certain lower layer parameters that are expected
in the derivation.  This could be due to the lack of a driver interface
or the presence of a proxy between the authenticator and EAP server.
Having the ability to signal what channel bindings are supported may be
critical for having any of the solutions work in real existing
deployments. 

Are the requirements for information in channel bindings the same across
all deployments of a method on a lower layer?

In some cases is the binding information uninteresting to the verifier.
Should the verifier have to retrieve it anyway or should it just accept
it?  

Would the exchange of parameters be useful even if the binding is done
outside of EAP?  

I think the options in channel binding are between a strict policy and a
flexible policy.  In a strict policy, channel binding verification is
done such that any variation in channel binding information will cause
failure.  In a flexible policy information is communicated between peer
and server that allows them to recover from differences in channel
binding information.  

It real deployments, given the varying state of drivers and back end
architecture, it seems that a strict policy will not be deployable.
Flexible policy adds some complexity, but it allows for the capability
for deployments to enable channel binding functionality without breaking
deployment.  The policy would be lenient to begin with to provide
information on if peers and authenticators are agreeing on the binding
information and then can be tightened down as things become consistent. 

Although this is covered in section 10.1, I think it would be good to
point out the difference in this section.  I don't really find the
difference between key derivation and exchanging parameters as useful as
the difference between the ability to implement a flexible policy vs.
enforcing a strict policy.  

Should we modify the section to focus on the differing policy approaches
and add their effect on incremental deployment?  

Thanks,

Joe
_______________________________________________
Emu mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/emu