Subject: [Emu] Crypto-binding in TTLS-v0

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 14 Aug 2007 01:42:17 -0700

This probably has been asked before, but I will ask it in a different 
context: as we try to standardize EAP-TTLS in EMU (is this  a charter 
item, Joe?) is there a plan to support cryto-binding in TTLS-v0?

My opinion: well, yeah! :)

regards,
Lakshminath

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

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Tue, 14 Aug 2007 13:03:23 +0200

Crypto-binding: Yes (my opinion)

Sam also suggested to add channel bindings and to address internalization support in a proper way. 

Regarding your other question: No. EAP-TTLS is not a charter item since the work on password-based protocols currently does not include tunneled EAP protocols. This was discussed during the meeting. 

It was also mentioned that the fans of EAP-TTLS would like to publish their EAP-TTLSv0 as is -- without any modifications. 

Ciao
Hannes

> -----Ursprüngliche Nachricht-----
> Von: Lakshminath Dondeti [mailto:[email-masked]] 
> Gesendet: Dienstag, 14. August 2007 10:42
> An: [email-masked]
> Betreff: [Emu] Crypto-binding in TTLS-v0
>

---

From: "Stephen Hanna" <[email-masked]>
Date: Tue, 14 Aug 2007 09:53:09 -0400

Perhaps a little clarification or correction is in order here.

draft-funk-eap-ttls-v0-01.txt describes EAP-TTLSv0 as it has
been implemented by vendors and adopted by other SDOs. We plan
to submit this for RFC status as part of the ongoing effort
to document popular EAP methods as RFCs.

As I described in my presentation at EMU in Chicago, we are
working on an Internet-Draft that describes a few AVPs for
use with EAP-TTLSv0 that allow it to address all the requirements
the EMU WG has laid out for a strong password-based method.
I expect to have this Internet-Draft ready in the next week
or two.

As to your question about whether EAP-TTLSv0 is a chartered
work item for the EMU WG, that may depend in part on how the
WG decides to address the work item to deliver a strong
password-based method. At the EMU WG in Chicago, there were
two proposals: my proposal to use EAP-TTLSv0 with these
new AVPs and another proposal to define a new EAP method
especially for this purpose. The results of a hum were
inconclusive and it was agreed to take this discussion
to the email list.

If the WG decides to use EAP-TTLSv0 to address the work item
related to delivering a strong password-based method, then
I think that EAP-TTLSv0 and the new AVPs would not be work
items for the EMU WG but the work item would instead be the
creation of a profile showing how to use EAP-TTLSv0 and the
new AVPs to provide a strong password-based method.

Joe, is that consistent with your current thinking?

Thanks,

Steve

-----Original Message-----
From: Tschofenig, Hannes [mailto:[email-masked]] 
Sent: Tuesday, August 14, 2007 7:03 AM
To: Lakshminath Dondeti; [email-masked]
Subject: AW: [Emu] Crypto-binding in TTLS-v0

Ciao
Hannes

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 14 Aug 2007 07:38:31 -0700

>Sam also suggested to add channel bindings and to address internalization 

Do you mean internationalization?

If so, I'm not quite sure what this means.  RFC 4282 supports 
internationalization of the NAI.  Are we talking about internationalization 
of error messages?  For TLS-based EAP methods this will often depend on TLS 
internationalization support.

With respect to Channel Bindings, it should be understood that no proposals 
for this have ever been implemented, as far as I am aware.  So a first step 
would be for a method to choose one of the approaches to Channel Bindings 
and support it (probably as an experimental extension), and then to evaluate 
the experiment so we can understand how well (or badly) the chosen approach 
works.  At that point we might be ready to support Channel Bindings in other 
methods.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 14 Aug 2007 17:18:23 +0200

Hi Bernard,

> Do you mean internationalization?
Typo.

Yes. That's what I meant.

> internationalization of the NAI.  Are we talking about 
> internationalization of error messages?  For TLS-based EAP methods 
> this will often depend on TLS internationalization support.

Sam mentioned it in context of password based EAP methods.

>
> With respect to Channel Bindings, it should be understood that no 
> proposals for this have ever been implemented, as far as I am aware.  
> So a first step would be for a method to choose one of the approaches 
> to Channel Bindings and support it (probably as an experimental 
> extension), and then to evaluate the experiment so we can understand 
> how well (or badly) the chosen approach works.  At that point we might 
> be ready to support Channel Bindings in other methods.
>
>
Doesn't RFC 4962 mandate that channel binding has to be provided by an 
EAP method. At least it gets mentioned every time in discussions about 
new EAP methods.

The market does not seem to be excited about a number of aspects. One 
the other hand we write documents and mandate things that do not seem to 
have any chance for deployment.

Ciao
Hannes

---

From: Alan DeKok <[email-masked]>
Date: Tue, 14 Aug 2007 12:47:18 -0400

