On 2/23/2012 3:21 PM, Dan Harkins 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. While that might be true in -01, the issue
should not be closed. TLVs 8, 16,
On 10/20/2011 8:55 PM, Sam Hartman wrote:
Glen == Glen Zorn glenz...@gmail.com writes:
Glen On 10/20/2011 3:09 AM, Sam Hartman wrote:
I believe I've addressed all of Alan's comments with the exception of
removing the RADIUS diagram from 5.3.
Glen Great, so what
On 10/20/2011 3:09 AM, Sam Hartman wrote:
I believe I've addressed all of Alan's comments with the exception of
removing the RADIUS diagram from 5.3.
Great, so what are we supposed to do now? WGLC was issued on
draft-ietf-emu-chbind-09. The last call is not complete. Shall we just
start
On 8/26/2011 1:13 PM, Dan Harkins wrote:
On Thu, August 25, 2011 10:32 pm, Glen Zorn wrote:
On 8/26/2011 4:22 AM, Dan Harkins wrote:
3) I think MSCHAPv2 is an entirely inappropriate MTI for this
mechanism. I brought that up as an example about how under certain
conditions the fact
On 8/26/2011 1:27 PM, Glen Zorn wrote:
...
Hardly. The fact that the IETF was busy a) insisting that there was no,
and never would be, any need for dynamic key generation (let alone
mutual authentication) in network access protocols (specifically PPP;
how could there be, since the only
On 8/24/2011 3:03 AM, Dan Harkins wrote:
Hello,
I noticed that the initial registry for TLV types starts out with
three reserved numbers which is pretty odd. It says in the IANA
Considerations (similar verbage is in the General TLV Format of
section 4.2.1):
A summary of the
On 8/26/2011 4:22 AM, Dan Harkins wrote:
3) I think MSCHAPv2 is an entirely inappropriate MTI for this
mechanism. I brought that up as an example about how under certain
conditions the fact that something is the kind of thing the IETF
standardizes but is never the less informational should
On 8/24/2011 3:12 AM, Dan Harkins wrote:
Hello,
In Quebec there was a discussion on what we're gonna call the tunnel
method. The candidates discussed were:
- ITEM -- Internet Tunnel EAP Method
- ETA -- Extensible Tunneled Authentication
- TEAP -- Tunnel EAP
- EAP-TUNNEL
On 8/10/2011 12:31 PM, Joe Salowey wrote:
At the meeting in Quebec we discussed removing attributes specific to
particular media types or lower layers and including recommendations for a
small number of generally useful attributes in the draft.
The attribute that seems to be most useful
On 5/31/2011 11:08 AM, Joe Salowey wrote:
On May 23, 2011, at 5:50 PM, Glen Zorn wrote:
On 5/24/2011 12:53 AM, Joe Salowey wrote:
One benefit I see in keeping the same EAP method type code is it allows
secure version negotiation from v1 to v2 with version rollback protection
On 5/23/2011 7:45 PM, Stefan Winter wrote:
Hi,
two suggestions for the new name (assuming that the Deciders establish
that a new type is a good idea), just to get the ball rolling: Tunneled
Extensible Authentication Method (TEAM, an oldie but goody) and Internet
(or IETF) Tunneled EAP
On 5/24/2011 12:53 AM, Joe Salowey wrote:
One benefit I see in keeping the same EAP method type code is it allows
secure version negotiation from v1 to v2 with version rollback protection.
However, moving to a new EAP type code would seem to make EAP method
negotiation somewhat better
On 5/18/2011 12:39 PM, Alan DeKok wrote:
Glen Zorn wrote:
On 5/17/2011 2:33 PM, Alan DeKok wrote:
We're asking for input, not a decision right now.
Why not?
I'd like to see what the WG consensus is prior to making a decision.
I guess the IETF process has really changed lately! I had
On 5/17/2011 2:33 PM, Alan DeKok wrote:
Nancy Cam-Winget wrote:
It seems too early to decide whether there is a need to change the EAP type
at this point.
We're asking for input, not a decision right now.
Why not?
Changing the type code has implications to the configuration and
On 5/16/2011 7:39 PM, Sam Hartman wrote:
I'd like to confirm my understanding.
The current text proposes the use of eap type code 43.
I'd like to confirm that code is in use both by implementations of
eap-fast v1 and v2.
I'm pretty sure that there are no implementations (except maybe
On 5/16/2011 9:32 PM, Hao Zhou 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.
As a backup question: Are there *any* implementations of v2?
On 5/15/2011 2:36 AM, Sam Hartman wrote:
Alan == Alan DeKok al...@deployingradius.com writes:
Alan Glen Zorn wrote:
There seem to be two issues here: renaming the draft allocating
a new EAP type. For which one are opinions being solicited?
Alan Allocating a new EAP
On 5/13/2011 10:29 PM, Alan DeKok wrote:
Since we have reached WG consensus on the method, can the authors of
draft-zhou-emu-eap-fastv2-00.txt
please re-submit the document as:
draft-ietf-emu-eap-tunnel-method-00.txt
The reason for the name change is that there have
On 4/19/2011 1:12 AM, Sam Hartman wrote:
Glen == Glen Zorn g...@net-zen.net writes:
Glen On 4/16/2011 2:21 AM, Stephen Hanna wrote:
I agree with Katrin's count for the email poll. When combined
with the count from the meeting in Prague (since Alan asked for
only folks who
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 4/16/2011 2:21 AM, Stephen Hanna wrote:
I agree with Katrin's count for the email poll. When combined
with the count from the meeting in Prague (since Alan asked
for only folks who didn't attend the EMU WG meeting in Prague),
Based upon a
I agree w/Bernard. It is never too late to fix a broken document.
Hope this helps.
~gwz
From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of
Bernard Aboba
Sent: Tuesday, August 31, 2010 10:48 PM
To: emu@ietf.org
Subject: Re: [Emu] security paper on tunneled
Sam Hartman [mailto:hartmans-i...@mit.edu] writes:
Glen == Glen Zorn g...@net-zen.net writes:
Glen Or we could use the more direct much simpler approach of
Glen allowing the client to authenticate the network to which it is
Glen attached use that data to decide by itself
Alan DeKok [mailto:al...@deployingradius.com] writes:
Glen Zorn wrote:
Alan DeKok [mailto:al...@deployingradius.com] writes:
This proxying violates the privacy requirements.
What privacy requirements are those?
The requirement to keep authentication credentials private, which
Sam Hartman [mailto:hartm...@mit.edu] writes:
Glen == Glen Zorn g...@net-zen.net writes:
Hi. I have read the later messages on this thread, but it sounded like
you and Alan were talking past each other a bit, so I want to come back
to where I think the disagreement is introduced
Alan DeKok [mailto://al...@deployingradius.com] writes:
...
Channel bindings closes a security issue in current deployments of the
EAP protocol.
Is that true? If all you want is to solve the case where ...the NAS could
tell the user we're partner X: $0.05 / minute. It could *really* be
Alan DeKok [mailto://al...@deployingradius.com] writes:
...
It's part of the channel binding. It closes the loop between what
the
NAS tells the AAA, and what the NAS tells the client.
Only in the special case where (in your roaming example, below)
roaming
partners X and Y have
Alan DeKok [mailto:al...@deployingradius.com] writes:
Glen Zorn wrote:
Is there an RFC that says this somewhere?
RFC 3580, Section 3.20
OK, thanks. This appears to be identical to the section from 802.1X-2004
that I quoted below, though...
802.11-2007 doesn't mention
Called
Alan DeKok [mailto:al...@deployingradius.com]
(sigh, hit send too soon)
...
802.11-2007 doesn't mention
Called-Station-ID; 802.1X-2004 says this:
Taken from 3580.
Whatever; 3580 says
This document provides suggestions on Remote Authentication Dial In
User Service (RADIUS)
Sam Hartman [mailto://hartmans-i...@mit.edu] writes:
Hi. At IETF 77, I agreed to edit draft-ietf-emu-chbind. Also, at that
meeting, I sat down with Glen to understand his concerns with the
document. I'd like to write up my notes on that meeting and to discuss
what I think the critical next
Sam Hartman [hartmans-i...@mit.edu] writes:
Folks, I'm trying to get a room for the federated authentication bar BOF
Thursday March 25 at 9 PM US Pacific time I've requested a room from the
secretariat and Pasi said he would approve the request, so we'll see
what their availability is.
I
SeongHan Shin wrote:
Could you please let me know when the deadline of IPR disclosure is?
Before the meeting.
A little justification, please.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Alan DeKok [mailto:al...@deployingradius.com] writes:
Glen Zorn wrote:
No. Please don't confuse authentication with authorization. The
parameters
you mention above are policy-related, not related to authentication.
You are making arbitrary distinctions between pieces of information
Alan DeKok [mailto://al...@deployingradius.com] writes:
Alper Yegin wrote:
I’m not against this. But let’s face it, this is venturing into
dealing
with authorization parameters with EAP (EAP layer? EAP method layer?
Etc.) I’m not against that either. In fact, I know there are a lot of
pesky name purpose thing -- you know, Extensible
_Authentication_ Protocol.
Thanks,
Steve
-Original Message-
From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On
Behalf Of Alan DeKok
Sent: Tuesday, August 11, 2009 2:36 PM
To: Glen Zorn
Cc: emu@ietf.org
Subject
Stephen Hanna [mailto:sha...@juniper.net] writes:
This discussion started with the statement that channel bindings
are a form of authorization data.
And no one disputed this?
Our charter requires us to
support carrying channel bindings in the tunnel method.
Password change is another form
FYI
-Original Message-
From: i-d-announce-boun...@ietf.org [mailto:i-d-announce-boun...@ietf.org]
On Behalf Of internet-dra...@ietf.org
Sent: Sunday, May 03, 2009 2:45 PM
To: i-d-annou...@ietf.org
Subject: I-D Action:draft-clancy-emu-aaapay-02.txt
A New Internet-Draft is available from
Tim Polk [mailto://tim.p...@nist.gov] writes:
So, there's no problem with reusing IANA-assigned numbers for whatever
incompatible purpose one might like; oh, no, WAIT! There's a NOTE! Oooo,
scary. Just to save time and energy, I've saved the scary note as a XML
file will include it in every
Tim Polk [mailto:tim.p...@nist.gov] writes:
Folks,
As the AD that sponsored publication of the EAP-FAST documents under
discussion,
I have been trying to find the best way forward. I believe that the
best course of action
involves some clarifications to draft-cam-winget-eap-fast-
Hi, Bernard. I can't find anything in 5226 that says anything about
vendor-specific registries. Can you send a quote?
From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of
Bernard Aboba
Sent: Thursday, February 05, 2009 4:19 AM
To: emu@ietf.org
Subject: Re: [Emu] IANA
Alan DeKok [mailto:al...@deployingradius.com] writes:
Glen Zorn wrote:
Note that while it does say that the enabling of support for channel
bindings will not generate a new method it says nothing of the sort
about
the tunneled method itself,
Yes.
Both EAP-TTLS and EAP-FAST have
Alan DeKok [mailto:al...@deployingradius.com] writes:
Glen Zorn wrote:
Alan DeKok [mailto:al...@deployingradius.com] writes:
Discussing the applicability, cost, benefit, etc. of EAP-FAST is a
good idea. Re-visiting its architectural choices isn't something we
have time
Alan DeKok [mailto:al...@deployingradius.com] writes:
Dan Harkins wrote:
A tunnel method is definitely in our charter and we have had much
discussion on what that would look like. If you re-read the notes
from
IETF 71 there was a long discussion about choosing an existing one to
2. The following text could be added either in the introduction or IANA
considerations (or anywhere the IESG prefers):
EAP-FAST has been implemented by many vendors and it is used in the
Internet. Publication of this is intended to promote interoperability.
The reuse of EAP-MSCHAPv2/EAP-GTC
today, these
difficulties could be avoided by the assignment of new EAP Type
codes.
Although I concur with the assessments of Glen Zorn, Dan Harkins,
David Mitton and Dorothy Stanley in many respects, I would suggest that
those concerns are outweighed by the IETF's mission to make
pasi.ero...@nokia.com [mailto:pasi.ero...@nokia.com] writes:
Glen Zorn wrote:
Ok, so now I'm totally confused. None of the examples you cite are
IANA registries I would have no problem w/Cisco handing out
numbers for their proprietary protocol, but that's not what they're
doing
pasi.ero...@nokia.com [mailto:pasi.ero...@nokia.com] writes:
Glen Zorn wrote:
I would like to remind everyone that these documents did go
through IETF Last Call, and have already been approved by IESG.
Given the quality of the documents in question, perhaps that's not
something
Bernard Aboba [mailto:bernard_ab...@hotmail.com] writes:
Dan Harkins said:
draft-cam-winget-eap-fast-provisioning claims a reference to RFC 5226
but nowhere in that RFC can I find description of the following label
for an initial assignment of repository values:
allocated for management
- to meet the desire to document deployed methods.
Dorothy Stanley
On Mon, Feb 2, 2009 at 6:56 PM, Glen Zorn glenz...@comcast.net wrote:
Dear EMU WG:
These two documents are in the RFC Editor queue:
draft-cam-winget-eap-fast-provisioning-10.txt
draft-zhou-emu-fast-gtc-05.txt
Dear EMU WG:
These two documents are in the RFC Editor queue:
draft-cam-winget-eap-fast-provisioning-10.txt
draft-zhou-emu-fast-gtc-05.txt
The IESG has received a very late comment about these documents, and
we seek your input on the proposed resolution.
The late comment
Chris Hessing wrote:
Further it bothers me more when
I see a NIST document that indicates that EAP-FAST is the best choice
for a secure, but easy to deploy, EAP method.
Alan DeKok replied:
Do the NIST documents permit anonymous provisioning?
[KH]: No.
Unfortunately w/o anonymous
This version adds the following text: IEEE 802.1X as utilized by IEEE
802.11i. However, IEEE 802.11i (more formally IEEE Std 802.11i-2004)
disappeared when it was merged into the main standard, i.e., this
should
now be IEEE Std 802.11-2007 instead of IEEE 802.11i.
Yes.
Neither of these
Alan DeKok mailto://[EMAIL PROTECTED] writes:
...
Please respond FOR or AGAINST making the input and output lengths
independent. This consensus call will last until August 19.
FOR
...
___
Emu mailing list
Emu@ietf.org
Won't hurt, I suppose, as long as the adoption isn't a pass to WGLC (as it
seems to be in some other WGs).
...
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
-Original Message-
From: Glen Zorn [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 02, 2008 2:09 AM
To: Dan Harkins
Cc: Joseph Salowey (jsalowey); emu@ietf.org
Subject: RE: [Emu] comment on draft-ietf-emu-eap-gpsk
Joseph Salowey (jsalowey) scribbled on :
Thanks Dan, I agree
I agree with Bernard on all points.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Bernard Aboba
Sent: Friday, February 22, 2008 2:54 AM
To: emu@ietf.org
Subject: Re: [Emu] EMU Charter revision
SeongHan Shin scribbled on :
Dear Dan Harkins,
Sorry, I didn't know that the ID is updated.
Anyway, I'll go through the new ID.
By the way, is pwe in section 2.6.4.2 the same as PWE?
Yes.
...
___
Emu mailing list
Emu@ietf.org
Joseph Salowey (jsalowey) mailto:[EMAIL PROTECTED] scribbled on
Friday, January 25, 2008 12:45 AM:
So far I have only seen responses from Dan Harkins on the proposed
charter update (
http://www1.ietf.org/mail-archive/web/emu/current/msg00712.html )
I'm a little confused: I interpreted the
Bernard Aboba mailto:[EMAIL PROTECTED] allegedly scribbled on
Monday, April 02, 2007 3:42 PM:
Part of the problem with EAP methods is that people should have
started to standardize them within the IETF several years ago.
Unfortunately, there was no interest by some of the EAP method
authors
58 matches
Mail list logo
