Subject: [Emu] Re: Thoughts on Password-based EAP Methods

From: Pascal Urien <[email-masked]>
Date: Fri, 13 Apr 2007 22:46:08 +0200

Hi Everybody,

The emu working agreed on the fact that a secure channel is needed

  Item1.

    - a)  Is there a consensus for TTLS (what version ?)
    - b) Is this possible to push   TTLS as an RFC (from an IT point of view)

  Item2
  -c) Do we need a new password based method ?
       I agree with Bernard point of view. Many methods already exist.

My personal feeling  is
a=yes, b=yes, c=no

I am ready to organize a meeting  in Paris in June, if the working 
group intends to debate about these points

Best Regards

Pascal

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

---

From: Badra <[email-masked]>
Date: Fri, 13 Apr 2007 23:08:18 +0200

Since Nancy comments are reasonable and that EAP-FAST is designed in a nice
fashion, I think it is good to add it as option d)

Best regards,
Badra

---

From: "Hao Zhou \(hzhou\)" <[email-masked]>
Date: Fri, 13 Apr 2007 17:12:31 -0400

While I agree that we probably don't need another password based method,
I firmly believe that we need a standard base method provides more
extensibility beyond password based authentication, for instance,
channel binding, exchange protected data, crypto-agility, etc. Past
experience tells me that if we don't define a standard one to address
this, someone will come up with proprietary solution and we will end up
with multiple methods again. TTLS, PEAP, EAP-FAST are early attempts. We
will keep making the same mistakes.

That's why I think addressing password authentication should not be the
only goal, but addressing the standard extension points might be the
more important goal here. Addressing password authentication should be
trivial, as we already have working protocol. Just like TLS is being
used as a framework, I like to have a standard EAP tunnel method that is
extensible, extensible on the tunnel establishment as well as inside the
tunnel. Since the extension points are standardized and extensions need
to go thru IETF process and publishing, this will ensure better
interoperability.  That's why I think we need to take a look at both the
password based method and enhanced TLS based method requirements
together, and maybe with some requirements outside the current WG
charter, and come up with a standard tunneling method that's extensible.

As far as the basis for such method,  I don't think we have consensus
towards TTLS. We need to judge them base on the requirements and each
candidate's merits.

> -----Original Message-----
> From: Pascal Urien [mailto:[email-masked]] 
> Sent: Friday, April 13, 2007 4:46 PM
> To: [email-masked]
> Subject: [Emu] Re: Thoughts on Password-based EAP Methods
> 
> Hi Everybody,
> 
> I am ready to organize a meeting  in Paris in June, if the 
> working group intends to debate about these points
> 
> Best Regards
> 
> Pascal
> 
> 
> 
> 
> 
> 
>   
> 
> 
>

---

From: Ryan Hurst <[email-masked]>
Date: Fri, 13 Apr 2007 15:09:51 -0700

I agree that if there is not a standards based approach to choose
proprietary solutions will be implemented, I also agree that addressing
the password based authentication is not the only problem here.

I also think there is need for a standards based tunneled EAP method
also.

I for one support the standardization of a TTLS that addresses channel
binding, crypto binding, etc.

Ryan

---

From: "Bernard Aboba" <[email-masked]>
Date: Sat, 14 Apr 2007 12:30:32 -0700

>I am ready to organize a meeting  in Paris in June, if the  working group 
>intends to debate about >these points

Paris in June (or any time, really) sounds wonderful.  However, if the idea 
is to focus people on work, without the distractions created by art, music, 
good food and inspiring architecture, then other places (such as a Motel 6 
in Newark, New Jersey) may work better :)

---

From: "Clint Chaplin" <[email-masked]>
Date: Sat, 14 Apr 2007 12:34:54 -0700

Right, and make sure there is >no< internet access.  It's amazing how
much work can get done when none of the participants have their head
buried in a laptop answering email.

Of course, there are some people who you don't want to be engaged in
the discussion...

-- 
Clint (JOATMON) Chaplin
Principal Engineer
Corporate Standardization (US)
SISA

---

From: "Bernard Aboba" <[email-masked]>
Date: Sat, 14 Apr 2007 12:53:47 -0700

>       I agree with Bernard point of view. Many methods already exist.

I agree with this.

With respect to a) there is realy only one deployed version of EAP-TTLS, 
namely EAP-TTLSv0.  EAP-TTLSv1 has not been implemented.  So that is 
probably the place to start.