> to document popular EAP methods as RFCs.

  I think this document should be published.  It's widely used, and
deserves documentation in the IETF process.

> inconclusive and it was agreed to take this discussion

  I am in favor of EAP-TTLSv0 + new AVP's.

  Alan DeKok.

---

From: Ryan Hurst <[email-masked]>
Date: Tue, 14 Aug 2007 09:57:29 -0700

I agree, I also want to see PEAPv0 published for the same reasons (I am
working on a draft of this, no ETA I can share at this time).

-----Original Message-----
From: Alan DeKok [mailto:[email-masked]] 
Sent: Tuesday, August 14, 2007 9:47 AM
To: Stephen Hanna
Cc: [email-masked]
Subject: Re: [Emu] Crypto-binding in TTLS-v0

  Alan DeKok.

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 14 Aug 2007 10:00:27 -0700

One of the things I would like to see is the addition of crypto-binding 
(optionally and therefore does not affect others' existing 
implementations).  I am hoping that can be added as part of the 
draft-funk-eap-ttls-v0-01.txt publication process.

The other thing I would like to see is addition of IANA considerations 
on using TTLS to carry other legacy weak authentication methods.  This 
would avoid making all of those line up for EAP-MyMethod IANA registrations.

Steve, if you would like, I can volunteer cycles to write text.

Thoughts?

thanks,
Lakshminath

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Tue, 14 Aug 2007 10:15:12 -0700

gwz> I agree, no matter what the outcome of our discussions here may be.

> especially for this purpose. 
 
gwz > I thought that the new method had already been defined by a design team?
 
> The results of a hum were

gwz> Ditto.

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 14 Aug 2007 11:06:25 -0700

>Doesn't RFC 4962 mandate that channel binding has to be provided by an EAP 
>method. At least it gets mentioned every time in discussions about new EAP 
>methods.

As far as I can tell, there is no channel binding requirement in RFC 4962.  
RFC 4017 lists Channel Binding as optional.  During EAP WG review, the 
argument against recommending (or requiring) Channel Bindings was that there 
were several models for Channel Bindings, but none had been standardized; 
implementation experience was also limited (or non-existent).  So the 
argument was that we could not mandate or recommend support for something 
that unproven.

>The market does not seem to be excited about a number of aspects. One the 
>other hand we write documents and mandate things that do not seem to have 
>any chance for deployment.

It's one thing to mandate something that is doable, but which people may not 
choose to deploy.  It's another thing to mandate something which we don't 
know how to do.

A good first step might be to specify channel binding support as an optional 
feature in at least one method, and get an implementation to test.  Then at 
least we'd have some experience for further discussion.

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 14 Aug 2007 11:08:20 -0700

>   I am in favor of EAP-TTLSv0 + new AVP's.

[BA] + 1

---

From: "David B. Nelson" <[email-masked]>
Date: Tue, 14 Aug 2007 14:13:31 -0400

Glen Zorn writes...

> I thought that the new method had already been defined 
> by a design team?

As a process observation, the work product and decisions of a design team
are subject to acceptance by WG consensus.

---

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Tue, 14 Aug 2007 11:15:54 -0700

The charter item is for a password based method that supports legacy
password databases.  I do not believe Crypto-binding is strictly
required to satisfy this charter item.  

TTLS is being considered as part of the solution to this charter item,
not necessarily a as method for tunneling generic authentication
mechanisms so it is not clear if crypto-binding is required.  However,
for a protocol that tunnels arbitrary authentication mechanisms it is
highly desirable to provide crypto-binding.  

> From: Lakshminath Dondeti [mailto:[email-masked]] 
> Sent: Tuesday, August 14, 2007 1:42 AM
> To: [email-masked]
> Subject: [Emu] Crypto-binding in TTLS-v0
> 
> context: as we try to standardize EAP-TTLS in EMU (is this  a 
> charter item, Joe?) is there a plan to support cryto-binding 
> in TTLS-v0?
>

---

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Tue, 14 Aug 2007 11:18:18 -0700

Inline below: 

> From: Stephen Hanna [mailto:[email-masked]] 
> Sent: Tuesday, August 14, 2007 6:53 AM
> To: Tschofenig, Hannes; Lakshminath Dondeti; [email-masked]
> Subject: RE: [Emu] Crypto-binding in TTLS-v0
> 
> been implemented by vendors and adopted by other SDOs. We 
> plan to submit this for RFC status as part of the ongoing 
> effort to document popular EAP methods as RFCs.
> 
> use with EAP-TTLSv0 that allow it to address all the 
> requirements the EMU WG has laid out for a strong 
> password-based method.
> I expect to have this Internet-Draft ready in the next week or two.
> 
[Joe] good.

> two proposals: my proposal to use EAP-TTLSv0 with these new 
> AVPs and another proposal to define a new EAP method 
> inconclusive and it was agreed to take this discussion to the 
> email list.
> 
[Joe] Yes, there were at least two hums that need to be validated on the list.  I'll get those notes out today. 

