Subject: Re: [Emu] Tunnel Method (Current WG Work item status)

From: Alan DeKok <[email-masked]>
Date: Sun, 19 Oct 2008 20:52:08 +0200

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-req-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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu
> 
> 

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

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Thu, 30 Oct 2008 20:09:35 -0700

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-masked] [mailto:[email-masked]] On 
> Behalf Of Alan DeKok
> Sent: Sunday, October 19, 2008 11:52 AM
> To: [email-masked]
> 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.
> 
>   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:
> > - 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:
> >