easons I gave before, we cannot standardize on a
tunneled protocol that fails to support clear-text passwords.
I welcome text to clarify the security requirements. But I am opposed
to removing the stated requirement for clear-text passwords. Everything
else we've discussed is se
ns
> against the tunneled method when employing a username and password for
> authentication MUST be through interaction and not computation. "
The first sentence refers to "authentication server", while the second
uses "EAP server". I suggest using "EAP serv
real reason.
Who are the expected consumers of the document?
Anyone can read the ITU document, but who will be paying attention to
it, and following its recommendations?
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
We have a 1 hour slot on Wednesday. We currently have a few agenda
items, and want to ensure we don't miss any.
Please send agenda requests to Joe && myself.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
rest of the text.
What are the situations where authentication can continue after a NAK?
A NAK of a mandatory attribute should be treated as a failure.
Otherwise, what does "mandatory" mean, if it can be ignored?
Alan DeKok.
___
Emu mailing lis
l. (At least according
> to the current draft).
Hmm... I'd like to understand exactly what a NAK means, then. The
use-cases and failure scenarios aren't clear to me.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
--- Begin Message ---
IETF working group chairs;
We are developing an open-source tool for monitoring the status and
progress of conflicts in on-line working groups (WG). The tool works by
analyzing the WG mailing list. When developed, this tool should be
helpful to WG chairs trying to understan
esn't forbid anonymous methods, the only issue
here is whether or not the document should make them mandatory to
implement. I agree with Joe, in that they shouldn't be mandatory.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.iet
t; cert (I am thinking enterprise CA here, not a public CA).
Enterprises usually have areas which are physically secure, and that
can be used to bootstrap the system.
Anonymous provisioning is more useful for ISPs and telcos, who need to
provision user
SeongHan Shin wrote:
> Dear Alan DeKok,
>
> I'm Shin.
>
> I submitted the below I-D (00) and want to introduce our work.
> Could you please let me know if it is possible for me to present
> our work in emu WG?
Section 6 of the document says that a patent has been fi
(sorry, hit too soon)
SeongHan Shin wrote:
> Dear Alan DeKok,
>
> I'm Shin.
>
> I submitted the below I-D (00) and want to introduce our work.
> Could you please let me know if it is possible for me to present
> our work in emu WG?
Section 6 of the document s
SeongHan Shin wrote:
> Could you please let me know when the deadline of IPR disclosure is?
Before the meeting.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
document in question states that a patent application has been
filed, but no IPR disclosure has been submitted. Contributing to or
participating in IETF discussions about a technology without making
required IPR disclosures is a violation of IETF process.
Alan DeKok.
IETF 77 EMU WG Meeting
Wednesday, March 24, 2010
0900 - 1015 Pacific Time
Manhattan room
Anaheim, CA
Chairs: Joe Salowey
Alan DeKok
Jabber room: emu at jabber.ietf.org (please join)
Agenda
0900 - 910: Preliminaries
Bluesheets
Attendance
Note takers
Agenda bash
Presenters, please send slides to the chairs before Monday.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
comments.
If there are no objections, we will start the publication process. If
all goes well, the document should be in process by the next IETF meeting.
Alan DeKok.
internet-dra...@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
nsuming channel binding
> to need to pay attention to what their method supports. Some methods
> will support channel binding; some will not. However for those that do,
> we want a consistent interface provided to the lower layer.
I agree.
> I'd appreciate comments from the WG and chairs on this proposed
> approach.
I think it's a good approach.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
hat script would check the SSID, and enforce a local
configuration for that SSID.
But it's not the role of EAP to "change the configuration".
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Glen Zorn wrote:
> Alan DeKok [mailto:al...@deployingradius.com] writes:
>> and an indication that the home AAA approves
>> of the connection.
>
> Hmm. I could have sworn that this indication already existed, in the form
> of "Access-Accept" (for RADIUS).
And
Glen Zorn wrote:
> Is there an RFC that says this somewhere?
RFC 3580, Section 3.20
802.11-2007 doesn't mention
> Called-Station-ID; 802.1X-2004 says this:
>
> D.3.20 Called-Station-Id
> For IEEE 802.1X Authenticators, this attribute is used to store the Bridge
> or Access Point MAC address
t there is no way to detect such a lie in a >1 hop AAA scenario) and that
> there is no collusion between X & Z. We seem to be assuming a _lot_ of
> honesty from our thieves.
Yes.
There are mitigating circumstances. AAA relationships leverage trust.
Continued trust depe
>> Continued trust depends on the parties continuing to meet expectations.
>> Lying about SSIDs violates trust.
>
> But fraud doesn't?
Yes, fraud violates trust. My original post included an example of
fraud, stated why this was bad, and how channel bindings could h
Glen Zorn wrote:
> 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 &qu
Stephen McCann wrote:
> imho, I'd not place any trust in an SSID.
> Its just a 32 octet string that can be set to anything, and provides
> no guarantee about the identity of a WLAN.
It's useful as an exa
Glen Zorn wrote:
> Note that transitive trust issues are irrelevant if EAP-TTLS is used.
I agree with Sam here. I'd like to see more explanation behind this
assertion.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org
document describing how the client could perform the certificate checks
against the local network information, so that would require standards
action, too.
And I'm not sure why this applies only to TTLS. I see this as
applying equally well (or poorly) any other TL
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 is
one of the reasons for choosing a TLS-base
Glen Zorn wrote:
> Alan DeKok [mailto:al...@deployingradius.com] writes:
>> The requirement to keep authentication credentials private, which is
>> one of the reasons for choosing a TLS-based method in the first place.
>
> Are you confused? We're talking about bein
en use WISPr to post
the passwords. This is semantically identical to the proposal to
terminate EAP-TLS locally, and proxy the inner tunnel data.
The reason EAP channel bindings are being proposed is that many of the
people who've deployed "local TLS + password" login methods
roxy attackers?
The proposal to terminate TLS on the visited network *requires* that
the users credentials are exposed all the way down the proxy chain.
The proposal to terminate TLS on the home network *permits* the home
system to do what it wants with the user credentials.
If you can't see a difference between the two scenarios, then there is
nothing more to discuss.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
irrelevant.
The alternate view, and one I'm opposed to, is that a third-party
chooses the privacy requirements for the home system. In that view,
your question is highly relevant. Since it's not a view I hold, I
cannot answer your question in any meaningful way.
Alan DeKok.
I can see to do PAP inside EAP-TTLS or EAP-FAST is
> when using a token card or other OTP.
For enterprises, this is a reasonable assumption. For ISPs, it's not.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
This is a call for agenda items for IETF 78. We have a 1 hour time
slot at 9am on Wednesday AM.
Please email Joe && myself with requests for time on the agenda.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/
This is a reminder for presenters to send slides to the chairsby
Tuesday AM.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
ttend.
---
IETF 78 EMU WG Meeting
Wednesday, July 28, 2010
0900 - 1015 Pacific Time
Athens room
Maastricht, NL
Chairs: Joe Salowey
Alan DeKok
Jabber room: emu at jabber.ietf.org (please join)
Agenda
0900 - 910: Preliminaries
Bluesheets
Attendance
Note takers
Agenda
em? Right
> now it is still a personal draft.
Sam's suggestion (IIRC) was to merge the two documents. The channel
binding document is small, and may be better served by specifying the
protocol, too.
Alan DeKok.
___
Emu mailing list
Emu@
e made resistant to these attacks.
If that is right, then I don't think there is anything to do in the draft.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
the credentials.
For the attack to work on the client, it requires that the client set
up an anonymous tunnel with the attacker, and send credentials down that
tunnel. If the client were to associate the credentials with a server
cert, the attack could be detecte
-- Forwarded message --
From: NomCom Chair
Date: Thu, Sep 16, 2010 at 6:26 PM
Subject: NomCom 2010-2011: Call for More Nominations
To: IETF Announcement list
Hi Folks,
Nominations have slowed down dramatically, so this update is to enlist
the community in an effort to pick up
(1.a) Who is the Document Shepherd for this document?
==> Alan DeKok.
Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publicat
ntext of
channel bindings, then using a namespace (and AVP format) specific to CB
is the best approach.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
This is a call for proposals to meet the tunnel method requirements
defined in draft-ietf-emu-eaptunnel-req.
Proposals must:
* be in the form of an internet draft defining the method, including
references to appropriate existing documents.
* describe how the proposal meets the requirements.
to move forward with that option, effectively reversing
> our IETF 78 decision.
We should be aware of the alternatives,and costs/benefits before
making or reversing any decision.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
iameter is that the requirements are for the data to be
aligned. Does that requirement continue for the channel-bindings data?
Or can we just pack Diameter data into an opaque blob, and wrap a 2-4
byte "channel binding" header around it?
Alan DeKok.
_
We've asked for a 2 hour session for IETF. Please send requests for
agenda items to myself and Joe Salowey.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Sam Hartman wrote:
> I just want to confirm I haven't missed mail.
> It's my understanding that the call for proposals for tunnel methods
> closes March 7 and that so far we've seen no submissions.
> Is that correct?
Yes.
Alan DeKok.
one of the two proposed methods:
FASTv2
or
EAP-Team
Alan DeKok.
EMU Co-Chair
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Stephen Hanna wrote:
> Alan,
>
> Could you set a deadline for these comments?
Thursday April 14. That gives us 2 weeks, which is usual for a
consensus call.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
We had 4 responses on the list, in addition to the discussion at IETF.
Q1: 4 yes
0 No
Q2: 3 EAP-FASTv2
1 EAP-TEAM
The WG consensus is that EAP-FASTv2 should be the tunnel method.
Alan DeKok wrote:
> For people who didn't attend the EMU meeting at IETF, please answer
> th
I've gone back and reviewed my EMU folder, and Katrin is correct.
Sorry for the miscount.
As you not, this does not change the rough consensus of the WG, where
the majority at IETF supported FASTv2.
Alan DeKok.
___
Emu mailing list
Emu@ie
(speaking as individual contributor)
#1 - Yes, I agree.
#2 - encoding method #2
Joe Salowey wrote:
> This consensus call closes next week. This is an important working group
> work item. If you have an opinion about this issue please send it to the list
> so we can keep the work moving forw
Joe Salowey wrote:
>> 1. Do you agree with the direction taken in draft-ietf-emu-chbind-07. More
>> specifically the usage of a channel binding specific TLV, the support of
>> multiple name spaces, and that the server indicates to the client what
>> attributes were validated.
Yes.
>> 2.
the WG seems to be against this opinion.
Oh well.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
ng and
unpacking RADIUS attributes. There should be little cost to re-using
that, and a larger cost in writing a new attribute packer.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
with opinions either way is requested to discuss the pros and
cons of the issue.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
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?
Allocating a new EAP type.
The draft name "eap-tunnel-method" describes the protocol accur
keeping the existing EAP-FAST code?
What is the value in changing to a new code?
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
desired that people be able to create a v2 only implementation?
I will partially avoid those two questions, and say that it should be
possible to deploy only the EMU tunneled method.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
t is a factor to consider.
> I thought one of the
> reasons EAP-FASTv2 is adopted is because of its existing code and
> deployment, with small changes to meet EMU requirements. Changing the method
> name and type would totally negativate that.
I'm not sure how changing the
n the client side.
Yes, that is certainly true.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
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.
In addition, I'd like to be sure we understand the consequences
Glen Zorn wrote:
> I guess the IETF process has really changed lately! I had always
> thought that WG consensus _was_ the decision & the task of the chairs
> was merely to determine what WG consensus was. Silly me!
Make that "establish WG consensus prior to announcing a
before the meeting. This will allow the authors
to have a detailed list of issues to resolve, or questions to answer.
Please provide questions by the start of IETF (2 weeks). The EMU
meeting is early in the week, so there will not be time to review it
during the meeting.
Alan DeKok
Joe Salowey wrote:
> This is the working group last call for draft-ietf-emu-chbind-09. Please
> send your comments to the list by October 21, 2011.
I've read the document, and have comments as follows.
Section 4.3 Page 11:
For example, information carried
in AAA attributes such as t
uld be explanation as to why it's a good idea.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
onse uses the same basic format as the channel
binding data.
OK so what does the response *mean*?
For me, echoing a copy of an attribute (value and all) means that the
server validated the attribute. Echoing nothing means that the server
doesn't know what to do with the attribute. E
feedback on the list. This has happened with other WG's, too.
> Apparently I was unclear: the specific text to which I am objecting is
> -10. All of it.
Curious.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
although if there is
> WG consensus to make a change we should do so.
I think there's been a lot of discussion on the document. We need to
get closure quickly. This means not re-opening issues which were
previously discussed and decided.
Alan DeKok.
___
that it is not requirement.
I agree.
> I'll note that a lot of use cases such as channel binding where the
> tunnel method is considered without certificate verification are
> entirely inappropriate if the inner method is terminated at a different
> place than the tunnel method.
ere a legacy AAA server is
"upgraded" to support EAP, by placing an EAP-aware server in front of
it, and applying the protocol conversion outlined above.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
so key the HMAC using a key derived from *both* the TLS MSK
and from the users authentication credentials. This would ensure that
MITM attacks are impossible.
I'm interested in seeing a wider discussion of these topics.
Alan DeKok.
___
Emu
at part.
> No.
>
> The attacker controls the outer TLS session. The attacker knows the MSK.
> The keys need to be derived from something the attacker does not know in
> order to avoid an attack.
OK.
Alan DeKok.
___
Emu mailing list
Em
r tunnels using an inner method with
> an EMSK
Yes.
> 3) Figure out if we want to do something like what you propose using
> long-term credentials for inner methods that don't have an EMSK.
That's a wider discussion for the WG. I'd like to see more input.
Alan DeKok
may cross implementations and in terms of what to specify to
> get the security we need in new standards track methods. So, I think
> this could really be worth a bit of discussion at IETF 83.
We'll schedule some time for this at the meeting.
Alan DeKok.
__
to convince the server to send a
> channel binding reply. So, putting it mildly, I suspect a lot of
> clients will be fairly liberal in accepting unprotected success.
I agree.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Please submit requests for agenda items to the EMU chairs.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
t; that it's an ID verification problem, but only does so in
> debug mode. And it being a heuristic, sometimes it's just wrong. So
> getting a clear "The client didn't like me" message to act upen would be
> a good thing IMHO.
That heuristic is simple: An EAP conversation
number of round trips.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
d idea. Or, why
it's useful only in certain limited circumstances.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
t. If all goes well, we can get updated
documents issued before the next meeting.
Thanks to everyone for their help.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
s on the list?
The inner EAP-TLS has proven to work before. It seems fine.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Message forwarded from the WG-chairs list.
--- Begin Message ---
I sent a message several hours ago requesting that you help and make
your working group aware that the NomCom is looking for input from the
community. This message had a minor error. The NomCom needs to
receive community input by
. Minor editorial issues can be resolved then.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Alan DeKok wrote:
> This is a WG last call on the draft-ietf-emu-eap-tunnel-method
> document. Please post reviews, comments, feedback, etc. to this list.
>
> The WG last call will last two weeks, until February 26.
>
> If there have been no substantive comments or is
that, and a post from Jim Schaad.
I'll respond with detailed updates in another message.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Can the presenters please send slides to the chairs?
Thanks.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
s that this is "the same" system is a
subject for discussion.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
ting thought, and a bit complex. I suggest we discuss this when
> the draft gets adopted in ... "some" working group. Suggestions welcome :-)
I'd support a "roaming inter-operations" WG. Some of the documents
now in RADEXT could move there, and maybe DIME. This docu
I concur.
Not only because I'm an open source implementor. But also because that
software supports networks encompassing hundreds of millions of devices.
Software which is used by all network equipment vendors.
It is just infeasible to mandate that all devices upgrade to TLS
ms for EAP-TLS with TLS 1.3,
> it is likely that 3GPP will do that, we would much rather see an IETF RFC
> that 3GPP and other can refer to.
What, exactly is different with the message flows in EAP-TLS when TLS 1.3 is
used?
Please be specific.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
s in TLS 1.3 and why
> an update is needed.
>
> - Add information on how Key_Material and IV is derived when using EAP-TLS
> with TLS 1.3. Refering to RFC5216 for to get MSK, EMSK, etc, from
> Keying_Material.
That's the best approach.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
ld still be on this list. I think also that it could be
sponsored by an AD, and could be published quickly.
To summarize:
- the errata should probably be held for a document update
- a similar errata should be filed for 5448
- a new document should define the session IDs
- hopefully only a 3-4 page document with boilerplate..
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
s. It would be good to find a way to allow this use-case.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
I have is whether we can do anything to EAP-TLS to address the
issue. Answering that question requires a deeper dive into TLS.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
nce on how to handle large certificates and long
> certificate chains in EAP-TLS with all versions of TLS. This could be handled
> in the same bullet as “guidance or update to enable the use of TLS 1.3”.
That would definitely be useful.
Alan DeKok.
t when TLS 1.3 is used
> then Key_Material, IV, and Session-Id SHALL be derived from the
> exporter_master_secret using the TLS exporter interface.
That's good.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
good to me. I think it covers all of the open topics of
conversation.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
n if not completed within x seconds/minutes)?
Mainly the number of EAP messages. The duration is less of an issue, because
it almost always happens within a second.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
possible.
That gets you a rough upper limit on the size of the certificate.
Even the sample certificates I use for FreeRADIUS testing easily reach 2.5Kb,
with only small amounts of test information in them.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
I will review it.
> On May 28, 2018, at 4:58 PM, Joseph Salowey wrote:
>
> I didn't see any objections, but I want to make sure we have some folks
> willing to review the draft. Please respond to this thread if you would be
> willing to review the draft.
>
> Thanks,
>
> Joe
>
> On Sun, A
101 - 200 of 800 matches
Mail list logo