> related to delivering a strong password-based method, then I 
> think that EAP-TTLSv0 and the new AVPs would not be work 
[Joe] Maybe, but it is possible that a profile will not meet the charter item.  Also, it seems that  the AVPs that form a protocol that solves the problems of password authentication, password change, internationalization, etc. could be considered to be within the scope of the working group charter.   

> Regarding your other question: No. EAP-TTLS is not a charter 
> item since the work on password-based protocols currently 
> does not include tunneled EAP protocols. This was discussed 
> during the meeting. 
> 
> It was also mentioned that the fans of EAP-TTLS would like to 
> publish their EAP-TTLSv0 as is -- without any modifications. 
> 
> Ciao
> Hannes
>

---

From: "Stephen Hanna" <[email-masked]>
Date: Tue, 14 Aug 2007 14:52:23 -0400

> new AVPs to provide a strong password-based method.
[Joe] Maybe, but it is possible that a profile will not meet the charter
item.  Also, it seems that  the AVPs that form a protocol that solves
the problems of password authentication, password change,
internationalization, etc. could be considered to be within the scope of
the working group charter.   

[Steve] If the WG decides it wants to adopt the draft on the
new AVPs for EAP-TTLSv0 as a WG item in order to fulfill the
WG charter, that's fine with me.

Thanks,

Steve

---

From: "Stephen Hanna" <[email-masked]>
Date: Tue, 14 Aug 2007 14:53:12 -0400

>   I am in favor of EAP-TTLSv0 + new AVP's.

[SH] + 1

---

From: "Nancy Winget \(ncamwing\)" <[email-masked]>
Date: Tue, 14 Aug 2007 16:29:25 -0700

Publishing TTLS and PEAPv0 (and PEAPv1) is a worthy cause given that
there are deployments out there.  However, I think that is a different
item/issue than having it be taken as an EMU work item.  For instance,
it can be published as an informational RFC much the same way EAP-FAST
is now RFC 4851.

It is not clear why TTLS should become an EMU work item or standardized
as the means to deliver a strong password based method.  There are other
tunnel methods such as PEAP and EAP-FAST that can also meet the
requirements.  If we are discussing what would need to be
changed/updated to TTLS to meet the requirements, perhaps we should also
be evaluating PEAP and EAP-FAST as alternatives as they also meet the
requirements and perhaps more so than TTLS.

	Nancy.

-----Original Message-----
From: Alan DeKok [mailto:[email-masked]]
Sent: Tuesday, August 14, 2007 9:47 AM
To: Stephen Hanna
Cc: [email-masked]
Subject: Re: [Emu] Crypto-binding in TTLS-v0

Stephen Hanna wrote:
> draft-funk-eap-ttls-v0-01.txt describes EAP-TTLSv0 as it has been 
> implemented by vendors and adopted by other SDOs. We plan to submit 
> this for RFC status as part of the ongoing effort to document popular 
> EAP methods as RFCs.

> As to your question about whether EAP-TTLSv0 is a chartered work item 
> for the EMU WG, that may depend in part on how the WG decides to 
> address the work item to deliver a strong password-based method. At 
> the EMU WG in Chicago, there were two proposals: my proposal to use 
> EAP-TTLSv0 with these new AVPs and another proposal to define a new 
> EAP method especially for this purpose. The results of a hum were 
> inconclusive and it was agreed to take this discussion to the email 
> list.

  Alan DeKok.

---

From: Ryan Hurst <[email-masked]>
Date: Tue, 14 Aug 2007 16:44:38 -0700

I agree that PEAPv0 is a orthogonal issue Nancy, did not mean to suggest
it was although in hindsight I can see how it might have read that way.

On the topic of TTLS as a EMU working group item, I am not opposed to
this as from the customer engagements I have had it appears to have a
very strong existing deployment across a number of customer segments and
from a protocol standpoint is pretty clean (It just needs a couple of
additions like CryptoBindings).

Ryan
-----Original Message-----
From: Nancy Winget (ncamwing) [mailto:[email-masked]] 
Sent: Tuesday, August 14, 2007 4:29 PM
To: Ryan Hurst; Alan DeKok; Stephen Hanna
Cc: [email-masked]
Subject: RE: [Emu] Crypto-binding in TTLS-v0

	Nancy.

-----Original Message-----
From: Alan DeKok [mailto:[email-masked]]
Sent: Tuesday, August 14, 2007 9:47 AM
To: Stephen Hanna
Cc: [email-masked]
Subject: Re: [Emu] Crypto-binding in TTLS-v0

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 14 Aug 2007 22:44:50 -0400

> it can be published as an informational RFC much the same way EAP-FAST

  I would prefer at least that.

> requirements.

  TTLS has a much more flexible structure for in-tunnel transport than
PEAP does.  TTLS is also widely deployed than EAP-FAST.

