Jim:
Thanks for the detailed review comments. Response inline below. Will try
to submit a new rev with these changes soon.
On 11/15/12 3:24 PM, Jim Schaad i...@augustcellars.com wrote:
Expanding on the issues so that you have full descriptions of the problem
from the last message
1. When
field, or a
length of the Outer TLV data would be preferable to me. If you did the
second, then it would only affect processing on the first two messages.
Jim
-Original Message-
From: Hao Zhou (hzhou) [mailto:hz...@cisco.com]
Sent: Tuesday, October 09, 2012 12:46 PM
To: Jim Schaad; emu
Stefan:
Actually even if the client is authenticated as part of the TLS tunnel
establishment, NEA data can still be passed inside TEAP tunnel. It is
designed to carry additional data in Phase 2.
The Current TEAP draft supports both of these modes, as in Section 3.2:
TEAP implementations MUST
Jim:
Please see comments inline below.
On 10/8/12 1:11 AM, Jim Schaad i...@augustcellars.com wrote:
-Original Message-
From: Hao Zhou (hzhou) [mailto:hz...@cisco.com]
Sent: Thursday, October 04, 2012 2:56 PM
To: Jim Schaad; emu@ietf.org; draft-ietf-emu-eap-tunnel-
met
Agree. We will clarify that.
On 10/8/12 1:11 AM, Jim Schaad i...@augustcellars.com wrote:
-Original Message-
From: Hao Zhou (hzhou) [mailto:hz...@cisco.com]
Sent: Thursday, October 04, 2012 3:06 PM
To: Jim Schaad; emu@ietf.org; draft-ietf-emu-eap-tunnel-
met...@tools.ietf.org
in the TEAP document about the length
of
the TLS data. Are you suggesting that one should crack the TLS data blob
to find the length of that data blob?
Jim
-Original Message-
From: Hao Zhou (hzhou) [mailto:hz...@cisco.com]
Sent: Tuesday, October 09, 2012 11:43 AM
To: Jim Schaad; emu
Jim:
Thanks for the review. Please see my comments below.
On 9/30/12 2:01 PM, Jim Schaad i...@augustcellars.com wrote:
1. Should the Message Length field be present if the TLS Data field is
absent?
[HZ] According to the text in the draft, the message length field should
only be present if the
Jim:
Please see comments below.
On 10/1/12 1:10 PM, Jim Schaad i...@augustcellars.com wrote:
I found two that I forgot to include in the last message
1. When exporting the user-id, does there need to be a way to distinguish
at export time between the different types of ids that are
Jim:
Thanks for pointing out this issue. How about the following text with slight
modification with policy control from both sides to prevent downgrade attack.
Added text in red.
1. The first sender of the Crypto-Binding TLV needs to create it as
follows:
a) If the EMSK is not available, then
Jim:
Your comments were on draft-ietf-emu-crypto-bind-00.txt, not
draft-ietf-emu-eap-tunnel-method?
On 9/26/12 12:10 AM, Jim Schaad i...@augustcellars.com wrote:
Version 0 of the document is not ready for a last call as security
considerations are missing.
Other comments
1. I think in
Simon:
Thanks for the review. Good catch on both. We will fix both of them.
On 9/25/12 2:02 PM, Simon Josefsson si...@josefsson.org wrote:
Alan DeKok al...@deployingradius.com writes:
https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-method/
Section 5.3:
The Compound MAC
Sam:
A new draft TEAP-03 was submitted. Please review and make sure all of your
issues raised below are addressed in this draft. Thanks.
On 3/25/12 7:50 AM, Sam Hartman hartmans-i...@mit.edu wrote:
1) TEAP extends TLS RFC 5077
In section 2, TEAP discusses using phase 2 TLVs to include a TLS
...@mit.edumailto:hartmans-i...@mit.edu, Zhangdacheng (Dacheng)
zhangdach...@huawei.commailto:zhangdach...@huawei.com
Subject: 答复: Re: 答复: RE: Re: [Emu] New draft on mutual crypto binding problem
Regards~~~
-Sujing Zhou
Hao Zhou (hzhou) hz...@cisco.commailto:hz...@cisco.com 写于 2012-07-10
00:33:21:
We
Jouni:
Thanks for the feedback.
To clarify, EAP-FAST-MSCHAPv2 is only being used during anonymous
provisioning mode, in other cases, the normal EAP-MSCHAPv2 is being
used. This is mentioned in draft-cam-winget-eap-fast-provisioning
Section 3.2.3 and reflects current implementations. The design
Dave and Dorothy:
We don't believe there are interoperability issues, as the intended
informational RFCs clearly describe the protocol and packet format over
the wire for these inner methods specifically when running inside
EAP-FAST. The so called interoperability issue raised is at most an
I like Bernard's text better.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Bernard Aboba
Sent: Wednesday, April 30, 2008 7:54 PM
To: Joseph Salowey (jsalowey); emu@ietf.org
Subject: Re: [Emu] EMU charter revision,
[Joe] Jari had asked to
: Dan Harkins [mailto:[EMAIL PROTECTED]
Sent: Monday, April 28, 2008 12:45 PM
To: Hao Zhou (hzhou)
Cc: Yoav Nir; emu@ietf.org
Subject: Re: [Emu] EMU charter revision
Hold on a second there Hao. A security proof was never a
requirement.
I'm not aware of any other IETF protocols
Joe:
I approve the current charter revision and am willing to contribute to
the tunnel method.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Joseph Salowey (jsalowey)
Sent: Tuesday, February 19, 2008 2:15 PM
To: Joseph Salowey (jsalowey);
Joe:
I am ok with the updated charter, with the following minor comments:
1. Should we add crypto-agility to the requirements of tunnel method?
And maybe strong shared secret method as well?
2. Move this paragraph right after the tunnel method paragraph, as it
reference the tunnel method above.
I can help.
-Original Message-
From: Joseph Salowey (jsalowey)
Sent: Tuesday, October 30, 2007 2:29 PM
To: emu@ietf.org
Subject: [Emu] Password Method Consensus
We have working group consensus to move forward with working
on a tunneled EAP method in order to provide the basis
Me too. I like to see a standard based tunneling method, that supports
crypto-binding, crypto-agility, internationalization, as well as a
standard framework for extension within the tunnel.
-Original Message-
From: Ryan Hurst [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 03,
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
There is an EAP-FAST module for EAPHost plug-in, which currently uses
three hard coded inner methods, EAP-GTC, EAP-MSCHAPv2 and EAP-TLS. But
it can be extended to work with EAPHost supplicant interface to load any
inner method registered with EAPHost. Will you have a POTP plug-in soon?
The problem
Is there any reason not to use the approach in RFC2716Bis? This
guarantees backward compatibility and require less computation.
From: Bernard Aboba [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 07, 2007 3:05 PM
To: emu@ietf.org
What is the difference between defining a new method vs. a new version
of the existing EAP method that is not backward compatible? I don't see
how the implementation issue will go away. Some one still needs to
implement it and customers need to deploy it. Might be more confusing to
define another
Bernard:
I am not sure reusing one of the existing EAP methods is the right
approach. All three EAP method mentioned, EAP-TTLS/PEAP/EAP-FAST all has
something that are outside the scope of the charter, which means we have
to take some of them out. Not unitl we change the charter, then we can
pick
26 matches
Mail list logo
