Here is the list of revisions planned for the next revision of the tunnel method requirements document.
+ 4.5.1.2 authentication of server Issue: I don't think it is as important to protect the username as the password. Resolution: Update 4.5.1.2 as "The EAP server MUST be authenticated before the peer can send the clear text password to the server. + Peer Identity Privacy Issue: Just username is too limited, all credentials need to be protected, and arguably all attributes of a user. Suggested Resolution: In section 4.2.1.4, clarify that the information goes beyond user name to all other attributes as well. " A tunnel protocol MUST support peer privacy. This requires that the username and other attributes associated with the peer are not transmitted in the clear and, if applicable, the peer certificate is sent confidentially (i.e. encrypted)." + 4.4 EAP Channel Binding Requirements Issue: (multiple issues) This section incompletely or incorrectly describes Channel Binding Suggested resolution: have this section reference the channel binding work so we don't have to do things twice. Replace section 4.4 with: "The tunnel method MUST be capable of meeting EAP channel binding requirements described in [I-D.clancy-emu-chbind]." + Requirements Associated with Carrying Username and Passwords Issue: OTP is not a password database. Other places where password verifier should be included as well. Suggested Resolution: Modify 4.5 to read: " This section describes the requirements associated with tunneled password authentication. The password authentication mentioned here refers to user or machine authentication using a legacy password database and verifiers, such as LDAP, OTP, etc. These typically require the password in its original text form in order to authenticate the peer, hence they require the peer to send the clear text user name and password to the EAP server." Modify other sections similarly (1, 4.5.1, 4.5.4) + EAP Header Protection Issue: Mostly EAP header protection is not really necessary. The requirement should focus on what is necessary to protect. Suggested Resolution: Revise 4.2.3 to read: "4.2.3. Protection of Data External to Tunnel A tunnel method MUST provide protection of any data external to the TLS tunnel that can cause a problem if it is modified by an attacker. This may include data such as type codes and version numbers." Revise section 6.3 to: "6.3. Data External to Tunnel The tunnel method will use data that is outside the TLS tunnel such as the EAP type code or version numbers. If an attacker can compromise the protocol by modifying these values the tunnel method MUST protect this data. " + Other types of authentication mechanisms Issue: This wording excludes means of authentication that are neither based on passwords nor EAP Suggested resolution: Discuss, while it is true we can carry anything in the tunnel I think we want to limit the scope of what we initially try to accomplish. + 3.4 Id Protection Issue: The intent of this section is unclear to me. Suggested Resolution: Remove sentence "If an inner method also provides identity protection, this protection MUST extend all the way to the server that terminates that inner method." + 3.1. Password Authentication Issue: Outer method should not be concerned about password management. Suggested Resolution: Change second paragraph to read: "Since EAP authentication occurs before network access is granted the tunnel method SHOULD enable and inner exchange to provide support for minimal password management tasks including password change, "new PIN mode", and "next token mode" required by some systems." + 6.1. Cipher suite Selection Issue: section does not tie into the document Suggested resolution: Add sentence to last paragraph that says: "This document requires server authentication to mitigate the risks associated with anonymous cipher suites." + 3.7. Credential Provisioning and Enrollment Issue: this should be more of a use case to drive extensibility requirement Suggested Resolution: Move text in 3.7 into section 3.10: "3.10. Extensibility The tunnel method MUST provide extensibility so that additional types of data can be carried inside the tunnel in the future. This removes the need to develop new tunneling methods for specific purposes. One example of a application for extensibility is credential provisioning When a peer has authenticated with EAP, this is a convenient time to distribute credentials to that peer that may be used for later authentication exchanges. For example, the authentication server can provide a private key or shared key to the peer that can be used by the peer to perform rapid re-authentication or roaming. In addition there have been proposals to perform enrollment within EAP, such as [I-D.mahy-eap-enrollment]." + 4.1.1 4962 and channel bindings Issue: 4962 does not necessarily require channel bindings Suggested resolution: Remove last sentence in section + Add requirement to carry inner EAP method without modification Issue: in the past some tunnel methods have modified the inner method Suggested Resolution: add text to section 4.6 "The tunnel method MUST be able to carry inner EAP methods without modifying them." + Additional Editorial Changes > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Alan DeKok > Sent: Sunday, October 19, 2008 11:52 AM > To: emu@ietf.org > Subject: Re: [Emu] Tunnel Method (Current WG Work item status) > > IETF 73 is approaching soon, and we need to ensure that > make progress on the current WG activities. To that end, I > am repeating previous posts about WG status items. > > The document has been accepted as a WG item: > > http://www.ietf.org/internet-drafts/draft-ietf-emu-eaptunnel-r > eq-00.txt > > and reviewed: > > http://www.ietf.org/mail-archive/web/emu/current/msg00860.html > > http://www.ietf.org/mail-archive/web/emu/current/msg00911.html > > I encourage WG members to review the document prior to the > next meeting. We need to ensure that the document is ready > for last call, prior to moving ahead with other WG activies. > > Alan DeKok wrote: > > While the charter updates are being formally approved, we > can start > > discussions about the new work items. Please respond with > comments, > > queries, or feedback on the items listed below. > > > > Work item: > > > > - A mechanism to support extensible communication within a TLS > > protected tunnel. This mechanism must support channel bindings in > > order to meet RFC 4962 requirements. This mechanism will support > > meeting the requirements of an enhanced TLS mechanism, a password > > based authentication mechanism, and additional inner authentication > > mechanisms. > > > > Status: > > > > A tunnel method draft has been submitted: > > > > http://tools.ietf.org/id/draft-salowey-emu-eaptunnel-req-01.txt > > > > A separate call for consensus will be issued for this document. > > _______________________________________________ > > Emu mailing list > > Emu@ietf.org > > https://www.ietf.org/mailman/listinfo/emu > > > > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