>  If we are discussing what would need to be

  I believe that the evaluation is ongoing on this list.

  Alan DeKok.

---

From: "Nancy Winget \(ncamwing\)" <[email-masked]>
Date: Wed, 15 Aug 2007 21:46:26 -0700

Hi Ryan,

Well, I thought presenting tunneled methods were in general out of scope
for the password based authentication.  But it is a viable means to
meeting the requirements.....which I believe, is what the design team
presented with PP-EAP.

My point is that if we contemplate TTLS as a working group item, we
should also be analyzing PEAP and EAP-FAST.  Though PEAP may not have as
much traction, I believe though EAP-FAST was instantiated after TTLS, is
also widely deployed and addresses some of the deployment challenges
(like crypto binding and the ability to establish tunnels without the
need of asymmetric crypto) that were presented by PEAP and TTLS.

	Nancy.

-----Original Message-----
From: Ryan Hurst [mailto:[email-masked]] 
Sent: Tuesday, August 14, 2007 4:45 PM
To: Nancy Winget (ncamwing); Alan DeKok; Stephen Hanna
Cc: [email-masked]
Subject: RE: [Emu] Crypto-binding in TTLS-v0

Ryan
-----Original Message-----
From: Nancy Winget (ncamwing) [mailto:[email-masked]]
Sent: Tuesday, August 14, 2007 4:29 PM
To: Ryan Hurst; Alan DeKok; Stephen Hanna
Cc: [email-masked]
Subject: RE: [Emu] Crypto-binding in TTLS-v0

	Nancy.

-----Original Message-----
From: Alan DeKok [mailto:[email-masked]]
Sent: Tuesday, August 14, 2007 9:47 AM
To: Stephen Hanna
Cc: [email-masked]
Subject: Re: [Emu] Crypto-binding in TTLS-v0

  Alan DeKok.

---

From: "Nancy Winget \(ncamwing\)" <[email-masked]>
Date: Wed, 15 Aug 2007 21:46:26 -0700

Hi Ryan,

	Nancy.

-----Original Message-----
From: Ryan Hurst [mailto:[email-masked]] 
Sent: Tuesday, August 14, 2007 4:45 PM
To: Nancy Winget (ncamwing); Alan DeKok; Stephen Hanna
Cc: [email-masked]
Subject: RE: [Emu] Crypto-binding in TTLS-v0

Ryan
-----Original Message-----
From: Nancy Winget (ncamwing) [mailto:[email-masked]]
Sent: Tuesday, August 14, 2007 4:29 PM
To: Ryan Hurst; Alan DeKok; Stephen Hanna
Cc: [email-masked]
Subject: RE: [Emu] Crypto-binding in TTLS-v0

	Nancy.

-----Original Message-----
From: Alan DeKok [mailto:[email-masked]]
Sent: Tuesday, August 14, 2007 9:47 AM
To: Stephen Hanna
Cc: [email-masked]
Subject: Re: [Emu] Crypto-binding in TTLS-v0

  Alan DeKok.

---

From: "Nancy Winget \(ncamwing\)" <[email-masked]>
Date: Wed, 15 Aug 2007 21:48:30 -0700

Thanks Alan, I am glad to see that the evaluation is continuing on the
thread.....I think both TTLS and EAP-FAST are being widely deployed and
both merit consideration.

	Nancy. 

-----Original Message-----
From: Alan DeKok [mailto:[email-masked]] 
Sent: Tuesday, August 14, 2007 7:45 PM
To: Nancy Winget (ncamwing)
Cc: Ryan Hurst; Stephen Hanna; [email-masked]
Subject: Re: [Emu] Crypto-binding in TTLS-v0

> It is not clear why TTLS should become an EMU work item or 
> standardized as the means to deliver a strong password based method.  
> There are other tunnel methods such as PEAP and EAP-FAST that can also

> meet the requirements.

>  If we are discussing what would need to be changed/updated to TTLS to

> meet the requirements, perhaps we should also be evaluating PEAP and 
> EAP-FAST as alternatives as they also meet the requirements and 
> perhaps more so than TTLS.

  Alan DeKok.

---

From: "Nancy Winget \(ncamwing\)" <[email-masked]>
Date: Wed, 15 Aug 2007 21:48:30 -0700

Nancy. 

-----Original Message-----
From: Alan DeKok [mailto:[email-masked]] 
Sent: Tuesday, August 14, 2007 7:45 PM
To: Nancy Winget (ncamwing)
Cc: Ryan Hurst; Stephen Hanna; [email-masked]
Subject: Re: [Emu] Crypto-binding in TTLS-v0

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 16 Aug 2007 08:45:52 -0400

> both merit consideration.

  I think EAP-FAST has been considered, and has little support.  I've
never seen an EAP-FAST deployment, and most people I talk to haven't
seen one, either.  Most people I talk to don't plan on supporting
EAP-FAST any time soon.

  Alan DeKok.

