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
-
From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of
Hao Zhou
Sent: Monday, April 02, 2012 4:29 AM
To: Jim Schaad; draft-ietf-emu-eap-tunnel-met...@tools.ietf.org
Cc: emu@ietf.org
Subject: Re: [Emu] Multiple Request Action Items
Jim:
Good question. The current draft
Jim:
Good question. The current draft allows for multiple request TLV items, but
only says a single Result TLV, indicating the what EAP Success/Failure
result the peer would expect if the requested action is not granted.
I can definitely see the need for the case you cited. If we want to extend
Stefan:
Actually this is already specified in TEAP. Section 3.6.1, states:
If the TEAP peer detects an error at any point in the TLS layer, the
TEAP peer should send a TEAP response encapsulating a TLS record
containing the appropriate TLS alert message. The server may restart
the
Jim:
Thanks for the detailed review. My comments are below inline:
On 3/21/12 6:15 AM, Jim Schaad i...@augustcellars.com wrote:
1. After the first exchange of messages, if the version does not match the
agreed on version - what happens?
[HZ] Good catch. Both sides should stick with the
Hi, Sam:
I can meet with you and Dacheng either during Monday lunch or first
afternoon session to discuss the options. Thanks.
On 3/19/12 3:00 PM, Sam Hartman hartmans-i...@mit.edu wrote:
Dear Hao:
I was pleased to hear your analysis of areas where mutual crypto binding
may be tricky to
I would like 30 mins of discussion on TEAP,
http://www.ietf.org/id/draft-ietf-emu-eap-tunnel-method-02.txt
2012/3/6 Alan DeKok al...@deployingradius.com
Please submit requests for agenda items to the EMU chairs.
Alan DeKok.
___
Emu
Sam:
This is a well thought and well written draft, it covers a lot of background
and aspect of the attacks and mitigations. However, I have few comments:
1. I don't agree that Mutual crypto-binding is the recommended mitigation
and should be added to TEAP. I actually think proper server
Dan:
I will reopen the ticket and address it in -02.
On 2/23/12 3:21 AM, Dan Harkins dhark...@lounge.org wrote:
Hi,
Ticket #35 was about the TLV numbering which had gaps of unassigned
in it. The ticket has been closed with the resolution, In -01 TLV
numbering starts a (sic) 1.
http://trac.tools.ietf.org/wg/emu/trac/ticket/36
Old Text:
³In the case of multiple peer authentications, the Peer-ID is determined
from the first peer authenticatication.²
New Text:
³In the case of multiple peer authentications, all authenticated peer
identities need to be exported. ²
http://trac.tools.ietf.org/wg/emu/trac/ticket/38
Clarify that crypto-binding TLV will always be run after every single EAP
authentication, also even if there is no inner EAP authentication or, to
ensure the outer TLVs and EAP type, version are verified.
TEAP draft 01,
http://trac.tools.ietf.org/wg/emu/trac/ticket/40
Channel Binding TLV should match Channel Binding Spec. clarify that channel
binding tlv can be used bidirectional to transmit channel back data and
verification result.
TEAP draft 01,
http://trac.tools.ietf.org/wg/emu/trac/ticket/34
Dan proposed text for server unauthenticated provisioning. This is still in
discussion on the list and has not be incorporated into the the draft.
TEAP draft 01,
http://tools.ietf.org/html/draft-ietf-emu-eap-tunnel-method-01
Section 3.2
Old
Sam:
My review comments:
1. Section 3, paragraph 1, should far removed be far remoted?
2. Section 3, bottom of Page 6, should virtual Lads (VLANs) be virtual
LANs (VLANs)?
3. Section 5.1, page 14, paragraph 2, should I2 be i2?
4. So, client sends channel-binding data automatically or by its
I wasn't aware of previous discussion and decision on this already. Sorry
for bringing this up. Proceed with the current draft.
On 10/21/11 3:36 PM, Alan DeKok al...@deployingradius.com wrote:
Sam Hartman wrote:
I think we discussed the flow in a fair bit of detail and I think we
have
Rereading the updated chbind draft, it has already defined the mechanism for
two way communication and tunnel EAP draft just defined a TLV container to
carry the Channel binding data defined in Section 5.3, so we should be ok.
No change is needed on the tunnel EAP draft on this, other maybe called
Alan:
Please see responses inline below.
On 5/16/11 9:02 AM, Alan DeKok al...@deployingradius.com wrote:
Sam Hartman wrote:
I'd like to confirm that code is in use both by implementations of
eap-fast v1 and v2.
[HZ] Yes. Type Code 43 is being used by EAP-FAST v1 and widely deployed.
We have submitted EAP-FAST Version 2 proposal for the standard Tunnel Based
EAP method. It is at
http://www.ietf.org/id/draft-zhou-emu-eap-fastv2-00.txt.
Comments welcome.
From: Alan DeKok al...@deployingradius.com
Date: Thu, 03 Mar 2011 18:24:34 +0100
To: Sam Hartman hartmans-i...@mit.edu
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
43 matches
Mail list logo
