EKE is a well known password-based mutual authentication protocol. The patent
on EKE is nearing expiry, so we figured this is a good time to specify an EAP
method using this protocol.
We would appreciate all comments.
Thanks,
Yaron
-Original Message-
From: internet-dra...@ietf.
Hi everyone,
We have just published a new version of the EAP-EKE draft, closing a
vulnerability that was discovered on CFRG. I hope everyone has had enough
EAP-FAST bashing for a while (:-) and can give our protocol some bashing, too.
Thanks,
Yaron
-Original Message-
From: inte
Hi,
A few days ago I was at Tel Aviv University to see a demonstration of
EAP-EKE, implemented between a WPA client (wpa_supplicant), a generic access
point and a FreeRADIUS server. All working very smoothly. The students
managed to write the whole thing based on the draft
(http://tools.ietf.org/h
Hi,
Pasi asked that we propose a charter item for password-based authentication,
so here's a first shot, for your review.
Thanks,
Yaron
The working group will develop a single standards-track EAP method for
authenticating users using short, memorable passwords but with n
Hi,
Referring to Sec. 3.5 of
http://tools.ietf.org/html/draft-ietf-emu-eaptunnel-req-03, there should be
an indication to the application that is using EAP that such "strange"
authentication took place. For example, the VoIP server may than make sure
that only calls to 911 or 112 are allowed. O
I'm fine with this text.
Thanks,
Yaron
> -Original Message-
> From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of
> Joseph Salowey (jsalowey)
> Sent: Thursday, August 06, 2009 22:16
> To: emu@ietf.org
> Subject: [Emu] Issue #15: Algorithm agility and certs
>
>
Actually this is still kind of vague: what is "generated directly"? In a
challenge-response, it is the password is encrypted/hashed - does this count
as "directly"?
Also, *all of* sec. 4.5.1 should apply to this kind of methods, not just
server authentication. So I suggest to replace:
Due to
Well, this could stand even more detail, but fine...
> -Original Message-
> From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of
> Joseph Salowey (jsalowey)
> Sent: Thursday, August 06, 2009 22:18
> To: emu@ietf.org
> Subject: [Emu] Issue #17: What is "housekeeping"
>
> #
I support the current text. Having explicit marking for mandatory attributes
(a "Critical bit") adds power to protocol extensions, in that you can ensure
that negotiation will fail if the other side doesn't understand you.
Thanks,
Yaron
> -Original Message-
> From: emu-boun...@iet
[snip]
>
> > Section 4.2.1.1.3
> >
> > " A tunnel method MUST provide unidirectional authentication from
> >authentication server to EAP peer or mutual authentication between
> >authentication server and EAP peer."
> >
> > Is this really an or? For example, would a tunnel method
Yes, you are right.
Yaron
> -Original Message-
> From: Joseph Salowey (jsalowey) [mailto:jsalo...@cisco.com]
> Sent: Friday, August 07, 2009 0:26
> To: Yaron Sheffer; emu@ietf.org
> Subject: RE: Issue #22: Collection of smaller issues
>
> In section 3.7 we
The contract between the authenticator and the EAP layer is, when I see an
EAP Success message, it means that both sides are authenticated. We are now
breaking this contract, so it makes sense to have EAP inform the upper layer
of this fact.
But I suppose EAP is not extensible enough to add such s
Hi,
IMHO this document is not ready to be advanced, at least not as Standards Track.
The document is extremely abstract: it defines the problem statement very well,
but then keep its options open when describing the solution. The fact that the
document has an empty IANA section is a strong hint
e-
> From: Hoeper Katrin-QWKN37 [mailto:khoe...@motorola.com]
> Sent: Tuesday, March 02, 2010 17:57
> To: Yaron Sheffer; emu@ietf.org
> Subject: RE: [Emu] Working Group Last Call for draft-ietf-emu-chbind-
> 04.txt
>
> Yaron,
>
> Thank you for your comments.
>
>
Joe, what Dan is proposing is a reasonable way to use a one-time password for
the initial provisioning of a trust anchor. Initial provisioning is important
for many types of deployments. Does the document allow an alternative secure
way to do that?
Dan, I suspect that for this specific use case
gt; From: Alan DeKok [mailto:al...@deployingradius.com]
> Sent: Thursday, March 04, 2010 8:47
> To: Yaron Sheffer
> Cc: emu@ietf.org
> Subject: Re: [Emu] review of draft-ietf-emu-eaptunnel-req-04
>
> Yaron Sheffer wrote:
> > Joe, what Dan is proposing is a reasonable way to use a one-
Hi Joe,
Yes, I am OK with the text.
Thanks,
Yaron
> -Original Message-
> From: Joseph Salowey (jsalowey) [mailto:jsalo...@cisco.com]
> Sent: Thursday, March 04, 2010 17:12
> To: Yaron Sheffer; Alan DeKok
> Cc: emu@ietf.org
> Subject: RE: [Emu] review of draft-
Hi Sam,
I am glad you are taking a fresh look at this issue. Some comments:
- I think draft-ietf-emu-chbind is not as interesting, or potentially
useful, as draft-clancy-emu-aaapay. In any case, both drafts should be
looked at together.
- I think tunnel methods are more trouble than they're
I'd like to point out that EAP-EKE (RFC 6124) is another potential
candidate for this role.
Yes, it is also Informational.
Thanks,
Yaron
On 08/25/2011 09:01 AM, emu-requ...@ietf.org wrote:
Message: 1
Date: Wed, 24 Aug 2011 15:15:28 -0400
From: Sam Hartman
To: "Dan Harkins"
Cc: emu@ietf.or
19 matches
Mail list logo