---

From: "Gene Chang \(genchang\)" <[email-masked]>
Date: Thu, 16 Aug 2007 10:13:29 -0400

Alan,
It is not unusual for developers to be unaware of the breath of the
EAP-FAST market adoption. It has been growing under the radar for a lot
of people since market research firms do not track market share of
different EAP methods.

Part of the misperception that EAP-FAST has no market presence has been
because no one has been drawing attention to the adoption success of
EAP-FAST. I am hoping to assemble some public data to shed a light on
the secret life of EAP-FAST.

Gene

------------------------------------------------------------------------
----
Eugene Chang (genchang)
WNBU, Technical Leader
Office:   603-559-2978
Mobile:  781-799-0233

-----Original Message-----
From: Alan DeKok [mailto:[email-masked]] 
Sent: Thursday, August 16, 2007 8:46 AM
To: Nancy Winget (ncamwing)
Cc: Ryan Hurst; [email-masked]
Subject: Re: [Emu] Crypto-binding in TTLS-v0

  Alan DeKok.

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 16 Aug 2007 16:26:49 +0200

> Steve, if you would like, I can volunteer cycles to write text.
I offered help to the authors a few month ago already and it was rejected.

Ciao
Hannes

---

From: Alan DeKok <[email-masked]>
Date: Thu, 16 Aug 2007 10:57:14 -0400

> of people since market research firms do not track market share of

  I do rather a bit more than just development.  I work with people
deploying systems from 100 to 10M+ users.  I don't see EAP-FAST being
adopted.

  I *do* hear rumors about EAP-FAST from enterprises who have bought
single source solutions.

> the secret life of EAP-FAST.

  People haven't drawn attention to the adoption success of PEAP or
TTLS, either.  Instead, people just deployed it in large numbers.

  I started hearing about PEAP and TTLS almost as soon as they were
proposed.  There was quick and immediate demand for both protocols from
a wide range of systems (small, medium, large).  I've seen nothing
similar happen with EAP-FAST (so far).

  Part of the misperception that EAP-FAST has a large market presence
has been that the people who are deploying it don't talk to the people
*not* deploying it, and vice versa.  Within the EAP-FAST camp, it looks
like there's wide-spread adoption.  Outside of it, it just doesn't come
up in any conversation.

  Alan DeKok.

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 16 Aug 2007 09:00:11 -0700

>both merit consideration.

I would agree that the EMU WG should focus on evaluation of existing, 
deployed EAP methods for the password work item.

---

From: "Gene Chang \(genchang\)" <[email-masked]>
Date: Thu, 16 Aug 2007 12:06:53 -0400

Alan,
I think we can all agree that without the help of the market analysts
measuring deployment, comparing our personal perceptions of deployment
is a bit like the five blind men and the elephant.

I had the pleasure of helping to bring TTLS into the market. The
industry conditions in 2003 was very different from 2005-2006. 2003 was
a greenfield market so adoption of a strong EAP method was instant
(especially with the then prevailing embarrassment of WEP as a
protection scheme). By the time EAP-FAST arrived, EAP-FAST had to earn
adoption on to its own merits. The adoption characteristic was naturally
different from TTLS or PEAP. 

Gene

 

-----Original Message-----
From: Alan DeKok [mailto:[email-masked]] 
Sent: Thursday, August 16, 2007 10:57 AM
To: Gene Chang (genchang)
Cc: Nancy Winget (ncamwing); Ryan Hurst; [email-masked]
Subject: Re: [Emu] Crypto-binding in TTLS-v0

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 16 Aug 2007 12:17:40 -0400

> is a bit like the five blind men and the elephant.

  I disagree.  Sufficient volumes of data make personal perception
statistically significant.  That's just what market analysts do.

> The adoption characteristic was naturally different from TTLS or PEAP. 

  The only relevant characteristic is volume of deployments.

  Alan DeKok.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 21 Aug 2007 14:09:31 -0400

As a matter of process, if EMU is going to satisfy its charter item
regarding passwords, it will need to refer to a standards-track EAP
type of some kind.  The existing process for getting EAP methods
published as RFCs does not result in standards track RFCs.

So, if EMU is going to base its work on something existing, it is
probably important for EMU to take on the entire method.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 22 Aug 2007 06:38:27 +0200

> probably important for EMU to take on the entire method.

  If consensus is to use EAP-TTLS, then I would suggest publishing the
base EAP-TTLS document pretty much as-is as a standards-track document.
   The additional EMU requirements can be addressed in a separate document.

  This process lets us get something done quickly.  I would prefer to
void spending years talking about a new EAP method, followed by years of
trying to get it widely deployed.

  Alan DeKok.

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 21 Aug 2007 21:45:21 -0700

