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.
Issue:
Sec. 4.1.1 has requirements on algorithm agility. They are important,
but insufficient. I propose to mention that when the tunnel method uses
certificates, it MUST be possible to migrate to new algorithms for such
certificates as well. (This possibly belongs in 4.2.1).
Comment:
#19: Method Chaining
Section 3.3
Several circumstances are best addressed by using chained EAP
methods. For example, it may be desirable to authenticate the
user
and also authenticate the device that he or she is using.
This requirement can be met by support for cryptographic
Dan Harkins wrote:
Perhaps it would be a good idea to mandate that the method used
to authenticate the tunnel (outer method, whatever you want to call
it) MUST NOT be susceptible to a dictionary attack if it is going
to be used to transport a username and plaintext password to the
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
Issue:
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
#17: What
Section 3.1 already states:
... The tunnel method MUST support this use case.
However, it MUST NOT expose the username and password to parties in
the communication path between the peer and the EAP Server and it
MUST provide protection against man-in-the-middle and dictionary
I think your proposed text is good.
Thanks,
Joe
-Original Message-
From: Yaron Sheffer [mailto:yar...@checkpoint.com]
Sent: Thursday, August 06, 2009 1:40 PM
To: Joseph Salowey (jsalowey); emu@ietf.org
Subject: RE: Issue #16: Server auth
Actually this is still kind of vague:
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:
I just created several tickets for the tunnel requirements draft in the
issue tracker:
http://trac.tools.ietf.org/wg/emu/trac/report/1
I think issues 9 - 13, 15, 16, 22 are fairly straight forward. If there
is no discussion on these issues by 8/24 I will close the issues and
update the document
Hi Stephen,
Stephen Hanna wrote:
With respect to the internationalization issue noted below, relating
to draft-ietf-emu-eaptunnel-req-02.txt, Alexey Melnikov recently pointed
out to me that BCP 18 (RFC 2277), section 4.2 says:
Protocols that transfer text MUST provide for carrying
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 say:
The tunnel method
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
Often, there is a richer interface between EAP and the authenticator.
For example in an Access-Accept message from RADIUS a number of things
can be communicated about the authentication including the identity of
the authenticated peer. I also don't think that EAP-Success necessarily
implies
14 matches
Mail list logo
