Yes, changing the language to be consistent with Section 4.4 would be good. I would also remove the reference to RFC 4962 Section 3, and substitute one to RFC 4017 instead (since channel bindings are explicitly discussed there and indicated as optional).
From: Hao Zhou (hzhou) [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 09, 2008 8:11 AM To: Bernard Aboba; emu@ietf.org Subject: RE: [Emu] Requirements for Channel Binding in the Tunnel Method Requirements document Bernard: Section 4.4 lists the requirement for channel binding as "The tunnel method MUST be capable of supporting EAP channel bindings described above.". I think this is the intent of the requirement. Section 4.1.1 language of "MUST support" might be too strong. Are you ok with changing Section 4.1.1 to be consistent with Section 4.4? I think this will allow WG to work on channel binding separately and if deemed important, not requiring us to modify the tunnel method. _____ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bernard Aboba Sent: Thursday, June 26, 2008 3:50 AM To: emu@ietf.org Subject: [Emu] Requirements for Channel Binding in the Tunnel Method Requirements document Section 4.1.1 of the Tunnel Method Requirements document includes the following statement: In addition, the tunnel method MUST support EAP channel bindings to enable a system based on EAP to meet the additional requirements in Section 3 of RFC 4962. While I have no problem with including support for channel bindings within the EMU tunnel method, I do not believe that any requirement for EAP Channel Bindings can be inferred from Section 3 of RFC 4962. Here is what Section 3 says: The context will include the peer and NAS identities in more than one form. One (or more) name form is needed to identify these parties in the authentication exchange and the AAA protocol. Another name form may be needed to identify these parties within the lower layer that will employ the session key. Notice that neither this paragraph nor the ones surrounding it mention exported EAP keying material specifically. This omission was intentional -- the intent was to enable the requirement to be met by subsequent cryptographic binding operations operating within lower layers. As an example, IEEE 802.11r's PMK-R0 and PMK-R1 cryptographically bind the PMK/MSK to channel properties, satisfying this requirement. Part of the reason that EAP channel bindings were not mandatory to implement is that they were (and remain) undeployed, so that their practicality remains unproven. For this reason, despite considerable IESG pressure, RFC 4017 included EAP channel bindings only as an optional feature within Section 2.4, rather than promoting it to required or even recommended to implement. Between the publication of RFC 4017 and 4962, many aspects of EAP, including new methods, RFC 3748 implementations, etc. moved ahead, but progress in the channel binding area remained slow, so that the case for requiring EAP channel binding did not grow stronger. As proof that EAP channel binding is NOT required by RFC 4962 Section 3, RFC 5247 which was chartered to demonstrate how RFC 4962 requirements can met by EAP/Secure Association/AAA systems does not mention EAP channel bindings at all in Section 5.4, which discussed how the RFC 4962 key binding requirements from Section 3 can be met. Rather, RFC 5247 Section 2.3 which discussed authenticator identification, mentions both EAP channel binding and lower layer bindings in points (f) through (k), albeit without normative language. Given the extensive discussion of RFC 4017 and 4962 on the IETF mailing list and various other mailing lists, including the EAP WG list, it is therefore somewhat disappointing to see something which could only garner IETF consensus as an optional capability promoted to mandatory, purely due to IESG re-interpretation of a BCP after publication. Given that the EMU WG has as a work item for development of an Internet Draft on EAP channel binding, my advice is for the WG, through its analysis of the problem and the potential solutions, to develop its own consensus as to the value and practicality of channel bindings, rather than allowing an opinion to be imposed upon it from the IESG. As a first step toward that, a concise statement of the problem is very important. Section 4.4 of the Tunnel Method Requirements document includes the following statement of the Channel Binding problem: The so-called "lying NAS" problem is a well-documented problem with the current Extensible Authentication Protocol (EAP) architecture [RFC3748] when used with pass-through authenticators. Here, a Network Access Server (NAS), or pass-through authenticator, may authenticate to the backend AAA infrastructure using one set of credentials, while representing contrary information to EAP peers. The issue is not just whether the information presented to the peer and server are contradictory, but also whether the information is correct. To make this clear, RFC 5247 Section 5.3.3 included additional text beyond what was present in RFC 3748 Section 7.15: While the verification [of channel bindings] can be done either by the peer or the server, typically only the server has the knowledge to determine the correctness of the values, as opposed to merely verifying their equality. The use of the term "credentials" in the short problem description is somewhat odd, since in AAA protocols, the credentials used for mutual authentication between the AAA client and server do not relate to channel binding parameters such as the NAS-Identifier. For example, a AAA client can use a certificate containing a subjectAltName field of "aaaclient.example.com" to authenticate to the AAA server, whereas the enclosed NAS-Identifier attribute could contain a the R0KH-ID from IEEE 802.11r. Such an Access-Request would be completely valid, and RFC 5247 Section 2.5 notes some of the issues that can arise: It is possible for problems to arise in situations where the EAP server identifies itself differently to the EAP peer and authenticator. For example, it is possible that the Server-Id exported by EAP methods will not be identical to the Fully Qualified Domain Name (FQDN) of the backend authentication server. Where certificate-based authentication is used within RADIUS or Diameter, it is possible that the subjectAltName used in the backend authentication server certificate will not be identical to the Server-Id or backend authentication server FQDN. This is not normally an issue in EAP, as the authenticator will be unaware of the identities used between the EAP peer and server. However, this can be an issue for key caching, if the authenticator is expected to locate a backend authentication server corresponding to a Server-Id provided by an EAP peer. Where the backend authentication server FQDN differs from the subjectAltName in the backend authentication server certificate, it is possible that the AAA client will not be able to determine whether it is talking to the correct backend authentication server. Where the Server-Id and backend server FQDN differ, it is possible that the combination of the key scope (Peer-Id(s), Server- Id(s)) and EAP conversation identifier (Session-Id) will not be sufficient to determine where the key resides. For example, the authenticator can identify backend servers by their IP address (as occurs in RADIUS), or using a Fully Qualified Domain Name (as in Diameter). If the Server-Id does not correspond to the IP address or FQDN of a known backend authentication server, then it may not be possible to locate which backend authentication server possesses the key.
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