I would like to see the crypto-binding stuff (not compound binding -- as 
others have noted, we don't have consensus on that topic) and 
extensibility (how to add new attributes) specified.

That should not take more than 1-2 months to write-up, review and 
finalize :).  That should also be least disruptive to existing 
implementations.  I would also like to see TTLS-v0 published very soon.

regards,
Lakshminath

---

From: "Hao Zhou \(hzhou\)" <[email-masked]>
Date: Wed, 22 Aug 2007 02:17:59 -0400

Lakshminath:

Do you mean channel binding, not "compound binding"? I thought
crypto-binding is "compound-binding".

I think publishing a "widely" deployed EAP method is orthogonal to
publishing a new method meeting EMU charter. I agree publishing the
existing method as deployed is something needs to be done quickly. I am
still doubtful that adding the extra stuff required to meet the charter
(crypto-binding, crypto-agility, synchronized result indication,
internationalization), to the existing method can be done without
breaking backward compatibility.  If indeed breaks it, then the argument
of TTLS is widely deployed doesn't stand anymore. The new method or new
version of the old method still needs to be implemented and deployed.

> Sent: Wednesday, August 22, 2007 12:45 AM
> To: Alan DeKok
> Cc: Sam Hartman; [email-masked]
> I would like to see the crypto-binding stuff (not compound 
> binding -- as others have noted, we don't have consensus on 
> that topic) and extensibility (how to add new attributes) specified.
> 
> That should not take more than 1-2 months to write-up, review 
> and finalize :).  That should also be least disruptive to 
> existing implementations.  I would also like to see TTLS-v0 
> published very soon.
> 
> regards,
> Lakshminath
> 
> > void spending years talking about a new EAP method, 
> followed by years 
> > of trying to get it widely deployed.
> > 
> >   Alan DeKok.
> >

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 21 Aug 2007 23:24:30 -0700

Yeah, sorry.  I meant channel binding.

I am not necessarily tying TTLS-v0 with the password-based EMU method 
deliverable.  If the extensibility is there, that decision could be 
separated from the much needed publication of TTLS-v0.

regards,
Lakshminath

---

From: Alan DeKok <[email-masked]>
Date: Wed, 22 Aug 2007 11:56:14 +0200

Hao Zhou (hzhou) wrote:
> internationalization), 

  I'm not sure why internationalization is an issue.  This came up in
RADEXT a while ago.  The consensus at the time was that RFC 4282
discusses internationalization of the NAI, and that passwords don't need
to be internationalized.

  Internationalization matters for *display* to end users.
Internationalization is about *languages*.  Passwords aren't displayed,
and they aren't words in any language.  They're opaque tokens that users
have memorized, and can repeat on demand to demonstrate secret knowledge.

> to the existing method can be done without

  One of the suggestions at IETF 69 was that TTLS was at least safely
backwards compatible with any new feature.  i.e. The new features would
require changes to the content of the TLS tunnel, and not much else.
Those changes could be done via AVP's with the "M" bit set.  Existing
clients would know enough to fail when they saw an "M" bit set on an AVP
that they didn't understand.

  Do you expect that crypto-binding/agility features would require
changes that are not compatible with existing TTLS deployments?  If so,
can you provide examples?

  Alan DeKok.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 22 Aug 2007 07:14:32 -0400

>>>>> "Alan" == Alan DeKok <[email-masked]> writes:

    Alan> Hao Zhou (hzhou) wrote:
    >> I think publishing a "widely" deployed EAP method is orthogonal
    >> to publishing a new method meeting EMU charter. I agree
    >> publishing the existing method as deployed is something needs
    >> to be done quickly. I am still doubtful that adding the extra
    >> stuff required to meet the charter (crypto-binding,
    >> crypto-agility, synchronized result indication,
    >> internationalization),

    Alan>   I'm not sure why internationalization is an issue.  This
    Alan> came up in RADEXT a while ago.  The consensus at the time
    Alan> was that RFC 4282 discusses internationalization of the NAI,
    Alan> and that passwords don't need to be internationalized.

    Alan>   Internationalization matters for *display* to end users.
    Alan> Internationalization is about *languages*.  Passwords aren't
    Alan> displayed, and they aren't words in any language.  They're
    Alan> opaque tokens that users have memorized, and can repeat on
    Alan> demand to demonstrate secret knowledge.

The consensus of the SASL and Kerberos communities has been different.
In particular, these communities believe that it is strongly desirable
that the same password when entered on two different systems actually
work.  To get that, you need to deal with issues like normalization.
Otherwise, if you use a system with input methods that produce
combined characters you will get different results than if you use
input methods that produce decomposed characters.

At some level, this is an implementation issue for the server.
However to support the server, you definitely need to label the
character set, discuss any normalization that the client should do
(often none) and set interoperability goals.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 22 Aug 2007 07:48:37 -0400

>>>>> "Lakshminath" == Lakshminath Dondeti <[email-masked]> writes:

    Lakshminath> I would like to see the crypto-binding stuff (not
    Lakshminath> compound binding -- as others have noted, we don't
    Lakshminath> have consensus on that topic) and extensibility (how
    Lakshminath> to add new attributes) specified.

