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

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: Ryan Hurst [mailto:Ryan.Hurst@microsoft.com] 
Sent: Tuesday, August 14, 2007 9:57 AM
To: Alan DeKok; Stephen Hanna
Cc: emu@ietf.org
Subject: RE: [Emu] Crypto-binding in TTLS-v0

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:aland@deployingradius.com]
Sent: Tuesday, August 14, 2007 9:47 AM
To: Stephen Hanna
Cc: emu@ietf.org
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.

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

> 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.

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

  Alan DeKok.

_______________________________________________
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

_______________________________________________
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu

_______________________________________________
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu