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

From: Alan DeKok <[email-masked]>
Date: Thu, 05 Jun 2008 15:45:49 +0200

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

---

From: "Josh Howlett" <[email-masked]>
Date: Thu, 5 Jun 2008 16:08:23 +0100

>   A separate call for consensus will be issued for this document.

RFC3748 (section 2.1) states:

   However, the peer
   and authenticator MUST utilize only one authentication method (Type 4
   or greater) within an EAP conversation, after which the authenticator
   MUST send a Success or Failure packet.

Am I correct in understanding that section 3.3 ('Chained EAP Methods')
is not a violation of RFC3748 because it only applies to methods run
*within* the tunnel method itself, and not to other methods that might
precede or follow the tunnel method? In other words, this is not an
attempt to change the behaviour stipulated in RFC3748?

>From the same section:

   However,
   chained EAP methods from different conversations can be re-directed
   into the same conversation by an attacker giving the authenticator
   the impression...

At the risk of appearing pedantic, would it be more accurate to say 'EAP
server' rather than 'authenticator'?

josh.

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG

---

From: Alan DeKok <[email-masked]>
Date: Thu, 05 Jun 2008 17:23:59 +0200

> attempt to change the behaviour stipulated in RFC3748?

  That would be my understanding.  Section 2.1 of RFC 3748 also says:

   Multiple authentication methods within an EAP conversation are not
   supported due to their vulnerability to man-in-the-middle attacks
   (see Section 7.4) and incompatibility with existing implementations.

  And Section 7.4 says:

   As noted in Section 2.1, EAP does not permit untunneled sequences of
   authentication methods.

  Due to MITM attacks, which may be mitigated by:

   [b] Requiring cryptographic binding between the EAP tunneling
       protocol and the tunneled EAP methods.

  Hence the current WG work items on cryptographic binding.

  Alan DeKok.

---

From: "Hao Zhou (hzhou)" <[email-masked]>
Date: Thu, 5 Jun 2008 13:18:19 -0400

Alan:

I don't think we have a cryptographic binding WG work item, but a
channel binding one. However, the crypto-binding requirement is captured
in the Tunnel method requirement draft, as it is required to run a
single tunneled EAP method or chained ones.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Alan DeKok
> Sent: Thursday, June 05, 2008 11:24 AM
> To: Josh Howlett
> Cc: [email-masked]
> Subject: Re: [Emu] Tunnel Method (Current WG Work item status)
> 
> Josh Howlett wrote:

---

From: Alan DeKok <[email-masked]>
Date: Fri, 06 Jun 2008 12:09:22 +0200

> single tunneled EAP method or chained ones.

  Sorry, my mistake.

  Alan DeKok.