I'd really appreciate it if someone would think hard about the
interactions of draft-housley-aaa-key-mgmt and channel binding.  I'd
like to understand whether we can meet all the requirements of that
BCP without channel binding and if not, what we need to do about it.

---

From: "Gene Chang \(genchang\)" <[email-masked]>
Date: Wed, 22 Aug 2007 10:28:51 -0400

> Sent: Wednesday, August 22, 2007 5:56 AM
> To: Hao Zhou (hzhou)

- Passwords aren't just a random number.
- Users often need mnemonic aids to accurately reproduce their
passwords. This is why often passwords are related to words or phrases.
- It is also important that these passwords are normalized between the
user system and the backend systems as the strings generated by the
user's system may be handled differently from the backend.
- There may be more variety for users that use multiple systems or speak
multiple languages or for backend systems that support a community that
use more than one language.

Gene Chang

---

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 22 Aug 2007 09:38:41 -0700

Sam,

We discussed channel binding before the publication of 4962 (I was 
reminded recently that draft-housley-aaa-key-mgmt is now a published 
document :) ) and concluded (I think) that the language in 4962 should 
just mirror the language of 3748.  I think that is what 4962 in fact does:

"As described in RFC
          3748 in Section 7.15, channel binding is required to enable the
          peer to verify that the authenticator claim of identity is both
          consistent and correct."

As to what needs to be done for channel binding, I would echo what 
Bernard said recently

"With respect to Channel Bindings, it should be understood that no 
proposals for this have ever been implemented, as far as I am aware.  So 
a first step would be for a method to choose one of the approaches to 
Channel Bindings and support it (probably as an experimental extension), 
and then to evaluate the experiment so we can understand how well (or 
badly) the chosen approach works.  At that point we might be ready to 
support Channel Bindings in other methods. "

best regards,
Lakshminath

---

From: Alan DeKok <[email-masked]>
Date: Thu, 23 Aug 2007 10:57:09 +0200

Sam Hartman wrote:
> work.

  Well, yes.  But is it a real problem, or a theoretical issue?

  RADIUS has had over a decade of experience in authenticating pretty
much everyone who accesses the Internet.  Internationalization issues
with usernames or passwords just haven't been encountered.  I'm wary of
trying to create a solution where the existing deployments show no problems.

  I know of multiple RADIUS / EAP implementations outside of North
America, with 15 million or more users.  The largest Kerberos
implementation I've heard of was about a million users.

  I think that RADIUS has pretty well searched the space of potential
internationalization issues.

>  To get that, you need to deal with issues like normalization.

  For EAP methods, the majority of users are using a small number of
input systems for almost all authentications.  e.g. a laptop.  They
enter the password once, and it's cached for the next time.  Even if
they have to enter the password again, they will likely do so on a
similar system.  So whatever format is used the first time is the same
format they user for subsequent authentications.

  This doesn't solve the problem, but it makes the problem much less
likely to appear.

> (often none) and set interoperability goals.

  The whole composed / decomposed thing is a nightmare for passwords.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 23 Aug 2007 11:31:15 +0200

> passwords. This is why often passwords are related to words or phrases.

  The key is "related".  But they're not words, and we should not treat
them as such.

  The only important requirement is *consistency*.  All systems that are
used to enter passwords must convert the users intention to the same
sequence of bytes.  Once that's done, the rest of the network can treat
the password as an opaque token.  Doing it this way simplifies the i18n
issues enormously for the authentication systems.

> user's system may be handled differently from the backend.

  Are you really saying that the backend has to *interpret* the password
that the user has entered?  i.e. Turn o" into ö?

  What happens when the back-end has stored the password in hashed
format?  Does *it* normalize the password sent to it by the client
before doing the hash?  Does it try hashing & comparing both the
normalized and non-normalized passwords?

  If the authentication server can normalize the password, why isn't
that done on the client, which presumably has *more* information about
the users language preferences?  Doing that would also permit better
scaling, as more per-user work is done at the edge, where it belongs.

> use more than one language.

  I understand what you're trying to get at, but has this been a real
problem in currently deployed networks?

  I see these issues as requirements on end user devices, UI, and data
entry schemes.  I don't see that these issues should affect the
underlying authentication protocol.  The client device should do any
normalization or mangling, and send an opaque sequence of bytes to the
authentication server.  The authentication server shouldn't interpret
those bytes, it should just compare them to previously stored credentials.

  Alan DeKok.

---

From: "Gene Chang \(genchang\)" <[email-masked]>
Date: Thu, 23 Aug 2007 10:32:53 -0400