With respect to b), a fothcoming version of the EAP-TTLSv0 specification 
will be submitted for publication as an RFC.  This will address questions 
from implementers and address the need for a stable reference from WiMAX 
Forum, OMA, TNC and other organizations that are incorporating EAP-TTLSv0 
into their standards.

With respect to c), one needs to take several factors into account, such as 
the certification/testing situation, availability of reference 
implementations and IPR declarations.  EAP-TTLSv0 is currently being tested 
for interoperability by WFA so that a certification program is already in 
place.  As far as I could tell, there is only one IPR declaration relating 
to EAP-TTLS, and that relates to EAP-TTLSv1, rather than EAP-TTLSv0:
https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=594

Compare this with the IPR Declarations relating to EAP FAST:
http://www.ietf.org/ietf/IPR/cisco-ipr-draft-cam-winget-eap-fast.txt
http://www.ietf.org/ietf/IPR/cisco-ipr-draft-cam-winget-eap-fast-provisioning-03.txt
http://www.ietf.org/ietf/IPR/cisco-ipr-draft-salowey-tls-ticket.txt
https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=595
http://www1.ietf.org/ietf/IPR/microsoft-ipr-draft-cam-winget-eap-fast.txt

---

From: "Hao Zhou \(hzhou\)" <[email-masked]>
Date: Tue, 17 Apr 2007 12:06:27 -0400

Bernard:

With regard to the IPR issue on TTLS and EAP-FAST, I believe they share
the common declaration related to a Nokia Patent. As far as I can tell,
it is somewhat related to crypto-binding. Although it is only put on
TTLSv1 (as TTLSv0 doesn't address crypto-binding), I believe that if we
need to address crypto-binding in the standard RFC, we will face the
same IPR.

As for rest of the IPR declarations on EAP-FAST, they are all related to
the use of TLS ticket and provisioning of additional credentials. They
may not end up in or be optional features in the standard RFC method. If
we bring these features in to the standard RFC method, we will be likely
facing the same IPRs, regardless which draft method to base on.

Last, IPR doesn't necessary prevent protocol becomes standard. There is
plenty example of protocols with Cisco IPR in the standard track. 

> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Saturday, April 14, 2007 3:54 PM
> To: [email-masked]; [email-masked]
> >    - b) Is this possible to push  TTLS as an RFC (from an 
> IT point of
> >view)
> >
> >  Item2
> With respect to a) there is realy only one deployed version 
> of EAP-TTLS, namely EAP-TTLSv0.  EAP-TTLSv1 has not been 
> implemented.  So that is probably the place to start.
> 
> With respect to b), a fothcoming version of the EAP-TTLSv0 
> specification will be submitted for publication as an RFC.  
> This will address questions from implementers and address the 
> need for a stable reference from WiMAX Forum, OMA, TNC and 
> other organizations that are incorporating EAP-TTLSv0 into 
> their standards.
> 
> With respect to c), one needs to take several factors into 
> account, such as the certification/testing situation, 
> availability of reference implementations and IPR 
> declarations.  EAP-TTLSv0 is currently being tested for 
> interoperability by WFA so that a certification program is 
> already in place.  As far as I could tell, there is only one 
> IPR declaration relating to EAP-TTLS, and that relates to 
> EAP-TTLSv1, rather than EAP-TTLSv0:

---

From: Madjid Nakhjiri <[email-masked]>
Date: Wed, 18 Apr 2007 14:34:13 -0700

I guess this explains all the motivation behind March Minnesota IETFs:)

---

From: Madjid Nakhjiri <[email-masked]>
Date: Wed, 18 Apr 2007 14:43:56 -0700

Bernard,

By "that is probably the place to start", I am assuming you mean insert all
EMU changes into an EAP-TTLSv1. What happens with the existing EAP-TTLSv1? 

Are the authors okay with us taking over and calling something different
than theirs EAP-TTLSv1?

 If yes, then I am for it. Not sure how we can get away with crypto-binding
IPR if it is a blanker IPR, I have not read the patent myself.

R,

Madjid

-----Original Message-----
From: Bernard Aboba [mailto:[email-masked]] 
Sent: Saturday, April 14, 2007 12:54 PM
To: [email-masked]; [email-masked]
Subject: RE: [Emu] Re: Thoughts on Password-based EAP Methods

I agree with this.

http://www.ietf.org/ietf/IPR/cisco-ipr-draft-cam-winget-eap-fast-provisionin
g-03.txt