Hi Sam, Please see my comments below.
(2011/10/18 23:02), Sam Hartman wrote: >>>>>> "Yoshihiro" == Yoshihiro Ohba<[email protected]> writes: > > Yoshihiro> [1] As far as I understand, the method-based channel > Yoshihiro> binding is not applicable to ERP. For completeness of > Yoshihiro> the specification it may be good to add some text to > Yoshihiro> clarify this. > > I'd welcome suggestions. > I'm not really familiar with ERP. OK. My suggestion is to modify the following text in Section 4.2: " For many deployments, changing all the NASes is expensive and adding channel binding support to enough EAP methods to meet the goals of the deployment will be cheaper. However for deployment of new equipment, or especially deployment of a new lower layer technology, changing the NASes may be cheaper than changing EAP methods. Especially if such a deployment needed to support a large number of EAP methods, sending channel bindings in the secure association protocol might make sense. " to: " For many deployments, changing all the NASes is expensive and adding channel binding support to enough EAP methods to meet the goals of the deployment will be cheaper. However for deployment of new equipment, or especially deployment of a new lower layer technology, changing the NASes may be cheaper than changing EAP methods. Especially if such a deployment needed to support a large number of EAP methods, sending channel bindings in the secure association protocol might make sense. Sending channel bindings in the secure association protocol can work even with ERP [RFC5296] in which previously established EAP key material is used for the secure association protocol without carrying out any EAP method during re-authentication. " > > Yoshihiro> [3] Probably this was discussed in the WG, but I want to > Yoshihiro> understand the motivation for the namespace in Channel > Yoshihiro> Binding Encoding because it seems to be a hard > Yoshihiro> requirement if the peer has to know what namespace (or > Yoshihiro> protocol) is being used between an EAP authenticator and > Yoshihiro> EAP server. Also, in some case, the channel binding > Yoshihiro> operation may be performed with a standalone > Yoshihiro> authenticator since, due to EAP's mode independence > Yoshihiro> property, the peer does not know whether the > Yoshihiro> authenticator it is talking to is a pass-through > Yoshihiro> authenticator or a stand-alone one. What namespace > Yoshihiro> should be used with a standalone authenticator? > > The namespace ID simply names where the attribute comes from. If you > are describing some value that is available in a RADIUS ID, then you > should use the RADIUS namespace. The EAP server (which as you point out > may be the authenticator) is responsible for matching up that > information in whatever form it has it. > > For attributes available both in the diameter and RADIUS namespaces I'd > expect some lower layer document to describe which one to use regardless > of whether an AAA protocol is in use or which one is in use. > So it seems there is a requirement for lower-layer protocols or profiles to describe about the channel binding namespace. Shouldn't such a requirement be explicitly mentioned in this document? Yoshihiro Ohba _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