> Sent: Thursday, August 23, 2007 5:31 AM
> Cc: Hao Zhou (hzhou); Sam Hartman; [email-masked]
[EC: ] Yes...
> scaling, as more per-user work is done at the edge, where it belongs.
[EC: ] [EC: ] No... I implied that we cannot assume the backend UI and the client system UI will convert human input into normalized passwords the same way unless we explicitly specify the conversion. Otherwise we are in agreement about the typical machinery.

> problem in currently deployed networks?
[EC: ] Whether it is a problem or not depends on your perspective and on our attitude of being user friendly. I have seen this issue in the past. Back then, the AAA system could not handle multiple inputs from multiple character sets. The solution then was to require all users of a system to "speak" the same language. In large international deployment, this usually means that all users us our "English" character set. The time is past for us to expect single language systems.

> those bytes, it should just compare them to previously stored credentials.
[EC: ] It depends on where we want to put the normalization and where we want to handle differences between different operating systems.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 24 Aug 2007 12:13:54 +0200

Gene Chang (genchang) wrote:
> [EC: ] [EC: ] No... I implied that we cannot assume the backend UI and
> the client system UI will convert human input into normalized
> passwords the same way unless we explicitly specify the conversion.

  Yes.

> [EC: ] Whether it is a problem or not depends on your perspective
> and on our attitude of being user friendly. I have seen this issue
> in the past. Back then, the AAA system could not handle multiple
> inputs from multiple character sets. The solution then was to
> require all users of a system to "speak" the same language.
> In large international deployment, this usually means that all users
> us our "English" character set. The time is past for us to expect
> single language systems.

  I agree.  The tests I've done on multiple AAA systems indicate that
the majority now support UTF-8.  This solves many 18n issues, other than
composed / decomposed characters.

> [EC: ] It depends on where we want to put the normalization and where
> we want to handle differences between different operating systems.

  My opinion is that normalization belongs at the edge, which generally
also has information about the language and locale.  Once normalization
is performed, the password can be sent over the wire *without* language
or locale information to the server.

  Alan DeKok.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 27 Aug 2007 10:59:42 -0400

>>>>> "Alan" == Alan DeKok <[email-masked]> writes:

    Alan>   My opinion is that normalization belongs at the edge,
    Alan> which generally also has information about the language and
    Alan> locale.  Once normalization is performed, the password can
    Alan> be sent over the wire *without* language or locale
    Alan> information to the server.

This isn't a bad idea.  Think though about how it interacts with
password databases used for multiple purposes.  You sometimes get into
situations where you need to do normalization both at the client and
server.  That too can be OK.  You just need to think it all through
when writing your specs.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 27 Aug 2007 11:03:13 -0400

>> character set, discuss any normalization that the client should
    >> do (often none) and set interoperability goals.

    Alan>   The whole composed / decomposed thing is a nightmare for
    Alan> passwords.

And one the emu working group needs to deal with.

Sam hartman
Security Area Director

---

From: Alan DeKok <[email-masked]>
Date: Tue, 28 Aug 2007 10:53:20 +0200

> And one the emu working group needs to deal with.

  RFC 3629 says that overlong sequences are invalid:

   Implementations of the decoding algorithm above MUST protect against
   decoding invalid sequences.  For instance, a naive implementation may
   decode the overlong UTF-8 sequence C0 80 ...

  I would therefore follow the lead of the UTF-8 experts, and suggest
that decomposed characters are "overlong", and thus invalid for the
purposes of EMU.  Therefore, UTF-8 sequences must consist solely of
composed characters.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 28 Aug 2007 10:55:11 +0200

> server.  That too can be OK.  You just need to think it all through

  When people enter passwords, the pop-up window often says "CASE
SENSITIVE", and "Make sure you don't have CAPS-LOCK pressed".

  Servers don't currently normalize passwords to do case-insensitive
comparisons.  I don't see why they would need to normalize passwords for
composed/decomposed characters.

  Alan DeKok.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 28 Aug 2007 10:59:17 -0400

>>>>> "Alan" == Alan DeKok <[email-masked]> writes:

    Alan> Sam Hartman wrote: The whole composed / decomposed thing is
    Alan> a nightmare for passwords.
    >>  And one the emu working group needs to deal with.

    Alan>   RFC 3629 says that overlong sequences are invalid:

    Alan>    Implementations of the decoding algorithm above MUST
    Alan> protect against decoding invalid sequences.  For instance, a
    Alan> naive implementation may decode the overlong UTF-8 sequence
    Alan> C0 80 ...

    Alan>   I would therefore follow the lead of the UTF-8 experts,
    Alan> and suggest that decomposed characters are "overlong", and
    Alan> thus invalid for the purposes of EMU.  Therefore, UTF-8
    Alan> sequences must consist solely of composed characters.

This will be my last message on the subject.

There are approaches to consider in this space, but it's not that simple.

If only it were that simple.  One of the simplest problems with this
approach is that not all the combined characters that you need
actually exist.  Another potential issue is that I think normalizing
towards decomposed may be easier than normalizing towards combined.

--Sam